Your SlideShare is downloading. ×
Oracle sql high performance tuning
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Oracle sql high performance tuning

19,652

Published on

Overview of SQL tuning

Overview of SQL tuning

Published in: Technology
2 Comments
16 Likes
Statistics
Notes
No Downloads
Views
Total Views
19,652
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
1,163
Comments
2
Likes
16
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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?”
  • Transcript

    • 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
    • 9.
    • 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)
    • 18.
    • 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
    • 26.
    • 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
    • 51.
    • 52. Merge optimization
      • The optimizer usually can’t determine the overlap between Tables
      • 53. Forcing a Nested loops Merge outer join may be significant
    • Other DML optimizations
      Array insert
      Direct path
      NOLOGGING
      Commit frequency
      NOWAIT and BATCH redo logging
    • 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

    ×