Oracle performance tuning_sfsf

812 views
742 views

Published on

1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total views
812
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
70
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

Oracle performance tuning_sfsf

  1. 1. Oracle Performance TuningEric Geng2/24/2011
  2. 2. Agenda• Oracle Basics• Performance Tuning Methods• SQL Tuning
  3. 3. Oracle Architecture Overview• Database• Instance• Multi-Processes, share memory based C program• Interfaces • SQL, PL/SQL • JDBC, OCI, Pro*C etc• Administration Interfaces • Sqlplus, RMAN • Enterprise Manger
  4. 4. Processes• PMON – Process Monitor• SMON – System Monitor• DBWR – Data Base Writer• LGWR – Log Writer• CKPT – Checkpoint• ARCH – Log Archive
  5. 5. Wait Event• Over 800 wait events, classified to 10+ types.• They are self-diagnostic instruments – lots of counts and timers.• Events • db file scattered read • db file sequential read • enqueue waits • library cache latch/mutex • log file sync • buffer busy waits • free buffer waits • …
  6. 6. Dynamic Views• System statistics • v$sys_time_model, v$sysstat• Session statistics • v$session, v$sesstat• Contention statistics • v$lock, v$latch• SQL staticstics • v$sql, v$sql_plan, v$sql_plan_statistics_all
  7. 7. Statspack/AWR• Capture dynamic statistics into snapshots, then summary database activities between two snapshots.• Statspack(9i) • External scripts and packages • Store snapshots in own-created table • DBMS_STATSPACK • sp*.sql• Automatic Workload Repository(10g) • Built-in feature: scripts, packages, tables, automatic job • Store snapshots in DBA_HIST_* tables • DBMS_WORKLOAD_REPOSITORY • awr*.sql
  8. 8. AWR report
  9. 9. Enterprise Manager• ASH • Sampling in seconds, support real-time Performance view in OEM • Store in SGA, v$active_session_history • Can also generate reports• ADDM • Automatic Database Diagnostic Monitor • Identify issues and give recommendations from snapshots• SQL Tuning Advisor • Create sql profile for sql statement• SQL Access Advisor • Advice on index etc for sql statement
  10. 10. Enterprise Manager
  11. 11. Top SQL• Elapsed time• Parse time• Executions• Buffer gets• Physical reads
  12. 12. Basic terminology• Anoptimizeris the part of the RDBMS responsible for determining the most efficient way for a SQL statement to access data• An execution plan is the complete sequence of operations required to resolve a SQL statement (the combination of access paths and join methods). The in-memory structure of a execution plan also can be called a cursor.• A join method determines how two tables will be joined together (only two tables can be joined together at a time)
  13. 13. Hard parse• Syntax analysis • Analyze "text" of SQL query • Detect syntax errors • Create internal query representation• Semantic Checking • Validate SQL statement • View analysis • Incorporate constraints, triggers, etc.• Query Optimization • Modify query to improve performance (Query Rewrite) • Choose the most efficient "access plan" (Query Optimization)• Plan Generation
  14. 14. Optimizer• Optimizer mode • RULE, CHOOSE, FIRST_ROWS, ALL_ROWS• RULE is not supported• Cost Based Optimizer • Highly depends on statistics• Init parameters can affect the CBO • optimizer_mode • optimizer_index_cost_adj • optimizer_index_cache • data_block_multiple_read_count
  15. 15. Execution Plan• Explain plan for <query> • Select * from table(dbms_xplan.display);• dbms_xplan.display• dbms_xplan.display_cursor• dbms_xplan.display_awr• Query with /*+ gather_plan_statistics */ • more details in v$sql_plan_statistics_all • dbms_xplan.display_cursor(null, null, ‘ALLSTAT LAST’) • useful to find out wrong estimation by optimizer
  16. 16. Execution Plan
  17. 17. Plan of ‘ALLSTATS’
  18. 18. How to read an execution plan• Order • Inner -> outer • At same level, up -> down. Some operations are iterative.• Rows • Estimated by optimizer. Often cause problem.• Time • Estimated by optimizer. Very inaccurate.• A-Rows | A-Time • Actual numbers. Collected by /*+ gather_plan_statistics */
  19. 19. Operations in execution plan• TABLE ACCESS FULL• INDEX RANGE SCAN / TABLE ACCESS BY INDEX ROWID• NESTED LOOPS / HASH JOIN / MERGE JOIN• MERGE JOIN CARTESIAN• INLIST ITERATOR• SORT• AGGREGATE• FILTER
  20. 20. SQL trace/tkprof• Alter session set sql_trace = true (SQL*PLUS)• Alter session set events 10046 trace name context forever, level 12‘ • Level 1 equals sql_trace=true • Level 4 includes bind values • Level 8 includes wait time statistics • Level 12 includes both bind values and wait time stats.• dbms_monitor.session_trace_enable(sid, serial#, waits, binds)• Trace file is in USER_DUMP_DEST folder• tkprof<trace_file><output_file>
  21. 21. SQL trace
  22. 22. TKPROF
  23. 23. Autotrace• Set autotrace on/traceonly (SQL*PLUS)• Besides the plan –
  24. 24. 10053 trace (optimizer trace)• Alter session set events ’10053 trace name context forever, level 1‘
  25. 25. SQL Tuning• Common rules • Filter as early as possible and as much as possible • Join order is more significant than join method• Methods • Statistics • Hints (sql profile / outline) • Rewrite • Index • Schema
  26. 26. Statistics• DBMS_STATS.GATHER_XXX_STATS • analyze table xxx compute/estimate statistics is deprecated • GATHER_STATS_JOB• USER_TABLES • NUM_ROWS, BLOCKS, AVG_ROW_LEN• USER_TAB_COL_STATISTICS • NUM_DISTINCT, NUM_NULLS, NUM_BUCKETS, DENSITY• USER_INDEXES • NUM_ROWS, DISTINCT_KEYS, LEAF_BLOCKS, CLUSTERING_FACTOR, BLEVEL, AVG_LEAF_BLOCKS_PER_KEY• USER_HISTOGRAM • ENDPOINT_NUMBER, ENDPOINT_VALUE
  27. 27. Hint /*+ */• Join order • ORDERED, LEADING• Join method • USE_NL, USE_HASH, USE_MERGE, STAR• Query transformation • USE_CONCAT, NO_EXPAND, UNNEST, PUSH_SUBQ• Index • INDEX, INDEX_JOIN, INDEX_COMBINE• Stats • DYNAMIC_SAMPLING, CADINALITY, SELECTIVITY• Sql Profile is a set of hints fundamentally
  28. 28. SQL rewrite• In / exists• Not in / not exists• Correlated / non-correlated• Join / SubQuery
  29. 29. Challenges for stable plan• Volatile data• Screw data / histograms / bind value peeking• Data correlation
  30. 30. Application Tuning• Avoid unnecessary query • Check logics • Cache• Avoid to fetch too many rows • Pagination• Avoid complex query • Material views • Denormalize• Optimize locking• Optimize indexes
  31. 31. OLTP applications• Use connection pool• Use bind variables (CURSOR_SHARING=FORCE?)• Prefer OPTIMIZER_MODE=FIRST_ROW• Enforce pagination• Caution with any query which join too many tables• Caution with any Full Table Scan or Fast Full Index Scan on large table• Caution with any Sort, Aggregation, Hash Join, Merge Join, especially Merge Join Cartesian on large sets
  32. 32. Links• oracle-l@freelists.org• https://groups.google.com/forum/?pli=1#!forum/com p.databases.oracle.server• http://tahiti.oracle.com/• http://www.oaktable.net/• http://blogs.oracle.com/optimizer/• http://blog.tanelpoder.com/• http://jonathanlewis.wordpress.com/• http://kevinclosson.wordpress.com/• http://structureddata.org/• http://www.eygle.com/
  33. 33. Q&A Q&A

×