AUTOMATIC DATABASE DIAGNOSTIC MONITOR

AN INTRODUCTION TO THE ADDM TOOL OF THE ORACLE DATABASE

ADDM is diagnostic software built into Oracle Database. ADDM examines and analyzes data
captured in Automatic Workload Repository (AWR) to determine possible database performance
problems. This document provides an insight of what this tool is and how it works.
Contents
...................................................................................................................................................................................................................................... 0
1. Introduction ....................................................................................................................................................................................................... 0
2. Overview of the Automatic Database Diagnostic Monitor.............................................................................................................. 2
3. ADDM Analysis .................................................................................................................................................................................................. 3
4. Using ADDM with Oracle Real Application Clusters .......................................................................................................................... 5
5. ADDM Analysis Results .................................................................................................................................................................................. 6
6. Reviewing the ADDM Analysis .................................................................................................................................................................... 6
7. Reviewing ADDM Analysis Results: Example ................................................................................................................................... 8
8. Setting Up ADDM ....................................................................................................................................................................................... 9
8.1 Setting the DBIO_EXPECTED Parameter ........................................................................................................................................10
9. Diagnosing Database Performance Problems with ADDM ...........................................................................................................10
9.1 Running ADDM in Database Mode .................................................................................................................................................11
9.2 Running ADDM in Instance Mode ...................................................................................................................................................11
9.3 Running ADDM in Partial Mode .......................................................................................................................................................12
9.4 Displaying an ADDM Report ..............................................................................................................................................................13
10. Views with ADDM Information ...............................................................................................................................................................13
11. Reviewing the ADDM Analysis ...............................................................................................................................................................14
12. Implementing ADDM Recommendations ..........................................................................................................................................16

1
1. Introduction
When problems occur with a system, it is important to perform accurate and timely diagnosis of the problem before
making any changes to a system. Oftentimes, a database administrator (DBA) simply looks at the symptoms and
immediately starts changing the system to fix those symptoms. However, an accurate diagnosis of the actual
problem in the initial stage significantly increases the probability of success in resolving the problem.

With Oracle Database, the statistical data needed for accurate diagnosis of a problem is stored in the Automatic
Workload Repository (AWR). ADDM is diagnostic software built into Oracle Database. ADDM examines and analyzes
data captured in Automatic Workload Repository (AWR) to determine possible database performance problems.

2. Overview of the Automatic Database Diagnostic Monitor

Automatic Database Diagnostic Monitor (ADDM) automatically detects and reports performance problems with the
database. The results are displayed as ADDM findings on the Database Home page in Oracle Enterprise Manager
Cloud Control. Reviewing the ADDM findings enables you to quickly identify the performance problems that require
your attention.

Each ADDM finding provides a list of recommendations for reducing the impact of the performance problem. You
should review ADDM findings and implement the recommendations every day as part of regular database
maintenance. Even when the database is operating at an optimal performance level, you should continue to use
ADDM to monitor database performance on an ongoing basis. As mentioned in the introduction, the statistical data
needed for accurate diagnosis of a problem is stored in the Automatic Workload Repository (AWR). ADDM is
diagnostic software built into Oracle Database. ADDM examines and analyzes data captured in Automatic Workload
Repository (AWR) to determine possible database performance problems. The Automatic Database Diagnostic
Monitor (ADDM):

 Analyzes the AWR data on a regular basis

 Diagnoses the root causes of performance problems
 Provides recommendations for correcting any problems
 Identifies non-problem areas of the system

ADDM examines and analyzes data captured in Automatic Workload Repository (AWR) to determine possible
database performance problems. ADDM then does the following:

 Locates the root causes of the performance problems

 Provides recommendations for correcting them
 Quantifies the expected benefits
 Identifies areas where no action is necessary

Because AWR is a repository of historical performance data, ADDM can analyze performance issues after the event,
often saving time and resources in reproducing a problem. In most cases, ADDM output should be the first place
that a DBA looks when notified of a performance problem. ADDM provides the following benefits:

 Automatic performance diagnostic report every hour by default

