Transcript dba lecuture 8 - Database Tuning

Database Tuning
Objectives
Describe 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 methodology
Pre 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 methodology
Tune
Tune
Tune
Tune
Tune
Tune
data design
application design
memory allocation
I/O and physical structure
resource contention
underlying platform
Production system
1.
2.
3.
4.
5.
6.
Define problem clearly and identify tuning goals.
Examine host system and gather oracle stats.
Compare identified problems to common
performance problems.
Use stats gathered in second step to get a picture
of what might be happening in the system.
Identify changes to be made and implement the
changes.
Determine whether objectives identified have been
met if yes STOP TUNING if not repeat 5 & 6 again.
Goal oriented tuning
It is important to set tuning goals and
measure progress.
Establish benchmarks and base line stats
including:
Client machine performance
Network performance
Middle tier application or web server performance
Hardware performance
OS performance
Oracle DB performance
Setting performance goals
Need to be specific enough to allow
quantifiable measures.
5 most frequent PL/SQL packages are always in
memory for faster access
Response time of a message in server will be less
than ½ a second
Explicit goals allow:
Tuning to be narrow in scope therefore effective
Stop tuning process once goal reached
Service level agreements
(SLA’s)
Written agreements between DBA and
users include:
Agreed response times
Maximum allowable downtime
Recovery time following a failure
Can be used to drive performance
goals.
General tuning concepts
Tuning 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.
CPU
Tuning Oracle’s memory and IO will give little
benefit if CPU is over-loaded
Oracle 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 be
Increasing buffer cache can make OS page
and swap which is a serious overhead
Modern 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
performance
Memory needs to be managed so that it is
used to maximise benefit and not waste it.
Network
The speed of the network will affect client
server systems
Common tuning problem areas
Poor application SQL
Poor DB design
Inefficient execution plans
Excessive file IO
Waiting for DB resources
Two tuning guidelines
Add 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 bigger
Problems 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 joins
Procedure code v scripts
2.
Configuration of new system
Benchmarked for each potential configuration
3.
Changes in work load
If 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 mechanisms
Before tuning is done, you must
understand the relationship between
Oracle’s memory structures, background
processes and IO activities
Database instance
When 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
Memory system global area
Redo log buffer
DB buffer cache Shared library
PMON
SMON
client
Server
DBWn
processes
Control
files
CKPT
Data files
LGWR
Redo logs
ARCn
Archive redo
logs
Data files (DFs)
The database is contained in a number of DFs
held on disk
When 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 processed
They 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 files
DBW writes blocks from the buffer cache that have
been dirtied by various processes
DBW tries to make sure that there are always free
blocks in the cache for the server process to read
data into
A commit in a client process does NOT make the
DBW write blocks
A check point makes the DBW write all current dirty
blocks to speed any subsequent recovery
Re-do log buffer
Changes made to a DB are written to the redo
log buffer
This 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 seconds
Redo 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 buffer
Written sequentially (serially) into cyclic
redo logs
Written when log 4 is full the next redo log is log 1
Redo
log 1
Redo
log 2
Redo
Log 3
Redo
log 4
Redo Log
This records all the changes from the redo log
buffer so that a DB can be recovered, it is written
to by the LGWR process
It 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 cyclically
All redo logs must be kept since the last backup
to enable a DB to be recovered
Can be queried using log miner.
Redo log archiving
The LGWR writes the contents of the redo log
buffer to the current redo logs
When each redo log is full it is closed and the
information written to the next log
The current redo log is cycled round
Redo information wil be lost unless it is
written away to a permanent area before the
redo log is cycled
If 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 go
If a redo log is missing the the db can only be
recovered to the redo log that is missing
Hence all redo must be kept from the last
successful backup to enable recovery
ARCn process
The arch process automates the copying of
the online redo to the archive area
If archiving is turned on current when redo
log is closed it is copied to archive area by
ARC
If 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 files
Contains information about the DB including
Db name
Files and locations
System control number of DB and data files
Archiving 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 up
Can include parameters that
Name things (e.g. files)
Set limits
Affect 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.ora
SP (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 DB
On startup
If pfile is specified the init.ora file is used
If no pfile specified then default spfile is used if
exists
If no pfile specified and no default spfile exists
then default init.ora file is used
CKPT (Checkpoint) process
To minimise the time to recover a DB, Oracle
periodically tells the DBW to write all current
dirty blocks to the data files
This makes the DBW work harder by
checkpoints help reduce the amount of work
the DB has to do during a recovery
When 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 log
CKPT updates the headers to reduce impact on
DBW
PMON – process monitor
Monitors the processors running and
performs various functions including
Performs process recovery when a user
process fails
Cleans up the cache and frees the
resources held by the processes
Checks 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 logs
Shared 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 running
Use V$parameter to identify the value
of sga_max_size on the data base
(largest the SGA will be allowed to get
to)