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.

SQLd360

SQLd360 is a free tool designed to help collecting and analyzing SQL Tuning-related info from an Oracle database.
Available for free on GitHub, just google "sqld360"

  • Login to see the comments

  • Be the first to like this

SQLd360

  1. 1. SQLd360 SQL diagnostic made easy a.k.a. Tune SQLs 21st century style Mauro Pagano
  2. 2. Trivia! • History quiz about Oracle RDBMS! – Was any feature introduced since 1998(*)? – Did any of them has to do the optimizer? – How much has the optimizer changed since? – How much more complex has the CBO become? • One answer to all questions => YES! A LOT 2(*) Oracle 8i release date
  3. 3. The last 20 years of Optimizer • Shift to cost-based optimization – Instead of heuristic-based – Introduced statistics necessity • Query Transformations – Made optimizer way more sophisticated (complex) • Stability vs flexibility challenge – Conservative way, ensure plans NOT change – Progressive way, plans DO change 3
  4. 4. My SQL runs slow… • How to approach a SQL tuning challenge? • “Classic” 3 steps approach: – Enable tracing events (10053 & 10046) – Execute the SQL again – Review trace files This is 1998 SQL Tuning!!!! 4
  5. 5. Seriously? That’s your approach? • By “classic” I meant old! J • 10053&10046 has many limitations – Need to be put in place BEFORE exec starts • No after-the-fact investigation – Hard to review and digest • Have you ever read a 2M lines long 10053? – Provide limited info about surrounding env • You need to reconnect & gather missing pieces! 1/29/17 5
  6. 6. What can be improved? • A lot more info needed but: – Not trivial to collect – Time sensitive – Some are pieces you just don’t know about • Need a new way to – Collect everything in one shot – Be able to execute it anytime 1/29/17 6
  7. 7. Flash forward to 2007 • Meet SQLTXPLAIN a.k.a. SQLT – Free tool from Oracle – Authored by the one and only Carlos Sierra – Designed by Support, for Support • Can be executed at any time • Collects everything around a SQL statement 1/29/17 7
  8. 8. So SQLT is the perfect tool? • SQLT still has some limitations – Requires installation, two schemas – Presents a lot of RAW info, hard to digest – Main focus is plan generation, not much on exec – Heavily depends on rowsource info This is 2007 SQL Tuning!!!! 1/29/17 8
  9. 9. What’s wrong with 2007? • Oracle RDBMS 11g was released • Some decisions deferred to exec time – Plan started to diverge from the one “on paper” • New features changed SQL Tuning forever – SQL Monitoring (got better in 11.2) – ASH data collected by Execution Plan Line 1/29/17 9
  10. 10. Can we do better than SQLT? • Not on plan generation, SQLT still rocks – But most of the time that’s Support role, not ours • Yes on data presentation, use charts to – Consume large amount of info quickly – Hide the complexity of some information – Allow for trend and pattern recognition 1/29/17 10
  11. 11. Really? Better than SQLT? 1/29/17 11
  12. 12. What else can we do? • Leverage new features from Oracle • SQL Monitor removes dependency on 10046 – Allow to better focus on SQL execution – Also historical from 12c onwards • ASH by Plan Line allows to: – Group info by plan line, not possible with 10046 – Identify bottlenecks with no SQL Mon nor 10046 1/29/17 12
  13. 13. Meet the 2016 runaway-approved SQL Tuning tool 1/29/17 13
  14. 14. Meet SQLd360 • FREE! • No installation • Can be executed any time • Single step execution • Extensive use of visualization • Leverage existing Oracle features 1/29/17 14
  15. 15. SQLd360 use Google Charts • Present large amount of info as charts – Easy to consume and spot trends / patterns • FREE, no license required • Libraries are downloaded from Google – Similar to SQL Monitor or PerfHub • Data is kept local, not sent to Google 15
  16. 16. How to run it • Download SQLd360 (my blog or github) • Refer to readme.txt J • Connect to SQL*Plus as any DBA or user with access to Data Dictionary • Parameters – SQL ID – Oracle Tuning or Diagnostics Pack? [T | D | N] 16
  17. 17. What’s the output? • Single ZIP file – Self-consistent, allows offline analysis – Only Metadata extracted, no application data • Thousands of files – Each small and easy to consume – Index.html drives navigation – Reports with different granularity – Specific “drill-down” pages 1/29/17 17
  18. 18. 18 00001_sqld360_dbnamehash_sqlid_index.html
  19. 19. 19 Report Data Source DESC of source table Query Copy&Paste
  20. 20. 1/29/17 20
  21. 21. Bind peeking, data distrib on histogram • 1998 SQL Tuning (aka traces) – Trace each exec and collect histgram info manually • 2007 SQL tuning (aka SQLT) – Provides every info necessary – Straightforward to spot distribution • But still requires to read a table of up to 2048 rows 1/29/17 21
  22. 22. 1/29/17 22 One chart per histogram created automatically Cardinality, selectivity and endpoint conversion available with mouse-over Easier this way? J
  23. 23. SQL Y breaks SLA since Monday • 1998 SQL Tuning (aka traces) – Sorry, can’t help you • 2007 SQL tuning (aka SQLT) – Plan stability issue, second plan is takes 909 secs PLAN_HASH_VALUE EXECS AVG_BUFFER_GETS AVG_ELAPSED_TIME_SECS 3716292209 43 195354839 909.592 4161077702 3 15562769 71.769 1/29/17 23 “But my SLA is 1000secs!!!!” and PHV 3716… was used before Monday
  24. 24. Old approaches make it hard • 2007 SQL tuning (aka SQLT) – Ops, here is the data, figure it out 1/29/17 24
  25. 25. 1/29/17 25 Average elapsed time/exec over time per PHV Executions started to take longer and longer over time, even original plan degraded. Likely not a plan issue Easier this way? J Plan performance evaluation needs time dimension!
  26. 26. CBO used this plan, it seemed slow ------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | E-Rows |E-Bytes|E-Temp | Cost (%CPU)| E-Time | ------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | | 11754 (100)| | |* 1 | FILTER | | | | | | | |* 2 | HASH JOIN | | 85222 | 8738K| 2792K| 11754 (1)| 00:02:22 | | 3 | TABLE ACCESS BY INDEX ROWID | MTL_SYSTEM_ITEMS_B | 81549 | 1831K| | 9762 (1)| 00:01:58 | |* 4 | INDEX RANGE SCAN | MTL_SYSTEM_ITEMS_B_N10 | 81549 | | | 277 (1)| 00:00:04 | |* 5 | COUNT STOPKEY | | | | | | | | 6 | INDEX FULL SCAN | MTL_PARAMETERS_N1 | 1 | 4 | | 1 (0)| 00:00:01 | |* 7 | TABLE ACCESS FULL | SPRN_INV_ITEM_IN_INT | 55245 | 4423K| | 1608 (2)| 00:00:20 | | 8 | NESTED LOOPS | | 1 | 37 | | 643 (1)| 00:00:08 | | 9 | NESTED LOOPS | | 1 | 37 | | 643 (1)| 00:00:08 | | 10 | NESTED LOOPS | | 1 | 20 | | 642 (1)| 00:00:08 | |* 11 | TABLE ACCESS FULL | QP_LIST_LINES | 1 | 9 | | 641 (1)| 00:00:08 | |* 12 | TABLE ACCESS BY INDEX ROWID| QP_LIST_HEADERS_B | 1 | 11 | | 1 (0)| 00:00:01 | |* 13 | INDEX UNIQUE SCAN | QP_LIST_HEADERS_B_PK | 1 | | | 0 (0)| | |* 14 | INDEX UNIQUE SCAN | QP_LIST_HEADERS_TL_PK | 1 | | | 0 (0)| | |* 15 | TABLE ACCESS BY INDEX ROWID | QP_LIST_HEADERS_TL | 1 | 17 | | 1 (0)| 00:00:01 | | 16 | SORT AGGREGATE | | 1 | 20 | | | | |* 17 | FILTER | | | | | | | |* 18 | TABLE ACCESS FULL | SPRN_INV_ITEM_IN_INT | 3 | 60 | | 1588 (1)| 00:00:20 | |* 19 | TABLE ACCESS FULL | QP_LIST_LINES | 1 | 10 | | 641 (1)| 00:00:08 | ------------------------------------------------------------------------------------------------------------------- 1/29/17 26
  27. 27. Old approaches make it hard • 1998 SQL Tuning (aka traces) – Maybe can’t go back and run the SQL again – Maybe run it again and it runs fine • 2007 SQL tuning (aka SQLT) – Plan looks questionable but don’t have A-Rows – Need to restore SQLT repo and write SQLs 1/29/17 27
  28. 28. Old approaches make it hard • 2007 SQL tuning (aka SQLT) – You have the data, figure it out … SELECT sql_plan_hash_value, count(*), count(distinct sql_exec_id) FROM dba_hist_active_sess_history WHERE sql_id = ‘…’ GROUP BY sql_plan_hash_value … SELECT sql_exec_id, sql_exec_start, count(*) FROM dba_hist_active_sess_history WHERE sql_id = ‘…’ AND sql_plan_hash_value = … GROUP BY sql_exec_id, sql_exec_start … <<another 10 SQL statements>> 1/29/17 28
  29. 29. 1/29/17 29 Exec plan reported as a tree Just read it left to right Nodes are colored depending on time sampled on them. Easy to spot bottlenecks Easier this way? J Tree available also for individual executions, easy to diagnose random slowness
  30. 30. What’s the impact of SQL X on DB A? • 1998 SQL Tuning (aka traces) – Can’t quite do that – Would require to trace every single SQL • 2007 SQL tuning (aka SQLT) – Focused on individual SQL, not much on overall • Nothing wrong but makes it hard to scope impact 1/29/17 30
  31. 31. 1/29/17 31 Significant part of the workload, peaks up to 30% Easier this way? J
  32. 32. 1/29/17 32 System has 10 CPUs, up to 18 sessions demanding CPU Easier this way? J
  33. 33. SQL runs slow, must be plan issue • 1998 SQL Tuning (aka traces) – Need tracing every execution – Might translate in 100s of files to review • 2007 SQL tuning (aka SQLT) – Provides every info about the plan and exec – Main focus on the plan, up to you to figure out 1/29/17 33
  34. 34. 1/29/17 34 Up to 70% on Cluster, plan might be secondary issue, investigate app first Easier this way? J
  35. 35. Performance broke, not sure why • 1998 SQL Tuning (aka traces) – Can trace next exec, no idea of previous one • 2007 SQL tuning (aka SQLT) – Provides info about all plans, some slower – No easy way to spot if plans are cause here – Require you to parse raw AWR / ASH info 1/29/17 35
  36. 36. 1/29/17 36 Plan switched from 2210 (good) to 2898 (bad), also plan 711 exists Easier this way? J
  37. 37. Same plan runs randomly slow • 1998 SQL Tuning (aka traces) – Need to trace every exec until it reproduces • 2007 SQL tuning (aka SQLT) – Nothing specific about executions – Data is available but partially presented raw – Need to restore SQLT repo and query manually 1/29/17 37
  38. 38. 1/29/17 38 Instance 4 session 1474 was the one with slow execution on August 24 Easier this way? J Several reports specific to that execution List of all sampled executions by instance, session, serial with elapsed time and many more info
  39. 39. Need to investigate my PX execs • 1998 SQL Tuning (aka traces) – Every slave generates one trace – Need to manually glue them together • 2007 SQL tuning (aka SQLT) – Nothing specific about PX details • No way to spot downgrades, skewness, etc – Need to restore SQLT repo and query manually 1/29/17 39
  40. 40. 1/29/17 40 Little skewness in distribution PX is never easy, but faster this way? Number of sessions executing the SQL over time by wait event
  41. 41. 1/29/17 41 Number of processes sampled by ASH PX is never easy, but faster this way? Execution DoP PX servers requested PX servers allocated Bottom two executions are serial
  42. 42. Closing Remarks • SQLd360 takes few minutes to run – Can be executed any time even during the issue • SQLd360 speeds up SQL Tuning process – Automating collection and improving presentation • A new Release about once a month • Installs nothing and it is free! 42
  43. 43. 43
  44. 44. References • SQLd360 introduction – http://mauro-pagano.com/2015/02/16/sqld360- sql-diagnostics-collection-made-faster/ • SQLd360 examples and download – http://mauro.pagano.com 44
  45. 45. Contact Information • http://mauro-pagano.com – Email • mauro.pagano@gmail.com – Download • SQLd360 vYYMM (date) – Pages • SQLd360 45

×