AWR VS ASH

ASH can help you when there's a sudden performance degradation of the database felt.
AWR - historic past snapshot intervals.
AWR, stores the session performance statistics for analysis later.
ASH - the storage is not persistent and as time progresses, the old entries are removed to
accommodate new ones. They can be viewed using V$ACTIVE_SESSION_HISTORY
ASH report provides the below info.
Top Events
Load Profile
Top SQL
Top PL/SQL
Top Sessions
Top Objects/Files/Latches
Activity Over Time
AWR reports provide the below info.
Report Summary
Wait Events Statistics
SQL Statistics
Instance Activity Statistics
IO Stats
Buffer Pool Statistics
Advisory Statistics
Wait Statistics
Undo Statistics
Latch Statistics
Segment Statistics
Dictionary Cache Statistics
Library Cache Statistics
Memory Statistics
Streams Statistics
Resource Limit Statistics
init.ora Parameters

From Oracle PT guide:

5 Automatic Performance Statistics
This chapter discusses the gathering of performance statistics. This chapter contains the following
topics:
Overview of Data Gathering
Overview of the Automatic Workload Repository

Managing the Automatic Workload Repository

5.1 Overview of Data Gathering
To effectively diagnose performance problems, statistics must be available. Oracle generates many
types of cumulative statistics for the system, sessions, and individual SQL statements. Oracle also
tracks cumulative statistics on segments and services. When analyzing a performance problem in any
of these scopes, you typically look at the change in statistics (delta value) over the period of time you
are interested in. Specifically, you look at the difference between the cumulative value of a statistic at
the start of the period and the cumulative value at the end.
Cumulative values for statistics are generally available through dynamic performance views, such as
the V$SESSTAT and V$SYSSTAT views. Note that the cumulative values in dynamic views are reset
when the database instance is shutdown. The Automatic Workload Repository (AWR) automatically
persists the cumulative and delta values for most of the statistics at all levels except the session level.
This process is repeated on a regular time period and the result is called an AWR snapshot. The delta
values captured by the snapshot represent the changes for each statistic over the time period. See
"Overview of the Automatic Workload Repository".
Another type of statistic collected by Oracle is called a metric. A metric is defined as the rate of
change in some cumulative statistic. That rate can be measured against a variety of units, including
time, transactions, or database calls. For example, the number database calls per second is a metric.
Metric values are exposed in some V$ views, where the values are the average over a fairly small
time interval, typically 60 seconds. A history of recent metric values is available through V$ views, and
some of the data is also persisted by AWR snapshots.
A third type of statistical data collected by Oracle is sampled data. This sampling is performed by the
active session history (ASH) sampler. ASH samples the current state of all active sessions. This data
is collected into memory and can be accessed by a V$ view. It is also written out to persistent store by
the AWR snapshot processing. See "Active Session History (ASH)".
A powerful tool for diagnosing performance problems is the use of statistical baselines. A statistical
baseline is collection of statistic rates usually taken over time period where the system is performing
well at peak load. Comparing statistics captured during a period of bad performance to a baseline
helps discover specific statistics that have increased significantly and could be the cause of the
problem.
AWR supports the capture of baseline data by enabling you to specify and preserve a pair or range of
AWR snapshots as a baseline. Carefully consider the time period you choose as a baseline; the
baseline should be a good representation of the peak load on the system. In the future, you can
compare these baselines with snapshots captured during periods of poor performance.
Oracle Enterprise Manager is the recommended tool for viewing both real time data in the dynamic
performance views and historical data from the AWR history tables. Enterprise manager can also be
used to capture operating system and network statistical data that can be correlated with AWR data.
For more information, see Oracle Database 2 Day + Performance Tuning Guide.
This section covers the following topics:
Database Statistics
Operating System Statistics
Interpreting Statistics
5.1.1 Database Statistics
Database statistics provide information on the type of load on the database, as well as the internal
and external resources used by the database. This section describes some of the more important
statistics:

Wait Events
Time Model Statistics
Active Session History (ASH)
System and Session Statistics
5.1.1.1 Wait Events
Wait events are statistics that are incremented by a server process/thread to indicate that it had to
wait for an event to complete before being able to continue processing. Wait event data reveals
various symptoms of problems that might be impacting performance, such as latch contention, buffer
contention, and I/O contention.
To enable easier high-level analysis of the wait events, the events are grouped into classes. The wait
event classes include: Administrative, Application, Cluster, Commit, Concurrency, Configuration, Idle,
Network, Other, Scheduler, System I/O, and User I/O.
The wait classes are based on a common solution that usually applies to fixing a problem with the
wait event. For example, exclusive TX locks are generally an application level issue and HW locks are
generally a configuration issue.
The following list includes common examples of the waits in some of the classes:
Application: locks waits caused by row level locking or explicit lock commands
Commit: waits for redo log write confirmation after a commit
Idle: wait events that signify the session is inactive, such as SQL*Net message from client
Network: waits for data to be sent over the network
User I/O: wait for blocks to be read off a disk
See Also:
Oracle Database Reference for more information about Oracle wait events
5.1.1.2 Time Model Statistics
When tuning an Oracle system, each component has its own set of statistics. To look at the system as
a whole, it is necessary to have a common scale for comparisons. Because of this, most Oracle
advisories and reports describe statistics in terms of time. In addition, the V$SESS_TIME_MODEL
and V$SYS_TIME_MODEL views provide time model statistics. Using the common time
instrumentation helps to identify quantitative effects on the database operations.
The most important of the time model statistics is DB time. This statistics represents the total time
spent in database calls and is a indicator of the total instance workload. It is calculated by aggregating
the CPU and wait times of all sessions not waiting on idle wait events (non-idle user sessions).
DB time is measured cumulatively from the time that the instance was started. Because DB time it is
calculated by combining the times from all non-idle user sessions, it is possible that the DB time can
exceed the actual time elapsed since the instance started up. For example, a instance that has been
running for 30 minutes could have four active user sessions whose cumulative DB time is
approximately 120 minutes.
The objective for tuning an Oracle system could be stated as reducing the time that users spend in
performing some action on the database, or simply reducing DB time. Other time model statistics
provide quantitative effects (in time) on specific actions, such as logon operations and hard and soft
parses.

