awr + 12c performance tuning

© Copyright 2015. Apps Associates LLC. 1

Oracle AWR/ASH Analysis

June 18, 2016


Satyendra Kumar Pasalapudi

Associate Practice Director – IMS, Cloud & Big data Practice @ Apps Associates

Co Founder & President of AIOUG

@pasalapudi

http://orakhoj.blogspot.com

http://www.aioug.org/index.php


Agenda

• Oracle Time Model, Wait Classes, & Metrics

• ASH Architecture

• ADDM

• AWR Infrastructure

• SQL Plan Baseline Architecture

• Compare Period ADDM

• ASH Analytics


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 time Indexed 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 Idle Wait


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

snapshots MMON


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 Read Cache 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

[email protected] [email protected]

mailto:[email protected]

awr + 12c performance tuning

Technology