Analyzing and Interpreting AWR Report

1. 1
Analyzing and Interpreting
AWR Report
by
Satyendra Pasalapudi
@pasalapudi

2. 2
Agenda
• AWR Overview
• Why AWR is powerful than Statspack?
• Top 5 Timed Events
• Oracle Time Model, Wait Classes, & Metrics
• Interpreting AWR

3. 3
Automatic Workload Repository (AWR)
– Built-in repository of performance information (
Light Weight)
– Snapshots of database metrics taken every 60
minutes and retained for 7 days
– Foundation for all self-management functions
– Data to find root cause and suggest remedies.
MMON
In-memory
statistics
Snapshots
AWR
SGA
60 minutes

4. 4
Managing the AWR
– Retention period
• The default is 7 days
• Consider storage needs
– Collection interval
• The default is
60 minutes
• Consider storage needs and performance impact
– Collection level
• Basic (disables most of ADDM functionality)
• Typical (recommended)
• All (adds additional SQL tuning information to
snapshots)

5. 5
Secret Behind the Success of AWR and all
other self components from Oracle 10g (
ADDM , Metrics , Alerts) ?

6. 6
AiSHwarya Rai

7. 7
ASH ( Active Session History)
• Memory buffers in the fixed areas
• New Oracle Background Process
– MMNL – MMON Lite
• V$ACTIVE_SESSION_HISTORY
• X$ASH
• DBA_HIST_ACTIVE_SESS_HISTORY
– Based on WRH$_ACTIVE_SESSION_HISTORY

8. 8
ASH Architecture
Circular buffer
in SGA
V$ACTIVE_SESSION_HISTORY
X$ASH
AWR
WRH$_ACTIVE_SESSION_HISTORY
Every
30 mins
or
when buffer is
full
Samples with
variable size rows
Direct-path
inserts
MMON
Lite
(MMNL)
Indexed on timeIndexed on time

9. 9
ASH Details - General
• No installation or setup required
• Intended 30-min circular buffer in the SGA
• In memory ASH contains as much history as it can
store.
– Circular buffer not cleared when written to disk
• ASH on Disk (1 of 10 in memory samples)
• Init.ora
– STATISTICS_LEVEL = TYPICAL (Default)
• Master Switch
– _ACTIVE_SESSION_HISTORY = TRUE (Default)

10. 10
Session 1
Ash Samples Session State
TIME
10:00:00 10:00:01 10:00:02 10:00:03 10:00:04 10:00:05

11. 11
Session 1
Ash Samples Session State
TIME? ? ? ? ?
Sessions change a lot quicker but can
get the main picture via sampling by
sampling faster

12. 12
Session States
IO CPU IdleWait

13. 13
Session States
• Idle
• CPU
• Waiting
• I/O

14. 14
Session 1
Session 2
Session 3
Session 4
Samples for all users
10:15:00 10:15:01 10:15:02 10:15:03 10:15:04 10:15:05 10:15:06 10:15:07 TIME

15. 15
v$active_session_history
SESSION_ID NUMBER
SESSION_SERIAL# NUMBER
USER_ID NUMBER
SERVICE_HASH NUMBER
SESSION_TYPE VARCHAR2(10)
PROGRAM VARCHAR2(64)
MODULE VARCHAR2(48)
ACTION VARCHAR2(32)
CLIENT_ID VARCHAR2(64)
EVENT VARCHAR2(64)
EVENT_ID NUMBER
EVENT# NUMBER
SEQ# NUMBER
P1 NUMBER
P2 NUMBER
P3 NUMBER
WAIT_TIME NUMBER
TIME_WAITED NUMBER
CURRENT_OBJ# NUMBER
CURRENT_FILE# NUMBER
CURRENT_BLOCK# NUMBER0
SQL_ID VARCHAR2(13)
SQL_CHILD_NUMBER NUMBER
SQL_PLAN_HASH_VALUE NUMBER
SQL_OPCODE NUMBER
QC_SESSION_ID NUMBER
QC_INSTANCE_ID NUMBER
SAMPLE_ID NUMBER
SAMPLE_TIME TIMESTAMP(3)
When
Session
SQL
Wait
SESSION_STATE VARCHAR2(7)
WAIT_TIME NUMBER
State
TIME_WAITED NUMBER Duration