2
  Problem diagnosis based on decades of tuning expertise

 Time-based quantification of problem impacts and recommendation benefits

 Identification of root cause, not symptoms

 Recommendations for treating the root causes of problems

 Identification of non-problem areas of the system

 Minimal overhead to the system during the diagnostic process

It is important to realize that tuning is an iterative process, and fixing one problem can cause the bottleneck to shift
to another part of the system. Even with the benefit of ADDM analysis, it can take multiple tuning cycles to reach
acceptable system performance. ADDM benefits apply beyond production systems; on development and test
systems, ADDM can provide an early warning of performance issues.

3. ADDM Analysis

An ADDM analysis can be performed on a pair of AWR snapshots and a set of instances from the same database.
The pair of AWR snapshots define the time-period for analysis, and the set of instances define the target for analysis.
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.
If you are using Oracle Real Application Clusters (Oracle RAC), ADDM has three analysis modes:

 Database

In Database mode, ADDM analyzes all instances of the database.

 Instance

In Instance mode, ADDM analyzes a particular instance of the database.

 Partial

In Partial mode, ADDM analyzes a subset of all database instances.

If you are not using Oracle RAC, ADDM can only function in Instance mode because there is only one instance of
the database.

An ADDM analysis is performed each time an AWR snapshot is taken and the results are saved in the database. The
time period analyzed by ADDM is defined by the last two snapshots (the last hour by default). ADDM will always
analyze the specified instance in Instance mode. For non-Oracle RAC or single instance environments, the analysis
performed in the Instance mode is the same as a database-wide analysis. If you are using Oracle RAC, ADDM will
also analyze the entire database in Database mode. After an ADDM completes its analysis, you can view the results
using Oracle Enterprise Manager, or by viewing a report in a SQL*Plus session.

By reducing DB time, the database is able to support more user requests using the same resources, which increases
throughput. The problems reported by ADDM are sorted by the amount of DB time they are responsible for. System
areas that are not responsible for a significant portion of DB time are reported as non-problem areas.

The types of problems that ADDM considers include the following:

3
  CPU bottlenecks - Is the system CPU bound by Oracle Database or some other application?

 Undersized Memory Structures - Are the Oracle Database memory structures, such as the SGA, PGA, and
buffer cache, adequately sized?

 I/O capacity issues - Is the I/O subsystem performing as expected?

 High load SQL statements - Are there any SQL statements which are consuming excessive system resources?

 High load PL/SQL execution and compilation, and high-load Java usage

 Oracle RAC specific issues - What are the global cache hot blocks and objects; are there any interconnect
latency issues?

 Sub-optimal use of Oracle Database by the application - Are there problems with poor connection
management, excessive parsing, or application level lock contention?

 Database configuration issues - Is there evidence of incorrect sizing of log files, archiving issues, excessive
checkpoints, or sub-optimal parameter settings?

 Concurrency issues - Are there buffer busy problems?

 Hot objects and top SQL for various problem areas

ADDM analysis is performed top down, first identifying symptoms, and then refining them to reach the root causes
of performance problems. The goal of the analysis is to reduce a single throughput metric called DB time. DB time is
the cumulative time spent by the database in processing user requests. It includes wait time and CPU time of all
non-idle user sessions. DB time is displayed in the V$SESS_TIME_MODEL and V$SYS_TIME_MODEL views.

The goal of database performance tuning is to reduce the DB time of the system for a given workload. By reducing
DB time, the database can support more user requests by using the same or fewer resources. ADDM reports system
resources that are using a significant portion of DB time as problem areas and sorts them in descending order by
the amount of related DB time spent.

ADDM also documents the non-problem areas of the system. For example, wait event classes that are not
significantly impacting the performance of the system are identified and removed from the tuning consideration at
an early stage, saving time and effort that would be spent on items that do not impact overall system performance.

