Configuring SQL Servers
for Reporting

If you installed the TrafficDirector application on a Windows NT platform, and you chose the Microsoft SQL database (instead of the embedded database), you must set up a permanent repository for collecting data from agents before you can use Trend Reporter to generate historical trend reports.

This chapter describes how to define SQL servers and configure agents for logging. After you have defined the servers and configured agents, you can use Trend Reporter to generate reports based on information logged by multiple management stations.

The following sections contain more information:

How SQL Servers Work With the TrafficDirector Application

The Trend Reporter application generates reports based on information in SQL databases. The Configure SQL Servers application lets you define access to the SQL databases by configuring each database as a SQL server. Although each copy of the TrafficDirector software writes only to a single SQL server, you can use this application to configure the TrafficDirector application to read from multiple SQL servers.

The TrafficDirector application supports a distributed database architecture. This design allows you to use multiple management stations to monitor your network, each management station logging to a single SQL server. To access SQL servers that other management stations are logging to, use Configure SQL Servers to define each SQL server that you want to read from in the TrafficDirector application, associate those servers with agents.

For example, if you want to use the TrafficDirector application to generate reports, and include the data gathered by each management station, you must do the these tasks on the TrafficDirector system:

Define the SQL database that each copy of the TrafficDirector software is logging to as a SQL Server. Doing so provides the information that the TrafficDirector application needs to access each database. See "Defining SQL Servers to the TrafficDirector Application" for more information.
Associate each SQL server with an agent by adding the agents that each copy of the TrafficDirector software is logging. See "Associating SQL Servers with Agents" for more information.

Understanding Distributed Database Architecture

Polling across routers and over WAN links can be slow and waste bandwidth. The TrafficDirector application has a distributed database architecture that lets you eliminate unnecessary WAN traffic by setting up multiple iterations of the TrafficDirector application to poll agents locally and log data to their respective SQL databases. You can use a central TrafficDirector location to retrieve the information at report time. In this way, you restrict all agent polling to local segment clusters, and retrieve the information over a WAN link when you generate reports based on the data collected by each remote management station.

Figure 30-1 illustrates this distributed database design---A single TrafficDirector management station, and two TrafficDirector management stations polling their local segment clusters.

Figure 30-1: Distributed Database Architecture

Note All management stations are polling agents in their local segment clusters and writing the data to their respective SQL databases; no polling is being performed over the WAN links across routers. Depending on the structure of your organization, you can have each local site generate its own reports, or you can use a central site to generate reports based on the data gathered locally at each remote site.

Configuring the Microsoft SQL Server

The TrafficDirector application includes a utility called Trend Reporter that uses a SQL database. To use this utility, you must configure the NT server portion, including:

Creating the SQL device.
Adding the appropriate database.
Adding users with correct permissions.

Note You must install the SQL server on a Windows NT server. You must install the SQL server and SQL client before installing the TrafficDirector application.

The following sections provide more information:

Setting Server and Client Network Options

To set server and client network options, follow these steps:

Step 1 From the SQL program group, select SQL Setup.

Step 2 Click the Change Network Support box.

Make sure that only TCP/IP sockets is checked. Named Pipes will be checked by default.

Step 3 From the SQL program group, select SQL Client Configuration Utility.

Step 4 Click the Net Library tab.

Step 5 Change the Default Network from Named Pipes to TCP/IP Sockets.

Step 6 Click the Advanced tab.

Step 7 Enter the server name.

Step 8 Change the DLL name to TCP/IP sockets.

Step 9 Click Locate next to the connection string.

A list of three DLLs pops up.

Step 10 Select dbmssocn.

Step 11 Click Done.

Step 12 Click Add/Modify.

Step 13 Click Done to close the window.

Registering the SQL Server

To register the SQL server, follow these steps:

Step 1 Start the SQL Enterprise Manager from the SQL Server Program group.

Step 2 Click Server in the top menu bar.

Step 3 Click Register Server.

Step 4 In the Server field, enter the server name or select it from the pull-down menu.

This name should be the name of the NT server.

Step 5 Make sure Use Standard Security is checked.

The Login ID will be sa. Do not use a password.

Step 6 Click Register.

A green light should display next to the server name in the Enterprise Manager window. If you get an error, the server does not exist.

Step 7 From the SQL Server Program group, select Service Manager.

Both MSSQLserver and SQLExecutive processes should be started.

Step 8 Try stopping and restarting both processes and try registering the server again.

Creating the SQL Database

To create the SQL database, follow these steps:

Step 1 Click the SQL Enterprise Manager icon.

