SQLd360
0 likes1,530 views
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"
![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)
Ad
More Related Content
What's hot (20)
Viewers also liked (6)
Ad
Similar to SQLd360 (20)
Ad
Recently uploaded (20)
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