Database Tuning

ObjectivesDescribe the roles associated with database tuning.Describe the dependency between tuning in different development phases.Describe SLA’s.Describe appropriate tuning goals.Describe common tuning problems.Describe tuning considerations.Describe performance and safety trade-offs.

Tuning methodologyPre 9i top down tuning, post 9i ‘performance tuning principles’ if top down not appropriate.Traditional approach is appropriate for development systems but new approach is for live systems.Performance tuning is ongoing and iterative process.Requires expertise of DBA and application designers and developers as well as system and network administrators.

Top down methodologyTune data designTune application designTune memory allocationTune I/O and physical structureTune resource contentionTune underlying platform

Production system1. Define problem clearly and identify tuning goals.2. Examine host system and gather oracle stats.3. Compare identified problems to common

performance problems.4. Use stats gathered in second step to get a picture

of what might be happening in the system.5. Identify changes to be made and implement the

changes.6. Determine whether objectives identified have been

met if yes STOP TUNING if not repeat 5 & 6 again.

Goal oriented tuningIt is important to set tuning goals and measure progress.Establish benchmarks and base line stats including:

Client machine performanceNetwork performanceMiddle tier application or web server performanceHardware performanceOS performanceOracle DB performance

Setting performance goalsNeed to be specific enough to allow quantifiable measures.

5 most frequent PL/SQL packages are always in memory for faster accessResponse time of a message in server will be less than ½ a second

Explicit goals allow:Tuning to be narrow in scope therefore effectiveStop tuning process once goal reached

Service level agreements (SLA’s)

Written agreements between DBA and users include:

Agreed response times Maximum allowable downtimeRecovery time following a failure

Can be used to drive performance goals.

General tuning conceptsTuning can have a detrimental effect on other areas

Faster CPU may improve batch processes but make OLTP slower

The batch works faster so is asking for IO quicker so queues start to form.

CPUTuning Oracle’s memory and IO will give little benefit if CPU is over-loadedOracle is a CPU aware product and several configuration parameters change dynamically when a CPU is added or removed from the server.

Continued ...Disk IO

The more oracle activity is done in memory (buffer cache) the lower the physical IO will beIncreasing buffer cache can make OS page and swap which is a serious overheadModern disk caching HW and SW complicate DB IO tuning since reads may be from disk cache as well

Continued ...Memory

The availability of memory for Oracle’s memory structures is key to good performanceMemory needs to be managed so that it is used to maximise benefit and not waste it.

NetworkThe speed of the network will affect client server systems

Common tuning problem areas

Poor application SQLPoor DB designInefficient execution plansExcessive file IOWaiting for DB resources

Two tuning guidelinesAdd more

If a resource is being demanded more frequently than they can be supplied then bottlenecks occur e.g.

Add more buffers to buffer cache if buffer latch waits occur

Make it biggerProblems may occur if a resource is too small

If latch waits are occurring on redo logs buffer then you can not add more log buffers but can increase the size of the existing ones

Tuning lifecycle Three areas of lifecycle where performance may be impacted in addition to normal running:1. Application design

Excessive normalisation = excessive joinsProcedure code v scripts

2. Configuration of new systemBenchmarked for each potential configuration

3. Changes in work loadIf workload patterns change the performance is affected e.g. adding more users or making application available to external users.

Review of oracle architecture

Oracle DBA needs to completely understand Oracle’s underlying architecture and mechanismsBefore tuning is done, you must understand the relationship between Oracle’s memory structures, background processes and IO activities

Database instanceWhen a database is started the current state of the database is given by the data files, a set of background (BG) processes and memory structures, which is called database instance (DBI)The DBI is a set of memory structures and BG processes that access a set of data files (DFs)Oracle’s physical file structures are collectively known as the Oracle server.

Init.ora

Redo logs

Archive redo logs

Control files

Data files

Memory system global area

DB buffer cacheRedo log bufferShared library

client

PMON

Serverprocesses

SMON

DBWn

CKPT

LGWR

ARCn

Data files (DFs)

The database is contained in a number of DFs held on diskWhen a DB is opened, these DFs and associated BG processes and memory structures are called a DBI. DFs are read via the client process into the memory structure database buffer cache from where the data is processedThey are written back to the DFs only by the DBWR process