Step 2 Select Manage in the menu bar.

Step 3 Select Database Devices.

The Manage Database Devices window opens.

Step 4 Click the icon in the upper left of the window to create a new database device.

Step 5 Name this device NETSQL.

Step 6 Assign the device a size of approximately 300 MB.

This example database size is based on six agents with one RMON domain with default aging. Actual size will vary based on how many domains and agents will be polled. You can change the size of the device at any time.

Step 7 Click Create Now.

NETSQL displays in the bar graph.

Step 8 Close this window.

Step 9 Select Manage in the menu bar.

Step 10 Select Databases.

Step 11 Click the icon in the upper left of screen.

This allows you to create a new database that will be part of the new database device NETSQL that you created.

Step 12 Name this Database NSTREND_DB.

The size of this database cannot be greater than that of the database device.

Note

Step 13 Select Create Now.

Step 14 Close the window.

Step 15 From the Server Manager window, click Server Name.

A tree structure of everything you have installed should appear.

Step 16 Click Databases.

Step 17 Click on NSTREND_DB.

Step 18 Select Manage in the menu bar.

Step 19 Select Groups.

Note

Step 20 Create a user group called NETSQLUSERS.

This group will be associated with NSTREND_DB.

Step 21 Add name of the user who does the reporting.

Note

Step 22 Make sure Permit is checked along with the default, correct user name.

Step 23 Select netsqlusers under Group.

Note

Step 24 Highlight NSTREND_DB.

Step 25 Select Manage from top menu bar.

Step 26 Select Databases.

Step 27 Click the middle icon in the upper left of the screen to edit.

Step 28 Click the Options tab.

Step 29 Click Truncate Log on Checkpoint.

This command saves space for data in the database.

Step 30 Click the Permissions tab.

Step 31 Give both Netsqlusers and the user you created All permissions.

Installing the Client

Note If you plan to install the TrafficDirector application on the same Windows NT server as the SQL server you can go to Step 4 because an ISQL client is installed by default when installing a SQL server.

To install the client, follow these steps:

Step 1 Insert the SQL Server CD in the drive where you will install the TrafficDirector application.

Step 2 Run SETSUP.EXE in the i386 directory.

Step 3 Under Setup Options, select Utilities Only.

After installation, an ISQL/w icon is created.

Step 4 Click the ISQL/w icon from the SQL Server Program Group.

Step 5 Enter the SQL Server IP address.

Step 6 Enter the user name and password for the user you just created on the server.

Step 7 Select Connect.

An SQL query box opens.

Step 8 Minimize this utility.

You must stay connected when you install the TrafficDirector application on this system.

Setting Up SQL Databases

If you want a repository of network statistics so that the TrafficDirector software can use the data to create long-term trend reports with the Trend Reporter application, you must set up one or more SQL servers for logging to a SQL database.

The TrafficDirector software comes bundled with an embedded-SQL database for all Windows and UNIX platforms. The TrafficDirector software that runs on the Windows NT Server platform also enables you to use Microsoft Windows SQL Server as a SQL server database.

The following sections contain more information:

Options for Deploying the Database

You select which type of SQL database you intended to use---embedded SQL or Microsoft SQL server---while running the installation script to properly install the TrafficDirector software.

If you selected embedded SQL as the database option, all logged data is stored on the same host as where the TrafficDirector software is installed.
If you selected Microsoft SQL server as the database option, all logged data is stored on the host you have defined as the Microsoft SQL Server.

Options for Collecting Statistics

The TrafficDirector application supports a distributed database architecture so you can create reports from SQL data logged at multiple sites. You can define multiple TrafficDirector management stations to monitor (log data for) your network locally, then use Trend Reporter to collect SQL data from remote SQL databases.

By setting up your logging scheme to perform most agent polling locally, you can avoid unnecessary traffic to and from a central SQL database.

You can also configure your environment so each local site is generating reports based on the data gathered locally, or have the central site gather the reporting information from each remote site and compile reports globally.

The major tasks required to properly set up the SQL server environment include the following.

