You are on page 1of 4

Understand each field of AWR

posted Mar 10, 2011, 3:20 AM by Sachchida Ojha

AWR report is broken into multiple parts.

1)Instance information:-
This provides information the instance name , number,snapshot ids,total time the report was taken for and the database time during this elapsed time.

Elapsed time= end snapshot time - start snapshot time


Database time= Work done by database during this much elapsed time( CPU and I/o both add to Database time).If this is lesser than the elapsed time by a great margin, then dat

2)Cache Sizes : This shows the size of each SGA region after AMM has changed them. This information
can be compared to the original init.ora parameters at the end of the AWR report.

3)Load Profile: This important section shows important rates expressed in units of per second and
transactions per second.This is very important for understanding how is the instance behaving.This has to be compared to base line report to understand the expected load on the

4)Instance Efficiency Percentages (Target 100%): This section talks about how close are the vital ratios like buffer cache hit, library cache hit,parses etc.These can be taken as indic
performance problem.Hence these are not stand alone statistics, should be read for a high level view .

5)Shared Pool Statistics: This summarizes changes to the shared pool during the snapshot
period.

6)Top 5 Timed Events :This is the section which is most relevant for analysis.This section shows what % of database time was the wait event seen for.Till 9i, this was the way to backt

7)RAC Statistics :This part is seen only incase of cluster instance.This provides important indication on the average time take for block transfer, block receiving , messages ., which c

8)Wait Class : This Depicts which wait class was the area of contention and where we need to focus.Was that network, concurrency, cluster, i/o Application, configuration etc.

9)Wait Events Statistics Section: This section shows a breakdown of the main wait events in the
database including foreground and background database wait events as well as time model, operating
system, service, and wait classes statistics.

10)Wait Events: This AWR report section provides more detailed wait event information for foreground
user processes which includes Top 5 wait events and many other wait events that occurred during
the snapshot interval.

11)Background Wait Events: This section is relevant to the background process wait events.

12)Time Model Statistics: Time mode statistics report how database-processing time is spent. This
section contains detailed timing information on particular components participating in database
processing.This gives information about background process timing also which is not included in database time.

13)Operating System Statistics: This section is important from OS server contention point of view.This section shows the main external resources including I/O, CPU, memory, and n

14)Service Statistics: The service statistics section gives information services and their load in terms of CPU seconds, i/o seconds, number of buffer reads etc.

15)SQL Section: This section displays top SQL, ordered by important SQL execution metrics.

a)SQL Ordered by Elapsed Time: Includes SQL statements that took significant execution
time during processing.

b)SQL Ordered by CPU Time: Includes SQL statements that consumed significant CPU time
during its processing.

c)SQL Ordered by Gets: These SQLs performed a high number of logical reads while
retrieving data.

d)SQL Ordered by Reads: These SQLs performed a high number of physical disk reads while
retrieving data.
e)SQL Ordered by Parse Calls: These SQLs experienced a high number of reparsing operations.

f)SQL Ordered by Sharable Memory: Includes SQL statements cursors which consumed a large
amount of SGA shared pool memory.

g)SQL Ordered by Version Count: These SQLs have a large number of versions in shared pool
for some reason.

16)Instance Activity Stats: This section contains statistical information describing how the database
operated during the snapshot period.

17)I/O Section: This section shows the all important I/O activity.This provides time it took to make 1 i/o say Av Rd(ms), and i/o per second say Av Rd/s.This should be compared to t

18)Advisory Section: This section show details of the advisories for the buffer, shared pool, PGA and
Java pool.

19)Buffer Wait Statistics: This important section shows buffer cache waits statistics.

20)Enqueue Activity: This important section shows how enqueue operates in the database. Enqueues are
special internal structures which provide concurrent access to various database resources.

21)Undo Segment Summary: This section gives a summary about how undo segments are used by the database.
Undo Segment Stats: This section shows detailed history information about undo segment activity.

22)Latch Activity: This section shows details about latch statistics. Latches are a lightweight
serialization mechanism that is used to single-thread access to internal Oracle structures.The latch should be checked by its sleeps.The sleepiest Latch is the latch that is under co
highest contention.

23)Segment Section: This portion is important to make a guess in which segment and which segment type the contention could be.Tally this with the top 5 wait events.

Segments by Logical Reads: Includes top segments which experienced high number of
logical reads.

Segments by Physical Reads: Includes top segments which experienced high number of disk
physical reads.

Segments by Buffer Busy Waits: These segments have the largest number of buffer waits
caused by their data blocks.

Segments by Row Lock Waits: Includes segments that had a large number of row locks on
their data.

