Model Repository monitoring

The Model Repository is an Oracle database that contains essential information necessary to build, operate, and maintain a list of all managed servers, their hardware, their configuration, the operating system, and all other applications.

For more information about the Model Repository, including detailed information about monitoring the Model Repository, see the SA 10.60 Install section.

• Model Repository port
• Monitoring processes for the Model Repository
• Model Repository logs
• Tablespace usage
• Multimaster conflicts

Model Repository port

The default port for the Model Repository is 1521; however, this might have been modified by the database administrator who installed it.

Monitoring processes for the Model Repository

Monitor the Oracle Database process. If the process is not found, the database has failed or was not started.

On Linux, execute the command on the server running Oracle:

# ps -fu oracle | grep pmon

Running this command should produce output similar to the following:

oracle 2112 1 0 21:22 ?    00:00:00 ora_pmon_truth

(The process name might include the database SID, truth, as shown in this example.)

If the process is not found, the listener has failed or was not started.

On Linux, use this command to monitor the Oracle Listener process:

# ps -fu oracle | grep tnslsnr

Running this command should produce output similar to the following:

oracle 2021 1 0 21:22 ?    00:00:01 /u01/app/oracle/product/11.2.0/db_2/bin/tnslsnr LISTENER -inherit

Model Repository logs

Log files for the Model Repository are produced by the Oracle database, and their location is specific to your installation.

By default, SA uses a directory for each SID (in this case truth) for the Model Repository logs. (This could be different based on how Oracle was installed.)

/u01/app/oracle/admin/truth/bdump/alter_truth.log

Conditions to monitor:

Not all errors indicate a problem with the database. Some errors might be caused by an application.

In these examples, there is a problem if the command has output.

grep ORA- /u01/app/oracle/admin/truth/bdump/alter_truth.log

ORA-00600: internal error code, arguments: [729], [480], [space leak], [], [], [], [], []

ORA-07445: exception encountered: core dump [lxmcpen()+0] [SIGSEGV] [Address not mapped to object] ...

Tablespace usage

Tablespace usage should be monitored against a threshold, usually increasing in severity (for example., over 80% is a warning, over 90% is an error, over 95% is a critical error).

There are several ways to monitor tablespace usage. For a SQL query that you can run to check for sufficient free disk space in the tablespaces, see the SA 10.60 Install section. The SQL query provided in the Install section must be executed as a privileged database user.

Multimaster conflicts

The number of conflicting transactions in any Model Repository can be found by running the following SQL query as any SA database user.

select count(*) from transaction_conflicts where resolved = 'N';

Multimaster conflicts should be monitored in stages, with increasing numbers of conflicts resulting in increasing levels of escalation. The values used for the stages depend on patterns of use.

The SA administrator should record the number of conflicts for some period of time (perhaps a week) and use that information to determine the level of alert raised by the monitoring system.