Running an ADDM or AWR report 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

4
 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

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.

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.

4. Using ADDM with Oracle Real Application Clusters

If you are using Oracle RAC, you can run ADDM in Database analysis mode to analyze the throughput performance
of all instances of the database. In Database mode, ADDM considers DB time as the sum of the database time for
all database instances. Using the Database analysis mode enables you to view all findings that are significant to the
entire database in a single report, instead of reviewing a separate report for each instance.

The Database mode report includes findings about database resources (such as I/O and interconnect). The report
also aggregates findings from the various instances if they are significant to the entire database. For example, if the
CPU load on a single instance is high enough to affect the entire database, the finding will appear in the Database
mode analysis, which will point to the particular instance responsible for the problem.
5
5. ADDM Analysis Results
In addition to problem diagnostics, ADDM recommends possible solutions. ADDM analysis results are represented
as a set of findings. Each ADDM finding can belong to one of the following types:

 Problem findings describe the root cause of a database performance problem.

 Symptom findings contain information that often lead to one or more problem findings.

 Information findings are used for reporting information that are relevant to understanding the performance
of the database, but do not constitute a performance problem (such as non-problem areas of the database
and the activity of automatic database maintenance).

 Warning findings contain information about problems that may affect the completeness or accuracy of the
ADDM analysis (such as missing data in the AWR).

Each problem finding is quantified by an impact that is an estimate of the portion of DB time caused by the finding's
performance issue. A problem finding can be associated with a list of recommendations for reducing the impact of
the performance problem. The types of recommendations include:

 Hardware changes: adding CPUs or changing the I/O subsystem configuration

 Database configuration: changing initialization parameter settings
 Schema changes: hash partitioning a table or index, or using automatic segment-space management
(ASSM)
 Application changes: using the cache option for sequences or using bind variables
 Using other advisors: running SQL Tuning Advisor on high-load SQL or running the Segment Advisor on
hot objects
A list of recommendations can contain various alternatives for solving the same problem; you do not have to apply
all the recommendations to solve a specific problem. Each recommendation has a benefit which is an estimate of
the portion of DB time that can be saved if the recommendation is implemented. Recommendations are composed
of actions and rationales. You must apply all the actions of a recommendation to gain the estimated benefit. The
rationales are used for explaining why the set of actions were recommended and to provide additional information
to implement the suggested recommendation.

6. Reviewing the ADDM Analysis

By default, ADDM runs every hour to analyze snapshots taken by AWR during that period. If the database finds
performance problems, then it displays the results of the analysis under Diagnostics in the Summary section on the
Database Home page.

The ADDM Findings link shows how many ADDM findings were found in the most recent ADDM analysis.

To view ADDM findings:

1. Access the Database Home page.

6
 2. From the Performance menu, select Advisors Home.

If the Database Login page appears, then log in as a user with administrator privileges. The Advisor Central page
appears.

3. In the Results section of Advisor Tasks, select the most recent ADDM result, and then click View Result.

The Automatic Database Diagnostic Monitor (ADDM) page appears. The results of the ADDM run are displayed.

Figure 6.1 The Automatic Database Diagnostic Monitor Page

On the Automatic Database Diagnostic Monitor (ADDM) page, the Database Activity chart shows the database
activity during the ADDM analysis period. Database activity types are defined in the legend based on their
corresponding colors in the chart. Each icon below the chart represents a different ADDM task, which in turn
corresponds to a pair of snapshots saved in AWR.

In the above figure 6.1, stacked area chart in the Database Activity section shows that the most database activity
was between 2:00 p.m. to 4:30 p.m. on December 30. During that time, the activity was dominated by CPU and wait
classes, with very little I/O happening.

In the ADDM Performance Analysis section, ADDM findings are listed in descending order, from highest to least
impact. The Informational Findings section lists areas that have no performance impact and are for information
only.
7
 4. Optionally, click the Zoom icons to shorten or lengthen the analysis period displayed on the chart.

