4 Database Instance

4.1.1 Alert Log Error Trace File

This metric is the name of the trace file (if any) associated with the logged error. For all target versions, the collection frequency for this metric is every 15 minutes.

Data Source

$ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.

4.1.2 Alert Log Name

This metric is the name of the alert log file. For all target versions, the collection frequency for this metric is every 15 minutes

Data Source

$ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.

4.1.3 Archiver Hung Alert Log Error

This metric signifies that the archiver of the database being monitored has been temporarily suspended since the last sample time.

If the database is running in ARCHIVELOG mode, an alert is displayed when archiving is hung (ORA-00257) messages are written to the ALERT file. The ALERT file is a special trace file containing a chronological log of messages and errors.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

* Once an alert is triggered for this metric, it must be manually cleared.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Time/Line Number" object.

If warning or critical threshold values are currently set for any "Time/Line Number" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Time/Line Number" object, use the Edit Thresholds page.

Data Source

$ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.

User Action

Examine ALERT log and archiver trace file for additional information; however, the most likely cause of this message is that the destination device is out of space to store the redo log file. Verify the device specified in the initialization parameter ARCHIVE_LOG_DEST is set up properly for archiving. Note: This event does not automatically clear since there is no automatic way of determining when the problem has been resolved. Hence, you need to manually clear the event once the problem is fixed.

4.1.4 Data Block Corruption Alert Log Error

This metric signifies that the database being monitored has generated a corrupted block error to the ALERT file since the last sample time. The ALERT file is a special trace file containing a chronological log of messages and errors. An alert event is triggered when data block corrupted messages are written to the ALERT file.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

* Once an alert is triggered for this metric, it must be manually cleared.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Time/Line Number" object.

If warning or critical threshold values are currently set for any "Time/Line Number" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Time/Line Number" object, use the Edit Thresholds page.

Data Source

$ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.

User Action

Examine ALERT log for additional information. Note: This event does not automatically clear since there is no automatic way of determining when the problem has been resolved. Hence, you need to manually clear the event once the problem is fixed.

4.1.5 Generic Alert Log Error

This metric signifies that the database being monitored has generated errors to the ALERT log file since the last sample time. The ALERT log file is a special trace file containing a chronological log of messages and errors. An alert event is triggered when Oracle Exception (ORA-006xx) messages are written to the ALERT log file. A warning is displayed when other ORA messages are written to the ALERT log file.

Deadlock detected (ORA-00060), archiver hung (ORA-00257), and data block corrupted (ORA-01578) messages are sent out as separate metrics.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

* Once an alert is triggered for this metric, it must be manually cleared.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Time/Line Number" object.

If warning or critical threshold values are currently set for any "Time/Line Number" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Time/Line Number" object, use the Edit Thresholds page.

Data Source

$ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.

User Action

Examine ALERT log for additional information. Note: This event does not automatically clear since there is no automatic way of determining when the problem has been resolved. Hence, you need to manually clear the event once the problem is fixed.

4.1.6 Media Failure Alert Log Error

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

* Once an alert is triggered for this metric, it must be manually cleared.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Time/Line Number" object.

If warning or critical threshold values are currently set for any "Time/Line Number" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Time/Line Number" object, use the Edit Thresholds page.

4.1.7 Session Terminated Alert Log Error

This metric signifies that a session terminated unexpectedly since the last sample time. The ALERT file is a special trace file containing a chronological log of messages and errors. An alert is displayed when session unexpectedly terminated (ORA-00603) messages are written to the ALERT file.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

* Once an alert is triggered for this metric, it must be manually cleared.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Time/Line Number" object.

If warning or critical threshold values are currently set for any "Time/Line Number" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Time/Line Number" object, use the Edit Thresholds page.

Data Source

$ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.

User Action

Examine the ALERT log and the session trace file for additional information. Note: This event does not automatically clear since there is no automatic way of determining when the problem has been resolved. Hence, you need to manually clear the event once the problem is fixed.

4.2.1 Archiver Hung Alert Log Error Status

This metric reflects the number of Archiver Hung alert log errors witnessed the last time Enterprise Manager scanned the Alert Log.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

Alert Log metric

User Action

Examine the Alert Log.

4.2.2 Data Block Corruption Alert Log Error Status

This metric reflects the number of Data Block Corruption alert log errors witnessed the last time Enterprise Manager scanned the Alert Log.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

Alert Log metric

User Action

Examine the Alert Log.

4.2.3 Generic Alert Log Error Status

This metric reflects the number of Generic alert log errors witnessed the last time Enterprise Manager scanned the Alert Log.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

Alert Log metric

User Action

Examine the Alert Log.

4.2.4 Media Failure Alert Log Error Status

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

4.2.5 Session Terminated Alert Log Error Status

This metric reflects the number of Session Terminated alert log errors witnessed the last time Enterprise Manager scanned the Alert Log.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

Alert Log metric

User Action

Examine the Alert Log.

4.3.1 Archive Area Used (%)

The Archive Full (%) metric returns the percentage of space used on the archive area destination. If the space used is more than the threshold value given in the threshold arguments, then a warning or critical alert is generated.

If the database is not running in ARCHIVELOG mode or all archive destinations are standby databases for Oracle8i, this metric fails to register.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Archive Area Destination" object.

If warning or critical threshold values are currently set for any "Archive Area Destination" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Archive Area Destination" object, use the Edit Thresholds page.

Data Source

If no quota is set for archive area, the percentage is calculated using the UNIX df -k command.

If quota is set:

archive area used (%) = (total area used / total archive area) * 100

User Action

Verify the device specified in the initialization parameter LOG_ARCHIVE_DEST is set up properly for archiving.

• For Oracle8, verify that the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST initialization parameters are set up properly for archiving.

• For Oracle8i, there are two methods you can use to specify archive destinations. The first method is to use the LOG_ARCHIVE_DEST_n parameter (where n is an integer from 1 to 5) to specify from one to five different destinations for archival. Each numerically-suffixed parameter uniquely identifies an individual destination, for example, LOG_ARCHIVE_DEST_1, LOG_ARCHIVE_DEST_2, and so on. The second method, which allows you to specify a maximum of two locations, is to use the LOG_ARCHIVE_DEST parameter to specify a primary archive destination and the LOG_ARCHIVE_DUPLEX_DEST parameter to determine an optional secondary location.

If the LOG_ARCHIVE_DEST initialization parameter is set up correctly and this metric triggers, then free up more space in the destination specified by the archive destination parameters.

4.3.2 Archive Area Used (KB)

This metric represents the total space used (in KB) on the device containing the archive destination directory. For all target versions, the collection frequency for this metric is every 15 minutes

Data Source

If no quota is set for archive area, this is calculated through the UNIX df -k command.

total area used = quota_used * db_block_size (in KB)

User Action

Verify the device specified in the initialization parameter LOG_ARCHIVE_DEST is set up properly for archiving.

• For Oracle8, verify that the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST initialization parameters are set up properly for archiving.

• For Oracle8i, there are two methods you can use to specify archive destinations. The first method is to use the LOG_ARCHIVE_DEST_n parameter (where n is an integer from 1 to 5) to specify from one to five different destinations for archival. Each numerically-suffixed parameter uniquely identifies an individual destination, for example, LOG_ARCHIVE_DEST_1, LOG_ARCHIVE_DEST_2, and so on. The second method, which allows you to specify a maximum of two locations, is to use the LOG_ARCHIVE_DEST parameter to specify a primary archive destination and the LOG_ARCHIVE_DUPLEX_DEST parameter to determine an optional secondary location.

If the LOG_ARCHIVE_DEST initialization parameter is set up correctly and this metric triggers, then free up more space in the destination specified by the archive destination parameters.

4.3.3 Free Archive Area (KB)

When running a database in ARCHIVELOG mode, the archiving of the online redo log is enabled. Filled groups of the online redo log are archived, by default, to the destination specified by the LOG_ARCHIVE_DEST initialization parameter. If this destination device becomes full, the database operation is temporarily suspended until disk space is available.

If the database is running in ARCHIVELOG mode, this metric checks for available redo log destination devices.

If the database is not running in ARCHIVELOG mode, or all archive destinations are standby databases for Oracle8i, this metric fails to register.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Archive Area Destination" object.

If warning or critical threshold values are currently set for any "Archive Area Destination" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Archive Area Destination" object, use the Edit Thresholds page.

Data Source

If the database is in NOARCHIVELOG mode, then nothing is collected.

If the database is in ARCHIVELOG mode, log_archive_destination from v$parameter is queried to obtain the current list of archivelog destinations. The results are obtained by directly checking the disk usage (df -kl).

User Action

Verify the device specified in the initialization parameter LOG_ARCHIVE_DEST is set up properly for archiving.

• For Oracle8, verify that the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST initialization parameters are set up properly for archiving.

• For Oracle8i, there are two methods you can use to specify archive destinations. The first method is to use the LOG_ARCHIVE_DEST_n parameter (where n is an integer from 1 to 5) to specify from one to five different destinations for archival. Each numerically-suffixed parameter uniquely identifies an individual destination, for example, LOG_ARCHIVE_DEST_1, LOG_ARCHIVE_DEST_2, and so on. The second method, which allows you to specify a maximum of two locations, is to use the LOG_ARCHIVE_DEST parameter to specify a primary archive destination and the LOG_ARCHIVE_DUPLEX_DEST parameter to determine an optional secondary location.

If the LOG_ARCHIVE_DEST initialization parameter is set up correctly and this metric triggers, then free up more space in the destination specified by the archive destination parameters.

4.3.4 Total Archive Area (KB)

This metric represents the total space (in KB) on the device containing the archive destination directory. For all target versions, the collection frequency for this metric is every 15 minutes

Data Source

If no quota is set for archive area, this is calculated through the UNIX df -k command.

If quota is set:

total archive area = quota_size * db_block_size (in KB)

User Action

Oracle recommends that multiple archivelog destinations across different disks be configured. When at least one archivelog destination gets full, Oracle recommends the following:

• If tape is being used, back up archivelogs to tape and delete the archivelogs.

• If tape is not being used, back up the database and remove obsolete files. This also removes archivelogs that are no longer needed based on the database retention policy.

• If archivelog destination quota_size is being used, raise the quota_size.

4.4.1 SQL Response Time (%)

SQL response time (%). For all target versions, the collection frequency for this metric is every 15 minutes

4.5.1 Data Guard Status

The Data Guard Status metric checks the status of each database in the broker configuration and triggers a warning or critical alert if necessary.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Name" object.

If warning or critical threshold values are currently set for any "Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Name" object, use the Edit Thresholds page.

4.5.2 Data Not Applied (logs)

The broker computes the highest applied SCN and uses its value to find the last continuous log that was successfully archived to the standby database. Redo data in all subsequent log files are counted as logs not applied. If the primary database goes down at this point, the redo data from these log files can be applied on the standby database. If there is a gap in the log files received on the standby database, any log files received after the gap cannot be applied.

For example, if log files 1, 2, 3, 6, 7, and 9 are received on the standby database and log apply services is currently applying log 1, log apply services can continue to apply up to log 3. Log apply services cannot apply any more log files because log 4 is missing. Even though log files 6, 7, and 9 are received, they cannot be applied and they will not be counted as data not applied.

If all the archived log files on the standby database are continuous, and standby redo logs are used, the standby redo logs are also counted as data not applied, unless real-time apply is turned on and log apply services is already working on the standby redo log files.

If the standby redo logs are multithreaded, the broker computes the highest applied SCN for every thread and totals the numbers. If there are multiple incarnations and the standby database is in a different incarnation from the primary database, each incarnation is computed separately and the results are then totaled.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Name" object.

If warning or critical threshold values are currently set for any "Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Name" object, use the Edit Thresholds page.

4.5.3 Data Not Applied (MB)

