2713894 oracle tuning tips

7/30/2019 2713894 Oracle Tuning Tips

1/41

1

SQL Performance Tuning Tips

By Puneet Goenka


2/41

2

Tuning Tips and Techniques

Oracles SQL is a very flexible language.

You can use many different SQL statements

to accomplish the same purpose. Yet, although dozens of differently

constructed queries and retrieval statements

can produce the same result, in a given

situation only one statement will be the most

efficient choice.


3/41

3

It is much harder to write efficient SQL than it is towrite functionally correct SQL

A SQL choice is correct only if it produces the right

result in the shortest possible amount of time,without impeding the performance of any other

system resources.


4/41

4

Sharing SQL Statements

Parsing a SQL statement and figuring out itsoptimal execution plan are time-consumingoperations, Oracle holds SQL statements in

memory after it has parsed them Whenever you issue a SQL statement,

Oracle first looks in the context (SGA) area tosee if there is an identical statement there

To be shared, the SQL statements must trulybe the same


5/41

5

For example the following two select statements are NOT the same:

SELECT STUDENT_NMBER,NAMEFROM STUDENTWHERE STUDEN_NUMBER = 0220

Select Student_Number,NameFrom StudentWhere Student_Number = 0220


6/41

6

Using Bind variables when possible Try using Bind Variable instead of Literals. Consider the following

SQL statementSELECT FIRST_NAME, LAST_NAMEFROM ClientWHERE CLIENT_NUM = 1200

Since the CLIENT_NUMBER is likely to be different for everyexecution, we will almost never find a matching statement in theShared Pool and consequently the statement will have to be reparsed

every time Consider the following approach

SELECT FIRST_NAME, LAST_NAME

FROM Client

WHERE CLIENT_NUM = :Client_Num

You do not need to create a new cursor or re-parse the SQL statement if thevalue of the bind variable changes. Also, if another session executes the samestatement, it is likely to find them in the Shared Pool, since the name of thebind variable does not change from execution to execution.


7/41

7

Using ROWID When Possible

Each record added to the database has a unique ROWID and will

never change until the delete statement issued on that record. If the record block or location was changed for any reason, the

original ROWID points to the new location or the new ROWID and so

on. Use ROWID whenever possible to get the best performance out of

your retrievals


8/41

8

cursor accounts_cur isselect acct_no,

currency,branchRowid acct_rowid,

From account

where . . . .

for acct_rec in accounts_cur loop

update account set

where rowid = acct_rec.acct_rowid;

end loop;


9/41

9

Using WHERE in Place of HAVING

In general, avoid including a HAVING clause in the SELECT

statements. The HAVING clause filters selected rows only after allrows have been fetched. This could include sorting, summing, andetc. HAVING clause

usually used to filter a SELECT statement containing groupfunctions.

select *from accountwhere cust_Active_flag = yhaving group = 001

Instead use -

select *from accountwhere cust_Active_flag = yand group = 001


10/41

10

Using UNION ALL instead of UNION

The SORT operation is very expensive in terms of

CPU consumption.

The UNION operation sorts the result set to eliminate

any rows, which are within the sub-queries.

UNION ALL includes duplicate rows and does not

require a sort. Unless you require that these duplicate

rows be eliminated, use UNION ALL


11/41

11

Using NOT EXISTS in place of NOT IN for indexed

columns In sub-query statements such as the following, the NOT IN

clause causes an internal sort/merge.

select * from Studentwhere STUDENT_NUM not in

(select STUDENT_NUM from CLASS) So use-

select * from STUDENT Cwhere not exists(select 1 from CLASS A where

A.STUDENT_NUM = C.STUDENT_NUM)


12/41

12

Using IN with MINUS in place of NOT IN for non

indexed columns

In sub-query statements such as the following, the NOT IN clause

causes an internal sort/merge

select * from system_userwhere su_user_id not in(select ac_user from account)

INSTEAD USE

select * from system_userwhere su_user_id in(select su_user_id from system_user

minus

select ac_user from account)


13/41

13

Using Joints in Place of EXISTS for Unique Scan Indexes and

small tables

In general join tables rather than specifying sub-queries for them suchas the following:

select acct_ID, currency, branchfrom accountwhere exists (select 1 from branch where code =branch and def_curr = '001')

With join -

select acct_ID,currency, branchfrom account A, branch Bwhere b.code = A.branchand A.def_curr = '001'


14/41

14

Influencing the Optimizer using HINTS

Hints are special instructions to Optimizer. You can change theOptimization goal for an individual statement by using Hint. Somecommonly used Hints are: CHOOSE, RULE, FULL(table_name),

INDEX(table_name index_name), USE_NL,USE_HASH(table_name), PARALLEL(table_name parallelism) etc.

SELECT /*+RULE*/ NAME,

ACCT_ALLOCATION_PERCENTAGEFROM ACCOUNTS WHERE ACCOUNT_ID = 1200

The above SQL statement will be processed using the RULE basedoptimizer.

SELECT /*+ INDEX(A, ACCT_ID_IND) */ NAME,

ACCT_ALLOCATION_PERCENTAGEFROM ACCOUNTS AWHERE ACCOUNT_ID = :ACCT_ID ANDCLIENT_ID= :CLIENT_ID

In the above SQL statement, an Index Hint has been used to forcethe use of a particular index.


15/41

15

Using Indexes to Improve Performance Indexes primarily exist to enhance performance. But they do

not come without a cost. Indexes must be updated duringINSERT, UPDATE and DELETE operation, which may slowdown performance

Besides, the usefulness of an Index depends on selectivity of a

column/columns. Generally Indexes are more selective if the column/columns

have a large number of unique values.

If an Index contains more than one column, it is calledCONCATENATED INDEX .

Concatenated index is often more selective than a single keyindex.

Column positions play an important role in Concatenatedindex. While using Concatenated Index, be sure to useLEADING columns


16/41

16

Which is Faster: Indexed Retrieval or Full-table

Scan? Full-table scans can be efficient because they require little disk

movement. The disk starts reading at one point and continues reading

contiguous data blocks.

Index retrievals are usually more efficient when retrieving few recordsor when using joints with other tables.

If more than 52%, this percentage defers from table to table anddepends on the physical I/O, of the table retrieved a full table scan isbetter.


17/41

17

Avoiding Calculations on Indexed Columns The optimizer does not use an index if the indexed column is a part of

a function (in the WHERE clause). In general, avoid doing

calculations on indexed columns, apply function and concatenating on

an indexed columns.

Select * from

AccountWhere substr(ac_acct_no,1,1) = 1

Instead use -

Select * fromAccountWhere ac_acct_no like 1%

Note: The SQL functions MIN and MAX are exceptions tothis rule and will utilize all available indexes.


18/41

18

Avoiding NOT on Indexed Columns

In general avoid using NOT when testing indexed columns.

When Oracle encounters a NOT, it will choose not to use index andwill perform a full-table scan instead.

Remember, indexes are built on what is in a table, but not what isNOT in a table.

For example the following select statement will never use the index onSTUDENT_NUM column

Select * from

studentWhere STUDENT_NUM not like 9%


19/41

19

Using UNION in Place of OR

In general, always consider the UNION verb instead of OR verb in the

WHERE clauses.

Using OR on an indexed column causes the optimizer to perform a

full-table scan rather than an indexed retrieval.


20/41

20

Position of Joins in the WHERE Clause

Table joins should be written first before any condition of WHERE clause.

And the conditions which filter out the maximum records should be placed at

the end after the joins as the parsing is done from BOTTOM to TOP.

Least Efficient :

SELECT . . . .

FROM EMP E

WHERE SAL > 50000

AND JOB = CLERKAND 25 < (SELECT COUNT(*)

FROM EMP WHERE MGR = E.EMPNO);


21/41

21

Most Efficient :

SELECT . . . .

FROM EMP E

WHERE 25 < (SELECT COUNT(*)FROM EMP

WHERE MGR = E.EMPNO )

AND SAL > 50000 AND JOB =

CLERK;


22/41

22

Nested Loops Join Sort-Merge Join Hash Join ClusterJoin

When can be used: Any join Equi joins only Equi joins only Equijoins on

complete

cluster key of

clustered

tables only