5. To view the ADDM findings in a report, click View Report.

The View Report page appears.

You can click Save to File to save the report for later access.

7. Reviewing ADDM Analysis Results: Example

Consider the following section of an ADDM report Example ADDM Report

FINDING 1: 31% impact (7798 seconds)

------------------------------------

SQL statements were not shared, due to the usage of literals. This resulted in additional hard parses, which were
consuming significant database time.

RECOMMENDATION 1: Application Analysis, 31% benefit (7798 seconds)

ACTION: Investigate application logic for possible use of bind variables instead of literals. Alternatively, you may
set the parameter

"Cursor sharing" to "force".

RATIONALE: SQL statements with PLAN_HASH_VALUE 3106087033 were found to be using literals. Look in V$SQL
for examples of such SQL statements.

In the example, the finding points to a particular root cause, the usage of literals in SQL statements, which is
estimated to have an impact of about 31% of total DB time in the analysis period.

The finding has a recommendation associated with it, composed of one action and one rationale. The action
specifies a solution to the problem found and is estimated to have a maximum benefit of up to 31% DB time in the
analysis period. Note that the benefit is given as a portion of the total DB time and not as a portion of the finding's
impact. The rationale provides additional information on tracking potential SQL statements that were using literals
and causing this performance issue. Using the specified plan hash value of SQL statements that could be a problem,
a DBA could quickly examine a few sample statements.

When a specific problem has multiple causes, the ADDM may report multiple problem and symptom findings. In
this case, the impacts of these multiple findings can contain the same portion of DB time. Because the performance
8
issues of findings can overlap, the sum of the impacts of the findings can exceed 100% of DB time. For example, if
a system performs many reads, then ADDM might report a SQL statement responsible for 50% of DB time due to
I/O activity as one finding, and an undersized buffer cache responsible for 75% of DB time as another finding.

When multiple recommendations are associated with a problem finding, the recommendations may contain
alternatives for solving the problem. In this case, the sum of the recommendations' benefits may be higher than the
finding's impact.

When appropriate, an ADDM action may have multiple solutions for you to choose from. In the example, the most
effective solution is to use bind variables. However, it is often difficult to modify the application. Changing the value
of the CURSOR_SHARING initialization parameter is much easier to implement and can provide significant
improvement.

8. Setting up ADDM
Automatic database diagnostic monitoring is enabled by default and is controlled by
the CONTROL_MANAGEMENT_PACK_ACCESS and the STATISTICS_LEVEL initialization parameters.

The CONTROL_MANAGEMENT_PACK_ACCESS parameter should be set

to DIAGNOSTIC or DIAGNOSTIC+TUNING to enable automatic database diagnostic monitoring. The default
setting is DIAGNOSTIC+TUNING. Setting CONTROL_MANAGEMENT_PACK_ACCESS to NONE disables ADDM.

The STATISTICS_LEVEL parameter should be set to the TYPICAL or ALL to enable automatic database diagnostic
monitoring. The default setting is TYPICAL. Setting STATISTICS_LEVEL to BASIC disables many Oracle Database
features, including ADDM, and is strongly discouraged.

ADDM analysis of I/O performance partially depends on a single argument, DBIO_EXPECTED that describes the
expected performance of the I/O subsystem. The value of DBIO_EXPECTED is the average time it takes to read a
single database block in microseconds. Oracle Database uses the default value of 10 milliseconds, which is an
appropriate value for most modern hard drives. If your hardware is significantly different, such as very old hardware
or very fast RAM disks, consider using a different value.

To determine whether ADDM is enabled:

1. Access the Database Home page.

2. From the Administration menu, select Initialization Parameters.

If the Database Login page appears, then log in as a user with administrator privileges. The Initialization
Parameters page appears.

3. In the Name field, enter statistics level and then click Go.

The Initialization Parameters table shows the setting of this initialization parameter.