The broker computes the highest applied SCN and uses its value to find the last continuous log that was archived to the standby database. The size of redo data in all subsequent log files are counted as data not applied. If the primary database goes down at this point, redo from these log files can be applied on the standby database. If there is a gap in the log files received on the standby database, any log files received after the gap cannot be applied.

For example, if log files 1, 2, 3, 6, 7, and 9 are received on the standby database and log apply services is currently applying log 1, log apply services can continue to apply up to log 3. Log apply services cannot apply any more log files because log 4 is missing. Even though log files 6, 7, and 9 are received, they cannot be applied and they will not be counted as data not applied. In this case, the total size of log files 1, 2, and 3 is the size of Data Not Applied.

If all the archived log files on the standby database are continuous, and standby redo log files are used, the standby redo log files are also counted as data not applied, unless real-time apply is turned on and log apply services is already working on the standby redo log files. The size of an archived log file is its file size. However, the size of a standby redo log is the size of the actual redo in the log and not the file size.

If the standby redo log files are multithreaded, the broker computes the highest applied SCN for every thread and totals the numbers. If there are multiple incarnations and the standby database is in a different incarnation from the primary database, each incarnation is computed separately and the results are then totaled.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Name" object.

If warning or critical threshold values are currently set for any "Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Name" object, use the Edit Thresholds page.

4.5.4 Data Not Received (logs)

The broker computes the highest applied SCN and uses its value to find the last continuous log file that was successfully archived to the standby database. Redo data in all subsequent log files, including the current online redo log file, are counted as log files for potential data loss and will be unrecoverable if the primary database goes down at this point.

For example, if log files 1, 2, 3, 6, 7, and 9 are received on the standby database, and if log 10 is the current online log file, and if log apply services are currently applying log 1, the last continuous log after the highest applied SCN is log 3. All log files after log 3, that is log files 4 through 10, are counted as data not received. If the primary database goes down at this point, all redo data in log files 4 through 10 are lost on the standby database.

If the primary database is multithreaded (in a RAC database), the broker computes the highest applied SCN for every thread and totals the numbers. If the primary database has multiple incarnations (for example, due to a flashback operation) and the standby database is in a different incarnation from the primary database, the computation is done on each incarnation and the results are then totaled.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Name" object.

If warning or critical threshold values are currently set for any "Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Name" object, use the Edit Thresholds page.

4.5.5 Data Not Received (MB)

The broker computes the highest applied SCN and uses its value to find the last continuous log file that was successfully archived to the standby database. The size of redo data in all subsequent log files, including the current online redo log file, are counted as data for potential data loss and will be unrecoverable if the primary database goes down at this point. The size of an archived log file is its file size, and the size of the online redo log file is the size of the actual redo in the online log file, not the file size of the online redo log file.

For example, if log files 1, 2, 3, 6, 7, and 9 are received on the standby database, and if log 10 is the current online log file, and if log apply services is currently applying log 1, the last continuous log after the highest applied SCN is log 3. All log files after log 3, that is log files 4 through 10, are counted as data not received and the total size of redo data in these log files is the size of Data Not Received.

If the primary database is multithreaded (in a RAC database), the broker computes the highest applied SCN for every thread and totals the numbers. If the primary database has multiple incarnations (for example, due to a flashback operation) and the standby database is in a different incarnation from the primary database, the computation is done on each incarnation and the results are then totaled.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Name" object.

If warning or critical threshold values are currently set for any "Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Name" object, use the Edit Thresholds page.

4.6.1 Data Guard Status

Checks the status of each database in the broker configuration.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Name" object.

If warning or critical threshold values are currently set for any "Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Name" object, use the Edit Thresholds page.

4.6.2 Data Not Applied (logs)

The broker computes the highest applied SCN and uses its value to find the last continuous log that was successfully archived to the standby database. Redo data in all subsequent log files are counted as logs not applied. If the primary database goes down at this point, the redo data from these log files can be applied on the standby database. If there is a gap in the log files received on the standby database, any log files received after the gap cannot be applied.

For example, if log files 1, 2, 3, 6, 7, and 9 are received on the standby database and log apply services is currently applying log 1, log apply services can continue to apply up to log 3. Log apply services cannot apply any more log files because log 4 is missing. Even though log files 6, 7, and 9 are received, they cannot be applied and they will not be counted as data not applied.

If all the archived log files on the standby database are continuous, and standby redo logs are used, the standby redo logs are also counted as data not applied, unless real-time apply is turned on and log apply services is already working on the standby redo log files.

If the standby redo logs are multithreaded, the broker computes the highest applied SCN for every thread and totals the numbers. If there are multiple incarnations and the standby database is in a different incarnation from the primary database, each incarnation is computed separately and the results are then totaled.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Name" object.

If warning or critical threshold values are currently set for any "Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Name" object, use the Edit Thresholds page.

4.6.3 Data Not Received (logs)

The broker computes the highest applied SCN and uses its value to find the last continuous log file that was successfully archived to the standby database. Redo data in all subsequent log files, including the current online redo log file, are counted as log files for potential data loss and will be unrecoverable if the primary database goes down at this point.

For example, if log files 1, 2, 3, 6, 7, and 9 are received on the standby database, and if log 10 is the current online log file, and if log apply services are currently applying log 1, the last continuous log after the highest applied SCN is log 3. All log files after log 3, that is log files 4 through 10, are counted as data not received. If the primary database goes down at this point, all redo data in log files 4 through 10 are lost on the standby database.

If the primary database is multithreaded (in a RAC database), the broker computes the highest applied SCN for every thread and totals the numbers. If the primary database has multiple incarnations (for example, due to a flashback operation) and the standby database is in a different incarnation from the primary database, the computation is done on each incarnation and the results are then totaled.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Name" object.

If warning or critical threshold values are currently set for any "Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Name" object, use the Edit Thresholds page.

4.7.1 Fast-Start Failover Occurred

When Fast-Start Failover (FSFO) is enabled, this metric will generate a critical alert on the new primary database (old standby) if an FSFO occurs. The FSFO SCN must be initialized to a value before the metric will alert. This usually takes one collection interval. Once an FSFO occurs and the new primary is ready, the FSFO alert fires. It then clears after one collection interval. A critical alert is configured by default.

Both primary and standby must be configured with sysdba monitoring access.

Shows the time when a fast-start failover occurred.

The value is 0 if FSFO has not occurred, 1 if FSFO has occurred.

4.7.2 Fast-Start Failover SCN

When Fast-Start Failover (FSFO) is enabled, this metric will generate a critical alert on the new primary database (old standby) if an FSFO occurs. The FSFO SCN must be initialized to a value before the metric will alert. This usually takes one collection interval. Once an FSFO occurs and the new primary is ready, the FSFO alert fires. It then clears after one collection interval. A critical alert is configured by default.

Both primary and standby must be configured with sysdba monitoring access.

Any value indicates the metric is ready to trigger.

4.7.3 Fast-Start Failover Time

When Fast-Start Failover (FSFO) is enabled, this metric will generate a critical alert on the new primary database (old standby) if an FSFO occurs. The FSFO SCN must be initialized to a value before the metric will alert. This usually takes one collection interval. Once an FSFO occurs and the new primary is ready, the FSFO alert fires. It then clears after one collection interval. A critical alert is configured by default.

Both primary and standby must be configured with sysdba monitoring access.

A time stamp appears if FSFO occurred.

4.8.1 Apply Lag (seconds)

Displays (in seconds) how far the standby is behind the primary.

Data Source

v$dataguard_stats('apply lag')

4.8.2 Estimated Failover Time (seconds)

The approximate number of seconds it would require to failover to this standby database. This accounts for the startup time (if necessary) plus the remaining time it would require to apply all the available redo on the standby. If a bounce is not required, it is only the remaining apply time.

Data Source

v$dataguard_stats ('estimated startup time','apply finish time','standby has been open')

4.8.3 Redo Apply Rate (KB/second)

Displays the Redo Apply Rate in KB/second on this standby.

4.8.4 Transport Lag (seconds)

The approximate number of seconds of redo not yet available on this standby database. This may be because the redo has not yet been shipped or there may be a gap.

Data Source

v$dataguard_stats('transport lag')

4.9.1 Data Guard Status

Use the Data Guard Status metric to check the status of each database in the Data Guard configuration.

By default, a critical and warning threshold value was set for this metric column. Alerts will be generated when threshold values are reached. You can edit the value for a threshold as required.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Name" object.

If warning or critical threshold values are currently set for any "Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Name" object, use the Edit Thresholds page.

User Action

Perform the following steps:

1. Check the Edit Properties General page for the primary and standby databases for detailed information.

2. Examine the database alert logs and the Data Guard broker logs for additional information.

4.10.1 Average File Read Time (centi-seconds)

This metric represents the average file read time, measured in hundredths of a second.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "File Name" object.

If warning or critical threshold values are currently set for any "File Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "File Name" object, use the Edit Thresholds page.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.10.2 Average File Write Time (centi-seconds)

This metric represents the average file write time, measured in hundredths of a second.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "File Name" object.

If warning or critical threshold values are currently set for any "File Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "File Name" object, use the Edit Thresholds page.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.11.1 Broken Job Count

The Oracle Server job queue is a database table that stores information about local jobs such as the PL/SQL call to execute for a job such as when to run a job. Database replication is also managed by using the Oracle job queue mechanism using jobs to push deferred transactions to remote master sites, to purge applied transactions from the deferred transaction queue or to refresh snapshot refresh groups.

A job can be broken in two ways:

Oracle has failed to successfully execute the job after sixteen attempts. The job has been explicitly marked as broken by using the procedure DBMS_ JOB.BROKEN.

This metric checks for broken DBMS jobs. A critical alert is generated if the number of broken jobs exceeds the value specified by the threshold argument.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

SELECT COUNT(*)
  FROM dba_jobs
  WHERE broken [less] [greater] 'N'

User Action

Check the ALERT log and trace files for error information. Correct the problem that is preventing the job from running. Force immediate re-execution of the job by calling DBMS_JOB.RUN.

4.11.2 Failed Job Count

The Oracle Server job queue is a database table that stores information about local jobs such as the PL/SQL call to execute for a job such as when to run a job. Database replication is also managed by using the Oracle job queue mechanism using jobs to push deferred transactions to remote master sites, to purge applied transactions from the deferred transaction queue or to refresh snapshot refresh groups.

If a job returns an error while Oracle is attempting to execute it, the job fails. Oracle repeatedly tries to execute the job doubling the interval of each attempt. If the job fails sixteen times, Oracle automatically marks the job as broken and no longer tries to execute it.

This metric checks for failed DBMS jobs. An alert is generated if the number of failed job exceeds the value specified by the threshold argument.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

SELECT COUNT(*) 
  FROM dba_jobs 
  WHERE NVL(failures, 0) [less] [greater] 0

User Action

Check the ALERT log and trace files for error information. Correct the problem that is preventing the job from running.

4.12.1 Current Logons Count

This metric represents the current number of logons.

Note: Unlike most metrics, which accept thresholds as real numbers, this metric can only accept an integer as a threshold.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

logons current

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.12.2 Current Open Cursors Count

This metric represents the current number of opened cursors.

Note: Unlike most metrics, which accept thresholds as real numbers, this metric can only accept an integer as a threshold.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

opened cursors current

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.12.3 Lock Limit Usage (%)

The DML_LOCKS initialization parameter specifies the maximum number of DML locks. The purpose of DML locks is to guarantee the integrity of data being accessed concurrently by multiple users. DML locks prevent destructive interference of simultaneous conflicting DML and/or DDL operations.

This metric checks for the utilization of the lock resource against the values (percentage) specified by the threshold arguments. If the percentage of all active DML locks to the limit set in the DML_LOCKS initialization parameter exceeds the values specified in the threshold arguments, then a warning or critical alert is generated.

