Scribd
Upload
195 views

Oracle SQL High Performance Tuning: Guy Harrison Director, R&D Melbourne

Oracle SQL high Performance tuning - Guy Harrison Director, R&D Melbourne www.guyharrison.net. 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.

Uploaded by

Zakir Chowdhury
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
195 views

Oracle SQL High Performance Tuning: Guy Harrison Director, R&D Melbourne

Oracle SQL high Performance tuning - Guy Harrison Director, R&D Melbourne www.guyharrison.net. 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.

Uploaded by

Zakir Chowdhury
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 56

Oracle SQL High Performance Tuning

Guy Harrison
Director, R&D Melbourne
www.guyharrison.net
Guy.harrison@quest.com
@guyharrison

2011 Quest Software, Inc. ALL RIGHTS RESERVED

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

Optimizing the optimizer

Optimizer inputs
Table and index

Cardinality

Structure

Estimates

DB parameters

IO and CPU

And config

Estimates

Object Statistics

System Statistics

Cost estimate

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

Histograms

20,000
18,000
16,000
14,000
12,000
10,000
8,000
Number of rows
6,000
4,000
2,000
0

11g Extended Statistics


Select *
from people
Where gender=boy

Boys

Girls

And name=Sue

People named Sue


People named Sue

10

Histogram limitations
Height balanced histograms dont 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

13

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

14

Mining V$SQL

15

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

hr.departments USING (department_id)

FROM hr.employees JOIN


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

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 |

107 |

20

(0)| 00:00:01 |

5 |

| EMP_JOB_IX

107 |

12

(0)| 00:00:01 |

|*

6 |

19 |

(25)| 00:00:01 |

7 |

| JOBS

19 |

(0)| 00:00:01 |

8 |

TABLE ACCESS BY INDEX ROWID | DEPARTMENTS |

1 |

(0)| 00:00:01 |

|*

9 |

1 |

(0)|

TABLE ACCESS BY INDEX ROWID| EMPLOYEES


INDEX FULL SCAN
SORT JOIN
TABLE ACCESS FULL

INDEX UNIQUE SCAN

| DEPT_ID_PK

26 (100)|

16

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)

17

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

19

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)

20

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

22

SQL Baselines in SQL Optimizer

23

Indexing and single table lookups

24

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

25

1000
Full Scan no caching
Index sorted data, no caching
Index unsorted, cached data
Full Table scan, cached data

100

Elaspe d Tim e (s )

Break even points for index vs table scan

10

1
0

10

20

30

40

50

60

Pct of table acces se d

70

80

90

100

Concatenated Index Effectiveness

last,first,birthyear,id

3
SELECT cust_id
FROM sh.customers c
WHERE cust_first_name = 'Connor'

last,first,BirthYear

last+first name

last name

AND cust_last_name = 'Bishop'


AND cust_year_of_birth = 1976;

63

None

1459

200

400

600

800
Logical IO

1000

1200

1400

1600

Bitmap indexes

28

Bitmap indexes
100

10

Elapsed Time (s)

0.1

0.01
1

10

100

1000

10000

100000

1000000

Distinct values in table


Bitmap index

B*-Tree index

Full table scan

29

Vertical partitioning

30

Joins

31

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

32

Nested loops join


prod_id,channel_id,cust_id,time_id,promo_id

2.2

time_id

Indexing

3.14

prod_id,channel_id

23.43

prod_id

48.36

No Index

546.55

100

200
Elapsed time (s)

300

400

500

600

Sort-merge and hash join


250

200

Disk Sort

150

Elapsed Time (s)


100
In Memory
Multi pass disk sort

Single pass disk sort

50
In Memory

0
1

10

100
Workarea Memory (MB)

Hash Join

Sort Merge Join

1000

Bitmap join index

Bitmap join performance


Full table scan

13,480

Bitmap index

Access Path

1,524

Bitmap Join index 68

2000

4000

6000

8000

10000

12000

14000

Logical IO

SELECT SUM (amount_sold)


FROM customers JOIN sales s USING (cust_id) WHERE
cust_email='flint.jeffreys@company2.com';

36

Sorting

37

Sorting what we expect

Multi-pass
Disk Sort
Time

Single Pass
Disk Sort

Memory Sort

PGA Memory available (MB)

Table/Index IO

CPU Time

Temp Segment IO

38

Flash drive to the rescue?


4000

3500

3000

Multi-pass
2500

Disk Sort
2000

Elapsed time (s)

1500

1000

Single Pass
Disk Sort

500

0
300

250

200

150

100

50

Sort Area Size


SAS based TTS

SSD based TTS

39

Less memory than you may think....


450

400

350

300

250
Size Limit (MB)
200

150

100

50

0
0

200

400

600

800

1000

1200

PGA_AGGREGATE_TARGET (MB)
Max process PGA

Max workarea PGA

1400

1600

1800

2000

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;

41

Grouping

42

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

GROUP BY HASH (11g)

GROUP BY SORT (10g)

1000

2000

3000

4000

5000

6000

7000

8000

9000

Analytic (windowing) functions

Self Join

Table IO
temp IO
CPU

Partition by

5000

10000

15000

20000

25000

Elapsed time (ms)


44

Pivot vs CASE

CASE

IO Time
CPU Time

PIVOT

2000

4000

6000

8000

10000

12000

14000

16000

45

18000

DML

46

DML tuning - indexes


7

16,316

14,285

Number of indexes

12,727

10,719

8,691

6,671

1 (PK only)

1,191

2,000

4,000

6,000

8,000

10,000

Logical reads required

12,000

14,000

16,000
47

18,000

Multi-table insert

Multi-table insert

Multi-table insert

Insert both
Insert EMEA
Insert US

Two Inserts

Elapsed time (s)

10
49

Merge

MERGE

Merge
Insert
Update

INSERT + UPDATE

3.89

3.71

6
Elapsed Time (s)

3.32

10

12

Merge optimization

The optimizer usually cant determine


the overlap between Tables

Forcing a Nested loops Merge outer


Hash (full scan)

join may be significant

7.96

Merge join method

Nested loops (indexed)

4.23

Elapsed time (s)

Other DML optimizations

Array insert
Direct path
NOLOGGING
Commit frequency
NOWAIT and BATCH redo logging

53

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

54

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

55

Thank You

Danke Schn

Gracias

Merci

Obrigado

2011 Quest Software, Inc. ALL RIGHTS RESERVED

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy