You are on page 1of 8

The Maintenance Plan

Components of a simple maintenance plan that should be automated as much as


possible
Regular backups are absolutely critical to the safety of the database. Backup logs
should be reviewed frequently and a recovery exercise should be conducted at least
once a yearmore often if possible.
The query optimier relies on statistical information about the data. !tatistics are
automatically refreshed by "racle every night# but some sites use a custom
approach. $anual intervention may be occasionally needed.
%ata that is no longer needed should be achieved and then &urged from the
database. Tables and indexes that contain a large amount of wasted space should
be rebuilt to reclaim space.
'og files should reviewed regularly# daily if possible. "ld log files should be removed.
%isk capacity and system capacity should be reviewed regularly. %isk space should
be proactively added to the database.
(ser )ctivities should be )udited
&asswords should be changed regularly or when compromised. (nneeded accounts
should be locked or removed.
&atches should be applied to the database when necessary.
Backups
Best Practices for Database Backups
*stablish service level agreement +!'), for backups and recovery. Clearly document
the maximum amount of data loss that is permitted# backup retention policies# and
how much time is allowed for database recovery.
%ocument the backup methodology and have it formally reviewed. &ublish the
documentation to an audience that includes the database owner.
&eriodically test recoverable backups. Typically this is done on a testing
environment. ) recovery test establishes how long it will take to recover the
database.
Recover from user error +-hen users inadvertently update or delete the wrong data,
.ave contingency plan that cover damage to the operating system or hardware be
prepared to move the database to another server.
*nsure the safety of backups. The traditional method is to send backup tapes offline.
/ewer methods involve backups to a backup appliance over the network. )
combination of near- line +disk, and far- line +tape or network, backups can be used.
/ear0 line backups reduce the time needed for recovery# while far0 line backups
increase the safety of backups. The tape library should not be a single point of failure
ensure that data can be recovered even if the tape library is damaged.
Retain multiple backups in case one set of backups is damaged.
Backup scripts should incorporate error checking and an adequate amount of
logging. The logs should be retained for an appropriate time. /otification of backup
failures should be sent to the database administrators. Backup failures should be
formally investigated.
Reports of backup1s success and failures# the amount of data backed up# and time it
took to perform backups should be generated and sent to an audience that includes
the database administrators and the database owner.
Changes to any aspect of backup procedures whether temporary or permanent#
should be performed under formal change control procedures.
Best Practices for Oracle Database Backups
(se recovery $anager +R$)/, for backups. The advantages of R$)/ are so
numerous and valuable that it is hard to 2ustify not using it. 3or example# R$)/
checks data blocks for corruption while it is making a backup# single0 block recovery
is possible with R$)/# and so on.
&revent unlogged operations in the database that use )RC.45*'"6 mode7 use
)'T*R %)T)B)!* 3"RC* '"664/6 command to this.
Back up all the aspects of the databases including the archive d redo logs +for
databases that use )RC.45*'"6 mode,# the control file# and the parameter file
+spfile,.
Create logical backups to supplements physical backups. This help to create a
certain amount of protection from logical damage# such as data entry errors. (se a
setting such as 3')!.B)C89T4$* to ensure the consistency of the exported data.
'everage "racle1s 3lashback features by increasing the value of
(/%"9R*T*/T4"/ from the default value of :; minutes to a more appropriate
value such as <= hours. This allows recovery from logical damage without having to
resort to physical backups.
%atabase that run in )RC.45*'"6 mode should set ')69)RC.45*9T)R6*T to
an appropriate value# such as :; minutes# to control maximum data loss.
4ncorporate the use of techniques that check for data corruption. These include
initialiation parameters# such as %B9B'"C89C.(C84/6#
%B9B'"C89C.*C8!($# and %B9'"!T-R4T*9(&%)T*# and commands that
scan the database# such as 5)'4%)T* %)T)B)!*
Statistics
The query optimier requires statistical information about the data such as the
number of rows in each table# in order to generate efficient query plans7 this
information is collected using the procedures in the %B$!9!T)T! package.
Beginning with "racle %atabase :>g# statistical information about the data is
refreshed automatically by a scheduled nightly 2ob called 6)T.*R9!T)T!9?"B7
you are free to disable this 2ob in favour of a custom approach. "racle supplies a
wide collection of procedures to collect and manage statistics including
6)T.*R# %*'*T*# 6*T# !*T# 4$&"RT# *@&"RT# '"C8# (/'"C8# &(B'4!. and
R*!T"R* procedures.
Archiving and Purging
%atabase performance commonly degrades as the database grows large. To keep
the database performing optimally# we should remove unnecessary data from the
database. 4n some cases# it may be necessary to save a copy of the data in a data
archive# such as flat files# @$' documents# or the like# before the data is purged from
the database. The archiving phase also involves a special backup that is tagged with
a high retention setting# such as seven years.
The freed space is automatically used by new data. Regular purging keeps the sie
of the database under control and helps keep performance stable. 4f a large amount
of data is purged at a time# the sies of the tables and indexes will not be
commensurate with the amount of data they actually contain# and additional
maintenance will be required to compact and shrink the bloated tables and indexes.
This is discussed in the section on rebuilding tables and indexes.
The use of partitioning can completely eliminate the need for archiving# purging# and
rebuilding. 3or example# a table can be divided into partitions in such a way that
each month1s data is inserted into a separate partition. Aueries that require the most
recent data perform optimally because the required data will be clustered in a
relatively small number of data blocks instead of being randomly scattered
throughout the table as happens when partitioning is not used. 4n the case of
partitioned tables# purging the data requires only that a partition be dropped7 this is a
very quick operation. 4f the old partitions are in a separate tablespace# an alternative
to purging is to convert the tablespaces to read0 only mode and move them to cheap
storage such as -"R$ drives or unmirrored !)T) disks7 this is a wonderful way to
keep performance optimal without having to remove data. *ven the overhead of
backups can be kept under control7 read0 only tablespaces require to be backed up
only one more time with a high retention setting and then no longer need to be
backed up.
Rebuilding
The sie of a table does not change when records are deleted from itthe indexes
associate with the table will not shrink in sie either. The wasted space causes three
problemsB
The gains that come from caching blocks of data in memory are reduced
because fewer records are packed into each block.
)dditions space on disk will be required as the database grows.
Backup and recovery will require more time# more space# and more
computing resources.
The tables and indexes will have to be rebuilt to reclaim spaceseveral
methods are available for the purpose. Tables and indexes that have a lot of
wasted space are automatically identified by the )utomatic !egment )dvisor#
which runs automatically during the nightly maintenance
)lternatively# you can conduct your own investigation of wasted space# using
the !&)C*9(!)6* procedure. "nce you have identified tables and indexes
that will benefit from compaction# you can reclaim the wasted space using the
!.R4/89!&)C* command# using the */)B'* R"- $"5*$*/T command
"racle does not do this automatically# so as not to affect any application
that has taken advantage of row addresses +R"-4%s,.
Log File Maintenance
'og files of all kinds accumulate over time and can fill up the available space. 3or
example# a trace file is created whenever certain errors occur# such as "R)0 >>>C>
+deadlock, and "R)0 >>C>> +internal error,.
The log files are organied into an )utomatic %iagnostics Repository +)%R,# whose
location is controlled by the %4)6/"!T4C9%*!T setting. 'og files are automatically
purged after D> daysyou can change the retention window using the !*T
C"/TR"' option of the )%RC4 tool. Eou can also purge log files manually using the
tool1s &(R6* command
Auditing
"racle provides the ability to audit all aspects of database usage. )udit records can
be stored in the )(%F table owned by !E! or in files outside the databasethis is
controlled by the )(%4T9TR)4' and )(%4T934'*9%*!T settings. There are a
number of useful views on the )(%F table# the chief ones being %B)9)(%4T9TR)4'
and %B)9)(%4T9!*!!4"/.
Reviewing audit records regularly is a good practice. /ote that "racle does not
delete old audit data automaticallythat is the responsibility of the database
administrator. Eou should consider archiving the data using the *@& or *@&%B
utilities before you delete it.
ser Manage!ent
The security of the database is the responsibility of the database administrator.
!imple security rulesB
&assword should be changed regularly using &)!!-"R%9'43*9T4$*#
&)!!-"R%9 R*(!* 9T4$* and &)!!-"R%9R*(!*9$)@ settings in the
%*3)('T profile
!hared passwords should be changed when an employee relieved of his or
her responsibilities or leaves the company. 3or example# database
administrators typically share the passwords to the !E! and !E!T*$
accounts. These passwords should be changed whenever a database
administrator leaves the organiational group or the company.
(sers should be required to have strong passwords7 this should not be
required by default.
*xecute the (T'&-%$6.!A' script from the !E! account to enforce the
requirement.
-hen a user1s 2ob responsibilities change# their database privileges should be
changed appropriately. -hen a user leaves the organiation# their account
should be removed from the database.
"apacit# Manage!ent
Regular capacity reviews are part of good database management. %atabase sie
and free space should be recorded at regular intervalsthe required information can
be found in the %B)9%)T)934'*! and %B)93R**9!&)C* views. 6rowth
pro2ections should be made and opportunities to reclaim disk space should be
identified. Capacity management also refers to utiliation of system resources such
as C&( and memory. The information in the !T)T!&)C8 reports and tables can be
used to track system utiliation or you can develop a simple system that periodically
captures system utiliation metrics from the 5F!E!!T)T table.
Ti!e Series
) time series is a sequence of measurements made at periodic intervals. The
!T)T!&)C8 tables contain much time series data and can be used for capacity
reviews. The !T)T!&)C8 tables !T)!F"!!T)T# !T)!F!E!!T)T#
!T)T!F!E!T*$9*5*/T and !T)T!F!E!9T4$*9$"%*' are of particular interest
they store snapshots of the dynamic performance views 5F"!!T)T# 5F!E!!T)T#
5F!E!T*$9*5*/T# and 5F!E!9T4$*9$"%*' respectively.
Patching
"racle periodically releases fixes# known as patches# for software bugs. ) one- off
patch is a fix for an individual bug# while a patchset is a collection of numerous bug
fixes. ) critical patch update +C&(, is a collection of fixes for security0 related bugs7
"racle releases one such C&( every quarter. ) patchset has an "racle database
version string associated with it7 for example# :>.<.>.= is a patchset associated with
"racle :>g Release <. By contrast# one0 off patches and C&(s are identified by a
single number7 for example# G<:>:H; is the number of the ?uly <>>I C&(. "ne0 off
patches# patches# and patchsets can be downloaded from the &atches J (pdates
section of the $etalink customer portal.

You might also like