If DML_LOCKS is 0, this test fails to register. A value of 0 indicates that enqueues are disabled.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

SELECT resource_name name, 
  100*DECODE(initial_allocation, ' UNLIMITED', 0, current_utilization / 
  initial_allocation) usage 
FROM v$resource_limit 
WHERE LTRIM(limit_value) 
  != '0' AND LTRIM(initial_allocation) != '0' AND resource_name = 'dml_locks'

User Action

Increase the DML_LOCKS instance parameter by 10%.

4.12.4 Process Limit Usage (%)

The PROCESSES initialization parameter specifies the maximum number of operating system user processes that can simultaneously connect to a database at the same time. This number also includes background processes utilized by the instance.

This metric checks for the utilization of the process resource against the values (percentage) specified by the threshold arguments. If the percentage of all current processes to the limit set in the PROCESSES initialization parameter exceeds the values specified in the threshold arguments, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

SELECT resource_name name, 
  100*DECODE(initial_allocation, ' UNLIMITED', 0, current_utilization) != '0' 
  AND resource_name = 'processes'

User Action

Verify that the current PROCESSES instance parameter setting has not exceeded the operating system-dependent maximum. Increase the number of processes to be at least 6 + the maximum number of concurrent users expected to log in to the instance.

4.12.5 Session Limit Usage (%)

The SESSIONS initialization parameter specifies the maximum number of concurrent connections that the database will allow.

This metric checks for the utilization of the session resource against the values (percentage) specified by the threshold arguments. If the percentage of the number of sessions, including background processes, to the limit set in the SESSIONS initialization parameter exceeds the values specified in the threshold arguments, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

SELECT resource_name name, 
  100*DECODE(initial_allocation, ' UNLIMITED', 0, current_utilization) != '0' 
  AND resource_name = 'sessions' 

User Action

Increase the SESSIONS instance parameter. For XA environments, confirm that SESSIONS is at least 2.73 * PROCESSES. For shared server environments, confirm that SESSIONS is at least 1.1 * maximum number of connections.

4.12.6 User Limit Usage (%)

The LICENSE_MAX_SESSIONS initialization parameter specifies the maximum number of concurrent user sessions allowed simultaneously.

This metric checks whether the number of users logged on is reaching the license limit. If the percentage of the number of concurrent user sessions to the limit set in the LICENSE_MAX_SESSIONS initialization parameter exceeds the values specified in the threshold arguments, then a warning or critical alert is generated. If LICENSE_MAX_SESSIONS is not explicitly set to a value, the test does not trigger.

Note: This metric is most useful when session licensing is enabled. Refer to the Oracle Server Reference Manual for more information on LICENSE_MAX_SESSIONS and LICENSE_MAX_USERS.

Note: Unlike most metrics, which accept thresholds as real numbers, this metric can only accept an integer as a threshold.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

SELECT 'user' name, 
  100*DECODE(session_max, 0, 0, sessions_current/session_max) usage 
  FROM v$license 

User Action

This typically indicates that the license limit for the database has been reached. The user will need to acquire additional licenses, then increase LICENSE_MAX_ SESSIONS to reflect the new value.

4.13.1 Service CPU Time (per user call) (microseconds)

This metric represents the average CPU time, in microseconds, for calls to a particular database service.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Service Name" object.

If warning or critical threshold values are currently set for any "Service Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Service Name" object, use the Edit Thresholds page.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.13.2 Service Response Time (per user call) (microseconds)

This metric represents the average elapsed time, in microseconds, for calls to a particular database service.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Service Name" object.

If warning or critical threshold values are currently set for any "Service Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Service Name" object, use the Edit Thresholds page.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.14.1 Deferred Transaction Count

Oracle uses deferred transactions to propagate data-level changes asynchronously among master sites in an advanced replication system as well as from an updatable snapshot to its master table.

This metric checks for the number of deferred transactions. An alert is generated if the number of deferred transactions exceeds the value specified by the threshold argument.

Data Source

SELECT count(*) FROM sys.deftran 

User Action

When the advanced replication facility pushes a deferred transaction to a remote site, it uses a distributed transaction to ensure that the transaction has been properly committed at the remote site before the transaction is removed for the queue at the local site. If transactions are not being pushed to a given remote site, verify that the destination for the transaction was correctly specified. If you specify a destination database when calling DBMS_DEFER_SYS.SCHEDULE_EXECUTION using the DBLINK parameter or DBMS_DEFER_SYS.EXECUTE using the DESTINATION parameter, make sure the full database link is provided.

Wrong view destinations can lead to erroneous deferred transaction behavior. Verify the DEFCALLEST and DEFTRANDEST views are the definitions from the CATREPC.SQL not the ones from CATDEFER.SQL.

4.14.2 Deferred Transaction Error Count

Oracle uses deferred transactions to propagate data-level changes asynchronously among master sites in an advanced replication system as well as from an updatable snapshot to its master table. If a transaction is not successfully propagated to the remote site, Oracle rolls back the transaction, logs the transaction in the SYS.DEFERROR view in the remote destination database.

This metric checks for the number of transactions in SYS.DEFERROR view and raises an alert if it exceeds the value specified by the threshold argument.

Data Source

SELECT count(*) FROM sys.deferror 

User Action

An error in applying a deferred transaction may be the result of a database problem, such as a lack of available space in the table is to be updated or may be the result of an unresolved insert, update or delete conflict. The SYS.DEFERROR view provides the ID of the transaction that could not be applied. Use this ID to locate the queued calls associated with the transaction. These calls are stored in the SYS.DEFCALL view. You can use the procedures in the DBMS_DEFER_QUERY package to determine the arguments to the procedures listed in the SYS.DEFCALL view.

4.15.1 Dump Area Directory

This metric is the directory represented by this metric index's dump destination.

Each server and background process can write to an associated trace file to log messages and errors.

Background processes and the ALERT file are written to the destination specified by BACKGROUND_DUMP_DEST. Trace files for server processes are written to the destination specified by USER_ DUMP_DEST.

For all target versions, the collection frequency for this metric is every 15 minutes.

Data Source

data from v$parameter

User Action

Verify the device specified in the initialization parameters BACKGROUND_DUMP_DEST and USER_DUMP_DEST are set up properly for archiving.

If the BACKGROUND_DUMP_DEST and USER_DUMP_DEST initialization parameters are set up correctly and this metric triggers, then free up more space in the destination specified by the dump destination parameters.

4.15.2 Dump Area Used (%)

This metric returns the percentage of used space of the dump area destinations.

If the space used is more than the threshold value given in the threshold arguments, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Type of Dump Area" object.

If warning or critical threshold values are currently set for any "Type of Dump Area" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Type of Dump Area" object, use the Edit Thresholds page.

Data Source

Calculated using the UNIX df -k command.

• Critical threshold: Percentage of free space threshold for critical alert.

• Warning threshold: Percentage of free space threshold for warning alert.

User Action

Verify the device specified in the initialization parameters BACKGROUND_DUMP_DEST and USER_DUMP_DEST are set up properly for archiving.

If the BACKGROUND_DUMP_DEST and USER_DUMP_DEST initialization parameters are set up correctly and this metric triggers, then free up more space in the destination specified by the dump destination parameters.

4.15.3 Dump Area Used (KB)

This metric represents the total space used (in KB) on the device containing the dump destination directory.

Metric Summary

The following table shows how often the metric's value is collected.

Data Source

Calculated using the UNIX df -k command.

User Action

Verify the device specified in the initialization parameters BACKGROUND_DUMP_DEST and USER_DUMP_DEST are set up properly for archiving.

If the BACKGROUND_DUMP_DEST and USER_DUMP_DEST initialization parameters are set up correctly and this metric triggers, then free up more space in the destination specified by the dump destination parameters.

4.15.4 Free Dump Area (KB)

Each server and background process can write to an associated trace file in order to log messages and errors. Background processes and the ALERT file are written to the destination specified by BACKGROUND_DUMP_DEST.

Trace files for server processes are written to the destination specified by USER_DUMP_DEST.

This metric checks for available free space on these dump destination devices. If the space available is less than the threshold value given in the threshold arguments, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Type of Dump Area" object.

If warning or critical threshold values are currently set for any "Type of Dump Area" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Type of Dump Area" object, use the Edit Thresholds page.

Data Source

Calculated using the UNIX df -k command.

User Action

Verify the device specified in the initialization parameters BACKGROUND_DUMP_DEST and USER_DUMP_DEST are set up properly for archiving.

If the BACKGROUND_DUMP_DEST and USER_DUMP_DEST initialization parameters are set up correctly and this metric triggers, then free up more space in the destination specified by the dump destination parameters.

4.15.5 Total Dump Area (KB)

This metric represents the total space (in KB) available on the device containing the dump destination directory.

Metric Summary

The following table shows how often the metric's value is collected.

Data Source

Calculated using the UNIX df -k command.

User Action

Verify the device specified in the initialization parameters BACKGROUND_DUMP_DEST and USER_DUMP_DEST are set up properly for archiving.

If the BACKGROUND_DUMP_DEST and USER_DUMP_DEST initialization parameters are set up correctly and this metric triggers, then free up more space in the destination specified by the dump destination parameters.

4.16.1 Buffer Cache Hit (%)

This metric represents the data block buffer cache efficiency, as measured by the percentage of times the data block requested by the query is in memory.

Effective use of the buffer cache can greatly reduce the I/O load on the database. If the buffer cache is too small, frequently accessed data will be flushed from the buffer cache too quickly which forces the information to be re-fetched from disk. Since disk access is much slower than memory access, application performance will suffer. In addition, the extra burden imposed on the I/O subsystem could introduce a bottleneck at one or more devices that would further degrade performance.

This test checks the percentage of buffer requests that were already in buffer cache. If the value is less than or equal to the threshold values specified by the threshold arguments, and the number of occurrences exceeds the value specified in the "Number of Occurrences" parameter, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

((DeltaLogicalGets - (DeltaPhysicalReads - DeltaPhysicalReadsDirect)) / DeltaLogicalGets) * 100 where:

• DeltaLogicalGets: difference in 'select value from v$sysstat where name='session logical reads'' between sample end and start

• DeltaPhysicalReads: difference in 'select value from v$sysstat where name='physical reads'' between sample end and start

• DeltaPhysicalReadsDirect: difference in 'select value from v$sysstat where name='physical reads direct'' between sample end and start (Oracle8i)

User Action

A low buffer cache hit ratio means that the server must often go to disk to retrieve the buffers required to satisfy a query. The queries that perform the most physical reads lower the numerical value of this statistic. Typically queries that perform full table scans force large amounts of buffers into the cache, aging out other buffers that may be required by other queries later. The Top Sessions page sorted by Physical Reads will show the sessions performing the most reads and through further drilldown their associated queries can be identified. Similarly, the Top SQL page sorted by Physical Reads shows which SQL statements are performing the most physical reads. The statements performing the most I/O should be looked at for tuning.

The difference between the two is that the Top Sessions chart shows the sessions that are responsible for the physical reads at any given moment. The Top SQL view shows all SQL that is still in the cache. The top statement may not be executing currently, and thus not responsible for the current poor buffer cache hit ratio.

If the queries seem to be well tuned, the size of the buffer cache also determines how often buffers need to be fetched from disk. The DB_BLOCK_BUFFERS initialization parameter determines the number of database buffers available in the buffer cache. It is one of the primary parameters that contribute to the total memory requirements of the SGA on the instance. The DB_BLOCK_BUFFERS parameter, together with the DB_BLOCK_SIZE parameter, controls the total size of the buffer cache. Since DB_BLOCK_SIZE can only be specified when the database is first created, normally the size of the buffer cache size is controlled using the DB_BLOCK_BUFFERS parameter.