If you plan to use embedded SQL server on either Microsoft Windows or UNIX platforms:
- Identify the desired aging and utilization parameters for determining how long to maintain historical data in the SQL database. Use the Configuration Rollup application to do this. See "Starting Configure Rollup" for information on how to use the Configuration Rollup application.
- (Optional) Define any read-only SQL servers used to obtain statistics from remote logging servers. Use the Configure SQL Servers application to do this. See "Defining Embedded SQL Read-Only Servers" for information about configuring read-only SQL servers.
- Associate the SQL servers with the appropriate agent definition. Use the Configuration Manager application to do this. See "Associating SQL Servers with Agents" for more information about associating SQL servers with agents.
If you plan to use Microsoft SQL Server software for the Windows NT Server environment to log TrafficDirector data:
- Install and configure the SQL server database software according to vendor-specified instructions.
- Identify the centralized logging server to the TrafficDirector software. Use the Configure SQL Servers application to do this. See "Defining a Microsoft SQL Logging Server" for more information about defining the logging server.
- Identify the desired aging and utilization parameters for determining how long to maintain historical data in the SQL database. Use the Configuration Rollup application to do this. See "Starting Configure Rollup" for information about the Configuration Rollup application.
- (Optional) Define any read-only SQL servers used to obtain statistics from remote logging servers. Use the Configure SQL Servers application to do this.
- A remote server is one that the TrafficDirector software can retrieve data from for reporting, but does not write to.
- Associate the SQL servers with the appropriate agent definition. Use the Configuration Manager application to do this.

Defining SQL Servers to the TrafficDirector Application

The Configure SQL Servers application lets you define the address and access information the TrafficDirector software requires to either write to or read from a SQL database. Although TrafficDirector application logging writes to only a single SQL server, you can use this application to configure Trend Reporter to read from multiple SQL servers. Use Configure SQL Servers to do the following:

Designate a Windows NT logging server---For installations that implement the Microsoft SQL Server option, you must provide the TrafficDirector software with address and access information for the Windows NT Server-based SQL Server.
Designate read-only servers for distributed reporting---TrafficDirector logging can write to only one SQL Server database; however Trend Reporter can read data from multiple databases for distributed reporting, on either Windows or UNIX platforms. Use Configure SQL Servers to define this information.

The following sections provide more information:

Defining a Microsoft SQL Logging Server

If you are running the TrafficDirector software on the Windows NT Server platform and installed the Microsoft SQL Server, use the Configure SQL Servers application to define the SQL server as the logging server.

To define the logging server, follow these steps:

Step 1 Click the Config Servers icon in the TrafficDirector Admin window.

The Configure SQL Servers window opens (Figure 30-2):

Figure 30-2: Configure SQL Server Window with Microsoft SQL Installed

Step 2 Select Edit>New from the menu.

The Add Server Entry window opens (Figure 30-3).

Figure 30-3: Add Server Entry Window with Microsoft SQL Installed

Step 3 Enter the following information in the Add Server Entry window:

SQL Server Name---The name you want to define for the SQL server. The name you select can be up to 15 alphanumeric characters and is case-sensitive. You can also use dashes and underscores. This name is only used by the TrafficDirector application and does not have to match the network name defined for the server.
IP Address---The IP address of the Windows NT SQL server that you want the TrafficDirector software to access.
User Name---The SQL user name needed for the TrafficDirector software to access the SQL database.
Password---The SQL password needed for the TrafficDirector software to access the SQL database.
Enable Logging (y/n)---Specifies whether you want to use the SQL server as a logging server. A logging server is the SQL database that the TrafficDirector software writes data to. The TrafficDirector software can only log to one Windows NT Server SQL database. Enter Y if you want to use the SQL Server as the logging server, or N if you want the TrafficDirector software to read from the database for reporting purposes only.

Step 4 Click OK to accept the server configuration and add the SQL Server to the TrafficDirector configuration.

Step 5 Close the Configure SQL Servers window.

Note You do not need to create a logging server for either UNIX or Windows platforms (embedded SQL configuration). The logging server is the embedded SQL component of the TrafficDirector software.

Defining Embedded SQL Read-Only Servers

Although TrafficDirector logging can only write report data to one SQL Server---the logging server---the distributed reporting feature enables Trend Reporter to read data from multiple SQL servers while generating trend reports.

To configure any read-only SQL servers to read data and generate reports from, (on either Windows or UNIX platforms), follow these steps:

Step 1 Click the Config Servers icon in the TrafficDirector Admin window.

The Configure SQL Servers window opens (Figure 30-4).

Figure 30-4: Configure SQL Server Read-Only Window

Step 2 Select Edit>New from the menu.

The Add Server Entry window opens (Figure 30-5).

Figure 30-5: Add Server Entry Read-Only Window

Step 3 Enter the following information in the Add Server Entry window.