Optimizer hint: use_nl Use_merge use_hash None

Resource concerns: CPU Temporary segments Memory Storage Disk I/O

init.ora parameters:None sort_area_size hash_join_enabledNone db_file_multi block_

hash_area_sizeread_count hash_multiblock_io_count

Features:Works with any join Better than nested Better than nested ReducesI/O for master-

loop when indesx is loop when index is

detail Queries

missing or search missing or search

critiria is not restrictive criteria is not restrictive

Side by Side Comparison of Join Methods


23/41

23

ORACLE parser always processes table names from right to left, sothe table name you specify last (driving table) is actually the firsttable processed.

If you specify more than one table in a FROM clause of a SELECT

statement, you must choose the table containing the lowest number ofrows as the driving table.

When ORACLE processes multiple tables, it uses an internalsort/merge procedure to join those tables.

First, it scans and sorts the first table (the one specified last in theFROM clause).

Next, it scans the second table (the one prior to the last in the FROMclause) and merges all of the rows retrieved from the second tablewith those retrieved from the first table.

For example:

Table TABA has 16,384 rows.

Table TABB has 1 row.

SELECT COUNT(*) FROM TABA, TABB 0.96 seconds elapsedSELECT COUNT(*) FROM TABB, TABA 26.09 seconds elapsed


24/41

24

If three tables are being joined, select the intersection table as the drivingtable.

The intersection table is the table that has many tables dependent on it.

E.g.. The EMP table represents the intersection between the LOCATION

table and the CATEGORY table.SELECT . . .

FROM LOCATION L, CATEGORY C, EMP E

WHERE E.EMP_NO BETWEEN 1000 AND 2000

AND E.CAT_NO = C.CAT_NO

AND E.LOCN = L.LOCNis more efficient than this next example:

SELECT . . .

FROM EMP E,

LOCATION L, CATEGORY C

WHERE E.CAT_NO = C.CAT_NO

AND E.LOCN = L.LOCN

AND E.EMP_NO BETWEEN 1000 AND 2000


25/41

25

Problems when Converting Index Column Types

Oracle performs simple column type conversion, or casting,

when it compares columns of different type. If a numeric

column is compared to an alphabetic column, the charactercolumn automatically has its type converted to numeric.

Select *from AccountWhere ACCOUNT_ID = 90426001

In fact, because of conversion this statement will actually be processedas:

Select *

from AccountWhere to_number(ACCOUNT_ID) = 90426001


26/41

26

But the following statement:

Select *

From acc_txnWhere acc_txn_ref_no = 119990012890

Will be processed as:

Select *From acc_txn

Where acc_txn_ref_no = to_number(119990012890 )


27/41

27

Use DECODE to Reduce Processing

The DECODE statement provides a way to avoid having toscan the same rows repetitively or to join the same tablerepetitively.

For example:

SELECT COUNT(*), SUM(SAL)

FROM EMP

WHERE DEPT_NO = 0020

AND ENAME LIKE SMITH%;

SELECT COUNT(*), SUM(SAL)

FROM EMP

WHERE DEPT_NO = 0030

AND ENAME LIKE SMITH%;

You can achieve the same result much more efficiently withDECODE:


28/41

28

SELECT COUNT(DECODE(DEPT_NO,0020, X, NULL))

D0020_COUNT,

COUNT(DECODE(DEPT_NO,0030,X,NULL))D0030_COUNT,

SUM(DECODE(DEPT_NO,0020, SAL, NULL))

D0020_SAL,

SUM(DECODE(DEPT_NO, 0030, SAL, NULL))

D0030_SALFROM EMP

WHERE ENAME LIKE SMITH%;

Similarly, DECODE can be used in GROUP BY or ORDER

BY clause effectively.


29/41

29

To improve performance, minimize the number of tablelookups in queries, particularly if your statements includesub-query SELECTs or multi-column UPDATEs.

For example:

Least Efficient :

SELECT TAB_NAME

FROM TABLES

WHERE

TAB_NAME =(SELECT TAB_NAME

FROM TAB_COLUMNS

WHERE VERSION = 604)

AND