4. Do one of the following:

 If the Value list shows ALL or TYPICAL, then do nothing.

 If the Value list shows BASIC, then select ALL or TYPICAL, and then click Apply.
9
 5. In the Name field, enter control_management_pack_access, and then click Go.

The table shows the setting of this initialization parameter.

6. Do one of the following:

 If the Value column shows DIAGNOSTIC or DIAGNOSTIC+TUNING, then do nothing.
 If the Value column shows NONE, then select DIAGNOSTIC or DIAGNOSTIC+TUNING and
click Apply.

8.1 Setting the DBIO_EXPECTED Parameter

ADDM analysis of I/O performance partially depends on a single argument, DBIO_EXPECTED that describes the
expected performance of the I/O subsystem. The value of DBIO_EXPECTED is the average time it takes to read a
single database block, in microseconds. Oracle Database uses the default value of 10 milliseconds, which is an
appropriate value for most hard drives. You can choose a different value based on the characteristics of your
hardware.

To determine the correct setting for the DBIO_EXPECTED initialization parameter:

1. Measure the average read time of a single database block for your hardware.

This measurement must be taken for random I/O, which includes seek time if you use standard hard drives.
Typical values for hard drives are between 5000 and 20000 microseconds.

2. Set the value one time for all subsequent ADDM executions.

For example, if the measured value is 8000 microseconds, then execute the following PL/SQL code as
the SYS user:

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

9. Diagnosing Database Performance Problems with ADDM

To diagnose database performance problems, first review the ADDM analysis results that are automatically created
each time an AWR snapshot is taken. If a different analysis is required (such as a longer analysis period, using a
different DBIO_EXPECTED setting, or changing the analysis mode), you can run ADDM manually as described in this
section.

ADDM can analyze any two AWR snapshots (on the same database), as long as both snapshots are still stored in
the AWR (have not been purged). ADDM can only analyze instances that are started before the beginning snapshot
and remain running until the ending snapshot. Additionally, ADDM will not analyze instances that experience
significant errors when generating the AWR snapshots. In such cases, ADDM will analyze the largest subset of
instances that did not experience these problems.

The primary interface for diagnostic monitoring is Oracle Enterprise Manager. Whenever possible, you should run
ADDM using Oracle Enterprise Manager. If Oracle Enterprise Manager is unavailable, you can run ADDM using
the DBMS_ADDM package. In order to run the DBMS_ADDM APIs, the user must be granted the ADVISOR privilege.
10
9.1 Running ADDM in Database Mode
For Oracle RAC configurations, you can run ADDM in Database mode to analyze all instances of the databases. For
single-instance configurations, you can still run ADDM in Database mode; ADDM will simply behave as if running
in Instance mode.

To run ADDM in Database mode, use the DBMS_ADDM.ANALYZE_DB procedure:

BEGIN

DBMS_ADDM.ANALYZE_DB (

task_name IN OUT VARCHAR2,

Begin snapshot IN NUMBER,

End snapshot IN NUMBER,

db_id IN NUMBER := NULL);

END;

The task_name parameter specifies the name of the analysis task that will be created.
The begin_snapshot parameter specifies the snapshot number of the beginning snapshot in the analysis period.
The end_snapshot parameter specifies the snapshot number of the ending snapshot in the analysis period.
The db_id parameter specifies the database identifier of the database that will be analyzed. If unspecified, this
parameter defaults to the database identifier of the database to which you are currently connected.

The following example creates an ADDM task in database analysis mode, and executes it to diagnose the
performance of the entire database during the time period defined by snapshots 137 and 145:

VAR tname VARCHAR2(30);

BEGIN

:tname := 'ADDM for 7PM to 9PM';

DBMS_ADDM.ANALYZE_DB(:tname, 137, 145);

END;

9.2 Running ADDM in Instance Mode

To analyze a particular instance of the database, you can run ADDM in Instance mode. To run ADDM in Instance
mode, use the DBMS_ADDM.ANALYZE_INST procedure:

BEGIN

