Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles
New Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 
 

Automatic Database Diagnostic Monitor (ADDM)


Oracle Tips by Burleson Consulting

 

The following Tip is from the outstanding book "Oracle PL/SQL Tuning: Expert Secrets for High Performance Programming" by Dr. Tim Hall, Oracle ACE of the year, 2006:

The Automatic Database Diagnostic Monitor (ADDM) analyzes data in the Automatic Workload Repository (AWR) to identify potential performance bottlenecks.  For each of the identified issues, it locates the root cause and provides recommendations for correcting the problem.  An ADDM analysis task is performed and its findings and recommendations stored in the database every time an AWR snapshot is taken provided the statistics_level parameter is set to TYPICAL or ALL. The ADDM analysis includes:

  • CPU Load

  • Memory Usage

  • I/O Usage

  • Resource Intensive SQL

  • Resource Intensive PL/SQL and Java

  • RAC Issues

  • Application Issues

  • Database Configuration Issues

  • Concurrency Issues

  • Object Contention

The ADDM reports are much simpler to read than those of AWR or STATSPACK, making them a useful method for identifying resource intensive SQL and PL/SQL.

There are several ways to produce reports from the ADDM analysis which will be explained later, but all follow the same format.  The findings (problems) are listed in order of potential impact on database performance, along with recommendations to resolve the issue and the symptoms which lead to its discovery.  An example finding is shown below.

FINDING 1: 59% impact (944 seconds)
-----------------------------------
The buffer cache was undersized causing significant additional read I/O. 

   RECOMMENDATION 1: DB Configuration, 59% benefit (944 seconds)

      ACTION: Increase SGA target size by increasing the value of parameter

         "sga_target" by 28 M.

   SYMPTOMS THAT LED TO THE FINDING:

      Wait class "User I/O" was consuming significant database time. (83%

      impact [1336 seconds]) 

The recommendations for a particular finding may include:

  • Hardware changes

  • Database configuration changes

  • Schema changes

  • Application changes

  • Using other advisors

The analysis of I/O performance is affected by the dbio_expected parameter which should be set to the average time (in microseconds) it takes to read a single database block from disk with typical values range from 5000 to 20000 microseconds.

EXECUTE DBMS_ADVISOR.set_default_task_parameter('ADDM', 'DBIO_EXPECTED', 8000);

In Enterprise Manager DBConsole, the "Performance Analysis" section on the "Home" page is a list of the top five findings from the last ADDM analysis task.  Specific reports can be produced by clicking on the "Advisor Central" link, then the "ADDM" link.  The resulting page allows the selection of a start and end snapshot, the creation of an ADDM task and the display of the resulting report by clicking on a few links.

Alternatively, an ADDM report can be generated from SQL*Plus using the addmrpt.sql script located in the $ORACLE_HOME/rdbms/admin directory.  When run, the script lists all available snapshots and prompts the user to enter the start and end snapshot along with the report name.

It is also possible to create and execute ADDM advisor tasks using the dbms_advisor package, as shown below.

BEGIN
  -- Create an ADDM task.
  DBMS_ADVISOR.create_task (
    advisor_name      => 'ADDM',
    task_name         => '970_1032_AWR_SNAPSHOT',
    task_desc         => 'Advisor for snapshots 970 to 1032.'); 

  -- Set the start and end snapshots.
  DBMS_ADVISOR.set_task_parameter (
    task_name => '970_1032_AWR_SNAPSHOT',
    parameter => 'START_SNAPSHOT',
    value     => 970); 

  DBMS_ADVISOR.set_task_parameter (
    task_name => '970_1032_AWR_SNAPSHOT',
    parameter => 'END_SNAPSHOT',
    value     => 1032); 

  -- Execute the task.

  DBMS_ADVISOR.execute_task(task_name => '970_1032_AWR_SNAPSHOT');
END;

-- Display the report.

SET LONG 100000
SET PAGESIZE 50000
SELECT DBMS_ADVISOR.get_task_report('970_1032_AWR_SNAPSHOT') AS report
FROM   dual;
SET PAGESIZE 24

The value for the SET LONG command should be adjusted to allow the whole report to be displayed.

The following views can be used to display the ADDM output without using Enterprise Manager or the get_task_report function:

  • dba_hist_snapshot - Lists all valid snapshots.

  • dba_advisor_tasks - Basic information about existing tasks.

  • dba_advisor_log - Status information about existing tasks.

  • dba_advisor_findings - Findings identified for an existing task.

  • dba_advisor_recommendations - Recommendations for the problems identified by an existing task.