SQL Server Name---The name of the SQL server which can be up to 15 alphanumeric characters and is case-sensitive. You can also use dashes and underscores. This name is only used by the TrafficDirector software and does not have to match the network name defined for the server.
IP Address---The IP address of the Host where the distributed database resides.
TCP Port---The TCP port that the TrafficDirector application has set aside to use to communicate with the SQL database. The default is port 3000, and is defined in the .trafficdir.sh or .trafficdir.cshrc file. The port entered into Config Server must match the msqld TCP port defined in the .trafficdir.sh or trafficdir.cshrc file of the management system logging to the database. See the MSQL_TCP_Port line.

Step 4 Click OK to accept the server configuration and add the SQL server to the TrafficDirector configuration files.

Associating SQL Servers with Agents

You use Trend Reporter to generate reports based on information collected by specific agents. When you define a SQL server with Configure SQL Servers, the TrafficDirector application has the information it needs to access an SQL database that another copy of the TrafficDirector software is logging to.

To access the information collected by a specific agent, you must associate an SQL server with an agent name. To do so, follow these steps:

Step 1 Add the agent to the copy of the TrafficDirector software that is using the same name defined for it on the remote management station that is logging the agent.

Step 2 Specify the SQL server that the remote management station is logging to as part of the agent configuration.

To assign the appropriate server to each agent, follow these steps:

Step 1 Click the Admin radio button in the TrafficDirector main window.

Step 2 Click the Config Manager icon.

Step 3 Select an agent.

Step 4 Select Edit.

Step 5 Click the SQL Server list box.

Step 6 Select the appropriate server for the agent.

Step 7 Click OK.

The proper SQL server definition has been assigned to the agent.

Step 8 If necessary, repeat Steps 3 through 7 for each agent.

For example, the TrafficDirector application is running on a Windows NT platform in New York and polling two agents named NewYork_1 and NewYork_2. You want to generate reports on the NewYork_1 and NewYork_2 segments from your copy of the TrafficDirector software in Boston.

You must first define the SQL server to which the TrafficDirector software in New York is logging. For example, you create the SQL server with the name NewYork_Server.

Figure 30-6 illustrates the SQL server configuration:

Figure 30-6: SQL Server Configuration

You can use Configuration Manager to add two agents named NewYork_1 and NewYork_2 to the TrafficDirector station in Boston. For each agent, you must define NewYork_Server as the SQL Server logging that agent.

After you have added agents NewYork_1 and NewYork_2 to the TrafficDirector station in Boston, you can use Trend Reporter to select those agents and run a variety of reports (Figure 30-7).

Figure 30-7: Associating a Server With an Agent

Maintaining SQL Server Definitions

There might be times when you want to edit a SQL server definition or delete a definition that is no longer in use. For example, on Windows platforms, you may want to designate a different logging server. On UNIX platforms, you can change the TCP port assignment if the msqld port changes on the remote management station. In these cases, you can either edit or delete the SQL server definitions as outlined in the following sections:

Editing Server Definitions

To edit a server definition, follow these steps.

Step 1 Click the Config Servers icon in the TrafficDirector Admin window.

The Configure SQL Servers window opens.

Step 2 Select the remote server entry you want to edit.

Step 3 Select Edit>Edit from the menu.

Step 4 The Edit Server Entry window opens.

Step 5 Change any of the parameters for the selected SQL server entry.

Step 6 Click OK to accept the server definition and add the SQL server to the TrafficDirector configuration files with the new changes.

Deleting Server Definitions

To delete an SQL server configuration definition no longer needed, follow these steps:

Step 1 Click the Config Servers icon in the TrafficDirector Admin window.

Step 2 Select the SQL server entry you want to delete.

Step 3 Select Edit>Delete from the menu.

Step 4 The TrafficDirector software deletes the SQL server configuration and removes it from the Configure SQL Servers main window.

Overview of Logging

The TrafficDirector application retrieves information from agents (SwitchProbe devices and Network Analysis Modules) on network segments. The data can be used for display in the real-time monitoring application or periodically logged to a SQL database and later extracted to create customized reports.

Logging is the act of retrieving data from an agent and storing it in a database.

The agent(s) is polled for information.
Data retrieved from the agent is logged into a SQL database.

: Data is logged based on the logging parameters enabled in the properties file associated with the device being polled. See Chapter 6, "Working with Properties" for more information about properties files.
: You must configure the TrafficDirector software to an SQL database. See "Setting Up SQL Databases" for information about setting up SQL servers for logging to a SQL database.

You can retrieve, analyze, and display data by generating reports with Trend Reporter.

: If the device is not configured to collect data, the data can not be logged. If it is not being logged, it cannot be reported.

The following section provides an overview of daemons:

Understanding Daemons

Understanding Daemons

