Database Administration:

The Complete Guide to Practices and Procedures

Chapter 16
Database Backup and Recovery
Agenda
• The Importance of Backup & Recovery
• Preparing for Problems
• Image Copy Backups
• Recovery
• Alternatives to Backup and Recovery
• Questions

The Importance of Backup & Recovery

• Many DBAs believe that ensuring optimal database and application performance
is the
most important part of their job…
– But it is not true.
– These DBAs are confusing frequency with importance.
• Recoverability should be at (or near) the very top of the DBA task list, definitely
before Performance.
– If you cannot recover your databases after a problem then it won’t matter how
fast you can access them.
– Anybody can deliver fast access to the wrong information (or an empty file).

Preparing for Problems

• it is wise to take precautionary measures to prevent failures. Techniques such as
• UPS systems,
• mirrored disks,
• and failover technology
can minimize the need to recover, but no amount of planning and regulation can
prevent unexpected failures.

Database failures that might need recovery can be divided into 3

• Instance failures
– The result of an internal exception within the DBMS, an operating system
failure, or other software-related database failure.
In some cases, an instance failure can result in corruption of data that requires a
recovery, but usually such failures do not damage data, so the DBMS simply
needs to be restarted to reestablish normal operations.
• Application (or transaction) failures
– When programs or scripts are run at the wrong time, using the wrong input, or
in the wrong order. An application failure usually results in corrupt data that
requires a database restore or recovery. The sooner an application failure is
identified and corrected, the smaller the amount of damage.
• Media failure
• Includes damage to disk storage devices, file system failures, tape
degradation or damage, and deleted data files. Although less common in
practice, damaged memory chips also can cause data corruption. After a
media failure, the database will likely be in a state where valid data is
unreadable, invalid data is readable, or referential integrity is violated.
• Outages due to media failures can often be avoided by implementing
modern disk technologies such as RAID

Backup Plan = Insurance

• It is common for organizations to manage a terabyte or more of data on a single
database server.
• A sound backup and recovery plan can be thought of as an insurance policy for
your data.

Image Copy Backups 7-53

• A fundamental component of a database backup and recovery plan is creating
backup copies of data.
• When an error occurs that damages the integrity of the database, a backup copy
of the data can be used as the basis to recover or restore the database.
• However, the full story on backing up a database is not quite that simple.
Image Copies
In
• Backing up databases involves making consistent copies of your data, usually in
the form of image copies, which are the output of a COPY utility.
• The name of the copy utility will vary from DBMS to DBMS. Common names for
the backup utility include
BACKUP, COPY, DUMP, and EXPORT.
• Some DBMSs rely on the native operating system’s file system commands for
backing up data. However, even if the DBMS supplies an internal backup option,
the DBA may choose to use facilities that operate outside the realm of the DBMS.
Assuring Accuracy
• Current and accurate image copies provide the foundation for database
recovery.
• The DBA must assure the currency and accuracy of the image copies and base
the backup plan on the recovery needs of the applications.
• The DBA will use those recovery requirements to determine how often to take
image copy backups and how many backup generations must be kept on hand.
– The DBA also must make sure that the appropriate log records are available or
backed up for recovery purposes.
Factors Influencing Duration of Recovery
• The number of log records that must be processed to recover.
• Whether the log is compacted or compressed
• Whether the image copy backup is encrypted or compressed
• The time it takes an operator to mount and dismount the required tapes
• The time it takes to read the part of the log needed for recovery
• The time needed to reprocess changed pages

Additional Factors
• DBMS Architecture
• Activity During Image Copy Process
– Read Only
– Read/Write
• Balancing Duration of Recovery Against the Time Required to Take Image Copy
Additional Factors
• Additionally, recovery duration depends on the architecture of the DBMS.
For example, mainframe DB2 keeps track of log range information and reads only
the required log files for any recovery operation. However, some DBMSs require
that all the log files be read to scan for information needed for recovery.
• Keep in mind that database backups taken while there is read-only activity,
or no activity, can be restored back to that point in time using only the
backup—no log files are required. This can simplify and minimize the cost
of a recovery.
• In general, the more often you make an image copy, the less time recovery takes
(less log files in between which leads to faster recovery). However, the amount of
time required to make an image copy backup must be balanced against the need
for concurrent processing during the backup process.
How Many Backups?
• The DBA must decide how many complete generations of backups (for both
database object copies and log copies) to keep.
• Keeping extra generations can help you recover from a media failure during
recovery by switching to an older backup.
– At a minimum, the retention period should be at least two full cycles.
– The number of copies you decide to keep must be tempered by the number of
associated logs that must also be maintained for the backups to remain viable