16. 16
AWR Infrastructure
SGA
V$ DBA_*
ADDM
Self-tuning
component
Self-tuning
component
…
Internal clients
External clients
EM SQL*Plus …
Efficient
in-memory
statistics
collection
AWR
snapshotsMMON

17. 17
Automatic Database Diagnostic Monitor (ADDM)
– Runs after each AWR snapshot
– Monitors the instance; detects bottlenecks
– Stores results within the AWR
Snapshots
ADDM
AWR
EM
ADDM results

18. 18
Advisory Framework
ADDM
SQL Tuning
Advisor
SQL Access
Advisor
Memory
Space
PGA Advisor
SGA
Segment Advisor
Undo Advisor
Buffer Cache
Advisor
Library Cache
Advisor
PGA
Backup MTTR Advisor

19. 19
AWR TOP5 Timed Events – Wait Class

20. 20
Active Sessions in OEM

21. 21
AWR– Top Timed Events
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~
% Total
Event Waits Time (s) Ela Time
--------------------------- ------------ ----------- --------
db file sequential read 399,394,399 2,562,115 52.26
CPU time 960,825 19.60
buffer busy waits 122,302,412 540,757 11.03
PL/SQL lock timer 4,077 243,056 4.96
log file switch 188,701 187,648 3.83
(checkpoint incomplete)

22. 22
Top 12 Waits
NAME Count % Total
1. db file sequential read 23,850.00 11.67%
2. log file sync 20,594.00 10.08%
3. db file scattered read 15,505.00 7.59%
4. latch free 11,078.00 5.42%
5. enqueue 7,732.00 3.78%
6. SQL*Net more data from client 7,510.00 3.67%
7. direct path read 5,840.00 2.86%
8. direct path write 4,868.00 2.38%
9. buffer busy waits 4,589.00 2.25%
10. SQL*Net more data to client 3,805.00 1.86%
11. log buffer space 2,990.00 1.46%
12. log file switch completion 2,878.00 1.41%
Above is over 80% of wait times reported

23. 23
Top 36 Waits
19. write complete waits
20. library cache lock
21. SQL*Net more data from dblink
22. log file switch (checkpoint incomplete)
23. library cache load lock
24. row cache lock
25. local write wait
26. sort segment request
27. process startup
28. unread message
29. file identify
30. pipe put
31. switch logfile command
32. SQL*Net break/reset to dblink
33. log file switch (archiving needed)
34. Wait for a undo record
35. direct path write (lob)
36. undo segment extension
1. db file sequential read
2. log file sync
3. db file scattered read
4. latch free
5. enqueue
6. SQL*Net more data from client
7. direct path read
8. direct path write
9. buffer busy waits
10. SQL*Net more data to client
11. log buffer space
12. log file switch completion
13. library cache pin
14. SQL*Net break/reset to client
15. io done
16. file open
17. free buffer waits
18. db file parallel read

24. 24
Waits
I/O
Library Cache
Locks
Redo
Buffer Cache
SQL*Net
Wait Areas

25. 25
Wait Tree
Waits
IO
Buffer Cache
Library Cache
Lock
Redo
SQL Net
Buffer Busy
Rollback
Free lists
IO ReadCache Latches
Library Cache
Shared Pool
TX Row Lock
TX ITL Lock
HW Lock
Write IO
Read IO
Log Buffer
Log File Sync
Log File

26. 26
OEM TOP Activity

27. 27
OEM TOP Activity

28. 28
OEM TOP Activity

29. 29
Empty. Why?
Top 5 Timed Events – CPU time