See Also:
Oracle Database Reference for information about the V$SESS_TIME_MODEL and
V$SYS_TIME_MODEL views
5.1.1.3 Active Session History (ASH)
The V$ACTIVE_SESSION_HISTORY view provides sampled session activity in the instance. Active
sessions are sampled every second and are stored in a circular buffer in SGA. Any session that is
connected to the database and is waiting for an event that does not belong to the Idle wait class is
considered as an active session. This includes any session that was on the CPU at the time of
sampling.
Each session sample is a set of rows and the V$ACTIVE_SESSION_HISTORY view returns one row
for each active session per sample, returning the latest session sample rows first. Because the active
session samples are stored in a circular buffer in SGA, the greater the system activity, the smaller the
number of seconds of session activity that can be stored in the circular buffer. This means that the
duration for which a session sample appears in the V$ view, or the number of seconds of session
activity that is displayed in the V$ view, is completely dependent on the database activity.
As part of the Automatic Workload Repository (AWR) snapshots, the content of
V$ACTIVE_SESSION_HISTORY is also flushed to disk. Because the content of this V$ view can get
quite large during heavy system activity, only a portion of the session samples is written to disk.
By capturing only active sessions, a manageable set of data is represented with the size being directly
related to the work being performed rather than the number of sessions allowed on the system. Using
the Active Session History enables you to examine and perform detailed analysis on both current data
in the V$ACTIVE_SESSION_HISTORY view and historical data in the
DBA_HIST_ACTIVE_SESS_HISTORY view, often avoiding the need to replay the workload to gather
additional performance tracing information. The data present in ASH can be rolled up on various
dimensions that it captures, including the following:
SQL identifier of SQL statement
Object number, file number, and block number
Wait event identifier and parameters
Session identifier and session serial number
Module and action name
Client identifier of the session
Service hash identifier
See Also:
Oracle Database Reference for more information about the V$ACTIVE_SESSION_HISTORY view
Active Session History information over a specified duration can be gathered into a report. For more
information, see "Generating Active Session History Reports".
5.1.1.4 System and Session Statistics
A large number of cumulative database statistics are available on a system and session level through
the V$SYSSTAT and V$SESSTAT views.
See Also:

Oracle Database Reference for information about the V$SYSSTAT and V$SESSTAT views
5.1.2 Operating System Statistics
Operating system statistics provide information on the usage and performance of the main hardware
components of the system, as well as the performance of the operating system itself. This information
is crucial for detecting potential resource exhaustion, such as CPU cycles and physical memory, and
for detecting bad performance of peripherals, such as disk drives.
Operating system statistics are only an indication of how the hardware and operating system are
working. Many system performance analysts react to a hardware resource shortage by installing more
hardware. This is a reactionary response to a series of symptoms shown in the operating system
statistics. It is always best to consider operating system statistics as a diagnostic tool, similar to the
way many doctors use body temperature, pulse rate, and patient pain when making a diagnosis. To
help identify bottlenecks, gather operating system statistics for all servers in the system under
performance analysis.
Operating system statistics include the following:
CPU Statistics
Virtual Memory Statistics
Disk Statistics
Network Statistics
For information on tools for gathering operating statistics, see "Operating System Data Gathering
Tools".

5.1.2.1 CPU Statistics

CPU utilization is the most important operating system statistic in the tuning process. Get CPU
utilization for the entire system and for each individual CPU on multi-processor environments.
Utilization for each CPU can detect single-threading and scalability issues.
Most operating systems report CPU usage as time spent in user space or mode and time spent in
kernel space or mode. These additional statistics allow better analysis of what is actually being
executed on the CPU.
On an Oracle data server system, where there is generally only one application running, the server
runs database activity in user space. Activities required to service database requests (such as
scheduling, synchronization, I/O, memory management, and process/thread creation and tear down)
run in kernel mode. In a system where all CPU is fully utilized, a healthy Oracle system runs between
65% and 95% in user space.
The V$OSSTAT view captures system level information in the database, making it easier for you to
determine if there are hardware level resource issues. The V$SYSMETRIC_HISTORY view shows a
one-hour history of the Host CPU Utilization metric, a representation of percentage of CPU usage at
each one-minute interval. The V$SYS_TIME_MODEL view supplies statistics on the CPU usage by
the Oracle database. Using both sets of statistics enable you to determine whether the Oracle
database or other system activity is the cause of the CPU problems.
5.1.2.2 Virtual Memory Statistics
Virtual memory statistics should mainly be used as a check to validate that there is very little paging or
swapping activity on the system. System performance degrades rapidly and unpredictably when
paging or swapping occurs.
Individual process memory statistics can detect memory leaks due to a programming failure to

