Automatic Workload Repository (AWR) in Oracle Database 10g

Oracle have provided many performance gathering and reporting tools over
the years. Originally the UTLBSTAT/UTLESTAT scripts were used to
monitor performance metrics. Oracle8i introduced the Statspack
functionality which Oracle9i extended. In Oracle 10g statspack has evolved
into the Automatic Workload Repository (AWR).

AWR Features

The AWR is used to collect performance statistics including:

● Wait events used to identify performance problems.
● Time model statistics indicating the amount of DB time associated
with a process from the V$SESS_TIME_MODEL and
V$SYS_TIME_MODEL views.
● Active Session History (ASH) statistics from the
V$ACTIVE_SESSION_HISTORY view.
● Some system and session statistics from the V$SYSSTAT and
V$SESSTAT views.
● Object usage statistics.
● Resource intensive SQL statements.

Snapshots

By default snapshots of the relevant data are taken every hour and retained
for 7 days. The default values for these settings can be altered using:
BEGIN

DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings
(
retention => 43200, -- Minutes (= 30 Days). Current value
retained if NULL.
interval => 30); -- Minutes. Current value retained if
NULL.
END;
/

The changes to the settings are reflected in the

DBA_HIST_WR_CONTROL view. Typically the retention period should
capture at least one complete workload cycle. If you system has monthly
archive and loads a 1 month retention time would be more beneficial that the
default 7 days. An interval of "0" switches off snapshot collection, which in
turn stops much of the self-tuning functionality, hence this is not
recommended. Automatic collection is only possible if the
STATISTICS_LEVEL parameter is set to TYPICAL or ALL. If the value is
set to BASIC manual snapshots can be taken, but they will be missing some
statistics.

Extra snapshots can be taken and existing snapshots can be removed using:
EXEC DBMS_WORKLOAD_REPOSITORY.create_snapshot;

BEGIN
DBMS_WORKLOAD_REPOSITORY.drop_snapshot_range (
low_snap_id => 22,
high_snap_id => 32);
END;
/

Snapshot information can be queried from the DBA_HIST_SNAPSHOT

view.

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:
BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE
(low_snap_id => 22,
high_snap_id => 32, dbid => 3310949047);
END;
/

Baselines

A baseline is a pair of snapshots that represents a specific period of usage.

Once baselines are defined they can be used to compare current performance
against similar periods in the past. You may wish to create baseline to
represent a period of batch processing like:
BEGIN
DBMS_WORKLOAD_REPOSITORY.create_baseline (
start_snap_id => 210,
end_snap_id => 220,
baseline_name => 'batch baseline');
END;
/

The pair of snapshots associated with a baseline are retained until the
baseline is explicitly deleted:
BEGIN
DBMS_WORKLOAD_REPOSITORY.drop_baseline (
baseline_name => 'batch baseline',
cascade => FALSE); -- Deletes associated snapshots if
TRUE.
END;
/

Baseline information can be queried from the DBA_HIST_BASELINE

view.

Workload Repository Views

The following workload repository views are available:

● V$ACTIVE_SESSION_HISTORY - Displays the active session
history (ASH) sampled every second.
● 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_ACTIVE_SESS_HISTORY - Displays the history
contents of the active session history.
● DBA_HIST_BASELINE - Displays baseline information.
● DBA_HIST_DATABASE_INSTANCE - Displays database
environment information.
● DBA_HIST_SNAPSHOT - Displays snapshot information.
● DBA_HIST_SQL_PLAN - Displays SQL execution plans.
 ● DBA_HIST_WR_CONTROL - Displays AWR settings.

Workload Repository Reports

Oracle provide two scripts to produce workload repository reports

(awrrpt.sql and awrrpti.sql). They are similar in format to the statspack
reports and give the option of HTML or plain text formats. The two reports
give essential the same output but the awrrpti.sql allows you to select a
single instance. The reports can be generated as follows:
@$ORACLE_HOME/rdbms/admin/awrrpt.sql
SQL script generates an HTML or text report that displays statistics for a
range of snapshot Ids
@$ORACLE_HOME/rdbms/admin/awrrpti.sql

SQL script generates an HTML or text report that displays statistics for a
range of snapshot Ids for a specified database and instance.

The scripts prompt you to enter the report format (html or text), the start
snapshot id, the end snapshot id and the report filename. The resulting report
can be opend in a browser or text editor accordingly.

Running the awrrpt.sql Report

To generate a 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 days for which you want to list snapshot Ids.
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.

Lock types

There are three general classes of locks in oracle

DML locks : (Select, Insert, Update, Delete, Merge)
DML locks are the mechanism that allows for concurrent data modifications.
For example locks on a specific row or lock at the table level which locks
every row.
These are used to ensure that only one person at a time modifies a row and
no one can
drop a table upon which you are working.
TX(Transaction) locks)
A TX lock is acquired when a transaction initiates its first change and it is
held until
the transaction performs a COMMIT or ROLLBACK. It is used as a
queuing
mechanism so that other sessions can wait for the transaction to complete.
Each and every row we modify or select for update in a transaction will
point to an associated TX
lock.
Since the lock is stored as an attribute of data, oracle does not need a
traditional lock manager.
V$transaction : This contains an entry for every active transaction.
V$session : shows the sessions logged in
V$lock : This contains an entry for all enqueue locks being
held as well as
sessions that are waiting on locks.
TM(DML enqueue )locks
These are used to ensure that the structure of a table is not altered while we
are modifying
its contents. If we have updated a table we will acquire a TM lock.
This will prevent another user from executing drop or alter commands on
that table.
If another user attempts to perform DDL on the table while we have a TM
lock on the
table he will get following error message.
Resource busy and acquire with nowait specified.