DBMS_ADDM.ANALYZE_INST (

task_name IN OUT VARCHAR2,

11

begin_snapshot IN NUMBER,
 end_snapshot IN NUMBER,

instance_number IN NUMBER := NULL,

db_id IN NUMBER := NULL);

END;

The task_name parameter specifies the name of the analysis task that will be created.
The begin_snapshot parameter specifies the snapshot number of the beginning snapshot in the analysis period.
The end_snapshot parameter specifies the snapshot number of the ending snapshot in the analysis period.
The instance_number parameter specifies the instance number of the instance that will be analyzed. If unspecified,
this parameter defaults to the instance number of the instance to which you are currently connected.
The db_id parameter specifies the database identifier of the database that will be analyzed. If unspecified, this
parameter defaults to the database identifier of the database to which you are currently connected.

The following example creates an ADDM task in instance analysis mode, and executes it to diagnose the
performance of instance number 1 during the time period defined by snapshots 137 and 145:

VAR tname VARCHAR2(30);

BEGIN

:tname := 'my ADDM for 7PM to 9PM';

DBMS_ADDM.ANALYZE_INST(:tname, 137, 145, 1);

END;

9.3 Running ADDM in Partial Mode

To analyze a subset of all database instances, you can run ADDM in Partial mode. To run ADDM in Partial mode, use
the DBMS_ADDM.ANALYZE_PARTIAL procedure:

BEGIN

DBMS_ADDM.ANALYZE_PARTIAL (

task_name IN OUT VARCHAR2,

instance_numbers IN VARCHAR2,

begin_snapshot IN NUMBER,

end_snapshot IN NUMBER,

db_id IN NUMBER := NULL);

END;

/
12
The task_name parameter specifies the name of the analysis task that will be created.
The instance_numbers parameter specifies a comma-delimited list of instance numbers of instances that will be
analyzed. The begin_snapshotparameter specifies the snapshot number of the beginning snapshot in the analysis
period. The end_snapshot parameter specifies the snapshot number of the ending snapshot in the analysis period.
The db_id parameter specifies the database identifier of the database that will be analyzed. If unspecified, this
parameter defaults to the database identifier of the database to which you are currently connected.

The following example creates an ADDM task in partial analysis mode, and executes it to diagnose the performance
of instance numbers 1, 2, and 4, during the time period defined by snapshots 137 and 145:

VAR tname VARCHAR2(30);

BEGIN

:tname: = 'my ADDM for 7PM to 9PM';

DBMS_ADDM.ANALYZE_PARTIAL (: tname, '1,2,4', 137, 145);

END;

9.4 Displaying an ADDM Report

To display a text report of an executed ADDM task, use the DBMS_ADDM.GET_REPORT function:

DBMS_ADDM.GET_REPORT (

task_name IN VARCHAR2

RETURN CLOB);

The following example displays a text report of the ADDM task specified by its task name using the tname variable:

SET LONG 1000000 PAGESIZE 0;

SELECT DBMS_ADDM.GET_REPORT(:tname) FROM DUAL;

Note that the return type of a report is a CLOB, formatted to fit line size of 80. For information about reviewing the
ADDM analysis results in an ADDM report.

10. Views with ADDM Information

Typically, you should view output and information from ADDM using Oracle Enterprise Manager or ADDM reports.

However, you can display ADDM information through the DBA_ADVISOR views. This group of views includes:

 DBA_ADVISOR_FINDINGS

This view displays all the findings discovered by all advisors. Each finding is displayed with an associated finding ID,
name, and type. For tasks with multiple executions, the name of each task execution associated with each finding is
also listed.

 DBA_ADDM_FINDINGS
13
This view contains a subset of the findings displayed in the related DBA_ADVISOR_FINDINGS view. This view only
displays the ADDM findings discovered by all advisors. Each ADDM finding is displayed with an associated finding
ID, name, and type.

 DBA_ADVISOR_FINDING_NAMES