DB_VER = (SELECT DB_VER

FROM TAB_COLUMNS



30/41

30

Most Efficient :

SELECT TAB_NAME

FROM TABLES

WHERE (TAB_NAME,DB_VER)=

(SELECT TAB_NAME, DB_VER

FROM TAB_COLUMNS


U EXISTS i Pl f DISTINCT


31/41

31

Use EXISTS in Place of DISTINCT

Avoid joins that require the DISTINCT qualifier on theSELECT list when you submit queries used to determineinformation at the owner end of a one-to-many relationship

(e.g. departments that have many employees).

Least Efficient :

SELECT DISTINCT DEPT_NO, DEPT_NAME

FROM DEPT D, EMP E

WHERE D.DEPT_NO = E.DEPT_NO

Most Efficient :

SELECT DEPT_NO, DEPT_NAME

FROM DEPT D

WHERE EXISTS (SELECT X

FROM EMP E

WHERE E.DEPT_NO = D.DEPT_NO);

EXISTS is a faster alternative because the RDBMS kernelrealizes that when the sub-query has been satisfied once,the query can be terminated.


32/41

32

Some Dos and Donts

Some SELECT statement WHERE clauses do not use indexes

at all. If you have specified an index over a table that is

referenced by a clause of type shown in this section Oracle will

simply ignore the index.

For each clause that cannot use an index, an alternative

approach, which will allow you to get better performance out of

your SELECT statements is suggested.


33/41

33

Do Not Use:Select * from

AccountWhere substr(ac_acct_no,1,1) = 9

Use:

Select * fromAccountWhere ac_acct_no like 9%

Do Not Use:

Select *

From fin_trxnWhere ft_trxn_ref_no != 0

Use: Select *

From fin_trxnWhere ft_trxn_ref_no > 0

Do Not Use:


34/41

34

Do Not Use:Select *From accountWhere ac_type || ac_branch = sav001

Use:Select *From accountWhere ac_type = sav

And ac_branch = sav001

Do Not Use:Select *

From CLIENT where

to_char(CUTT_OFF_TIME,yyyymmdd) =to_char(sysdate,yyyymmdd)

Use:Select *

From CLIENTWhere CUT_OFF_DATE >=

trunc(sysdate) and CUT_OFF_TIME to_char(sysdate,yyyymmdd)

Use:

Select *

From acct_trxnWhere at_value_date >= trunc(sysdate) + 1


36/41

36

Do Not Use:Select *From acct_trxnWhere to_char(at_value_date,yyyymmdd) =to_char(sysdate,yyyymmdd)

Use:

Select *

From acct_trxnWhere at_value_date >= trunc(sysdate)


38/41

38

Do Not Use:Select *

From acct_trxn

Where to_char(at_value_date,yyyymmdd)


39/41

39

Avoid Using SELECT * Clauses

The dynamic SQL column reference (*) gives you a way to refer toall of the columns of a table.

Do not use the * feature because it is very inefficient -- the * has to

be converted to each column in turn.

The SQL parser handles all the field references by obtaining the

names of valid columns from the data dictionary and substitutes them

on the command line, which is time consuming.

Using SQL*Plus Autotrace


40/41

40

g

If youre using SQL*Plus you can take advantage of the auto tracefeature to have queries explained automatically.

SQL*Plus will execute the query and display the execution plan following

the results.

E.g

SQL> SET AUTOTRACE ON EXPLAINSQL> SELECT animal_name FROM aquatic_animal

ORDER BY animal_name;ANIMAL_NAME

------------------------------Batty

Bopper

Flipper

3 rows selected.

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=10Bytes=170)

1 0 SORT (ORDER BY) (Cost=3 Card=10 Bytes=170)

2 1 TABLE ACCESS (FULL) OF AQUATIC_ANIMAL (Cost=1 Card=10Bytes=170)


41/41

41

SQL*Plus does execute the query. If a query generates a lot of I/O andconsumes a lot of CPU, you wont want to kick it off just to see the

execution plan.

In that case use following :

SQL> SET AUTOTRACE TRACEONLY EXPLAIN

you are through using autotrace, you can turn the feature off by issuing the

SET AUTOTRACE OFF command.

2713894 oracle tuning tips

Documents