This chapter provides information about the Cluster Database (Oracle Real Application Clusters (RAC) database) metrics.
For each metric, it provides the following information:
Description
Metric table
The metric table can include some or all of the following: target version, default collection frequency, default warning threshold, default critical threshold, and alert text.
This metric category contains the metrics representing the use of the archive areas.
If the database is running in ARCHIVELOG mode, these metrics check for available redo log destinations. If the database is not running in ARCHIVELOG mode, these metrics fail to register. For each destination, this metric category returns the total, used, and free space.
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.
Note:
For databases that are configured to archive to the Fast Recovery Area, the Archive Area metrics (Archive Area Used(%), Archive Area Used (KB), Free Archive Area (KB), and Total Archive Area (KB)) are not applicable. Instead, use the Recovery Area Free Space(%) metric to monitor Fast Recovery Area usage. For more information, see Section 6.31.1, "Recovery Area Free Space (%)".Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
Not Available | Every 15 Minutes | 80 | Not Defined | %value%%% of archive area %archDir% is used. |
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.
There are two methods you can use to specify archive destinations. These destinations can be setup using Enterprise Manager. For each database target, you can drill-down to the database Availability tab, and access the Recovery Settings page.
The first method is to use the LOG_ARCHIVE_DEST_n parameter (where n is an integer from 1 to 10) to specify from one to ten 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.
This metric represents the total space used (in KB) on the device containing the archive destination directory.
Note:
For databases that are configured to archive to the Fast Recovery Area, the Archive Area metrics (Archive Area Used(%), Archive Area Used (KB), Free Archive Area (KB), and Total Archive Area (KB)) are not applicable. Instead, use the Recovery Area Free Space(%) metric to monitor Fast Recovery Area usage. For more information, see Section 6.31.1, "Recovery Area Free Space (%)".Target Version | Collection Frequency |
---|---|
Not Available | 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.
There are two methods you can use to specify archive destinations. These destinations can be setup using Enterprise Manager. For each database target, you can drill-down to the database Availability tab, and access the Recovery Settings page.
The first method is to use the LOG_ARCHIVE_DEST_n parameter (where n is an integer from 1 to 10) to specify from one to ten 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.
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, this metric fails to register.
Note:
For databases that are configured to archive to the Fast Recovery Area, the Archive Area metrics (Archive Area Used(%), Archive Area Used (KB), Free Archive Area (KB), and Total Archive Area (KB)) are not applicable. Instead, use the Recovery Area Free Space(%) metric to monitor Fast Recovery Area usage. For more information, see Section 6.31.1, "Recovery Area Free Space (%)".Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
Not Available | Every 15 Minutes | Not Defined | Not Defined | Archive area %archDir% has %value% free KB remaining. |
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.
There are two methods you can use to specify archive destinations. These destinations can be setup using Enterprise Manager. For each database target, you can drill-down to the database Availability tab, and access the Recovery Settings page.
The first method is to use the LOG_ARCHIVE_DEST_n parameter (where n is an integer from 1 to 10) to specify from one to ten 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.
This metric represents the total space (in KB) on the device containing the archive destination directory.
Note:
For databases that are configured to archive to the Fast Recovery Area, the Archive Area metrics (Archive Area Used(%), Archive Area Used (KB), Free Archive Area (KB), and Total Archive Area (KB)) are not applicable. Instead, use the Recovery Area Free Space(%) metric to monitor Fast Recovery Area usage. For more information, see Section 6.31.1, "Recovery Area Free Space (%)".Target Version | Collection Frequency |
---|---|
Not Available | 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 archive logs to tape and delete the archive logs.
If tape is not being used, back up the database and remove obsolete files. This also removes archive logs that are no longer needed based on the database retention policy.
If archivelog destination quota_size is being used, raise the quota_size.
The metrics in the Cluster Managed Database Services metric category provide information about the CPU load for the managed database services.
This metric provides the CPU load percentage for any cluster managed database service that exceeds the defined threshold in the last 5 minutes.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10g, 11g, 12c | Every 5 Minutes | Not Defined | Not Defined | CPU Load Percent %value% for service %name% exceeds the thresholds set. |
The metrics in the Data Guard metrics category check the status, data not received, and data not applied for the databases in the Data Guard configuration. The metric runs on the primary database and covers conditions for all databases in the Data Guard configuration, including the primary and all physical and logical standby databases. It is applicable to both broker and non-broker Data Guard configurations.
For non-broker configurations, the metric is limited to monitoring primary database redo transport destination errors (as reflected in the ERRORS column of v$archive_dest).
For broker configurations, the metric is based on the Data Guard broker health check, which covers a much broader range of issues.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10gR1 | Every 5 Minutes | Warning | Error | The Data Guard status of %dg_name% is %value%. |
Data Source
The following commands are the data sources for this metric:
Non-broker: v$archive_dest on primary database
Broker: Data Guard broker on primary database
User Action
Check the Edit Properties General page for the primary and standby databases for detailed information.
Examine the database alert logs and the Data Guard broker logs for additional information.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10gR1 | Every 5 Minutes | 1 | 3 | Standby database %dg_name% has not applied the last %value% received logs. |
Data Source
The following commands are the data sources for this metric:
Non-broker: v$archive_dest on primary database
Broker: Data Guard broker on primary database
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10gR1 | Every 5 Minutes | Not Defined | Not Defined | Standby database %dg_name% has not applied the last %value% megabytes of data received. |
Data Source
The following commands are the data sources for this metric:
Non-broker: v$archive_dest on primary database
Broker: Data Guard broker on primary database
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10gR1 | Every 5 Minutes | 1 | 3 | Standby database %dg_name% has not received the last %value% logs from the primary database. |
Data Source
The following commands are the data sources for this metric:
Non-broker: v$archive_dest on primary database
Broker: Data Guard broker on primary database
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10gR1 | Every 5 Minutes | Not Defined | Not Defined | Standby database %dg_name% has not received the last %value% megabytes of data from the primary database. |
Data Source
The following commands are the data sources for this metric:
Non-broker: v$archive_dest on primary database
Broker: Data Guard broker on primary database
The metrics in the Data Guard metrics category check the status, data not received, and data not applied for the databases in the Data Guard configuration. The metric runs on the primary database and covers conditions for all databases in the Data Guard configuration, including the primary and all physical and logical standby databases. It is applicable to both broker and non-broker Data Guard configurations.
For non-broker configurations, the metric is limited to monitoring primary database redo transport destination errors (as reflected in the ERRORS column of v$archive_dest).
For broker configurations, the metric is based on the Data Guard broker health check, which covers a much broader range of issues.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
9iR2 | Every 5 Minutes | Warning | Error | The Data Guard status of %dg_name% is %value%. |
Data Source
The following commands are the data sources for this metric:
Non-broker: v$archive_dest on primary database
Broker: Data Guard broker on primary database
User Action
Check the Edit Properties General page for the primary and standby databases for detailed information.
Examine the database alert logs and the Data Guard broker logs for additional information.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
9iR2 | Every 5 Minutes | 1 | 3 | Standby database %dg_name% has not applied the last %value% received logs. |
Data Source
The following commands are the data sources for this metric:
Non-broker: v$archive_dest on primary database
Broker: Data Guard broker on primary database
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
9iR2 | Every 5 Minutes | 1 | 3 | Standby database %dg_name% has not received the last %value% logs from the primary database. |
Data Source
The following commands are the data sources for this metric:
Non-broker: v$archive_dest on primary database
Broker: Data Guard broker on primary database
The metrics in this category are database-level metrics. For cluster databases, these metrics are monitored at the cluster database target level and not by member instances.
This metric provides the time at which a fast-start failover occurred.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10gR2 | Every 5 Minutes | Not Defined | 1 | A fast-start failover occurred at %dg_fs_time%. |
The metrics in the Data Guard Fast-Start Failover Observer Status metric category provide information about the status of the observer process.
The observer process continuously monitors the primary and target standby databases and evaluates whether failover is necessary, and then initiates a fast-start failover when conditions warrant.
The metrics in the Data Guard Fast-Start Failover Observer Status - 10.2 Database metric category provide information about the status of the observer process for Oracle Database 10gR2 only.
The observer process continuously monitors the primary and target standby databases and evaluates whether failover is necessary, and then initiates a fast-start failover when conditions warrant.
This metric displays the status of the observer process for Oracle Database 10gR2.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10gR2 | Every 5 Minutes | Not Defined | Error | The Data Guard fast-start failover observer status is %value%. |
This metric category provides the Data Guard Performance metric.
This metric displays (in seconds) how far the standby is behind the primary.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 5 Minutes | Not Defined | Not Defined | The standby database is approximately %value% seconds behind the primary database. |
Data Source
The data source for this metric is the following command:
v$dataguard_stats('apply lag')
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
This metric shows the approximate number of seconds required to failover to this standby database. This accounts for the startup time, if necessary, plus the remaining time required to apply all the available redo on the standby. If a bounce is not required, it is only the remaining apply time.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 5 Minutes | Not Defined | Not Defined | The estimated time to failover is approximately %value% seconds. |
Data Source
The data source for this metric is the following command:
v$dataguard_stats ('estimated startup time','apply finish time','standby has been open')
Displays the Redo Apply Rate in KB/second on this standby.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 5 Minutes | Not Defined | Not Defined | The estimated time to failover is approximately %value% seconds. |
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10gR2, 11g, 12c | Every 5 Minutes | Not Defined | Not Defined | The redo generation rate is %value% KB/sec. |
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.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 5 Minutes | Not Defined | Not Defined | There are approximately %value% seconds of redo not yet available on this standby database. |
Data Source
The data source for this metric is the following command:
v$dataguard_stats('transport lag')
This metric category includes the Data Guard Performance metrics for Oracle Database 11g and Oracle Database 10gR2.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
This metric displays (in seconds) how far the standby is behind the primary.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10gR2, 11gR1 | Every 5 Minutes | Not Defined | Not Defined | The standby database is approximately %value% seconds behind the primary database. |
Data Source
The data source for this metric is the following command:
v$dataguard_stats('apply lag')
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
This metric shows the approximate number of seconds required to failover to this standby database. This accounts for the startup time, if necessary, plus the remaining time required to apply all the available redo on the standby. If a bounce is not required, it is only the remaining apply time.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10gR2, 11gR1 | Every 5 Minutes | Not Defined | Not Defined | The estimated time to failover is approximately %value% seconds. |
Data Source
The data source for this metric is the following command:
v$dataguard_stats ('estimated startup time','apply finish time','standby has been open')
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10gR2, 11gR1 | Every 5 Minutes | Not Defined | Not Defined | There are approximately %value% seconds of redo not yet available on this standby database. |
Data Source
The data source for this metric is the following command:
v$dataguard_stats('transport lag')
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
This metric displays the Redo Apply Rate in KB/second on this standby.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10gR2, 11gR1 | Every 5 Minutes | Not Defined | Not Defined | The redo apply rate is %value% KB/sec |
The metrics in the Data Guard metrics category check the status, data not received, and data not applied for the databases in the Data Guard configuration.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10gR2, 11g, 12c | Every 5 Minutes | Warning | Error | The Data Guard status of %dg_name% is %value%. |
Data Source
Check the Edit Properties General page for the primary and standby databases for detailed information.
Examine the database alert logs and the Data Guard broker logs for additional information.
This metric category contains the metrics that monitor the number of active instances of a cluster database.
This metric monitors how many instances are in an open state.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
Not Available | Every 5 Minutes | Not Defined | Not Defined | %value% instance(s) out of %total_count% are up. |
This metric category contains the metrics that represent the health of database jobs registered through the DBMS_SCHEDULER interface.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
Not Available | Every 30 Minutes | 0 | Not Defined | %value% job(s) are broken. |
Data Source
The data source for this metric is the following command:
SELECT COUNT(*) FROM dba_jobs WHERE broken < > '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_SCHEDULER.RUN.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
Not Available | Every 30 Minutes | 0 | Not Defined | %value% job(s) have failed. |
Data Source
The data source for this metric is the following command:
SELECT COUNT(*) FROM dba_jobs WHERE NVL(failures, 0) < > 0"
User Action
Check the ALERT log and trace files for error information. Correct the problem that is preventing the job from running.
This metric category contains the metrics that approximate the percentage of time spent waiting by user sessions across instances for the cluster database. This approximation takes system-wide totals and discounts the effects of sessions belonging to background processes.
This metric represents the active sessions using CPU.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
Target Version | Collection Frequency |
---|---|
10g, 11g, 12c | Every 15 Minutes |
This database-level metric represents the active sessions waiting for I/O. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
Target Version | Collection Frequency |
---|---|
10g, 11g, 12c | Every 15 Minutes |
This database-level metric represents all the waits that are neither idle nor user I/O. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
Target Version | Collection Frequency |
---|---|
10g, 11g, 12c | Every 15 Minutes |
This metric represents the average database CPU across instances as a percentage.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
This metric represents the percentage of CPU being used across hosts.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
Target Version | Collection Frequency |
---|---|
10g, 11g, 12c | Every 15 Minutes |
This metric reports the sum of the current CPU load for all cluster database hosts.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
This metric represents the total CPU count across all the cluster database hosts.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
Target Version | Collection Frequency |
---|---|
10g, 11g, 12c | Every 15 Minutes |
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
This metric represents the percentage of time spent waiting, database-wide, for resources or objects during this sample period.
This test checks the percentage time spent waiting, database-wide, for resources or objects during this sample period. If the % Wait Time 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.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10g, 11g, 12c | Every 15 Minutes | Not Defined | Not Defined | Generated By Database Server |
Data Source
The data source for this metric is the following formula where:
DeltaTotalWait: Difference of 'sum of time waited for all wait events in v$system_event' between sample end and start.
DeltaCpuTime: Difference of 'select value from v$sysstat where name='CPU used by this session' between sample end and start.
DeltaTotalWait / (DeltaTotalWait + DeltaCpuTime)
User Action
Investigate further into which specific wait events are responsible for the bulk of the wait time. Individual wait events may identify unique problems within the database. Diagnosis will be tailored where appropriate through drilldowns specific to individual wait events.
The metrics in the Database Vault Attempted Violations - Command Rules metric category provides information about the attempted Database Vault command rule violations.
This metric raises an alert, which helps the Oracle Database Vault security analyst to monitor violation attempts on the Database Vault database. This user can select the command rules to be affected by the alert and filter these command rules based on the different types of attempts by using error codes.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
9iR2,10g, 11g, 12c | Every Hour | Not Defined | Not Defined | %ACTION_OBJECT_NAME% got violated at %VIOLATIONTIMESTAMP% |
The metrics in the Database Vault Attempted Violations - Realms metric category provide information about realm violations (for example, when an unauthorized user tries to modify an object that is protected by the realm).
This metric raises an alert, which helps the Oracle Database Vault security analyst to monitor violation attempts on the Database Vault database. This user can select the realms to be affected by the alert and filter these realms based on the different types of attempts by using error codes.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
9iR2,10g, 11g, 12c | Every Hour | Not Defined | Not Defined | %ACTION_OBJECT_NAME% got violated at %VIOLATIONTIMESTAMP%. |
The metrics in the Database Vault Configuration Issues - Realms metric category provide information about configuration issues in the realm. The Oracle Database Vault realm protects configuration information in the Oracle Database Vault.
This metric tracks and raises an alert if users misconfigure realms.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
9iR2,10g, 11g, 12c | Every Hour | Not Defined | 0 | %ACTION_OBJECT_NAME% has configuration issues. |
The metrics in the Database Vault Configuration Issues - Command Rules metric category provide information about configuration issues in the command rules. A command rule is a rule that you create to protect SELECT, ALTER SYSTEM, database definition language (DDL), and data manipulation language (DML) statements that affect one or more database objects
This metric tracks and raises an alert if users misconfigure command rules.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
9iR2,10g, 11g, 12c | Every Hour | Not Defined | 0 | %ACTION_OBJECT_NAME% has configuration issues. |
The metrics in the Database Vault Policy Changes metric category provide information about any changes to a Database Vault Policy.
This metric raises an alert on any change to any Database Vault policy, such as policies for realms and command rules.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
9iR2,10g, 11g, 12c | Every Hour | Not Defined | 0 | %ACTION_OBJECT_NAME% has configuration issues. |
This metric category contains the metrics associated with this distributed database's deferred transactions.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
Not Available | Every 5 Minutes | 100 | Not Defined | Number of deferred transactions is %value%. |
Data Source
The data source for this metric is the following command:
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 that the DEFCALLEST and DEFTRANDEST views are the definitions from the CATREPC.SQL and not those from CATDEFER.SQL.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
Not Available | Every 5 Minutes | 0 | Not Defined | Number of deferred transactions with errors is %value%. |
Data Source
The data source for this metric is the following command:
SELECT count(*) FROM sys.deferror
User Action
An error in applying a deferred transaction may result from a database problem, such as a lack of available space in the table 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.
This metric category provides information about any Exadata module version errors.
This metric tracks and raises an alert when a defined number of Exadata module version errors occur.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 24 Hours | 0 | Not Defined | %errorCode% occurrences of %errorCount%. |
The metric in this metric category 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.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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. Because it is important to know every time a significant number of failed logins occurs on a system, this metric will generate a new alert for any ten-minute interval where the thresholds are crossed. You can manually clear these alerts. They will not automatically clear after the next collection.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
Not Available | Every 30 Minutes | 150 | 300 | Number of failed login attempts exceeds threshold value. |
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
The metrics in the Fast Recovery metrics category relate to the fast recovery area.
Formerly referred to as flash recovery area, this metric returns an optional disk location that you can use to store recovery-related files such as control file and online redo log copies, archived redo log files, flashback logs, and RMAN backups.
Oracle Database and RMAN manage the files in the fast recovery area automatically. You can specify the disk quota, which is the maximum size of the fast recovery area.
Target Version | Collection Frequency |
---|---|
10g, 11g | Every 15 Minutes |
Data Source
The data source for this metric is the following command:
SELECT value FROM v$parameter WHERE name='db_recovery_file_dest';
User Action
No user action is required.
This metric returns the Fast Recovery Area Size.
Target Version | Collection Frequency |
---|---|
10g, 11g | Every 15 Minutes |
Data Source
The data source for this metric is the following command:
SELECT value INTO 1_fast_recovery_size FROM v$parameter WHERE name='db_recovery_file_dest_size';
User Action
No user action is required.
This metric returns whether or not flashback logging is enabled - YES, NO, or RESTORE POINT ONLY. For the RESTORE POINT ONLY option, flashback is ON but you can only flashback to guaranteed restore points.
Target Version | Collection Frequency |
---|---|
10g, 11g | Every 15 Minutes |
Data Source
The data source for this metric is the following command:
SELECT flashback_on FROM v$database;
User Action
No user action is required.
This metric returns the log mode of the database - ARCHIVELOG or NOARCHIVELOG.
Target Version | Collection Frequency |
---|---|
10g, 11g | Every 15 Minutes |
Data Source
The data source for this metric is the following command:
SELECT log_mode FROM v$database;
User Action
No user action is required.
This metric represents the percentage of space non-reclaimable (spaced used minus space reclaimable) in the fast recovery area.
Target Version | Collection Frequency |
---|---|
10g, 11g | Every 15 Minutes |
Data Source
The data source for this metric is one of the following commands:
Non-reclaimable = space used - space reclaimable Space Used: SELECT SUM(PERCENT_SPACE_USED FROM v$fast_recovery_area_usage; Space Reclaimable: SELECT SUM(PERCENT_SPACE_RECLAIMABLE) FROM v$fast_recovery_area_usage;
User Action
No user action is required.
This metric returns the oldest point-in-time to which you can flashback your database.
Target Version | Collection Frequency |
---|---|
10g, 11g | Every 15 Minutes |
Data Source
The data source for this metric is the following command:
SELECT to_char(oldest_flashback_time, 'YYYY-MM-DD HH24:MI:SS') FROM v$flashback_database_log;
User Action
No user action is required.
This metric represents the percentage of space reclaimable in the fast recovery area.
Target Version | Collection Frequency |
---|---|
10g, 11g | Every 15 Minutes |
Data Source
The data source for this metric is the following command:
Space Reclaimable: SELECT SUM(PERCENT_SPACE_RECLAIMABLE) FROM v$fast_recovery_area_usage;
User Action
No user action is required.
This metric represents the percentage of space usable in the fast recovery area. The space usable is composed of the space that is free in addition to the space that is reclaimable.
Target Version | Collection Frequency |
---|---|
10g, 11g | Every 15 Minutes |
Data Source
The data source for this metric is the following command:
SELECT (CASE WHEN PERCENT_USED > 100 THEN 0 ELSE (100-PERCENT_USED) END) PERCENT_FREE FROM (SELECT (SUM(PERCENT_SPACE_USED)-SUM(PERCENT_SPACE_RECLAIMABLE)) PERCENT_USED FROM V$FAST_RECOVERY_AREA_USAGE);
User Action
No user action is required.
This metric category contains the metrics associated with invalid objects.
This metric represents the total invalid object count.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
All Versions | Every 24 Hours | Not Defined | Not Defined | %value% object(s) are invalid in the database. |
This metric category contains the metrics that represent the number of invalid objects in each schema.
This metric represents the invalid object count by owner.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
All Versions | Every 24 Hours | Not Defined | %value% object(s) are invalid in the %owner% schema. |
Data Source
The data source for each metric index is the following command:
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.
The metrics in the Messages Per Buffered Queue metrics category monitor the age and state of the first (top of the queue) message for each buffered queue in the database except for the system queues. Queues that are in the schema of SYS, SYSTEM, DBSNMP, and SYSMAN are defined as system level queues.
This metric provides the average age (in seconds) of the messages in the buffered queue for all nonsystem queues in the database.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Average age of messages in %schema%.%queue_name% queue is %value% seconds. |
This metric gives the age (in seconds) of the first message in the buffered queue for all non-system queues in the database.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Age of first message in %schema%.%queue_name% buffered queue is %value% seconds. |
Multiple Thresholds
For this metric you can set different warning and critical threshold values for each unique combination of Schema Name and Queue Name objects.
If warning or critical threshold values are currently set for any unique combination of Schema Name and Queue Name objects, those thresholds can be viewed on the Metric Detail page for this metric.
To specify or change warning or critical threshold values for each unique combination of Schema Name and Queue Name objects, use the Edit Thresholds page.
Data Source
This metric is calculated by finding the age of the first message in all the subscribers of the queue and then the oldest amongst all is taken.
The following views and tables are used for the calculation:
<SCHEMA>.AQ$<QUEUE_TABLE>
v$buffered_queues
User Action
When using buffered queues for storing and propagating messages, monitor this metric to get the age of first message in the queue.
This metric gives the messages processed percentage per minute per buffered queue in the last collection interval of the metric.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Messages processed for queue %schema%.%queue_name% is %value% percent. |
Multiple Thresholds
For this metric you can set different warning and critical threshold values for each unique combination of Schema Name and Queue Name objects.
If warning or critical threshold values are currently set for any unique combination of Schema Name and Queue Name objects, those thresholds can be viewed on the Metric Detail page for this metric.
To specify or change warning or critical threshold values for each unique combination of Schema Name and Queue Name objects, use the Edit Thresholds page.
Data Source
This is calculated as the percent of total number of messages processed per minute and total number of messages received per minute in the last collection interval per buffered queue.
User Action
When using queues for storing/propagating messages, monitor this metric to get the messages processed percent (or throughput) per minute in the last collection interval for the queue.
This metric gives the messages processed percentage per minute in the last interval per buffered queue in the last collection interval of the metric.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Messages processed per minute in the last interval for queue %schema%.%queue_name% is %value% . |
This metric displays the current number of overflow messages spilled to disk from the buffered queue.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Current number of overflow messages spilled to disk from the buffered queue %schema%.%queue_name% is %value% |
This metric gives the total number of messages processed per minute per buffered queue in the last collection interval of the metric.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Total messages processed per minute in the last interval for queue %schema%.%queue_name% is %value% . |
This metric gives the total number of messages received or enqueued into the buffered queue per minute in the last collection interval of the metric.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Total messages received per minute in the last interval for queue %schema%.%queue_name% is %value% . |
This metric category monitors the messages for buffered queues per subscriber in the database.
This metric display's the average age of messages in the buffered queue per queue in seconds.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Average age of messages for the subscriber %subs_name% %subs_address% in %schema%.%queue_name% queue is %value% seconds. |
This metric displays the age of the first message in the buffered queue per queue per subscriber in seconds.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Age of first message for subscriber %subs_name% %subs_address% in %schema%.%queue_name% queue is %value% seconds. |
This metric gives the total number of messages processed per minute per buffered queue subscriber in the last collection interval of the metric.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Messages processed per minute in the last interval for the subscriber %subs_name% %subs_address% in %schema%.%queue_name% queue is %value% |
This metric gives the messages processed percentage for the buffered queue per subscriber. Messages processed percent is calculated as the percent of the total number messages processed or dequeued to the total number of messages received or enqueued.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Messages processed for the subscriber %subs_name% %subs_address% in %schema%.%queue_name% queue is %value% percent. |
This metric gives the total number of messages processed per minute per buffered queue subscriber in the last collection interval of the metric.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Total messages processed per minute in the last interval for the subscriber %subs_name% %subs_address% in %schema%.%queue_name% queue is %value% . |
This metric gives the total number of messages received or enqueued into the queue per subscriber per minute in the last collection interval of the metric.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Total messages received per minute in the last interval for the subscriber %subs_name% %subs_address% in %schema%.%queue_name% queue is %value% . |
The metrics in the Messages Per Persistent Queue metrics category monitor the age and state of the first (top of the queue) message for each persistent queue in the database except for the system queues. Queues that are in the schema of SYS, SYSTEM, DBSNMP, and SYSMAN are defined as system level queues.
This metric displays the average age of messages in the persistent queue per queue in seconds.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Average age of messages in %schema%.%queue_name% queue is %value% seconds. |
This metric gives the age (in seconds) of the first message in the persistent queue for all non-system queues in the database.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Age of first message in %schema%.%queue_name% queue is %value% seconds. |
Multiple Thresholds
For this metric you can set different warning and critical threshold values for each unique combination of Schema Name and Queue Name objects.
If warning or critical threshold values are currently set for any unique combination of Schema Name and Queue Name objects, those thresholds can be viewed on the Metric Detail page for this metric.
To specify or change warning or critical threshold values for each unique combination of Schema Name and Queue Name objects, use the Edit Thresholds page.
Data Source
This metric is calculated by finding the age of the first message in all the subscribers of the queue and then the oldest amongst all is taken.
The following views/tables are used for the calculation:
<SCHEMA>.AQ$_<QUEUE_TABLE>_S
<SCHEMA>.AQ$_<QUEUE_TABLE>_I
<SCHEMA>.AQ$<QUEUE_TABLE>
User Action
When using persistent queues for storing and propagating messages, monitor this metric to get the age of first message in the queue.
This metric gives the messages processed percentage for the persistent queue. Messages processed percent is calculated as the percent of the total number messages processed or dequeued to the total number of messages received or enqueued.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Messages processed for queue %schema%.%queue_name% is %value% percent. |
This metric gives the messages processed percentage per minute per persistent queue in the last collection interval of the metric.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Messages processed per minute in the last interval for queue %schema%.%queue_name% is %value% |
This metric gives the total number of messages processed per minute per persistent queue in the last collection interval of the metric.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Total messages processed per minute in the last interval for queue %schema%.%queue_name% is %value% . |
This metric gives the total number of messages received or enqueued into the queue per minute in the last collection interval of the metric.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Total messages received per minute in the last interval for queue %schema%.%queue_name% is %value% . |
The metrics in the Messages Per Persistent Queue Per Subscriber metrics category monitor the age and state of the first (top of the queue) message for each persistent queue per queue subscriber in the database except for the system queues. Queues that are in the schema of SYS, SYSTEM, DBSNMP, and SYSMAN are defined as system level queues.
This metric display's the average age of messages in the persistent queue per queue in seconds.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Average age of messages for the subscriber %subs_name% %subs_address% in %schema%.%queue_name% queue is %value% seconds. |
This metric gives the age (in seconds) of the first message in the persistent queue per subscriber for all non-system queues in the database.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Age of first message for subscriber %subs_name% %subs_address% in %schema%.%queue_name% queue is %value% seconds. |
This metric gives the messages processed percentage per minute per persistent queue subscriber in the last collection interval of the metric.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Messages processed per minute in the last interval for the subscriber %subs_name% %subs_address% in %schema%.%queue_name% queue is %value% . |
This metric gives the messages processed percentage for the persistent queue per subscriber. Messages processed percent is calculated as the percent of the total number messages processed or dequeued to the total number of messages received or enqueued.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Messages processed for the subscriber %subs_name% %subs_address% in %schema%.%queue_name% queue is %value% percent. |
This metric gives the messages processed percentage per minute per persistent queue subscriber in the last collection interval of the metric.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Messages processed per minute in the last interval for the subscriber %subs_name% %subs_address% in %schema%.%queue_name% queue is %value% . |
This metric gives the total number of messages received or enqueued into the queue per subscriber per minute in the last collection interval of the metric.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Total messages received per minute in the last interval for the subscriber %subs_name% %subs_address% in %schema%.%queue_name% queue is %value% . |
Oracle Database Quality of Service (QoS) Management is an automated, policy-based product that monitors the workload requests for an entire system.
For more information, see Oracle Database Quality of Service Management User's Guide.
This metric tracks the negative PSM duration and raises an alert when it exceeds its threshold.
Performance Satisfaction Metric (PSM) is a normalized numeric value that indicates how well a particular Performance Objective is being met, and which enables Oracle Database QoS Management to compare the performance of the system for widely differing Performance Objectives.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 5 Minutes | Not Defined | Not Defined | Negative PSM Duration value %value% for Performance Class %PC% has crossed the threshold. |
This metric category contains the metrics representing database recovery.
This metric represents the count of corrupt data blocks.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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%.
Data Source
The data source for this metric is the following command:
SELECT count(unique(file#)) FROM v$database_block_corruption;
User Action
Perform a database recovery.
This metric represents the count of missing media files.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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%.
Data Source
This metric is calculated with the following command:
SELECT count(file#) FROM v$datafile_header WHERE recover ='YES' OR error is not null;
User Action
You should perform a database recovery.
This metric category contains the recovery area metrics.
Use the Recovery Area Free Space (%) metric to monitor Fast Recovery Area usage. This metric represents the recovery area free space as a percentage. It is a database-level metric that is evaluated by the database server every 15 minutes or during a file creation, whichever occurs first. The metric data is also printed in the alert log. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.The Critical Threshold is set for < 3% and the Warning Threshold is set for < 15%. You cannot customize these thresholds. An alert is returned the first time the alert occurs, and the alert is not cleared until the available space rises above 15%.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10g, 11g, 12c | Every 15 Minutes or during file creation, whichever occurs first | 15% (Cannot be changed) | 3% (Cannot be changed) | db_recovery_file_dest_size of N
bytes is N% used, and has N remaining bytes available. |
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.
This metric category provides information about the Systems Change Number (SCN) in the database environment and reports on the health of the SCN growth in the database.
This metric category provides information about the maximum value of the SCN.
This metric displays the maximum SCN jump in one second over the previous 24 hours.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10g, 11g, 12c | Every Hour | Not Defined | Not Defined | The maximum SCN jump in one second (last 24 hours) is %scn_max_jump%. |
This metric category contains metrics related to the Automatic Segment Advisor job.
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.
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.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
This metric category contains the metrics that represent the number of resumable sessions that are suspended due to a correctable error.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
This metric represents the session suspended by a data object limitation.
Target Version | Collection Frequency |
---|---|
10g, 11g, 12c | Every 5 Minutes |
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.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
This metric represents the session suspended by a quota limitation.
Target Version | Collection Frequency |
---|---|
10g, 11g, 12c | Every 5 Minutes |
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.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
This metric represents the session suspended by a rollback segment limitation.
Target Version | Collection Frequency |
---|---|
10g, 11g, 12c | Every 5 Minutes |
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.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
This metric represents the session suspended by a tablespace limitation.
Target Version | Collection Frequency |
---|---|
10g, 11g, 12c | Every 5 Minutes |
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.
This metric category contains the snapshot too old metrics.
This database-level metric represents snapshots too old because of the rollback segment limit. This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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.
This database-level metric represents snapshots too old because of the tablespace limit. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
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.
This metric category monitors the space usage of buffered queues with respect to the streams pool size.
This metric display's the size of buffered queue, which is the total number of Mega bytes allocated for all messages and metadata.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Size of buffered queue %schema%.%queue_name% is %value% MB. |
Multiple Thresholds
For this metric you can set different warning and critical threshold values for each unique combination of Schema Name and Queue Name objects.
If warning or critical threshold values are currently set for any unique combination of Schema Name and Queue Name objects, those thresholds can be viewed on the Metric Detail page for this metric.
To specify or change warning or critical threshold values for each unique combination of Schema Name and Queue Name objects, use the Edit Thresholds page.
Data Source
The source of this metric is the INSTANCE_NAME column from GV$INSTANCE view.
User Action
When using queues for storing or propagating messages, monitor this metric to get the instance in which the buffered queue is available.
This metric gives the space usage percentage of buffered queue with respect to streams pool size per buffered queue.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Buffered queue %schema%.%queue_name% has consumed %value% percent of streams pool size. |
Multiple Thresholds
For this metric you can set different warning and critical threshold values for each unique combination of Schema Name and Queue Name objects.
If warning or critical threshold values are currently set for any unique combination of Schema Name and Queue Name objects, those thresholds can be viewed on the Metric Detail page for this metric.
To specify or change warning or critical threshold values for each unique combination of Schema Name and Queue Name objects, use the Edit Thresholds page.
Data Source
The source of this metric is the QUEUE_SIZE AND CURRENT_SIZE columns from GV$BUFFERED_QUEUES and GV$SGA_DYNAMIC_COMPONENTS views.
User Action
When using buffered queues for storing or propagating messages, monitor this metric to get the space usage percentage of buffered queue with respect to the allocated streams pool size.
The metrics in the Streams Apply Queue - Buffered metrics category show the current total number of messages in a buffered queue to be dequeued by each apply process and the total number of messages to be dequeued by each apply process that have spilled from memory into the persistent queue table.
This metric usually indicates that transactions are staying longer in memory.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
11gR2, 12c | Every 30 Minutes | Not Defined | Not Defined | Spilled messages for Apply process [%APPLY_NAME%] queue is %value% percent. |
Multiple Thresholds
For this metric you can set different warning and critical threshold values for each Apply Name object.
If warning or critical threshold values are currently set for any Apply 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 Apply Name object, use the Edit Thresholds page.
Data Source
The source for this metric is the target database in the gv$buffered_queues and gv$buffered_subscribers tables.
User Action
Either increase Streams Pool size and /or increase Apply Parallelism to speed up Apply processing.
The metrics in the Streams Apply Queue - Persistent metrics category show the number of messages in a persistent queue in READY state and WAITING state for each apply process.
This metric shows the percentage of messages in a wait state.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
9iR2, 10g, 11g, 12c | Every 30 Minutes | Not Defined | Not Defined | Messages waiting for Apply process [%APPLY_NAME%] queue is %value% percent. |
Multiple Thresholds
For this metric you can set different warning and critical threshold values for each unique combination of Apply Name and Messages Delivery Mode objects.
If warning or critical threshold values are currently set for any unique combination of Apply Name and Messages Delivery Mode objects, those thresholds can be viewed on the Metric Detail page for this metric.
To specify or change warning or critical threshold values for each unique combination of Apply Name and Messages Delivery Mode objects, use the Edit Thresholds page.
Data Source
The data source for this metric is Target Database and Apply Queue.
User Action
No user action is required.
The reader server for an apply process dequeues messages from the queue. The reader server 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.
The metrics in this metric category show the total number of messages dequeued by the reader server for the apply process since the last time the apply process was started.
The reader server for an apply process dequeues messages from the queue. The reader server 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 rate at which message are getting spilled (per second) by the reader server for the apply process since the last time the apply process was started.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
9iR2, 10g, 11g, 12c | Every 30 Minutes | Not Defined | Not Defined | Total number of spilled messages for Apply Process [%APPLY_NAME%] is %value% . |
Multiple Thresholds
For this metric you can set different warning and critical threshold values for each Apply Name object.
If warning or critical threshold values are currently set for any Apply 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 Apply Name object, use the Edit Thresholds page.
Data Source
For this metric, the data source is Target database, gv$streams_apply_reader view.
User Action
No user action is required.
The metrics in this metric category show the current total number of messages in a buffered queue that were enqueued by each capture process and the total number of messages enqueued by each capture process that have spilled from memory into the queue spill table.
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.
Queue spill indicates the messages are staying in memory longer. It can also indicate that the Propagation or Apply Process is slow to consume the enqueued messages.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10g, 11g, 12c | Every 30 Minutes | Not Defined | Not Defined | Spilled messages for Capture process %CAPTURE_NAME% queue is %value% percent. |
Multiple Thresholds
For this metric you can set different warning and critical threshold values for each Capture Name object. If warning or critical threshold values are currently set for any Capture 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 Capture Name object, use the Edit Thresholds page.
Data Source
The source of this metric is the target database in the gv$buffered_queues table view.
User Action
Increase Streams Pool Size to avoid queue spills.
The metrics in the Streams Latency and Throughput metrics category collect information about latency and throughput for each capture, propagation and apply component in the database. Latency and throughput are important indicators for the overall performance of the streams path.
High Latency indicates that the components are slow.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10gR2, 11g, 12c | Every 30 Minutes | Not Defined | Not Defined | Latency for Streams %streams_process_type% Process %streams_process_name% is %value% seconds. |
Multiple Thresholds
For this metric you can set different warning and critical threshold values for each unique combination of Streams Process Name and Streams Process Type objects.
If warning or critical threshold values are currently set for any unique combination of Streams Process Name and Streams Process Type objects, those thresholds can be viewed on the Metric Detail page for this metric.
To specify or change warning or critical threshold values for each unique combination of Streams Process Name and Streams Process Type objects, use the Edit Thresholds page.
Data Source
The data source for this metric is the target database in the gv$streams_capture, gv$propagation_sender, and gv$streams_apply_server views.
User Action
Identify and correct the least performing component in the streams configuration.
This metric collects information about throughput for each capture, propagation and apply component in the database.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10gR2, 11g, 12c | Every 30 Minutes | Not Defined | Not Defined | Throughput for Streams %streams_process_type% Process %streams_process_name% is %value% messages/sec. |
Multiple Thresholds
For this metric you can set different warning and critical threshold values for each unique combination of Streams Process Name and Streams Process Type objects.
If warning or critical threshold values are currently set for any unique combination of Streams Process Name and Streams Process Type objects, those thresholds can be viewed on the Metric Detail page for this metric.
To specify or change warning or critical threshold values for each unique combination of Streams Process Name and Streams Process Type objects, use the Edit Thresholds page.
Data Source
Not available.
User Action
The required actions are specific to your site.
The metrics in this metric category show the total number of Streams capture processes, propagations, and apply processes at the local database. This metric also shows the number of capture processes, propagations, and apply processes that have encountered errors.
This metric shows the number of apply processes that have encountered errors at the local database.
Target Version | Collection Frequency |
---|---|
10g, 11g, 12c | 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.
This metric shows the number of capture processes that have encountered errors at the local database.
Target Version | Collection Frequency |
---|---|
10g, 11g, 12c | 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.
This metric shows the number of apply processes at the local database.
Target Version | Collection Frequency |
---|---|
10g, 11g, 12c | 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.
This metric shows the number of capture processes at the local database.
Target Version | Collection Frequency |
---|---|
10g, 11g, 12c | 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.
This metric shows the number of propagations at the local database.
Target Version | Collection Frequency |
---|---|
10g, 11g, 12c | 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.
This metric shows the number of propagations that have encountered errors at the local database.
Target Version | Collection Frequency |
---|---|
10g, 11g, 12c | 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.
The metrics in this metric category collect the number of messages in Ready and Waiting state for each Propagation process.
This metric collects the number of messages in Ready state for each Propagation process.
Target Version | Collection Frequency |
---|---|
9iR2, 10g, 11g, 12c | Every 30 Minutes |
Data Source
The source of the data for this metric is the target database in the source and destination queues.
User Action
No user action is required.
The metrics in this metric category contain the metrics that represent the number of resumable sessions that are suspended due to a correctable error.
This metric represents the number of resumable sessions currently suspended in the database.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
9i | Every 5 Minutes | 0 | Not Defined | %value% session(s) are suspended. |
Data Source
This metric is calculated with the following command:
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 method to correct each error depends on the nature of the error.
The metrics in this metric category check the amount of space used and the amount of space allocated to each tablespace. The used space can then be compared to the allocated space to determine how much space is unused in the tablespace. This metric is intended for reporting, rather than alerts. Historical views of unused allocated free space can help DBAs to correctly size their tablespaces, eliminating wasted space.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
The allocated space of a tablespace is the sum of the current size of its data files. 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, the allocated free space is not being used.
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 a historical view of the amount of space being used and unused by each tablespace.
Data Source
Tablespace Allocated Space (MB) is calculated by looping though the tablespace�s data files and totalling the size of the data files.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
The allocated space of a tablespace is the sum of the current size of its data files. 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 a historical view of the amount of space being used and unused by each tablespace.
Data Source
Tablespace Used Space (MB) is derived from Tablespace Allocated Space (MB)� Tablespace Allocated Free Space (MB) where:
Tablespace Allocated Space (MB) is calculated by looping through the tablespace�s data files and totaling the size of the data files.
Tablespace Allocated Free Space (MB) is calculated by looping through the tablespace�s data files and totaling the size of the free space in each data file.
The metrics in this metric category check for the amount of space used by each tablespace. The used space is then compared to the available free space to determine tablespace fullness. The available free space accounts for the maximum data file size as well as available disk space. This means that a tablespace will not be flagged as full if data files can extend and there is enough disk space available for them to extend.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
As segments within a tablespace grow, the available free space decreases. If there is no longer any available free space, meaning data files reached 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.
If the version of the monitored database target is Oracle Database 10g Release 1 or later and the tablespace uses Local Extent Management, then the Oracle Database Server evaluates this metric internally every 10 minutes. Alternatively, if the version of the monitored Database target is Oracle 9i or earlier, or the tablespace uses Dictionary Extent Management, then the Oracle Management Agent tests the value of this metric every 30 minutes.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
8i, 9i | Every 30 Minutes | Not Defined | Not Defined | Tablespace [%name%] has [%value% mbytes] free |
10g, 11g, 12c | Every 30 Minutes | Not Defined | Not Defined | Generated By Database Server |
Data Source
The source of the data for this metric is 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 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, thereby increasing the free space in this tablespace.
Run the Segment Advisor on the tablespace.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
As segments within a tablespace grow, the available free space decreases. If there is no longer any available free space, meaning data files have reached 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.
If the version of the monitored database target is Oracle Database 10g Release 1 or later and the tablespace uses Local Extent Management, then the Oracle Database Server evaluates this metric internally every 10 minutes. Alternatively, if the version of the monitored Database target is Oracle 9i or earlier, or the tablespace uses Dictionary Extent Management, then the Oracle Management Agent tests the value of this metric every 30 minutes.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
8i, 9i | Every 30 Minutes | 85 | 97 | Tablespace [%name%] is [%value% percent] full |
10g, 11g, 12c | Every 30 Minutes | 85 | 97 | Generated By Database Server |
Data Source
This metric is calculated with the following command 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.
(TotalUsedSpace / MaximumSize) * 100
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.
The metrics in this metric category check for the amount of space used by each tablespace. The used space is then compared to the available free space to determine tablespace fullness. The available free space accounts for the maximum data file size as well as available disk space. This means that a tablespace will not be flagged as full if data files can extend, and there is enough disk space available for them to extend.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
As segments within a tablespace grow, the available free space decreases. If there is no longer any available free space, meaning data files have reached 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.
If the version of the monitored database target is Oracle Database 10g Release 1 or later and the tablespace uses Local Extent Management, then the Oracle Database Server evaluates this metric internally every 10 minutes. Alternatively, if the version of the monitored Database target is Oracle 9i or earlier, or the tablespace uses Dictionary Extent Management, then the Oracle Management Agent tests the value of this metric every 30 minutes.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10g, 11g, 12c | Every 30 Minutes | Not Defined | Not Defined | Tablespace [%name%] has [%value% mbytes] free. |
Data Source
The source of the data for this metric is 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 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.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
As segments within a tablespace grow, the available free space decreases. If there is no longer any available free space, meaning data files have reached 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.
If the version of the monitored database target is Oracle Database 10g Release 1 or later and the tablespace uses Local Extent Management, then the Oracle Database Server evaluates this metric internally every 10 minutes. Alternatively, if the version of the monitored Database target is Oracle 9i or earlier, or the tablespace uses Dictionary Extent Management, then the Oracle Management Agent tests the value of this metric every 30 minutes.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
10g, 11g, 12c | Every 30 Minutes | 85 | 97 | Tablespace [%name%] is [%value% percent] full |
Data Source
The source of the data for this metric is (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, thereby increasing the free space in this tablespace.
Run the Segment Advisor on the tablespace.
The metrics in this metric category check for the following:
The largest chunk-free space in the tablespace. If any table, index, cluster, or rollback segment within the tablespace cannot allocate one additional extent, then an alert is generated.
Whether any of the segments in the tablespace are approaching their maximum extents. If, for any segment, the maximum number of extents minus the number of existing extents is less than 2, an alert is generated.
Only the tablespaces with problem segments are returned as results.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
This metric checks for segments 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, a warning or critical alert is generated.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
All Versions | Every 24 Hours | 0 | Not Defined | %value% segments in %name% tablespace approaching max extents. |
Data Source
The source of the data for this metric is the 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 segment�s 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. For a dictionary managed tablespace, specify STORAGE parameters where NEXT=INITIAL and PCTINCREASE = 0.
This is a database-level metric. For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
This metric checks for segments that cannot allocate an additional extent. If the number of segments is greater than the values specified in the threshold arguments, a warning or critical alert is generated.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
All Versions | Every 24 Hours | 0 | Not Defined | %value% segments in %name% tablespace unable to extend. |
Data Source
After checking for the largest chunk free space in the tablespace, this is the number of segments that 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, thereby increasing the free space in this tablespace.
This metric category contains the Temporary File Status metric.
The absolute file number of the temporary file, used to join with other database tables and views to retrieve additional information.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
9i, 10g, 11g, 12c | Every 15 Minutes | OFFLINE | Not Defined | The temporary file %NAME% is %STATUS%. |
The metrics in this metric category contain the metric that provides the number of database objects in a schema.
This metric displays the total number of database objects in a schema.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
Not Available | Every 24 Hours | Not Defined | Not Defined | %value% object(s) exist in the %owner% schema. |
The metrics in this metric category provide the number of tables in a schema.
The metrics in this metric category contain the metrics that tell to what extent, and how consistently, a given session is blocking multiple other sessions.
For cluster databases, this metric is monitored at the cluster database target level and not by member instances.
This metric signifies that a database user is blocking at least one other user from performing an action, such as updating a table. An alert is generated if the number of consecutive blocking occurrences reaches the specified value. The sessions being blocked can come from different instances.
Note: The catblock.sql script needs to be run on the managed database prior to using the User Blocks test. This script creates some additional tables, view, and public synonyms that are required by the User Blocks test.
Target Version | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|
Not Available | Every 5 Minutes | 0 | Not Defined | Session %sid% blocking %value% other sessions for all instances. |
Data Source
This metric is calculated using the following command:
SELECT blocking_sid, num_blocked FROM ( SELECT blocking_sid, SUM(num_blocked) num_blocked FROM ( SELECT l.id1, l.id2, MAX(DECODE(l.block, 1, i.instance_name||'-'||l.sid, 2, i.instance_name||'-'||l.sid, 0 )) blocking_sid, SUM(DECODE(l.request, 0, 0, 1 )) num_blocked FROM gv$lock l, gv$instance i WHERE ( l.block!= 0 OR l.request > 0 ) AND l.inst_id = i.inst_id GROUP BY l.id1, l.id2) GROUP BY blocking_sid ORDER BY num_blocked DESC) WHERE num_blocked != 0
User Action
Either have the user who is blocking other users rollback the transaction, or wait until the blocking transaction has been committed.
The metrics in this metric category provide information regarding user locks.
Enterprise Manager will issue the alert when the Maximum Blocked Session Count or maximum blocked DB time (seconds) of transactional locks: TM, TX, UL reach the threshold.
This metric represents the maximum time wasted in any given lock chain, not for the total time wasted by everyone in any lock chain.
Target Version | Key | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|---|
9i, 10g, 11g, 12c | lockType= TM | Every 10 Minutes | Not Defined | Not Defined | %value% seconds in DB Time is spent waiting for %lockType% lock. |
9i, 10g, 11g, 12g | lockType= TX | Every 10 Minutes | Not Defined | Not Defined | %value% seconds in DB Time is spent waiting for %lockType% lock. |
9i, 10g, 11g, 12c | lockType = UL | Every 10 Minutes | Not Defined | Not Defined | %value% seconds in DB Time is spent waiting for %lockType% lock. |
Multiple Thresholds
For this metric you can set different warning and critical threshold values for each User Lock Type object.
If warning or critical threshold values are currently set for any User Lock Type 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 User Lock Type object, use the Edit Thresholds page.
Data Source
The data for the metric is retrieved from database view gv$session.
User Action
You can set the threshold for warning alert or critical alert for maximum Blocked DB Time (seconds). When maximum time wasted in any given lock chain reaches the threshold, Enterprise Manager will issue the alert.
This metric represents the maximum length of any lock chain, not for the total number of people stuck in lock chains.
Target Version | Key | Evaluation and Collection Frequency | Default Warning Threshold | Default Critical Threshold | Alert Text |
---|---|---|---|---|---|
9i, 10g, 11g, 12c | lockType= TM | Every 10 Minutes | Not Defined | Not Defined | %value% sessions are blocked by %lockType% lock. |
9i, 10g, 11g, 12c | lockType= TX | Every 10 Minutes | Not Defined | Not Defined | %value% sessions are blocked by %lockType% lock. |
9i, 10g, 11g, 12c | lockType= UL | Every 10 Minutes | Not Defined | Not Defined | %value% sessions are blocked by %lockType% lock. |