Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Awr + 12c performance tuning

271 views

Published on

AIOUG Vizag Chapter Performance Tuning

Published in: Technology
  • Be the first to comment

Awr + 12c performance tuning

  1. 1. © Copyright 2015. Apps Associates LLC. 1 Oracle AWR/ASH Analysis June 18, 2016
  2. 2. © Copyright 2015. Apps Associates LLC. 2 Satyendra Kumar Pasalapudi Associate Practice Director – IMS, Cloud & Big data Practice @ Apps Associates Co Founder & President of AIOUG @pasalapudi http://orakhoj.blogspot.com
  3. 3. © Copyright 2014. Apps Associates LLC. 3 Agenda • Oracle Time Model, Wait Classes, & Metrics • ASH Architecture • ADDM • AWR Infrastructure • SQL Plan Baseline Architecture • Compare Period ADDM • ASH Analytics
  4. 4. © Copyright 2014. Apps Associates LLC. 4 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
  5. 5. © Copyright 2014. Apps Associates LLC. 5 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)
  6. 6. © Copyright 2014. Apps Associates LLC. 6 Secret Behind the Success of AWR and all other self components from Oracle 10g ( ADDM , Metrics , Alerts) ?
  7. 7. © Copyright 2014. Apps Associates LLC. 7 AiSHwarya Rai
  8. 8. © Copyright 2014. Apps Associates LLC. 8 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
  9. 9. © Copyright 2014. Apps Associates LLC. 9 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
  10. 10. © Copyright 2014. Apps Associates LLC. 10 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)
  11. 11. © Copyright 2014. Apps Associates LLC. 11 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
  12. 12. © Copyright 2014. Apps Associates LLC. 12 Session 1 Ash Samples Session State TIME? ? ? ? ? Sessions change a lot quicker but can get the main picture via sampling by sampling faster
  13. 13. © Copyright 2014. Apps Associates LLC. 13 Session States IO CPU IdleWait
  14. 14. © Copyright 2014. Apps Associates LLC. 14 Session States • Idle • CPU • Waiting • I/O
  15. 15. © Copyright 2014. Apps Associates LLC. 15 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
  16. 16. © Copyright 2014. Apps Associates LLC. 16 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
  17. 17. 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
  18. 18. © Copyright 2014. Apps Associates LLC. 18 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
  19. 19. 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
  20. 20. © Copyright 2014. Apps Associates LLC. 20 AWR TOP5 Timed Events – Wait Class
  21. 21. © Copyright 2014. Apps Associates LLC. 21 Active Sessions in OEM
  22. 22. © Copyright 2014. Apps Associates LLC. 22 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)
  23. 23. © Copyright 2014. Apps Associates LLC. 23 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
  24. 24. 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. © Copyright 2014. Apps Associates LLC. 25 Waits I/O Library Cache Locks Redo Buffer Cache SQL*Net Wait Areas
  26. 26. © Copyright 2014. Apps Associates LLC. 26 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
  27. 27. © Copyright 2014. Apps Associates LLC. 27 OEM TOP Activity
  28. 28. © Copyright 2014. Apps Associates LLC. 28 OEM TOP Activity
  29. 29. © Copyright 2014. Apps Associates LLC. 29 OEM TOP Activity
  30. 30. © Copyright 2014. Apps Associates LLC. 30 Empty. Why? Top 5 Timed Events – CPU time
  31. 31. © Copyright 2014. Apps Associates LLC. 31 • 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
  32. 32. © Copyright 2014. Apps Associates LLC. 32 • 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
  33. 33. © Copyright 2014. Apps Associates LLC. 33 What Is DB Time? DB Time
  34. 34. © Copyright 2014. Apps Associates LLC. 34 DB Time = DB Wait Time + DB CPU Time
  35. 35. © Copyright 2014. Apps Associates LLC. 35 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.
  36. 36. © Copyright 2014. Apps Associates LLC. 36 • (8879/110582)*100=8.03% How does Oracle calculates it?
  37. 37. © Copyright 2014. Apps Associates LLC. 37 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.
  38. 38. © Copyright 2014. Apps Associates LLC. 38 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.
  39. 39. © Copyright 2014. Apps Associates LLC. 39 • 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?
  40. 40. © Copyright 2014. Apps Associates LLC. 40 • 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?
  41. 41. © Copyright 2014. Apps Associates LLC. 41
  42. 42. © Copyright 2014. Apps Associates LLC. 42
  43. 43. © Copyright 2014. Apps Associates LLC. 43
  44. 44. 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
  45. 45. 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
  46. 46. © Copyright 2014. Apps Associates LLC. 46 Real Time ADDM
  47. 47. © Copyright 2014. Apps Associates LLC. 47 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.
  48. 48. © Copyright 2014. Apps Associates LLC. 48 ADDM Compare Periods – Cause to Effect Analysis
  49. 49. © Copyright 2014. Apps Associates LLC. 49 Compare Period ADDM- 12c Snapshot Offset System Moving Window Customize Period
  50. 50. © Copyright 2014. Apps Associates LLC. 50 Compare Period ADDM- 12c
  51. 51. © Copyright 2014. Apps Associates LLC. 51 Top Activity Page – Pre 12c
  52. 52. © Copyright 2014. Apps Associates LLC. 52 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
  53. 53. © Copyright 2014. Apps Associates LLC. 53 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.
  54. 54. © Copyright 2014. Apps Associates LLC. 54 ASH Analytics
  55. 55. © Copyright 2014. Apps Associates LLC. 55 ASH Analytics
  56. 56. @pasalapudi Satyendra.pasalapudi@appsassociates.com Satyendra.kumar@aioug.org

×