1.
Full vs. Incremental
• A full image copy backup is a complete copy of all the data in the database
object at the time the image copy was run.
• An incremental image copy backup (aka differential backup) contains only the
data that has changed since the last full or incremental image copy was made.
– The advantage of taking an incremental rather than a full backup is that it
can sometimes be made more quickly, and requires less space on disk (or
tape).
– The disadvantage is that recovery based on incremental copies can take
longer because, in some cases, the same row is updated several times
before the last changes are restored.
• For example, suppose you took a full image copy of a database object early
Monday morning at 2:00 A.M. and then took an incremental image copy at the
same time the following three mornings. The full image copy plus all three
incremental image copies need to be applied to recover the tablespace. If the
same column of the same row was updated on Tuesday to "A", Wednesday to
"B", and Thursday to "C", the recovery process would have to apply these three
changes before arriving at the final, accurate data. If a full image copy were taken
each night, the recovery process would only need to apply the latest image copy
backup, which would contain the correct value.
Incremental Versus Full Image Copy Backups
• Favor full image copies for small database objects.
– The definition of “small” will vary from site to site and DBMS to DBMS.
 • Consider using incremental image copies to reduce the batch processing
window for very large database objects that are minimally modified in
between image copy backups.
– The DBA should base the full-versus-incremental decision on the
percentage of blocks of data that have been modified, not on the
number of rows that have been modified.
• Some scenarios are not compatible with incremental image copy backups.
– Some DBMSs permit the user to disable logging during some operations
and utilities. Whenever an action is taken that adds or changes data
without logging, a full image copy is required.
• Some DBMSs provide the capability to analyze a database object to
determine if a full or incremental backup is recommended or required.
• This is typically accomplished using an option of the copy utility. If such an
option exists, the DBA can run the copy utility to examine the amount of
data that has changed since the last image copy backup was taken.
Furthermore, the DBA can set a threshold such that a full image copy is
taken when more than a specified amount of data has changed; an
incremental image copy is taken when the amount of data that has
changed is less than the threshold
• Some DBMSs permit the user to disable logging during some operations
and utilities. Whenever an action is taken that adds or changes data
without logging, a full image copy is required.
Merging Incremental Image Copies
• A merge utility, sometimes referred to as MERGECOPY, can be used to combine
multiple incremental image copy backups into a single incremental copy backup,
or to combine a full image copy backup with one or more incremental image copy
backups to create a new full backup.
• If your DBMS supports merging incremental copies, consider running the merge
utility to create a new full image copy directly after the creation of an incremental
copy.
• If you wait until recovery is required to run the merge, downtime will be
increased because the merge (or similar processing) will occur during the recovery
process while the database object is unavailable.

Database Objects and Backups

• Typically, an image copy backup is made at the database, tablespace, or table
level.
• The level(s) supported will depend on the DBMS being used.
• In general, though, the idea is to back up the database object or objects that
contain the data
The more granular control the Dbms provides for backup of database objects, the
easier it will be to effectively implement a useful backup and recovery strategy.

