DB_Tune.ppt

7/27/2019 DB_Tune.ppt

1/67

Database Tuning Methodology

Michael R. Ault

OCP Certified DBADMR Consulting Group


2/67


Begin With Physical Design

Proper use of RAID

Proper Controller/Stripe Usage

OFA (Optimal Flexible Architecture

Normalization/Denormalization

Sizing and Placement DB block size and other parameters

Optimizer Mode


3/67


RAID Usage

RAID 0/1 - Striped and Mirrored (or shadowed)

Good for all types of files, both read and write

RAID5 - Uses striping combined with parity disk

Good for read intensive files, some writepenalties


4/67


Proper Controller /Stripe Usage

Spread across controllers, not just disks

Use as many disks as is feasible (4 minimum)

Stripe size a multiple of db_block_read_count

Striping, db_writers, PQO all go hand-in-hand


5/67


1

Disk Controller

4-disk Stripe Set

Example of Improper Striping


6/67


2

Disk Controllers

4-disk Stripe Set

1 43

Example of proper striping


7/67


OFA (Optimal Flexible Architecture)

A standardized method of file placement

A step towards isolation of function

Requires analysis of usage patterns toproperly implement

Allows for flexibility in file placement


8/67


ORACLE_BASE /var/opt/oracle

ORACLE_HOME /var/opt/oracle/product/7.3.4

/oracle1/ADMIN/dbname/DATA/dbname

/CONTROL/dbname

/LOG/dbname

/LOCAL/dbname/TAR/dbaname


9/67


/oracle1/ADMIN/dbname

bdump

udumpcdump

arch

export

adhoccreate

pfile

logbook


10/67


Normalization

Most databases attempt to use 3rd normal

form Every attribute must relate to t whole primary

key and only to the primary key

Good in theory but hard to implement 100% Based in preventing insert/update/delete

anomalies


11/67


Denormalization

Used to real world the data structure

Usually items that are always retrievedtogether will be placed in the same table andthe keys combined

Usually used for report type informationAs long as allowance is made for any possible

anomalous behavior ok to do


12/67


Sizing

First must size tables, indexes and clusters

Then size tablespaces

SWAG avg_row_len*num_rows*1.5 (tables and clusters)

avg_key_len*num_keys*1.5 (indexes)

More accurate

Use Admin guide or my book! Always size for 1 year as a minimum

If using PQO allow enough freespace in an index tablespace forn*num_pqo_slaves initial extents


13/67


DB_BLOCK_SIZE and Other Parameters

DB_BLOCK_SIZE is not able to be reset without

rebuilding the database, size it as large as youever will need

Set other MAX parameters to what makessense, but they are able to be reset with acontrol file rebuild


14/67


Optimizer Mode

CHOOSE or RULE

I have used CHOOSE since 7.2 CHOOSE dependent on analyzed tables

Can get to 70% of the performance for non-

optimized code Good for ad hoc or changing environments


15/67


Optimizer Mode (Cont.)

RULE

Good for well known predictable environments Good for non-ad-hoc environments

Requires a more hands-on DBA


16/67


Tune Application Statements

Full table scans

Proper Index Usage HINTS

Bind Variables

Use PL/SQL


17/67


Full Table Scans

Used to be always bad

Now if scanning size/PQS is smaller than anindex scan makes sense to FTS

If a table is large and must be FTS, then

consider manually striping it in V7 or use O8table partitioning

If not using PQO, FTS is bad

If using CHOOSE analyze or FTS will result


18/67


Full Table Scans (cont.)

Use EXPLAIN PLAN

Can do automatically using:SET AUTOTRACE ON EXPLAIN

Can get statement timing using SET TIMING ON

Can use both together


19/67


Example using AUTOTRACE:DCAR: SET AUTOTRACE ON EXPLAIN

DCARS: select * from dba_running_stats where rownum


20/67


Example Using SET TIMIMGDCARS:set timing on

DCARS:r

1* select * from dba_running_stats where rownum


21/67


TKPROF

Used against trace files

Must set SQL tracing on either at database orsession level

Should set TIMED_STATISTICS to true

Gives explain plan, timing and row counts aswell as CPU related stats


22/67


PQO (Parallel Query Option)

Use in terminal 7.2 and 7.3 releases

If full table scans are have tos then do them inparallel with stiping or partitions

In O8 everything is parallel if partitioning or

striping is used. Stripe to the same number of disks as degree

of parallel or partition to as many disks


23/67


HINTS

Hints allow control of the optimizer

Tells optimizer to use a specific action Can be used with DELETE, SELECT, UPDATE

commands

Placed as a comment usually after thekeywords DELETE, SELECT, UPDATE


24/67


HINTS (cont.)

Example:

SELECT /*+ hint */

;


25/67


Hint Meaning

+ Must be right after

comment indicator,

tells Oracle this is

a list of hints.

ALL_ROWS Use the cost based

approach for best

throughput.

CHOOSE Default, if statistics

are available willuse cost, if not,

rule.

FIRST_ROWS Use the cost based

approach for best

response time.

Hint Meaning

RULE Use rules based

approach, this

cancels any

other hints

specified for this

statement. This

will not be

available after

ORACLE7.Access Method Hints:

CLUSTER(table) This tells Oracle to

explicitly do a

cluster scan to

access the cluster


26/67


Hint Meaning

FULL(table) This tells the

optimizer to do a

full scan of

the specified table.

HASH(table) Tells Oracle to

explicitly choose

the hash access

method for the

table.HASH_AJ(table) Transforms a NOT

IN subquery to a

hash anti-join.

ROWID(table) Forces a rowid

scan of the

specified table.

Hint Meaning

INDEX(table [index])Forces an index

scan of the

specified table

using thespecifiedindex(s). If a list of

indexes is

specified, the

optimizer chooses

the one with thelowest cost. If no

index is specified

then the optimizer

chooses the

available index for

the table with thelowest cost.


27/67


Hint Meaning

INDEX_ASC (table [index]) Same as

INDEX only

performs an

ascending search

of the indexchosen,

this is functionally

identical to the

INDEX statement.

INDEX_DESC(table [index]) Same asINDEX except

performs a

descending search.

If more than one

table is accessed,

this is ignored.

Hint Meaning

INDEX_COMBINE(table index)

Combines the

bitmapped indexes

on the table if the

cost shows that to

do so would give

better performance.

INDEX_FFS(table index) Perform a

fast full index scanrather than a table

scan.

MERGE_AJ (table) Transforms a NOT

IN subquery into a

merge anti-join.


28/67


Hint Meaning

USE_CONCAT Combines OR

conditions in the

WHERE clause

into a compound

query using the

UNION ALL set

operator.

AND_EQUAL(table index index

[index index index])Causes a merge on

several single

column indexes.

Two must be

specified, five can

be.

Hints for join orders

Hint Meaning

ORDERED This hint forces

tables to be joined

in the order

specified. If you

know table X has

fewer rows, then

ordering it first

may speedexecution in a join.

STAR Forces the largest

table to be joined

last using a

nested_loops join

on the index.


29/67


Hints for Join Operations:

Hint Meaning

NO_MERGE (table) This causes

Oracle to join each

specified table with

another row source

without a sort-

merge join

USE_HASH (table) This causes Oracle

to join eachspecified table with

another row source

with a hash join

Hint Meaning

USE_NL(table) This operation

forces a nested

loop using the

specified table asthe controlling

table.

USE_MERGE(table,[table,...]) This

operation forces a

sort-merge-joinoperation of the

specified tables.


30/67

Database Tuning methodologies

Hints for Parallel Operations

Hint Meaning

APPEND This specifies that

data is to be or not

to be appended to

the NOAPPEND

end of a file rather

than into existing

free space. Use

only with INSERTcommands.

NOPARALLEL (table) This specifies

the operation is not

to be done in

parallel.

Hint Meaning

PARALLEL(table, instances)

This specifies the

operation is to be

done in parallel.

PARALLEL_INDEX Allows

parallelization of a

fast full index scan

on any index.


31/67


Other Hints:

Hint Meaning

CACHE The blocks

retrieved for the

table in the hint are

placed at the MRU

end of the LRU list

when the table is

FTS.

NOCACHE The blocksretrieved for the

table in the hint

are placed at the

LRU end of the

LRU list when the

table is FTS.

Hint Meaning

PUSH_SUBQ This causes

nonmerged

subqueries to be

evaluated at theearliest possible

point in the

execution plan.


32/67


Use Bind Variables

Creates reusable statements

Prevent filling up the shared pool with garbageSQL

Any difference in a SQL statement makes it anew statement and thus non-reusable

Helps prevent pool thrashing


33/67


User Text Executes

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

DCARS SELECT SUM(item_amt_mtd)FROM billsum WHERE 1

region_code= '32' AND region_dealer_num =

'0725' AND catalog_number = 'PARTS' AND

year_num >=(TO_NUMBER(TO_CHAR(sysdate,

'YYYY')) - 2) AND year_num


34/67


User Text Executes

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

DCARS Select Descr from CODE 10372

where Code_Table_Name = :1 and

Code = :2

Notice the above code has been reused 10372 times.

This is because of the use of bind variables (:1 and:2)


35/67


Use PL/SQL Tables instead of databasetables for temporary holding

Memory IO is several orders of magnitudefaster than disk IO

Use of UTL_FILE allows formatting of output tofile

Use of DBMS_OUTPUT is also possible withanonymous PL/SQL


36/67


Tune Memory

On some platforms Oracle must be relinked to

go bigger than ~250 meg You shouldnt exceed 50-60% of available

memory

Size kernel parameters properly (sharedsegment size)

Size swap and paging files properly (4 timesphysical memory)


37/67


Tune Memory (cont)

Set semaphores properly

Set open file limit and number of processesproperly

Set process private memory size properly

I suggest setting these to their maximum for yourconfiguration.


38/67


SGA Sizing

DB_BLOCK_BUFFERS

SHARED_POOL_SIZE LARGE_POOL_SIZE (Oracle8)

Log Buffers


39/67


DB_BLOCK_BUFFERS

Usually 1/100 to 1/200 of full DB physical size

so for 20 gig 200 to 400 megabytes Total SGA not more than 50-60% of segment

size or failure to fork errors may result

SHARED_POOL_SIZE Depends on system usage, ad-hoc requires

more, all stored package and canned queryrequires less.


40/67


SHARED_POOL_SIZE (cont)

ORA-04031, ORA-07445 errors can result from a

too-small shared pool Performance that is peak at startup and

declines also symptom of too small or trashingshared pool

Shared pool is for sharable code, notthrowaway SQL

Pin large/frequently used objects


41/67


LOG_BUFFERS and LOG_BUFFER_SIZE

usually I size at redo log size or a fraction of

redo log size, the default is too small The number of buffers is usually ok at default

Watch redo log waits and increase logbuffers/size until they minimize

Waits can also be reduced by adding moreredo logs


42/67


When are DB block Buffers sized correctly?

When buffer hit ratio is high

AND when db block waits are low A high hit ratio doesnt mean there is no

contention for blocks

Use the X$CBRBH and X$CBCBH tables and theDB_BLOCK_LRU_EXTENTDED_STATISTICS andDB_BLOCK_LRU_STATISTICS to monitor blockhits gained or lost by adding/removing buffers


43/67


Tune Proactively

No users in SYSTEM tablespace

No rollbacks in non-rollback tablespaces Temporary segments in temporary

tablespaces

Verify space before you startAllow for parallel builds

Require new SQL to be fully analyzed andexplained


44/67


Tune Proactively (Cont.)

Validate new indexes use the provided

UTLDIDXS.SQL , UTLOIDXS.SQL and UTLSIDXS.SQLscripts.

Limit ad hoc SQL usage

Analyze before it is needed

Periodically use UTLBSTAT/UTLESTAT orautomated sampling scripts


45/67


General Gotchas

Watch out for C_TS# corruption bug

Watch for disable/enable constraint errors Index storage and table definitions are not

persistent and must be restated on enable


46/67


Owner Index Tablespace

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

AGCD SYS_C001131 DATA_TS

SYS_C001133

SYS_C001134

SYS_C001135

SYS_C001136

SYS_C001162

.

USR_PK

XRF_PK

CAT_GRA INDEX_TS


47/67


Proactive Tuning

Be sure you have enough and properly sized

redo logs on separate platters or controllers Be sure one segment per DML user in rollback

segments

Watch alert log

Monitor file space usage

One some systems SQLTRACE is turned on


48/67


Inherited Applications

Immediately check sizing, extents and file

placement Check chaining and fragmentation

Check indexes for browning

Monitor SGA usage and shared pool usage Library Hit Ratios


49/67


Browning is calculated by using the calculation:

(del_lf_rows_len/decode((lf_rows_len+

del_lf_rows_len),0,1,lf_rows_len+del_lf_rows_len))*100


50/67


Example Browning Report:

NAME Deleted Bytes Filled Bytes Browned

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

I_ARHIST_3 15,091,329 361,274,732 4.01

I_AR_TURN_DEALER 394,488 823,958 32.38

I_BUNDLE_BO_2 19 95 16.67

I_BUNDLE_RESERVE_BUND 9,705 52,203 15.68

I_BUNDLE_RESERVE_CATVER 17,736 67,179 20.89

I_CHECKPNT_1 19 19 50.00I_CURRENT_SETTLEMENT 1,125 1,290 46.58


51/67


Library Hit Ratio

Library area suffers contention

Use:select

namespace,

gets,

gethitratio*100 gethitratio,

pins,

pinhitratio*100 pinhitratio,

RELOADS,

INVALIDATIONS

from

v$librarycache


52/67


Example Report:

Get Pin

Library Object Gets Hit% Pins Hit% Reloads Invalid

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

SQL AREA 439,864 92.83 2,997,952 97.60 5,338 607

TABLE/PROCEDURE 127,146 97.31 1,455,108 99.66 1,049 0

BODY 4,459 98.45 4,468 98.19 12 0

TRIGGER 9,937 99.22 9,937 99.22 0 0

INDEX 361 1.11 361 1.11 0 0

CLUSTER 33 48.48 21 42.86 0 0OBJECT 0100.00 0 100.00 0 0

PIPE 21,918 99.98 24,220 99.98 0 0


53/67


Latch Contention

Monitor using the v$latch and v$latchname

views:SELECT

a.name,100.*b.sleeps/b.gets ratio1,

100.*b.immediate_misses/decode((b.immediate_misses+

b.immediate_gets),0,1) ratio2

FROMv$latchname a, v$latch b

WHERE

a.latch# = b.latch# AND b.sleeps > 0;


54/67


Example Output

NAME RATIO1 RATIO2------------------------------ --------- ---------

cache buffers chains .0000

row cache objects .0007

shared pool .0299 .0000

library cache .0003


55/67


Block Contention

SELECT class,sum(count) total_waits, sum(time)total_time

FROM v$waitstat

GROUP BY class;


56/67


Example Ouptut

CLASS TOTAL_WAITS TOTAL_TIME------------------ ----------- ----------

data block 2485 1873

undo block 18 1

undo header 4 3


57/67


Check EnvironmentFor Proper Settings

The oraenv programdoes this on UNIX

Checks:

OS version

Ulimit settings

Swap settings

Disk mounts

Disk freespace

Environment settings

System Tables

Semaphores

Shared memory

Oratab entries

Tracing settings


58/67


Shared pool usageselect

sum(a.bytes)/(1024*1024) shared_pool_used,

max(b.value)/(1024*1024) shared_pool_size,(max(b.value)/(1024*1024))-(sum(a.bytes)/(1024*1024)) shared_pool_avail,

(sum(a.bytes)/max(b.value))*100 shared_pool_pct

from v$sgastat a, v$parameter b

where a.name in ( 'reserved stopper', 'table definiti', 'dictionary cache',

'library cache', 'sql area', 'PL/SQL DIANA', 'SEQ S.O.')

and

b.name='shared_pool_size';


59/67


Example Output

SHARED SHARED SHARED SHAREDPOOL POOL POOL POOL

USED SIZE AVAIL PCT

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

63.87 135.00 71.13 47.31


60/67


If shared pool greater than 90% may needsize increase

Size needs could be due to garbage SQL SQL_GARBAGE view helps to sort this out


61/67


SQL_GARBAGE Viewcreate or replace view

sql_garbage as

select b.username users,sum(a.sharable_mem+

a.persistent_mem) Garbage,

to_number(null) good

from sys.v_$sqlarea a,

dba_users b where(a.parsing_user_id =

b.user_id and

a.executions1)

group by b.username;


62/67


Example Select against SQL_GARBAGEcolumn garbage format 9,999,999,999 heading 'Non-Shared SQL'

column good format 9,999,999,999 heading 'Shared SQL'

column good_percent format 999.99 heading 'Percent Shared'break on report

compute sum of garbage on report

compute sum of good on report

compute avg of good_percent on report

spool rep_out\sql_garbage

select a.users,a.garbage, b.good,

(b.good/(b.good+a.garbage))*100 good_percent

from sql_garbage a, sql_garbage b

where a.users=b.users and a.garbage is not null and b.good is

not null;

spool off


63/67


Example OutptutUSERS Non-Shared SQL Shared SQL Percent Shared

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

AULTM 502,520 606,937 54.71

DCARS 18,319,609 21,081,924 53.51HEARONB 14,966 19,185 56.18

MCNAIRT 39,956 212,468 84.17

QDBA 26,329 1,949,775 98.67

RCAPS 3,636,691 6,993,564 65.79

RCOM 269,398 85,575 24.11

REPORTS1 156,824 292,641 65.11SECURITY_ADMIN 20,583 8,137 28.33

SYS 63,034 1,165,528 94.87

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

avg 62.54

sum 23,049,910 32,415,734


64/67


Shared Pool Thrashing

Caused by excessive garbage SQL

Results in repeated scans of SQL hash codes When there are several thousand SQL areas

that are not reusable, this impactsperformance

Happens in Ad-Hoc environments where bindvariables arent used


65/67


Pool Used

0

50

100

150

161

121

181

241

301

361

421

481

541

601

661

Measurement

Meg

Pool Used


66/67

Database Tuning MethodologyPerformance

0

100

200

300

400

Measurement

1/100

sec

Performance

Pool Usage

0

20

40

60

80

100

120

140

Measurement

Meg

Pool Usage


67/67


Summary

Tune OS and file layout first

Tune application statements Tune memory

Tune Contention

Inherited applications need special attention,look at structure and memory usage (usually

you are stuck with application)

Documents

DB_Tune.ppt