AWR & ASH Analysis

© Copyright 2015. Apps Associates LLC. 1
Oracle AWR/ASH Analysis
May 30, 2015

Satyendra Kumar Pasalapudi
Associate Practice Director – IMS, Cloud & Big data Practice
@ Apps Associates
Co Founder & President of AIOUG
@pasalapudi
http://orakhoj.blogspot.com

Agenda
• Oracle Time Model, Wait Classes, & Metrics
• ASH Architecture
• ADDM
• AWR Infrastructure
• SQL Plan Baseline Architecture
• Compare Period ADDM
• ASH Analytics
• Demo

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

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)

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

AiSHwarya Rai

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

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

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)

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

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

Session States
IO CPU IdleWait

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

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

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

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

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

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

AWR TOP5 Timed Events – Wait Class

Active Sessions in OEM

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)

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

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

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

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

OEM TOP Activity

Empty. Why?
Top 5 Timed Events – CPU time

• Because “CPU time” is not wait event. It is the time spent on CPU to do the
actual work.

• 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”

What Is DB Time?
DB Time

DB Time =
DB Wait Time +
DB CPU Time

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.

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

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.

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.

• 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?

• 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?

Real Time ADDM - Challenges
 Sick Systems
 Database is very slow
 All user queries are very slow
 Performance Screens show slow data refresh rates
 There is significant reduction in throughput
 Database is hung due to internal contention for resources
 Database is totally unresponsive; no logon is allowed.
 User queries are hanging
 Performance screens do not refresh
 DBA is unable to logon to the instance because it is hung state
DBA did not find the blocking session to kill, Emergency Monitoring did not
provide the root cause

Real Time ADDM - Goals
 With 12c One can Switch to Real-Time ADDM before bouncing the instance
 starts collecting performance data from all database instances
 Analyzed recent data for systems paralyzed becuase of severe contention on
local or global resources
 Provides holistic analysis for systems experiencing unusally high database activity
 Detects findings for the recent activity(past 10 minutes)
 Offers actionable recommendations
 Use the recommendation to solve
 Return back to regular performance monitoring
Note: Can be invoked for RAC environment

Real Time ADDM

AWR Compare Periods Report
• Till now we have been comparing with two different snapshots either available
or preserved
• Comparison between DB replay capture and replay or two replays
• Pre 12c these reports are missing the intelligence and cannot map the root
cause with performance degradation.

ADDM Compare Periods – Cause to Effect
Analysis

Compare Period ADDM- 12c
Snapshot Offset
System Moving Window
Customize Period

Compare Period ADDM- 12c

Top Activity Page – Pre 12c

Top Activity Page Limitations
 Limitations with Top Activity till 11g
 One cannot switch dimensions on the area chart shown on the top part of the screen.
 The left hand table that is fixed to displaying TOP SQL, while the right hand table has only a few
dimensions that it can be displayed such top sessions or top modules
 The information does not harness the full value of ASH data as some key dimensions that are
actually captured with ASH data are not displayed at all
 The slider used to select the time period for the detailed section is fixed width with 5 minutes real
time and 30 minutes historical
 The data cannot be displayed as an active report. The visualization is restricted to a stacked area
chart by wait classes

ASH Analytics 12c
• Filter dimensions on the filters shown in the middle left part of the page
• One can select the dimensions for the left and right hand tables in the bottom
left and right parts of the page
• Vary the slider width to select the time period for the detailed section
• One can Drill into a load map view to display the different waits indicating the
importance of each by the size of the box.

ASH Analytics

@pasalapudi
Satyendra.pasalapudi@appsassociates.com
Satyendra.kumar@aioug.org

AWR & ASH Analysis

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to AWR & ASH Analysis

Similar to AWR & ASH Analysis (20)

More from aioughydchapter

More from aioughydchapter (16)

Recently uploaded

Recently uploaded (20)

AWR & ASH Analysis