Tuning your applications with the Quest Central ... - Quest Software

quest

Tuning your applications with the Quest Central ... - Quest Software

Top Tips for

Optimizing Oracle

Databases

Guy Harrison

Principal Software Architect


The Top Tips:

1. Adopt a methodical approach to

tuning

2. Tune your Application workload first

3. Reduce contention before tuning IO

4. Minimize physical IO

5. Optimize IO


Adopt a Methodical Approach

� Best results will come from

performing an orderly sequence of

optimizations to your system.

� Performing ad-hoc or random

optimizations is both inefficient and

often futile


Quest Tuning Methodology (1)

� Optimize application workload first

–Tune SQL and PL/SQL

– Optimize table sizes for scans

– Optimize indexing scheme

– When this is done, logical IO demand on the

database will be optimal


Quest Tuning Methodology (2)

� Once logical IO is nominal, eliminate

contention for internal resources

– Contention may be restricting the amount of logical

IO that Oracle can perform.

– Use the wait interface to identify contention

•Latches

•Locks

• Freelists

• Redo log

• Buffer cache


Quest Tuning Methodology (3)

� Once contention is eliminated, optimize the

physical IO demand

– Physical reads to the datafiles

– Disk sorts

� Optimal memory configuration is the key

– Buffer cache size

– Sort area size/pga_aggregate_target

– Keep and recycle pools

– Oracle9i advisories are invaluable


Quest Tuning Methodology (4)

� Once physical IO demand is

optimized, optimize the IO

subsystem to meet the demand:

– Balance IO load across disk devices

– Increase the number of disk devices used

for database datafiles

– Increase the database block size

– Consider moving files to raw devices


Tuning the Application

Workload (1)

� Identify resource-intensive or

tunable SQL

– Mine V$SQL or use Quest Central SQL

tuning

–Optimize target SQL

•Indexing strategy

•Rewrite SQL

•Hints

• Cost based optimizer


Examining Contention

� Look at the values in the table

“V$SYSTEM_EVENT”

� Eliminate any idle events (SQL*Net waiting

for client, etc)

� Calculate the amount of time spent waiting

for the remaining events.

� Minimize parse time

Quest Central Spotlight uses this technique

to graphically highlight contention


Abnormal Events

� The following events should not contribute

significantly to the total wait time:

– Latch free

– Buffer busy

– Free buffer

– Write complete

– Enqueue

– Parse time (from v$sysstat)

– Log switch

– Log buffer


Enqueue Waits

� These occur when a session is

waiting to get a lock held by another

session.

� This might be due to application

design, application design flaw, or

internal contention

� Using v$lock you can identify what

type of lock is being sought and

which object.


Resolving Enqueue Waits

� If the object is an application table you

need to encourage an application design

change.

– Changing from a “pessimistic” to “optimistic”

strategy can often resolve the issue.

� If the lock is a system lock determine what

resource is involved.

– Most common system lock contention is for the

“Space Transaction” lock.


Investigating the lock waits


Buffer Busy Waits

� Most typically occur when a table has too

few freelists and is subject to concurrent

inserts.

� This shows up as “data block” waits in

v$sysstat – not “Freelist” waits

� Solution is simply to add more freelists

� Oracle9i ASM option reduces freelist waits


Free Buffer and Write Complete

Waits

� Free buffer waits occur when a session

wants to bring a block from disk into the

cache, but has to wait for an unmodified

buffer to become available.

� Write complete waits occur when a session

wants to update a block that is currently in

the process of being written to disk.

� In both cases, database writer

configuration is probably responsible


Configuring Database Writers

� Only the database writer is allowed to

write to database files.

� If you have too few database writers, then

the DBWR cannot write as fast as user

sessions can make changes.

� Implement asynchronous IO (preferably)

or configure multiple database writers – at

least one per disk.


Log Switch

� When a redo log fills, Oracle switches

to the next log.

� The switch cannot occur if the new

log has not yet been archived or

checkpointed.

� Following best practice for redo log

layout can avoid this.


Best Practices for Redo Logs

� Size the redo logs so that log switches do

not occur to frequently (5 minutes)?

� Put redo logs on dedicated devices.

� Alternate redo logs between two devices

(so that while one is being written, the

archiver can be reading the other).

� Create enough redo logs so that even if

the archiver falls behind during peak

processing, users are not affected.


Minimize Physical IO

� Our aim is to try and reduce the

amount of logical IO that becomes

physical IO

– Size the buffer cache correctly

– Allow adequate memory for PGA structures

(sort_area_size, hash_area_size,

pga_aggregate_target)

– Consider keep and recycle pools


Minimizing Physical IO in

Oracle9i

� Very significant new functionality to

help you optimize your memory

allocation:

– Buffer cache, shared pool and pga

advisories allow you to determine the best

way to allocate memory across these

structures.

– Information in v$sql_plan_statistics helps

you allocate segments into keep and recycle

pool


Using the 9i Advisories

� Three views show effect of altering

memory settings:

– V$db_cache_advice: how much physical IO

would be saved by changing buffer cache

sizes

– V$shared_pool_advice: change in parse

times for various shared pool sizes

– V$pga_target_advice: change in IO to

temporary segments for various

pga_aggregate_targets


Using the 9i Advisories

� Determine amount of memory available for

the SGA and all PGAs on your system

� Determine the combination of buffer

cache, shared pool and pga that will

reduce waits for parsing and IO

� These parameters are all dynamic in 9i

� The next release of Quest Central Spotlight

will automatically adjust these settings for

you.


Mining v$sql_plan

� Keep and recycle pools can be very

effective in optimizing the cache

� In the past, it has been hard to know

how to allocate objects to the various

caches.

� In 9i v$sql_plan can show you how

your segments are accessed


Mining v$sql_plan

� Small tables subject to frequent

scans should be allocated to the keep

pool

� Large tables subject to table scans

only should be allocated to the

recycle pool

� Tables subject mainly to index

lookup should go in the default pool


Optimize IO

� Basic principle is to allocate sufficient disks

to support your workload and spread IO

evenly across these disks.

� Typical disk devices can do about 50

IO/second. If you divide your physical IO

rate by 50, you have a first cut estimate of

the number of disks you will need.

� Your disk devices need to support the IO

rate as much as the physical storage

requirements. It’s OK to have sparsely

populated disks!


QUEST CENTRAL for Oracle

� A suite of integrated, best of breed

technologies

� Aids in the identification, diagnosis and

resolution of performance problems

� Diagnoses problems

– Occurring in real-time

– Have occurred in the past

� Improves performance!

– Oracle RDBMS

– Applications running on it


Quest Central Health Check

� A no-charge service from Quest in

which our consultants use Quest

Central Performance management to

diagnose the health of your

database.

� The reason we can offer this service

is that our tuning and diagnostic

tools can rapidly identify tuning

opportunities.


Quest Central health check

� The Health check program proves the

ROI of Quest Central:

– Allows you to manage more databases with

less staff

– Allows you to get more return from your

hardware and software investments

– Avoids costly hardware upgrades.


Q & A

� Register for a Free Database Health

Check:

http://www.quest.com/healthcheck/


THANK YOU

FOR LISTENING

More magazines by this user
Similar magazines