| Oracle® Database 2 Day + Performance Tuning Guide 11g Release 1 (11.1) Part Number B28275-01 |
|
|
View PDF |
| Oracle® Database 2 Day + Performance Tuning Guide 11g Release 1 (11.1) Part Number B28275-01 |
|
|
View PDF |
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 (Enterprise Manager). 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. Reviewing ADDM findings and implementing the recommendations are tasks that you should perform daily as part of the 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.
This chapter contains the following sections:
Reviewing the Automatic Database Diagnostic Monitor Analysis
Interpretation of Automatic Database Diagnostic Monitor Findings
Implementing Automatic Database Diagnostic Monitor Recommendations
See Also:
Oracle Database Performance Tuning Guide for information about using the DBMS_ADVISOR package to diagnose and tune the database with the Automatic Database Diagnostic Monitor
ADDM is self-diagnostic software built into Oracle Database. ADDM examines and analyzes data captured in the Automatic Workload Repository (AWR) to determine possible performance problems in Oracle Database. ADDM then locates the root causes of the performance problems, provides recommendations for correcting them, and quantifies the expected benefits. ADDM also identifies areas where no action is necessary.
This section contains the following topics:
An ADDM analysis is performed after each AWR snapshot (every hour by default), and the results are saved in the database. You can then view the results by means of Oracle Enterprise Manager. Before using another performance tuning method described in this guide, first review the results of the ADDM analysis.
The ADDM analysis is performed from the top down, first identifying symptoms and then refining the analysis to reach the root causes of performance problems. ADDM uses the DB time statistic to identify performance problems. DB time is the cumulative time spent by the database in processing user requests, including both the wait time and CPU time of all user sessions that are not idle.
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 is able to support more user requests by using the same or a smaller amount of 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. For more information about the DB time statistic, see "Time Model Statistics".
In addition to diagnosing performance problems, ADDM recommends possible solutions. When appropriate, ADDM recommends multiple solutions from which you can choose. ADDM recommendations include the following:
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 statements or running the Segment Advisor on hot objects
ADDM benefits apply beyond production systems. Even on development and test systems, ADDM can provide an early warning of potential performance problems.
Performance tuning is an iterative process. Fixing one problem can cause a bottleneck to shift to another part of the system. Even with the benefit of the ADDM analysis, it can take multiple tuning cycles to reach a desirable level of performance.
See Also:
Oracle Database 2 Day DBA for information the Segment Advisor
In an Oracle Real Application Clusters (Oracle RAC) environment, you can use ADDM to analyze the throughput performance of a database cluster. ADDM for Oracle RAC considers DB time as the sum of database times for all database instances and reports findings that are significant at the cluster level. For example, the I/O levels of each cluster node may be insignificant when considered locally, but the aggregate I/O level may be a significant problem for the cluster as a whole.
See Also:
Oracle Database 2 Day + Real Application Clusters Guide for information about using ADDM for Oracle RAC
This section describes how to configure ADDM and contains the following topics:
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 initialization parameter should be set to DIAGNOSTIC+TUNING (default) or DIAGNOSTIC to enable automatic database diagnostic monitoring. Setting CONTROL_MANAGEMENT_PACK_ACCESS to NONE disables many Oracle Database features, including ADDM, and is strongly discouraged.
The STATISTICS_LEVEL initialization parameter should be set to the TYPICAL (default) or ALL to enable automatic database diagnostic monitoring. Setting STATISTICS_LEVEL to BASIC disables many Oracle Database features, including ADDM, and is strongly discouraged.
To determine whether ADDM is enabled:
From the Database Home page, click Server.
The Server subpage appears.
In the Database Configuration section, click Initialization Parameters.
The Initialization Parameters page appears.
In the Name field, enter statistics_level and then click Go.
The table shows the setting of this initialization parameter.
Do one of the following:
If the Value column shows ALL or TYPICAL, then do nothing.
If the Value column shows BASIC, then select ALL or TYPICAL and click Apply.
In the Name field, enter control_management_pack_access and then click Go.
The table shows the setting of this initialization parameter.
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.
See Also:
Oracle Database Reference for information about the STATISTICS_LEVEL initialization parameter
Oracle Database Reference for information about the CONTROL_MANAGEMENT_PACK_ACCESS initialization 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. If your hardware is significantly different, then consider using a different value.
To determine the correct setting for the DBIO_EXPECTED initialization parameter:
Measure the average read time of a single database block for your hardware.
This measurement needs to 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.
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);
By default, the Automatic Workload Repository (AWR) generates snapshots of performance data once every hour, and retains the statistics in the workload repository for 8 days. You can change the default values for both the snapshot interval and the retention period.
Oracle recommends that you adjust the AWR retention period to at least a month. You can also extend the period to one business cycle so you can compare data across time frames such as the close of the fiscal quarter. You can also create AWR baselines to retain snapshots indefinitely for important time periods.
The data in the snapshot interval is analyzed by ADDM. ADDM compares the difference between snapshots to determine which SQL statements to capture, based on the effect on the system load. The ADDM analysis shows the number of SQL statements that need to be captured over time.
This section contains the following topics:
Manually creating snapshots is usually not necessary because AWR generates snapshots of the performance data once every hour by default. In some cases, however, it may be necessary to manually create snapshots to capture different durations of activity, such as when you want to compare performance data over a shorter period of time than the snapshot interval.
From the Database Home page, click Performance.
The Performance page appears.
Under Additional Monitoring Links, click Snapshots.
The Snapshots page appears with a list of the most recent snapshots.
Click Create.
The Confirmation page appears.
Click Yes.
The Processing: Create Snapshot page is displayed while the snapshot is being taken.
After the snapshot is taken, the Snapshots page reappears with a Confirmation message.
In this example, the ID of the snapshot that was created is 249.
By default, AWR generates snapshots of performance data once every hour. Alternatively, you can modify the default values of both the interval between snapshots and their retention period.
To modify the snapshot settings:
From the Database Home page, click Server.
The Server subpage appears.
In the Statistics Management section, click Automatic Workload Repository.
The Automatic Workload Repository page appears.
In this example, snapshot retention is set to 8 days and snapshot interval is set to 60 minutes.
Click Edit.
The Edit Settings page appears.
For Snapshot Retention, do one of the following:
Select Use Time-Based Retention Period (Days), and in the associated field enter the number of days to retain the snapshots.
Select Retain Forever to retain snapshots indefinitely.
It is recommended that you increase the snapshot retention period whenever possible based on the available disk space.
In this example, the snapshot retention period is changed to 30 days.
For Snapshot Collection, do one of the following:
Select System Snapshot Interval and, in the Interval list, select the desired interval to change the interval between snapshots.
Select Turn off Snapshot Collection to disable snapshot collection.
In this example, the snapshot collection interval is changed to 30 minutes.
Click the link next to Collection Level.
The Initialization Parameter page appears.
To change the statistics level, select the desired value in the Value list for the statistics_level parameter. Click Save to File to set the value in the server parameter file.
In this example, the default value of Typical is used.
Click OK to apply the changes.
The Automatic Workload Repository page appears and displays the new settings.
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 Diagnostic Summary on the Database Home page.
The ADDM Findings link shows how many ADDM findings were found in the most recent ADDM analysis.
On the Database Home page, under Diagnostic Summary, click the link next to ADDM Findings.
The Automatic Database Diagnostic Monitor (ADDM) page appears. The results of the ADDM run are displayed.
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 individual Oracle Database snapshots saved in the Workload Repository.
In this example, the largest block of activity from 8:00 onwards appears in green and corresponds to CPU usage, as described in the legend. This data suggests that CPU may be a performance bottleneck during the ADDM analysis period.
In the ADDM Performance Analysis section, the ADDM findings are listed in descending order, from highest impact to least impact. The Informational Findings section lists the areas that do not have a performance impact and are for informational purpose only.
Optionally, click the Zoom icons to shorten or lengthen the analysis period displayed on the chart.
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.
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 the performance problems can overlap, summing all the impacts of the reported findings can yield a number higher than 100 percent of DB time. For example, if a system performs many read I/O operations, ADDM may report a SQL statement responsible for 50 percent of DB time due to I/O activity as one finding, and an undersized buffer cache responsible for 75 percent 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 the estimated benefit of that recommendation. The rationales explain why the set of actions was recommended, and provide additional information for implementing the suggested recommendation. An ADDM action may present multiple solutions to you. If this is the case, then choose the easiest solution to implement.
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:
On the Database Home page, under Diagnostic Summary, click the link next to ADDM Findings.
The Automatic Database Diagnostic Monitor (ADDM) page appears.
In the ADDM Performance Analysis section, click the ADDM finding that has the greatest impact.
In this example, the finding with the greatest impact is Top SQL by DB Time.
The Performance Finding Details page appears.
Under Recommendations, 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.
In this example, two recommendations are displayed for this finding. The first recommendation contains one action and is estimated to have a maximum benefit of up to 84.6% of DB time in the analysis period. The second recommendation contains one action and is estimated to have a maximum benefit of up to 78.3% of DB time in the analysis period.
If additional information about why the set of actions was recommended is available, then click Additional Information, or review the content displayed under Additional Information.
For example, the Undersized Buffer Cache finding contains additional information to indicate the value of the DB_CACHE_SIZE initialization parameter.
To view the history of a finding, click Finding History.
The Finding History page appears.
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 on the system. Based on this information, you can determine whether the actions associated with the finding should be implemented.
The Active Sessions chart shows the impact of the finding and of the other load on the system. You can change the display as follows:
To move the 3-hour interval, click and drag the shaded box in the Active Sessions chart to the time period in which you are interested.
To change dates, enter the desired date in the View field and click Go.
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.
Optionally, create a filter to suppress known findings that have been tuned or cannot be tuned further. To create filters for this ADDM finding:
Click Filters.
The Filters for Finding page appears.
Click Create.
The Create Filter for Finding page appears.
In the Name field, enter a name for the ADDM filter.
In the Active Sessions field, specify the filter criteria, in terms of the number of active sessions, for this finding.
The ADDM finding will be filtered for future ADDM runs if the number of active sessions for this finding is less than the specified filter criteria.
In the % Active Sessions field, specify the filter criteria, in terms of percentage of active sessions, for this finding.
The ADDM finding will be filtered for future ADDM runs if the number of active sessions for this finding is less than the specified filter criteria.
Click OK.
Perform the required action of a chosen recommendation.
Depending on the type of action you choose to perform, various buttons may be available, such as Implement or Run Advisor Now. These buttons enable you to implement the recommendation immediately with only a single mouse click.
In this example, the simplest solution is to click Run Advisor Now to immediately run a SQL Tuning Advisor task on the SQL statement.
See Also:
You can view the data contained in snapshots taken by AWR using Enterprise Manager. Typically, it is not necessary to review snapshot data because it consists primarily of raw statistics. Instead, you should rely on ADDM, which analyzes these statistics to identify performance problems. Snapshot statistics should be used primarily by advanced users, or by DBAs who are accustomed to using Statspack for performance analysis.
From the Database Home page, click Performance.
The Performance page appears.
Under Additional Monitoring Links, click Snapshots.
The Snapshots page appears with a list of the most recent snapshots.
To view the statistics gathered in a snapshot, click the ID link of the snapshot you want to view.
The Snapshot Details appears, showing the Details subpage.
In this example, statistics gathered from the previous snapshot (snapshot 161) to the selected snapshot (snapshot 162) are displayed.
To view a Workload Repository report of the statistics, click Report.
The Workload Repository report appears.
Optionally, click Save to File to save the report for later access.
