The purpose of this document is to inform the user how to:
Configure AWR for best results.
Produce AWR and ASH Reports.
Interpret AWR and ASH reports.
Automate or batch the production of AWR reports.
Obtain more detailed information from the AWR views.
Although this document has been written with Oracle E-Business Suite in mind, almost all of it is applicable to other applications (e.g. Oracle Fusion Applications). Where there is instruction or advice specific to Oracle E-Business Suite then this is clearly stated.
From 10g onwards, the Oracle database automatically collects and stores workload information in the Automatic Workload Repository (AWR). Prior to that useStatspack.
The AWR has many advantages over Statspack. It has much more information (e.g. wait classes, metrics, OS stats). In addition the repository is maintained automatically and html reports can be produced.
The AWR can be used to identify
SQLs or Modules with heavy loads or potential performance issues. These could be from other processes than the one with reported issues.
Symptoms of those heavy loads (e.g. logical I/O (buffer gets), Physical I/O, contention, waits).
SQLs that could be using sub-optimal execution plans (e.g. buffer gets, segment statistics).
Numbers of executions.
Parsing issues.
General performance issues, e.g. system capacity (I/O, memory, CPU), system/DB configuration.
SGA (shared pool/buffer cache) and PGA sizing advice.
The results are stored in tables and then accessed using the AWR reports.
The AWR stores and reports statistics for each snapshot (identified by snapshot IDs). This is the minimum granularity of time. An AWR report can only report the total of each statistic between two completed snapshots. So the choice of snapshot duration is critical.
For more information seeOracle Database Performance Tuning Guideand My Oracle Support documents:
How to Generate an AWR Report and Create Baselines (Document 748642.1)
FAQ: Automatic Workload Repository (AWR) Reports (Document 1599440.1)
AWR data collection is enabled by default and some database features (such as Automatic Segment Advisor and Undo Advisor) use AWR data, without needing additional pack licenses.
However, the Diagnostic Pack License is required to be able to use AWR reports or any of the information from the AWR (or it’s views).
Statspack is still available from 10g onwards and can be used if the Diagnostic Pack is not licensed.
The Diagnostic Pack can only be purchased with the Enterprise Edition of the Oracle Database.
See My Oracle Support document “AWR Reporting – Licensing Requirements Clarification (Document 1490798.1)” orOracle Database Licensing Informationin the documentation library.
These should be decided before capturing and using AWR data.
The snapshot interval, retention and the number of SQLs captured for each “Top” criteria can be controlled by using the DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS procedure.
This has 4 arguments. Interval, retention, topnsql and dbid.
If NULL is specified for retention, interval or topnsql then the existing values are preserved.
For more information seeOracle Database PL/SQL Packages and Types ReferenceandOracle Database Performance Tuning Guidein the documentation library.
This controls how often snapshots are captured (automatically). It is specified in minutes. The minimum is 10 minutes, the maximum is 1 year. The default is 60 minutes (1 hour). If zero is specified then automatic and manual snapshots are disabled.
The interval should be short enough to provide the granularity required.
Normally 1 hour is sufficient, however it may be necessary to analyze the performance for shorter periods. For short programs (or processes of indeterminate length) it is often best tomanually create snapshotsjust before the program starts and just after it has completed.
For long running processes made up of many smaller stages, where many of the stages may only take short amounts of time (e.g. 15 minutes), then (provided the overall process is not too long) it can be advisable to have a shorter interval (e.g. 15 minutes, 30 minutes). This is often recommended for upgrades. This will increase the overheads incurred by the AWR, but if they are excessive it is likely that there is aperformance issue with AWR snapshot creation.
This controls how long snapshots are retained in the workload. It is specified in days. The default is 8 days for 11g and above (7 days for 10g). The minimum is 1 day, the maximum 100 years. If zero is specified then snapshots will be retained forever.
The retention period should be long enough to allow full analysis of the performance issues to be carried out. Quite often the performance analyst will need to run subsequent reports from the AWR (e.g. AWR SQL Reports, ASH, ADDM or querying AWR views directly).
This controls the number of Top SQLs to flush into the AWR for each of the “Top” criteria (Elapsed Time, CPU Time etc). This can be set to a numeric value, or DEFAULT, MAXIMUM. The minimum value is 30 and the maximum 50,000. DEFAULT will capture the top 30 (statistics_level=TYPICAL) or the top 100 (statistics_level=ALL). MAXIMUM will capture the complete set of SQL in the cursor cache.
Normally the default will suffice. However, there may be situations where a larger set of SQL needs to be monitored.
Note that TOPNSQL can be set to a very high value. However, there will be much more data to capture and store; this could cause space or performance issues.
This is the database identifier (in AWR). NULL specifies the local database.
The values of these arguments can be accessed by querying the view DBA_HIST_WR_CONTROL.
The view sys.wrm$_wr_control gives a little more information.
Note the meaning of the following values in column sys.wrm$_wr_control.topnsql:
2000000000 = DEFAULT
2000000001 = MAXIMUM
From 11g Release 2 onwards, the amount of information (rows) in an AWR report can be controlled by using the DBMS_WORKLOAD_REPOSITORY.AWR_SET_REPORT_THRESHOLDS procedure.
Note that this is only at session level. So the procedure needs to be run again for new sessions.
See My Oracle Support document “How to Control the Number of SQL Statements and other information displayed in AWR Report (Document 1357637.1)”
Automatic statistics gathering by the AWR is disabled if the STATISTICS_LEVEL initialization parameter is set to BASIC. So setting STATISTICS_LEVEL to BASIC is not recommended.
Note that (if STATISTICS_LEVEL=BASIC) AWR statistics can still be captured manually. However, as the collection of many statistics (in-memory) will be disabled, the AWR reports will omit a lot of information (such as segment statistics or memory advice).
Sometimes it is necessary to restrict the AWR reports to a specific time interval (that is not coincidental with the automatically created snapshots). In this case snapshots can be created manually by using the DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT procedure. e.g.
For more information seeOracle Database PL/SQL Packages and Types ReferenceandOracle Database Performance Tuning Guidein the documentation library.
The time period that is required or even the Snapshot IDs may already be known.
However, the following SQLs can be used to identify the Snapshot IDs (the AWR reports do help with the choice of Snapshot IDs; they display the time associated with each Snapshot ID from a specified number of previous days).
Note that the Snapshot ID identifies the time when a snapshot ends. Requesting an AWR Report from Snapshot N to M, will show the activity between the end time for Snapshot N and the end time for Snapshot M.
Alternatively, the following SQL can be used to identify the snapshots when a particular SQL was running:
These scripts are provided for educational purposes only and not supported by Oracle Support Services.
AWR baselines are a series of snapshots that are retained for comparison with subsequent snapshots. The subsequent snapshots may be when performance problems have occurred, or they may be used to compare changes in workload. They can be created by using the procedure DBMS_WORKLOAD_REPOSITORY.create_baseline.
They are retained indefinitely and are not purged from the AWR.
AWR Baselines are not normally used for diagnosing specific performance issues, so they are not covered in much detail here.
For more information see:
Oracle Database PL/SQL Packages and Types ReferenceandOracle Database Performance Tuning Guidein the documentation library.
An AWR report can be generated from SQL*Plus by running the AWR SQL scripts. These are stored under $ORACLE_HOME/rdbms/admin.
The APPS (Oracle E-Business Suite), SYS or SYSTEM users can be used to generate the reports.
Note that AWR Reports can also be produced from Enterprise Manager (AWR Page/Browser, ASH Analytics in 12c).
The main scripts available are:
awrrpt.sql – Produces the AWR report for the current (local) database and instance.
awrrpti.sql – Produces the AWR report for a specified database and instance.
awrgrpt.sql (11g Release 2 and above) – Produces the Global AWR report for all available instances in an Oracle Real Application Clusters (RAC) environment. It does this for the current database.
awrgrpti.sql (11g Release 2 and above) – Produces the Global AWR report for available instances in an Oracle Real Application Clusters (RAC) environment. It does this for a specified database and instances (either one instance, a comma delimited list of some instances or all instances can be chosen).
spawrrac.sql (10g to 11g Release 1) – This is a global AWR report (in text format) for all instances in an Oracle Real Application Clusters (RAC) environment. It does this for a specified database.
There are other scripts available for comparing periods (e.g. awrddrpt.sql, awrddrpi.sql) – seeOracle Database Performance Tuning Guidein the documentation library and My Oracle Support document “Note How to Generate an AWR Report and Create Baselines (Document 748642.1)”
All the scripts are interactive. Arguments cannot be specified in the command line. Seeherefor information on automating AWR Reports.
TheOracle Database Performance Tuning Guidehas more information about the arguments that the AWR reports prompt for, but here is some additional information.
The HTML format is recommended. It is clearer, easier to read and has complete SQL statements (they are not truncated).
If running for a specified instance (e.g. awrrpti.sql) then the script will list the “Instances in this Workload Repository schema” and prompt for the database id (dbid) and instance number (inst_num).
The current (local) instance will be highlighted with an asterix (*) at the left hand side of the row.
Choose an instance. This should be the database and instance on which the performance issue has been observed.
If running for specified instances on a RAC environment (e.g. awrgrpti.sql) then the instance can be a comma separated list of instance numbers or “ALL”.
It is advisable to think about the snapshots required before running these scripts. SeeIdentifying Snapshots to Reportsection.
It is usually best to produce AWR reports for every snapshot during the period of the performance issue.
If a performance issue is long running (straddles more than 2 snapshots) then it is very useful to produce a report for the whole period of the performance issue, program or process. Ideally for snapshots covering the period from just before the program/process starts until just after program/process completes.
If a series of successive programs or processes is being reported on (e.g. Upgrade) then produce a separate report for the period that each successive program is running (if possible).
Specify the report name or enter null for it to default to
awrrpt_
or
awrrpt_rac_
for the RAC reports (awrrptg.sql/awrrptgi.sql)
If using an Oracle Real Application Clusters (RAC) environment then provide.
A separate AWR report (awrrpti.sql) for each node (instance) where the performance issue is occurring. If the node (with the performance issue) is not yet determined then report for all nodes.
An AWR Global report (awrgrpt.sql / awrgrpti.sql) for all nodes (being used) if on 11g Release 2 or above. This will aggregate the statistics for all nodes and highlight differences between nodes. For 10g and 11g Release 1 use the script spawrrac.sql.
If a process (such as an upgrade) is being run on one node (instance) only then the awrrpti.sql report for that instance will suffice.
For more information seeOracle Database Performance Tuning Guidein the documentation library.
Each section of the AWR report contains useful information. However, the following sections are the ones that are most frequently looked at:
Report Header– This contains information about the Database and environment. Along with the snapshot IDs and times.
Report Summary- Top N Timed Foreground Events and Host/Instance CPU
Wait Event Statistics- Foreground Wait Events and Wait Event Histogram
SQL Statistics- SQL ordered by Elapsed Time, CPU Time, Gets, Reads (SQL Statistics), Complete List of SQL Text
Advisory Statistics- Buffer Pool Advisory, PGA Memory Advisory, Shared Pool Advisory, SGA Target Advisory
Enqueue Activity
Segment Statistics- Segments by Logical Reads, Physical Reads, Physical Writes, DB Block Changes, Row Lock Waits, ITL Waits, Buffer Busy Waits
Init.ora Parameters
This contains information about the Database and environment. Along with the snapshot Ids and times.
This indicates the most time consuming events. These are either DB CPU or wait events.
Note that there could be significant waits that are not listed here, so check the Foreground Wait Events (Wait Event Statistics) section for any other time consuming wait events.
A high level of DB CPU is not usually a reason for concern, unless it is accompanied by a high level ofCPU Usageor a few SQLs with high CPU Time (and potentially sub-optimal execution plans).
However, the wait events can give us an indication of performance issues. These performance issues could be due to poor execution plans on individual SQLs, which can be resolved by SQL tuning. Or they could be general performance issues that can be resolved by changes to the DB/system configuration or system resources.
The key things to look for are the total time (and percentage) and the average wait for each event.
For the largest waits look at theWait Event Histogramto identify the distribution of waits.
A high value of a specific wait does not always have one solution. The wait could have several different causes and solutions. In many cases, the wait could be removed by SQL (or application) tuning and this should be considered first before assuming it is a system configuration or resource issue.
For more information on interpreting the top wait events see the “How to interpret the output? > 3. Understanding AWR and ADDM reports > 3.4 Major top waits” section in My Oracle Support document “Oracle E-Business Suite SQL Tuning Tips for Customers (Document 2098522.1)”.
A high level of DB CPU usage in the Top N Foreground Events (or Instance CPU: %Busy CPU) does not necessarily mean that CPU is a bottleneck.
Look at the Host CPU and Instance CPU sections. The key things to look for are the values “%Idle” in the “Host CPU” section and “%Total CPU” in the “Instance CPU” section.
If the “%Idle” is low and “%Total CPU” is high then the instance could have a bottleneck in CPU (be CPU constrained).
Otherwise, the high DB CPU usage just means that the database is spending a lot of time in CPU (processing) compared to I/O and other events.
In either case (CPU 免费云主机域名is a bottleneck or not) there could be individual expensive SQLs with high CPU time, which could indicate sub-optimal execution plans, especially if accompanied with high (buffer) gets.
This is useful because there could be time consuming report wait events that do not appear in the “Top N Timed Foreground Events”.
For the larger waits look at theWait Event Histogramto identify the distribution of waits. Are they closely clustered around an average value or are there a wide variance of values ? Are there a large number of smaller waits or a few larger waits ?
Just above this in the AWR there is a “Foreground Wait Class” section. This is of less use. A wait could have multiple possible causes (in different classes) depending on the context. There are normally only a handful of time consuming waits, which can be analyzed and investigated separately.
For more information on interpreting wait events see the “How to interpret the output? > 3. Understanding AWR and ADDM reports > 3.4 Major top waits” section in My Oracle Support document “Oracle E-Business Suite SQL Tuning Tips for Customers (Document 2098522.1)”.
This can be used to determine the distribution of wait times.
For example, in this case there is a high level of “db file sequential read” waits (21.5%), with an average wait time of 34ms. This is very high. These days less than 5ms is expected and more than 10ms is considered poor.
An analysis of the histogram shows a smooth exponential distribution of wait times beyond a minimum service time clustered around 8ms. This indicates that I/O service times could be slow, but that there is also considerable contention (the I/O load is heavy). There could be a number of reasons and solutions for both.
Incidentally, the absence of waits below 2ms indicates that there is no caching in storage.
Similarly an analysis of the histogram can indicate if a high average time is due to a few individual long waits.
If the following places in the AWR show high levels of RAC wait events (“gc” wait events) then the RAC configuration may need to be changed.
Top N Timed Foreground Events , Foreground Wait Events, Wait Event Histogram
SQL ordered by Cluster Wait Time
Segments by Global Cache Buffer Busy
See the following My Oracle Support documents for more information:
RAC: Frequently Asked Questions (Document 220970.1)
RAC and Oracle Clusterware Best Practices and Starter Kit (Platform Independent) (Document 810394.1)
Using Oracle 11g Release 2 Real Application Clusters with Oracle E-Business Suite Release 12 (Document 823587.1)
Troubleshooting gc block lost and Poor Network Performance in a RAC Environment (Document 563566.1)
Also see Chapter 13 Monitoring Performance in the “Real Application Clusters Administration and Deployment Guide”.
The most useful sections are SQL ordered by Elapsed Time, CPU Time, Gets and Reads. All the sections can be useful in identifying if a particular SQL from a particular module was running during the AWR report period.
For more information on interpreting the SQL Statistics sections see the
“What is the challenging SQL? > 2 From Automatic Workload Repository (AWR)”
or
“How to interpret the output? > 3. Understanding AWR and ADDM reports > 3.5 Top SQLs”
sections in My Oracle Support document “Oracle E-Business Suite SQL Tuning Tips for Customers (Document 2098522.1)”.
This can be used to identify the long running SQLs that could be responsible for a performance issue. It can give useful information about the CPU time, the number of executions and the (SQL) Module.
The Top SQLs can be matched to long running or slow Processes in the application.
The Elapsed time can indicate if a SQL is multi-threaded (either Parallel DML/SQL or multiple workers). In this case the elapsed time will be multiple times the AWR duration (or the observed clock time of the process/SQL). The elapsed time for multi-threaded SQL will be the total of elapsed time for all workers or parallel slaves.
Note that the “SQL Ordered” sections can often contain the PL/SQL call that contains SQLs. So in this case the procedure WF_ENGINE.BackgroundConcurrent (via procedures Background and ProcessStuckProcess ultimately calls the SQL 1wmz1trqkzhzq).
In most cases this section does not reveal much more information than the “SQL Ordered by Elapsed Time” section. However, it does sort by CPU and can output SQLs that are not in the previous section.
A high number of buffer gets is one of the main indicators of SQLs with sub-optimal execution plans.
Bear in mind that the SQL could have a good execution plan and just be doing a lot of work.
If the physical I/O waits (e.g. db file sequential read, db file scattered read, direct path read) are relatively high then this section can indicate which SQLs are responsible.
This section can help identify the SQLs that are responsible for high physical I/O and may indicate sub-optimal execution plans, particularly if the execution plan contains full table scans or large index range scans (where more selective index scans are preferable).
This shows the complete SQL text for all SQL listed in the “SQL ordered by” sections. The SQL Ids in the “SQL ordered by” sections are hyper links to entries in this list.
Note that the advisory statistics within this section (MTTR Advisory, Buffer Pool Advisory, PGA Memory Advisory, Shared Pool Advisory, SGA Target Advisory, Streams Pool Advisory, Java Pool Advisory) are all reported for the last snapshot interval only. If the AWR report covers more than one snapshot interval and the last snapshot interval has a lower workload (e.g. the process being observed completes a long time before the end snapshot) then the advisory statistics could underestimate the advised values.
The My Oracle Support document “How to Read Buffer Cache Advisory Section in AWR and Statspack Reports (Document 754639.1)” gives an excellent explanation of how to read this section.
It can indicate if the buffer cache (or the SGA that contains it) needs to be increased.
Starting at a “Size Factor” of 1 (this indicates the current size of the buffer pool). If the “Physical Read Factor” decreases significantly as the “Size Factor” increases then increasing the buffer cache (SGA Target) will significantly reduce the physical reads and improve performance.
For 10g and above it is recommended to use the sga_target initialization parameter to specify the size of the SGA, so there is no longer a need to specify the size of the buffer cache. The db_cache_size parameter (if specified) defines the minimum size of the default buffer cache.
So the size of Buffer Cache advised here should be added to the advised Shared Pool size and any Large Pool to determine the advised size for the SGA (sga_target). However, there is also an SGA Target Advisory section (see below).
For more information on the recommended initialization parameter values in Oracle E-Business Suite see My Oracle Support documents:
Database Initialization Parameters for Oracle Applications Release 11i (Document 216205.1)
Database Initialization Parameters for Oracle E-Business Suite Release 12 (Document 396009.1)
The My Oracle Support document “How to Read PGA Memory Advisory Section in AWR and Statspack Reports (Document 786554.1)” gives an excellent explanation of how to read this section.
It can indicate if the PGA (defined by the pga_aggregate_target initialization parameter) needs to be increased.
Starting at a “Size Factor” of 1 (this indicates the current size of the PGA). If the “Estd Extra W/A MB Read/Written to Disk” decreases significantly as the “Size Factor” increases then increasing the PGA will improve performance. The best value to use is a PGA Target at the point where the “Estd Extra W/A MB Read/Written to Disk” stops significantly reducing.
It can indicate if the Shared Pool (defined by the shared_pool_size initialization parameter) needs to be increased.
Starting at a “Size Factor” of 1 (this indicates the current size of the shared pool). If the “Est LC Time Saved Factr” increases as the “Size Factor” increases then increasing the shared pool will improve performance.
It can indicate if the SGA (defined by the sga_target initialization parameter) needs to be increased.
Starting at a “Size Factor” of 1 (this indicates the current size of the SGA). If the “Est DB Time (s)” decreases significantly as the “Size Factor” increases then increasing the SGA will significantly reduce the physical reads and improve performance.
Note that the SGA Target Advisory (and Buffer Pool Advisory) may underestimate the performance improvement gained from increasing SGA for situations where there are many workers accessing the same objects at the same time (e.g. AD Parallel jobs (on upgrades), multiple workers (concurrent requests) for batch processes).
This is in the Wait Statistics section.
This can give some more information for enqueue waits (e.g. Requests, Successful gets, Failed gets), which can give an indication of the percentage of times that an enqueue has to wait and the number of failed gets.
For more information on interpreting the SQL Statistics sections see the “How to interpret the output? > 3. Understanding AWR and ADDM reports > 3.6 Top segments” sections in My Oracle Support document “Oracle E-Business Suite SQL Tuning Tips for Customers (Document 2098522.1)”.
Note that the Segment Statistics section (see below) of the AWR will contain no data if the hidden parameter “_object_statistics” is set to FALSE.
If “_object_statistics” is set to FALSE then the object level statistics (logical and physical reads, writes, block changes, locks, ITL etc) will not be gathered. However, the default is “TRUE”.
See My Oracle Support document “”No data exists for this section of the report” in Segment Statistics Section of AWR Report (Document 1570007.1)”.
If a SQL is sub-optimal then this can indicate the tables and indexes where the workload or throwaway occurs and where the performance issue lies. It can be particularly useful if there are no actual statistics elsewhere (e.g. Row Source Operation Counts (STAT lines) in the SQL Trace or no actuals in the SQLT/Display Cursor report).
If there are a high number of physical read waits (db file scattered read, db file sequential read and direct path read) then this section can indicate on which segments (tables or indexes) the issue occurs.
This can help identify sub-optimal execution plan lines. It can also help identify changes to tablespace and storage management that will improve performance.
If there are long running Inserts, Deletes or Updates during the AWR period then this section can help identify those segments (tables or indexes) where most of the workload is occurring.
If there are long running Inserts, Deletes or Updates during the AWR period then this section can help identify those segments (tables or indexes) where most of the workload is occurring.
If there is a high level of “enq: TX – row lock contention” waits then this section can identify the segments (tables/indexes) on which they occur.
If there is a high level of “enq: TX – allocate ITL entry” waits then this section can identify the segments (tables/indexes) on which they occur.
If there is a high level of “Buffer Busy Waits” waits then this section can identify the segments (tables/indexes) on which they occur.
This section can be used to check the values of initialization parameters on the instance. It can also indicate if they have been changed during the AWR period.
For Oracle E-Business Suite any unusual or unexpected values can be checked against My Oracle Support documents:
Database Initialization Parameters for Oracle Applications Release 11i (Document 216205.1)
Database Initialization Parameters for Oracle E-Business Suite Release 12 (Document 396009.1)
Although, it can be easier to use script bde_chk_cbo.sql from My Oracle Support document “EBS initialization parameters – Healthcheck (Document 174605.1)”.
For more advice on initilization parameters see the “How to interpret the output? > 3. Understanding AWR and ADDM reports > 3.3 Basic instance configuration” section in My Oracle Support document “Oracle E-Business Suite SQL Tuning Tips for Customers (Document 2098522.1)”.
This gives some advice on the parameters:
In some casesActive Session History (ASH)reports can be used to give more detailed information on which SQLs, Wait Events, Objects and Row Sources the performance issue occurs.
Analysis of the AWR and ASH reports may lead to one or more of the following conclusions:
One or more expensive SQLs could have sub-optimal execution plans that require tuning.
The database requires configuration changes. This could simply be initialization parameters that require changing or it could be architectural changes such as partitioning, OATM etc.
Underlying system performance issues that could require additional or improved system resources.
There are potential performance issues on the applications tier.
This will dictate which additional diagnostics are required (if any).
There can often be several actions that can improve performance, each to a differing extent.
Just because a small improvement has been identified, possibly by changing an initialization parameter to a recommended value, does not mean that the performance issue has been fixed.
If possible all potential improvements should be prioritized and the largest ones pursued.
In a high percentage of cases there will be one or more expensive SQLs (with potentially sub-optimal execution plans) and SQL specific diagnostics (SQL Trace/TKPROF, Display Cursor/SQL Monitor or SQLT) will be required.
In other cases Operating System Statistics or Application Tier diagnostics may be required.
The AWR reports are interactive. However, they could be automated in the following way.
Input (in the standard AWR reports) is provided using substitution variables, some of which are then populated into bind variables (for use inside anonymous PL/SQL blocks).
A wrapper such as the following could be used to populate the substation variables (e.g. begin_snap, end_snap, dbid, inst_num (or instance_numbers_or_ALL for RAC global reports) and report_name) from command line arguments and then call the AWR report scripts awrrpt.sql or awrgrpt.sql.
A SQL*Plus script containing lines such as the following could then be written to produce a series of reports.
Or a SQL*Plus script, similar to the following, could be used to generate and run a SQL*Plus script that contains command lines to run the wrapper above and produce AWR reports (for the local database and instance) for each snapshot within a defined time period.
It is also possible to automate many of the other AWR reports (e.g. ASH Reports, AWR SQL Reports, AWR Compare Periods report) in a similar way.
These scripts are provided for educational purposes only and not supported by Oracle Support Services.
Note that the DBMS_WORKLOAD_REPOSITORY.AWR_SET_REPORT_THRESHOLDS procedure could be used in the scripts above to change the AWR report thresholds for the number of top SQLs or events output.
e.g.
However, this does not apply to the RAC Global AWR reports, where the thresholds are reset to defaults.
An AWR HTML report for a specific database and instance can be produced by directly using DBMS_WORKLOAD_REPOSITORY functions as follows:
This script is provided for educational purposes only and not supported by Oracle Support Services.
It is also possible to produce other AWR reports using other procedures such as AWR_REPORT_TEXT, AWR_GLOBAL_REPORT_HTML, AWR_GLOBAL_REPORT_TEXT etc.
SeeOracle Database PL/SQL Packages and Types Referencein the documentation library.
The AWR is held in a number of tables on the database.
Here are some of the top views that can be used for more detailed analysis of issues or for comparing/tracking values across snapshots.
Seeherefor a few examples of how SQL can be used on these views to get more detail.
See theOracle Database Referencefor more detailed information and column descriptions.
This contains snapshots of the active session history information taken from memory (V$ACTIVE_SESSION_HISTORY).
It can be used to analyze many things :-
The main wait events for a SQL.
The main SQLs on which a wait event occurs.
When (which snapshots) particular SQLs were running.
On which objects wait events are occurring.
Note that this view contains samples of the activities that are occurring at specific intervals (sample times). It can be used to indicate the main events/activities, however the percentages indicate the number of times an activity/event was sampled and not the actual percentage of time spent in that activity/event.
This is the wait time for the last wait event (0 if currently waiting). So cannot be used to analyze wait events.
For waits that are always less than the sample interval (typically 10 seconds) then this is probably the best indication of activity. However, it can be inaccurate if there are individual waits over 10 seconds.
The count of the number of rows (samples) where a wait occurs can also give some idea of the most popular waits.
Multiplying by the sample interval (10 seconds) gives a very rough approximation of time spent. Note that it is subject to a significant statistical margin of error, particularly for smaller time periods. So it can only give an indication of the most popular waits.
The columns current_obj=# and current_block# can be used to analyze the objects and blocks on which wait events are occurring. The view DBA_HIST_SEG_STAT_OBJ can be used to identify the object names.
In addition the columns p1, p3 and p3 can give additional information about waits, in particular the file, object and block. The p1text, p2text and p3text columns will indicate the content of the p1, p2 and p3 columns for each event.
This contains high level information (DB Version, DB Name, Instance Name, Host Name, Platform Name, Startup Time) for each database instance (stored in the repository). This will normally be just the instances in the cluster (RAC). However, AWR information from other databases can be imported into the AWR for analysis.
This contains execution plans used for each SQL in the AWR.
Unfortunately there are no actual statistics or filters/access predicates stored for each execution plan line.
This can also be useful in identifying whether an index has been used in any execution plans.
This view along with the view DBA_HIST_SEG_STAT_OBJ is used in the Segment Statistics section of the AWR report. The AWR only reports the top objects, so this view can be useful if the statistics are spread across a lot of objects (e.g. partitions/sub-partitions).
Use the delta columns, which have the totals since the previous snapshot.
This is used in the “Top N Timed Foreground Events” and “Wait Events Statistics” section of the AWR report.
Note that the _FG columns refer to the foreground waits. Also, the totals for the previous snapshot have to be deducted to obtain the totals between the two snapshots.
This is used in the “Wait Event Histogram” section of the AWR report.
The totals for the previous snapshot have to be deducted to obtain the totals for the current snapshot.
This is used in the “SQL Statistics” section of the AWR report.
Use the delta columns, which have the totals since the previous snapshot.
This contains information, including the object name, on all the objects referenced in the repository. It is useful for obtaining the object name with many of the views above.
This contains the SQL Text for each SQL ID referenced in the repository.
This contains the snapshot information (e.g. begin and end interval times). So it can be used toidentify the snapshot idsfor a particular time interval (or vice versa).
This contains some AWR settings (snap interval, retention period, top n sql).
The view SYS.WRM$_WR_CONTROL gives a little more information (note the topnsql values: 2000000000 = DEFAULT, 2000000001 = MAXIMUM).
This contains the classification (e.g. Concurrency, User I/O Configuration) of wait events.
Here are some examples of how SQL can be used on the AWR Tables.
To report on the top SQL between two snapshots in the AWR (without running an AWR report) run the following SQL. This example does it for the local database and instance
Note that this particular example outputs the top 100 SQLs ordered by elapsed time, but this can easily be changed to order by other statistics (e.g. CPU time) or output fewer or more SQLs.
The following shows the SQL IDs on which a particular wait occurs between two snapshots in the AWR for the local database and instance.
The following SQL shows the objects on which a particular wait occurs for a given SQL ID between two snapshots in the AWR for the local database and instance.
Note that the view DBA_HIST_ACTIVE_SESS_HISTORY contains samples of the activities that are occurring at specific intervals (sample times). It can be used to indicate the main events/activities, however the percentages indicate the number of times an activity/event was sampled and not the actual percentage of time spent in that activity/event.
These scripts are provided for educational purposes only and not supported by Oracle Support Services.
Automatic Workload Repository (AWR) reports are only available from 10g onwards. They are only available if the Diagnostic Pack is licensed.
It will be necessary to use Statspack prior to 10g.
Statspack is still available from 10g onwards and can be used if the Diagnostic Pack is not licensed.
See My Oracle Support document “AWR Reporting – Licensing Requirements Clarification (Document 1490798.1)” orOracle Database Licensing Informationin the documentation library.
The My Oracle Support document “Systemwide Tuning using STATSPACK Reports (Document 228913.1)” gives an excellent explanation of the information contained in a Statspack report.
The following My Oracle Support documents are useful further reading:
Installing and Configuring StatsPack Package (Document 149113.1)
Gathering a StatsPack snapshot (Document 149121.1)
Statistics Package (STATSPACK) Guide (Document 394937.1)
The My Oracle Support document “How to Identify Resource Intensive SQL (“TOP SQL”) (Document 232443.1)” explains how Statspack can be used to identify resource intensive SQLs.
The AWR Report for a SQL Statement can be used to report on the actual runtime execution plan for long running or resource intensive SQLs that have been identified in the AWR (or elsewhere).
Note that this information can also be obtained from the Display AWR report (dbms_xplan.display_awr).
There are two SQL scripts in $ORACLE_HOME/rdbms/admin that can be used to generate this report:
awrsqrpt.sql – Produces the report for the current (local) database and instance and the specified SQL.
awrsqrpi.sql – Produces the report for a specified database, instance and SQL.
The arguments are very similar to the AWR Reports. And they can be automated in a similar way.
SeeOracle Database Performance Tuning Guidefor more information.
This can be used to report the Active Session History for specified SQLs, Sessions, Wait Classes, Modules etc. It can also be used to report on all activity on a database instance.
It can seamlessly report from both the AWR (view DBA_HIST_ACTIVE_SESS_HISTORY) and memory (view v$ACTIVE_SESSION_HISTORY).
If specific SQLs or Wait Events (classes) have been identified from the AWR Reports then this report can give more information on where the performance issue occurs with those SQLs and Wait Events and (in some cases) why.
SeeOracle Database Performance Tuning Guidefor more information.
An ASH report can be generated from SQL*Plus by running the ASH SQL scripts. These are stored under $ORACLE_HOME/rdbms/admin.
The APPS (Oracle E-Business Suite), SYS or SYSTEM users can be used to generate the reports.
Note that ASH Reports can also be produced from Enterprise Manager.
The main scripts available are:
ashrpt.sql – Produces the ASH report for the current (local) database and instance for all targets (all activity). Also for the default slot width.
ashrpti.sql – Produces the ASH report for a specified database and instance.
These scripts can also be used to produce reports for some or all instances in an Oracle Real Application Clusters (RAC) environment.
All the scripts are interactive. Arguments cannot be specified in the command line. The ASH reports could beautomatedin a similar way to the AWR reports.
TheOracle Database Performance Tuning Guidehas more information about the arguments that the AWR reports prompt for, but here is some additional information.
The HTML format is recommended. It is clearer, easier to read and has complete SQL statements (they are not truncated).
If running for a specified instance (e.g. awrrpti.sql) then the script will list the “Instances in this Workload Repository schema ” and prompt for the database id (dbid) and instance number (inst_num).
The current (local) instance will be highlighted with an asterix (*) at the left hand side of the row.
Choose an instance. This should be the database and instance on which the performance issue has been observed.
For a RAC environment then the instance can be a comma separated list of instance numbers or “ALL”.
The begin time can accept relative times (before the current system time) using the format –HH24:MI or absolute start time using various date/time formats.
The duration is in minutes only (not hours and minutes).The default is a duration up to the current system time.
It is advisable to think about the begin time and duration required before running these scripts. This will normally be the time when a particular program or SQL is running.
This will be limited to the minimum granularity available (typically 10 seconds for active session history from the AWR).
This can only be specified if using ashrpti.sql.
If running ashrpti.sql the active session history can be limited to specific SQLs, Sessions, Wait Classes, Services, Modules, Actions, Client Identifiers or PL/SQL entries by specifying values for these targets. If they are all omitted (NULL) then the active session history for all activity on the specified database instance will be reported.
Note that the wait class is not the wait event name, but the class that the wait events belong to. This is the Event Class for an event, which is visible in the “Top User Events” section of the ASH report or in the “Top N Timed Events” in an AWR report. It is also available in the view V$EVENT_NAME.
Specify the report name or enter null for it to default to
ashrpt_
or
ashrpt_rac_
for the RAC reports (awrrptg.sql/awrrptgi.sql)
Where
For more information seeOracle Database Performance Tuning Guidein the documentation library.
Each section of the ASH report contains useful information. Most are self explanatory.
Note that ASH samples the activities that are occurring at specific intervals (sample times), which are typically every 10 seconds. It can be used to indicate the main events/activities, however the percentages indicate the number of times an activity/event was sampled and not the actual percentage of time spent in that activity/event. If used to indicate actual time spent then there is a significant statistical margin of error, particularly for smaller time periods– and that is why the figures on the ASH will not match the wait event statistics on the AWR.
Be aware that percentages are not expressed as a percentage of total activity (or all wait events/SQL etc.), but as a percentage of the activity captured in the report (e.g. If the report is for one wait class, then 100% of the activity is associated with that wait class).
The most useful sections are :-
This can be useful in identifying more information about waits, particularly hot objects and blocks on some Concurrency and Configuration wait events.
These sections can be used to identify the top wait events on a SQL (or vice versa) along with the top row sources.
Unfortunately the row source does not specify the object, however this may be deduced from the Top DB Objects section below.
This can be useful in identifying which sessions are blocking others and the extent to which this is happening. Again, note that the percentages relate to the activity/wait events included in the report.
This can be useful in identifying the objects on which wait events are occurring. In the absence of actual statistics on an execution plan this can give some idea of the steps of an execution plan where workload or contention is occurring.
Note that logical reads (buffer gets) are not picked up in these statistics, so unless logical reads results in physical I/O or a Concurrency/Configuration wait then it will not show up here. So it is still possible for a SQL to have an inefficient execution plan, with too many buffer gets, and the objects on which the inefficient line(s) occur not show in this section.
The ASH reports are interactive. However, they could be automated in the following way.
Input (in the standard ASH reports) is provided using substitution variables, which are then populated into bind variables (for use inside anonymous PL/SQL blocks).
A wrapper such as the following could be used to populate the substation variables (e.g. begin_time, duration, slot_width, dbid, inst_num and report_name) from command line arguments and then call the ASH report script ashrpti.sql.
A SQL*Plus script containing lines such as the following could then be written to produce a series of reports.
Where
Or a SQL*Plus script, similar to the following, could be used to generate and run a SQL*Plus script that contains command lines to run the wrapper above. This example produces ASH reports for the top 100 SQLs between two AWR snap ids.
These scripts are provided for educational purposes only and not supported by Oracle Support Services.
An ASH HTML report for a specific database and instance can be produced by directly using DBMS_WORKLOAD_REPOSITORY functions as follows:
This script is provided for educational purposes only and not supported by Oracle Support Services.
It is also possible to produce other ASH reports using other procedures such as ASH_REPORT_TEXT, ASH_GLOBAL_REPORT_HTML, ASH_GLOBAL_REPORT_TEXT etc.
SeeOracle Database PL/SQL Packages and Types Referencein the documentation library.
The AWR data is stored in WRH$ tables in the SYS schema (SYSAUX tablespace). These are part of a group of tables known as dictionary tables.
In some cases the AWR tables will have grown significantly due to one or more of the following:
Changes to AWR snapshot settings (increasing retention period, reducing snapshot interval etc.)
The nature of the activity (e.g. an upgrade) being monitored creates more rows in the AWR, e.g. increased latches due to concurrency, increased wait events etc.
The level of diagnostics being captured. e.g. statistics_level = ALL
After a significant number of DDL operations other dictionary object tables, such as those containing metadata about database objects, files and configuration (e.g. SYS.USER$, SYS.TS$, SYS.SEG$, SYS.OBJ$, SYS.TAB$, SYS.FILE ) could also have grown significantly. This could be after (or during) a platform, database or application (Oracle E-Business Suite) upgrade or after a move to OATM.
Similarly, fixed objects (e.g. X$ objects containing information on the instance and memory structures, used by V$SQL, V$SQL_PLAN, V$ACTIVE_SESSION_HISTORY etc.) could also have grown significantly, due to database, platform or application (Oracle E-Business Suite) upgrades. They could also grow because of changes to the SGA/PGA, configuration of the database or significant changes in the workload or number of sessions.
If the AWR reports or snapshot creation (collection) do not perform well (take a long time to run) then it could be due to inefficient execution plans for SQLs on dictionary or fixed objects. So Dictionary Statistics or Fixed Object Statistics could be inaccurate and require gathering again.
For 10g and above the commands are :
Note that, dependent cursors should be invalidated by using the argument “no_invalidate=>FALSE” or by using procedure DBMS_STATS.set_database_prefs to set the AUTO_INVALIDATE parameter prior to gathering statistics.
See My Oracle Support document “Best Practices for Gathering Statistics with Oracle E-Business Suite (Document 1586374.1)” for more information on gathering Fixed Object and Dictionary statistics with Oracle E-Business Suite.
In some instances there may have been significant growth on one AWR table (e.g. WRH$_LATCH_CHILDREN), in which case gathering table stats for that table only may resolve the issue.
There could also have been growth on one or two particular fixed objects (e.g. ‘X$KCCFN’, ‘X$KCCFE’), in which case gathering statistics for those objects only may resolve the issue.
See My Oracle Support document “AWR or STATSPACK Snapshot collection extremely slow in 11gR2 (Document 1392603.1)”.
Note that it may be necessary to SQL Trace the AWR report or Snapshot Creation to identify inefficient execution plans.
AWR reports can easily be traced from SQL*Plus using “alter session set events” (event 10046). See the “Obtaining Traces (TKPROF) in E-Business Suite – From SQL*Plus” section in the My Oracle Support document “Oracle E-Business SQL Trace and TKPROF Guide (Document 1674024.1)” for instructions.
If the performance issues relate to AWR tables (WRH$) then the “awrinfo.sql” report ( in $ORACLE_HOME/rdbms/admin ) can be used to identify the space usage of the SYSAUX tablespace and AWR. It also shows the size and data distribution of AWR objects. This script can also be used to help resolve space issues on SYSAUX and AWR objects.
See My Oracle Support documents:
Troubleshooting Issues with SYSAUX (Document 1399365.1)
General Guidelines for SYSAUX Space Issues (Document 552880.1)
If not on a RAC environment then please provide an AWR report (in HTML format) for the period that the performance issue was observed (or the program was running). Use either of the scripts awrrpt.sql or awrrpti.sql.
If on a RAC environment, please provide:
An AWR report (awrrpt.sql/awrrpti.sql) for each node (instance) where the performance issue is occurring.
An AWR Global report for all nodes (being used). Use script awrgrpt.sql / awrgrpti.sql on 11g Release 2 and above; spawrrac.sql for 10g and 11g Release 1.
If a process (such as an upgrade) is being run on one node (instance) only then the awrrpti.sql report for that instance will suffice.
If the issue/program is particularly long running then multiple AWR reports can be provided for eachnhour slot.
If the performance issue requires reproducing then on the next run the snapshot settings should have:
A retention period that is long enough for reports to be produced at a later stage. Note that the performance analyst may request more AWR or ASH reports after the initial analysis.
A snapshot interval that is short enough to give the required granularity. However, this can be best achieved by creatingmanual snapshots(using DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ).
These can be set using DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS. SeeAWR Snapshot Settings.
相关推荐: rhel6.4 自动安装oracle 11g客户端
点击(此处)折叠或打开 免费云主机域名 点击(此处)折叠或打开 点击(此处)折叠或打开 点击(此处)折叠或打开 点击(此处)折叠或打开相关推荐: ORACLE数据库中如何插入生僻字本文转自oracle官方博客， 很多客户的数据库的字符集是ZHS16GBK ，但…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
