This metric reports the name of the trace file (if any) associated with the logged error.

Data Source

The following command is the data source for this metric where $ORACLE_HOME refers to the home of the Oracle Management Agent:

$ORACLE_HOME/sysman/admin/scripts/alertlog.pl

User Action

No user action is required.

This metric reports the name of the alert log file.

Data Source

The following command is the data source for this metric where $ORACLE_HOME refers to the home of the Oracle Management Agent:

$ORACLE_HOME/sysman/admin/scripts/alertlog.pl

User Action

No user action is required.

This metric signifies that an archiver error has occurred on the database being monitored, since the last sample time.

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

Multiple Thresholds

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

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

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

Data Source

The following command is the data source for this metric where $ORACLE_HOME refers to the home of the Oracle Management Agent:

$ORACLE_HOME/sysman/admin/scripts/alertlog.pl

User Action

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

Multiple Thresholds

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

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

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

Data Source

The following command is the data source for this metric where $ORACLE_HOME refers to the home of the Oracle Management Agent:

$ORACLE_HOME/sysman/admin/scripts/alertlog.pl

User Action

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

• For all supported databases monitored by Enterprise Manager release 10.2.0.4 Management Agent:

  Alert Log Filter - up to 1024 characters

  Warning or Critical Threshold - up to 256 characters

• For all supported databases monitored by Enterprise Manager release 10.2.0.5 Management Agent:

  Alert Log Filter - up to 4000 characters

  Warning or Critical Threshold - up to 4000 characters

Archiver error (ORA-00257) and data block corrupted (ORA-01578) messages are sent out as separate metrics.

Multiple Thresholds

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

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

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

Data Source

The following command is the data source for this metric where $ORACLE_HOME refers to the home of the Oracle Management Agent:

$ORACLE_HOME/sysman/admin/scripts/alertlog.pl

User Action

This metric represents the media failure alert log error. An alert event is triggered when messages ORA-01242 and ORA-01243 are written to the ALERT file.

Multiple Thresholds

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

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

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

Data Source

Not available.

User Action

No user action is required.

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

Multiple Thresholds

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

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

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

Data Source

The source for this metric is $ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.

User Action

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

Data Source

The source of this metric is the Alert Log metric.

User Action

Examine the Alert Log.

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

Data Source

The source of this metric is the Alert Log metric.

User Action

Examine the Alert Log.

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

Data Source

The source of this metric is the Alert Log metric.

User Action

Examine the Alert Log.

This metric represents the media failure alert log error status.

Data Source

Not available.

User Action

No user action is required.

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

Data Source

The source of this metric is the Alert Log metric.

User Action

Examine the Alert Log.

The Archive Area Used (%) metric returns the percentage of space used in the archived redo log destination. If the space used is more than the threshold value given in the threshold arguments, then a warning or critical alert is generated.

Multiple Thresholds

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

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

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

Data Source

The formula used for each of the three archive area scenarios is as follows:

• Quota is set: Regardless of whether the destination is using ASM or a conventional filesystem location, if the QUOTA_SIZE attribute is specified in the associated LOG_ARCHIVE_DEST_n parameter (meaning there is a quota specified for the destination), the percentage is calculated using the following formula:

  Archive Area Used (%) = (QUOTA_USED/QUOTA_SIZE) * 100

• No quota is set:

  • Archive area on regular filesystem: Free and used space in the archive area is determined by running the UNIX df -k command against the filesystem on which the archive area resides.

  • Archive area on ASM diskgroup: The space used in the archive area is calculated by first determining the total diskgroup size (minus space required for redundancy management) and dividing that by the diskgroup redundancy factor (1 for External, 2 for Normal, 3 for High) to arrive at the "Total Safely Usable" space. Then, the "Safely Usable Free" space is determined, which is the free space that can be safely utilized taking mirroring and redundancy needs into account. The SQL used to determine these values is as follows:

    select (((NVL(dg.total_mb,0) -            
    NVL(dg.required_mirror_free_mb,0))*1024)/decode(dg.type,'EXTERN',1,'NORMAL',2,'HIGH',3,1)) 
    TotalSafelyUsable,NVL(dg.usable_file_mb,0)*1024 SafelyUsableFree from V$ASM_DISKGROUP_STAT dg 
    where state in ('CONNECTED', 'MOUNTED') and name='$diskGroup'";

    Using the values from this query, the Archive Area Used (%) is calculated as follows:

    Archive Area Used (%) = [(TotalSafelyUsable – SafelyUsableFree)/TotalSafelyUsable] * 100

User Action

Verify that the database archived redo log destination parameters are configured properly. For more information, see Specifying Archive Destinations in Oracle Database Administrator’s Guide.

This metric returns the total space used (in KB) on the device containing the archived redo log destination directory.

Data Source

The formula used for each of the three archive area scenarios is as follows:

• Quota is set: Same underlying methodology as described above for the Archive Area Used (%) metric, but using the following formula:

  Archive Area Used (KB) = QUOTA_USED

• No quota is set:

  • Archive area on regular filesystem: Same underlying methodology as described above for the Archive Area Used (%) metric.

  • Archive area on ASM diskgroup: Same underlying methodology as described above for the Archive Area Used (%) metric, but using the following formula (referencing the values from the SQL query in the Archive Area Used (%) metric):

    Archive Area Used (KB) = TotalSafelyUsable – SafelyUsableFree