Daemons are processes that run in the background and are disconnected from a process group and terminal. The TrafficDirector software uses specific daemons to control other daemons, control traps, poll (get network data from agents), log data (put data to SQL database), and purge database records. Daemons that work with related configuration files that define how and when they are used to perform their roles.

Table 30-1 describes the daemons that work with the SQL database and the TrafficDirector application.

Table 30-1: Daemons That Control Logging
This Daemon... Performs This Function

Check daemon
(dbchkd)

Started by the TrafficDirector software, this daemon starts the following daemons:

Database server daemon (msqld)

Trap daemon (dvtrapd)

Snapshot daemons (dbsnapd)

IP ping snapshot and Proxy SNMP daemon (dbsnpres)

Extraction daemon (dbextrad¹)

aging daemon (dbrolld)

Snapshot daemon
(dbsnapd)

Started by the dbchkd daemon to poll network agents and log data to the snapshot, detail, and summary binary files.

Aging daemon
(dbrolld)

Ages all database tables (once every 24 hours) at 2:00 am.

SQL Server daemon (msqld)

Migrates data records from binary files to the embedded SQL database. Also handles reporting queries.

IP Ping daemon
and Proxy SNMP
(dbsnpres)

Polls network agents and logs information to the snapshot, detail and summary IP ping binary files.

Extraction daemon
(dbextrad)

Migrates data records from binary files to a Microsoft SQL database (Windows NT platforms only).

Autoreporter daemon (autorptd)

Sequentially runs all reports configured in the autorpt.cfg file. This daemon starts up daily at 3:00am.

Trap daemon
(dvtrapd)

Listens for and logs SNMP trap messages. Receives and logs important fatal and warning messages from all daemons.

¹Microsoft NT SQL only.

**Table 30-1: Daemons That Control Logging**
This Daemon...	Performs This Function
Check daemon (dbchkd)	Started by the TrafficDirector software, this daemon starts the following daemons: Database server daemon (msqld) Trap daemon (dvtrapd) Snapshot daemons (dbsnapd) IP ping snapshot and Proxy SNMP daemon (dbsnpres) Extraction daemon (dbextrad¹) aging daemon (dbrolld)
Snapshot daemon (dbsnapd)	Started by the dbchkd daemon to poll network agents and log data to the snapshot, detail, and summary binary files.
Aging daemon (dbrolld)	Ages all database tables (once every 24 hours) at 2:00 am.
SQL Server daemon (msqld)	Migrates data records from binary files to the embedded SQL database. Also handles reporting queries.
IP Ping daemon and Proxy SNMP (dbsnpres)	Polls network agents and logs information to the snapshot, detail and summary IP ping binary files.
Extraction daemon (dbextrad)	Migrates data records from binary files to a Microsoft SQL database (Windows NT platforms only).
Autoreporter daemon (autorptd)	Sequentially runs all reports configured in the autorpt.cfg file. This daemon starts up daily at 3:00am.
Trap daemon (dvtrapd)	Listens for and logs SNMP trap messages. Receives and logs important fatal and warning messages from all daemons.

See Chapter 33, "Reviewing Report Resource Information" for more information about each of these daemons.

Enabling and Disabling Logging

If you disable logging, you cannot generate any reports because no data is being logged to the SQL database. This is true regardless of what platform you are using or what you have enabled for logging in your properties files.

There are four ways to disable logging, as listed in Table 30-2.

Table 30-2: Enable/Disable Logging Utility
Logging On/Off UNIX Windows NT

Installation Script

Supported

Supported

Logging -on |-off commands

Supported

Supported

Exit---shut down daemons

Supported^¹

Supported

Shut Down Utility---dbshutdown

Supported

Not Available^²

¹On UNIX, the msqld and dvtrapd daemons continue to run even if the user selects Yes to the Shutdown all daemons prompt.
²On Windows NT, running dbshutdown -all from the command console will not work because all TrafficDirector daemons are running under the NT Service Control Manager (SCM) with kernel mode access.

**Table 30-2: Enable/Disable Logging Utility**
Logging On/Off	UNIX	Windows NT
Installation Script	Supported	Supported
Logging -on \|-off commands	Supported	Supported
Exit---shut down daemons	Supported^¹	Supported
Shut Down Utility---dbshutdown	Supported	Not Available^²

Note If you disable or stop the RMON Manager Service, all logging and reporting features are automatically disabled. See Appendix B, "Maintaining the TrafficDirector Environment" for more information.

The following sections provide more information about enabling and disabling logging:

Enabling and Disabling Logging During Installation

The TrafficDirector installation script prompts you to enable (default) or disable the TrafficDirector data logging.

