AWR - Automatic Workload Repository

存档下，有时间再读～

The AWR

To properly collect database statistics, the parameter statistics_level should be set to TYPICAL (the default) or ALL.

The Oracle database uses AWR for problem detection and analysis as well as for self-tuning. A number of different statistics are collected by the AWR including wait events, time model statistics, active session history statistics, various system and session-level statistics, object usage statistics, and information on the most resource-intensive SQL statements. Other Oracle Database 10g features use the AWR, including ADDM and the other advisors in Oracle Database 10g that we will discuss in this series of articles.

If you want to explore the AWR repository, feel free to do so. The AWR consists of a number of tables owned by the SYS schema and typically stored in the SYSAUX tablespace (currently no method exists to move these objects to another tablespace). All AWR table names start with the identifier "WR." Following WR is a mnemonic that identifies the type designation of the table followed by a dollar sign ($). AWR tables comewith three different type designations:

1.Metadata (WRM$)
2.Historical data (WRH$)
3.AWR tables related to advisor functions (WRI$)

Most of the AWR table names are pretty self-explanatory, such as WRM$_SNAPSHOT or WRH$_ACTIVE_SESSION_HISTORY.

Also Oracle Database 10g offers several DBA tables that allow you to query the AWR repository. The tables all start with DBA_HIST, followed by a name that describes the table. These include tables such as DBA_HIST_FILESTATS, DBA_HIST_DATAFILE, or DBA_HIST_SNAPSHOT.

Manually Managing the AWR

While AWR is meant to be automatic, provisions for manual operations impacting the AWR are available. You can modify the snapshot collection interval and retention criteria, create snapshots, and remove snapshots from the AWR. We will look at this process in more detail in the next few sections.

Manual snapshot collection and retention
You can modify the snapshot collection interval using the dbms_workload_repository package. The procedure dbms_workload_repository.modify_snapshot_settings is used in this example to modify the snapshot collection so that it occurs every 30 minutes, and retention of snapshot data is fixed at 10080 minutes:

-- This causes the repository to refresh every 30 minutes
-- and retain all data for 1 weeks.

Exec dbms_workload_repository.modify_snapshot_settings (retention=>10080, interval=> 30);

(Setting the interval parameter to 0 will disable all statistics collection.)

To view the current retention and interval settings of the AWR, use the DBA_HIST_WR_CONTROL view. Here is an example of how to use this view:

SELECT * FROM dba_hist_wr_control;

DBIDAAAAAAAAAAAAA SNAP_INTERVALAAAAAAA RETENTIONAAAAAAAAAAAAAAAAAAAAA TOPNSQL
----------AAAAAAAA --------------------AAAAAAAA -------------------------AAAAAAAA ----------
4005531560 +00000 01:00:00.0AAA +00007 00:00:00.0AAAAAAAA DEFAULT

In this example, we see that the snapshot interval is every hour (the default), and the retention is set for seven days.

Creating or removing snapshots
You can use the dbms_workload_repository package to create or remove snapshots. The dbms_workload_repository.create_snapshot procedure creates a manual snapshot in the AWR as seen in this example:

EXEC dbms_workload_repository.create_snapshot;

You can see what snapshots are currently in the AWR by using the DBA_HIST_SNAPSHOT view as seen in this example:

SELECT snap_id, begin_interval_time, end_interval_time FROM dba_hist_snapshot ORDER BY 1;

SNAP_ID BEGIN_INTERVAL_TIMEAAAAAAAAAAA END_INTERVAL_TIME
---------- ------------------------------ ------------------------------
1 01-SEP-08 11.26.45.000 AMAAAAA 01-SEP-08 12.00.50.984 PM
2 01-SEP-08 12.00.50.984 PMAAAAA 01-SEP-08 01.00.55.991 PM
3 01-SEP-08 01.00.55.991 PMAAAAA 01-SEP-08 02.00.57.578 PM
4 01-SEP-08 02.00.57.578 PMAAAAA 01-SEP-08 03.00.59.208 PM
5 01-SEP-08 03.00.59.208 PMAAAAA 01-SEP-08 04.00.00.796 PM
6 01-SEP-08 04.00.00.796 PMAAAAA 01-SEP-08 05.00.02.407 PM
7 01-SEP-08 05.00.02.407 PMAAAAA 01-SEP-08 06.00.04.038 PM
8 01-SEP-08 06.00.04.038 PMAAAAA 01-SEP-08 07.00.05.639 PM
9 01-SEP-08 07.00.05.639 PMAAAAA 01-SEP-08 08.00.07.304 PM