List of all finding names registered with the advisor framework.

 DBA_ADVISOR_RECOMMENDATIONS

This view displays the results of completed diagnostic tasks with recommendations for the problems identified in
each execution. The recommendations should be reviewed in the order of the RANK column, as this relays the
magnitude of the problem for the recommendation. The BENEFIT column displays the benefit to the system you
can expect after the recommendation is performed. For tasks with multiple executions, the name of each task
execution associated with each advisor task is also listed.

 DBA_ADVISOR_TASKS

This view provides basic information about existing tasks, such as the task ID, task name, and when the task was
created. For tasks with multiple executions, the name and type of the last or current execution associated with each
advisor task is also listed.

11. Reviewing the ADDM Analysis

By default, ADDM runs every hour to analyze snapshots taken by AWR during that period. If the database finds
performance problems, then it displays the results of the analysis under Diagnostics in the Summary section on the
Database Home page.

The ADDM Findings link shows how many ADDM findings were found in the most recent ADDM analysis.

To view ADDM findings:

1. Access the Database Home page.

2. From the Performance menu, select Advisors Home.

If the Database Login page appears, then log in as a user with administrator privileges. The Advisor Central page
appears.

3. In the Results section of Advisor Tasks, select the most recent ADDM result, and then click View Result.

The Automatic Database Diagnostic Monitor (ADDM) page appears. The results of the ADDM run are displayed.

Figure 11 The Automatic Database Diagnostic Monitor Page

14
On the Automatic Database Diagnostic Monitor (ADDM) page, the Database Activity chart shows the database
activity during the ADDM analysis period. Database activity types are defined in the legend based on their
corresponding colors in the chart. Each icon below the chart represents a different ADDM task, which in turn
corresponds to a pair of snapshots saved in AWR.

In the above figure 11, stacked area chart in the Database Activity section shows that the most database activity
was between 2:00 p.m. to 4:30 p.m. on December 30. During that time, the activity was dominated by CPU and wait
classes, with very little I/O happening.

In the ADDM Performance Analysis section, ADDM findings are listed in descending order, from highest to least
impact. The Informational Findings section lists areas that have no performance impact and are for information
only.

4. Optionally, click the Zoom icons to shorten or lengthen the analysis period displayed on the chart.
15
 5. To view the ADDM findings in a report, click View Report.

The View Report page appears.

You can click Save to File to save the report for later access.

Interpretation of Automatic Database Diagnostic Monitor Findings

The ADDM analysis results are represented as a set of findings. Each ADDM finding belongs to one of three types:

 Problem

Findings that describe the root cause of a database performance issue

 Symptom

Findings that contain information that often leads to one or more problem findings

 Information

Findings that are used to report areas of the system that do not have a performance impact

Each problem finding is quantified with an estimate of the portion of DB time that resulted from the performance
problem.

When a specific problem has multiple causes, ADDM may report multiple findings. In this case, the impacts of these
multiple findings can contain the same portion of DB time. Because performance problems can overlap, summing
the impacts of the reported findings can yield a number higher than 100% of DB time. For example, if a system
performs many read I/O operations, ADDM may report a SQL statement responsible for 50% of DB time due to I/O
activity as one finding, and an undersized buffer cache responsible for 75% of DB time as another finding.

A problem finding can be associated with a list of recommendations for reducing the impact of a performance
problem. Each recommendation has a benefit that is an estimate of the portion of DB time that can be saved if the
recommendation is implemented. When multiple recommendations are associated with an ADDM finding, the
recommendations may contain alternatives for solving the same problem. In this case, the sum of the benefits may
be higher than the impact of the finding. You do not need to apply all the recommendations to solve the same
problem.

Recommendations are composed of actions and rationales. You must apply all the actions of a recommendation to
gain its estimated benefit. The rationales explain why the set of actions are recommended, and provide additional
information for implementing them. An ADDM action may present multiple solutions. If this is the case, then choose
the easiest solution to implement.