deallocate memory taken from the process heap. These statistics should be used to validate that
memory usage does not increase after the system has reached a steady state after startup. This
problem is particularly acute on shared server applications on middle tier systems where session state
may persist across user interactions, and on completion state information that is not fully deallocated.
5.1.2.3 Disk Statistics
Because the database resides on a set of disks, the performance of the I/O subsystem is very
important to the performance of the database. Most operating systems provide extensive statistics on
disk performance. The most important disk statistics are the current response time and the length of
the disk queues. These statistics show if the disk is performing optimally or if the disk is being
overworked.
Measure the normal performance of the I/O system; typical values for a single block read range from
5 to 20 milliseconds, depending on the hardware used. If the hardware shows response times much
higher than the normal performance value, then it is performing badly or is overworked. This is your
bottleneck. If disk queues start to exceed two, then the disk is a potential bottleneck of the system.
5.1.2.4 Network Statistics
Network statistics can be used in much the same way as disk statistics to determine if a network or
network interface is overloaded or not performing optimally. In today's networked applications,
network latency can be a large portion of the actual user response time. For this reason, these
statistics are a crucial debugging tool.
5.1.2.5 Operating System Data Gathering Tools
Table 5-1 shows the various tools for gathering operating statistics on UNIX. For Windows, use the
Performance Monitor tool.
Table 5-1 UNIX Tools for Operating Statistics
Component UNIX Tool
CPU

sar, vmstat, mpstat, iostat

Memory

sar, vmstat

Disk

sar, iostat

Network

netstat

5.1.3 Interpreting Statistics

When initially examining performance data, you can formulate potential theories by examining your
statistics. One way to ensure that your interpretation of the statistics is correct is to perform crosschecks with other data. This establishes whether a statistic or event is really of interest.
Some pitfalls are discussed in the following sections:
Hit ratios
When tuning, it is common to compute a ratio that helps determine whether there is a problem. Such
ratios include the buffer cache hit ratio, the soft-parse ratio, and the latch hit ratio. These ratios should
not be used as 'hard and fast' identifiers of whether there is or is not a performance bottleneck.
Rather, they should be used as indicators. In order to identify whether there is a bottleneck, other
related evidence should be examined. See "Calculating the Buffer Cache Hit Ratio".

Wait events with timed statistics

Setting TIMED_STATISTICS to true at the instance level directs the Oracle server to gather wait time
for events, in addition to wait counts already available. This data is useful for comparing the total wait
time for an event to the total elapsed time between the performance data collections. For example, if
the wait event accounts for only 30 seconds out of a two hour period, then there is probably little to be
gained by investigating this event, even though it may be the highest ranked wait event when ordered
by time waited. However, if the event accounts for 30 minutes of a 45 minute period, then the event is
worth investigating. See "Wait Events".
Note:
Timed statistics are automatically collected for the database if the initialization parameter
STATISTICS_LEVEL is set to TYPICAL or ALL. If STATISTICS_LEVEL is set to BASIC, then you must
set TIMED_STATISTICS to TRUE to enable collection of timed statistics. Note that setting
STATISTICS_LEVEL to BASIC disables many automatic features and is not recommended. If you
explicitly set DB_CACHE_ADVICE, TIMED_STATISTICS, or TIMED_OS_STATISTICS, either in the
initialization parameter file or by using ALTER_SYSTEM or ALTER SESSION, the explicitly set value
overrides the value derived from STATISTICS_LEVEL.
Comparing Oracle statistics with other factors
When looking at statistics, it is important to consider other factors that influence whether the statistic is
of value. Such factors include the user load and the hardware capability. Even an event that had a
wait of 30 minutes in a 45 minute snapshot might not be indicative of a problem if you discover that
there were 2000 users on the system, and the host hardware was a 64 node system.
Wait events without timed statistics
If TIMED_STATISTICS is false, then the amount of time waited for an event is not available.
Therefore, it is only possible to order wait events by the number of times each event was waited for.
Although the events with the largest number of waits might indicate the potential bottleneck, they
might not be the main bottleneck. This can happen when an event is waited for a large number of
times, but the total time waited for that event is small. The converse is also true: an event with fewer
waits might be a problem if the wait time is a significant proportion of the total wait time. Without
having the wait times to use for comparison, it is difficult to determine whether a wait event is really of
interest.
Idle wait events
Oracle uses some wait events to indicate if the Oracle server process is idle. Typically, these events
are of no value when investigating performance problems, and they should be ignored when
examining the wait events. See "Idle Wait Events".
Computed statistics
When interpreting computed statistics (such as rates, statistics normalized over transactions, or
ratios), it is important to cross-verify the computed statistic with the actual statistic counts. This
confirms whether the derived rates are really of interest: small statistic counts usually can discount an
unusual ratio. For example, on initial examination, a soft-parse ratio of 50% generally indicates a
potential tuning area. If, however, there was only one hard parse and one soft parse during the data
collection interval, then the soft-parse ratio would be 50%, even though the statistic counts show this
is not an area of concern. In this case, the ratio is not of interest due to the low raw statistic counts.
See Also:
"Setting the Level of Statistics Collection" for information about STATISTICS_LEVEL settings
Oracle Database Reference for information on the STATISTICS_LEVEL initialization parameter

5.2 Overview of the Automatic Workload Repository

