SQLd360
0 likes1,597 views
The document discusses the evolution of SQL tuning tools and approaches over the years, focusing on the transition from traditional methods like tracing events to modern diagnostic tools such as sqld360. It emphasizes the limitations of older techniques and highlights the advantages of sqld360, which allows for easier data collection and visualization without installation. Ultimately, sqld360 aims to streamline the SQL tuning process, making it more efficient and user-friendly.
![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](https://image.slidesharecdn.com/sqld360-170129153802/85/SQLd360-16-320.jpg)
SQLd360
- 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. 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. 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. 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. 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. 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. 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. 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. 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
- 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
- 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. 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. 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. 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
- 20. 1/29/17 20
- 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
- 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
- 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. 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. 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
- 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
- 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
- 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. 1/29/17 36 Plan switched from 2210 (good) to 2898 (bad), also plan 711 exists Easier this way? J
- 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
- 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
- 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
- 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. Contact Information • http://mauro-pagano.com – Email • [email protected] – Download • SQLd360 vYYMM (date) – Pages • SQLd360 45