DBWn (DataBase Writers)Except when the database is being recovered it is only the DBW which updates the data filesDBW writes blocks from the buffer cache that have been dirtied by various processesDBW tries to make sure that there are always free blocks in the cache for the server process to read data intoA commit in a client process does NOT make the DBW write blocksA check point makes the DBW write all current dirty blocks to speed any subsequent recovery

Re-do log bufferChanges made to a DB are written to the redo log bufferThis is a cyclic buffer and is flushed to the redo log whenever a user process flags a commit or the buffer becomes more than a third full or every 3 secondsRedo logs are fundamental to recovery.

Note: the DBW will not write dirty blocks to a data file until the redo log buffer containing the change has been written to the redo log

LGWR (Log Writer)Writes redo log entries to the REDO LOG from the redo log bufferWritten sequentially (serially) into cyclic redo logs

Redo log 1

Redo log 2

Redo Log 3

Redo log 4

Written when log 4 is full the next redo log is log 1

Redo LogThis records all the changes from the redo log buffer so that a DB can be recovered, it is written to by the LGWR processIt is used to recover a DB

Roll forward data files from a known point (backup) to any point covered by continuous redo logs

Min of 2 used cyclicallyAll redo logs must be kept since the last backup to enable a DB to be recoveredCan be queried using log miner.

Redo log archivingThe LGWR writes the contents of the redo log buffer to the current redo logsWhen each redo log is full it is closed and the information written to the next logThe current redo log is cycled roundRedo information wil be lost unless it is written away to a permanent area before the redo log is cycledIf turned on process ARCH does this by copying them to the archived redo log area

Archive redo logs

Archive redo logs and the current redo logs contain the change vectors as far back as the archive logs goIf a redo log is missing the the db can only be recovered to the redo log that is missingHence all redo must be kept from the last successful backup to enable recovery

ARCn processThe arch process automates the copying of the online redo to the archive areaIf archiving is turned on current when redo log is closed it is copied to archive area by ARCIf not copied by the time the un-archived current redo is cycled DB will STOP until archiving complete

Could be due to insufficient room

Control filesContains information about the DB including

Db nameFiles and locationsSystem control number of DB and data filesArchiving on or off

Used to detect and control recovery if SCN’s in control file do not match those on data files it knows if recovery needed.Less than 500K in <8i but can be several MB in 9i

Initialisation parameters (init.ora)

Contains parameters that control the DB instance, read on start upCan include parameters that

Name things (e.g. files)Set limitsAffect capacity

Many parameters can be changed dynamically using alter system or alter session however they are not automatically propagated across on close of DB unless edited in the init.oraSP (server parameter) file in 9i+ allows alter statements to dynamically change parameters.

Server parameter file (SP file)

These parameter files allow changes applied dynamically to be carried across shutting and opening the DBOn startup

If pfile is specified the init.ora file is usedIf no pfile specified then default spfile is used if existsIf no pfile specified and no default spfile exists then default init.ora file is used

CKPT (Checkpoint) processTo minimise the time to recover a DB, Oracle periodically tells the DBW to write all current dirty blocks to the data filesThis makes the DBW work harder by checkpoints help reduce the amount of work the DB has to do during a recoveryWhen a checkpoint is complete all header blocks in the data and control files have to be updated and a check point entry has to be written to the redo logCKPT updates the headers to reduce impact on DBW

PMON – process monitorMonitors the processors running and performs various functions including

Performs process recovery when a user process failsCleans up the cache and frees the resources held by the processesChecks dispatcher and server processors and restarts them if they have failed

It is always running if the db is open

SGA (Shared Global Area) memory structures

Three main memory structures in the SGA area

DB buffer cache – a cache of db blocks oracle can not process data unless the block it belongs to is in the cache Log buffers – a buffer of redo vectors being written to the redo logsShared pool – an area containing information on recently used statements, used to minimise reparsing of statements Very useful for optimisation

Have a look at …Look at V$session to identify what processes are runningUse V$parameter to identify the value of sga_max_size on the data base (largest the SGA will be allowed to get to)