The Automatic Workload Repository (AWR) collects, processes, and maintains performance statistics
for problem detection and self-tuning purposes. This data is both in memory and stored in the
database. The gathered data can be displayed in both reports and views.
The statistics collected and processed by AWR include:
Object statistics that determine both access and usage statistics of database segments
Time model statistics based on time usage for activities, displayed in the V$SYS_TIME_MODEL and
V$SESS_TIME_MODEL views
Some of the system and session statistics collected in the V$SYSSTAT and V$SESSTAT views
SQL statements that are producing the highest load on the system, based on criteria such as elapsed
time and CPU time
Active Session History (ASH) statistics, representing the history of recent sessions activity
The STATISTICS_LEVEL initialization parameter must be set to the TYPICAL or ALL to enable the
Automatic Workload Repository. If the value is set to BASIC, you can manually capture AWR statistics
using procedures in the DBMS_WORKLOAD_REPOSITORY package. However, because setting the
STATISTICS_LEVEL parameter to BASIC turns off in-memory collection of many system statistics,
such as segments statistics and memory advisor information, manually captured snapshots will not
contain these statistics and will be incomplete.
This section describes the Automatic Workload Repository and contains the following topics:
Snapshots
Baselines
Space Consumption
See Also:
Oracle Database Reference for information on the STATISTICS_LEVEL initialization parameter
5.2.1 Snapshots
Snapshots are sets of historical data for specific time periods that are used for performance
comparisons by ADDM. By default, AWR automatically generates snapshots of the performance data
once every hour and retains the statistics in the workload repository for 7 days. You can also manually
create snapshots, but this is usually not necessary. The data in the snapshot interval is then analyzed
by the Automatic Database Diagnostic Monitor (ADDM). For information about ADDM, see "Automatic
Database Diagnostic Monitor".
AWR compares the difference between snapshots to determine which SQL statements to capture
based on the effect on the system load. This reduces the number of SQL statements that need to be
captured over time.
For information about managing snapshots, see "Managing Snapshots".
5.2.2 Baselines
A baseline contains performance data from a specific time period that is preserved for comparison
with other similar workload periods when performance problems occur. The snapshots contained in a
baseline are excluded from the automatic AWR purging process and are retained indefinitely.
For information about managing baselines, see "Managing Baselines".

5.2.3 Space Consumption

The space consumed by the Automatic Workload Repository is determined by several factors:
Number of active sessions in the system at any given time
Snapshot interval
The snapshot interval determines the frequency at which snapshots are captured. A smaller snapshot
interval increases the frequency, which increases the volume of data collected by the Automatic
Workload Repository.
Historical data retention period
The retention period determines how long this data is retained before being purged. A longer retention
period increases the space consumed by the Automatic Workload Repository.
By default, the snapshots are captured once every hour and are retained in the database for 7 days.
With these default settings, a typical system with an average of 10 concurrent active sessions can
require approximately 200 to 300 MB of space for its AWR data. It is possible to change the default
values for both snapshot interval and retention period. See "Modifying Snapshot Settings" for
information about modifying AWR settings.
The Automatic Workload Repository space consumption can be reduced by the increasing the
snapshot interval and reducing the retention period. When reducing the retention period, note that
several Oracle self-managing features depend on AWR data for proper functioning. Not having
enough data can affect the validity and accuracy of these components and features, including the
following:
Automatic Database Diagnostic Monitor
SQL Tuning Advisor
Undo Advisor
Segment Advisor
If possible, Oracle recommends that you set the AWR retention period large enough to capture at
least one complete workload cycle. If your system experiences weekly workload cycles, such as
OLTP workload during weekdays and batch jobs during the weekend, you do not need to change the
default AWR retention period of 7 days. However if your system is subjected to a monthly peak load
during month end book closing, you may have to set the retention period to one month.
Under exceptional circumstances, the automatic snapshot collection can be completely turned off by
setting the snapshot interval to 0. Under this condition, the automatic collection of the workload and
statistical data is stopped and much of the Oracle self-management functionality is not operational. In
addition, you will not be able to manually create snapshots. For this reason, Oracle Corporation
strongly recommends that you do not turn off the automatic snapshot collection.
5.3 Managing the Automatic Workload Repository
This section describes how to manage the Automatic Workload Repository and contains the following
topics:
Managing Snapshots
Managing Baselines
Transporting Automatic Workload Repository Data

Using Automatic Workload Repository Views

Generating Automatic Workload Repository Reports
Generating Active Session History Reports
For a description of the Automatic Workload Repository, see "Overview of the Automatic Workload
Repository".

5.3.1 Managing Snapshots

By default, Oracle Database generates snapshots once every hour, and retains the statistics in the
workload repository for 7 days. When necessary, you can use DBMS_WORKLOAD_REPOSITORY
procedures to manually create, drop, and modify the snapshots. To invoke these procedures, a user
must be granted the DBA role. For more information about snapshots, see "Snapshots".
The primary interface for managing the Automatic Workload Repository is Oracle Enterprise Manager.
Whenever possible, you should manage snapshots using Oracle Enterprise Manager, as described in
Oracle Database 2 Day + Performance Tuning Guide. If Oracle Enterprise Manager is unavailable,
you can manage the AWR snapshots and baselines using the DBMS_WORKLOAD_REPOSITORY
package, as described in this section.
This section contains the following topics:
Creating Snapshots
Dropping Snapshots
Modifying Snapshot Settings
See Also:
Oracle Database PL/SQL Packages and Types Reference for detailed information on the
DBMS_WORKLOAD_REPOSITORY package
5.3.1.1 Creating Snapshots
You can manually create snapshots with the CREATE_SNAPSHOT procedure if you want to capture
statistics at times different than those of the automatically generated snapshots. For example:

BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
END;
/
In this example, a snapshot for the instance is created immediately with the flush level specified to the
default flush level of TYPICAL. You can view this snapshot in the DBA_HIST_SNAPSHOT view.
5.3.1.2 Dropping Snapshots
You can drop a range of snapshots using the DROP_SNAPSHOT_RANGE procedure. To view a list
of the snapshot Ids along with database Ids, check the DBA_HIST_SNAPSHOT view. For example,
you can drop the following range of snapshots:

10

BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE (low_snap_id => 22,
high_snap_id => 32, dbid => 3310949047);
END;
/
In the example, the range of snapshot Ids to drop is specified from 22 to 32. The optional database
identifier is 3310949047. If you do not specify a value for dbid, the local database identifier is used as
the default value.
Active Session History data (ASH) that belongs to the time period specified by the snapshot range is
also purged when the DROP_SNAPSHOT_RANGE procedure is called.
5.3.1.3 Modifying Snapshot Settings
You can adjust the interval, retention, and captured Top SQL of snapshot generation for a specified
database Id, but note that this can affect the precision of the Oracle diagnostic tools.
The INTERVAL setting affects how often in minutes that snapshots are automatically generated. The
RETENTION setting affects how long in minutes that snapshots are stored in the workload repository.
The TOPNSQL setting affects the number of Top SQL to flush for each SQL criteria (Elapsed Time,
CPU Time, Parse Calls, Shareable Memory, and Version Count). The value for this setting will not be
affected by the statistics/flush level and will override the system default behavior for the AWR SQL
collection. It is possible to set the value for this setting to MAXIMUM to capture the complete set of
SQL in the cursor cache, though by doing so (or by setting the value to a very high number) may lead
to possible space and performance issues since there will more data to collect and store. To adjust
the settings, use the MODIFY_SNAPSHOT_SETTINGS procedure. For example:

BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention => 43200,
interval => 30, topnsql => 100, dbid => 3310949047);
END;
/
In this example, the retention period is specified as 43200 minutes (30 days), the interval between
each snapshot is specified as 30 minutes, and the number of Top SQL to flush for each SQL criteria
as 100. If NULL is specified, the existing value is preserved. The optional database identifier is
3310949047. If you do not specify a value for dbid, the local database identifier is used as the default
value. You can check the current settings for your database instance with the
DBA_HIST_WR_CONTROL view.
5.3.2 Managing Baselines
This section describes how to manage baselines. For more information about baselines, see
"Baselines".
The primary interface for managing snapshots is Oracle Enterprise Manager. Whenever possible, you
should manage snapshots using Oracle Enterprise Manager, as described in Oracle Database 2 Day
+ Performance Tuning Guide. If Oracle Enterprise Manager is unavailable, you can manage
snapshots using the DBMS_WORKLOAD_REPOSITORY package, as described in the following
sections:
Creating a Baseline
Dropping a Baseline
5.3.2.1 Creating a Baseline

11

This section describes how to create a baseline using an existing range of snapshots.
To create a baseline:
Review the existing snapshots in the DBA_HIST_SNAPSHOT view to determine the range of
snapshots that you want to use.
Use the CREATE_BASELINE procedure to create a baseline using the desired range of snapshots:

BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE (start_snap_id => 270,
end_snap_id => 280, baseline_name => 'peak baseline',
dbid => 3310949047, expiration => 30);
END;
/
In this example, 270 is the start snapshot sequence number and 280 is the end snapshot sequence.
The name of baseline is peak baseline. The optional database identifier is 3310949047. If you do not
specify a value for dbid, the local database identifier is used as the default value. The optional
expiration parameter is set to 30, so the baseline will expire and be dropped automatically after 30
days. If you do not specify a value for expiration, the baseline will never expire.
The system automatically assign a unique baseline Id to the new baseline when the baseline is
created. The baseline Id and database identifier are displayed in the DBA_HIST_BASELINE view.
5.3.2.2 Dropping a Baseline
This section describes how to drop an existing baseline. Periodically, you may want to drop a baseline
that is no longer used to conserve disk space. The snapshots associated with a baseline are retained
indefinitely until you explicitly drop the baseline or the baseline has expired.
To drop a baseline:
Review the existing baselines in the DBA_HIST_BASELINE view to determine the baseline that you
want to drop.
Use the DROP_BASELINE procedure to drop the desired baseline:

BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE (baseline_name => 'peak baseline',
cascade => FALSE, dbid => 3310949047);
END;
/
In the example, the name of baseline is peak baseline. The cascade parameter is set to FALSE,
which specifies that only the baseline is dropped. Setting this parameter to TRUE specifies that the
drop operation will also remove the snapshots associated with the baseline. The optional dbid
parameter specifies the database identifier, which in this example is 3310949047. If you do not specify
a value for dbid, the local database identifier is used as the default value.
5.3.3 Transporting Automatic Workload Repository Data
Oracle Database enables you to transport AWR data between systems. This is useful in cases where
you want to use a separate system to perform analysis of the AWR data. To transport AWR data, you
need to first extract the AWR snapshot data from the database on the source system, then load the
data into the database on the target system, as described in the following sections:

12

Extracting AWR Data