Segments by ITL Waits: Includes segments that had a large contention for Interested
Transaction List (ITL). The contention for ITL can be reduced by increasing INITRANS storage
parameter of the table.

24)Dictionary Cache Stats: This section exposes details about how the data dictionary cache is
operating.

25)Library Cache Activity: Includes library cache statistics which are needed in case you see library cache in top 5 wait events.You might want to see if the reload/invalidations a

26)SGA Memory Summary:This would tell us the difference in the respective pools at the start and end of report.This could be an indicator of setting minimum value for each, whe

27)init.ora Parameters: This section shows the original init.ora parameters for the instance during
the snapshot period.

There would be more Sections in case of RAC setups to provide details.

nctionality of V$SESSION and WAIT MODEL


posted Mar 10, 2011, 3:23 AM by Sachchida Ojha
In prior releases, we joined v$session_wait with the v$session to determine the sessions waits.
From Oracle 10g, all wait event columns from v$session_wait have been added
to v$session thus increasing performance by eliminating the overhead of joins.

1. New columns of V$SESSION related with enhanced wait model

(1) All V$SESSION_WAIT columns

SEQ#, EVENT#, EVENT, P1TEXT, P1, P1RAW, P2TEXT, P2, P2RAW, P3TEXT, P3, P3RAW,WAIT_TIME , SECONDS_IN_WAIT, STATE

(2) Brand new columns


BLOCKING_SESSION_STATUS : VALID/NO HOLDER GLOBAL/UNIMPLEMENTED/UNKNOWN
BLOCKING_SESSION : Session identifier of blocking session
WAIT_CLASS# : Wait class number
WAIT_CLASS : Name of the wait class.

2. How to determine a blocking session using only V$SESSION ?

session 1 : update dept set loc='SEOUL' where deptno=10;


session 2 : update dept set loc='SEOUL' where deptno=10;

(1) Finding Blocking Session


--- blockings.sql
col program format a40
col username format a10

select s.sid blocker, substr(s.program,1,40) program, w.username, w.sid blocked


from v$session s, v$session w
where w.blocking_session = s.sid
and w.blocking_session_status='VALID';
---

BLOCKER PROGRAM USERNAME BLOCKED


---------- ---------------------------------------- ---------- ----------
14 sqlplus@dhcp-samhwa-152-69-41-87 (TNS V1 SCOTT 9

(2) Finding Specific Type of WAIT EVENT.

Some enqueues and latches are now broken down in the specific type of event.
You will be able to see EVENT column for the enqueue in particular whether the breakdown
is made in v$session. The expected result is that instead of having a 'enqueue' wait,
you will see several 'enq%' type of waits.
--- waitevent.sql
col hevent format a40
col wevent format a40

select s.sid blocker,


s.event hevent,
w.event wevent,
w.sid blocked
from v$session s, v$session w
where w.blocking_session = s.sid
and w.blocking_session_status='VALID';
---

BLOCKER HEVENT WEVENT BLOCKED


---------- ---------------------------- ---------------------------- ---------
14 SQL*Net message from client enq: TX - row lock contention 9

(3) Finding Blocked OBJECT#, FILE#, BLOCK# and ROW#


--- blockedobj.sql
select sid, event, row_wait_obj# obj, row_wait_file# file,
row_wait_block# block, row_wait_row# row
from v$session s, v$session w
where w.blocking_session = s.sid
---

SID EVENT OBJ FILE BLOCK ROW


---- ------------------------------ ---------- ------ --------- ----
9 enq: TX - row lock contention 41456 1 46818 0

(4) Finding outstanding wait classes of sessions.

In Oracle 10G, wait events are classified into 14 categories of wait classes.
V$SESSION.WAIT_CLASS is used to gain quick insight into contentious areas of the
database.
--- waitclass.sql
col CLASS format a40
select wait_class# CLASS#, wait_class CLASS, count(event#)
from v$event_name
group by wait_class#, wait_class;
---

CLASS# CLASS COUNT(EVENT#)


------- ------------------------------------- --------------
0 Other 400
1 Application 8
2 Configuration 18
3 Administrative 40
4 Concurrency 12
5 Commit 1
6 Idle 49
7 Network 18
8 Archival Process Scheduling 19
9 Managed Recovery Processing Scheduling 10
10 User I/O 13
11 System I/O 17
12 Scheduler 6
13 Cluster 82

--- mostwaitclass.sql
select wait_class, count(username)
from v$session
group BY wait_class;
---

WAIT_CLASS COUNT(USERNAME)
-------------------------------- ---------------
Application 3
Idle 1
Other 1

You might also like