Consider increasing the DB_BLOCK_BUFFERS initialization parameter to increase the size of the buffer cache. This increase allows the Oracle Server to keep more information in memory, thus reducing the number of I/O operations required to do an equivalent amount of work using the current cache size.

4.16.2 CPU Usage (per second)

This metric represents the CPU usage per second by the database processes, measured in hundredths of a second. A change in the metric value may occur because of a change in either workload mix or workload throughput being performed by the database. Although there is no �correct� value for this metric, it can be used to detect a change in the operation of a system. For example, an increase in Database CPU usage from 500 to 750 indicates that the database is using 50% more CPU. ('No correct value' means that there is no single value that can be applied to any database. The value is a characteristic of the system and the applications running on the system.)

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. ADDM can help to identify database operations that are consuming CPU. ADDM reports are available from a number of locations including the Database Home page and Advisor Central.

4.16.3 CPU Usage (per transaction)

This metric represents the average CPU usage per transaction expressed as a number of seconds of CPU time. A change in this metric can occur either because of changing workload on the system, such as the addition of a new module, or because of a change in the way that the workload is performed in the database, such as changes in the plan for a SQL statement. The threshold for this metric should be set based on the actual values observed on your system.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. ADDM will provide information about which operations are using the CPU resources.

4.16.4 Cursor Cache Hit (%)

This metric represents the percentage of soft parses satisfied within the session cursor cache.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

session cursor cache hits / (parse count (total) - parse count (hard))

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.16.5 Data Dictionary Hit (%)

This metric represents dictionary cache efficiency as measured by the percentage of requests against the dictionary data that were already in memory. It is important to determine whether the misses on the data dictionary are actually affecting the performance of the Oracle Server. The shared pool is an area in the SGA that contains the library cache of shared SQL requests, the dictionary cache, and the other cache structures that are specific to a particular instance configuration.

Misses on the data dictionary cache are to be expected in some cases. Upon instance startup, the data dictionary cache contains no data, so any SQL statement issued is likely to result in cache misses. As more data is read into the cache, the likelihood of cache misses should decrease. Eventually the database should reach a steady state in which the most frequently used dictionary data is in the cache. At this point, very few cache misses should occur. To tune the cache, examine its activity only after your application has been running.

This test checks the percentage of requests against the data dictionary that were found in the Shared Pool. If the value is less than or equal to the threshold values specified by the threshold arguments, and the number of occurrences exceeds the value specified in the "Number of Occurrences" parameter, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

(Gets/Misses) * 100 where:

• Misses: select sum(getmisses) from v$rowcache

• Gets: select sum(gets) from v$rowcache

User Action

If the percentage of gets is below %90 to %85, consider increasing SHARED_POOL_SIZE to decrease the frequency in which dictionary data is being flushed from the shared pool to make room for new data. To increase the memory available to the cache, increase the value of the initialization parameter SHARED_POOL_SIZE.

4.16.6 Database CPU Time (%)

This metric represents the percentage of database call time that is spent on the CPU. Although there is no �correct� value for this metric, it can be used to detect a change in the operation of a system, for example, a drop in Database CPU time from 50% to 25%. ('No correct value' means that there is no single value that can be applied to any database. The value is a characteristic of the system and the applications running on the system.)

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

User Action

Investigate the change is CPU usage by using Automatic Database Diagnostic Monitor (ADDM). ADDM reports are available from a number of locations including the Database Home page and Advisor Central. Examine the report for increased time spent in wait events.

4.16.7 Library Cache Hit (%)

This metric represents the library cache efficiency, as measured by the percentage of times the fully parsed or compiled representation of PL/SQL blocks and SQL statements are already in memory.

The shared pool is an area in the SGA that contains the library cache of shared SQL requests, the dictionary cache and the other cache structures that are specific to a particular instance configuration.

The shared pool mechanism can greatly reduce system resource consumption in at least three ways: Parse time is avoided if the SQL statement is already in the shared pool.

Application memory overhead is reduced, since all applications use the same pool of shared SQL statements and dictionary resources.

I/O resources are saved, since dictionary elements that are in the shared pool do not require access.

If the shared pool is too small, users will consume additional resources to complete a database operation. For library cache access, the overhead is primarily the additional CPU resources required to re-parse the SQL statement.

This test checks the percentage of parse requests where cursor already in cache If the value is less than or equal to the threshold values specified by the threshold arguments, and the number of occurrences exceeds the value specified in the "Number of Occurrences" parameter, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

(DeltaPinHits / DeltaPins) * 100 where:

• DeltaPinHits: difference in 'select sum(pinhits) from v$librarycache' between sample end and start

• DeltaPins: difference in 'select sum(pins) from v$librarycache' between sample end and start

User Action

The Top Sessions page sorted by Hard Parses lists the sessions incurring the most hard parses. Hard parses occur when the server parses a query and cannot find an exact match for the query in the library cache. You can avoid hard parses by sharing SQL statements efficiently. The use of bind variables instead of literals in queries is one method to increase sharing.

By showing you which sessions are incurring the most hard parses, this page can identify the application or programs that are the best candidates for SQL rewrites.

Also, examine SQL statements that can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.

The SHARED_POOL_SIZE initialization parameter controls the total size of the shared pool. Consider increasing the SHARED_POOL_SIZE to decrease the frequency in which SQL requests are being flushed from the shared pool to make room for new requests.

To take advantage of the additional memory available for shared SQL areas, you may also need to increase the number of cursors permitted per session. You can increase this limit by increasing the value of the initialization parameter OPEN_CURSORS.

4.16.8 Library Cache Miss (%)

This metric represents the percentage of parse requests where the cursor is not in the cache.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

1 - pinhits / pins 

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.16.9 Parallel Execution Downgraded (per second)

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

4.16.10 Parallel Execution Downgraded 25% or more (per second)

Number of times per second parallel execution was requested and the degree of parallelism was reduced to 25% and more because of insufficient parallel execution servers.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

(parallel operations downgraded 25 to 50 percent 
+ parallel operations downgraded 50 to 75 percent 
+ parallel operations downgraded 75 to 99 percent) 
/ time

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.16.11 Parallel Execution Downgraded 50% or more (per second)

Number of times per second parallel execution was requested and the degree of parallelism was reduced to 50% and more because of insufficient parallel execution servers.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

(+ parallel operations downgraded 50 to 75 percent 
+ parallel operations downgraded 75 to 99 percent) 
/ time 

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.16.12 Parallel Execution Downgraded 75% or more (per second)

Number of times per second parallel execution was requested and the degree of parallelism was reduced to 75% or more because of insufficient parallel execution servers.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

(parallel operations downgraded 75 to 99 percent) / time 

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.16.13 Parallel Execution Downgraded to Serial (per second)

Number of times per second parallel execution was requested but execution was serial because of insufficient parallel execution servers.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

parallel operations downgraded to serial / time

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.16.14 Parallel Execution Downgraded to Serial (per transaction)

Number of times per transaction parallel execution was requested but execution was serial because of insufficient parallel execution servers.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

parallel operations downgraded to serial / transactions

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.16.15 PGA Cache Hit (%)

This metric represents the total number of bytes processed in the PGA versus the total number of bytes processed plus extra bytes read/written in extra passes.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.16.16 Redo Log Allocation Hit (%)

Redo log entries contain a record of changes that have been made to the database block buffers. The log writer (LGWR) process writes redo log entries from the log buffer to a redo log file. The log buffer should be sized so that space is available in the log buffer for new entries, even when access to the redo log is heavy. When the log buffer is undersized, user process will be delayed as they wait for the LGWR to free space in the redo log buffer.

The redo log buffer efficiency, as measured by the hit ratio, records the percentage of times users did not have to wait for the log writer to free space in the redo log buffer.

This metric monitors the redo log buffer hit ratio (percentage of success) against the values specified by the threshold arguments. If the number of occurrences is smaller than the values specified, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

100 * (redo_entries_delta - redo_space_requests_delta) 
/redo_entries_delta 
where: 

• redo_enties_delta = difference between "SELECT value FROM v$sysstat WHERE name = 'redo entries'" at the beginning and ending of the interval

• redo_space_requests_delta = difference between "SELECT value FROM v$sysstat WHERE name = 'redo log space requests'" at the beginning and ending of the interval

User Action

The LOG_BUFFER initialization parameter determines the amount of memory that is used when buffering redo entries to the redo log file.

Consider increasing the LOG_BUFFER initialization parameter in order to increase the size of the redo log buffer. Redo log entries contain a record of the changes that have been made to the database block buffers. The log writer process (LGWR) writes redo log entries from the log buffer to a redo log. The redo log buffer should be sized so space is available in the log buffer for new entries, even when access to the redo log is heavy.

Note: For Oracle Management Agent release 9i, this metric has been obsoleted. It is recommended that you use the Redo NoWait Ratio metric. This metric is kept for backward compatibility with older versions of the Management Agent.

4.16.17 Response Time (per transaction)

This metric represents the time spent in database operations per transaction. It is derived from the total time that user calls spend in the database (DB time) and the number of commits and rollbacks performed. A change in this value indicates that either the workload has changed or that the database�s ability to process the workload has changed because of either resource constraints or contention.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page. Changes in the response time per transaction will appear as increased time spent in the database, either on CPU or in wait events and ADDM will report the sources of contention for both hardware and software resources.

4.16.18 Row Cache Miss Ratio (%)

This metric represents the percentage of row cache miss ratio.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.16.19 Sorts in Memory (%)

This metric represents the sort efficiency as measured by the percentage of times sorts were performed in memory as opposed to going to disk.

For best performance, most sorts should occur in memory because sorts to disks are less efficient. If the sort area is too small, extra sort runs will be required during the sort operation. This increases CPU and I/O resource consumption.

This test checks the percentage of sorts performed in memory rather than to disk. If the value is less than or equal to the threshold values specified by the threshold arguments, and the number of occurrences exceeds the value specified in the "Number of Occurrences" parameter, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

(DeltaMemorySorts / (DeltaDiskSorts + DeltaMemorySorts)) * 100 where:

• DeltaMemorySorts: difference in 'select value from v$sysstat where name='sorts (memory)'' between sample end and start

• DeltaDiskSorts: difference in 'select value from v$sysstat where name='sorts (disk)'' between sample end and start

User Action

The sessions that are performing the most sorts should be identified such that the SQL they are executing can be further identified. The sort area sizes for the database may be sized correctly, and the application SQL may be performing unwanted or excessive sorts. The sessions performing the most sorts are available through the Top Sessions page sorted by Disk Sorts.

Further drilldown into the session performing the most disk sorts with the Current SQL page shows you the SQL statement responsible for the disk sorts.

The Top SQL page sorted by Sorts provides a mechanism to quickly display the SQL statements in the cache, presented in sorted order by their number sort operations. This is an alternative to viewing a sort of current sessions. It allows you to view sort activity via SQL statements and contains cumulative statistics for all executions of that statement.

If excessive sorts are taking place on disk and the queries are correct, consider increasing the SORT_AREA_SIZE initialization parameter to increase the size of the sort area. A larger sort area allows the Oracle Server to maintain sorts in memory, reducing the number of I/O operations required to do an equivalent amount of work using the current sort area size.

4.17.1 Failed Login Count

This metric checks for the number of failed logins on the target database. This check is performed every ten minutes and returns the number of failed logins for that ten-minute interval. This metric will only work for databases where the audit_trail initialization parameter is set to DB or XML and the session is being audited.

If the failed login count crosses the values specified in the threshold arguments, then a warning or critical alert is generated. Since it is important to know every time a significant number of failed logins occurs on a system, this metric will fire a new alert for any ten-minute interval where the thresholds are crossed. The user can manually clear these alerts, they will not automatically clear after the next collection.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

* Once an alert is triggered for this metric, it must be manually cleared.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Time" object.

If warning or critical threshold values are currently set for any "Time" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Time" object, use the Edit Thresholds page.