Copying Indexes
• Some DBMSs support making backup copies of indexes.
– Indeed, some DBMSs require indexes to be backed up,
whereas index backup is optional for others.
– Index backup can be optional because the DBMS can
rebuild an index from the table data.
• You will need to examine the trade-offs of copying
indexes.
• Be sure to perform data and index backups at the same
time if you choose to back up rather than rebuild your
indexes.
– Failure to do so can result in indexes that do not match the
recovered data• As a DBA, though, you will need to examine the trade-
offs of copying indexes if your DBMS supports index
backup. The question DBAs must answer for each index
is "Rebuild or recover?" The more data that must be
indexed, the longer an index rebuild will require in a
recovery situation. For larger tables, backing up the
index can result in a much quicker recovery—although
at the expense of the increased time required for
backup. When multiple indexes exist on the large table,
backing them up, again, leads to faster recovery.
However, keep in mind that index backups will require
additional time to execute during your regular backup
process.
DBMS Control
• The degree of control the DBMS asserts over the backup
and recovery process differs from DBMS to DBMS.
– Some DBMSs record backup and recovery information in the
system catalog.
– That information is then used by the recovery process to
determine the logs, log backups, and database backups required
for a successful recovery.
• The more information the DBMS maintains about image
copy backups, the more the DBMS can control proper usage
during recovery.
• If your DBMS does not record backup and recovery
information in the system catalog then the DBA must track
image copy backup files and assure their proper usage
during a recovery.
The DB2 COPY Utility
• The COPY utility is used by DB2 for OS/390 to create image copy
backups. This utility maintains a catalog of image copy information
in the system catalog. Every successful execution of the COPY utility
causes DB2 to record information in the system catalog indicating
the status of the image copy, the image copy data set name and file
details, the date and time of the backup, and log information. This
information is read by the DB2 RECOVER utility to enable
automated tablespace and index recovery. Only valid image copies,
recorded in the system catalog, can be used by DB2 for recovery.
• As time passes, image copy backups become obsolete. New backup
copies are made and database objects are recovered to various
points in time. The DB2 DBA must maintain the information in the
system catalog because outdated and unnecessary backup rows in
the system catalog can slow down the recovery process. Backup
information in the system catalog is removed by the DBA using the
DB2 MODIFY utility.
RMAN
• Oracle provides a comprehensive method for
managing backup and recovery called RMAN.
RMAN, which stands for Recovery Manager, is
a utility that establishes a connection with a
server session and manages the data
movement for backup and recovery
operations.
Using Oracle RMAN for Backup and Recovery
• RMAN is a powerful program for managing the backup and recovery of Oracle
data.
The DBA can use RMAN to specify files or archived logs to be backed up using the
RMAN BACKUP command. Doing so causes RMAN to create a backup set as
output.
A backup set is one or more data files, control files, or archived redo logs that are
written by RMAN in proprietary format. The only way to recover using the backup
set is to use the RMAN RESTORE command. Of course, the DBA can choose to use
the COPY command instead. This creates an image copy of a file that is usable
outside the scope of RMAN.
• RMAN accesses backup and recovery information from either the control file or
the optional recovery catalog. The recovery catalog is similar to the DBMS system
catalog, but it contains only backup and recovery metadata.
• RMAN generally is preferable to other Oracle backup and recovery methods
because it is easier to use and more functional. For example, RMAN provide the
ability to create incremental backups. Only full image copy backups are available
when using traditional Oracle backup and recovery methods.
Concurrent Access Issues
• Concurrent write access allows you to keep the data online during
the backup process, but it will slow down any subsequent recovery
because the DBMS has to examine the database log to ensure
accurate recovery.
• Change accumulation creates an up-to-date image copy backup by
merging existing image copies with data from the database logs.
This is similar to the merging of incremental image copies.
• Some image copy backup techniques allow only read access to the
database object. Backups that allow only read access provide faster
recovery than those that allow concurrent read-write because the
database log is not needed to ensure a proper recovery.
– However, they are more disruptive to normal processing.
• Some image copy backup techniques require the database object to
be stopped, or completely offline. This type of copy provides fast
backup because there is no contention for the tablespace.
– This is even more disruptive to normal application processing.
Backup Planning Considerations
• The need for concurrent access and
modification during the backup process
• The amount of time available for the backup
process and the impact of concurrent access
on the speed of backing up data
• The speed of the recovery utilities
• The need for access to the database logs
• The difference between a hot backup and cold
backup.
Hot vs. Cold Backup
• A cold backup is accomplished by shutting down the
database instance and backing up the relevant database
files.
• A hot backup is performed while the database instance
remains online, meaning that concurrent access is possible.
• Depending on the capabilities of the DBMS you are using,
hot backups can be problematic because:
– They can be more complex to implement.
– They can cause additional overhead in the form of higher CPU,
additional I/O, and the additional database log archivals.
– They can require the DBA to create site-specific scripts to
perform the hot backup.
– They require extensive testing to ensure that the backups are
viable for recovery.
Backup Consistency
• Be sure your backup plan creates a consistent recovery
point for the database object.
– You need to be aware of all relationships between the
database objects being backed up and other database
objects including:
• Application-enforced relationships
• Referential constraints
• Triggers
• If you use an image copy backup to recover a database
object to a previous point in time, you will need to
recover any related database objects to the same point
in time.
– Failure to do so will most likely result in inconsistent data.
Quiesce
• If your DBMS provides a QUIESCE utility:
– Use it to establish a point of consistency for all related database
objects prior to backing them up.
– QUIESCE halts modification requests to the database objects to
ensure consistency and record the point of consistency on the
database log.
• If the DBMS does not provide a QUIESCE option:
– You will need to take other steps to ensure a consistent point for
recovery.
– For example, you can place the database objects into a read-
only mode, take the database objects offline, or halt application
processes—at least those application processes that update the
related database objects.
• Some recovery options/products can find quiet points without
requiring quiesce points during backup.
When to Create a Point of Consistency
• The DBA should create a point of consistency
during daily processing.
– Before archiving the active log.
– Before copying related database objects.
– Just after creating an image copy backup.
– Just before heavy database modification.
– During quiet times.
Log Archiving and Backup
• All database changes are logged by the DBMS to a log file
commonly called the transaction log or database log.
– Log records are written for every SQL INSERT, UPDATE, and DELETE
statement that is successfully executed and committed.
• The database log to which records are currently being written is
referred to as the active log. As the number of database changes
grows, the database log will increase in size.
– When the active database log is filled, the DBMS invokes a process
known as log archival or log offloading.
– When a database log is archived, the current active log information is
moved offline to an archived log file, and the active log is reset.
• The DBA typically controls the frequency of the log archival process
by using a DBMS configuration parameter.
– Most DBMSs also provide a command to allow the DBA to manually
request a log archival process.
– And remember, each DBMS performs log archival and backup
differently.
Determining Your Backup Schedule
Not all data is created equal.
• How much daily activity occurs against the data?
• How often does the data change?
• How critical is the data to the business?
• Can the data be recreated easily?
• What kind of access do the users need?
– Is 24/7 access required?
• What is the cost of not having the data available
during a recovery?
– What is the dollar value associated with each minute of
downtime?Volatility of the data
Static
Dynamic
4
2
3
1
Criticality and Volatility Grading

