9196191 SQL Statement Tunning

8/9/2019 9196191 SQL Statement Tunning

1/19


2/19

Things we will discuss

Why SST ?

Keep performance in mind

Establish a tuning environment

Index wisely

Reduce parsing


3/19

And ..

Avoid accidental table scans

Optimize necessary table scans

Optimize joins Consider PL/SQL for tricky SQL

Take advantage of Cost Based Optimizer


4/19

SST is ..

Anyone involved in tuning should follow a tuningmethodology to achieve maximum performance.

Tuning SQL statements is an important step thatis least expensive when performed at its propermoment in the methodology.

AND..


5/19

Also.

In addition to tuning at the right time, you

should also have a good understanding of theissues involved in performance managementand the types of performance problems thatmight arise.


6/19

Keep performance in mind

Explicitly identify performance targets

Focus on critical transactions

Test the SQL for these transactions against simulations ofproduction data

Measure performance as early as possible

Consider prototyping critical portions of theapplications

Consider de-normalization and other performance bydesign features early on


7/19

Establish a tuning environment

Make sure you establish a reasonable sub-set ofproduction data that is used during developmentand tuning of SQL

Make sure your developers understand EXPLAINPLAN and tkprof, or equip them with commercialtuning tools.


8/19

Tools used for SQL tuning

The foundation tools for SQL tuning are:

The EXPLAIN PLAN command

The SQL Trace facility

The tkprof trace file formatter

Effective SQL tuning requires either familiaritywith these tools or the use of commercial

alternatives such as SQLab


9/19

Index wisely

Index to support selective WHERE clauses andjoin conditions

Use concatenated indexes where appropriate Consider over indexing to avoid table lookups

Consider advanced indexing options Hash Clusters

Bit mapped indexes Index only tables


10/19

Some programmers satisfied if ..

Execution plan shows an index


11/19

But

Make sure the index has all the columns required

4

6

20

40

700

0 100 200 300 400 500 600 700 800

Logical IO

Index on

Surname+firstname+dob+phoneo

Index on

Surname+firstname+DOB

Index on Surname+firstname

Merge 3 indexes

Surname index only


12/19

Reduce parsing

Use bind variables Bind variables are key to application scalability

If necessary in 8.1.6+, set cursor CURSOR_SHA

RINGto FORCE

Reuse cursors in your application code How to do this depends on your development language

Use a cursor cache Setting SESSION_CACHED_CURSORS (to 20 or so)

can help applications that are not re-using cursors


13/19

Take advantage of the Cost Based

Optimizer

The older rule based optimizer is inferior in almostevery respect to the modern cost based optimizer

Using the cost based optimizer effectivelyinvolves: Regular collection of table statistics using theANALYZE or DBMS_STATS command

Understand hints and how they can be used to influence

SQL statement execution Choose the appropriate optimizer mode:

FIRST_ROWS is best for OLTP applications;ALL_ROWS suits reporting and OLAP jobs


14/19

Avoid accidental table scans

Tablescans that occur unintentionally are a majorsource of poorly performing SQL. Causesinclude:

Missing Index Using !=, or NOT

Use inclusive range conditions or IN lists

Looking for values that are NULL

Use NOT NULL values with a default value

Using functions on indexed columns

Use functional indexes in Oracle9i


15/19

Optimize necessary table scans

There are many occasions where a table scan is theonly option. If so:

Consider parallel query option

Try to reduce size of the table

Adjust PCTFREE and PCTUSED Relocate infrequently used long columns or BLOBs

Rebuild when necessary to reduce the high watermark

Improve the caching of the table Use the CACHE hint or table property

Implement KEEP and RECYCLE pools

Partition the table (if you really seek a largesubset of data)

Consider the fast full index scan


16/19

Optimize joins

Pick the best join method Nested loops joins are best for indexed joins of subsets

Hash joins are usually the best choice for big joins

Pick the best join order

Pick the best driving table Eliminate rows as early as possible in the join order

Optimize special joins when appropriate STAR joins for data-warehousing applications

STAR_TRANSFORMATION if you have bitmapindexes

ANTI-JOIN methods for NOT IN sub-queries

SEMI-JOIN methods for EXISTS sub-queries

Properly index CONNECT BY hierarchical queries


17/19

Consider PL/SQL for tricky SQL

With SQL you specify the data you want, not howto get it. Sometime you need to specifically

dictate your retrieval algorithms. For example:

Getting the second highest value

Doing lookups on a low-high lookup table

Correlated updates SQL with multiple complex correlated sub queries

SQL that seems to hard to optimize unless it is brokeninto multiple queries linked in PL/SQL


18/19


19/19

9196191 SQL Statement Tunning

Documents

Transcript of 9196191 SQL Statement Tunning