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"

1. SQLd360
SQL diagnostic made easy
a.k.a.
Tune SQLs 21st century style
Mauro Pagano

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

11. Really? Better than
SQLT?
1/29/17 11

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. Meet the 2016
runaway-approved
SQL Tuning tool
1/29/17 13

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

18. 18
00001_sqld360_dbnamehash_sqlid_index.html

19. 19
Report
Data
Source
DESC of
source table
Query
Copy&Paste

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

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. 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. Old approaches make it hard
• 2007 SQL tuning (aka SQLT)
– Ops, here is the data, figure it out
1/29/17 24

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. 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

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. 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. 1/29/17 31
Significant part of the
workload, peaks up to 30%
Easier this way? J

32. 1/29/17 32
System has 10 CPUs, up to
18 sessions demanding CPU
Easier this way? J

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. 1/29/17 34
Up to 70% on Cluster, plan
might be secondary issue,
investigate app first
Easier this way? J

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

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. 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. 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. 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. 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
• mauro.pagano@gmail.com
– Download
• SQLd360 vYYMM (date)
– Pages
• SQLd360
45