Backup and recovery concepts

A backup of a database is a database copy, together with control information,

ready to be restored in the event of a failure. A database backup minimizes data
loss and gives you the ability to reconstruct the failed database from the backup
copy using the recovery process.
There are many types of failure that cause a database to need recovery. However,
not all types of failure require human interaction. Here are various types of
failures that you may encounter:
Statement failures

A statement failure occurs when there is a logic misstep in an application.

This failure could have a number of different causes, for example a
statement running in an infinite loop, a user not having the correct
privleges needed to perform a certain task (causing a valid statement to
fail) or insert failure due to running out of space.
In Oracle, statement failures usually don't require an administrator, except
to perform minimal tasks such as adding more disk space, fixing the
application logic, or assigning proper user privileges. In DB2 UDB,
statement failures are handled similarly. An administrator is not needed to
solve a statement failure in terms of backup and recovery.
User errors

Valid yet destructive statements such as deleting an entire payroll table,

dropping a claims table or even inadvertently dropping an entire database
can cause extended down time for your database applications. You will
need more than proper education and guidance in order to avoid these
errors. Data definition language (DDL) statements are not statements that
can be rolled back. So if a user error has involved DDL, proper measures
will need to be taken to bring back your database.
For example, if a table is mistakenly dropped, as an administrator you
have two choices. You can either use a copy of your backup image and roll
it forward to the time right before the table was dropped (point-in-time
recovery), or you can restore a logical backup through the exp utility. Both
options could potentially result in lost data.
When a user drops a table in DB2 UDB, you can either do a database level
point-in-time recovery, rolling forward to the point before the table is
dropped; or, better still, use a table space level roll forward operation.
That way, you do not have to bring the database down, and data is still
accessible to your users. We shall see this in the scenario section.
Process failures
Failure of user, server or background processes is due to abnormal
termination or disconnection from these processes. A failed process will
cause a task to be unable to continue.
For a process failure on Oracle, no human intervention is required, as the
Oracle PMON background process will periodically monitor for these
aborted processes. For user and server processes, PMON will release the
locks held by users, roll back every uncommitted transaction, and release
any resources this process is using. If an Oracle background process is
aborted, often a restart of the instance is required.
On DB2 UDB, process failures such as a dead db2agent will cause a crash
recovery. In crash recovery, transactions that are not committed will be
rolled back while committed data will be flushed to disk. To enable this
automatic crash recovery feature, verify that the database configuration
parameter autorestart is set to ON. By default, autorestart is ON.

Database instance failures

A database instance failure is typically caused by an operating system

crash or a power outage.
When the database instance fails on Oracle, there is no need for human
intervention as the Oracle SMON background process will detect the
problem as soon as you restart your machine. SMON will initiate the
instance recovery.
In DB2, when database manager and memory structures go down due to
power failure, disk corruption or network failure, crash recovery will be
needed to recover DB2 to a consistent and usable state. To enable this
automatic crash recovery feature, verify that the database configuration
parameter autorestart is set to ON. By default, autorestart is ON. You can
also issue the command RESTART DATABASE to manually restart the
database. The RESTART DATABASE command uses active logs to roll back
changes that are not yet committed. Changes that are already committed
but not yet flushed to disk will be flushed to disk.
Media failure

Media failure occurs when someone accidentally deletes a database file

from the file system, the entire hard disk goes down with its data files,
causing data to be inaccessible, or just pure data corruption. This is a
more severe kind of failure than the types we've already discussed.
In Oracle, media failure does require an administrator to recover. Usually
media failure is caused by either the complete loss of a data file or an SCN
timestamp being out of sync with the rest of the database. Recovery from
this kind of failure varies from one situation to the other, primarily
depending on the mode of archive and the data files that have been
corrupted.
These failures are handled much the same way in DB2 UDB and Oracle, by
restoring either offline or online backups and using roll forward operations
to recover the logs.
Because media failure is the most complex of all the types of failure, you must
have a well thought-out strategy to plan for it. The rest of the article will be
devoted to planning for and recovering from this last form of failure.

Back to top
Data
structures
used for
backup and
recovery
Oracle and
DB2 UDB both
have a set of
components to
make up the
backup and
recovery
mechanism.
The
architecture
diagrams you
see in Figure 1
and Figure 2
are overviews
of the primary
components
used to
provide the
backup and
recovery for
Oracle and
DB2.
Figure 1.
Oracle
architecture

Oracle
memory
structure
Buffer
Cache

Memor
y
allocate
d for
storing
data
blocks
read
from
physica
l data
files.
Shared
Pool
Memor
y
allocate
d for
storing
parsed
SQL
statem
ents,
PL/SQL
proced
ures
and
data
dictiona
ry
informa
tion.
Log
Buffer

Memor
y
allocate
d for
storing
before
and
after
image
of
change
d data.
The
entry is
sequen
tial.
Large

Back to top