30. 30
• Because “CPU time” is not wait event. It is the
time spent on CPU to do the actual work.
Top 5 Timed Events – CPU time

31. 31
• We had 60*60=3600 CPU Seconds to use in that interval if it is a single CPU
machine and 1 hour is the snap.
• If I tell you there were 32 CPUs, means:
60*60*32=115200 CPU seconds to use in 1 hr interval. “Assuming” only
1 Database is running on box and no other application load except Oracle
database.
• (14,659/115,200)*100 = 12.73% of Total CPU
• So we are not CPU bound. “Hopefully”
Top 5 Timed Events – CPU time

32. 32
What Is DB Time?
DB Time

33. 33
DB Time =
DB Wait Time +
DB CPU Time

34. 34
Parse cpu to Parse elapsed ratio?
• If you spend 1 CPU second on CPU to parse
but total elapsed is 5 second wall clock time
then it means you are waiting on some
resources to complete the parsing.
• 100% ratio means parse CPU = Parse elapsed
time so no waits or no contention.

35. 35
• (8879/110582)*100=8.03%
How does Oracle calculates it?

36. 36
What does this ratio mean?
• Parse CPU to Parse Elapsd %: 8.03
• It is percentage. 8.03% means .0803
• If you divide it by 1 then 1/.0803 = 12.45
• Which means 12.45 second (wall clock time)
must be elapsed for every cpu second for
parsing. BAD
• It represents resource contention while parsing.

37. 37
Execute to Parse Ratio?
• This a ratio which measures how many times
a statement got executed as opposed to parsed.
• if it is 99.99% then it means for 1 parse there
are 10,000 executes.
• if it is 90% then it means for 1 parse there are
10 executes.
• For OLTP, good to be near 99%, for DSS it
could be lower as “generally” all sql
statements/reports are unique.

38. 38
• EXECUTE to PARSE = (1- parse/execute)
• 1-915,652/9,944,590 = 1-0.092 = 0.9079
• For percentage => .9079*100 = 90.79%
How does Oracle calculates it?

39. 39
• EXECUTE to PARSE %= 90.79
• 1-parse/execute = .9079
• Parse/execute = 1-.9079
• Parse/execute = 0.0921
• Parse/execute = 921/10000
• For parse = 1 execute = 10.85
• So 1 parse for every ~11 executes.
What does this ratio mean?

40. 40
?

41. 41
Thank You
www.linkedin.com/in/satyendra
@pasalapudi

42. 42
Wait Problem Potential Fix
Enqueue - ST Use LMT’s or pre-allocate large extents
Enqueue - HW Pre-allocate extents above HW (high
water mark.)
Enqueue – TX Increase initrans and/or maxtrans (TX4)
on (transaction) the table or index. Fix
locking issues if TX6. Bitmap (TX4) &
Duplicates in Index (TX4).
Enqueue - TM Index foreign keys; Check application
(trans. mgmt.) locking of tables. DML Locks.

43. 43 43
Wait Problem Potential Fix
Sequential Read Indicates many index reads – tune the
code (especially joins); Faster I/O
Scattered Read Indicates many full table scans – tune
the code; cache small tables; Faster I/O
Free Buffer Increase the DB_CACHE_SIZE;
shorten the checkpoint; tune the code to
get less dirty blocks, faster I/O,
use multiple DBWR’s
Buffer Busy Segment Header – Add freelists (if inserts)
or freelist groups (esp. RAC). Use ASSM.

44. 44 44
Wait Problem Potential Fix
Buffer Busy Data Block – Separate ‘hot’ data; potentially
use reverse key indexes; fix queries to
reduce the blocks popularity, use
smaller blocks, I/O, Increase initrans
and/or maxtrans (this one’s debatable)
Reduce records per block.
Buffer Busy Undo Header – Add rollback segments
or increase size of segment area (auto undo)
Buffer Busy Undo block – Commit more (not too
much) Larger rollback segments/area.
Try to fix the SQL.