Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Analyzing and Interpreting AWR
Similar to Analyzing and Interpreting AWR (20)
More from pasalapudi
More from pasalapudi (8)
Recently uploaded
Recently uploaded (20)
Analyzing and Interpreting AWR
- 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) ?
- 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
- 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
- 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 ?
- 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.