To enable logging, follow these steps:

Step 1 Click the Yes radio button.

Step 2 Press Next.

The TrafficDirector logging daemons become enabled. This operation affects all agents configured with a logging enabled properties file. Information for these agents will be logged to a configured SQL Server.

To disable logging, follow these steps:

Step 1 Click the No radio button.

Step 2 Press Next.

The TrafficDirector logging daemons are disabled. This operation disables logging for all agents configured with a logging enabled properties file.

Enabling and Disabling Logging After Installation

Logging is by default turned on after installation.

To disable logging---Type the following command at the command prompt:

: $NSHOME/bin/logging -off
: The logging.on file appears in the $NSHOME/usr directory

To enable logging---Type the following command at the command prompt:

: $NSHOME/bin/logging -on
: The logging.off file appears in the $NSHOME/usr directory.

Note If logging is on and the RMON Manager Service is disabled or stopped, the logging.on file does not change to logging.off. See Appendix B, "Maintaining the TrafficDirector Environment" for more information about the RMON Manager Service.

Shutting Down Daemons when Exiting the TrafficDirector Application

When you exit the TrafficDirector application, a confirmation box appears, prompting you to select Yes or No to shutdown all daemons.

Do you want to shutdown all daemons?

On UNIX, the msqld daemon and dvtrapd daemon continue to run even if you select Yes.

If you select Yes, all daemons will shut down. In Windows NT, this operation causes logging and reporting to become disabled. In UNIX, the msqld and dvtrapd daemons will continue to run and logging and reporting features will remain enabled.
If you select No, all daemons continue to run and logging and reporting will remain enabled.

The following section contains more information about shutting down daemons:

Using the dbshutdn Shutdown Utility

Using the dbshutdn Shutdown Utility

Use the dbshutdn command-line utility to stop all logging daemons currently running (dbsnapds, msqld, or dbextrad and dbsnpres).

Note The dvtrapd daemon is not stopped with this utility. You must use the
dbshutdown - all command to shut down dvtrapd.

To complete the shutdown, the utility goes through the list of process ids (PIDs) created when dbchkd ran various daemons and shut down all of the daemons.

Table 30-3 shows the process ids:

Table 30-3: Process Identification
This Process
ID File... Contains Process IDs For

agent.pid

dbsnapds (all daemons for *.alg files)

switch.pid

dbsnapds (all daemons for *.slg files)

fragent.pid

dbsnapds (all daemons for *.flg files)

msqld.pid

msqld

dbextrad.pid

dbextrad

dbsnpres.pid

dbsnpres

**Table 30-3: Process Identification**
This Process ID File...	Contains Process IDs For
agent.pid	dbsnapds (all daemons for *.alg files)
switch.pid	dbsnapds (all daemons for *.slg files)
fragent.pid	dbsnapds (all daemons for *.flg files)
msqld.pid	msqld
dbextrad.pid	dbextrad
dbsnpres.pid	dbsnpres

Note On Windows NT, the dbshutdown - all command is used by the RMON Manager Service to bring down all daemons (including msqld and dvtrapd).

Logging and Aging Data for Reporting

When you generate large numbers of data samples for extended periods of time, you use more disk space. One way to automatically maintain disk space is to tailor your data aging parameters using the Config Rollup application.

Use Config Rollup to define how long (in days) different types of report data is stored in the SQL report database before it is automatically deleted by the Rollup and Aging daemon (dbrolld).

The following sections show you how to edit aging parameters to suit your reporting and database administration needs:

Understanding Database Aging

The aging parameters you define determine the number of days Protocol, Segment, Host, Conversation, IP-Ping, Proxy SNMP, ALL NL, ALL AL, ART, and ART Server information is maintained in the detail and summary database tables. By specifying a minimum utilization percentage parameter, you define what level of Host or Conversation utilization must be reached or exceeded for information to be logged to host and conversation database tables. Use the minimum utilization percentage parameters to control how much host and conversation traffic gets logged into the SQL database.

You can specify the number of days you want to keep detail and summary data for each statistic type - Protocol, Segment, Host, Conversation, IP-Ping, Proxy SNMP, ALL NL, ALL AL, ART, ART Server - before it is automatically deleted by the dbrolld daemon. See Chapter 33, "Reviewing Report Resource Information" for more information about the statistical data contained in each database table.

For example, you may want to keep daily or monthly summary data to use for long term trend monitoring; to do this you would specify 365 days for summary aging. You might only want to keep detail data for several days and delete it on a weekly basis. To do this, you would specify seven days for detail aging.

