3.23 SetupSupplementalDB

Use this Knowledge Script to create an Avaya CM supplemental database, including the tables and stored procedures needed to store call detail records (CDRs), disconnected phone information, and deregistered phone information.

You can also create the Avaya CM supplemental database using the Set up supplemental database? parameters in the Discovery_AvayaCM Knowledge Script.

For more information, see Understanding the Avaya CM Supplemental Database.

3.23.1 Resource Object

AvayaCM Active SPE object

3.23.2 Default Schedule

By default, this script runs once.

3.23.3 Setting Parameter Values

Set the following parameters as needed:


How to Set It

General Settings

Job Failure Notification

Event severity when job fails

Set the event severity level, from 1 to 40, to indicate the importance of the failure of the SetupSupplementalDB job. The default is 5.

Raise event if database setup succeeds?

Select Yes to raise an event if creation of the Avaya CM supplemental database is successful. The default is unselected.

Event severity when database setup succeeds

Set the event severity level, from 1 to 40, to indicate the importance of the success of the creation of the Avaya CM supplemental database. The default is 25.

CDR Parameters

Number of days to keep call detail records

Specify the number of days’ worth of CDRs you want to keep in the Avaya CM supplemental database. Data older than what you specify is discarded. The default is 7 days.

NOTE:Run DeleteCDRRecords Knowledge Script to remove old records from the supplemental database.

SQL Server Information

Local SQL Server instance name

Specify the name of the local SQL Server instance (on the proxy agent computer) in which you want to create the new Avaya CM supplemental database. Leave this parameter blank to accept the default name.

3.23.4 Understanding the Avaya CM Supplemental Database

The Avaya CM supplemental database is a Microsoft SQL Server database you create on the proxy agent computer. The supplemental database fulfills several functions.

Storage for CDRs and RTCP packets

The managed object on the proxy agent computer receives call detail records (CDRs) from Communication Manager servers and RTCP packets from phones registered to Communication Manager servers. The proxy agent computer saves the CDR and RTCP packet data to tables in the Avaya CM supplemental database. The CallActivity, CallFailures, CallQuality, and CallQuery Knowledge Scripts query the supplemental database for the data they need.

When you start the CallActivity, CallFailures, CallQuality, or CallQuery Knowledge Script job, the managed object begins collecting CDR and RTCP data to store in the Avaya CM supplemental database. After the job stops, the managed object continues to collect CDRs and packet data. Data collection stops within a time period equal to two intervals of the job, but never less than 4 minutes after the job stops.

When you create the supplemental database, you specify how long data is retained before being deleted and archived. AppManager automatically deletes CDRs older than the retention age you specify.

Storage for phone deregistration and disconnection data

The PhoneDeregistrations and PhoneConnectivity Knowledge Scripts use SNMP queries to create lists of phones that are unregistered or registered but disconnected. The scripts query the Avaya CM supplemental database, which is populated by the RetrieveConfigData script with configuration data retrieved from Communication Manager.

To create and use the supplemental database:

  1. Create the database. Create one Avaya CM supplemental database per Communication Manager cluster you are monitoring. Use the Discovery_AvayaCM or SetupSupplementalDB Knowledge Script for this purpose.

  2. Populate the database. Use RetrieveConfigData to retrieve configuration data from Communication Manager and save it in the Avaya CM supplemental database.

  3. Monitor the data in the database. Use the following scripts to analyze the data in the database.

    • CallActivity monitors active and completed calls.

    • CallFailures monitors calls that ended with the condition codes you specify.

    • CallQuality monitors jitter, latency, lost data, and MOS.

    • CallQuery searches for data based on query filters you select.

    • PhoneConnectivity monitors disconnected registered phones and maintains a history of monitored phones in the supplemental database.

    • PhoneDeregistrations monitors phone deregistrations and maintains a history of phone deregistrations in the supplemental database.