|
Oracle® Enterprise Manager Metric Reference Manual
10g Release 1 (10.1) Part No. B12015-01 |
|
|
|
Oracle® Enterprise Manager Metric Reference Manual
10g Release 1 (10.1) Part No. B12015-01 |
|
|
|
The OMS and Repository target exposes metrics that are useful for monitoring the Oracle Enterprise Manager Management Service (OMS) and Management Repository.
This is a Management Agent metric intended to send out of band notifications when the Notification system is determined to be in a critical state.
This metric flags a DBMS job whose schedule is invalid. A schedule is marked 'Invalid' if it is scheduled for more than one hour in the past, or more than one year in the future. An invalid schedule means that the job is in serious trouble.
If the job schedule is invalid, the DBMS job should be restarted. To do this:
Copy down the DBMS Job Name that is down from the row in the table. This DBMS Job Name is 'yourDBMSjobname' in the following example.
Log onto the database as the repository owner.
Issue the following SQL statement:
select dbms_jobname from mgmt_performance_names where display_name='yourDBMSjobname';
If the dbms_jobname is 'myjob', then issue the following SQL statement:
select job from all_jobs where what='myjob';
Copy down the jobid.
Force the job into the broken state so that it can be restarted by specifying the following DBMS job command and parameters:
dbms_job.broken(jobid,true)
Verify that the job has been marked as broken by using this SQL statement:
select what, broken from all_jobs where broken='Y';
You should see the job in the results.
Once you've verified that the DBMS job is marked broken, restart the job with the following DBMS job command and parameters:
dbms_job.run(jobid)
The percentage of the past hour the job has been running.
The down condition equates to the dbms_job "broken" state. The Up Arrow means not broken.
Determine the reason for the dbms job failure. Once the reason for the failure has been determined and corrected, the job can be restarted through the dbms_job.run command.
To determine the reason the dbms job failed, take the following steps (replacing myjob with the displayed name of the down job):
Copy down the DBMS Job Name that is down from the row in the table. This DBMS Job Name is 'yourDBMSjobname' in the following example.
Log onto the database as the repository owner.
Issue the following SQL statement:
select dbms_jobname from mgmt_performance_names where display_name='yourDBMSjobname';
If the dbms_jobname is 'myjob', then issue the following SQL statement:
select job from all_jobs where what='myjob';
Using the job id returned, look for ORA-12012 messages for this jobid in the alerts log and trace files and try to determine and correct the problem.
The job can be manually restarted through the following database command:
execute dbms_job.run (jobid);
The number of files waiting for the loader to process, sampled every 10 minutes.
The number of job steps that were ready to be scheduled but could not be because all the dispatchers were busy.
When this number grows steadily, it means the job scheduler is not able to keep up with the workload.
The value of the mgmt_oms_parameters table in the Management Repository where the host_url is the host_url of the Management Service and the parameter_name column is jobStepCount.
This value is updated by the job dispatcher before its periodic wait. If the graph of this number increases steadily over time, the user should take one of the following actions:
Increase the em.jobs.shortPoolSize, em.jobs.longPoolSize, and em.jobs.systemPoolSize properties in the web.xml file. The web.xml file specifies the number of threads allocated to process different types of job steps. The short pool size should be larger than the long pool size.
| Property | Defaule value | Recommended value | Description |
|---|---|---|---|
| em.jobs.shortPoolSize | 10 | 10 - 50 | Steps taking less than 15 minutes |
| em.jobs.longPoolSize | 8 | 8 - 30 | Steps taking more than 15 minutes |
| em.jobs.systemPoolSize | 8 | 8 - 20 | Internal jobs (e.g. agent ping) |
Add another Management Service on a different host.
Check the job step contents to see if they can be made more efficient.
The job dispatcher is responsible for scheduling jobs as required. It starts up periodically and checks if jobs need to be run. If job dispatcher is running more than the threshold levels, then it is having problems handling the job load.
Timestamp from the last error. If the loader is not reading file correctly, the system may not be receiving data correctly from the Management Agent.
The directory from which the loader is getting files.
The unique name of the loader, consisting of the Management Service name separated by a comma from the loader name on that Management Service.
This is the number of lines of XML text processed by the loader thread over the past hour.
If this number continues to rise over time, then the user may want to consider adding another Management Service or increasing the number of loader threads for this Management Service. To increase the number of loader threads, add or change the em.loader.threadPoolSize entry in the emoms.properties file. The default number of threads is 2. Values between 2 and 10 are common.
This is the number of lines of XML text processed by the loader thread per second averaged over the past hour.
Shows whether the Management Service is up or down.
This metric lists targets for which the Management Agent has not uploaded data in the past two hours (excluding Management Agent, Beacon and Repository targets).
The alert is generated each time the Message content changes. The Message content changes each time the list of targets not uploading data changes.
Perform the following steps:
Determine the Management Agent for the target having problems.
Verify that the target collection schedule is under 2 hour interval.
Check the agent logs for errors uploading data.
Check the Management System Errors page for Loader errors processing information from the Management Agent concerned.
The time it took to deliver a notification, averaged over the past hour.
The percentage of the past hour that Notification delivery has been running.
Displays whether the notification DBMS job (which processes severities to determine if notifications are required) is up or down.
Determine the reason for the DBMS job failure. Once the reason for the failure has been determined and corrected, the job can be restarted through the dbms_job.run command.
To determine why the DBMS job failed, take the following steps:
Log onto the database as the Management Repository owner.
Issue the following SQL statement:
select job from all_jobs where what like '%CHECK_FOR_SEVERITIES%';
Using the job id returned, look for ORA-12012 messages for this jobid in the alerts log and trace files and try to determine and correct the problem.
Issue the following DBMS job command and parameters:
execute dbms_job.run (jobid);
The total number of notifications delivered by the Management Service over the previous 10 minutes.
When this metric becomes critical, an out of band notification will be sent to the address specified during the installation.
This is the sum of the amount of time the job has run over the last hour from the mgmt_system_performance_log table in the Management Repository divided by one hour, multiplied by 100 to arrive at the percent.
Perform the following user actions:
Check the Errors page for errors logged by the Notification Delivery dbms job.
Check the number of notification rules defined and verify that they are all necessary, removing those that are not.
Verify that the addresses being used for the notifications are correct.
The count of duplicate targets in the Management Repository.
Go to the Duplicate Targets page by clicking the Duplicate targets link on the Management System Overview page. The Duplicate targets link only appears on the Management System Overview page if there are problems involving duplicate targets.
Resolve the conflict by removing the duplicate target from the conflicting Management Agent.
This metric shows how long the loader file has been waiting to be processed by the loader. This is an indicator of the delay from when the Management Agent sends out information to when the user receives the information.
This is the total number of MB that the Management Repository tablespaces are currently using.
A count of the number of sessions between the Management Service and Management Repository database.
The number of job steps processed per second by the job dispatcher, averaged over the past hour and sampled every 10 minutes.
This metric provides a count of the targets that are not uploading data.
The number of notifications delivered per second, averaged over the past hour.
This is the amount of time in milliseconds that the loader thread has been running in the past hour.
If this number is steadily increasing along with the Loader Throughput (rows per hour) metric, then perform the actions described in the User Action section of the help topic for the Loader Throughput (rows per hour) metric. If this number increases but the loader throughput does not, check for resource constraints, such as high CPU utilization by some process, deadlocks in the Management Repository database, or processor memory problems.
This page indicates whether Enterprise Manager is up or down. It contains historical information for periods in which it was down.
This metric indicates whether the Management Service is up or down. If you cannot access the Management Repository, you will get an out of band error.
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
