Oracle sql high performance tuning

Oracle SQL High Performance Tuning
Guy Harrison
Director, R&D Melbourne
www.guyharrison.net
Guy.harrison@quest.com
@guyharrison

Introductions

Agenda
Philosophy and methodology
Optimizing the optimizer
Detecting errant SQLs
Changing the plan
Table lookups
Joins
Sorts
Group BY
Other topics

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

Optimizer inputs
Cardinality
Estimates
Table and index
Structure
Object Statistics
IO and CPU
Estimates
DB parameters
And config
Cost estimate
System Statistics

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

Histograms

11g Extended Statistics
Select *
from people
Where gender=‘boy’
And name=‘Sue’
Boys
Girls
People named Sue
People named Sue

Histogram limitations
Height balanced histograms don’t have the granularity we might want or expect.

Be realistic about histograms.....
Histograms often fail to push cardinalities through multi-table SQLs
Default histogram collections are not always optimal

Finding tunable SQL

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

Mining V$SQL

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")

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)

The best laid plans of Mice and Oracle....

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)

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

Exploit baselines and plan management

SQL Baselines in SQL Optimizer

Indexing and single table lookups

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

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;

Bitmap indexes

Vertical partitioning

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

Nested loops join

Sort-merge and hash join
In Memory
In Memory
Single pass disk sort
Multi pass disk sort
Disk Sort

Bitmap join index

Bitmap join performance
SELECT SUM (amount_sold)
FROM customers JOIN sales s USING (cust_id) WHERE cust_email='flint.jeffreys@company2.com';

Sorting

38
Sorting – what we expect
Multi-pass
Disk Sort
Memory Sort
Single Pass
Disk Sort

39
Flash drive to the rescue?
Multi-pass
Disk Sort
Single Pass
Disk Sort

Less memory than you may think....

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;

Grouping
42

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

Analytic (windowing) functions

Pivot vs CASE

DML tuning - indexes

Multi-table insert

Merge optimization
The optimizer usually can’t determine the overlap between Tables
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

Other topics
Database logical design
Clustering and exotic physical options
PL/SQL
Parallel SQL
Application optimization (Arrays, bind variables)

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

Oracle sql high performance tuning

by Guy Harrison on Jul 19, 2011

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

Oracle sql high performance tuning Presentation Transcript