Loading AWR Data
5.3.3.1 Extracting AWR Data
The awrextr.sql script extracts the AWR data for a range of snapshots from the database into a Data
Pump export file. Once created, this dump file can be transported to another system where the
extracted data can be loaded. To run the awrextr.sql script, you need to be connected to the database
as the SYS user.
To extract AWR data:
At the SQL prompt, enter:

@$ORACLE_HOME/rdbms/admin/awrextr.sql
A list of the databases in the AWR schema is displayed.
Specify the database from which the AWR data will be extracted:

Enter value for db_id: 1377863381

In this example, the database with the database identifier of 1377863381 is selected.
Specify the number of days for which you want to list snapshot Ids.

Enter value for num_days: 2

A list of existing snapshots for the specified time range is displayed. In this example, snapshots
captured in the last 2 days are displayed.
Define the range of snapshots for which AWR data will be extracted by specifying a beginning and
ending snapshot Id:

Enter value for begin_snap: 30

Enter value for end_snap: 40
In this example, the snapshot with a snapshot Id of 30 is selected as the beginning snapshot, and the
snapshot with a snapshot Id of 40 is selected as the ending snapshot.
A list of directory objects is displayed.
Specify the directory object pointing to the directory where the export dump file will be stored:

Enter value for directory_name: DATA_PUMP_DIR

In this example, the directory object DATA_PUMP_DIR is selected.
Specify the prefix for name of the export dump file (the .dmp suffix will be automatically appended):

Enter value for file_name: awrdata_30_40

13

In this example, an export dump file named awrdata_30_40 will be created in the directory
corresponding to the directory object you specified:

Dump file set for SYS.SYS_EXPORT_TABLE_01 is:

C:\ORACLE\PRODUCT\11.1.0.5\DB_1\RDBMS\LOG\AWRDATA_30_40.DMP
Job "SYS"."SYS_EXPORT_TABLE_01" successfully completed at 08:58:20
Depending on the amount of AWR data that needs to be extracted, the AWR extract operation may
take a while to complete. Once the dump file is created, you can use Data Pump to transport the file
to another system.
See Also:
Oracle Database Utilities for information about using Data Pump
5.3.3.2 Loading AWR Data
Once the export dump file is transported to the target system, you can load the extracted AWR data
using the awrload.sql script. The awrload.sql script will first create a staging schema where the
snapshot data is transferred from the Data Pump file into the database. The data is then transferred
from the staging schema into the appropriate AWR tables. To run the awrload.sql script, you need to
be connected to the database as the SYS user.
To load AWR data:
At the SQL prompt, enter:

@$ORACLE_HOME/rdbms/admin/awrload.sql
A list of directory objects is displayed.
Specify the directory object pointing to the directory where the export dump file is located:

Enter value for directory_name: DATA_PUMP_DIR

In this example, the directory object DATA_PUMP_DIR is selected.
Specify the prefix for name of the export dump file (the .dmp suffix will be automatically appended):

Enter value for file_name: awrdata_30_40

In this example, the export dump file named awrdata_30_40 is selected.
Specify the name of the staging schema where the AWR data will be loaded:

Enter value for schema_name: AWR_STAGE

In this example, a staging schema named AWR_STAGE will be created where the AWR data will be
loaded.
Specify the default tablespace for the staging schema:

14

Enter value for default_tablespace: SYSAUX

In this example, the SYSAUX tablespace is selected.
Specify the temporary tablespace for the staging schema:

Enter value for temporary_tablespace: TEMP

In this example, the TEMP tablespace is selected.
A staging schema named AWR_STAGE will be created where the AWR data will be loaded. After the
AWR data is loaded into the AWR_STAGE schema, the data will be transferred into the AWR tables in
the SYS schema:

Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT

Completed 113 CONSTRAINT objects in 11 seconds
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
Completed 1 REF_CONSTRAINT objects in 1 seconds
Job "SYS"."SYS_IMPORT_FULL_03" successfully completed at 09:29:30
... Dropping AWR_STAGE user
End of AWR Load
Depending on the amount of AWR data that needs to be loaded, the AWR load operation may take a
while to complete. After the AWR data is loaded, the staging schema will be dropped automatically.
5.3.4 Using Automatic Workload Repository Views
Typically, you would view the AWR data through Oracle Enterprise Manager or AWR reports.
However, you can also view the statistics with the following views:
V$ACTIVE_SESSION_HISTORY
This view displays active database session activity, sampled once every second. See "Active Session
History (ASH)".
V$ metric views provide metric data to track the performance of the system
The metric views are organized into various groups, such as event, event class, system, session,
service, file, and tablespace metrics. These groups are identified in the V$METRICGROUP view.
DBA_HIST views
The DBA_HIST views contain historical data stored in the database. This group of views includes:
DBA_HIST_ACTIVE_SESS_HISTORY displays the history of the contents of the in-memory active
session history for recent system activity.
DBA_HIST_BASELINE displays information about the baselines captured on the system
DBA_HIST_DATABASE_INSTANCE displays information about the database environment
DBA_HIST_SNAPSHOT displays information on snapshots in the system
DBA_HIST_SQL_PLAN displays the SQL execution plans
DBA_HIST_WR_CONTROL displays the settings for controlling AWR
See Also:

15

