Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Oracle sql high performance tuning

28,985 views

Published on

Overview of SQL tuning

Published in: Technology

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

×