Automatic Workload Repository - AWR

Welcome to the DBA world. Like the electric company, no one calls to say hey, all is great!. No, its usually the database is slow and .... Yes, that phone call (or now really its an email with half the company cc:d). And besides the validity of your backups, your response to this kind of problem will greatly affect your career success. First the adjective slow is relative slow compared to what? Maybe its a report. Good, because we can easily compare last week's run of REPORT245 and today's run. It ran it 30 minutes last time, this time its 45 minutes. And if you have a 35 minute SLA for this report, it really does matter, and we need to figure out the cause. But what if the user says, 'well, the online query is slower than last time I ran it last month'. This problem is a lot more vague. And before you put this in the 'I will get to this next week', maybe you need to see who he user is and if there are a lot of other users who may be using the online query. Fixing this now, may eliminate a big fix next week or while there are other issues like backups, space, or an upgrade. So, we need to look at a DB, the SQL, and the environment 'now' and 'before'. How do we do this? Starting with 10g, DBAs can use AWR, a wonderful new feature providing up-to-the-second statistics, as well as persistent statistics about every aspect of the database.

lIn the land before AWR

Some DBAs who started with 9i or 10g, may not know, but there was a time before any kind of persistent database statistics. In Oracle v6 and Oracle7 and Oracle8 we used internal scripts called the "UTLBSTAT/UTLESTAT" scripts. They populated tables (in the SYSTEM tablespace believe it or not) with database stats starting when after the DBA runs the BSTAT script, and stopping with after the ESTAT is run. The stats captured during this time can be looked at via queries or some reports. Remember there is no WEB so the DBAs used bulletin boards and user group meetings to trade tricks and tips. Bottom line: the information was 'after the fact' and less then helpful.

Starting with 8i - early STATSPACK

Starting in Oracle 8i (8.1.5 through 8.1.7), Oracle introduced persistent statistics gathering 'statistics gathering package', also known as STATSPACK. The idea was to collect statistics from a 'start time and end at a specific end time. This period is known as a snapshot. The statistics information was stored in PERFSTAT tables and these (hopefully) would be stored outside the SYSTEMS tablespace. The DBA runs a report against the statistics given the snapshot. This produces a TXT report and this is analyzed by the DBA and others in the team.

9i - improved STATSPACK
In 9i, the whole structure was improved. Also more WAIT events were exposed and documented. Therefore, the DBA would use the WAIT info for tuning. Now INTERNET sites would review your report and give you their analysis of the details. And other sites gave general hints, tips, etc. But still the architecture was still anything but automatic. The snap procedure calls need to be done as CRON jobs and the DBA needs to prune or truncate the PERFSTAT tables from time to time.

l10g Automatic Workload Repository

So, what do we really want in terms of DB tuning info collection: comprehensive collection to statistics snapshots taken automatically summary and detail info stored in local tables tables purged regularly and automatically the snapshot frequency be adjustable statistics info retention adjustable You have it now, and have had it since Oracle 10g Release 1 (10.1.x). And you can access this data in two ways via scripts (my preference) or using Enterprise Manager. You can also get a comprehensive report in TXT or HTML format by running a very simple script. But the real power of AWR is its ability to feed other sub-systems and advisors which then produce their own reports, recommendations, and GUI displays.

lAWR - the basics

AWR provides a comprehensive in-memory collection facility. The in-memory info is accessible by means of fixed views. Some of the information collected includes: access and usage statistics of database segments, time statistics that indicate time spent for DB activities, system and session statistics, and oracle optimizer statistics. active session history data collects the history of recent sessions activity There are a large set of V$ tables that the DBA can use to capture 'recent information. But AWR goes beyond that. It also has the facility to store historic collections of DB statistics into tables for later analysis. The memory statistics are transferred to disk by background process - MMON. But unlike STATSPACK the new statistics are added and they are later purged automatically by MMON. Your frequency and retention requirements are specific to your environment and sometimes specific databases also. So the repository workload statistics retention in the is controlled by setting collection and retention periods via PL/SQL calls (and via OEM). Rows are transferred from the V$ views to the tables in the SYSAUX tablespace. The AWR tables there are owned by SYS. The purging is done similar to the aging out of sales data in a rolling window approach in a partitioned DW system. The snapshots are removed in the order they were added

workload repository is stored in the WR schema: WRM$ tables store metadata information WRH$ tables store historical data or snapshots WRH$ tables store information for the advisory functions

lSnapshots the anchor to the history of data

The concept of the snapshot is key to the AWR. The snapshot itself, wether it was run automatically via the defined schedule or manually run by the DBA, is the way you join to the other AWR views. The key snapshot view is DBA_HIST_SNAPSHOT looks like this:
SNAP_ID BEGIN_INTERVAL_TIME END_INTERVAL_TIME (and other columns) NUMBER TIMESTAMP TIMESTAMP