12. Implementing ADDM Recommendations

This section describes how to implement ADDM recommendations. ADDM findings are displayed in the Automatic
Database Diagnostic Monitor (ADDM) page under ADDM Performance Analysis.

To implement ADDM recommendations:

1. Access the Database Home page.

2. From the Performance menu, select Advisors Home.

16
If the Database Login page appears, then log in as a user with administrator privileges. The Advisor Central page
appears.

3. In the Results section of Advisor Tasks, select the most recent ADDM result, then click View Result.

The Automatic Database Diagnostic Monitor (ADDM) page appears.

4. In the Database Activity section, click the chart icon for the ADDM run to investigate.

The data in the ADDM Performance Analysis section changes based on the ADDM run that you selected.

5. In the ADDM Performance Analysis table, click the ADDM finding that has the greatest impact.

In the following screenshot of the ADDM Performance Analysis table, the finding with the greatest impact is Top
SQL Statements.

The Performance Finding Details page appears.

In the following screen shot of the Performance Finding Details page, five recommendations are shown. The first is
estimated to have a maximum benefit of up to 26.7% of DB time in the analysis period. The second recommendation
is estimated to have a maximum benefit of up to 10.9% of DB time, the third also has a maximum of 10.9%, the
fourth has a maximum of 9.9%, and the fifth has a maximum of 5%.

17
 6. Under Recommendations, click Show to review the recommendations and required actions for each
recommendation.

The Category column displays the category of the recommendation. The Benefit (%) column displays the estimated
benefit of implementing the recommendation.

Figure below shows the recommendations for the first item in the Recommendations table.

Figure 12.1 Recommendations on the Performance Finding Details Page

7. If additional information is available about why the set of actions was recommended, then click Additional
Information, or review the content displayed under Additional Information.

For example, the following screenshot shows an Undersized Buffer Cache finding that contains additional
information that indicates the recommended value of the DB_CACHE_SIZE initialization parameter.
18
Figure 12.2 Performance Finding Details: Undersized Buffer Cache

To view the history of a finding, click Finding History.

The Finding History page appears (See Figure 12.3). The following screenshot shows the Finding History page for
the top SQL statements. 19
Figure 12.3 The Finding History Page

The Finding History page shows how often a particular finding has occurred in a selected 3-hour interval. You can
use this information to determine whether the finding was a transient or a persistent problem in the system. Based
on this information, you can determine whether the actions associated with the finding should be implemented.

The Active Sessions stacked area chart shows the impact of the finding and of the other loads on the system. You
can change the display as follows:

a. To move the 3-hour interval, click and drag the shaded box in the Active Sessions chart.

b. To change dates, enter the desired date in the View field, and then click Go.

c. To view details about a finding, under Detail for Selected 3 Hour Interval, click the link in
the Finding Details column to display the Performance Finding Details page for the corresponding
ADDM finding.

8. Optionally, create a filter to suppress known findings that have been tuned or cannot be tuned further. To
create filters for a selected ADDM finding:

a. Click Filters.

The Filters for finding page appears.

b. Click Create.

The Create Filter for finding page appears.

c. In the Name field, enter a name for the ADDM filter.

d. In the Active Sessions field, specify the filter criteria in terms of the number of active sessions.

The database filters the ADDM finding for future ADDM runs if the number of active sessions for the finding is less
than the specified filter criteria.
20
 e. In the % Active Sessions field, specify the filter criteria in terms of percentage of active sessions.

The database filters the ADDM finding for future ADDM runs if the number of active sessions for the finding is less
than the specified filter criteria.

f. Click OK.

9. Perform the required action of a chosen recommendation.

Depending on the type of action you choose to perform, various options may be available, such
as Implement or Run Advisor Now. These options enable you to implement the recommendation immediately
with a single mouse click.

In the example shown in Figure 12.1, the simplest solution is to click Run Advisor Now to immediately run a SQL
Tuning Advisor task on the SQL statement.

21