Maintaining the history database

Complying with the following guideline and procedures, which are suitable for all types of DBMS, reduces the potential for problems or unnecessary downtime. 

Related topics

Defining-data-rules-and-templates

History-data 

Backing up the database

Your MainView Middleware Monitor database should be part of your regular backup routine. Having up-to-date, valid backups limits any potential data loss and ensures that you can be running again quickly in the event of an unplanned outage.

BMC strongly recommends that you configure database backups and logging with the ability to restore the database to a specific point in time.

Offline backups are not recommended because the product is designed to run continuously and it expects the database to always be available.

Purging performance and availability history data

Performance and availability history data are purged via an automated process. See Defining-configuration-options-in-services-cfg for details about these parameters:

  • amount_of_hires_to_keep
  • amount_of_lowres_to_keep

Note

Setting amount_of_hires_to_keep or amount_of_lowres_to_keep to 0 deactivates the purge process, which is useful for implementations that manage the 

MainView Middleware Monitor

 history data using custom methods.

Purging Transaction Management history data

Collected Transaction Management history data are purged via an automated process.

There are eight tables that store collected Transaction Management history data. These tables store the data in a circular pattern, where only one table at a time has active inserts. The active table switches based on time. When all tables have been used, the first table is purged and re-used. See Defining-configuration-options-in-services-cfg for detail about the parameter amount_of_hires_to_keep, which is in the BTM_History stanza of services.cfg.

Note

Compressed Transaction Management history data are not purged automatically (table: QP_BTM_HDLR - Note that this table is no longer used with newly generated transaction pathway model instances, but the data is still useful for older model instances).

Purging Event Service Journal records

Event Service Journal records are purged via an automated process. See the Event_Service section for details about these parameters:

  • amount_of_event_journal_to_keep
  • event_journal_purge_buffer_size
  • event_journal_purge_candidate_keys_in_memory 

Note that when migrating from versions prior to 8.1, the amount_of_event_journal_to_keep is set to 0d, meaning no purge will be performed.

If you have been running MainView Middleware Monitor for multiple years in this installation, you may have a large number of Event Service Journal entries that will be purged after configuring this parameter. If you have any concerns about database transaction logging related to this initial purge, contact BMC Support before changing this parameter.

The log related messages for the purging process can be found in the qphs.log, as it is the history service that is actually performing the purge. 

Note

Setting amount_of_event_journal_to_keep to 0d deactivates the purge process. This is useful for implementations that manage the 

MainView Middleware Monitor

 Event Service Journal data using custom methods.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*