User Action

Verify that the database archived redo log destination parameters are configured properly. For more information, see Specifying Archive Destinations in Oracle Database Administrator’s Guide.

This metric returns the free space (in KB) on the device containing the archived redo log destination directory.

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

The formula used for each of the three archive area scenarios is as follows:

• Quota is set: Same underlying methodology as described above for the Archive Area Used (%) metric, but using the following formula:

  Free Archive Area (KB) = QUOTA_SIZE - QUOTA_USED

• No quota is set:

  • Archive area on regular filesystem: Same underlying methodology as described above for the Archive Area Used (%) metric.

  • Archive area on ASM diskgroup: Same underlying methodology as described above for the Archive Area Used (%) metric, but using the following formula (referencing the values from the SQL query in the Archive Area Used (%) metric):

    Free Archive Area (KB) = SafelyUsableFree

User Action

Verify that the database archived redo log destination parameters are configured properly. For more information, see Specifying Archive Destinations in Oracle Database Administrator’s Guide.

This metric returns the total space (in KB) on the device containing the archived redo log destination directory.

Data Source

The formula used for each of the three archive area scenarios is as follows:

• Quota is set: Same underlying methodology as described above for the Archive Area Used (%) metric, but using the following formula:

  Total Archive Area (KB) = QUOTA_SIZE

• No quota is set:

  • Archive area on regular filesystem: Same underlying methodology as described above for the Archive Area Used (%) metric.

  • Archive area on ASM diskgroup: Same underlying methodology as described above for the Archive Area Used (%) metric, but using the following formula (referencing the values from the SQL query in the Archive Area Used (%) metric):

    Total Archive Area (KB) = TotalSafelyUsable

User Action

Verify that the database archived redo log destination parameters are configured properly. For more information, see Specifying Archive Destinations in Oracle Database Administrator’s Guide.

This metric represents the SQL response time.

Data Source

Not available.

User Action

No user action is required.

This metric reports the name of the alert log file.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

No user action is required.

This metric signifies that a database health checker has detected one or more persistent data failures. Examples of data failures include missing files, corrupt files, inconsistent files, and corrupt blocks. The alert shows the number of data failures detected by a checker run. Details of individual data failures can be accessed from the Perform Recovery page in Enterprise Manager.

Setting Thresholds

To edit the thresholds for any of the following metrics, from the Enterprise Manager UI, right-click the target name, select Monitoring, then Metric and Collection Settings. The following settings provide examples of some of the possible settings:

• Warning Threshold: Not Defined; Critical Threshold: .*

  In this case, the Management Agent generates a critical error alert in Enterprise Manager when a data failure occurs.

• Warning Threshold: .*; Critical Threshold: Not Defined

  In this case, the Management Agent generates a warning alert in Enterprise Manager when a data failure occurs.

• Warning Threshold: Not Defined; Critical Threshold: Not Defined

  In this case, the Management Agent does not generate an alert in Enterprise Manager when a data failure occurs.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Details of individual data failures can be accessed from the Perform Recovery page in Enterprise Manager.

This metric generates a critical alert on the primary database if the fast-start failover (FSFO) configuration is in an unobserved condition, indicating that FSFO is not currently possible.

User Action

If the Data Guard configuration was configured in Enterprise Manager to use the automatic Observer restart feature, the alert will clear after a new observer process is restarted. Otherwise, determine the cause of the unobserved condition, and restart the Observer process if necessary.

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.

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.

Data Source

The data is derived from the following formula:

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

This metric 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.

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 or Far Sync instance. 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.

Data Source

The data is derived from the following formula:

v$dataguard_stats('transport lag')

Transport Lag metrics are computed based on data that is periodically received from the primary database. An unchanging value in this column across multiple queries indicates that the standby database or the Far Sync instance is not receiving data from the primary database.

Data Source

DATUM_TIME in v$dataguard_stats

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 is set for this metric column. Alerts will be generated when threshold values are reached. You can edit the value for a threshold as required. Certain ORA- errors can be ignored by providing the ORA- errors in the Data Guard Status Filter expression.

User Action

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

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

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

Multiple Thresholds

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

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

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

Data Source

Not 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 represents the average file write time, measured in hundredths of a second.

Multiple Thresholds

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

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

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

Data Source

Not 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.

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 failed to successfully execute the job after a specified number of attempts (defined in the job).

• The job is 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.

Data Source

The data is derived from the following formula:

SUM(broken)
  FROM (SELECT DECODE(broken, 'N', 0, 1) broken
         FROM dba_jobs
  UNION ALL
         SELECT DECODE(STATE, 'BROKEN', 1, 0) broken
          FROM dba_scheduler_jobs

User Action

From the Enterprise Manager console, check the Scheduler Job History page or query the ALL_SCHEDULER_JOB_RUN_DETAILS view 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.

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 after a specified number of times (specified in the job definition), 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.

Data Source

The data is derived from the following formula:

SELECT SUM(failed)
          FROM (SELECT DECODE(NVL(failures,0), 0, 0, 1) failed
                  FROM dba_jobs
        UNION ALL
                SELECT DECODE(STATUS ,'FAILED',DECODE(STATE,'BROKEN',0,'DISABLED',0,1),0) failed FROM (SELECT all_jobs.OWNER,
                               all_jobs.JOB_NAME,
                               all_runs.STATUS,
                               all_jobs.STATE
                         FROM (SELECT OWNER,
                                      JOB_NAME, MAX(ACTUAL_START_DATE) AS START_DATE
                                 FROM DBA_SCHEDULER_JOB_RUN_DETAILS
                             GROUP BY OWNER,JOB_NAME) last_run , DBA_SCHEDULER_JOB_RUN_DETAILS all_runs,
                             DBA_SCHEDULER_JOBS all_jobs
                        WHERE all_runs.OWNER(+)=all_jobs.OWNER
                          AND all_runs.JOB_NAME(+)=all_jobs.JOB_NAME
                          AND last_run.OWNER(+)=all_jobs.OWNER
                          AND last_run.JOB_NAME(+)=all_jobs.JOB_NAME
                          AND all_runs.ACTUAL_START_DATE=last_run.START_DATE))

User Action

From the Enterprise Manager console, check the Scheduler Job History page or query the ALL_SCHEDULER_JOB_RUN_DETAILS view for error information. Correct the problem that is preventing the job from running.

This metric represents the current number of logons.

Data Source

The data is derived from the current logins.

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 represents the current number of opened cursors.

Data Source

The data is derived from the current open cursors.

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.

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

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

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

Data Source

The data is derived from the following formula:

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

User Action

Increase the DML_LOCKS instance parameter by 10%.

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

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

Data Source

Depending on your release, one of the following derives the data:

The fifth column provides process usage. You can get this information from the inst_perf.xmlp file located in the plug-in installation directory (plugins/oracle.sysman.db.agent.plugin_version/metadata).

   SELECT /*+ ORDERED */
       TO_CHAR( FROM_TZ( CAST(m.end_time AS TIMESTAMP), 
              TO_CHAR(systimestamp, 'tzr') ) 
       AT TIME ZONE sessiontimezone,
       'YYYY-MM-DD HH24:MI:SS'),
       SUM(CASE WHEN a.internal_metric_name = 'logons'
           THEN m.value ELSE 0 END) logons,
       SUM(CASE WHEN a.internal_metric_name = 'opencursors'
           THEN m.value ELSE 0 END) opencursors,
       SUM(CASE WHEN a.internal_metric_name = 'user_limit'
           THEN m.value ELSE 0 END) user_limit,
       SUM(CASE WHEN a.internal_metric_name = 'process_usage'
           THEN m.value ELSE 0 END) process_usage,
       SUM(CASE WHEN a.internal_metric_name = 'session_usage'
           THEN m.value ELSE 0 END) session_usage
      FROM v$alert_types a, v$threshold_types t, v$sysmetric m
     WHERE a.internal_metric_category = 'Database_Resource_Usage'
       AND a.reason_id = t.alert_reason_id
       AND t.metrics_id = m.metric_id
       AND m.group_id = 2
       AND :1 != 'BASIC'
       AND m.end_time <= SYSDATE
      GROUP BY m.end_time
      ORDER BY m.end_time ASC

User Action

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

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

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

Data Source

The data is derived from the following formula:

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

User Action

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

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

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

Data Source

The data is derived from the following formula:

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

User Action

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

This metric shows if the database workload capture is in progress.

This metric is available for all versions.

Data Source

The source of the data is the server-generated alert triggered by the target database when a capture is started.

User Action

No user action is required.

This metric shows if database workload replay is in progress.

This metric is available for all versions.

Data Source

The source of the data is the server-generated alert triggered by the target database when a replay is started.

User Action

No user action is required.

This metric reflects the average response time for a single I/O for a database replay client.

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

Data Source

The source of the data is the server-generated alert triggered by the target database when an alarming condition is detected in a replay client.

User Action

Run the calibrate utility of the replay client and restart a replay with the suggested number of replay clients, distributed between machines with the necessary capacity.

This metric represents the number of replay client connections performing I/O operation concurrently.

The rest of the information in this section is only valid for this metric when it appears in Enterprise Manager. The following table shows how often the metric's value is collected.

Data Source

The source of the data is the server-generated alert triggered by the target database when an alarming condition is detected in a replay client.

User Action

Run the calibrate utility of the replay client and restart a replay with the suggested number of replay clients, distributed between machines with the necessary capacity.

This metric represents the number of replay client connections using the CPU concurrently.

Data Source

The source of the data is the server-generated alert triggered by the target database when an alarming condition is detected in a replay client.

User Action

Run the calibrate utility of the replay client and restart a replay with the suggested number of replay clients, distributed between machines with the necessary capacity.

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

Multiple Thresholds

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

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

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

Data Source

Not 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 represents the average elapsed time, in microseconds, for calls to a particular database service.

Multiple Thresholds

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

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

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

Data Source

Not 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 is used to enable Database Vault Security Analyst to keep a watch on the violation attempts against the Database Vault database. Database Vault Security Analysts can pick the command rules that they would like to get alerted on and even further filter them based on the different types of attempts by mentioning different thresholds to match SQL commands causing the violations.

This metric is not enabled out of the box. You must enable it from Metrics and Policy Settings page. By default, this metric is collected every 1 hour, but you can change the collection frequency.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each unique combination of Database Vault Command Rule and Violation Time objects.

If warning or critical threshold values are currently set for any unique combination of Database Vault Command Rule and Violation Time 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 Database Vault Command Rule and Violation Time objects, use the Edit Thresholds page.

Data Source

The attempted violations are picked up from the target's database vault audit trail. Only audit entries related to a command rule, which represent failed attempts to execute a SQL, are selected. Specified thresholds should match the SQL command causing command rule violation.

User Action

To know more about the violations, for example, the command that was violated, which database user triggered the violation, what action triggered this violation, and at what time this violation happened, login to the target's Database Vault Home Page and use the Attempted Violations charts.

This metric is used to enable Database Vault Security Analyst to keep a watch on the violation attempts against the Database Vault database. Database Vault Security Analysts can pick the realms that they would like to get alerted on and even further filter them based on the different types of attempts by mentioning different thresholds to match SQL commands causing the violations.

This metric is not enabled out of the box. You must enable it from Metrics and Policy Settings page. By default, this metric is collected every 1 hour, but you can specify the collection frequency.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each unique combination of Database Vault Realm and Violation Time objects.

If warning or critical threshold values are currently set for any unique combination of Database Vault Realm and Violation Time 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 Database Vault Realm and Violation Time objects, use the Edit Thresholds page.

Data Source

The attempted violations are picked up from the target's Database Vault audit trail. Only audit entries related to realms, which represent failed attempts to execute a SQL, are selected. Specified thresholds should match the SQL command causing command rule violation.

User Action

To know more about the violations, for example, the realm that was violated, which database user triggered the violation, what action triggered this violation, and at what time this violation happened, login to the target's Database Vault Home Page and use the Attempted Violations charts.

After the Database Vault policies are defined and configured to protect the database, further user actions over the course of time can disturb these configurations. This metric tracks the users' actions and raises an alert when there is a misconfiguration on a Command Rule that needs administrator attention. This metric is enabled out of the box. By default this metric is collected every 1 hour, but you can change the collection frequency.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each Database Vault Command Rule object.

If warning or critical threshold values are currently set for any Database Vault Command Rule 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 Database Vault Command Rule object, use the Edit Thresholds page.

Data Source

The configuration issues are picked from scanning the realm and command rule definitions.

User Action

To know the cause of the command rule misconfiguration, navigate to the target's Database Vault Home page, launch Database Vault Administrator, and view the Database Vault Configuration Issues Reports. These alerts are automatically cleared when the configuration issue is resolved.

After the Database Vault policies are defined and configured to protect the database, further user actions over the course of time can disturb these configurations. This metric tracks the users' actions and raises an alert when there is a misconfiguration on a Realm that needs administrator attention. This metric is enabled out of the box. By default this metric is collected every 1 hour, but you can change the collection frequency.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each Database Vault Realm object.

If warning or critical threshold values are currently set for any Database Vault Realm 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 Database Vault Realm object, use the Edit Thresholds page. See Editing Thresholds for information on accessing the Edit Thresholds page.

Data Source

The configuration issues are picked from scanning the realm and rule set definitions.

User Action

To know the cause of the realm misconfiguration, navigate to the target's Database Vault Home page, launch Database Vault Administrator, and view the Database Vault Configuration Issues Reports. These alerts are automatically cleared when the configuration issue is resolved.

After the Database Vault policies are defined, further changes to it is tracked by this metric. On any changes to the Database Vault policies, this metric will raise an alert. This metric is enabled out of the box. By default this metric is collected every 1 hour, but you can change the collection frequency.

Multiple Thresholds

For this metric you can set different warning and critical threshold values for each unique combination of DV Policy Change Category and DV Policy Change Time objects.

If warning or critical threshold values are currently set for any unique combination of DV Policy Change Category and DV Policy Change Time 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 DV Policy Change Category and DV Policy Change Time objects, use the Edit Thresholds page. See Editing Thresholds for information on accessing the Edit Thresholds page

Data Source

The policy changes are picked up from scanning the records in the Database Audit Trail related to Database Vault Schemas.

User Action

To know more about the policy changes, for example which object was changed, which database user changed the policy, what was the user action, and at what time this policy was changed, login to the target's Database Vault Home Page and view the Policy Changes Report.

This metric signifies that an archiver error has occurred on the database being monitored, since the last sample time.

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

Data Source

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

User Action

Examine the ALERT log and archiver trace file for additional information. However, the most likely cause of this message is that the destination device is out of space to store the redo log file. Verify the device specified in the initialization parameter ARCHIVE_LOG_DEST is set up properly for archiving.

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

Data Source

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

User Action

Examine the ALERT log for additional information.

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

• For all supported databases monitored by Enterprise Manager release 10.2.0.4 Management Agent:

  Alert Log Filter - up to 1024 characters

  Warning or Critical Threshold - up to 256 characters

• For all supported databases monitored by Enterprise Manager release 10.2.0.5 Management Agent:

  Alert Log Filter - up to 4000 characters

  Warning or Critical Threshold - up to 4000 characters

Archiver error (ORA-00257) and data block corrupted (ORA-01578) messages are sent out as separate metrics.

This metric indicates that the database being monitored has generated a media failure error to the ALERT file since the last sample time.

This metric indicates that the database being monitored has generated a session terminated message to the ALERT file since the last sample time.

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

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

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

This metric represents the media failure alert log error status.

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

This metric reports on the Oracle Home directory if a Single Instance HA is installed on the machine.

This metric indicates whether the database is managed by Single Instance HA. If the Oracle Database is not managed by Single Instance HA, indicates if a Single Instance HA is available for Oracle Database registration.

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

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

Data Source

The source of the data is the following formula:

SELECT count(*) FROM sys.deftran 

User Action

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

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

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

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

Data Source

The source of the data is the following formula:

SELECT count(*) FROM sys.deferror 

User Action

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

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

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

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

Data Source

The source of the data is the v$parameter view.

User Action

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

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

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

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

Multiple Thresholds

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

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

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

Data Source

Calculated using the UNIX df -k command.

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

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

User Action

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

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

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

Data Source

The the data is calculated using the UNIX df -k command.

User Action

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

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

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

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

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

Multiple Thresholds

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

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

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

Data Source

The data is calculated using the UNIX df -k command.

User Action

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

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

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

Data Source

The data is calculated using the UNIX df -k command.

User Action

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

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

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

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

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

Data Source

The data is derived from the ((DeltaLogicalGets - (DeltaPhysicalReads - DeltaPhysicalReadsDirect)) / DeltaLogicalGets) * 100 formula where:

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

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

User Action

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

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

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

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

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

Data Source

Not available.

User Action

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

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

Data Source

Not available.

User Action

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

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

Data Source

The source of the data is the following formula:

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

User Action

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

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

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

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

Data Source

The source of the data is (1 - Misses/Gets) * 100 where:

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

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

User Action

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

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

Data Source

Not available.

User Action

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

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

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

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

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

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

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

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

Data Source

The source of the data is the (DeltaPinHits / DeltaPins) * 100 formula where:

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

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

User Action

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

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

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

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

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

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

Data Source

The source of the data is the following formula:
1 - pinhits / pins 

User Action

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

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

Data Source

The source of the data is the following formula:

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

User Action

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

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

Data Source

The source of the data is the following formula:

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

User Action

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

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

Data Source

The source of the data is the following formula:

(parallel operations downgraded 75 to 99 percent) / time 

User Action

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

This metric reports the number of times per second parallel execution was requested but execution was serial because of insufficient parallel execution servers.

Data Source

The source of the data is the following formula:

parallel operations downgraded to serial / time

User Action

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

This metric reports the number of times per transaction parallel execution was requested but execution was serial because of insufficient parallel execution servers.

Data Source

The source of the data is the following formula:

parallel operations downgraded to serial / transactions

User Action

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

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

Data Source

Not 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.

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

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

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

Data Source

The source of the data is the following formula:

100 * (redo_entries_delta - redo_space_requests_delta) 
/redo_entries_delta 
where: 

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

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

User Action

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

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

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

Data Source

Not 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. Changes in the response time per transaction will appear as increased time spent in the database, either on CPU or in wait events and ADDM will report the sources of contention for both hardware and software resources.

This metric represents the percentage of row cache miss ratio.

Data Source

Not 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 represents the sort efficiency as measured by the percentage of times sorts were performed in memory as opposed to going to disk.

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

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

Data Source

The source of the data is (DeltaMemorySorts / (DeltaDiskSorts + DeltaMemorySorts)) * 100 where:

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

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

User Action

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

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

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

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

This metric displays the number of times that the error occurred.

This metric checks for the number of failed logins on the target database. This check is performed every interval specified by the collection frequency and returns the number of failed logins for the last 30 minutes. 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, on every collection, this metric determines the number of failed login attempts in the last 30 minutes and overrides the current alert instead of a new alert. You can manually clear these alerts. They will not automatically cleared after the next collection.

Multiple Thresholds

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

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

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

Data Source

The database stores login information in different views, based on the audit_trail setting. The database view used is DB or DB_EXTENDED: DBA_AUDIT_SESSION.

User Action

No user action is required.

Formerly referred to as flash recovery area, the metrics in this category return 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.

Data Source

The source of the data is the following formula:

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.

Data Source

The source of the data is the following formula:

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.

Data Source

The source of the data is the following formula:

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.

Data Source

The source of the data is the following formula:

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.

Data Source

The source of the data is the following formula:

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.

Data Source

The source of the data is the following formula:

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.

Data Source

The source of the data is the following formula:

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.

Data Source

The source of the data is the following formula:

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 collects the total number of text indexes that have crossed the fragmentation percentage threshold specified by the user.

This metric collects the number of text indexes that have crossed the critical fragmentation percentage threshold specified by the user.

Data Source

The fragmentation percentage for each index or index partition is derived by computing the data from DBA_IND_PARTITIONS, CTXSYS.CTX_INDEX_PARTITIONS, and its relevant text index metadata tables. The list of text indexes and the critical percentage threshold against which their fragmentation is to be evaluated are specified by the user as part of the "Evaluate and Fix Text Index Fragmentation" job.

User Action

A metric threshold could be set to generate incidents on the number of text indexes that have crossed the critical fragmentation threshold specified in "Evaluate and Fix Text Index Fragmentation" job. The scheduled DBMS job would automatically attempt to fix such text indexes (if they were specified in the fix list) by rebuilding them (using shadow creation). In addition, the incident also enables the user to fix the fragmented text indexes from the Enterprise Manager console.

This metric collects the total number of text indexes that have crossed the warning fragmentation percentage threshold, but not the critical percentage threshold, specified by the user.

Data Source

The fragmentation percentage for each index or index partition is derived by computing the data from DBA_IND_PARTITIONS, CTXSYS.CTX_INDEX_PARTITIONS, and its relevant text index metadata tables. The list of text indexes and the warning percentage threshold against which their fragmentation is to be evaluated are specified by the user as part of the "Evaluate and Fix Text Index Fragmentation" job.

User Action

A metric threshold could be set to generate incidents on the number of text indexes that have crossed the warning fragmentation threshold, but not the critical threshold, specified in "Evaluate and Fix Text Index Fragmentation" job. The scheduled DBMS job would automatically attempt to fix such text indexes (if they were specified in the fix list) by optimizing them. In addition, the incident also enables the user to fix the fragmented text indexes from the Enterprise Manager console.

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

Data Source

The source of the data is the following formula:

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

User Action

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

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

Data Source

The source of the data is the following formula:

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

User Action

The required actions are specific to your site.

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

Data Source

The source of the data is the following formula:

global cache blocks corrupted

User Action

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

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

Data Source

The source of the data is global cache blocks lost.

User Action

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

To edit the thresholds for any of the following metrics, from the Enterprise Manager UI, right-click the target name, select Monitoring, then Metric and Collection Settings. The following settings provide examples of some of the possible settings:

• Warning Threshold: Not Defined; Critical Threshold: .*

  In this case, the Management Agent generates a critical error alert in Enterprise Manager when the incident occurs.

• Warning Threshold: .*; Critical Threshold: Not Defined

  In this case, the Management Agent generates a warning alert in Enterprise Manager when the incident occurs.

• Warning Threshold: Not Defined; Critical Threshold: Not Defined

  In this case, the Management Agent does not generate an alert in Enterprise Manager when the incident occurs.

This metric signifies that the database has generated an incident due to some memory access violation. This type of incident is typically related to Oracle Exception messages such as ORA-3113 and ORA-7445. The database can also generate this type of incident when it detects a SIGSEGV or SIGBUS signals.

Multiple Thresholds

By default, Enterprise Manager reports this type of incident as Critical. For information about modifying threshold values, see Setting Thresholds for Incident Metrics.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Use Support Workbench in Enterprise Manager to examine the details of the incident.

This metric reports the name of the trace file (if any) associated with the logged incident.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

No user action is required.

This metric reports the name of the alert log file.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

No user action is required.

This metric signifies that the database has generated an incident due to a member evicted from the group by a member of the cluster database. This type of incident is typically related to Oracle Exception message ORA-29740.

Multiple Thresholds

By default, Enterprise Manager reports this type of incident as Critical. For information about modifying threshold values, see Setting Thresholds for Incident Metrics.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Use Support Workbench in Enterprise Manager to examine the details of the incident.

This metric signifies that the database has generated an incident due to a deadlock detected while trying to lock a library object. This type of incident is typically related to Oracle Exception message ORA-4020.

Multiple Thresholds

By default, Enterprise Manager reports this type of incident as Critical. For information about modifying threshold values, see Setting Thresholds for Incident Metrics.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Use Support Workbench in Enterprise Manager to examine the details of the incident.

This metric signifies that the database has generated an incident due to failure to read a file at the time.

Multiple Thresholds

By default, Enterprise Manager reports this type of incident as Critical. For information about modifying threshold values, see Setting Thresholds for Incident Metrics.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Use Support Workbench in Enterprise Manager to examine the details of the incident.

This metric signifies that the database has generated an incident due to some database error.

Multiple Thresholds

By default, Enterprise Manager reports this type of incident as Critical. For information about modifying threshold values, see Setting Thresholds for Incident Metrics.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Use Support Workbench in Enterprise Manager to examine the details of the incident.

This metric signifies that the database has generated an incident due to an internal database error. This type of incident is typically related to Oracle Exception message ORA-600 or ORA-0060*.

Multiple Thresholds

By default, Enterprise Manager reports this type of incident as Critical. For information about modifying threshold values, see Setting Thresholds for Incident Metrics.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Use Support Workbench in Enterprise Manager to examine the details of the incident.

This metric reports the impact of an incident. For a Generic Internal Error incident, the impact describes how the incident may affect the database.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

No user action is required.

This metric reports a number identifying an incident. The Support Workbench in Enterprise Manager uses this ID to specify an incident.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

No user action is required.

This metric signifies that the database has generated an incident due to an inconsistent database state such an invalid ROWID. This type of incident is typically related to Oracle Exception message ORA-1410.

Multiple Thresholds

By default, Enterprise Manager reports this type of incident as Critical. For information about modifying threshold values, see Setting Thresholds for Incident Metrics.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Use Support Workbench in Enterprise Manager to examine the details of the incident.

This metric signifies that the database has generated an incident due to an internal SQL error. This type of incident is typically related to Oracle Exception message ORA-604.

Multiple Thresholds

By default, Enterprise Manager reports this type of incident as Critical. For information about modifying threshold values, see Setting Thresholds for Incident Metrics.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Use Support Workbench in Enterprise Manager to examine the details of the incident.

This metric signifies that the database has generated an incident due to an ORACLE data block corruption. This type of incident is typically related to Oracle Exception message ORA-1578.

Multiple Thresholds

By default, Enterprise Manager reports this type of incident as Critical. For information about modifying threshold values, see Setting Thresholds for Incident Metrics.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Use Support Workbench in Enterprise Manager to examine the details of the incident.

This metric signifies that the database has generated an incident due to failure to allocate memory. This type of incident is typically related to Oracle Exception message ORA-4030 or ORA-4031.

Multiple Thresholds

By default, Enterprise Manager reports this type of incident as Critical. For information about modifying threshold values, see Setting Thresholds for Incident Metrics.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Use Support Workbench in Enterprise Manager to examine the details of the incident.

This metric signifies that the database has generated an incident due to an error with the redo log. This type of incident is typically related to Oracle Exception message ORA-353, ORA-355, or ORA-356.

Multiple Thresholds

By default, Enterprise Manager reports this type of incident as Critical. For information about modifying threshold values, see Setting Thresholds for Incident Metrics.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Use Support Workbench in Enterprise Manager to examine the details of the incident.

This metric signifies that the database has generated an incident due to an unexpected session termination. This type of incident is typically related to Oracle Exception message ORA-603.

Multiple Thresholds

By default, Enterprise Manager reports this type of incident as Critical. For information about modifying threshold values, see Setting Thresholds for Incident Metrics.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Use Support Workbench in Enterprise Manager to examine the details of the incident.

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

Multiple Thresholds

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

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

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

Data Source

The data is derived from the following views:

V$CLUSTER_INTERCONNECTS

V$CONFIGURED_INTERCONNECTS

User Action

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

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

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

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

Multiple Thresholds

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

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

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

Data Source

The data is derived from the following views:

V$SYSSTAT

V$DLM_MISC

V$PARAMETER

User Action

No user action is required.

This metric represents the total invalid object count in the database.

Data Source

The data is derived from the SYS.OBJ$ and SYS.USER$ tables.

User Action

The “Recompile Invalid Objects” corrective action could be setup against the incident to automatically attempt to recompile the invalid objects in the database. Some objects might need specific corrective steps to be performed manually before re-compilation.

This metric represents the total number of invalid objects per schema.

Multiple Thresholds

Different warning and critical threshold values could be set for each Invalid Object Owner (schema) object.

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

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

Data Source

The data is derived from the SYS.OBJ$ and SYS.USER$ tables.

User Action

The “Recompile Invalid Objects” corrective action could be setup against the incident to automatically attempt to recompile the invalid objects in a schema. Some objects might need specific corrective steps to be performed manually before recompilation.

This metric provides the average age (in seconds) of the messages in the buffered queue for all nonsystem queues in the database.

This metric gives the age (in seconds) of the first message in the buffered queue for all non-system queues in the database.

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:

1. <SCHEMA>.AQ$<QUEUE_TABLE>

2. 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.

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.

This metric displays the current number of overflow messages spilled to disk from the buffered queue.

This metric gives the total number of messages processed per minute per buffered queue in the last collection interval of the metric.

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.

This metric display's the average age of messages in the buffered queue per queue in seconds.

This metric displays the age of the first message in the buffered queue per queue per subscriber in seconds.

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.

This metric gives the total number of messages processed per minute per buffered queue subscriber in the last collection interval of the metric.

This metric gives the total number of messages processed per minute per buffered queue subscriber in the last collection interval of the metric.

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.

This metric gives the age (in seconds) of the first message in the persistent queue for all non-system queues in the database.

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:

1. <SCHEMA>.AQ$_<QUEUE_TABLE>_S

2. <SCHEMA>.AQ$_<QUEUE_TABLE>_I

3. <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 displays the average age of messages in the persistent queue per queue in seconds.

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.

This metric gives the messages processed percentage per minute per persistent queue in the last collection interval of the metric.

This metric gives the total number of messages processed per minute per persistent queue in the last collection interval of the metric.

This metric gives the total number of messages received or enqueued into the queue per minute in the last collection interval of the metric.

This metric display's the average age of messages in the persistent queue per queue in 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.

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.

This metric gives the messages processed percentage per minute per persistent queue subscriber in the last collection interval of the metric.

This metric gives the messages processed percentage per minute per persistent queue subscriber in the last collection interval of the metric.

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.

This metric displays the total amount of memory used in MB.

This metric monitors the expiry of the Monitoring User account password, and raises an alert when the password is not updated in Oracle Enterprise Manager's target configuration.

This metric monitors the potential expiry of the Monitoring User account.

This metric checks whether the Monitoring User account has monitoring privileges on par with the DBSNMP or SYSDBA user accounts. This is useful when using a non-DBSNMP user account.

The collection is disabled by default.

This metric determines whether the database has been instrumented with Oracle Configuration Manager.

Data Source

This metric tests for the existence of the MGMT_DB_LL_METRICS package body owned by the ORACLE_OCM user.

User Action

No user action is required.

This metric determines that Oracle Configuration Manager needs to be instrumented in the database.

Data Source

This metric tests for the existence of the emCCR executable in the $ORACLE_HOME/ccr/bin/ directory. If the emCCR executable is present, then Enterprise Manager checks to see if the MGMT_DB_LL_METRICS package body, owned by the ORACLE_OCM user, exists in the Management Repository.

If the emCCR executable is present but the MGMT_DB_LL_METRICS package body is missing, then this metric returns 1, indicating that the database must be instrumented.

User Action

Install Oracle Configuration Manager (OCM) in the database.

This metric determines how the Oracle Configuration Manager is configured.

Data Source

This metric tests for the existence of the emCCR executable in the $ORACLE_HOME/ccr/bin directory.

User Action

No user action is required.

This metric reports the name of the trace file (if any) associated with the logged error.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

No user action is required.

This metric reports the name of the alert log file.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

No user action is required.

This metric signifies that an archiver error has occurred on the database being monitored, since the last sample time.

lertlogAdr.pl: Tue Oct 24 16:09:29 2017: DEBUG:

20 error types defined.
Error type pattern:
 incident,type=["']INCIDENT_ERROR["'],group=["']Generic Internal Error["']
 incident,type=["']INCIDENT_ERROR["'],group=["']Session Terminated["']
 incident,type=["']INCIDENT_ERROR["'],group=["']Internal SQL Error["']
 incident,type=["']INCIDENT_ERROR["'],group=["']Access Violation["']
 incident,type=["']INCIDENT_ERROR["'],group=["']Redo Log Corruption["']
 incident,type=["']INCIDENT_ERROR["'],group=["']File Access Error["']
 incident,type=["']INCIDENT_ERROR["'],group=["']Inconsistent DB State["']
 incident,type=["']INCIDENT_ERROR["'],group=["']Data Block Corruption["']
 incident,type=["']INCIDENT_ERROR["'],group=["']Deadlock["']
 incident,type=["']INCIDENT_ERROR["'],group=["']Out of Memory["']
 incident,type=["']INCIDENT_ERROR["'],group=["']Cluster Error["']
 incident,level=["'][12]["'],type=["']INCIDENT_ERROR["']
 dataFailure,type=["']ERROR["'],group=["']DRA["']
 operational,type=["']ERROR["'],group=["']Archiver Error["']
 operational,type=["']ERROR["'],group=["']Data Block Corruption["']
 operational,type=["']ERROR["'],group=["']Media Failure["']
 operational,level=["'][12]["'],type=["']ERROR["']
 operational,level=["']*["'],type=["']ERROR["']
 operational,level=["']*["'],type=["']WARNING["']
 operational,level=["']*["'],type=["']*["'] 

Multiple Thresholds

By default, Enterprise Manager reports this type of error as Critical. For information about modifying threshold values, see Setting Thresholds for Incident Metrics.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Use Support Workbench in Enterprise Manager to examine the details of the error. However, the most likely cause of this message is that the destination device is out of space to store the redo log file. Verify the device specified in the initialization parameter ARCHIVE_LOG_DEST is set up properly for archiving.

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

Multiple Thresholds

By default, Enterprise Manager reports this type of error as Critical. For information about modifying threshold values, see "Setting Thresholds for Incident Metrics".

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Use Support Workbench in Enterprise Manager to examine the details of the error.

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

Multiple Thresholds

By default, Enterprise Manager reports this type of error as Critical. For information about modifying threshold values, see Setting Thresholds for Operational Error Metrics in Oracle Grid Infrastructure Metric Reference Manual.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Use Support Workbench in Enterprise Manager to examine the details of the error.

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

Multiple Thresholds

By default, Enterprise Manager reports this type of error as Critical. For information about modifying threshold values, see Setting Thresholds for Operational Error Metrics in Oracle Grid Infrastructure Metric Reference Manual.

Data Source

The source of the data is $AGENT_BASE/plugins/oracle.sysman.db.agent.plugin_n.n.n.n/scripts/alertlogAdr.pl.

In the preceding directory path, $AGENT_BASE refers to the home of the Oracle Management Agent and n.n.n.n refers to the release version of the Oracle Database plug-in, such as plug-in release 13.1.0.0.

User Action

Use Support Workbench in Enterprise Manager to examine the details of the error.

This metric displays the user-defined error.

This metric displays user-defined text. You can use this metric to raise alerts for custom text found in the XML alert log.

Multiple Thresholds

Use the thresholds to define the custom text (regular expression). An alert will be raised for any entry in the XML alert log with text matching the custom text entered here.

This metric displays the user-defined warning.

This metric displays the cumulative size of audit files. Due to different reasons, if audit trails can't be written to the database, then they are written to the file system, and with time, the files grow. If the cumulative size of audit files exceeds more than 1 GB, it is marked as a warning alert. You must configure the critical threshold if you want to define a critical alert.

Data Source

OS audit files of the target database

User Action

Load the audit files back to the database and find out why the audit trails are written to the OS file system.

This metric represents the recovery area free space as a percentage. 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%.

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 represents the recovery area used space as a percentage. The Critical threshold is set for < 97% and the Warning threshold is set for < 85% and these can be customized. Any changes will directly be applied on the database.

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 represents the state of the database.

Data Source

Not available.

User Action

The required actions are specific to your site. The required actions are specific to your site.

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

Data Source

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

User Action

This metric displays the value of the current SCN.

This metric displays the current SCN compatibility for the database.

This metric displays the rate at which the SCN growth is calculated, such as 16k/32k.

This metric displays the maximum SCN compatibility for the database.