Data Source

The database stores login information in different views, based on the audit_trail setting. The database views used are:

• DB or DB_EXTENDED: DBA_AUDIT_SESSION

• XML (10g Release 2 only): DBA_COMMON_AUDIT_TRAIL

4.18.1 Flash Recovery Area

This metric returns the Flash Recovery Area Location.

Metric Summary 10gR1 or higher Collection every 5 minutes Not evaluated (not alertable)

Metric Summary

The following table shows how often the metric's value is collected.

Data Source

SELECT value 
  FROM v$parameter 
  WHERE name='db_recovery_file_dest';

User Action

Not available since not alertable.

4.18.2 Flashback On

This metric returns whether or not flashback logging is enabled - YES or NO.

Metric Summary 10gR1 or higher Collection every 5 minutes Not evaluated (not alertable)

Metric Summary

The following table shows how often the metric's value is collected.

Data Source

SELECT flashback_on 
  FROM v$database;

User Action

Not available since not alertable.

4.18.3 Log Mode

This metric returns the log mode of the database - ARCHIVELOG or NOARCHIVELOG.

Metric Summary 10gR1 or higher Collection every 5 minutes Not evaluated (not alertable)

Metric Summary

The following table shows how often the metric's value is collected.

Data Source

SELECT log_mode 
  FROM v$database;

User Action

Not available since not alertable.

4.18.4 Oldest Flashback Time

This metric represents the oldest point-in-time to which you can flashback your database.

Metric Summary 10gR1 or higher Collection every 5 minutes Not evaluated (not alertable)

Metric Summary

The following table shows how often the metric's value is collected.

Data Source

SELECT to_char(oldest_flashback_time, 'YYYY-MM-DD HH24:MI:SS') 
  FROM v$flashback_database_log;

User Action

Not applicable since not alertable.

4.18.5 Usable Flash Recovery Area (%)

This metric represents the percentage of space usable in the flash recovery area. The space usable is composed of the space that is free in addition to the space that is reclaimable.

Metric Summary 10gR2 or higher Collection every 5 minutes Not evaluated (not alertable)

Metric Summary

The following table shows how often the metric's value is collected.

Data Source

SELECT (100 - sum(percent_space_used)) + sum(percent_space_reclaimable) 
  FROM v$flash_recovery_area_usage;

User Action

Not applicable since not alertable.

4.19.1 Global Cache Average Convert Time (centi-seconds)

This metric represents the average convert time, measured in hundredths of a second.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

global cache convert time * 10 / global cache converts

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.19.2 Global Cache Average CR Block Request Time (centi-seconds)

This metric represents the average time, measured in hundredths of a second, that CR block was received.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

global cache CR block receive time * 10 / global cache current blocks received

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.19.3 Global Cache Average Current Block Request Time (centi-seconds)

This metric represents the average time, measured in hundredths of a second, to get a current block.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

global cache current block send time * 10 / global cache current blocks served

4.19.4 Global Cache Average Get Time (centi-seconds)

This metric represents the average get time, measured in hundredths of a second.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

global cache get time * 10 / global cache gets

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.19.5 Global Cache Blocks Corrupt

This metric represents the number of blocks that encountered a corruption or checksum failure during interconnect over the user-defined observation period.

Note: Unlike most metrics, which accept thresholds as real numbers, this metric can only accept an integer as a threshold.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

* Once an alert is triggered for this metric, it must be manually cleared.

Data Source

global cache blocks corrupted

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.19.6 Global Cache Blocks Lost

This metric represents the number of global cache blocks lost over the user-defined observation period.

Note: Unlike most metrics, which accept thresholds as real numbers, this metric can only accept an integer as a threshold.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

* Once an alert is triggered for this metric, it must be manually cleared.

Data Source

global cache blocks lost

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.20.1 Maintenance

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

4.20.2 Mounted

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

4.20.3 State

Metric Summary

The following table shows how often the metric's value is collected.

4.20.4 State Description

Metric Summary

The following table shows how often the metric's value is collected.

4.20.5 Status

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

4.20.6 Unavailable

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

4.20.7 Unmounted

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

4.22.1 Interface Type

Cluster database instances should use private interconnects for internode communication. This metric monitors whether the network interface used by the cluster instance is a private one. If the network interface is known to be public, a critical alert is generated. If the network interface type is unknown, a warning alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Interface Name" object.

If warning or critical threshold values are currently set for any "Interface Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Interface Name" object, use the Edit Thresholds page.

Data Source

V$CLUSTER_INTERCONNECTS

V$CONFIGURED_INTERCONNECTS

User Action

Use oifcfg in the CRS home to correctly configure the private interfaces in OCR.

4.23.1 Transfer Rate (MB/s)

This metric collects the internode communication traffic of a cluster database instance. This is an estimation using the following formula:

(gc cr blocks received/sec + gc current blocks received/sec + gc cr blocks served/sec + gc current blocks served/sec) * db_block_size 
+
( messags sent directly/sec + messages send indirectly/sec + messages received/sec ) * 200 bytes

The critical and warning threshold of this metric are not set by default. Users can set them according to the speed of their cluster interconnects.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Instance Name" object.

If warning or critical threshold values are currently set for any "Instance Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Instance Name" object, use the Edit Thresholds page.

Data Source

V$SYSSTAT

V$DLM_MISC

V$PARAMETER

4.24.1 Total Invalid Object Count

This metric represents the total invalid object count.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

4.25.1 Owner's Invalid Object Count

This metric represents the invalid object count by owner.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Invalid Object Owner" object.

If warning or critical threshold values are currently set for any "Invalid Object Owner" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Invalid Object Owner" object, use the Edit Thresholds page.

Data Source

For each metric index:

SELECT count(1) 

User Action

View the status of the database objects in the schema identified by the Invalid Object Owner metric. Recompile objects as necessary.

4.26.1 Corrupt Data Blocks

This metric represents the count of corrupt data blocks.

Metric Summary 9iR2 or higher Evaluated and Collected every 15 minutes Operator > Warning Threshold - 0 Critical Threshold - Not Defined Number of corrupt data blocks is %value%.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