Starting Configure Rollup

To start Configure Rollup, follow these steps:

Step 1 Click the Configure Rollup icon in the TrafficDirector Admin window.

The Configure Rollup window opens (Figure 30-8).

All fields are set to the TrafficDirector default values.

Figure 30-8: Config Rollup Window

The following sections contain more information about Configure Rollup:

Understanding the Configure Rollup Window

Before you begin working with Config Rollup procedures, see Table 30-4 for a description of the data fields in the Configure Rollup window:

Table 30-4: Config Rollup Fields
This Field... Contains This Type of Information

Aging (Unit: Days)

The aging parameters you define determine the number of days Protocol, Segment, Host, Conversation, IP-Ping, Proxy SNMP, ALL NL, ALL AL, ART, and ART Server information is maintained in the detail and summary database tables.

Specify the number of days you want to keep detail and summary data for each statistic type - Protocol, Segment, Host, Conversation, IP-Ping, Proxy SNMP, ALL NL, ALL AL, ART, ART Server.

Detail Aging---Shows the number of days that information ages before the Aging daemon determines it to be obsolete and deletes it from the details table. Detail aging must be greater than one day. The default value for protocol and segment statistics from the detail table is 31 days; for host, conversation, IP Ping, Proxy SNMP, ALL NL, ALL AL, ART, and ART Server it is 7 days.

Daily Aging---Shows the number of days that information ages before the Aging daemon determines it to be obsolete and deletes it from the daily table. Daily aging must be greater than one day. The default value for protocol and segment statistics from the Summary (Daily) table is 366 days; for host, conversation, IP Ping, Proxy SNMP, ALL NL, ALL AL, ART, and ART Server it is 31 days.

Host and Conversation
Tables
(Minimum Utilization)

By specifying a minimum utilization percentage parameter, you define what level of Host or Conversation utilization must be reached or exceeded for information to be logged to host and conversation database tables. Use the minimum utilization percentage parameters to control how much host and conversation traffic gets logged into the SQL database.

Host Threshold---Configures the minimum utilization percentage that a host (combined inbound and outbound utilization) must meet before it's included in the host details table. The snapshot daemon compares a host segment's utilization percentage to this number and logs data to the host bin details binary file only if the utilization percentage meets or exceeds this value.

Conversation Threshold---Configures the minimum source-to-destination utilization percentage that a conversation must meet before it's included in the conversation details table. This means that the Snapshot daemon compares a conversation's source-to-destination utilization percentage to this number and logs data to the conversations bin details binary file only if the utilization percentage meets or exceeds this value.

Range Filter

Determines how many hours of summary data will be logged in the SQL daily (summary) table.

The default settings for the hour-range parameter is (00:00-24:00, or all the hours in a 24 hour period). For example, if you set the range to (08:00 - 18:00), the SQL daily (summary) tables will contain only 10 hours of summary data instead of the standard 24 hours.

The hour-range values set in the Config Rollup application are used to initialize the Trend Reporter Graphical User Interface.

Multiday reports can be generated for specific hour ranges within each day (for example, peak business hours).You can configure each report or auto report independently with unique hour-range parameter settings. See Chapter 31, "Configuring and Generating Reports" for more information about setting specific hour ranges for a report.

You can use the hour-range parameter, maintained in the $NSHOME/usr/dbupdate.cfg file, to affect the duration (time-range) of the data maintained in the SQL daily (summary) tables.