• Quadrant 1 on the grid identifies the

critical/dynamic data in the organization. This
data is crucial to your business and it changes
rapidly. As such, you must be able to recover it
quickly, so you should copy it frequently. As a
rule of thumb, the data should be backed up
at least on a daily basis. If more than 20% of
the data changes daily, be sure to make full
rather than incremental backups.

• Quadrant 2 represents critical but static data.

Even though the data changes little from day
to day, you will need to recover the data
promptly in the event of an error because it is
critical to the business. Be sure to back up this
data at least weekly. Consider using
incremental backups that are merged
immediately upon completion to minimize the
work required during a recovery.

• Quadrant 3 represents volatile data that is not as vital

to your business. You may be able to recreate the data
if it becomes corrupted. Depending on the amount of
data and the volume of change, you might not even
back it up at all. For small amounts of data, a printed
report may suffice as a backup. If the data fails, you
could simply reenter it from the printed report.
Alternatively, if data is recreated nightly in a batch job,
you could simply run the batch job to refresh the data.
As a DBA, you will need to ensure that the data can be
recreated or copied on a regular basis. In general, more
than a weekly backup for quadrant-3 data is likely to be
overkill.
• Quadrant 4 represents static, noncritical data.
Such data does not change much and can be
replaced easily. It is the least important data
and should be addressed only when data in
the other three quadrants have been
adequately backed up. In fact, quadrant-4 data
may never need to be backed up—the DBA
could take a similar approach to that
described for quadrant 3.
DBMS Instance Backup
• In addition to being prepared for failure of individual
database objects, the DBA must be prepared to recover
from failure of the entire DBMS instance or subsystem.
• Be sure to back up all of the crucial components of the
database instance, including:
– DBMS files
– System catalog and directory objects
– Database (archive) logs
– Configuration and setup files
– System libraries
– Tape management libraries
– Program source libraries and executable libraries.
• Again, each DBMS and platform will have different key
components that must be dealt with when planning a
recovery strategy for the DBMS instance.• Recovering an entire DBMS instance is
relatively
rare, but it is not something that can be ignored.
• In certain dire situations, you may need to resort
to the original installation media in order to
recover a DBMS component. Of course, when
restoring from the original media you may lose
any subsequent bug fixes that were applied.
• Therefore, the recovery process would include
reapplying the maintenance as supplied by the
DBMS vendor.• Furthermore, always reread the manuals
before attempting DBMS instance recovery,
and never attempt to recover the DBMS
instance without thoroughly understanding
the reason for recovering.
Alternate Approaches to Database Backup
• Using Database Exports to Create Logical Backups
– Logical backups (explained later)
• Using Storage Management Software to Make Backup Copies
• When using storage management software to back up database
objects outside the scope of DBMS control, be sure to disable
database write operations for all database objects that are being
backed up.
• To accomplish this, use the DBMS commands to stop the database
objects, or start them in read-only mode.
• Once database modification operations have been suspended, the
storage management software can be used to back up the database
objects. When the backup is complete, use the DBMS commands to
restart the database objects in read/write mode.• Be sure you fully understand
both the functionality of
the storage management software and the DBMS. For
example, some storage management software will not
copy open files. However, files containing database
data will be open if the DBMS is using them. Failing to
understand such details can result in missing backups
and unrecoverable data.
• Additionally, when recovery is required, the storage
management software should be used instead of
DBMS utilities or commands. The backups were made
by the storage management software and will likely be
in a format that is usable only by the same software.
Using Database Exports to Create Logical Backups
• An alternate approach to database recovery is
to create an export, or unload, of the data
stored in the database object. Sometimes the
process of backing up just the data, and not
the entire physical file, is referred to as a
logical backup
Logical backup
• Object or row recovery. If someone inadvertently drops
a table or deletes a few rows from a table, restoring
them from a physical backup may be difficult. With a
logical backup, the missing data is simply reloaded to
the table.
• • DBMS release upgrade. Sometimes the DBMS vendor
changes the underlying database structures for a
release migration. When this occurs, it can be useful to
have logical backups that can be imported into the new
version, instead of trying to convert existing
structures—data and all—to the new format.