DDL Locks ( CREATE and ALTER )

These are to protect the definition of the structure of objects.
These are automatically placed against objects during a DDL operation to
protect them
from changing by other sessions.
Latches
These are lightweight serialization devices used to coordinate multiuser
access to shared
data structures, objects, files.
Latches are locks designed to be held for extremely short periods of time.
They are used to protect certain memory structures, such as the database
buffer cache,
or the library cache in the shared pool.

First create a blocking lock

create a situation where one user is actively blocking another. Open two
sessions.
In th first session create a table and insert some rows then use commit.
Now grab a lock on the whole table, still in Session 1:
SQL> select * from sam1 for update ;
And in Session 2, try to update a row from the same
table sam1
SQL > update sam1 set name='ramesh' where
name='suresh';
This statement will hang, blocked by the lock that
Session 1 is holding on the entire table

Identify the blocking session

Oracle provides a view, DBA_BLOCKERS, which lists
the SIDs of all blocking sessions. But this view is
often, a bit slower than simply querying V$LOCK,
and it doesn't offer any information beyond the
SIDs of any sessions that are blocking other
sessions. The V$LOCK view is faster to query, makes
it easy to identify the blocking session, and has a
lot more information.
SQL> select * from v$lock ;
Note the BLOCK column. If a session holds a lock
that's blocking another session, BLOCK=1. Further,
you can tell which session is being blocked by
comparing the values in ID1 and ID2. The blocked
session will have the same values in ID1 and ID2 as
the blocking session, and, since it is requesting a
lock it's unable to get, it will have REQUEST > 0.
To avoid having to stare at the table and cross-compare ID1's and ID2's, put
this in a query:
SQL> select l1.sid, ' IS BLOCKING ', l2.sid
2 from v$lock l1, v$lock l2
3 where l1.block =1 and l2.request > 0
4 and l1.id1=l2.id1
5 and l1.id2=l2.id2
SQL>
Lock type and the ID1 / ID2 columns
we already know that the blocking lock is an exclusive DML lock, since
we're the ones who issued the locking statement. But most of the time, you
won't be so lucky. Fortunately, you can read this information from the
v$lock table with little effort.
The first place to look is the TYPE column. There are dozens of lock types,
but the vast majority are system types. System locks are normally only held
for a very brief amount of time
There are only three types of user locks, TX, TM and UL. UL is a user-
defined lock -- a lock defined with the DBMS_LOCK package. The TX lock
is a row transaction lock; it's acquired once for every transaction that
changes data, no matter how many objects you change in that transaction.
The ID1 and ID2 columns point to the rollback segment and transaction
table entries for that transaction.
The TM lock is a DML lock. It's acquired once for each object that's being
changed. The ID1 column identifies the object being modified.
You can see more information on TM and TX locks just by looking at the
lock modes. The LMODE and REQUEST columns both use the same
numbering for lock modes, in order of increasing exclusivity: from 0 for no
lock, to 6 for exclusive lock. A session must obtain an exclusive TX lock in
order to change data; LMODE will be 6. If it can't obtain an exclusive lock
because some of the rows it wants to change are locked by another session,
then it will request a TX in exclusive mode; LMODE will be 0 since it does
not have the lock, and REQUEST will be 6. You can see this interaction in
the rows we selected earlier from v$lock:
Lock Modes
You can see more information on TM and TX locks just by looking at the
lock modes. The LMODE and REQUEST columns both use the same
numbering for lock modes, in order of increasing exclusivity: from 0 for no
lock, to 6 for exclusive lock. A session must obtain an exclusive TX lock in
order to change data; LMODE will be 6. If it can't obtain an exclusive lock
because some of the rows it wants to change are locked by another session,
then it will request a TX in exclusive mode; LMODE will be 0 since it does
not have the lock, and REQUEST will be 6. You can see this interaction in
the rows we selected earlier from v$lock:
Identifying the locked object
Now that we know that each TM row points to a locked object, we can use
ID1 to identify the object.
SQL> select object_name from dba_objects where object_id=88519 ;

Identifying the locked row

We can get this information from v$session by looking at the v$session
entry for the blocked session:
SQL> select row_wait_obj#, row_wait_file#,
row_wait_block#, row_wait_row#
2* from v$session where sid=479 ;

ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK#

ROW_WAIT_ROW#
------------- -------------- ---------------
-------------
 88519 16 171309
0

This gives us the object ID, the relative file number, the block in the datafile,
and the row in the block that the session is waiting on. If that list of data
sounds familiar, it's because those are the four components of an extended
ROWID. We can build the row's actual extended ROWID from these
components using the DBMS_ROWID package. The ROWID_CREATE
function takes these arguments and returns the ROWID:
SQL> select do.object_name,
2 row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#,
3 dbms_rowid.rowid_create ( 1, ROW_WAIT_OBJ#,
ROW_WAIT_FILE#, ROW_WAIT_BLOCK#, ROW_WAIT_ROW# )
4 from v$session s, dba_objects do
5 where sid=543
6 and s.ROW_WAIT_OBJ# = do.OBJECT_ID ;

And, of course, this lets us inspect the row directly.

SQL> select * from sam1 where rowid='AAAVnHAAQAAAp0tAAA' ;

SELECT SQL_TEXT
FROM V$SQLAREA
WHERE (ADDRESS, HASH_VALUE) IN
(SELECT SQL_ADDRESS, SQL_HASH_VALUE
FROM V$SESSION
WHERE SID = &sid_number)
/

SELECT USERNAME, OSUSER, TERMINAL, SID, SERIAL#,

PROCESS, PROGRAM
FROM V$SESSION
ORDER BY OSUSER
/