Manage the volume of information in the alerts.details table

Use the following guidelines to manage the volume of information that is stored in this table.

• Ensure that the clean_details_table automation is enabled on both your primary and backup ObjectServers. This automation performs housekeeping cleanup on the alerts.details table, and deletes any entries not found in the alerts.status table.
• Avoid using details($*) in probe rules files, to add all the alert information to the alerts.details table. For each alert in the alerts.status table, multiple rows might be added to the alerts.details table because the details($*) command in the rules file records each token as one row. After using details($*) for long periods of time, the ObjectServer tables become very large and the performance of the ObjectServer suffers. Only use details($*) when you are debugging or writing rules files.

  If you need to add more information for the alert, use the details statement to add specific elements or use a regular expression to extract specific elements from the details. For example, details($a,$b) adds the elements $a and $b to the alerts.details table.

  Note also that each details entry requires a separate INSERT statement, so for an event with 20 details entries, 21 inserts will be made to the ObjectServer. An event with no details will, however, be a single insert.

• From the SQL interactive interface, use the DELETE SQL command to clear all the records in the alerts.details table. For example:

  delete from alerts.details;

  Note: Manually deleting data from the alerts.details table is a temporary solution because the number of details will increase again to a high volume if the first two guidelines for managing the alerts.details table are not followed. Instead of using alerts.details, consider using the ExtendedAttr column with the nvp_add rules file function, and the nvp_get or nvp_set SQL functions to store those fields that have been put in details.