Overview of SQL tuning

1. Oracle SQL High Performance Tuning Guy Harrison Director, R&D Melbourne www.guyharrison.net Guy.harrison@quest.com @guyharrison

2. Introductions

3. Agenda Philosophy and methodology Optimizing the optimizer Detecting errant SQLs Changing the plan Table lookups Joins Sorts Group BY Other topics

4. Prison guard analogy Keep the SQLs contained Indexing and clustering Optimizer configuration Detect break outs Monitor and detect errant SQLs Re-capture the fugitives Traditional SQL tuning Outlines, baselines, indexing, denormalization, hints

5. Optimizing the optimizer

6. Optimizer inputs Cardinality Estimates Table and index Structure Object Statistics IO and CPU Estimates DB parameters And config Cost estimate System Statistics

7. Optimizing the optimizer Create necessary physical structures for optimal plans Indexes, partitions, clusters Collect object statistics Histograms, extended statistics Optimizer configuration parameters Memory_target, db_block_size, etc Optimizer_index_caching, optimizer_index_cost_adj System statistics DBMS_STATS.gather_system_stats

8. Histograms

10. 11g Extended Statistics Select * from people Where gender=‘boy’ And name=‘Sue’ Boys Girls People named Sue People named Sue

11. Histogram limitations Height balanced histograms don’t have the granularity we might want or expect.

12. Be realistic about histograms..... Histograms often fail to push cardinalities through multi-table SQLs Default histogram collections are not always optimal

13. Finding tunable SQL

14. Detecting break outs V$SQL & V$SQL_PLAN Find SQLs with high resource costs EXPLAIN PLAN & DBMS_STAT Determine the execution plan SQL Trace/Tkprof Best drilldown at the session level

15. Mining V$SQL

16. DBMS_XPLAN SQL> SELECT * FROM TABLE (DBMS_XPLAN.display_cursor ('at6ss8tmxm5xz', '0', 'TYPICAL -BYTES')); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------- SQL_ID at6ss8tmxm5xz, child number 0 ------------------------------------- SELECT department_name, last_name, job_title FROM hr.employees JOIN hr.departments USING (department_id) JOIN hr.jobs USING (job_id) ORDER BY department_name, job_title Plan hash value: 3225241925 -------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Cost (%CPU)| Time | -------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | 26 (100)| | | 1 | SORT ORDER BY | | 106 | 26 (8)| 00:00:01 | | 2 | NESTED LOOPS | | 106 | 25 (4)| 00:00:01 | | 3 | MERGE JOIN | | 107 | 24 (5)| 00:00:01 | | 4 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 107 | 20 (0)| 00:00:01 | | 5 | INDEX FULL SCAN | EMP_JOB_IX | 107 | 12 (0)| 00:00:01 | |* 6 | SORT JOIN | | 19 | 4 (25)| 00:00:01 | | 7 | TABLE ACCESS FULL | JOBS | 19 | 3 (0)| 00:00:01 | | 8 | TABLE ACCESS BY INDEX ROWID | DEPARTMENTS | 1 | 1 (0)| 00:00:01 | |* 9 | INDEX UNIQUE SCAN | DEPT_ID_PK | 1 | 0 (0)| | -------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 6 - access("EMPLOYEES"."JOB_ID"="JOBS"."JOB_ID") filter("EMPLOYEES"."JOB_ID"="JOBS"."JOB_ID") 9 - access("EMPLOYEES"."DEPARTMENT_ID"="DEPARTMENTS"."DEPARTMENT_ID")

17. SQL Trace & tkprof Trace in current session: DBMS_SESSION In other session: DBMS_MONITOR Session_trace_enable – specific session Serv_mod_act_trace_enable – service, module or action name Analyze with tkprof Or third party tools (Toad, Spotlight, others)

19. The best laid plans of Mice and Oracle....

20. Returning to captivity – changing the plan Options for improving the plan: Indexing Configuration changes (esp. Memory) Stored outlines (stability) SQL Tuning sets and profiles 11g SQL Baselines (flexibility) Hints and re-writes (last resort)

21. Use hints with extreme caution Hints reduce optimizer flexibility and can lead to bad plans Eg: USE_NL can force a nested loops join without an index USE_NL_WITH_INDEX is safer..

22. Exploit baselines and plan management

23. SQL Baselines in SQL Optimizer

24. Indexing and single table lookups

25. Single table lookup Index or table scan? Avoid accidental table scans Optimize indexes best combination of concatenated indexes Optimize necessary table scans Vertical/Horizontal partitioning Compression Parallel Query

27. Concatenated Index Effectiveness SELECT cust_id FROM sh.customers c WHERE cust_first_name = 'Connor' AND cust_last_name = 'Bishop' AND cust_year_of_birth = 1976;

28. Bitmap indexes

29. Bitmap indexes

30. Vertical partitioning

31. Joins

32. Optimizing joins Best join order Eliminate rows as early as possible Join Type: Nested loops Optimize the join index Sort merge Avoid, esp. if memory scarce Hash join Avoid multi-pass executions

33. Nested loops join

34. Sort-merge and hash join In Memory In Memory Single pass disk sort Multi pass disk sort Disk Sort

35. Bitmap join index

36. Bitmap join performance SELECT SUM (amount_sold) FROM customers JOIN sales s USING (cust_id) WHERE cust_email='flint.jeffreys@company2.com';

37. Sorting

38. 38 Sorting – what we expect Multi-pass Disk Sort Memory Sort Single Pass Disk Sort

39. 39 Flash drive to the rescue? Multi-pass Disk Sort Single Pass Disk Sort

40. Less memory than you may think....

41. Memory and sorting Nothing matters as much as PGA to sort operations Automatic work area management restricts you to a subset of PGA For big sorts, “opt out” of automatic work area management ALTER SESSION SET workarea_size_policy = manual; ALTER SESSION SET sort_area_size = 524288000;

42. Grouping 42

43. Hash Group by 11g introduced the Hash GROUP BY Using an ORDER BY can suppress the hash GROUP BY.... Can override with USE_HASH_AGGREGATION hint

44. Analytic (windowing) functions

45. Pivot vs CASE

46. DML

47. DML tuning - indexes

48. Multi-table insert

49. Multi-table insert

50. Merge

54. Other topics Database logical design Clustering and exotic physical options PL/SQL Parallel SQL Application optimization (Arrays, bind variables)

55. Conclusion Maximizing optimizer accuracy provides the best return on investment Sub-optimal optimizations are unfortunately inevitable Key SQL tuning skills are therefore: Configuring Oracle to maximize optimizer effectiveness Detection of sub-optimal SQLs Techniques for coercing SQLs to acceptable performance