• Heterogeneous database migration. Physical data

structures differ between different platforms, even when
the same DBMS is being used. For example, an Oracle
database on OS/390 will use different physical file
structures than the same Oracle database implemented on
Windows NT. Logical backups can be used to facilitate the
movement of data between different databases on
different platforms.
• • Data movement. Data, once created in the database, will
be shifted and moved all over the organization—perhaps to
different DBMSs, perhaps to flat files, perhaps to
spreadsheets.
• A logical backup, because it is just the data, can make it
easier to move that data wherever it needs to be,
whenever it must be there.

• A logical backup is performed with the database up

and running, so the only impact on performance will
be the possible concurrent access to data by
transactions and other production programs.
• However, as a DBA you must keep the data integrity of
the logical backup in mind.
• Although the DBMS will use its locking mechanism to
assure consistent data, referential integrity will not be
guaranteed unless efforts are made to quiesce
concurrent activity during the data export process
Document Your Backup Strategy
• Thoroughly document and test the backup and recovery
strategy, implementation, and procedures.
• Test recovery from:
– media failure
– an instance failure
– and several types of application failures.
• Document the type of backup taken for each database
object, along with a schedule of when each is backed up.
• Be sure that all of your databases can be recovered and
that all DBAs on-site have firsthand experience at database
recovery.
• The DBA group should schedule periodic evaluations of the
backup and recovery plans for every production database.