**Table 30-4: Config Rollup Fields**
This Field...	Contains This Type of Information
Aging (Unit: Days)	The aging parameters you define determine the number of days Protocol, Segment, Host, Conversation, IP-Ping, Proxy SNMP, ALL NL, ALL AL, ART, and ART Server information is maintained in the detail and summary database tables. Specify the number of days you want to keep detail and summary data for each statistic type - Protocol, Segment, Host, Conversation, IP-Ping, Proxy SNMP, ALL NL, ALL AL, ART, ART Server. Detail Aging---Shows the number of days that information ages before the Aging daemon determines it to be obsolete and deletes it from the details table. Detail aging must be greater than one day. The default value for protocol and segment statistics from the detail table is 31 days; for host, conversation, IP Ping, Proxy SNMP, ALL NL, ALL AL, ART, and ART Server it is 7 days. Daily Aging---Shows the number of days that information ages before the Aging daemon determines it to be obsolete and deletes it from the daily table. Daily aging must be greater than one day. The default value for protocol and segment statistics from the Summary (Daily) table is 366 days; for host, conversation, IP Ping, Proxy SNMP, ALL NL, ALL AL, ART, and ART Server it is 31 days.
Host and Conversation Tables (Minimum Utilization)	By specifying a minimum utilization percentage parameter, you define what level of Host or Conversation utilization must be reached or exceeded for information to be logged to host and conversation database tables. Use the minimum utilization percentage parameters to control how much host and conversation traffic gets logged into the SQL database. Host Threshold---Configures the minimum utilization percentage that a host (combined inbound and outbound utilization) must meet before it's included in the host details table. The snapshot daemon compares a host segment's utilization percentage to this number and logs data to the host bin details binary file only if the utilization percentage meets or exceeds this value. Conversation Threshold---Configures the minimum source-to-destination utilization percentage that a conversation must meet before it's included in the conversation details table. This means that the Snapshot daemon compares a conversation's source-to-destination utilization percentage to this number and logs data to the conversations bin details binary file only if the utilization percentage meets or exceeds this value.
Range Filter	Determines how many hours of summary data will be logged in the SQL daily (summary) table. The default settings for the hour-range parameter is (00:00-24:00, or all the hours in a 24 hour period). For example, if you set the range to (08:00 - 18:00), the SQL daily (summary) tables will contain only 10 hours of summary data instead of the standard 24 hours. The hour-range values set in the Config Rollup application are used to initialize the Trend Reporter Graphical User Interface. Multiday reports can be generated for specific hour ranges within each day (for example, peak business hours).You can configure each report or auto report independently with unique hour-range parameter settings. See Chapter 31, "Configuring and Generating Reports" for more information about setting specific hour ranges for a report. You can use the hour-range parameter, maintained in the $NSHOME/usr/dbupdate.cfg file, to affect the duration (time-range) of the data maintained in the SQL daily (summary) tables.

Configuring Day Ranges Start/End Times

To configure the Day Range Start/End time for a report, follow these steps:

Step 1 Click the Trend Reporter icon in the TrafficDirector main window.

Step 2 Set the Day Range Start/End times.

Using Baseline Reports

Baseline reports compare two similar time ranges in one Protocol Usage or Segment History/Summary report. You cannot run baseline reports on Host/Conversation tables.

Baseline reports display data that has been previously collected from agents. The data is stored in a SQL database from which Trend Reporter can generate reports, based on your preferences.

You can use the Baseline reports to compare two similar time ranges in one report. In a Baseline report the baseline data is presented adjacent to the current (new) data.

Use Baseline reports to track levels of activity on the network at specific times during the day, plan network growth, and establish usage policies.

Baseline A and Baseline B

Each baseline table (Protocol, Segment, Host, etc.) can be configured to participate in the baseline time-range (enabled/disabled). Baseline A and Baseline B time range data is maintained (protected against purge) so that baseline data will be available at report time.

Trend Reporter uses the data in these tables to create a baseline report.

A box with a check mark indicates that the information in that table will be protected from purge according to the defined Baseline Range (Figure 30-9).

Figure 30-9: Baseline A and B---and Corresponding Tables

Baseline Range

Two baseline time ranges can be configured to prevent the database from purging the information during that specified time range. The time ranges you specify in the Baseline range supersede the aging parameters defined in the Detail and Daily Aging [Unit Days] category. The time range applies only to the individual baseline table values enabled in the Config Rollup screen. If a baseline value for a particular table is not enabled, it will not be included in the baseline.

Two baselines are configurable. If you do not add baseline ranges in Config Rollup, even though each baseline value for each table is enabled by default, you will not see any baselines displayed as an option when you generate individual reports.

Use the Baseline Range area (Figure 30-10) to configure Start and End times for Baseline A and Baseline B data.

Figure 30-10: Baseline Range Box

Customizing the Database Aging Parameters

To customize the database aging parameters for each statistic type, follow these steps:

Step 1 Click the Admin radio button in the TrafficDirector main window.

Step 2 Click the Config Rollup icon.

Step 3 Enter the number of days for detail aging for each database table.

You can specify one or more days for each table.

Step 4 Enter the number of days for summary (daily) aging for each database table.

You can specify one or more days for each table.

Step 5 Enter the minimum utilization value that must be reached or exceeded to log Host or Conversation data.

Step 6 Enable or disable Baseline tables (Protocol, Segment, Host, and so on) to participate in the baseline time-range.

By default all tables are enabled.

Step 7 Configure the Baseline A and Baseline B time ranges.

Data during this time period is maintained (protected against purge) so that baseline data will be available at report time.

Step 8 Click OK to click and apply the parameters, or click Cancel to cancel and reset all fields.

Table of Contents