tuning sql queries - oracle

8/8/2019 Tuning SQL Queries - Oracle

1/27

1

Different Type of IndexesB-Trees (traditional) indexes

Hash-cluster Bitmap indexesIndex-Organized Tables

Reverse-Key Indexes


2/27

2

Create Index command

C reate index on

();

C reate index cidx on orders (cid);


3/27

3

W hy do we create an index ?(OLTP x Data W arehouse)

A) To speed up query (SELEC

T) ?B) To speed up data entry (insert/update/delete) ?C ) All of the above ?


4/27

4

Indexes (Defaults)Anytime a PK is created, an index isautomatically created.Anytime when the type of index is notspecificied, the type of index created isa B-Trees.


5/27

5

B-Tree (Balanced Tree)Most popular type of index structure for any

programming language or database.

W hen you dont know what to do, the bestoption is usually a B-Tree. They are flexible

and perform well (not very well) in severalscenarios.It is really the B+ tree or B* tree


6/27

6

B-Trees (continued)One node corresponds to one block/page(minimum disk I-O).

Non-Leaf nodes(n keys, n+1 pointers)Leaf-Nodes (contain n entries, where eachentry has an index and a pointer to a data

block). Also, each node has a pointer tonext node.All leaves are at the same height.


7/27

7

Good Indexing (B-Tree)C andidates

Table must be reasonably largeField is queried by frequentlyField has a high cardinality (dont index bysex, where the cardinality is 2!! ).Badly balanced trees may inhibit

performance. Destroying and re-creatingindex may improve performance.


8/27

8

Bitmap IndexBitmap indexes contain the key value and a

bitmap listing the value of 0 or 1 (yes/no)for each row indicating whether the rowcontains that value or not.

May be a good option for indexing fieldsthat have low cardinality (opposite of B-trees).


9/27

9

Bitmap Index (cont.)Syntax: Create Bitmap index .Bitmap index works better with equality tests = or in (not with < or > )Bitmap index maintenance can be expensive; anindividual bit may not be locked; a single updatelocks a large portion of index.Bitmap indexes are best in read-onlydatawarehouse situations


10/27

10

Hash Indexing

B-trees and Bitmap index keys are used tofind rows requiring I/O to process index

Hash gets rows with a key based algorithmRows are stored based on a hashed valueIndex size should be known at indexcreationExample: create index cidx on orders (cid) hashed;


11/27

11

Hash Index work best withVery-high cardinality columnsOnly equal (=) tests are usedIndex values do not changeNumber of rows are known ahead of time


12/27

12

Index-Organized TablesTable data is incorporated into the B-Treeusing the PK as the index.Table data is always in order of PK. Manysorts can be avoided.Especially useful for lookup type tables

Index works best when there are few (andsmall) columns in your table other than thePK.


13/27

13

Reverse Key IndexesKey 12 3 4 becomes 43 2 1, etc.Only efficient for few scenarios envolving

parallel processing and a hughe amount of data.By reversing key values, index blocks might

be more evenly distributed reducing thelikelihood of densely or sparsely populatedindexes.


14/27

14

Conclusions on Indexes

For high-cardinality key values, B-Treeindexes are usually best.B-Trees work with all types of comparisonsand gracefully shrink and grow as tablechanges.

For low cardinality read-only environments,Bitmaps may be a good option.


15/27

15

Query Optimizer A query optimizer parsers your S QL/Queryinto a sequence of relational algebraoperations, determining an execution plan.The query optimizer figures out the bestexecution plan based on rules of thumb and

information provided in the Data Dictionary(System catalog).


16/27

16

Oracle Query Optimizer Up to version 6, Oracle Used a Rule BasedOptimizer. After version 6, Oracle offeredthe C ost Based and the Rule BasedOptimizer. The default is now the C ostBased Optimizer.


17/27

17

Query Optimizer To view how the query plan you must useeither s et autotrace on or explain plan . Setautotrace on is much simpler. Explain planis a little bit more efficient, but morecomplicated.


18/27

18

Typical S QL operations(results of autotrace)

TABLE A CC ESS FULLTABLE A CC ESS BY RO W IDINDEX RAN GE S C ANINDEX UNI QUE S C AN

NESTED LOOPS


19/27

19

TA BLE A CCESS FULL (full table s can):Oracle will look at every row in the table to

find the requested information. This is

usually the slowest way to access a table.


20/27

20

TA BLE A CCESS BY ROWID

Oracle will use the RO W ID methodto find a row in the table.RO W ID is a special column detailingan exact Oracle block wherethe row can be found. This is thefastest way to access a table (faster

than any index. Less flexible than anyindex).


21/27


22/27

22

INDEX UNIQUE SC A N

Oracle will perform this operationwhen the tables primary key or a unique key is part of the where

clause. This is the most efficientway to search an index.


23/27

2 3

NES T ED LOOPS

Indicates that a join operation is occurring.C an perform well or poorly, depending on

performance on the index and tableoperations of the individual tables being joined.


24/27

2 4

Tuning S QL and PL/S QLQueries

Sometimes, Same Query written more than1000 ways.

Generating more than 100 execution plans.Some firms have products that re-write

correctly written S QL queriesautomatically.


25/27

2 5

ROW

IDSELEC T RO W ID,

INTO :EMP_RO W ID, FROM EMPW HERE EMP.EMP_NO = 567 22

FOR UPDATE;UPDATE EMP SET EMP.NAME =

W HERE RO W ID = :EMP_RO W ID;


26/27

2 6

ROW

ID (cont.)FastestLess FlexibleAre very useful for removing duplicates of rows


27/27

2 7

SELEC

T STATEMENTNot exists in place of NOT INJoins in place of ExistsAvoid sub-selectsExists in place of distinct

UNION in place of OR on an index columnW HERE instead of ORDER BY

tuning sql queries - oracle

Documents