Recovery
• Database recovery can be a very complex task.
• Recovery involves much more than simply restoring an image
of the data as it appeared at some earlier point in time.
• A database recovery involves bringing the data back to its
state at (or before) the time of the problem.
– Often a recovery involves restoring databases and then reapplying the
correct changes that occurred to that database, in the correct
sequence.
• Simply stated, a successful recovery is one where you get the
application data to the state you want it—whether that state
is how it was last week, yesterday, or just a moment ago.
– If you planned your backup strategy appropriately, you should be able
to recover from just about any type of failure you encounter.
Determining Recovery Options
• What type of failure has occurred:
media, transaction, or database
instance?
• What is the cause of the failure?
• How did the database go down: abort,
crash, normal shutdown?
• Did any operating system errors occur?
• Was the server rebooted?
• Are there any errors in the operating
system log?
• Are there any errors in the alert log?
• Was a dump produced?
• Were any trace files generated?
• How critical is the lost data?
• Have you attempted any kind of
recovery so far? If so, what steps have
already been performed?
• What types of backups exist: full,
incremental, both?
• What needs to be recovered: the full
database, a tablespace, a single table,
an index, or combinations thereof?
• Does your backup strategy support the
type of recovery required (recover-to-
current vs. point-in-time)?
• If you have cold backups, how was the
database shut down when the cold
backups were taken?
• Are all of the archived database logs
available for recovery?
• Do you have recent logical backup
(EXPORT or UNLOAD)?
• What concurrent activities were
running when the system crashed?
• Can you bring the DBMS instance up?
• Can you access the database objects?
• What are your system availability
requirements?
• How much data must be recovered?
• Are you using raw files?
DBMS Version Migration and Recovery
• DBMS version migration can impact recoverability.
• Sometimes the DBMS vendors change the format of
image copy backup files, rendering any backups using
the old format unusable. The same could be true for
the log file—the format may have changed for a new
version, rendering
– Depending on the DBMS and the particulars of the new
version, a backup taken in a prior release may not be
usable for recovery after migration.
– Alternately, a backup taken after migration that is trying to
be used after falling back to an older version of the DBMS
also may not be usable for recovery.
General Steps for Database Object Recovery
At the very basic level, every database recovery will
involve most of these seven steps:
1. Identify the failure.
2. Analyze the situation.
3. Determine what needs to be recovered.
4. Identify dependencies between the database
objects to be recovered.
5. Locate the required image copy backup(s).
6. Restore the image copy backup(s).
7. Roll forward through the database log(s).
Types of Recovery
• Recovery to Current
• Point-in-Time (PiT) Recovery
• Transaction Recovery
Recovery to Current
• To successfully recover to current, the recovery process must be
able to reset the contents of the database to the way it looked just
at (or right before) the point of failure. To recover to current, the
recovery process must find a valid, full image copy backup and
restore that image copy. Then the recovery will roll forward through
the database log, applying all of the database changes.
• If the last full image copy is lost or destroyed, it may still be possible
to recover if a previous image copy exists. The recovery process
could start with the older backup copy, apply any incremental
copies, and then roll forward through the archived and active logs.
Of course, more database logs will be required in such a case, so
the recovery process will take longer.
• If no image copy is available as a starting point, it may be possible
to recover the database object using just the database log. If the
data was loaded and the load process was logged, recovery may be
able to proceed simply by applying log records.

PIT recovery
• Another traditional type of recovery is point-in-time (PIT)
recovery, which is usually done to deal with an application-
level problem. PIT recovery is sometimes referred to as
partial recovery because only part of the existing data will
remain after recovery. Recovery to a point in time removes
the effects of all transactions that have occurred since that
specified point in time.
• To perform a PIT recovery, an image copy backup is
restored and then changes are applied by rolling forward
through the database log (or log backups). However, only
the log records up to the specified time are processed.
Sometimes the recovery point is specified as an actual date
and time; sometimes it is specified using a relative byte
address on the database log.

Transaction Recovery
• Transaction recovery is a third type of
recovery; it addresses the shortcomings of the
traditional types of recovery: downtime and
loss of good data. Thus, transaction recovery is
an application recovery whereby the effects of
specific transactions during a specified
timeframe are removed from the database.
Third-party software is required to perform a
transaction recovery .
• Traditional types of recovery, both recovery to
current and PIT, recover at the database object
level. In direct contrast to this level of granularity,
transaction recovery allows a user to recover a
specific portion of the database based on user-
defined criteria. This can be at a transaction or
application program level. In this context, a
transaction is defined by the user's view of the
process.
• The important point is that there may or may not
be a correlation between the transactions you
are trying to fix and transactions (or units of
recovery) in the DBMS.
• Examples of user-level transaction definitions
might be
– All database updates performed by a userid since
last Wednesday at 11:50 A.M.
– All database deletes performed by the application
program named PAYROLL since 8:00 P.M. yesterday.Transaction recovery
• Once you have identified the transaction to recover,
you have three recovery options:
• PIT recovery. You can try to identify all of the database
objects impacted by the application and perform
traditional point-in-time recovery to remove the effects
of the transactions. You would then manually rerun or
reenter work that was valid.
• UNDO recovery. Remove only the effects of the bad
transactions.
• REDO recovery. Remove all the transactions after a
given point in time, and then redo the good
transactions only.Transaction recovery
• Let's first examine an UNDO recovery. UNDO recovery is the
simplest version of SQL-based transaction recovery because
it involves only SQL. To accomplish an UNDO recovery, the
database logs must be scanned for the identified
transaction and anti-SQL is produced. Anti-SQL reverses the
affect of SQL by
• Converting inserts into deletes
• Converting deletes into inserts
• • Reversing the values of updates (e.g., UPDATE "A" to "X"
becomes UPDATE "X" to "A")
• However, certain applications may need to be brought
down for the duration of the UNDO recovery to eliminate
the potential for data anomalies causing additional failures.UNDO SQL,
generated from the database log,
can be used to get rid of bad transactions. And
the database can remain online.
Apply UNDO SQL
Bad Transaction
Good Transaction 1
Generate UNDO SQL
UNDO Bad Transactions
Good Transaction 2
Recovery started
UNDO Transaction Recovery

• A REDO recovery is a combination of PIT recovery and

UNDO recovery, with a twist. Instead of generating SQL for
the bad transaction that we want to eliminate, we generate
the SQL for the transactions we want to save. Then we do a
standard point-in-time recovery to eliminate all the
transactions since the recovery point. Finally, we reapply
the good transactions captured in the first step.
• Unlike the UNDO process, which creates SQL statements
designed to back out all of the problem transactions, the
REDO process creates SQL statements that are designed to
reapply only the valid transactions from a consistent point
in time. Since the REDO process does not generate SQL for
the problem transactions, performing a recovery and then
executing the REDO SQL can restore the database object to
a current state that does not include the problem
transactions.

• When redoing transactions in an environment where availability is crucial,

1. Perform a recovery to a point in time.
2. Bring the application and database online.
3. Redo the subsequent valid transactions to complete the recovery This
step must be done while the database is online for concurrent read/write
operations.
• If your approach to backup and recovery is to use storage management
software, individual image copy backups for database objects will not exist.
In this case, you will need to deploy storage management software to
perform the recovery. The actual recovery process will depend on the type
of storage management software in use, as well as how (or if) it interacts
with the DBMS recovery mechanisms.
• Off-site disaster recovery is the rarest, but most comprehensive, type of
database recovery. An off-site disaster recovery is required when a natural
disaster (fire, flood, etc.) or other severe accident makes it impossible to
use your primary data processing center. In this case, you need to
reestablish your entire system environment, as well as recover your DBMS,
database objects, and dataYou can perform a point in time recovery and then
re-apply
good transactions using REDO SQL. The database is briefly
offline during the PIT recovery, then back online.
Matching Type of Failure to Type of Recovery
• Match the type of failure to the appropriate type of recovery.
– Recovering from a media failure usually involves a recover
to current.
– Recovering from a transaction failure usually involves a
point-in-time recovery or a transaction recovery.
– Recovering from a database
instance or subsystem
failure will most likely involve
a recover to current.
Index Recovery
There are two options for index recovery:
• Rebuilding the index from the table data, or
• Recovering the index from a backup copy of the
index itself.
Testing Your Recovery Plan
• You should develop a recovery plan and test it often
(ideally no less than twice per year).
• To develop your recovery plan:
– Write all aspects of the recovery plan out in detail,
documenting each step.
– Include all the scripts required to back up and recover each
database object.
– Review the plan with everyone who may be called on to
implement it.
– Include a contact list with names and phone numbers of
everyone who may be involved in the recovery.
– Keep the recovery plan up-to-date by modifying the plan
to include every new database object that is created.
Recovering a Dropped Database Object
• Recovering a dropped object requires extra steps beyond a
normal recovery.
• Depending on the DBMS and the tools available, it can
sometimes be very complicated.
• Each DBMS identifies the database objects under its control
by an internal identifier.
– When an object is dropped and recreated, the internal identifier
for that object usually will change.
– Therefore, recreating the object using the same DDL and
running a recovery using a prior image copy backup usually will
not work.
• To recover a dropped database object, the DBA may need
to translate the internal identifier of the old database
object to the internal identifier of the new database object.
Recovering Broken Blocks and Pages
• A broken block or page is a section of a tablespace or index that
contains bad or inconsistent data.
– Data may be inconsistent due to a broken or orphaned chain,
referential constraint violations, a damaged recovery log, a missing or
extra index entry, or some other arcane problem.
• To recover an index with a broken page you can simply rebuild the
index from the data in the tablespace.
• Tablespaces are a different proposition.
– Sometimes simply stopping and starting the tablespace or recycling
the DBMS instance can fix a broken page.
– Some DBMSs come with a repair utility that can be used to pinpoint
locations within a file based on offsets and replace data at the bit or
byte level.
• Before using any such repair tool, be sure to completely read the DBMS
instruction manuals.
• Repair utilities can be invasive and damaging to the contents of the database.
– Once you have repaired the information, you may need to recover the
tablespace to current.