Each snapshot is assigned a unique snapshot ID that is reflected in the SNAP_ID column. If you have two snapshots, the earlier snapshot will always have a smaller SNAP_ID than the later snapshot. The END_INTERVAL_TIME column displays the time that the actual snapshot was taken.

Sometimes you might want to drop snapshots manually. The dbms_workload_repository.drop_snapshot_range procedure can be used to remove a range of snapshots from the AWR. This procedure takes two parameters, low_snap_id and high_snap_id, as seen in this example:

EXEC dbms_workload_repository.drop_snapshot_range (low_snap_id=>1, high_snap_id=>4);

AWR automated snapshots

Oracle Database 10g uses a scheduled job, GATHER_STATS_JOB, to collect AWR statistics. This job is created, and enabled automatically when you create a new Oracle database under Oracle Database 10g. To see this job, use the DBA_SCHEDULER_JOBS view as seen in this example:

SELECT a.job_name, a.enabled, c.window_name, c.schedule_name,
c.start_date, c.repeat_interval
FROM dba_scheduler_jobs a,
dba_scheduler_wingroup_members b,
dba_scheduler_windows c
WHERE job_name='GATHER_STATS_JOB'
And a.schedule_name=b.window_group_name
And b.window_name=c.window_name;

You can disable this job using the dbms_scheduler.disable procedure as seen in this example:

Exec dbms_scheduler.disable('GATHER_STATS_JOB');

And you can enable the job using the dbms_scheduler.enable procedure as seen in this example:

Exec dbms_scheduler.enable('GATHER_STATS_JOB');

AWR Snapshot Reports

Oracle provides reports that you can run to analyze the data in the AWR. These reports are much like the statspack reports prior to Oracle Database 10g. There are two reports: awrrpt.sql and awrrpti.sql, which are available in the directory $ORACLE_HOME/rdbms/admin.

The output of these reports is essentially the same, except that awrrpti.sql script allows you to define a specific instance to report on.

The reports are much like the statspack reports of old, in that you define a beginning and ending snapshot ID, and the output filename of the report. Additionally, you can opt to produce the report in either text format or HTML format.

AWR Baselines

It is frequently a good idea to create a baseline in the AWR. A baseline is defined by <Robert, should this be "by" or "as"> a range of snapshots that can be used to compare to other pairs of snapshots. The Oracle database server will exempt the snapshots assigned to a specific baseline from the automated purge routine. Thus, the main purpose of a baseline is to preserve typical runtime statistics in the AWR repository, allowing you to run the AWR snapshot reports on the preserved baseline snapshots at any time and compare them to recent snapshots contained in the AWR. This allows you to compare current performance (and configuration) to established baseline performance, which can assist in determining database performance problems.

In this section, you will learn how to create baselines, remove baselines, and how to use baselines.

Creating baselines
You can use the create_baseline procedure contained in the dbms_workload_repository stored PL/SQL package to create a baseline as seen in this example:

EXEC dbms_workload_repository.create_baseline (start_snap_id=>1109, end_snap_id=>1111, baseline_name=>'EOM Baseline');

Baselines can be seen using the DBA_HIST_BASELINE view as seen in the following example:

SELECT baseline_id, baseline_name, start_snap_id, end_snap_id FROM dba_hist_baseline;

BASELINE_ID BASELINE_NAME START_SNAP_ID END_SNAP_ID
-----------AAAAAA ---------------AAAAAAAAA -------------AAAAAAAAA -----------
1AAAAAAAAAAAAAAAAAA BaselineAAAAAAAAAAAAAA 1 AAAAAAAAAAAAAAAAAAAAAAA 5

In this case, the column BASELINE_ID identifies each individual baseline that has been defined. The name assigned to the baseline is listed, as are the beginning and ending snapshot IDs.

Removing baselines

You can remove a baseline using the dbms_workload_repository.drop_baseline procedure as seen in this example that drops the "EOM Baseline" that we just created.

EXEC dbms_workload_repository.drop_baseline (baseline_name=>'Baseline', Cascade=>FALSE);

Note that the cascade parameter will cause all associated snapshots to be removed if it is set to TRUE; otherwise, the snapshots will be cleaned up automatically by the AWR automated processes.