The nest section will explain how Enterprise Manager relates to the previous sections.

Using Oracle Enterprise Manager

Over the last few versions of the database, Oracle has pushed Oracle Enterprise Manager (OEM) as the main administration tool for the database.  Depending on the version used, it provides either a Java GUI or HTML browser-based console that allows simplified access to a number of the features discussed above.

I do not dislike Enterprise Manager, but it does mask some detail of the underlying mechanisms.  I prefer to understand the technology, rather than be shielded from it.

Rather than launch into a lengthy discussion of the features that are supported by each version of OEM, I will simply say that if you understand the material discussed above, using OEM to access the features will be simple and intuitive.

ADDM

ADDM, or the Automatic Database Diagnostic Monitor, works in conjunction with the Automatic Workload Repository, or AWR. The AWR stores performance statistics, and these statistics are then used for problem detection and self-tuning. Much like STATSPACK, which is essentially what it is but better, snapshots are taken at regular intervals.

 

After the performance data has been collected, ADDM analyzes it. AWR is the hunter-gatherer, and ADDM is the thinker. The built-in functionality includes automated tasks which run in maintenance windows. One well-known maintenance window is the Oracle after-hours GATHER_STATS_JOB. The name of the job is GATHER_STATS_JOB .

 

Referencing the Performance Tuning Guide, this job is “created automatically at database creation time and is managed by the Scheduler. The Scheduler runs this job when the maintenance window is opened. By default, the maintenance window opens every night from 10 P.M. to 6 A.M. and all day on weekends.”

 

The automated tasks infrastructure, known as AutoTask, schedules routine maintenance tasks. These tasks include steps needed to perform or update optimizer statistics gathering, the Automatic Segment Advisor, and the SQL Tuning Advisor. A list of common problems ADDM can detect include:

  • CPU bottlenecks

  • Poor connection management

  • Excessive parsing

  • Lock contention

  • I/O capacity

  • Undersizing of Oracle memory structures

  • High load SQL statements

  • High PL/SQL and Java time

  • High checkpoint load and causes

  • RAC-specific issues

Running an ADDM or AWR report (the difference in the names is analogous to how users blur the difference between database and instance at times) can be accomplished via Database Control click and point functionality or by manually running one or more SQL scripts located in $ORACLE_HOME/rdbms/admin. 

 

The Diagnostic Pack scripts, of which ADDM falls under for licensing, can all be run as a command-line API. Many will prompt for input related to instance, dates, times, output format and snapshot coverage. The script file names and purposes are shown below. All scripts are .sql files.

 

Name

Purpose

awrrpt

Creates the main AWR report, based on STATSPACK

awrrpti

Comparison between snapshots

addmrtp

Runs ADDM analysis on pair of AWR snapshots

addmrpti

Same as above, but used for RAC instances

ashrpt

Runs the Active Session History report, calls ashrpti

ashrpti

Worker script that supports ashrpt

awrddrpt

Runs Workload Respository Compare Periods report

awrddrpi

Worker script that supports awrddrpt

awrsqrpt

Runs Workload for a particular SQL statement

awrsqrpi

Worker script that supports awrsqrpt

awrextr

Extracts AWR info, for use with/by Oracle Support

awrload

Loads AWR data, for use with/by Oracle Support

awrinfo

Outputs general AWR info

spawrrac

Server Performance RAC report

Table 8.2:  ADDM Scripts

 

The pattern on the scripts is that a script ending in -rpt typically defaults to the current DBID and instance, collects information via prompts, and passes that input to its corresponding -rpi script. The -rpi scripts can be run directly, but one will have to sort out the required/expected parameters. Some of the scripts are for overall and some are for comparison between snapshots or the repository. Many of the scripts also expect to be run as the SYS user.

 

 

This is an excerpt from the bestselling book "Oracle PL/SQL Tuning: Expert Secrets for High Performance Programming" by Dr. Tim Hall, Oracle ACE of the year, 2006.

You can buy the book for only $23.95 (30%-off) when you buy directly from the publisher, and you also get instant access to the code depot of PL/SQL tuning scripts:


 

 
��  
 
 
Oracle Training at Sea
 
 
 
 
oracle dba poster
 

 
Follow us on Twitter 
 
Oracle performance tuning software 
 
Oracle Linux poster
 
 
 

 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational