Table Of Contents

Purging Data and Maintaining System Stability

Cisco ANA Database Schemas

Purging Old Data Using the Integrity Service

Auto-Archiving Fault Data Based on the Size of Tickets

Purging Data and Maintaining System Stability

---

These topics provide basic information about data purging and archiving and system stability:

•Cisco ANA Database Schemas, describes the database schema names.

•Purging Old Data Using the Integrity Service, describes how the Cisco ANA integrity service maintains system stability by checking for and purging old data.

•Auto-Archiving Fault Data Based on the Size of Tickets, describes how Cisco ANA archives large tickets.

Cisco ANA Database Schemas

Cisco ANA database contains the following schemas, each of which contains different types of data. The variable anauser is the name of the UNIX user account for the Cisco ANA application, which is created when Cisco ANA is installed.

•anauser is the main schema that contains most of the Cisco ANA data. This schema also contains the fault database.

•anauser_ep is the Event Archive schema. It contains all raw events that are sent from devices to Cisco ANA. Specifically, these raw events are received by the AEC and persisted in the Event Archive. You can disable event archiving using the procedure in Disabling and Enabling Raw Event Archiving, page 12-13.

•anauser_dwe is the Workflow Engine schema that contains all data (templates and workflows) related to the Workflow Engine. The Workflow Engine is described in Workflow Administration Tasks, page 8-1.

Purging Old Data Using the Integrity Service

The Cisco ANA integrity service is responsible for maintaining system stability by running integrity tests to maintain the database and eliminate clutter in the system. It is an internal service that runs on a gateway or units. Integrity tests run every 12 hours, except for the test that enforces active ticket limits (which runs hourly).

You can schedule integrity tests to run automatically at specific intervals using cronjob commands. By default, integrity service tests run automatically every hour.

For example, the following line in the crontab file runs the file every_12_hours.cmd at 11:00 a.m. and 11:00 p.m.:

0 11,23 * * * local/cron/every_12_hours.cmd > /dev/null 2>&1

In this example, the integrity service capacity tests are defined in the every_12_hours.cmd file; for example:

echo "`date '+%d/%m/%y %H:%M:%S -'` running integrity.executeTest capacity"

cd ~/Main ; ./mc.csh localhost 8011 integrity.executeTest capacity >& /dev/null

In this example, the first line is written to the gateway log and indicates the test start time. The next line runs the test.

Integrity service test parameters are defined in the registry.

---

Note Changes to the registry should be performed only with the support of Cisco. For more information, contact your Cisco account representative.

---

The integrity service tests include the following:

•backup—Backs up the registry, encryption keys, and crontab files. (Registry backup settings are described in Backing Up and Restoring the Registry, page A-1.)

•activeTicket—Archives tickets when the system's open tickets count (total number of active tickets) exceeds a defined threshold. By default, this threshold is 15,000. Cisco ANA generates a warning alarm when the total exceeds 6,000 tickets. When the total exceeds 15,000 tickets, Cisco ANA purges the total number of tickets to 12,000.

•partitioning—Monitors the size of database partitions (whether to split the partitions and drop old data).

•businessObject—Checks for invalid OIDs in business objects.

•capacity—Checks the disk space capacity and sends alarms.

•mapAspect—Removes mapAspect OIDs which are not connected to any hierarchy.

•unusableIndexes—Checks for unusuable table indexes and, if found, rebuilds them.

•oidArrays—Removes OIDs which exist in the OidArrays table, but not in a parent table.

•workflowEngine—Deletes all complete workflows that have reached a certain age (in days).

•analyze—Generates a System event if the period between the current date and the date each database table was analyzed is larger than the analyze-Period setting.

•Removes old reports.

Auto-Archiving Fault Data Based on the Size of Tickets

---

Note This functionality is only supported if you have downloaded and installed Cisco ANA 3.7 Point Patch 3.7.0.2.8. To obtain this patch, contact your Cisco representative.

---

Every 5 minutes, Cisco ANA checks the Fault Database to see if it contains any large tickets that should be archived. A ticket is considered large if it has more than 150 events associated with an alarm.

If any large tickets are found, Cisco ANA does the following:

•If a large ticket is found, it generates a System event similar to the following:

The system contains the following XXX ticket(s) with more than 150 events per alarm. 
You can manually archive these tickets or the system will automatically archive them 
in: 15 minutes

If the user does not respond within 15 minutes, Cisco ANA archives the tickets.

•If the agent finds more then 1500 large tickets then it will also send a system event notifying about it.

There are more than X excessively large tickets in the system (tickets with more than 
150 events per alarm).

Table 13-1 shows the registry parameters that control this type of Fault Database purging.

---

Note Changes to the registry should only be carried out with the support of Cisco. For details, contact your Cisco account representative.

---

Table 13-1 Registry Settings for Purging Large Tickets From the Fault Databases 

Registry Entry	Description	Default Value
findLargeTicketsMessageInterval	Interval for searching for large tickets (in minutes).	5
maxTicketSize	When the number of events associated with an alarm surpasses this number, consider it a large ticket and generate a System event.	150
autoRemoveTimeInterval	Interval at which to archive a large ticket (in minutes) after sending System event.	15
oversizedTicketAmountLimit	When the number of large tickets surpasses this number, generate a System event.	1500