dbmonitor_nxd--Database Monitoring Daemon

The Database Monitoring daemon (dbmonitor_nxd) provides a mechanism to allow CA SDM cache of specific database tables to be refreshed when changes are made externally from CA SDM.
casm172
The Database Monitoring daemon (dbmonitor_nxd) provides a mechanism to allow CA SDM cache of specific database tables to be refreshed when changes are made externally from CA SDM.
The main function of dbmonitor_nxd is to generate CHANGE notifications for changes in specified tables that did not occur through CA SDM. In order to perform this function, the monitor periodically queries the database, determines what was changed externally and then sends CHANGE notifications to the bpvirtdb_nxd server. The bpvirtdb_nxd server notifies all domsrvr servers of the change, which causes each domsrvr to update its cache of specific database objects and then notify all other processes that subscribe for changes in the specified tables.
This mechanism works well for the occasional external change in tables that are monitored. However, in cases where mass updates are made externally a storm of CHANGE notifications are broadcast which leads to many database queries from various CA SDM processes which significantly impacts CA SDM's performance.
In order to eliminate this impact on CA SDM performance, dbmonitor_nxd has been updated for this release of the product. The Monitor supports a command line interface that allows the user to start and stop the monitoring of specified tables.
Syntax
This command has the following format:
dbmonitor_nxd -c <command> -t <tables>
  • <command>
    Enter start or stop.
  • <tables>
    Specifies a table name or a comma delimited list of table names that must match one or more of the tables specified in the NX_DBMONITOR_TABLES environment variable.
Each request is sent to the dbmonitor_nxd daemon. The daemon takes the appropriate action and returns a message to the user indicating the action taken.
  • If a start request is invoked for a table that is already started, no action is taken.
  • If a stop request is made for a table that is already stopped, no action is taken.
  • If monitoring is successfully stopped or started for a table, a log message is also written to stdlog.
When the Monitor is paused for a table, all CA SDM processes that cache data from these tables may become out of date and no provision is made to update this cache.
For example, BOPLGIN caches Contact records (from the ca_contact and usp_contact tables) and this cache would not be updated if the Monitor was paused for the ca_contact table during the time external updates were loaded into the database. In the BOPLGIN case this will have little consequence because the essential Contact attributes cached in BOPLGIN are taken from the usp_contact table and not the ca_contact table.
When the Monitor is paused for a table, Web Users will not be able to see changes in the table while viewing a detail form that were made externally while the Monitor was paused.