Oracle Database Reference for information on dynamic and static data dictionary views
5.3.5 Generating Automatic Workload Repository Reports
An AWR report shows data captured between two snapshots (or two points in time). The AWR reports
are divided into multiple sections. The HTML report includes links that can be used to navigate quickly
between sections. The content of the report contains the workload profile of the system for the
selected range of snapshots.
The primary interface for generating AWR reports is Oracle Enterprise Manager. Whenever possible,
you should generate AWR reports using Oracle Enterprise Manager, as described in Oracle Database
2 Day + Performance Tuning Guide. If Oracle Enterprise Manager is unavailable, you can generate
AWR reports by running SQL scripts:
The awrrpt.sql SQL script generates an HTML or text report that displays statistics for a range of
snapshot Ids.
The awrrpti.sql SQL script generates an HTML or text report that displays statistics for a range of
snapshot Ids on a specified database and instance.
The awrsqrpt.sql SQL script generates an HTML or text report that displays statistics of a particular
SQL statement for a range of snapshot Ids. Run this report to inspect or debug the performance of a
SQL statement.
The awrsqrpi.sql SQL script generates an HTML or text report that displays statistics of a particular
SQL statement for a range of snapshot Ids on a specified database and instance. Run this report to
inspect or debug the performance of a SQL statement on a specific database and instance.
The awrddrpt.sql SQL script generates an HTML or text report that compares detailed performance
attributes and configuration settings between two selected time periods.
The awrddrpi.sql SQL script generates an HTML or text report that compares detailed performance
attributes and configuration settings between two selected time periods on a specific database and
instance.
Note:
To run these scripts, you must be granted the DBA role. If you run a report on a database that does
not have any workload activity during the specified range of snapshots, calculated percentages for
some report statistics can be less than 0 or greater than 100. This result simply means that there is no
meaningful value for the statistic.
5.3.5.1 Running the awrrpt.sql Report
To generate an HTML or text report for a range of snapshot Ids, run the awrrpt.sql script at the SQL
prompt:

@$ORACLE_HOME/rdbms/admin/awrrpt.sql
First, you need to specify whether you want an HTML or a text report.

Enter value for report_type: text

Specify the number of days for which you want to list snapshot Ids.

16

Enter value for num_days: 2

After the list displays, you are prompted for the beginning and ending snapshot Id for the workload
repository report.

Enter value for begin_snap: 150

Enter value for end_snap: 160
Next, accept the default report name or enter a report name. The default name is accepted in the
following example:

Enter value for report_name:

Using the report name awrrpt_1_150_160
The workload repository report is generated.
5.3.5.2 Running the awrrpti.sql Report
To specify a database and instance before entering a range of snapshot Ids, run the awrrpti.sql script
at the SQL prompt to generate an HTML or text report:

@$ORACLE_HOME/rdbms/admin/awrrpti.sql
First, specify whether you want an HTML or a text report. After that, a list of the database identifiers
and instance numbers displays, similar to the following:

Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name
Instance Host
----------- -------- ------------ ------------ -----------3309173529
1 MAIN
main
dlsun1690
3309173529
1 TINT251
tint251
stint251
Enter the values for the database identifier (dbid) and instance number (inst_num) at the prompts.

Enter value for dbid: 3309173529

Using 3309173529 for database Id
Enter value for inst_num: 1
Next you are prompted for the number of days and snapshot Ids, similar to the awrrpt.sql script,
before the text report is generated. See "Running the awrrpt.sql Report".
5.3.5.3 Running the awrsqrpt.sql Report
To generate an HTML or text report for a particular SQL statement, run the awrsqrpt.sql script at the
SQL prompt:

@$ORACLE_HOME/rdbms/admin/awrsqrpt.sql
First, you need to specify whether you want an HTML or a text report.

17

Enter value for report_type: text

Specify the number of days for which you want to list snapshot Ids.

Enter value for num_days: 1

After the list displays, you are prompted for the beginning and ending snapshot Id for the workload
repository report.

Enter value for begin_snap: 146

Enter value for end_snap: 147
Specify the SQL Id of a particular SQL statement to display statistics.

Enter value for sql_id: 2b064ybzkwf1y

Next, accept the default report name or enter a report name. The default name is accepted in the
following example:

Enter value for report_name:

Using the report name awrsqlrpt_1_146_147.txt
The workload repository report is generated.
5.3.5.4 Running the awrsqrpi.sql Report
To specify a database and instance before entering a particular SQL statement Id, run the
awrsqrpi.sql script at the SQL prompt to generate an HTML or text report:

@$ORACLE_HOME/rdbms/admin/awrsqrpi.sql
First, you need to specify whether you want an HTML or a text report.

Enter value for report_type: text

Next, a list of the database identifiers and instance numbers displays, similar to the following:

Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name
Instance Host
----------- -------- ------------ ------------ -----------3309173529
1 MAIN
main
dlsun1690
3309173529
1 TINT251
tint251
stint251
Enter the values for the database identifier (dbid) and instance number (inst_num) at the prompts.

Enter value for dbid: 3309173529

Using 3309173529 for database Id

18

Enter value for inst_num: 1

Using 1 for instance number
Next you are prompted for the number of days, snapshot Ids, SQL Id and report name, similar to the
awrsqrpt.sql script, before the text report is generated. See "Running the awrsqrpt.sql Report".
5.3.5.5 Running the awrddrpt.sql Report
To compare detailed performance attributes and configuration settings between two time periods, run
the awrddrpt.sql script at the SQL prompt to generate an HTML or text report:

@$ORACLE_HOME/rdbms/admin/awrddrpt.sql
First, you need to specify whether you want an HTML or a text report.

