Oracle sql high performance tuning

26,265 views
25,688 views

Published on

Overview of SQL tuning

Published in: Technology
3 Comments
24 Likes
Statistics
Notes
No Downloads
Views
Total views
26,265
On SlideShare
0
From Embeds
0
Number of Embeds
25
Actions
Shares
0
Downloads
1,666
Comments
3
Likes
24
Embeds 0
No embeds

No notes for slide
  • Apologies, I’m a database type.....Quest is best known for toad, but we also have enterprise monitoring across all levels of the stackIn Melbourne, SQL Navigator + the spotlights. It’s not a complete co-incidence about the star trek theme.
  • Garbage In Garbage OutCreate necessary physical structures for optimal plans Indexes, partitions, clusters Collect object statistics Histograms, extended statistiOptimizer configuration parametersMemory_target, db_block_size, etcOptimizer_index_caching, optimizer_index_cost_adjSystem statisticsDBMS_STATS.gather_system_stats
  • Robert Burns
  • Stupid SQL Joke:An SQL statement walks into a bar and sees two tables.It approaches, and asks “may I join you?”
  • Oracle sql high performance tuning

    1. 1. Oracle SQL High Performance Tuning<br />Guy Harrison<br />Director, R&D Melbourne<br />www.guyharrison.net<br />Guy.harrison@quest.com<br />@guyharrison<br />
    2. 2. Introductions<br />
    3. 3. Agenda<br />Philosophy and methodology<br />Optimizing the optimizer<br />Detecting errant SQLs<br />Changing the plan <br />Table lookups<br />Joins<br />Sorts<br />Group BY<br />Other topics <br />
    4. 4. Prison guard analogy<br />Keep the SQLs contained <br />Indexing and clustering <br />Optimizer configuration <br />Detect break outs<br />Monitor and detect errant SQLs<br />Re-capture the fugitives<br />Traditional SQL tuning<br />Outlines, baselines, indexing, denormalization, hints<br />
    5. 5. Optimizing the optimizer<br />
    6. 6. Optimizer inputs<br />Cardinality <br />Estimates<br />Table and index<br />Structure<br />Object Statistics<br />IO and CPU<br />Estimates <br />DB parameters<br />And config<br />Cost estimate<br />System Statistics<br />
    7. 7. Optimizing the optimizer<br />Create necessary physical structures for optimal plans <br />Indexes, partitions, clusters <br />Collect object statistics <br />Histograms, extended statistics <br />Optimizer configuration parameters<br />Memory_target, db_block_size, etc<br />Optimizer_index_caching, optimizer_index_cost_adj<br />System statistics<br />DBMS_STATS.gather_system_stats<br />
    8. 8. Histograms<br />
    9. 9.
    10. 10. 11g Extended Statistics <br />Select * <br /> from people<br /> Where gender=‘boy’<br /> And name=‘Sue’<br />Boys<br />Girls<br />People named Sue<br />People named Sue<br />
    11. 11. Histogram limitations<br />Height balanced histograms don’t have the granularity we might want or expect. <br />
    12. 12. Be realistic about histograms.....<br />Histograms often fail to push cardinalities through multi-table SQLs<br />Default histogram collections are not always optimal<br />
    13. 13. Finding tunable SQL<br />
    14. 14. Detecting break outs <br />V$SQL & V$SQL_PLAN<br />Find SQLs with high resource costs <br />EXPLAIN PLAN & DBMS_STAT<br />Determine the execution plan <br />SQL Trace/Tkprof<br />Best drilldown at the session level <br />
    15. 15. Mining V$SQL<br />
    16. 16. DBMS_XPLAN<br />SQL> SELECT * FROM TABLE (DBMS_XPLAN.display_cursor ('at6ss8tmxm5xz', '0', <br />'TYPICAL -BYTES'));<br /> <br />PLAN_TABLE_OUTPUT<br />-----------------------------------------------------------------------------------------<br />SQL_ID at6ss8tmxm5xz, child number 0<br />-------------------------------------<br />SELECT department_name, last_name, job_title FROM hr.employees JOIN<br />hr.departments USING (department_id) JOIN hr.jobs USING (job_id)<br />ORDER BY department_name, job_title<br /> <br />Plan hash value: 3225241925<br /> <br />--------------------------------------------------------------------------------------<br />| Id | Operation | Name | Rows | Cost (%CPU)| Time |<br />--------------------------------------------------------------------------------------<br />| 0 | SELECT STATEMENT | | | 26 (100)| |<br />| 1 | SORT ORDER BY | | 106 | 26 (8)| 00:00:01 |<br />| 2 | NESTED LOOPS | | 106 | 25 (4)| 00:00:01 |<br />| 3 | MERGE JOIN | | 107 | 24 (5)| 00:00:01 |<br />| 4 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 107 | 20 (0)| 00:00:01 |<br />| 5 | INDEX FULL SCAN | EMP_JOB_IX | 107 | 12 (0)| 00:00:01 |<br />|* 6 | SORT JOIN | | 19 | 4 (25)| 00:00:01 |<br />| 7 | TABLE ACCESS FULL | JOBS | 19 | 3 (0)| 00:00:01 |<br />| 8 | TABLE ACCESS BY INDEX ROWID | DEPARTMENTS | 1 | 1 (0)| 00:00:01 |<br />|* 9 | INDEX UNIQUE SCAN | DEPT_ID_PK | 1 | 0 (0)| |<br />--------------------------------------------------------------------------------------<br /> <br />Predicate Information (identified by operation id):<br />---------------------------------------------------<br /> <br /> 6 - access("EMPLOYEES"."JOB_ID"="JOBS"."JOB_ID")<br /> filter("EMPLOYEES"."JOB_ID"="JOBS"."JOB_ID")<br /> 9 - access("EMPLOYEES"."DEPARTMENT_ID"="DEPARTMENTS"."DEPARTMENT_ID")<br />
    17. 17. SQL Trace & tkprof<br />Trace in current session: DBMS_SESSION<br />In other session: DBMS_MONITOR<br />Session_trace_enable – specific session <br />Serv_mod_act_trace_enable – service, module or action name<br />Analyze with tkprof<br />Or third party tools (Toad, Spotlight, others)<br />
    18. 18.
    19. 19. The best laid plans of Mice and Oracle....<br />
    20. 20. Returning to captivity – changing the plan <br />Options for improving the plan:<br />Indexing<br />Configuration changes (esp. Memory)<br />Stored outlines (stability)<br />SQL Tuning sets and profiles <br />11g SQL Baselines (flexibility)<br />Hints and re-writes (last resort)<br />
    21. 21. Use hints with extreme caution<br />Hints reduce optimizer flexibility and can lead to bad plans<br />Eg: USE_NL can force a nested loops join without an index<br />USE_NL_WITH_INDEX is safer..<br />
    22. 22. Exploit baselines and plan management<br />
    23. 23. SQL Baselines in SQL Optimizer<br />
    24. 24. Indexing and single table lookups<br />
    25. 25. Single table lookup<br />Index or table scan?<br />Avoid accidental table scans <br />Optimize indexes<br />best combination of concatenated indexes<br />Optimize necessary table scans <br />Vertical/Horizontal partitioning<br />Compression<br />Parallel Query<br />
    26. 26.
    27. 27. Concatenated Index Effectiveness<br />SELECT cust_id<br />FROM sh.customers c<br />WHERE cust_first_name = 'Connor'<br />AND cust_last_name = 'Bishop'<br />AND cust_year_of_birth = 1976;<br />
    28. 28. Bitmap indexes<br />
    29. 29. Bitmap indexes <br />
    30. 30. Vertical partitioning<br />
    31. 31. Joins<br />
    32. 32. Optimizing joins<br />Best join order <br />Eliminate rows as early as possible<br />Join Type: <br />Nested loops <br />Optimize the join index<br />Sort merge<br />Avoid, esp. if memory scarce <br />Hash join <br />Avoid multi-pass executions <br />
    33. 33. Nested loops join<br />
    34. 34. Sort-merge and hash join <br />In Memory<br />In Memory<br />Single pass disk sort<br />Multi pass disk sort<br />Disk Sort<br />
    35. 35. Bitmap join index<br />
    36. 36. Bitmap join performance <br />SELECT SUM (amount_sold)<br />FROM customers JOIN sales s USING (cust_id) WHERE cust_email='flint.jeffreys@company2.com';<br />
    37. 37. Sorting<br />
    38. 38. 38<br />Sorting – what we expect<br />Multi-pass<br />Disk Sort<br />Memory Sort <br />Single Pass<br />Disk Sort <br />
    39. 39. 39<br />Flash drive to the rescue?<br />Multi-pass<br />Disk Sort<br />Single Pass<br />Disk Sort <br />
    40. 40. Less memory than you may think....<br />
    41. 41. Memory and sorting<br />Nothing matters as much as PGA to sort operations<br />Automatic work area management restricts you to a subset of PGA<br />For big sorts, “opt out” of automatic work area management<br />ALTER SESSION SET workarea_size_policy = manual;<br />ALTER SESSION SET sort_area_size = 524288000;<br />
    42. 42. Grouping<br />42<br />
    43. 43. Hash Group by<br />11g introduced the Hash GROUP BY<br />Using an ORDER BY can suppress the hash GROUP BY....<br />Can override with USE_HASH_AGGREGATION hint<br />
    44. 44. Analytic (windowing) functions <br />
    45. 45. Pivot vs CASE<br />
    46. 46. DML<br />
    47. 47. DML tuning - indexes<br />
    48. 48. Multi-table insert<br />
    49. 49. Multi-table insert<br />
    50. 50. Merge<br />
    51. 51.
    52. 52. Merge optimization <br /><ul><li>The optimizer usually can’t determine the overlap between Tables
    53. 53. Forcing a Nested loops Merge outer join may be significant</li></li></ul><li>Other DML optimizations<br />Array insert<br />Direct path<br />NOLOGGING<br />Commit frequency<br />NOWAIT and BATCH redo logging<br />
    54. 54. Other topics<br />Database logical design <br />Clustering and exotic physical options<br />PL/SQL <br />Parallel SQL<br />Application optimization (Arrays, bind variables)<br />
    55. 55. Conclusion<br />Maximizing optimizer accuracy provides the best return on investment<br />Sub-optimal optimizations are unfortunately inevitable<br />Key SQL tuning skills are therefore:<br />Configuring Oracle to maximize optimizer effectiveness<br />Detection of sub-optimal SQLs<br />Techniques for coercing SQLs to acceptable performance<br />

    ×