Oracle® Enterprise Manager Oracle Database and Database-Related Metric Reference Manual 12c Release 1 (12.1.0.2.0) Part Number E25160-03 |
|
|
PDF · Mobi · ePub |
The Automatic Storage Management (ASM) metrics provide for each metric the following information:
Description
Metric Summary. The metric summary can include some or all of the following: target version, evaluation frequency, collection frequency, upload frequency, operator, default warning threshold, default critical threshold, consecutive number of occurrences preceding notification, and alert text.
Multiple Thresholds (where applicable)
Data Source
User Action
This metric signifies that the ASM target 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.
Critical Alerts are generated for different type of failure, for example, when archiver hung, data block corrupted and Media failure are found in the alert log with the following error code (ORA-00257, 16038, 01157,01578,27048). The metric shows the user the line number and time when the error occurred.
Warning alerts are also generated when Session Terminated Error Stack (ORA- 00603) are present in the alert log. Many other critical alerts also occur when the Ora-15130 (Disk Group is being dismounted), Ora-15050 (Disk contains errors) and Ora-15051 (File contains errors) are present in alert log.
You can edit the metric threshold and change the value of error you want to collect under a different head. Also, you can modify the warning and critical alert values.
This metric is collected at a time interval of 15 minutes. You can change the threshold limit as per your requirements.
This metric contains the information about different ORA- errors present in the alert log file. It ignores error patterns like ORA-0*(54|1142|1146) present in the alert log file and generate a warning alert when ORA-0*600x, ORA-07445, ORA-04 [0-9][0-9][0-9])[^0-9] errors are present.
Edit the metric threshold and change the value of the ORA- error to generate the warning and critical alert for a different set of ORA- errors.
Metric Summary for Database Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
10.1.0.x; 10.2.0.x | Every 5 Minutes | After Every Sample | MATCH | ORA-0*(600?|7445|4[0-9][0-9][0-9])[^0-9] | Not Defined | 1Foot 1 | ORA-error stack (%errCodes%) logged in %alertLogName%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
For this metric column you can set different warning and critical threshold values for each for each "Timestamp/LineNumber" object.
If warning or critical threshold values are currently set for any "Timestamp/LineNumber" 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 "Timestamp/LineNumber" object, use the Edit Thresholds page..
The data comes from Alert Log Files. It is collected using the perl script $ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent. The alert log file is scanned for the ORA- errors ignoring the patterns like ORA-0*(54|1142|1146).
Examine ALERT log for additional information.
This metric provides information about the trace file name in which ORA- errors are present. It provides the detail of the trace file name and the line at which the error has occurred.
Metric Summary for Database Control
The following table shows how often the metric's value is collected.
Target Version | Evaluation and Collection Frequency |
---|---|
10.1.0.x; 10.2.0.x | Every 5 Minutes |
The data comes from the Alert Log files. It is collected using the perl script $ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
No user action is required.
This metric provides the information about the alert log file in which ORA- errors are present. It displays the file name and the line at which the error has occurred.
Metric Summary for Database Control
The following table shows how often the metric's value is collected.
Target Version | Evaluation and Collection Frequency |
---|---|
10.1.0.x; 10.2.0.x | Every 5 Minutes |
The data comes from Alert Log Files. It is collected using the perl script $ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
Examine ALERT log for additional information.
This metric contains the information about different ORA- errors, which indicate the presence of Archive Hung in the alert log files. The errors ORA-00257 and ORA-16038 in the alert log indicates an archive-hung problem. This also generates a critical alert when these problems are found in alert logs.
You can edit the metric threshold and change the value of the error you want to collect under a different head. Also, the warning and critical alert values can be modified or set.
Metric Summary for Database Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
10.1.0.x; 10.2.0.x | Every 5 Minutes | After Every Sample | CONTAINS | Not Defined | ORA- | 1Foot 1 | The archiver hung at time/line number:%timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
For this metric column you can set different warning and critical threshold values for each for each "Timestamp/LineNumber" object.
If warning or critical threshold values are currently set for any "Timestamp/LineNumber" 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 "Timestamp/LineNumber" object, use the Edit Thresholds page.
The data comes from Alert Log Files. It is collected using the perl script $ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent. Alert log file is scanned for the ORA-00257 and ORA-16038 error.
Examine ALERT log for additional information.
This metric contains the information about different ORA- errors, which indicate the presence of Data Block Corruption errors in the alert log files. The errors ORA- 01157, ORA-01578, and ORA-27048 in the alert log indicates Data Block Corruption problems. This also generates a critical alert when these problems are found in alert logs.
You can edit the metric threshold and change the value of the error you want to collect under a different head. Also, the warning and critical alert values can be modified or set.
Metric Summary for Database Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
10.1.0.x; 10.2.0.x | Every 5 Minutes | After Every Sample | CONTAINS | Not Defined | ORA- | 1Foot 1 | The data block was corrupted at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
For this metric column you can set different warning and critical threshold values for each for each "Timestamp/LineNumber" object.
If warning or critical threshold values are currently set for any "Timestamp/LineNumber" 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 "Timestamp/LineNumber" object, use the Edit Thresholds page.
The data comes from Alert Log Files. It is collected using the perl script $ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent. Alert log file is scanned for the ORA- 01157, ORA-01578, and ORA-27048 error.
Examine ALERT log for additional information.
This metric contains the information about different ORA- errors, which indicate the presence of Media Failure Errors in the alert log files. The errors ORA- 15130,ORA-15049, ORA-15050 and ORA-15051 in the alert log indicates Media Failure Error problems. This generates a critical alert when these problems are found in alert logs.
You can edit the metric threshold and change the value of the error you want to collect under a different head. Also the warning and critical alert values can be modified or set.
Metric Summary for Database Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
10.1.0.x; 10.2.0.x | Every 5 Minutes | After Every Sample | CONTAINS | Not Defined | ORA- | 1Foot 1 | Media failure was detected at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
For this metric column you can set different warning and critical threshold values for each for each "Timestamp/LineNumber" object.
If warning or critical threshold values are currently set for any "Timestamp/LineNumber" 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 "Timestamp/LineNumber" object, use the Edit Thresholds page.
The data comes from Alert Log Files. It is collected using the perl script $ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent. Alert log file is scanned for the ORA- 15130,ORA-15049, ORA-15050and ORA-15051 error.
Examine ALERT log for additional information.
This metric contains the information about different ORA- errors, which indicate the presence of Session Terminated problems in the alert log files. The ORA- 00603 error in the alert log indicates Session Terminated problems. This also generates a warning alert when these problems are found in alert logs.
You can edit the metric threshold and change the value of the error you want to collect under a different head. Also, the warning and critical alert values can be modified or set.
Metric Summary for Database Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
10.1.0.x; 10.2.0.x | Every 5 Minutes | After Every Sample | CONTAINS | ORA- | Not Defined | 1Foot 1 | A session was terminated at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
For this metric column you can set different warning and critical threshold values for each for each "Timestamp/LineNumber" object.
If warning or critical threshold values are currently set for any "Timestamp/LineNumber" 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 "Timestamp/LineNumber" object, use the Edit Thresholds page.
The data comes from Alert Log Files. It is collected using the perl script $ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent. The alert log file is scanned for the ORA- 00603 error.
Examine the ALERT log for additional information.
This metric displays the number of times an Alert has been generated for the Alert log metric. It provides information about the current status of different errors present in the alert log file.
This Metric is part of 10g Release 2 and generates a warning alert with any occurrence of ORA- Error [excluding ORA-0*(54|1142|1146)]. It also generates a Warning alert when it detects an Archiver Hung Error, Data Block Corruption Error, Media Failure Error and Session Terminated Error.
This metric is collected with the help Alert Log Metric, and the time interval for collection 5 Minutes. You can change the threshold limit count for the Warning alert and critical alert as required.
This metric signifies the number of times the Archiver Hung error (ORA-00257 and ORA-16038) has been generated in the Alert log metric. It gives user an idea about the current status of Archiver Hung error present in the alert log file. This also generates a warning alert when this count is greater than zero.
User can edit the metric threshold and change the value of error he/she wants to collect under different head. Also the warning alert and critical alert values can be modified or set.
Metric Summary for Database Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
10.1.0.x; 10.2.0.x | Every 5 Minutes | After Every Sample | > | 0 | Not Defined | 1 | Archiver hung errors have been found in the alert log. |
Calculated based on the Archive Hung Error Stack Metric rollup.
Examine ALERT log for additional information. Note: This event does not automatically clear since there is no automatic way of determining when the problem has been resolved. Hence, you need to manually clear the event once the problem is fixed.
This metric signifies the number of times the Data Block Corruption error (ORA- 01157, ORA-01578, and ORA-27048) has been generated in the Alert log metric. It gives user an idea about the current status of Data Block Corruption error present in the alert log file. This also generates a warning alert when this count is greater than zero.
User can edit the metric threshold and change the value of error he/she wants to collect under different head. Also the warning alert and critical alert values can be modified or set.
Metric Summary for Database Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
10.1.0.x; 10.2.0.x | Every 5 Minutes | After Every Sample | > | 0 | Not Defined | 1 | Data block corruption errors have been found in the alert log. |
Calculated based on the Data Block Corruption Error Stack Metric rollup.
Examine ALERT log for additional information. Note: This event does not automatically clear since there is no automatic way of determining when the problem has been resolved. Hence, you need to manually clear the event once the problem is fixed.
This metric signifies the number of times the Generic Alert error (ORA-0*600x, ORA-07445, ORA-04 [0-9][0-9][0-9])[^0-9]) has been generated in the Alert log metric. It gives user an idea about the current status of Generic Alert (ORA-) error present in the alert log file. This also generates a warning alert when this count is greater than zero.
User can edit the metric threshold and change the value of error he/she wants to collect under different head. Also the warning alert and critical alert values can be modified or set.
Metric Summary for Database Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
10.1.0.x; 10.2.0.x | Every 5 Minutes | After Every Sample | > | 0 | Not Defined | 1 | %value% distinct types of ORA- errors have been found in the alert log. |
Calculated based on the Generic Alert Error Stack Metric rollup.
Examine ALERT log for additional information.
This metric signifies the number of times the Media Failure Alert error (ORA- 15130,ORA-15049, ORA-15050and ORA-15051) has been generated in the Alert log metric. It gives user an idea about the current status of Media Failure Alert (ORA-) error present in the alert log file. This also generates a warning alert when this count is greater than zero.
User can edit the metric threshold and change the value of error he/she wants to collect under different head. Also the warning alert and critical alert values can be modified or set.
Metric Summary for Database Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
10.1.0.x; 10.2.0.x | Every 5 Minutes | After Every Sample | > | 0 | Not Defined | 1 | Media failure errors have been found in the alert log. |
Calculated based on the Media Failure Alert Error Stack Metric rollup.
Examine ALERT log for additional information. Note: This event does not automatically clear since there is no automatic way of determining when the problem has been resolved. Hence, you need to manually clear the event once the problem is fixed.
This metric signifies the number of times the Session Terminated Alert error (ORA- 00603) has been generated in the Alert log metric. It gives user an idea about the current status of Session Terminated Alert (ORA-) error present in the alert log file. This also generates a warning alert when this count is greater than zero.
User can edit the metric threshold and change the value of error he/she wants to collect under different head. Also the warning alert and critical alert values can be modified or set.
Metric Summary for Database Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
10.1.0.x; 10.2.0.x | Every 5 Minutes | After Every Sample | > | 0 | Not Defined | 1 | Session terminations have been found in the alert log. |
Calculated based on the Session Terminated Alert Error Stack Metric rollup.
Examine ALERT log for additional information. Note: This event does not automatically clear since there is no automatic way of determining when the problem has been resolved. Hence, you need to manually clear the event once the problem is fixed.
The ASM Cluster File System metrics show the space used by all the ASM Cluster File Systems. These metrics are used to collect information about the ASM Cluster File System space usage and are used to show the trend of ASM Cluster File System space usage in the application. These metrics collect information for both mounted and dismounted ASM Cluster File Systems. This information is used to determine the following metrics for Space Usage: Allocated Space (GB), Size (GB), Free (GB), Used (GB), and Used (%). These metrics also collect information whether the ASM Cluster File System is corrupt. For dismounted ASM Cluster File Systems, 0 is returned for the Free (GB), Used (GB), and Used (%) metrics.
These metrics only collect information about the ASM Cluster File System that is not specific to a node in a cluster. They collect Space Usage information which is the same across all nodes in the cluster. Information like State and Availability of the ASM Cluster File System can be different across the nodes in a cluster and is collected by the ASM Cluster File System State metrics.
These metrics generate a warning alert if the ASM Cluster File System is 85% used and a critical alert if 97% used. These metrics also generate a critical alert if the ASM Cluster File System has sections that are corrupt.
These metrics are collected at a time interval of 15 minutes. You can change the threshold limit as required.
This metric shows if the mounted ASM Cluster File System has sections that are corrupt. A value of "TRUE" for this metric indicates that there are sections that are corrupt and hence the "Check and Repair" operation should be run on the ASM Cluster File System to fix it. For dismounted ASM Cluster File Systems, it returns a value of Null for this metric.
This metric generates a warning alert if the ASM Cluster File System is dismounted on a given host. The metric also generates a critical alert if the mounted ASM Cluster File System is not available on a host.
This metric is collected at a time interval of 15 minutes. You can change the threshold limit as required.
This metric is collected with the help of a SQL query which queries the V$ASM_FILESYSTEM, V$ASM_VOLUME, V$ASM_OFSVOLUMES views.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.2.0.x | Every 15 Minutes | After Every Sample | = | Not Defined | TRUE | 1 | The ASM Cluster File System using volume device %ofs_volume_device% has sections that are corrupt. Run check and repair operation on the file system to fix the issue. |
For this metric column you can set different warning and critical threshold values for each unique combination of "Volume Device" and "Disk Group" objects.
If warning or critical threshold values are currently set for any unique combination of "Volume Device" and "Disk Group" 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 "Volume Device" and "Disk Group" objects, use the Edit Thresholds page.
This metric is collected from the column CORRUPT in the V$ASM_FILESYSTEM view for mounted ASM Cluster File Systems. For Dismounted File Systems, a value of Null is returned for this metric.
Run Check and Repair on the ASM Cluster File System to fix the corrupted sections.
This metric shows the space allocated from the disk group for this ASM Cluster File System in GB.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every 15 Minutes |
This metric is collected from the column SPACE in the V$ASM_FILE view
No user action is required.
This metric shows the unused capacity of the ASM Cluster File System in gigabytes. It gives an indication of the free space available in the ASM Cluster File System. For dismounted ASM Cluster File Systems, a value of 0 is returned for this metric.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every 15 Minutes |
This metric is collected from the column TOTAL_FREE in the V$ASM_FILESYSTEM view. For dismounted ASM Cluster File Systems, a value of 0 is returned.
Consider resizing the ASM Cluster File System if there is not enough Free Space available.
This metric shows the size in GB of the ASM Cluster File System.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every 15 Minutes |
This metric is collected from the column TOTAL_SIZE in the V$ASM_FILESYSTEM view for mounted File Systems and from the column SIZE_MB in the view V$ASM_VOLUME for dismounted File Systems.
Consider resizing the ASM Cluster File System to add space.
This metric shows the space in GB that is used on the mounted ASM Cluster File System. For dismounted ASM Cluster File Systems, a value of 0 is returned for this metric.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every 15 Minutes |
This metric is calculated from the columns TOTAL_SIZE and TOTAL_FREE in the V$ASM_FILESYSTEM view. It is calculated as:
TOTAL_SIZE - TOTAL_FREE
For dismounted ASM Cluster File Systems, a value of 0 is returned for this metric
Consider Resizing the ASM Cluster File System to add more space.
This metric shows the percentage of space that is used on the ASM Cluster File System. For dismounted ASM Cluster File Systems, a value of 0 is returned for this metric.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.2.0.x | Every 15 Minutes | After Every Sample | > | 85 | 97 | 1 | The ASM Cluster File System using volume device %ofs_volume_device% is %ofs_used_pct%%% full. Resize the file system to add more space. |
For this metric you can set different warning and critical threshold values for each unique combination of "Volume Device" and "Disk Group" objects.
If warning or critical threshold values are currently set for any unique combination of "Volume Device" and "Disk Group" 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 "Volume Device" and "Disk Group" objects, use the Edit Thresholds page.
This metric is calculated from the columns TOTAL_SIZE and TOTAL_FREE in the V$ASM_FILESYSTEM view. It is calculated as:
TOTAL_SIZE - TOTAL_FREE/TOTAL_SIZE * 100
For dismounted ASM Cluster File Systems, a value of 0 is returned for this metric
Consider resizing the ASM Cluster File System to add more space to fix the alert generated by this metric.
This metric shows the Volume Name of the Volume Device used to create the ASM Cluster File System.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every 15 Minutes |
This metric is collected from the column VOLUME_NAME in the V$ASM_VOLUME view.
No user action is required.
This metric is used to alert the user to checker failures reported in the alert log. It contains the number of checker failures detected. It also generates a critical alert when these problems are found in the alert log.
The data comes from the alert log files. It is collected using the perl script $ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent. Alert log file is scanned for messages similar to "ASM Health Checker found 1 new failures".
This metric returns the name of the Alert Log file.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.1.0.x; 11.2.0.x | Every 5 Minutes |
The data comes from the alert log files. It is collected using the perl script $ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent. Alert log file is scanned for messages similar to "ASM Health Checker found 1 new failures".
Examine the alert log for additional information.
Note:
This event does not automatically clear since there is no automatic way of determining when the problem has been resolved. Therefore, you need to manually clear the event once the problem is fixed.This metric is used to alert the user to checker failures reported in the alert log. It contains the number of checker failures detected. .
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.1.0.x; 11.2.0.x
12.1.0.x |
Every 5 Minutes | After Every Sample | MATCH | Not Defined | .Foot 1 | 1Footref 1 | Health checker runs found %numberOfFailures% new failures in %alertLogName% at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
For this metric column you can set different warning and critical threshold values for each for each "Time/LineNumber" object.
If warning or critical threshold values are currently set for any "Time/LineNumber" 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/LineNumber" object, use the Edit Thresholds page.
The data comes from the alert log files. It is collected using the perl script $ORACLE_HOME/sysman/admin/scripts/alertlog.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent. Alert log file is scanned for messages similar to "ASM Health Checker found 1 new failures".
Examine the alert log for additional information.
Note:
This event does not automatically clear since there is no automatic way of determining when the problem has been resolved. Therefore, you need to manually clear the event once the problem is fixed.The Incident metrics represent incidents, for example, generic internal error, access violation, and so on as recorded in the ASM alert log file. The alert log file has a chronological log of messages and errors.
Each metric signifies that the ASM being monitored has detected a critical error condition about the ASM and has generated an incident to the alert log file since the last sample time. The Support Workbench in Enterprise Manager contains more information about each generated incident.
This metric signifies that the ASM 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 ASM can also generate this type of incident when it detects a SIGSEGV or SIGBUS signals.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.1.0.x 11.2.0.x | Every 5 Minutes | After Every Sample | MATCH | Not Defined | .Foot 1 | 1Foot 2 | An access violation detected in %alertLogName% at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
Footnote 2 Once an alert is triggered for this metric, it must be manually cleared.
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.
The data comes from the alert log files. It is collected using the Perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
Use Support Workbench in Enterprise Manager to examine the details of the incident.
This metric is the name of the trace file (if any) associated with the logged incident.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.1.0.x; 11.2.0.x | Every 5 Minutes |
The data comes from the alert log files. It is collected using the Perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
No user action is required.
This metric is the name of the alert log file.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.1.0.x; 11.2.0.x | Every 5 Minutes |
The data comes from the alert log files. It is collected using the Perl script: $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
No user action is required.
ASM Block corruption can happen due to many reasons over lifetime (for example head misalignment, dust spec, and so on). If the disk groups are mirrored, ASM automatically repairs the corrupted blocks from the mirror.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.1.0.x 11.2.0.x | Every 5 Minutes | After Every Sample | MATCH | Not Defined | .Foot 1 | 1Foot 2 | An ASM data block was corrupted at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
Footnote 2 Once an alert is triggered for this metric, it must be manually cleared.
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.
Incident metric
User can execute check and remap commands which have been implemented in Enterprise Manager.
Check
This checks the consistency of disk group metadata and logs the result in alert log and may repair depending upon repair/norepair option provided. In case of corruptions, the result would look like: "cache read a corrupted block group=NORM3 fn=1 blk=0 from disk 0" and so on.
Remap
This repairs a range of physical blocks that maps to a valid ASM file.
In addition, you can use Support Workbench in Enterprise Manager to examine the details of the incidents.
This metric signifies that the ASM 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.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.1.0.x 11.2.0.x | Every 5 Minutes | After Every Sample | MATCH | Not Defined | .Foot 1 | 1Foot 2 | A cluster error detected in %alertLogName% at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
Footnote 2 Once an alert is triggered for this metric, it must be manually cleared.
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.
The data comes from the alert log files. It is collected using the Perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
Use Support Workbench in Enterprise Manager to examine the details of the incident.
This metric signifies that the ASM 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.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.1.0.x 11.2.0.x | Every 5 Minutes | After Every Sample | MATCH | Not Defined | .Foot 1 | 1Foot 2 | A deadlock error detected in %alertLogName% at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
Footnote 2 Once an alert is triggered for this metric, it must be manually cleared.
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.
The data comes from the alert log files. It is collected using the Perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
Use Support Workbench in Enterprise Manager to examine the details of the incident.
This metric signifies that the ASM has generated an incident due to failure to read a file at the time.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.1.0.x 11.2.0.x | Every 5 Minutes | After Every Sample | MATCH | Not Defined | .Foot 1 | 1Foot 2 | A file access error detected in %alertLogName% at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
Footnote 2 Once an alert is triggered for this metric, it must be manually cleared.
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.
The data comes from the alert log files. It is collected using the Perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
Use Support Workbench in Enterprise Manager to examine the details of the incident.
This metric signifies that the ASM has generated an incident due to some error.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.1.0.x 11.2.0.x | Every 5 Minutes | After Every Sample | MATCH | Not Defined | .Foot 1 | 1Foot 2 | Incident (%errCodes%) detected in %alertLogName% at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
Footnote 2 Once an alert is triggered for this metric, it must be manually cleared.
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.
The data comes from the alert log files. It is collected using the perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
Use Support Workbench in Enterprise Manager to examine the details of the incident.
This metric signifies that the ASM has generated an incident due to an internal ASM error. This type of incident is typically related to Oracle Exception message ORA-600 or ORA-0060*.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.1.0.x 11.2.0.x | Every 5 Minutes | After Every Sample | MATCH | Not Defined | .Foot 1 | 1Foot 2 | Internal error (%errCodes%) detected in %alertLogName% at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
Footnote 2 Once an alert is triggered for this metric, it must be manually cleared.
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.
The data comes from the alert log files. It is collected using the perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
Use Support Workbench in Enterprise Manager to examine the details of the incident.
This metric is the impact of an incident. For a Generic Internal Error incident, the impact describes how the incident may affect the ASM.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.1.0.x; 11.2.0.x | Every 5 Minutes |
The data comes from the alert log files. It is collected using the Perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
No user action is required.
This metric is a number identifying an incident. The Support Workbench in Enterprise Manager uses this ID to specify an incident.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.1.0.x; 11.2.0.x | Every 5 Minutes |
The data comes from the alert log files. It is collected using the Perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
No user action is required.
This metric signifies that the ASM has generated an incident due to an internal SQL error. This type of incident is typically related to Oracle Exception message ORA-604.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.1.0.x 11.2.0.x | Every 5 Minutes | After Every Sample | MATCH | Not Defined | .Foot 1 | 1Foot 2 | An internal SQL error detected in %alertLogName% at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
Footnote 2 Once an alert is triggered for this metric, it must be manually cleared.
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.
The data comes from the alert log files. It is collected using the Perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
Use Support Workbench in Enterprise Manager to examine the details of the incident.
This metric signifies that the ASM 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.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.1.0.x 11.2.0.x | Every 5 Minutes | After Every Sample | MATCH | Not Defined | .Foot 1 | 1Foot 2 | Out of memory detected in %alertLogName% at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
Footnote 2 Once an alert is triggered for this metric, it must be manually cleared.
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.
The data comes from the alert log files. It is collected using the Perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
Use Support Workbench in Enterprise Manager to examine the details of the incident.
This metric signifies that the ASM 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.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.1.0.x 11.2.0.x | Every 5 Minutes | After Every Sample | MATCH | Not Defined | .Foot 1 | 1Foot 2 | A data block was corrupted at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
Footnote 2 Once an alert is triggered for this metric, it must be manually cleared.
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.
The data comes from the alert log files. It is collected using the Perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
Use Support Workbench in Enterprise Manager to examine the details of the incident.
This metric contains the information about different ORA- errors, which indicate the presence of Session Terminated problems in the alert log files. The ORA- 00603 error in the alert log indicates Session Terminated problems. This also generates a warning alert when these problems are found in alert logs.
You can edit the metric threshold and change the value of the error you want to collect under a different head. Also, the warning and critical alert values can be modified or set.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.1.0.x 11.2.0.x | Every 5 Minutes | After Every Sample | MATCH | Not Defined | .Foot 1 | 1Foot 2 | A session termination detected in %alertLogName% at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
Footnote 2 Once an alert is triggered for this metric, it must be manually cleared.
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.
The data comes from the alert log files. It is collected using the Perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent. The alert log file is scanned for the ORA- 00603 error.
Use Support Workbench in Enterprise Manager to examine the details of the incident.
The Instance Volume Performance metrics indicate the performance of the volumes present in an Automatic Storage Management (ASM) instance. These metrics show the volume performance parameters for all the volumes created on all disk groups mounted on an ASM Instance.
These metrics are used to collect information, for example, total I/O and read/write requests, total I/O and read/write time, and the total number of bytes read/written to the volume. These metrics also show the response of the volume for read, write, and I/O throughput and the Read Write Errors.
This metric shows the sum of ASM volume I/O performance per second in terms of total I/O requests for all the ASM Volumes. The data is displayed for all instances that are part of the cluster.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every Hour |
It is calculated using the Instance Volume Performance metric which in turn collects data from the GV$ASM_DISKGROUP_STAT and GV$ASM_VOLUME_STAT views.
To calculate the average I/Os per second for each volume, the total number of I/O responses is divided by the total I/O time during the collection interval. The data is displayed for all instances that are part of the cluster.
No user action is required.
This metric shows the sum of all volume I/O for all volumes. The data is not aggregated for all instances.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every Hour |
It is calculated using the Instance Volume Performance metric which in turn collects data from the GV$ASM_DISKGROUP_STAT and GV$ASM_VOLUME_STAT views.
To calculate the average I/O size of each volume, the total number of bytes read and written is divided by the total number of I/Os during the collection interval. The data is displayed for all instances that are part of the cluster.
No user action is required.
This metric shows the sum of I/O throughput for all volumes. The data is displayed for all instances that are part of the cluster.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every Hour |
It is calculated using the Instance Volume Performance metric which in turn collects data from the GV$ASM_DISKGROUP_STAT and GV$ASM_VOLUME_STAT views.
To calculate the average throughput of each volume, the total number of bytes read and written is divided by the total I/O time during the collection interval. The data is displayed for all instances that are part of the cluster.
No user action is required.
This metric shows the volume read response time detail of the volumes. This gives an indication of the volume response time in terms of total read requests for this volume.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every Hour |
It is calculated using the Instance Volume Performance metric which in turn collects data from the GV$ASM_DISKGROUP_STAT and GV$ASM_VOLUME_STAT views.
To calculate the average read response time for each volume, the total read time is divided by the total number of read responses during the collection interval. The data is displayed for all instances that are part of the cluster.
No user action is required.
This metric shows the sum of all volume reads for all volumes which are part of the cluster. The data is not aggregated for all instances.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every Hour |
It is calculated using the Instance Volume Performance metric which in turn collects data from the GV$ASM_DISKGROUP_STAT and GV$ASM_VOLUME_STAT views.
To calculate the average read size of each volume, the total number of bytes read are divided by the total number of reads during the collection interval. The data is displayed for all instances that are part of the cluster.
No user action is required.
This metric shows the read throughput detail of a volume created in an Automatic Storage Management (ASM) instance. This gives an indication for the total number of bytes read from the volume in proportion to the total read time for this volume in an instance.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every Hour |
It is calculated using the Instance Volume Performance metric which in turn collects data from the GV$ASM_DISKGROUP_STAT and GV$ASM_VOLUME_STAT views.
To calculate the average read throughput of each volume, the total number of bytes read is divided by the total read time during the collection interval. The data is displayed for all instances that are part of the cluster.
No user action is required.
This metric shows the detail of the total number of failed read/writes for the volume. This provides information about the total number of failed attempts of reads and writes for the volume.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every Hour |
It is calculated using the GV$ASM_DISKGROUP_STAT and GV$ASM_VOLUME_STAT views. From these views, the total number of failed read/writes for the volume is added to calculate the read write errors detail.
Investigate the issues behind read/write errors.
This metric shows the detail of total read requests per second for a volume in a disk group in an Automatic Storage Management (ASM) instance. This metric shows the read performance of all the volumes included in an instance.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every Hour |
It is calculated using the Instance Volume Performance metric which in turn collects data from the GV$ASM_DISKGROUP_STAT and GV$ASM_VOLUME_STAT views.
To calculate the average reads per second for each volume, the total number of read responses is divided by the total read time during the collection interval. The data is displayed for all instances that are part of the cluster.
No user action is required.
This metric shows the I/O response time detail of volumes. For this volume, this metric indicates the response time in terms of total I/O requests for all the volumes.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every Hour |
It is calculated using the Instance Volume Performance metric which in turn collects data from the GV$ASM_DISKGROUP_STAT and GV$ASM_VOLUME_STAT views.
To calculate the average I/O response time for each volume, the total I/O time is divided by the total number of I/O responses during the collection interval. The data is displayed for all instances that are part of the cluster.
No user action is required.
This metric shows the write response time detail of the volumes. This gives an indication for the volume response time in terms of total write requests for this volume.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every Hour |
It is calculated using the Instance Volume Performance metric which in turn collects data from the GV$ASM_DISKGROUP_STAT and GV$ASM_VOLUME_STAT views.
To calculate the average write response time for each volume, the total write time is divided by the total number of write responses during the collection interval. The data is displayed for all instances that are part of the cluster.
No user action is required.
This metric shows the sum of all volume writes for all volumes which are part of the cluster. The data is not aggregated for all instances.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every Hour |
It is calculated using the Instance Volume Performance metric which in turn collects data from the GV$ASM_DISKGROUP_STAT and GV$ASM_VOLUME_STAT views.
To calculate the average write size of each volume, the total number of bytes written is divided by the total number of writes during the collection interval. The data is displayed for all instances that are part of the cluster.
No user action is required.
This metric shows the write throughput detail of a volume created on a disk group in an Automatic Storage Management (ASM) instance. This gives an indication for the total number of bytes written from the volume with proportion to the total write time for this volume in an instance.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every Hour |
It is calculated using the Instance Volume Performance metric which in turn collects data from the GV$ASM_DISKGROUP_STAT and GV$ASM_VOLUME_STAT views.
To calculate the average write throughput of each volume, the total number of bytes written is divided by the total write time during the collection interval. The data is displayed for all instances that are part of the cluster.
No user action is required.
This metric shows the detail of total write requests per second for a Volume in an Automatic Storage Management (ASM) Instance. This metric shows the write performance of the volume.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.2.0.x | Every Hour |
It is calculated using the Instance Volume Performance metric which in turn collects data from the GV$ASM_DISKGROUP_STAT and GV$ASM_VOLUME_STAT views.
To calculate the average writes per second for each volume, the total number of write responses is divided by the total write time during the collection interval. The data is displayed for all instances that are part of the cluster.
No user action is required.
The Operational Error metrics represent errors that may affect the operation of the ASM, for example, data block corruption, media failure, and so on as recorded in the ASM alert log file. The alert log file has a chronological log of messages and errors.
Each metric signifies that the ASM being monitored has detected a critical error condition that may affect the normal operation of the ASM and has generated an error message to the alert log file since the last sample time. The Support Workbench in Enterprise Manager may contain more information about the error.
This metric is the name of the trace file (if any) associated with the logged error.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.1.0.x; 11.2.0.x | Every 5 Minutes |
The data comes from the alert log files. It is collected using the Perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
No user action is required.
This metric is the name of the alert log file.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected.
Target Version | Collection Frequency |
---|---|
11.1.0.x; 11.2.0.x | Every 5 Minutes |
The data comes from the alert log files. It is collected using the Perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
No user action is required.
This metric signifies that the ASM 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.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.1.0.x; 11.2.0.x | Every 5 Minutes | After Every Sample | MATCH | Not Defined | .Foot 1 | 1Foot 2 | A data block was corrupted at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
Footnote 2 Once an alert is triggered for this metric, it must be manually cleared.
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. See Editing Thresholds for information on accessing the Edit Thresholds page.
The data comes from the alert log files. It is collected using the Perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
Use Support Workbench in Enterprise Manager to examine the details of the error.
This metric signifies that the ASM being monitored has generated some error that may affect the normal operation of the ASM to the alert file since the last sample time. The alert file is a special trace file containing a chronological log of messages and errors. An alert event is triggered when data block corrupted messages are written to the alert file.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.1.0.x; 11.2.0.x | Every 5 Minutes | After Every Sample | MATCH | Not Defined | .Foot 1 | 1Foot 2 | Operational error (%errCodes%) detected in %alertLogName% at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
Footnote 2 Once an alert is triggered for this metric, it must be manually cleared.
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. See Editing Thresholds for information on accessing the Edit Thresholds page.
The data comes from the alert log files. It is collected using the Perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
Use Support Workbench in Enterprise Manager to examine the details of the error.
This metric signifies that the ASM 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.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
11.1.0.x; 11.2.0.x | Every 5 Minutes | After Every Sample | MATCH | Not Defined | .Foot 1 | 1Foot 2 | Media failure detected in %alertLogName% at time/line number: %timeLine%. |
Footnote 1 Once an alert is triggered for this metric, it must be manually cleared.
Footnote 2 Once an alert is triggered for this metric, it must be manually cleared.
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. See Editing Thresholds for information on accessing the Edit Thresholds page.
The data comes from the alert log files. It is collected using the Perl script $ORACLE_HOME/sysman/admin/scripts/alertlogAdr.pl where $ORACLE_HOME refers to the home of the Oracle Management Agent.
Use Support Workbench in Enterprise Manager to examine the details of the error.
The Response metric shows the status of the Automatic Storage Management (ASM) instance. It shows whether the instance is up or down. The check is performed every five minutes and returns the status of the connection as successful or it displays the ORA error for connection failure. This generates a critical alert if the ASM instance is down.
This metric shows the status of the Automatic Storage Management (ASM) instance. It displays whether the instance is up or down. This check is performed every five minutes and returns the status of the connection as successful or it displays the ORA error for connection failure. This generates a critical alert if the ASM instance is down.
Metric Summary for Database Control and Cloud Control
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
---|---|---|---|---|---|---|---|
All Versions | Every 5 Minutes | After Every Sample | = | Not Defined | 0 | 1 | Failed to connect to ASM instance %oraerr%. |
You can establish a connection to the ASM instance with instance properties, and if the connection succeeds then the status is shown as Up, otherwise is displays as Down. It may also display as Down if there is an error in the metric collection.
Perform one of the following:
Check that the configuration property saved for the ASM instance is correct.
If it displays as Down, the ASM instance is down. Try to reestablish the connection using the startup/shutdown feature using the Enterprise Manager application. Alternately, you can restart the application manually.