Alternatives to Backup & Recovery -

• Standby Databases
• Replication
– Snapshot replication
– Symmetric replication
• Disk Mirroring
These technologies do not completely replace the need
to backup and recovery your database objects. They can
be used to augment your database recovery planning.
Standby Databases
• A standby database is an identical copy of an online production
database that is close to being up-to-date in terms of its data
content. The standby database may not be 100% up-to-date
because of system latency between applying updates from the
online production database to the standby database. When a failure
occurs, control is transferred to the standby database, which is then
opened as the online production database to allow normal activity
to continue.
• Usually, a standby database is created initially by restoring a cold
backup. Then, all the archive logs from the production database
must be copied to the standby database and applied. For all intents
and purposes, the standby database is continuously running in
recovery mode because it is applying the archive logs from the
production database as operations are performed on the
production database.
Replication
• Data replication involves storing and maintaining
redundant data in a separate copy of the
database. Of course, replicated data can be a
subset of the rows and/or columns of the original
database. A simple form of replication can be
implemented simply by copying entire tables to
multiple locations at various times throughout
the day. Of course, this is easier said than done.
Some DBMSs provide automated replication
features, and for those DBMSs without such
features, third-party tools are available.
Snapshot replication
• produces a copy of database tables on a target system
based on a query of the source database. At the time a
snapshot is initially taken, the specified query (maybe an
entire table) is run, and the resulting data is loaded into the
target snapshot table. Furthermore, each replica database
should contain accurate, up-to-date information. When
multiple replicas exist, the DBA must facilitate the update
of all replicated copies at the same time. If replicas are
updated on different schedules, it becomes burdensome to
keep track of the state of each replica.
• The advantage of snapshot replication is its ease of
implementation. However, snapshot replicas can become
out-of-date very rapidly, and refreshing the replica can
cause administrative and performance problems.
Symmetric replication
• is a more robust implementation of replication
because it keeps the replicas up-to-date.
Symmetric replication can be set up to ensure
that no transaction is fully committed until all the
modifications have been committed locally for all
replicas. Alternatively, it can replicate
asynchronously, allowing each database node to
run at full speed without holding up local updates
because of remote database speed issues. The
updates are applied later, after the COMMIT is
taken for the master database.• The biggest advantage of symmetric replication
over
snapshot replication is the automatic synchronization
of modifications from the master database to the
replicas. However, symmetric replication is more
difficult to set up and administer, high transaction
volumes can cause performance degradation, and a
network failure can cause the database to fail because
modifications cannot be synchronized.
• Replication is not a substitute for backup and recovery,
but it can be helpful in some situations. With snapshot
replication, it may be possible to use the snapshot
replicas as a point in time before a failure. However,
symmetric replication has the same problem as a
standby database—the problems would be propagated
to the replica. Both types of replication may be useful
for a disaster recovery.
Disk Mirroring
• Mirroring disk devices can add an extra level of protection for
databases. Disk mirroring occurs by allocating a secondary device
that will contain a duplicate copy of the primary device. All data
• modifications made to the primary device are also made to the
mirrored device. If the primary device fails, the mirrored device can
be used without causing a system outage. Of course, disk mirroring
consumes double the amount of disk storage for the same amount
of data.
• Disk mirroring differs from replication in that the data duplication
occurs at the device level instead of the database level.
• Once again, disk mirroring does not replace the need for backup
and recovery, because the mirrored data will be the same as the
data that is experiencing the problem. Disk mirroring, though, can
remove the need to recover from a media failure. Instead of
recovering database objects on the failing disk, the DBA can switch
to the mirrored data.