This document provides an overview of Oracle performance tuning. It discusses Oracle architecture including processes, wait events, dynamic views, and tools for performance analysis like Statspack, AWR, Enterprise Manager, SQL tracing and tuning. Key aspects of performance tuning covered include statistics, hints, query rewrite, indexing, and application-level tuning for OLTP workloads.

1. Oracle Performance Tuning
Eric Geng
2/24/2011

2. Agenda
• Oracle Basics
• Performance Tuning Methods
• SQL Tuning

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. Processes
• PMON – Process Monitor
• SMON – System Monitor
• DBWR – Data Base Writer
• LGWR – Log Writer
• CKPT – Checkpoint
• ARCH – Log Archive

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. 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. 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. AWR report

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. Enterprise Manager

11. Top SQL
• Elapsed time
• Parse time
• Executions
• Buffer gets
• Physical reads

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. 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. 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. 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. Execution Plan

17. Plan of ‘ALLSTATS’

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. 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. 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. SQL trace

22. TKPROF

23. Autotrace
• Set autotrace on/traceonly (SQL*PLUS)
• Besides the plan –

24. 10053 trace (optimizer trace)
• Alter session set events ’10053 trace name context
forever, level 1‘

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. 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. 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. SQL rewrite
• In / exists
• Not in / not exists
• Correlated / non-correlated
• Join / SubQuery

29. Challenges for stable plan
• Volatile data
• Screw data / histograms / bind value peeking
• Data correlation

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. 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. 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. Q&A
Q&A