Enter value for report_type: text

Specify the number of days for which you want to list snapshot Ids for the first time period.

Enter value for num_days: 2

After the list displays, you are prompted for the beginning and ending snapshot Id for the first time
period.

Enter value for begin_snap: 102

Enter value for end_snap: 103
Next, specify the number of days for which you want to list snapshot Ids for the second time period.

Enter value for num_days2: 1

After the list displays, you are prompted for the beginning and ending snapshot Id for the second time
period.

Enter value for begin_snap2: 126

Enter value for end_snap2: 127
Next, accept the default report name or enter a report name. The default name is accepted in the
following example:

Enter value for report_name:

Using the report name awrdiff_1_102_1_126.txt
The workload repository report is generated.
5.3.5.6 Running the awrddrpi.sql Report
To specify a database and instance before selecting time periods to compare, run the awrddrpi.sql
script at the SQL prompt to generate an HTML or text report:

19

@$ORACLE_HOME/rdbms/admin/awrddrpi.sql
First, you need to specify whether you want an HTML or a text report.

Enter value for report_type: text

Next, a list of the database identifiers and instance numbers displays, similar to the following:

Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name
Instance Host
----------- -------- ------------ ------------ -----------3309173529
1 MAIN
main
dlsun1690
3309173529
1 TINT251
tint251
stint251
Enter the values for the database identifier (dbid) and instance number (inst_num) for the first time
period at the prompts.

Enter value for dbid: 3309173529

Using 3309173529 for Database Id for the first pair of snapshots
Enter value for inst_num: 1
Using 1 for Instance Number for the first pair of snapshots
Specify the number of days for which you want to list snapshot Ids for the first time period.

Enter value for num_days: 2

After the list displays, you are prompted for the beginning and ending snapshot Id for the first time
period.

Enter value for begin_snap: 102

Enter value for end_snap: 103
Next, enter the values for the database identifier (dbid) and instance number (inst_num) for the
second time period at the prompts.

Enter value for dbid2: 3309173529

Using 3309173529 for Database Id for the second pair of snapshots
Enter value for inst_num2: 1
Using 1 for Instance Number for the second pair of snapshots
Specify the number of days for which you want to list snapshot Ids for the second time period.

Enter value for num_days2: 1

After the list displays, you are prompted for the beginning and ending snapshot Id for the second time
period.

20

Enter value for begin_snap2: 126

Enter value for end_snap2: 127
Next, accept the default report name or enter a report name. The default name is accepted in the
following example:

Enter value for report_name:

Using the report name awrdiff_1_102_1_126.txt
The workload repository report is generated.
5.3.6 Generating Active Session History Reports
Use Active Session History (ASH) reports to perform analysis of:
Transient performance problems that typically last for a few minutes
Scoped or targeted performance analysis by various dimensions or their combinations, such as time,
session, module, action, or SQL_ID
You can view ASH reports using Enterprise Manager or by running the following SQL scripts:
The ashrpt.sql SQL script generates an HTML or text report that displays ASH information for a
specified duration.
The ashrpti.sql SQL script generates an HTML or text report that displays ASH information for a
specified duration for a specified database and instance.
The reports are divided into multiple sections. The HTML report includes links that can be used to
navigate quickly between sections. The content of the report contains ASH information used to identify
blocker and waiter identities and their associated transaction identifiers and SQL for a specified
duration. For more information on ASH, see "Active Session History (ASH)".
The primary interface for generating ASH reports is Oracle Enterprise Manager. Whenever possible,
you should generate ASH reports using Oracle Enterprise Manager, as described in Oracle Database
2 Day + Performance Tuning Guide. If Oracle Enterprise Manager is unavailable, you can generate
ASH reports by running SQL scripts, as described in the following sections:
Running the ashrpt.sql Report
Running the ashrpti.sql Report
5.3.6.1 Running the ashrpt.sql Report
To generate a text report of ASH information, run the ashrpt.sql script at the SQL prompt:

@$ORACLE_HOME/rdbms/admin/ashrpt.sql
First, you need to specify whether you want an HTML or a text report.

Enter value for report_type: text

Specify the time frame to collect ASH information by first specifying the begin time in minutes prior to
the system date.

21

Enter value for begin_time: -10

Next, enter the duration in minutes that the report for which you want to capture ASH information from
the begin time. The default duration of system date minus begin time is accepted in the following
example:

Enter value for duration:

The report in this example will gather ASH information beginning from 10 minutes before the current
time and ending at the current time. Next, accept the default report name or enter a report name. The
default name is accepted in the following example:

Enter value for report_name:

Using the report name ashrpt_1_0310_0131.txt
The session history report is generated.
5.3.6.2 Running the ashrpti.sql Report
If you want to specify a database and instance before setting the time frame to collect ASH
information, run the ashrpti.sql report at the SQL prompt to generate a text report:

@$ORACLE_HOME/rdbms/admin/ashrpti.sql
First, specify whether you want an HTML or a text report. After that, a list of the database Ids and
instance numbers displays, similar to the following:

Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name
Instance Host
----------- -------- ------------ ------------ -----------3309173529
1 MAIN
main
dlsun1690
3309173529
1 TINT251
tint251
stint251
Enter the values for the database identifier (dbid) and instance number (inst_num) at the prompts.

Enter value for dbid: 3309173529

Using 3309173529 for database id
Enter value for inst_num: 1

22