As a DBA you look at BEGIN_INTERVAL_TIME for the beginning time of the snapshot and END_INTERVAL_TIME for the end time. Then you use SNAP_ID to join to the other hist views, such as: DBA_HIST_SQLSTAT DBA_HIST_WAITSTAT (and 30+ more) The snapshot represents the start/stop of a stats-gather run against the DB. What is created is a set of performance statistics captured by the workload repository at a certain time. By default it is captured automatically every 60 minutes, therefore there is a new snapshot every 60 minutes, with a SNAP_ID of 20, 21, because the snapshots are uniquely identified by an identifier SNAP_ID. The stats-gather run collects all types of DB info. The data is organized into the following categories: File statistics, general system statistics concurrency statistics instance tuning statistics SQL statistics Segment Statistics Undo Statistics Time-model statistics, Recovery Statistics RAC statistics

Using the dbms_workload_repository package

PROCEDURE MODIFY_SNAPSHOT_SETTINGS RETENTION NUMBER IN INTERVAL NUMBER IN DBID NUMBER IN

The DBA can change the interval parameter using this package. It sets the time interval, in minutes, between the snapshots. The default interval between snapshots is 60 minutes. The valid range of values for this parameter is 10 to 52560000 (100 years)

The DBA can also change the retention time. The package sets the period, in minutes. The default value for this parameter is 10080 (7 days). The valid range of values for this parameter is 10 minutes to 52560000 (100 years) Example - change retention to 30 days and snapshot interval to 30 minutes
BEGIN DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings( retention => 43200, -- ( = 30 Days ) ( exiting value retained if NULL) interval => 30); -- ( = 30 min ) END;

The current settings for AWR retention and interval parameters can be viewed using dba_hist_wr_control data dictionary view
select extract( day from snap_interval ) * (24 * 60) + extract( hour from snap_interval ) * 60 + extract( minute from snap_interval ) snapintmins, ( extract( day from retention ) * (24 * 60) + extract( hour from retention ) * 60 + extract( minute from retention ) ) / (60 * 24) retenintdays from dba_hist_wr_control /

SNAPINTMINS RETENINTDAYS ---------------------60 8

lSome of the key AWR views

DBA_HIST_SNAPSHOT - Displays snapshot information. DBA_HIST_SYSSTAT - Displays detailed system statistics DBA_HIST_FILESTATXS Displays detailed datafile statistics DBA_HIST_SQL_SUMMARY Displays summary and higher level SQL statistics DBA_HIST_SQLSTAT Displays detailed SQL statistics DBA_HIST_WAITSTAT Displays detailed wait statistics V$METRIC - Displays metric information. V$METRICNAME - Displays the metrics associated with each metric group. V$METRIC_HISTORY - Displays historical metrics. V$METRICGROUP - Displays all metrics groups.

DBA_HIST_BASELINE - Displays baseline information. DBA_HIST_SQL_PLAN - Displays SQL execution plans.

lHow to run AWR report

{ORACLE_HOME}/rdbms/admin/awrrpt.sql {ORACLE_HOME}/rdbms/admin/awrrpti.sql {ORACLE_HOME}/rdbms/admin/awrinput.sql

lA simple AWR example query

REM File: indexsqlsnap.sql REM Copyright (c) 2009, OracleMan Consulting, all rights reserved clear break col begintvtm heading 'Interval|Time|Begin' format a8 col objnm heading 'Index Name' format a30 col dskrdstot heading 'Disk|Reads' format 99,999,999 col rwsprctot heading 'Proc-ed|Rows' format 99,999,999 break on begintvtm spool indexsqlsnap.lis select to_char(s.begin_interval_time,'mm-dd hh24') begintvtm , p.object_name objnm , sum(t.disk_reads_total) dskrdstot, sum(t.rows_processed_total) rwsprctot from dba_hist_sql_plan p, dba_hist_sqlstat t, dba_hist_snapshot s where p.sql_id = t.sql_id and t.snap_id = s.snap_id and p.object_type like '%INDEX%' group by to_char(s.begin_interval_time,'mm-dd hh24'), p.object_name order by begintvtm , dskrdstot desc, objnm / spool off ttitle off clear col clear break set echo on feedback on lines 80 pages 60

OUTPUT Interval

Time Begin -------02-12 14

Index Name -----------------------------I_IDL_UB11 I_TYPE2 I_USER2 I_IDL_UB21 I_OBJ4 I_IND1 I_LINK1 I_SUM$_1 I_OBJ#_INTCOL# I_OBJ1 MGMT_TARGETS_PK

Disk Reads -----3,930 2,481 2,344 1,362 1,100 886 876 876 566 554 451

Proc-ed Rows ----------6,808 0 2,093 3,828 948 948 946 946 25,263 10,366 0

lThe friend of ARW - ASH

ASH is active session history. Well, history and active, yes and no. Let me explain. ASH is another new way to look at DB activities and statistics. The active means the session was active, and while it was active, the statistics are captured. In this case, a V$ table, which means it is only good for this up of the DB. V$ACTIVE_SESSION_HISTORY - Displays the active session history (ASH) sampled every second. But this wouldn't be AWR without a HIST view/table. To look at statistics over time we use this view and join to snapshot, etc. DBA_HIST_ACTIVE_SESS_HISTORY - Displays the history contents of the active session history. basics example ASH report "$OH/rdbms/admin/ashrpt.sql"

lSome of the 11g changes in AWR

moving window baseline Baseline Metric Thresholds dbms_workload_repository.AWR_DIFF_REPORT_TEXT