SELECT count(unique(file#)) 
  FROM v$database_block_corruption;

User Action

Perform a database recovery.

4.26.2 Missing Media Files

This metric represents the count of missing media files.

Metric Summary 8i or higher Evaluated and Collected every 15 minutes Operator > Warning Threshold - 0 Critical Threshold - Not Defined Number of missing media files is %value%.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

SELECT count(file#) 
  FROM v$datafile_header 
  WHERE recover ='YES' OR error is not null;

User Action

You should perform a database recovery.

4.27.1 Recovery Area Free Space (%)

This metric represents the recovery area free space as a percentage.

Metric Summary

The following table shows how often the metric's value is collected.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.28.1 State

This metric represents the state of the database.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

4.28.2 Status

This metric checks whether a new connection can be established to a database. If the maximum number of users is exceeded or the listener is down, this test is triggered.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

Perl returns 1 when a connection can be made to the database (using Management Agent monitoring connection details), 0 otherwise.

User Action

Check the status of the listener to make sure it is running on the node where the event was triggered. If the listener is running, check to see if the number of users is at the session limit. Note: The choice of user credentials for the Probe metric should be considered. If the preferred user has the RESTRICED SESSION privilege, the user will be able to connect to a database even if the LICENSE_MAX_SESSIONS limit is reached.

4.28.3 User Logon Time (msec)

This metric represents the amount of time the agent takes to make a connection to the database, measured in milliseconds.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

Number of milliseconds (as measured in the Perl script) to connect to the database.

User Action

No user action is necessary.

4.29.1 Number of recommendations

Oracle uses the Automatic Segment Advisor job to detect segment issues regularly within maintenance windows. It determines whether the segments have unused space that can be released. The Number of recommendations is the number of segments that have Reclaimable Space. The recommendations come from all runs of the automatic segment advisor job and any user scheduled segment advisor jobs.

User Action

Oracle recommends shrinking or reorganizing these segments to release unused space.

4.30.1 Session Suspended by Data Object Limitation

This metric represents the session suspended by data object limitation.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.30.2 Session Suspended by Quota Limitation

This metric represents the session suspended by quota limitation.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.30.3 Session Suspended by Rollback Segment Limitation

This metric represents the session suspended by rollback segment limitation.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.30.4 Session Suspended by Tablespace Limitation

This metric represents the session suspended by tablespace limitation.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.31.1 Java Pool Free (%)

This metric represents the percentage of the Java Pool that is currently marked as free.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

((Free/Total)*100) where:

• Free: select sum(decode(name,'free memory',bytes)) from v$sgastat where pool = 'java pool'

• Total: select sum(bytes) from v$sgastat where pool = 'java pool'

User Action

If this pool size is too small, the database JVM (Java Virtual Machine) may not have sufficient memory to satisfy future calls, leading potentially to unexpected database request failures.

4.31.2 Large Pool Free (%)

This metric represents the percentage of the Large Pool that is currently marked as free.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

((Free/Total)*100) where:

• Free: select sum(decode(name,'free memory',bytes)) from v$sgastat where pool = 'large pool'

• Total: select sum(bytes) from v$sgastat where pool = 'large pool'

User Action

Consider enlarging the large pool or utilizing it more sparingly. This reduces the possibility of large memory areas competing with the library cache and dictionary cache for available memory in the shared pool.

4.31.3 Shared Pool Free (%)

This metric represents the percentage of the Shared Pool that is currently marked as free.

This test checks the percentage of Shared Pool that is currently free. If the value is less than or equal to the threshold values specified by the threshold arguments, and the number of occurrences exceeds the value specified in the "Number of Occurrences" parameter, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

((Free/Total)*100) where:

• free: select sum(decode(name,'free memory',bytes)) from v$sgastat where pool = 'shared pool'

• total: select sum(bytes) from v$sgastat where pool = 'shared pool'

User Action

If the percentage of Free Memory in the Shared Pool rises above 50%, too much memory has been allocated to the shared pool. This extra memory could be better utilized by other applications on the machine. In this case the size of the Shared Pool should be decreased. This can be accomplished by modifying the shared_pool_size initialization parameter.

4.32.1 Snapshot Too Old due to Rollback Segment Limit

This metric represents the snapshot too old because of the rollback segment limit.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.32.2 Snapshot Too Old due to Tablespace Limit

This metric represents the snapshot too old because of the tablespace limit.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.33.1 Baseline SQL Response Time

Baseline SQL Response Time

Metric Summary

The following table shows how often the metric's value is collected.

4.33.2 Current SQL Response Time

Current SQL response time

Metric Summary

The following table shows how often the metric's value is collected.

4.33.3 SQL Response Time (%)

SQL Response Time is the average elapsed time per execution of a representative set of SQL statements, relative to a baseline. It is expressed as a percentage.

This metric is unavailable in versions 8.1.7 and earlier.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

PL/SQL packaged procedure mgmt_response.get_metric_curs

User Action

If the SQL Response Time is less than 100%, then SQL statements are taking less time to execute when compared to the baseline. Response Time greater than 100% indicates that the database is not performing well when compared to the baseline.

SQL Response Time is a percentage of the baseline, not a simple percentage. So, for example, 100% of baseline means the SQL Response Time is the same as the baseline. 200% of baseline means the SQL Response Time is two times slower than the baseline. 50% of baseline means SQL Response Time is two times faster than baseline. A warning threshold of 200% indicates that the database is two times slower than the baseline, while a critical threshold of 500% indicates the database is 5 times slower than the baseline.

Representative statements are selected when two V$SQL snapshots are taken. All calculations are based on the deltas between these two snapshots. First, the median elapsed_time/execution for all statements that were executed in the time interval between the two snapshots are calculated. Then all statements that have an elapsed_time/execution > median elapsed_time/execution are taken, and the top 25 most frequently executed statements are displayed.

Pre-requisites for Monitoring SQL Response Time

Some tables and a PL/SQL package must be installed on the monitored database. This can be done by going to the database targets page and pressing the Configure button for your database. If a database has not been configured, the message "Not configured" will be displayed for SQL Response Time.

Configuring the Baseline

The baseline is configured on demand, automatically. The first time the agent calls the stored procedure to get the value of the metric, a snapshot of V$SQL is taken. The second time, another snapshot is taken. Then the representative statements are picked and stored in a table. The next time the agent requests the value of the metric, we are able to calculate and return the relative SQL response time.

Because of baseline configuration, there will be a delay between the time the database is configured and the value of the metric is displayed. During this period, the message "Not available" will be displayed for SQL Response Time.

Enterprise Manager will automatically configure the baseline against which SQL Response Time will be compared. However, in order for the SQL Response Time metric to be truly representative, the DBA must reconfigure the baseline at a time when the load on the database is typical.

To reconfigure the baseline, click on the link titled "Compared to Baseline" located next to the SQL Response Time value on the Database Home Page. The SQL statements used for tracking the SQL Response Time and baseline values are displayed. Click Reset Baseline. This clears the list of statements and the baseline values. Enterprise Manager will then automatically reconfigure the baseline within minutes.

If the database was lightly loaded at the time the baseline was taken, then the metric can indicate that the database is performing poorly under typical load when such is not the case. In this case, the DBA must reset the baseline. If the DBA has never manually reset the baseline, then the metric value will not be representative.

4.34.1 Number of Transactions Assigned

This metric shows statistics about the total number of transactions assigned by the coordinator process to apply servers since the apply process last started. For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

SELECT APPLY_NAME, TOTAL_RECEIVED, TOTAL_ASSIGNED, TOTAL_APPLIED 
  FROM V$STREAMS_APPLY_COORDINATOR; 

The TOTAL_ASSIGNED column in the following query shows this metric for an apply process:

User Action

When an apply process is enabled, monitor this metric to ensure that the apply process assigning transactions to apply servers.

4.34.2 Total number of Transactions applied

This metric shows statistics about the total number of transactions applied by the apply process since the apply process last started. For the target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The TOTAL_APPLIED column in the following query shows this metric for an apply process:

SELECT APPLY_NAME, TOTAL_RECEIVED, TOTAL_ASSIGNED, TOTAL_APPLIED 
  FROM V$STREAMS_APPLY_COORDINATOR; 

User Action

When an apply process is enabled, monitor this metric to ensure that the apply process is applying transactions.

4.34.3 Total Number of Transactions Received

This metric shows statistics about the total number of transactions received by the coordinator process since the apply process last started. For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The TOTAL_RECEIVED column in the following query shows this metric for an apply process:

SELECT APPLY_NAME, TOTAL_RECEIVED, TOTAL_ASSIGNED, TOTAL_APPLIED 
  FROM V$STREAMS_APPLY_COORDINATOR; 

User Action

When an apply process is enabled, monitor this metric to ensure that the apply process is receiving transactions.

4.35.1 Number of Outstanding Messages

This metric shows information about the number of messages in a buffered queue to be dequeued by the apply process. This number includes both messages in memory and messages spilled from memory. For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The NUM_MSGS column in the following query shows this metric for an apply process:

SELECT APPLY_NAME, S.NUM_MSGS NUM_MSGS, Q.SPILL_MSGS SPILL_MSGS 
  FROM DBA_APPLY A, V$BUFFERED_QUEUES Q,V$BUFFERED_SUBSCRIBERS S 
  WHERE A.QUEUE_NAME = S.QUEUE_NAME AND A.QUEUE_OWNER = S.QUEUE_SCHEMA 
  AND A.QUEUE_NAME = Q.QUEUE_NAME 
  AND A.QUEUE_OWNER = Q.QUEUE_SCHEMA 
  AND S.SUBSCRIBER_ADDRESS IS NULL; 

User Action

When an apply process is enabled, monitor this metric to ensure that the apply process is dequeuing messages.

4.35.2 Number of Overflow Messages

This metric shows information about the number of messages to be dequeued by the apply process that have spilled from memory to the queue table. Messages in a buffered queue can spill from memory into the queue table if they have been staged in the buffered queue for a period of time without being dequeued, or if there is not enough space in memory to hold all of the messages.

For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The SPILL_MSGS column in the following query shows this metric for an apply process:

SELECT APPLY_NAME, S.NUM_MSGS NUM_MSGS, Q.SPILL_MSGS SPILL_MSGS 
  FROM DBA_APPLY A, V$BUFFERED_QUEUES Q,V$BUFFERED_SUBSCRIBERS S 
  WHERE A.QUEUE_NAME = S.QUEUE_NAME AND A.QUEUE_OWNER = S.QUEUE_SCHEMA 
  AND A.QUEUE_NAME = Q.QUEUE_NAME 
  AND A.QUEUE_OWNER = Q.QUEUE_SCHEMA 
  AND S.SUBSCRIBER_ADDRESS IS NULL;

User Action

The number of spilled messages should be kept as low as possible for the best performance. A high number of spilled messages might result in the following cases:

• There might be a problem with an apply process that applies messages captured by the capture process. When this happens, the number of messages can build in a queue because they are not being consumed. In this case, make sure the relevant apply processes are enabled, and correct any problems with these apply processes.

• The Streams pool may be too small to hold the captured messages. In this case, increase the size of the Streams pool. If the database is Oracle Database 10g release 2 (10.2) or higher, then you can configure Automatic Shared Memory Management to manage the size of the Streams pool automatically. Set the SGA_TARGET initialization parameter to use Automatic Shared Memory Management.

4.36.1 Ready

This metric shows the number of messages in a persistent queue that are ready to be dequeued by the apply process. The apply process has not yet attempted to dequeue these messages.

Metric Summary

The following table shows how often the metric's value is collected.

Data Source

The data source includes the following data dictionary views: DBA_QUEUES, DBA_APPLY, and AQ$queue_table_name.

User Action

Monitor this metric to ensure that the apply process is dequeuing messages that are ready.

4.36.2 Waiting

This metric shows the number of messages in a persistent queue that are waiting to be dequeued by the apply process. The apply process has attempted to dequeue these messages at least once, and the apply process failed. The apply process might attempt to dequeue a waiting message again.

Metric Summary

The following table shows how often the metric's value is collected.

Data Source

The data source includes the following data dictionary views: DBA_QUEUES, DBA_APPLY, and AQ$queue_table_name.

User Action

The messages in WAITING might have been enqueued with a delay attribute set. In this case, after the specified delay period is finished, the messages will be ready to dequeue.

4.37.1 Total number of Messages Dequeued

The reader server for an apply process dequeues messages from the queue. The reader server is a parallel execution server that computes dependencies between LCRs and assembles messages into transactions. The reader server then returns the assembled transactions to the coordinator, which assigns them to idle apply servers.

This metric shows the total number of messages dequeued by the reader server for the apply process since the last time the apply process was started. For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The TOTAL_MESSAGES_DEQUEUED column in the following query shows this metric for an apply process:

SELECT APPLY_NAME, TOTAL_MESSAGES_DEQUEUED FROM V$STREAMS_APPLY_READER; 

User Action

When an apply process is enabled, monitor this metric to ensure that the apply process is dequeuing messages.

4.38.1 Total Messages Captured

This metric shows information about the number of redo entries passed by LogMiner to the capture process for detailed rule evaluation. A capture process converts a redo entry into a message and performs detailed rule evaluation on the message when capture process prefiltering cannot discard the change.

After detailed rule evaluation, the message is enqueued if it satisfies the capture process rule sets, or the message is discarded if it does not satisfy the capture process rule sets.

For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The TOTAL_MESSAGES_CAPTURED column in the following query shows this metric for a capture process:

SELECT CAPTURE_NAME, TOTAL_MESSAGES_CAPTURED, TOTAL_MESSAGES_ENQUEUED 
  FROM V$STREAMS_CAPTURE;

User Action

When a capture process is enabled, monitor this metric to ensure that the capture process is scanning redo entries.

4.38.2 Total Messages Enqueued

This metric shows information about the number of messages enqueued by a capture process. The number of messages enqueued includes logical change records (LCRs) that encapsulate data manipulation language (DML) and data definition language (DDL) changes. The number of messages enqueued also includes messages that contain transaction control statements. These messages contain directives such as COMMIT and ROLLBACK. Therefore, the number of messages enqueued is higher than the number of row changes and DDL changes enqueued by a capture process.

For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The TOTAL_MESSAGES_ENQUEUED column in the following query shows this metric for a capture process:

SELECT CAPTURE_NAME, TOTAL_MESSAGES_CAPTURED, TOTAL_MESSAGES_ENQUEUED 
  FROM V$STREAMS_CAPTURE;

User Action

When a capture process is enabled, monitor this metric to ensure that the capture process is enqueuing messages. If you know that there were source database changes that should be captured by the capture process, and the capture process is not capturing these changes, then there might be a problem with the rules used by the capture process.

4.39.1 Number of Messages

This metric shows information about the number of messages enqueued by a capture process in a buffered queue. This number includes both messages in memory and messages spilled from memory.

If queue publishers other than the capture process enqueue messages into a buffered queue, then the values shown can include messages from these other queue publishers.

For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The NUM_MSGS column in the following query shows this metric for a capture process:

SELECT CAPTURE_NAME, P.NUM_MSGS NUM_MSGS, Q.SPILL_MSGS SPILL_MSGS 
  FROM V$BUFFERED_PUBLISHERS P, V$BUFFERED_QUEUES Q, DBA_CAPTURE C 
  WHERE C.QUEUE_NAME = P.QUEUE_NAME 
    AND C.QUEUE_OWNER = P.QUEUE_SCHEMA 
    AND C.QUEUE_NAME = Q.QUEUE_NAME 
    AND C.QUEUE_OWNER = Q.QUEUE_SCHEMA 
    AND C.CAPTURE_NAME = P.SENDER_NAME 
    AND P.SENDER_ADDRESS IS NULL 
    AND P.SENDER_PROTOCOL = 1;

User Action

When a capture process is enabled, monitor this metric to ensure that the capture process enqueuing messages.

4.39.2 Number of Spilled Messages

This metric shows information about the number of messages enqueued by a capture process that have spilled from memory to the queue table. Messages in a buffered queue can spill from memory into the queue table if they have been staged in the buffered queue for a period of time without being dequeued, or if there is not enough space in memory to hold all of the messages.

If queue publishers other than the capture process enqueue messages into a buffered queue, then the values shown can include messages from these other queue publishers.

For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The SPILL_MSGS column in the following query shows this metric for a capture process:

SELECT CAPTURE_NAME, P.NUM_MSGS NUM_MSGS, Q.SPILL_MSGS SPILL_MSGS 
  FROM V$BUFFERED_PUBLISHERS P, V$BUFFERED_QUEUES Q, DBA_CAPTURE C 
  WHERE C.QUEUE_NAME = P.QUEUE_NAME 
    AND C.QUEUE_OWNER = P.QUEUE_SCHEMA 
    AND C.QUEUE_NAME = Q.QUEUE_NAME 
    AND C.QUEUE_OWNER = Q.QUEUE_SCHEMA 
    AND C.CAPTURE_NAME = P.SENDER_NAME 
    AND P.SENDER_ADDRESS IS NULL 
    AND P.SENDER_PROTOCOL = 1; 

User Action

The number of spilled messages should be kept as low as possible for the best performance. A high number of spilled messages can result in the following cases:

• There might be a problem with a propagation that propagates the messages captured by the capture process, or there might be a problem with an apply process that applies messages captured by the capture process. When this happens, the number of messages can build in a queue because they are not being consumed. In this case, make sure the relevant propagations and apply processes are enabled, and correct any problems with these propagations and apply processes.

• The Streams pool might be too small to hold the captured messages. In this case, increase the size of the Streams pool. If the database is Oracle Database 10g release 2 (10.2) or higher, then you can configure Automatic Shared Memory Management to manage the size of the Streams pool automatically. Set the SGA_TARGET initialization parameter to use Automatic Shared Memory Management.

4.40.1 Apply Processes Having Errors

This metric shows the number of apply processes that have encountered errors at the local database. For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The information in this metric is in the DBA_APPLY data dictionary view.

User Action

If an apply process has encountered errors, then correct the conditions that caused the errors.

4.40.2 Capture Processes Having Errors

This metric shows the number of capture processes that have encountered errors at the local database. For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The information in this metric is in the DBA_CAPTURE data dictionary view.

User Action

If a capture process has encountered errors, then correct the conditions that caused the errors.

4.40.3 Number of Apply Processes

This metric shows the number of apply processes at the local database. For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The information in this metric is in the DBA_APPLY data dictionary view.

User Action

Use this metric to determine the total number of apply processes at the local database.

4.40.4 Number of Capture Processes

This metric shows the number of capture processes at the local database. For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The information in this metric is in the DBA_CAPTURE data dictionary view.

User Action

Use this metric to determine the total number of capture processes at the local database.

4.40.5 Number of Propagation Jobs

This metric shows the number of propagations at the local database. For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The information in this metric is in the DBA_PROPAGATION data dictionary view.

User Action

Use this metric to determine the total number of propagations at the local database.

4.40.6 Propagation Errors

This metric shows the number of propagations that have encountered errors at the local database. For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The information in this metric is in the DBA_PROPAGATION data dictionary view.

User Action

If a propagation has encountered errors, then correct the conditions that caused the errors.

4.41.1 Total Number of KBytes Propagated

This metric shows the total number of messages propagated by the propagation from a buffered at the local database.

Data Source

The TOTAL_BYTES column in the following query shows this metric for a propagation:

SELECT PROPAGATION_NAME, TOTAL_NUMBER, TOTAL_BYTES/1024 KBYTES 
  FROM DBA_PROPAGATION P, DBA_QUEUE_SCHEDULES Q 
  WHERE P.SOURCE_QUEUE_NAME = Q.QNAME 
    AND P.SOURCE_QUEUE_OWNER = Q.SCHEMA 
    AND MESSAGE_DELIVERY_MODE = 'BUFFERED'; 

User Action

When a propagation is enabled, monitor this metric to ensure that the propagation is propagating messages.

4.41.2 Total Number of Messages Propagated

This metric shows the total number of messages propagated by the propagation from a buffered queue at the local database.

Data Source

The TOTAL_NUMBER column in the following query shows this metric for a propagation:

SELECT PROPAGATION_NAME, TOTAL_NUMBER, TOTAL_BYTES/1024 KBYTES 
  FROM DBA_PROPAGATION P, DBA_QUEUE_SCHEDULES Q 
  WHERE P.SOURCE_QUEUE_NAME = Q.QNAME 
    AND P.SOURCE_QUEUE_OWNER = Q.SCHEMA 
    AND MESSAGE_DELIVERY_MODE = 'BUFFERED'; 

User Action

When a propagation is enabled, monitor this metric to ensure that the propagation is propagating messages.

4.42.1 Messages in Ready State

This metric shows the number of messages in a buffered source queue that are ready to be propagated by the propagation to the destination queue. The propagation has not yet attempted to propagate these messages.

For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The NUM_MSGS column in the following query shows this metric for a propagation:

SELECT PROPAGATION_NAME, NUM_MSGS READY 
  FROM V$BUFFERED_SUBSCRIBERS, DBA_PROPAGATION 
  WHERE SUBSCRIBER_NAME IS NULL 
    AND SUBSCRIBER_ADDRESS = DESTINATION_DBLINK 
    AND QUEUE_SCHEMA = SOURCE_QUEUE_OWNER 
    AND QUEUE_NAME = SOURCE_QUEUE_NAME; 

User Action

Monitor this metric to ensure that the propagation is propagating messages that are ready.

4.43.1 Total Number of KBytes Propagated

This metric shows the total number of kilobytes propagated by the propagation from a persistent queue at the local database.

Data Source

The TOTAL_BYTES column in the following query shows this metric for a propagation:

SELECT PROPAGATION_NAME, TOTAL_NUMBER, TOTAL_BYTES/1024 KBYTES 
  FROM DBA_PROPAGATION P, DBA_QUEUE_SCHEDULES Q 
  WHERE P.SOURCE_QUEUE_NAME = Q.QNAME 
    AND P.SOURCE_QUEUE_OWNER = Q.SCHEMA 
    AND MESSAGE_DELIVERY_MODE = 'PERSISTENT';

User Action

When a propagation is enabled, monitor this metric to ensure that the propagation is propagating messages.

4.43.2 Total Number of Messages Propagated

This metric shows the total number of messages propagated by the propagation from a persistent queue at the local database.

Data Source

The TOTAL_NUMBER column in the following query shows this metric for a propagation:

SELECT PROPAGATION_NAME, TOTAL_NUMBER, TOTAL_BYTES/1024 KBYTES 
  FROM DBA_PROPAGATION P, DBA_QUEUE_SCHEDULES Q 
  WHERE P.SOURCE_QUEUE_NAME = Q.QNAME 
    AND P.SOURCE_QUEUE_OWNER = Q.SCHEMA 
    AND MESSAGE_DELIVERY_MODE = 'PERSISTENT'; 

User Action

When a propagation is enabled, monitor this metric to ensure that the propagation is propagating messages.

4.44.1 Messages in Ready State

This metric shows the number of messages in a persistent source queue that are ready to be propagated by the propagation to the destination queue. The propagation has not yet attempted to propagate these messages.

For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The data source includes the following data dictionary views: DBA_QUEUES, DBA_PROPAGATION, and AQ$queue_table_name.

User Action

Monitor this metric to ensure that the propagation is propagating messages that are ready.

4.44.2 Messages in Waiting State

This metric shows the number of messages in a persistent source queue that are waiting to be propagated by the propagation to the destination queue. The propagation has attempted to propagate these messages at least once, and the propagation failed. The propagation might attempt to propagate a waiting message again after a specified retry delay interval.

For target version 10.1.0.x, the collection frequency for this metric is every 10 minutes.

Data Source

The data source includes the following data dictionary views: DBA_QUEUES, DBA_PROPAGATION, and AQ$queue_table_name.

User Action

Common failures that prevent message propagation include the following:

• Database link failed

• Remote database is not available

• Remote queue does not exist

• Remote queue was not started

• Security violation while trying to enqueue messages into remote queue

Determine the problem that is causing propagation to fail, and correct the problem.

4.45.1 Suspended Session Count

This metric represents the number of resumable sessions currently suspended in the database.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

SELECT count(*) 
  FROM v$resumable 
  WHERE status = 'SUSPENDED' and enabled = 'YES'

User Action

Query the v$resumable view to see what the correctable errors are that are causing the suspension. The way to correct each error depends on the nature of the error.

4.46.1 System Response Time (centi-seconds)

This metric represents the average time taken for each call (both user calls and recursive calls) within the database. A change in this value indicates that either the workload has changed or that the database�s ability to process the workload has changed because of either resource constraints or contention.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.47.1 Waiting Session Count

This metric represents the number of sessions waiting at the sample time.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

SELECT count(*) 
  FROM v$session_wait 
  WHERE wait_time = 0 and event not in IdleEvents

See the Idle Events section in this chapter.

User Action

When this count is high, the system is doing more waiting than anything else. Evaluate the various types of wait activity using the real-time and historical performance monitoring capabilities of Enterprise Manager.

4.48.1 Tablespace Allocated Space (MB)

The allocated space of a tablespace is the sum of the current size of its datafiles. A portion of this allocated space is used to store data while some may be free space. If segments are added to a tablespace, or if existing segments grow, they will use the allocated free space. The allocated free space is only available to segments within the tablespace. If, over time, the segments within a tablespace are not using this free space, then the allocated free space is being unused.

This metric calculates the space allocated for each tablespace. It is not intended to generate alerts. Rather it should be used in conjunction with the Allocated Space Used (MB) metric to produce an historical view of the amount of space being used and unused by each tablespace.

For all target versions, the collection frequency for this metric is every 7 hours.

Data Source

Tablespace Allocated Space (MB) is calculated by looping though the tablespaces data files and totalling the size of the data files.

4.48.2 Tablespace Used Space (MB)

The allocated space of a tablespace is the sum of the current size of its datafiles. Some of this allocated space is used to store data and some of it may be free space. If segments are added to a tablespace, or if existing segments grow, they will use the allocated free space. The allocated free space is only available to segments within the tablespace. If, over time, the segments within a tablespace are not using this free space, then the allocated free space is being wasted.

This metric calculates the space used for each tablespace. It is not intended to generate alerts. Rather it should be used in conjunction with the Tablespace Allocated Space (MB) metric to produce an historical view of the amount of space being used and unused by each tablespace.

For all target versions, the collection frequency for this metric is every 7 hours.

Data Source

Tablespace Used Space (MB) is Tablespace Allocated Space (MB) Tablespace Allocated Free Space (MB) where:

Tablespace Allocated Space (MB) is calculated by looping through the tablespaces data files and totaling the size of the data files.

Tablespace Allocated Free Space (MB) is calculated by looping through the tablespaces data files and totaling the size of the free space in each data file.

4.49.1 Tablespace Free Space (MB)

As segments within a tablespace grow, the available free space decreases. If there is no longer any available free space, meaning datafiles have hit their maximum size or there is no more disk space, then the creation of new segments or the extension of existing segments will fail.

This metric checks for the total available free space in each tablespace. This metric is intended for larger tablespaces, where the Available Space Used (%) metric is less meaningful. If the available free space falls below the size specified in the threshold arguments, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Tablespace Name" object.

If warning or critical threshold values are currently set for any "Tablespace Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Tablespace Name" object, use the Edit Thresholds page.

Data Source

MaximumSize - Total Used Space where:

• TotalUsedSpace: total used space in MB of tablespace

• MaximumSize: Maximum size (in MB) of the tablespace. The maximum size is determined by looping through the tablespaces data files, as well as additional free space on the disk that would be available for the tablespace should a data file autoextend.

User Action

Perform one of the following:

• Increase the size of the tablespace by: Enabling automatic extension for one of its existing data files, Manually resizing one of its existing data files, or adding a new data file.

• If the tablespace is suffering from tablespace free space fragmentation problems, consider reorganizing the entire tablespace.

• Relocate segments to another tablespace, thus increasing the free space in this tablespace.

• Run the Segment Advisor on the tablespace.

4.49.2 Tablespace Space Used (%)

As segments within a tablespace grow, the available free space decreases. If there is no longer any available free space, meaning datafiles have hit their maximum size or there is no more disk space, then the creation of new segments or the extension of existing segments will fail.

This metric checks the Available Space Used (%) for each tablespace. If the percentage of used space is greater than the values specified in the threshold arguments, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Tablespace Name" object.

If warning or critical threshold values are currently set for any "Tablespace Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Tablespace Name" object, use the Edit Thresholds page.

Data Source

(TotalUsedSpace / MaximumSize) * 100 where:

• TotalUsedSpace: total used space in MB of tablespace

• MaximumSize: Maximum size (in MB) of the tablespace. The maximum size is determined by looping through the tablespaces data files, as well as additional free space on the disk that would be available for the tablespace should a data file autoextend.

For additional information about the data source, refer to the fullTbsp.pl Perl script located in the sysman/admin/scripts directory.

User Action

Perform one of the following:

• Increase the size of the tablespace by: Enabling automatic extension for one of its existing data files, Manually resizing one of its existing data files, or adding a new data file.

• If the tablespace is suffering from tablespace free space fragmentation problems, consider reorganizing the entire tablespace.

• Relocate segments to another tablespace, thus increasing the free space in this tablespace.

• Run the Segment Advisor on the tablespace.

4.50.1 Tablespace Free Space (MB) (dictionary managed)

As segments within a tablespace grow, the available free space decreases. If there is no longer any available free space, meaning datafiles have hit their maximum size or there is no more disk space, then the creation of new segments or the extension of existing segments will fail.

This metric checks for the total available free space in each tablespace. This metric is intended for larger tablespaces, where the Available Space Used (%) metric is less meaningful. If the available free space falls below the size specified in the threshold arguments, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Tablespace Name" object.

If warning or critical threshold values are currently set for any "Tablespace Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Tablespace Name" object, use the Edit Thresholds page.

Data Source

MaximumSize - Total Used Space where:

• TotalUsedSpace: total used space in MB of tablespace

• MaximumSize: Maximum size (in MB) of the tablespace. The maximum size is determined by looping through the tablespaces data files, as well as additional free space on the disk that would be available for the tablespace should a data file autoextend.

User Action

Perform one of the following:

• Increase the size of the tablespace by: Enabling automatic extension for one of its existing data files, Manually resizing one of its existing data files, or adding a new data file.

• If the tablespace is suffering from tablespace free space fragmentation problems, consider reorganizing the entire tablespace.

• Relocate segments to another tablespace, thus increasing the free space in this tablespace.

• Run the Segment Advisor on the tablespace.

4.50.2 Tablespace Space Used (%) (dictionary managed)

As segments within a tablespace grow, the available free space decreases. If there is no longer any available free space, meaning datafiles have hit their maximum size or there is no more disk space, then the creation of new segments or the extension of existing segments will fail.

This metric checks the Available Space Used (%) for each tablespace. If the percentage of used space is greater than the values specified in the threshold arguments, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Tablespace Name" object.

If warning or critical threshold values are currently set for any "Tablespace Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Tablespace Name" object, use the Edit Thresholds page.

Data Source

(TotalUsedSpace / MaximumSize) * 100 where:

• TotalUsedSpace: total used space in MB of tablespace

• MaximumSize: Maximum size (in MB) of the tablespace. The maximum size is determined by looping through the tablespace�s data files, as well as additional free space on the disk that would be available for the tablespace should a data file autoextend.

User Action

Perform one of the following:

• Increase the size of the tablespace by: Enabling automatic extension for one of its existing data files, Manually resizing one of its existing data files, or adding a new data file.

• If the tablespace is suffering from tablespace free space fragmentation problems, consider reorganizing the entire tablespace.

• Relocate segments to another tablespace, thus increasing the free space in this tablespace.

• Run the Segment Advisor on the tablespace.

4.51.1 Segments Approaching Maximum Extents

Segments which are nearing the upper limit of maximum extents. For all target versions, the collection frequency for this metric is every 24 hours.

Data Source

The first 10 segments names which are approaching their MaxExtent in the tablespace.

User Action

If possible, increase the value of the segments MAXEXTENTS storage parameter.

Otherwise, rebuild the segment with a larger extent size ensuring the extents within a segment are the same size by specifying STORAGE parameters where NEXT=INITIAL and PCTINCREASE = 0.

For segments that are linearly scanned, choose an extent size that is a multiple of the number of blocks read during each multiblock read. This will ensure that the Oracle multiblock read capability is used efficiently.

4.51.2 Segments Approaching Maximum Extents Count

This metric checks for segments which are nearing the upper limit of the number of maximum extents. If the number of segments is greater than the values specified in the threshold arguments, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Tablespace Name" object.

If warning or critical threshold values are currently set for any "Tablespace Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Tablespace Name" object, use the Edit Thresholds page.

Data Source

Number of segments for which the maximum number of extents minus the number of existing extents is less than 2.

For additional information about the data source, refer to the problemTbsp.pl Perl script located in the sysman/admin/scripts directory.

User Action

If possible, increase the value of the segments MAXEXTENTS storage parameter.

Otherwise, rebuild the segment with a larger extent size ensuring the extents within a segment are the same size by using a locally managed tablespace. In the case of a dictionary managed tablespace, specify STORAGE parameters where NEXT=INITIAL and PCTINCREASE = 0.

4.51.3 Segments Not Able to Extend

Segments which cannot allocate an additional extent.

Metric Summary

The following table shows how often the metric's value is collected.

Data Source

The first 10 segments names which cannot allocate an additional extent in the tablespace.

User Action

Perform one of the following:

• Increase the size of the tablespace by enabling automatic extension for one of its existing data files, manually resizing one of its existing data files. or adding a new data file.

• If the tablespace is suffering from tablespace free space fragmentation problems, consider reorganizing the entire tablespace.

4.51.4 Segments Not Able to Extend Count

This metric checks for segments which cannot allocate an additional extent. If the number of segments is greater than the values specified in the threshold arguments, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each "Tablespace Name" object.

If warning or critical threshold values are currently set for any "Tablespace Name" object, those thresholds can be viewed on the Metric Detail page for this metric.

To specify or change warning or critical threshold values for each "Tablespace Name" object, use the Edit Thresholds page.

Data Source

After checking for the largest chunk free space in the tablespace, this is the number of segments which cannot allocate an additional extent.

For additional information about the data source, refer to the problemTbsp.pl Perl script located in the sysman/admin/scripts directory.

User Action

Perform one of the following:

• Increase the size of the tablespace by enabling automatic extension for one of its existing data files, manually resizing one of its existing data files. or adding a new data file.

• If the tablespace is suffering from tablespace free space fragmentation problems, consider reorganizing the entire tablespace.

• Relocate segments to another tablespace thus increasing the free space in this tablespace.

4.52.1 All Sessions

This metric represents the number of users logged on at the sampling time.

Metric Summary

The following table shows how often the metric's value is collected.

Data Source

SELECT value 
  FROM v$sysstat 
  WHERE name = 'logons current'; 

User Action

No user action is necessary.

4.52.2 BG Checkpoints (per second)

This metric represents the BG checkpoints per second.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

4.52.3 Branch Node Splits (per second)

Number of times per second an index branch block was split because of the insertion of an additional value.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

branch node splits / time

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.52.4 Branch Node Splits (per transaction)

Number of times per transaction an index branch block was split because of the insertion of an additional value.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

branch node splits / transaction

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.52.5 Consistent Read Blocks Created (per second)

This metric represents the number of current blocks per second cloned to create consistent read (CR) blocks.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

CR blocks created / time

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.52.6 Consistent Read Blocks Created (per transaction)

This metric represents the number of current blocks per transaction cloned to create consistent read (CR) blocks.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

CR blocks created / transactions

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.52.7 Consistent Read Changes (per second)

This metric represents the number of times per second a user process has applied rollback entries to perform a consistent read on the block.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

consistent changes / time

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.52.8 Consistent Read Changes (per transaction)

This metric represents the number of times per transaction a user process has applied rollback entries to perform a consistent read on the block.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

consistent changes / transactions

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.52.9 Consistent Read Gets (per second)

This metric represents the number of times per second a consistent read was requested for a block.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

consistent gets / time

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.52.10 Consistent Read Gets (per transaction)

This metric represents the number of times per transaction a consistent read was requested for a block.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

consistent gets / transactions

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.52.11 Consistent Read Undo Records Applied (per second)

This metric represents the number of undo records applied for consistent read per second.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

current blocks converted for CR / time

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.52.12 Consistent Read Undo Records Applied (per transaction)

This metric represents the consistent read undo records applied per transaction.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.52.13 Cumulative Logons (per second)

This metric represents the number of logons per second during the sample period.

This test checks the number of logons that occurred per second during the sample period. If the value is greater than or equal to the threshold values specified by the threshold arguments, and the number of occurrences exceeds the value specified in the "Number of Occurrences" parameter, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

DeltaLogons / Seconds where:

• DeltaLogons: difference in 'select value from v$sysstat where name='logons cumulative'' between end and start of sample period

• Seconds: number of seconds in sample period

User Action

A high logon rate may indicate that an application is inefficiently accessing the database. Database logon's are a costly operation. If an application is performing a logon for every SQL access, that application will experience poor performance as well as affect the performance of other applications on the database. If there is a high logon rate try to identify the application that is performing the logons to determine if it could be redesigned such that session connections could be pooled, reused or shared.

4.52.14 Cumulative Logons (per transaction)

This metric represents the number of logons per transaction during the sample period.

The value of this statistic will be zero if there have not been any write or update transactions committed or rolled back during the last sample period. If the bulk of the activity to the database is read only, the corresponding "per second" metric of the same name will be a better indicator of current performance.

This test checks the number of logons that occurred per transaction. If the value is greater than or equal to the threshold values specified by the threshold arguments, and the number of occurrences exceeds the value specified in the "Number of Occurrences" parameter, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

DeltaLogons / Transactions where:

• DeltaLogons: difference in 'select value from v$sysstat where name='logons cumulative'' between end and start of sample period

• Transactions: number of transactions in sample period

User Action

A high logon rate may indicate that an application is inefficiently accessing the database. Database logon's are a costly operation. If an application is performing a logon for every SQL access, that application will experience poor performance as well as affect the performance of other applications on the database. If there is a high logon rate try to identify the application that is performing the logons to determine if it could be redesigned such that session connections could be pooled, reused or shared.

4.52.15 Database Block Changes (per second)

This metric represents the total number of changes per second that were part of an update or delete operation that were made to all blocks in the SGA.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

db block changes / time

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.52.16 Database Block Changes (per transaction)

This metric represents the total number of changes per transaction that were part of an update or delete operation that were made to all blocks in the SGA.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

db block changes / transactions

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.52.17 Database Block Gets (per second)

This metric represents the number of times per second a current block was requested.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

db block gets / time

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.52.18 Database Block Gets (per transaction)

This metric represents the number of times per transaction a current block was requested.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.

Data Source

db block gets / transactions

User Action

View the latest Automatic Database Diagnostic Monitor (ADDM) report. For a more detailed analysis, run ADDM from the Advisor Central link on the Database Home page.

4.52.19 DBWR Checkpoints (per second)

This metric represents the number of times, per second, during this sample period DBWn was asked to scan the cache and write all blocks marked for a checkpoint.

The database writer process (DBWn) writes the contents of buffers to datafiles. The DBWn processes are responsible for writing modified (dirty) buffers in the database buffer cache to disk.

When a buffer in the database buffer cache is modified, it is marked dirty. The primary job of the DBWn process is to keep the buffer cache clean by writing dirty buffers to disk. As user processes dirty buffers, the number of free buffers diminishes. If the number of free buffers drops too low, user processes that must read blocks from disk into the cache are not able to find free buffers. DBWn manages the buffer cache so that user processes can always find free buffers.

When the Oracle Server process cannot find a clean reusable buffer after scanning a threshold of buffers, it signals DBWn to write. When this request to make free buffers is received, DBWn writes the least recently used (LRU) buffers to disk. By writing the least recently used dirty buffers to disk, DBWn improves the performance of finding free buffers while keeping recently used buffers resident in memory. For example, blocks that are part of frequently accessed small tables or indexes are kept in the cache so that they do not need to be read in again from disk. The LRU algorithm keeps more frequently accessed blocks in the buffer cache so that when a buffer is written to disk, it is unlikely to contain data that may be useful soon.

Additionally, DBWn periodically writes buffers to advance the checkpoint that is the position in the redo log from which crash or instance recovery would need to begin.

This test checks the number of times DBWR was asked to advance the checkpoint. If the value is greater than or equal to the threshold values specified by the threshold arguments, and the number of occurrences exceeds the value specified in the "Number of Occurrences" parameter, then a warning or critical alert is generated.

Metric Summary

The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.