Introduction

Backup and recovery of databases are often not considered seriously until vital data is
lost. For every production system, it's essention that a proper backup and recovery
strategy be devised and deployed to avoid data loss.

If you're coming to DB2 with Oracle skills, you may be ready to learn how backup and
recovery work in DB2 UDB. In this article, I'll talk about how backup and recovery work
on DB2 UDB for Linux, UNIX and Windows, and will contrast and compare how those
functions work in Oracle.

In this article you will explore the following aspects of backup and recovery for both
Oracle and DB2 UDB:

 Backup and recovery concepts

 Data structures used for backup and recovery
 Backup and recovery options
 Backup and recovery utilities
 Recovery case scenarios

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 — Memory allocated for storing data blocks read from physical
data files.
 Shared Pool — Memory allocated for storing parsed SQL statements, PL/SQL
procedures and data dictionary information.
 Log Buffer — Memory allocated for storing before and after image of changed
data. The entry is sequential.
 Large Pool — Memory allocated for use by RMAN for backup and recovery.

Oracle background processes

 Database Writer (DBWr) — Writes to physical data files the dirty bits of buffer
asynchronously.
 Log Writer (LGWr) — Writes entries from log buffer to redo the log files.
 CheckPoint (CKPt) — Synchronizes the headers of data files and control files
with the current redo log and checkpoint numbers.
 Archiver (ARCH) — Automates the copying of redo logs. Manual archive of redo
logs will be required if this is not turned on.

Oracle database structures

 Data files — Physical files where data is stored.

  Control files — Files that contain the physical structure and status of the database
such as names of data file and log files with the absolute paths, size of files, block
size, online or offline status of data files etc. It contains also the names and paths,
file size and block size of log files.
 Redo logs — Files that contain the before and after images of changed data. Redo
logs are needed for recovery.
 Parameter files — Files that store the parameters for instance startup. You can
have multiple ways of starting an instance. Oracle first searches if the
spfile_SID.ora exists. If it does not, Oracle searchs for the spfile.ora parameter
file. If neither spfile_SID.ora nor spfile.ora exist, Oracle will use the init_SID.ora
parameter file.
 Archive logs — Physical copies of the online redo logs. Archived logs are needed
in online recovery.

Next we'll look at the DB2 UDB architechture and structures.

Figure 2. DB2 UDB architecture

DB2 UDB memory structure

 Package Cache — Memory allocated to store both static and dynamic SQL
statements.
 Buffer Pool — Memory allocated to store data before flushing it to disks
 Log Buffer — Memory used to store all changes to database before it is flushed to
the logs on disk.
Figure 3. DB2 UDB database structure

 Drive / Directory — The drive or directory specified on the CREATE

DATABASE command
 DB2 Instance Name — The name of the DB2 Instance owner
 NODE0000 — The partition number of the database. 0 for a non-partitioned
database
 SQL00001 — Database ID starting from 1
 SQLOGDIR — The default log directory for the database
 SQLT0000.0 — The catalog table space, SYSCATSPACE
 SQLT0001.0 — The temporary table space, TEMPSPACE1
 SQLT0002.0 — The user table space, USERSPACE1

Back to top

Backup and recovery options

There are two modes of backup and recovery for both Oracle and DB2 UDB databases:
offline and online. Either mode can recover with either complete or incomplete recovery.

Offline backup requires that all applications disconnect from the database, whereas online
backup allows transactions to carry on while backup is in progress. There are
implications of in terms of restoration of the backup mode chosen, in that the backup
mode determines the recovery mode. We shall see this in the following sections.

Complete recovery, as the name implied, recovers all committed transactions, whereas
incomplete recovery brings back transactions with some lost of data. Both Oracle and
DB2 UDB allow you to either recover to the current time with no loss of data, or to a
time previous to the current time, with some loss of data.

Often, the goal is to reach a compromise between business and operational needs with the
recovery mode chosen. For instance, if the database is not mission-critical and 24x7,
some downtime and loss of data may be acceptable, and re-keying of data may be an
acceptable option should media failure occurs. Depending on the available backups and
logs available, it is possible that sometimes there is no other choice but to do an
incomplete recovery.

There are two types of DB2 logging, and each logging method has an implications for
recovery. The two types of logging are circular and archive logging. When you choose to
use circular logging (the default), the only choice is to do an offline backup and version
recovery. If you choose to have archive logging, and do an online backup and roll
forward recovery, you can recover to a point in time or to the end of the logs for the
minimum loss of data.

We'll look at these two modes of backup and recovery in detail below.

Offline (Cold) Backup

In Oracle, the simplest form of all is to do an offline or cold backup. Offline backup is the
backup of all the physical database files after a normal database shutdown. This backup
method is the most common. A database using this form of backup is running in
NOARCHIVELOG mode, where any changes made to the database after the backup will
be irrecoverable should a media recovery is needed. As the name NOARCHIVELOG
implies, there is no archiving of redo logs, and thus no rolling forward beyond the online
redo logs. In case of media failure to any part of the database files, simply restore all the
database files, and of course all the changes made after the backup are irrecoverable.
Administrators are advised to do an offline backup whenever the schema of the database
changes, or changes are made such as adding or removing data files, and adding or
removing of table spaces.

The database files can be copied from disk to disk or from disk to tape, depending on the
backup procedure chosen. Operating system command such as cpio, tar and dd for Unix,
and backup manager or ocopy for Windows can be used to copy physical database files to
a backup media. Database files consist of

 Data files
 Control files
 Online redo log

You can loocate these files if you have adhered to Oracle's Optimal Flexible Architecture
(OFA). See Figure 4.
Figure 4. Optimal flexible architecture

In this example, ORACLE_BASE would be set to the value /u01/app/oracle, and

ORACLE_HOME would be set to either /u01/app/oracle/product/8.0.4 or
/u01/app/oracle/product/8.1.7.

The steps to perform an offline backup on Oracle are:

 Shut down database in normal mode

 Copy all data files, control files and online redo logs file to backup media

Offline backup is also the simplest form of backup in DB2 UDB. Offline backup requires
that a full database backup be taken and, obviously, that the database be offline while the
backup is in process. In other words, while doing an offline backup, users are not able to
access the database.
If you are using circular logging, offline backup is the only type of backup supported.
This is the default logging method when you first create a database. For circular logging,
both log retain for recovery status and user exit for logging status are set to NO. Two
parameters LOGRETAIN and USEREXIT are both set to OFF.

Figure 5. LOGRETAIN OFF

In circular logging, logs are used in a round robin manner much the same way as Oracle
uses redo logs in NoArchiveLog mode. As long as transactions in the logs are flushed to
disks, logs can be reused. However, during a long running transaction, a log full situation
may occur, where all the primary logs are active. When this happens, secondary logs will
be allocated dynamically. The DB2 configuration parameter LOGSECOND specifies the
maximum number (up to 254) of secondary logs that can be allocated dynamically when
needed. Secondary logs will only be removed when the database is deactivated.

Figure 6. Primary and secondary logs

Figure 7. Database configuration LOGSEC

Be aware that if you decide to use circular logging and offline recovery as your backup
strategy, all transactions after the last offline backup will be lost.

You can perform an offline backup either from the Control Center or using command line
processor. To do a Control Center backup, you will

 Bring up the Control Center.

 Go to the desired database (for example Sample) and right click on Backup, as
shown in Figure 8.
Figure 8. Backing up in DB2 UDB from the Control Center

 Note that the status of your logging is displayed.

 Figure 9. Circular logging

 Click Next to cotinue. Choose FileSystem as the media type. Click Add and fill in
the path (eg. e:\tmp). Click Next.

Figure 10. Choosing media type

 Note that your only option, Full Backup, is shown. Click Next.
Figure 11. Backup option screen
 Take the defaults. ClickNext.

Figure 12. Choosing backup parameters

 Enter the user id and password. Leave the rest at the defaults.

Figure 13. Choosing to run immediately or run as a task

  If you choose to run as a task, you will see the screen shown in Figure 14:

Figure 14. Task creation summary

 You can either run it immediately from the DB2 Task Manager, or let it be
triggered according to a scheduled time. The completed task will be displayed as
you see in Figure 15:

Figure 15. Tasks in Task Center

If you choose to run the backup from the DB2 command line, the syntax for command
DB2 backup is:

Listing 1. Command line Backup Syntax

BACKUP DATABASE database-alias [USER username [USING password]]
[TABLESPACE (tblspace-name [ {,tblspace-name} ... ])] [ONLINE]
[INCREMENTAL [DELTA]] [USE {TSM | XBSA} [OPEN num-sess SESSIONS]]
|
TO dir/dev [ {,dir/dev} ... ] | LOAD lib-name [OPEN num-sess
SESSIONS]]
[WITH num-buff BUFFERS] [BUFFER buffer-size] [PARALLELISM n]
[WITHOUT PROMPTING]

To do a backup in offline mode, simply issue a DB2 command:

Listing 2. Simple offline backup example

backup database sample to e:\tmp

Or you can have more options such as

Listing 3. Offline backup example with some parameters

backup database sample to e:\tmp

backup database sample to e:\tmp1, e:\tmp2
with 4 buffers
buffer 4096
parallelism 2

When the backup command is issued, a backup image will be created. Note that the
backup file names are slightly different for UNIX and Windows. For Windows, your path
and filenames will have this format:
Figure 16. Backup files in Windows

UNIX backup files will look something like this:

Figure 17. UNIX backup files

Table 1 shows similarities and differences between Oracle and DB2 UDB for offline
backup.

Table 1. Comparing offline backup: Oracle and DB2 UDB

Offline backup (Oracle) Offline backup (DB2 UDB)

 No particular  SYSADM, SYSCTRL
authority needed or SYSMAINT
 Operating in authority is required
NoArchiveLog  Operating in
mode (default) LOGRETAIN and
 Circular logs USEREXIT = OFF
contain both  Redo logs contain both
committed and committed and
uncommitted data uncommitted data
 Logs are written  Logs are written round
 round robin robin manner namely
manner namely when the last log is full,
when the last log it will overwrite log 1
is full, it will  For a long running
overwrite log 1 transaction when all
 For a long running logs are active,
transaction when secondary logs will be
all logs are active, allocated according to
log writing will parameter
overwrite in round LOGSECOND
robin manner  No rolling forward
 You can roll allowed
forward to do  No connection allowed.
recovery as long You will get a
as redo logs are SQL1035N: The
not overwritten database is currently in
 Need to shutdown use.
clean before SQLSTATE=57019
backing up error if there is an active
 All transactions connection
since the last  All transactions since
backup will be the last backup will be
lost lost
 Use OS level  Issue Backup Database
utilities to copy command to backup
database files to
other disks or
media

Recovery from offline (cold) backup in Oracle

There is nothing magical about restoring an offline backup in Oracle. You simply copy
back the physical database files into the right locations. In cases where you need to
relocate the data files, you need to update the control file by issuing the following
command.

Listing 4. Command for relocating data files in Oracle

alter database rename file <oldpath> to <newpath>

For DB2 UDB, each backup will create a timestamp. Therefore, the restore will be
according to the backup timestamp to ensure the latest backup image is restored in order
to minimize the loss of data. Note, the more frequently you take a backup, the less data
will be lost.

Figure 18 illustrates an example. At unit of work n, a media failure renders a directory to

be corrupted and inaccessible. You can either restore to Backup DB3 or earlier. Imagine,
if Backup DB3 isn't taken, you have no choice but to get earlier than backup that was
taken at 2004062510.

Figure 18. Offline backup and restore

For DB2 UDB, there are again two ways you can opt to do a restore. You can either use
the Control Center or command line processor (CLP). To restore from the Control Center
follow these steps:

 From the Control Center, select the database (for example, Sample) and right
click to perform a restore. You have an few options as shown below. Click Next.

Figure 19. Offline restore options

 Highlight a backup image and move to the right panel. Click Next.
 Figure 20. Backup image selections

 You may choose to redirect the containers if desired:

 Figure 21. Container redirect options

 Note that your only option, Full Backup, is shown. Click Next
 Figure 22. Choosing restore parameters

 Take the defaults. Click Next.

Figure 23. Choosing further restore parameters

 Take the defaults or choose to run immediately. Enter user id and password. Click
Next.
 Figure 24. Task scheduling

 Click Finish.
 Once completed restoring, you will see something like this in Task Manager:
 Figure 25. Task creation summary

To do a CLP restore of an offline backup, the command syntax is as shown in Listing 5:

Listing 5. Command for restore database

RESTORE DATABASE source-database-alias

{ restore-options | CONTINUE | ABORT }

restore-options:
[USER username [USING password]] [{TABLESPACE [ONLINE] |
TABLESPACE (tblspace-name [ {,tblspace-name} ... ]) [ONLINE] |
HISTORY FILE [ONLINE]}] [INCREMENTAL [AUTOMATIC | ABORT]]
[{USE {TSM | XBSA} [OPEN num-sess SESSIONS] |
FROM dir/dev [ {,dir/dev} ... ] | LOAD shared-lib
[OPEN num-sess SESSIONS]}] [TAKEN AT date-time] [TO target-directory]
[INTO target-database-alias] [NEWLOGPATH directory]
[WITH num-buff BUFFERS] [BUFFER buffer-size]
[DLREPORT file-name] [REPLACE EXISTING] [REDIRECT] [PARALLELISM n]
[WITHOUT ROLLING FORWARD] [WITHOUT DATALINK] [WITHOUT PROMPTING]

For example, to restore a particular image from E:\tmp, you will have to specify the
backup image to be restored. The command in Listing 6 will restore an image taken at
June 17 around 10:00 AM.

Listing 6. Simple restore database command

db2 restore database sample from e:\tmp taken at 2004061710

Figure 26. Restore database using CLP

There are times when restoring to the original directories is not possible, for example
with media failure. You can use a RESTORE DATABASE...REDIRECT to use different
containers. Directory and file containers are automatically created if they do not already
exist. For example, if my tablespace 0 needed to be redirected, I would issue these
commands:

Listing 7. Containers redirected using CLP

db2 restore database sample from e:\tmp taken at 2004061710 replace

existing
db2 set tablespace containers for 0 using (path 'E:\tmp\0')
(note if it's a DMS tablespace, you will need a set tablespace
containers for 0
using (file 'e:\tmp\0.dms' <SIZE>)
db2 restore database sample continue

Table 2 compares offline restore for DB2 UDB and Oracle.

Table 2. Comparison of offline restore for Oracle and DB2 UDB

Offline backup (Oracle) Offline backup (DB2 UDB)

 No particular  SYSADM,
authority needed SYSCTRL or
 Administrators doing SYSMAINT
backups will have to authority is required
label them correctly to restore to an
so that during restore, existing database.
a wrong copy of Restoring to a new
backup will not be database will require
restored. SYSCTRL or
 Data files can be SYSADM authority
 renamed and  During restore,
relocated using Alter administrators are
Database Rename able to pick backups
File <oldpath> to from certain
<newpath> DDL timestamps. Backup
statement command both from
 Cannot restore to Control Center and
different database CLP create
timestamp for
backups to ease the
restore.
 You can redefine
table space
containers by
invoking the
RESTORE
DATABASE
command and
specifying the
REDIRECT
parameter
 You can either
restore to an existing
database or a new
database

Online (hot) backup

Oracle online backup

In Oracle, online backup requires that the database operate in ARCHIVELOG mode. At
shops where the database must stay up 24x7, it is impossible to shut out users from
accessing the database for an offline backup. In this kind of scenario, the database should
run in ARCHIVELOG mode, where transactions keep running while the backup process
is taking place.

Unlike offline backup, online backup only requires that data files and control files be
backed up. The unit of backup for offline database is the entire database, whereas the unit
of backup for online backup is some or all table spaces.

The entire notion of online backup in Oracle is that as users carry out transactions, all
changes made to the database, either committed or uncommitted, are stored to the redo
log buffer and subsequently are written to the online redo log files by the LGWr process.
Redo logs are written in a round-robin manner; therefore, before they are overwritten, the
redo logs need to be archived either manually or automatically by kick-starting the
ARCH process. When all transactions are being logged and later archived preferably with
multiplexing (using parameter LOG_ARCHIVE_DUPLEX_DEST), a recovery can be
carried out using these archived redo logs should media recovery is needed.

Note that using online backup itself doesn't guarantee that you will not lose data. Steps
such as immunizing ther database by multiplexing (putting in different locations) control
files, using online redo logs and archiving redo logs are necessary to avoid a single point
of failure.

To switch to an online with auto archive from the default offline backup in Oracle, you
need to do the following:

 Fill in the parameters LOG_ARCHIVE_START, LOG_ARCHIVE_DEST,

LOG_ARCHIVE_FORMAT and LOG_ARCHIVE_DUPLEX_DEST,
LOG_ARCHIVE_DEST_N in the init.ora with the appropriate values
 Shutdown and Startup mount
 Alter database archivelog
 Alter database open
 Archive log list (to verify)
 Archive log all
 Backup all newly created logs

Online backup occurs either when any or all online table spaces are put into online
backup mode by issuing a command Alter Tablespace ts_name Begin Backup. When this
command is issued, all data files that are in the online backup mode will be issued
checkpoint SCN. In other words, all dirty bits of the data buffer will be flushed to the
data files. No checkpoint SCN will be issued after the initial checkpoint SCN. For those
data files not in the online backup mode, subsequent checkpoint will increase the SCN in
their headers. When Alter Tablespace ts_name End Backup is issued, again a checkpoint
SCN is recorded at the headers of online backup data files. These Begin and End backup
command allows Oracle to know which redo to apply and when to stop during rolling
forward.

Oracle recommends the minimum time elapsed between Begin and End backup
commands. Also, minimum user activities should be allowed during this time for the fact
that Oracle logs the entire block images on the first change to the block. This will result
in enormous redo logs to be generated for online backup data files. Practically it means
when Begin backup is issued, an operating system copy should follow, and then quickly
end by an End backup. The backup is restricted to sequential backup meaning after
backing up data files in tablespace1 then go on for data files in tablespace2.

For online backup, special care needs to be taken for the SYSTEM table space and
rollback segments table space. You need to also make sure that the control files are
backed up once there are schema changes to the database. The backup scripts should also
reflect the latest schema.
DB2 UDB online backup

The mechanism for DB2 UDB to do recovery to the point in time is similar to Oracle. To
understand the DB2 UDB online backup and recovery, you need to understand archive
logging. There are three definitions of logs that we need to familiar with:

 Active logs — Logs contain transactions that are not committed or roll backed or
committed transactions yet not flushed to disk.
 Online archive logs — Logs contain information for committed and flushed
transactions.
 Offline archive logs — Archive logs that are being moved from active log
directory to either another directory in another media or tape.

There are numerous configuration parameters that are related to logging.

 LOGFILSIZ — Total number of 4KB size to be allocated (default is 250)

 LOGPRIMARY — Total of primary logs (default is 3)
 LOGSECOND — Total number of secondary logs that can be allocated when the
primary logs fill up. When this is set to —1 (version 8), infinite active log is
available
 NEWLOGPATH - To change the location where the future log files are to be
stored. Will only be effective once database is reactivated.
 MIRRORLOGPATH — A secondary path to write the logs to avoid single point
of failure.
 OVERFLOWLOGPATH — Specify the location of the logs during a rollforward
operation to allow access logs in multiple locations
 USEREXIT — To specify to use userexit for automatic archiving of archive logs.
 BLK_LOG_DSK_FUL - prevent disk full errors from being generated when DB2
cannot create a new log file in the active log path.

In order to use online backup, archive logging must be turned on. You can turn on
archive logging by setting LOGRETAIN to ON.

Once archive logging is the logging mechanism, it differs from circular logging in the
sense that circular logging overwrites logs that are committed, whereas archive logging
archives logs that are committed.

In archive logging, there is no reuse of logs that have become archive logs. To move
those online archived logs, you will either move them manually or use a user exit to
move them. Figure 27 illustrates the archive logging mechanism:
Figure 27. Active, online and archived logging

At LOG (n+1), which is the active log, log (n) and log (n-i) (where i<=n) will be rendered
online archived logs. These archived logs can either sit in the path where the active logs
are stored, or you can use a user exit to specify a directory or media where they will be
stored.

By default, both active and online archive logs reside in the SQLOGDIR directory. The
NEWLOGPATH database configuration parameter determines where future active
archived logs will be stored. The NEWLOGPATH configuration parameter will only be
effective after you deactivate the database, which closes all active log files. Reactivating
the database will cause new log files to be created in the new path, and the archive logs
will be left in the old path.

When an online backup is taking place, all transactions for the database will be logged.
After an online backup is completed, DB2 will force the current active log to close and be
archived, as shown in Figure 28:

Figure 28. Active logs being closed

To prevent a single point of failure for offline archive logs such as media failure, log
mirroring shouldl be used. MIRRORLOGPATH is the configuration parameter to specify
a secondary path, allowing DB2 to write an identical second copy of log files to a
different directory. You will need to reactivate your database to cause the
MIRRORLOGPATH configuration parameter to become effective.

If there is a problem writing to any log path, DB2 will write a message in the
administration notification log stating that an error has been encountered. DB2 will
continue writing log records to good log paths. No synchronization of log paths will
occur. To figure out which log is active and which are archived, use the DB2 command
GET DB CFG to view the 'First active log file'. It provides the log file that is currently
active, and therefore archived logs will be those logs earlier than this current one.

Also, every backup operation such as database, table space or incremental will include a
copy of the recovery history file (RHF). You can use the information provided in the
history file to recover all or part of a database to a point in time. A recovery history file is
created with each database and is automatically updated when:

 A database or table spaces are backed up

 A database or table spaces are restored
 A database or table spaces are rolled forward
 A table space is created
 A table space is altered
 A table space is quiesced
 A table space is renamed
 A table space is dropped
 A table is loaded
 A table is dropped
 A table is reorganized

To see recovery history file, you can issue the following command, substituting your own
database name for "sample":

Listing 8. List Backup History

db2 list history backup all for sample

Figure 29. List backup history

For online backups, there are two levels of backups that can be taken, table space and
database level online backup. There are two ways to do online backup. You can either do
it using the Control Center GUI or CLP command prompt.

To do an online table space and database level backup using the Control Center, follow
these steps:
 To turn on LOGRETAIN through the Control Center, highlight the database and
right click to modify the configuration parameters. Change the LOGRETAIN
default NO to RECOVERY. Shutdown and start up the database again to make
the configuration change effective. >br/>
Figure 30. Modifying LOGRETAIN using Control Center

 You will also need to do a full offline backup. If you don't you will receive the
error below trying to connect to the database.

Figure 31. Backup pending message

 Now, do a full offline backup using CLP command.

Figure 32. Full offline backup

 Navigate to database sample, and right click to do a backup. The first screen you
see will be as below. Choose Backup selected table spaces and click Next.
 Figure 33. Online backup choices

 Select table space Userspace1 to backup. Click Next

Figure 34. Selecting tablespaces to back up

 For testing purpose, choose file system. Add the path, for example E:\tmp. Click
Next.
 Figure 35. Media type selection

 Take the defaults and click Next.

Figure 36. Choosing online backup

 Take the defaults and click Next.

 Figure 37. Specifying backup parameters

 Take the defaults. Enter user id and password. Click Next.

Figure 38. Running immediately or save as tasks

 Click Finish.
 Figure 39. Task creation summary

However, if you decide to do a database level backup, which is ideal for a smaller
size database, you will do the following.

 Navigate to database sample, right click to do a backup. The first screen you see
will be as below. Choose Backup entire database and click Next.

Figure 40. Backup the entire database

 Choose the path. Click Next.

 Figure 41. Choosing the media type

 Take the defaults. Click Next.

Figure 42. Online backup

 Take the defaults. Click Next.

Figure 43. Backup parameters

 Take the defaults. Enter user and password. Click Next.

 Figure 44. Schedule the task

 Click Finish.

To do an online table space and database level backup via CLP command prompt, follow
the steps below.

 Turn on LOGRETAIN. Shutdown and start up the database again to make the
configuration change effective.

Figure 45. Turning LOGRETAIN ON

 Once the configuration parameter is effective, you will see LOGRETAIN =
RECOVERY.

Figure 46. LOGRETAIN = RECOVERY

 You will also need to do a full offline backup. If you don't, you will receive the
error below trying to connect to the database.

Figure 47. Backup pending

 Now, do a full offline backup using CLP command.

Figure 48. Offline full backup

 To do a tables space level online backup, issue the command:

Listing 9. Backup a Tablespace Online via CLP

db2 backup database sample tablespace(userspace1) online to e:\tmp

Figure 49. Online tablespace backup via CLP

 To do a database level online backup, issue the command:

Listing 10. Backup a database online via CLP

db2 backup database sample online to e:\tmp

 Figure 50. Online database backup via CLP
Table 3compares DB2 UDB and Oracle online backup.
Table 3. Comparison of online backup for Oracle and DB2 UDB
Online backup (Oracle)
 SYSDBA privilege is required
 Operating in ArchiveLog mode
 Redo logs contain both committed
and uncommitted data. Oracle uses
archived logs to roll forward to
consistent state and Undo table
space to rollback any uncommitted
data.
 Online Redo Logs are written round
robin manner namely when the last
log is full, it will overwrite log 1.
During log switch, online redo logs
will be archived.
 For a long running transaction when
all logs are active, online redo logs
will only be overwritten if either
you manually archive the non-active
online redo or that you have the
ARCH process to do it for you.
Failure to do the either of the above
will cause the Oracle to hang.
 LOG_ARCHIVE_DUPLEX_DEST,
LOG_ARCHIVE_DEST_N can be
used to specify more than one
location Oracle write logs to.
Maximum value for
LOG_ARCHIVE_DEST_N is 10.
When one path is down, Oracle will
ignore it and continue functioning as
long as there is one path that works.
However, a message will be logged
in audit trail. No synchronization of
the paths will happen.
 Enabling ArchiveLog mode will
require a database rebounce, and a
Online backup (DB2 UDB)
 SYSADM, SYSCTRL or
SYSMAINT authority is
required to restore to an
existing database. To restore
to a new database you will
need either SYSADM and
SYSCTRL
 Operating in
LOGRETAIN=ON
 Logs contain both
committed and uncommitted
data. In DB2, both roll
forward and rollback using
logs
 Logs are not written in round
robin manner. Archived logs
will not be overwritten. An
active log will become an
archived log upon closing by
DB2
 For a long running
transaction when all logs are
active, secondary logs will
be allocated according to
parameter LOGSECOND
 MIRRORLOGPATH
configuration parameter is
used to multiplex logs.
Maximum value for
MIRROLOGPATH is 1.
When one path is down,
DB2 will write to DB2
administration notification
log and continue functioning
as long as there is one path
 close and clean full backup.
 Control files contain the name of the
database, log sequence and
checkpoint information, the physical
file structure etc.
 Table space level backup
 Backup all data blocks, both
changed and unchanged. Not
suitable for huge warehouse
environment
 No Compression in Backup.
 Database restore and roll forward
does not necessary require the
database be shutdown.
 Sequential Backup - Backing up
table space one after the other.
 Issue Alter Tablespace ts_name
Begin Backup
Recovery from Online (Hot) Backup
that works. However, DB2
will continually trying to
write to the bad path when
the current log is completed.
No synchronization of the
paths will happen.
 Enabling LOGRETAIN will
only be effective after a DB2
database restart. You will
need a full offline backup
 Recover History File
contains info such as backup
and restore of database or
tables paces, roll forward
recovery from database or
table space, altering and
quiescing a table space,
REORG and RUNSTATS,
dropping a table etc.
 Both tables pace and
database level backups
 Backup all data blocks, both
changed and unchanged. Not
suitable for huge warehouse
environment
 Backup compression has
been added as an option to
the BACKUP DATABASE
command and the
db2Backup APIs.
 Database restore and roll
forward must be done
offline. Restore and roll
forward for table space level
does not require an offline
 Parallelism allowed
 Issue Backup Database
command to backup. Eg
Backup database sample
tablespace(userspace1)
online to e:\tmpOr Backup
database sample online to
e:\tmp
Oracle online recovery depends a great deal on what is actually lost, for example, losing a
group on online redo logs, losing a rollback segment data file, or corrumption of a data
file for the SYSTEM table space. There are basically two situations where data can either
be recovered completely or partially. Refer to the Case scenarios section for more
detailed examples.

To do a roll forward recovery in DB2 UDB, archive logging must be used. During a
restore of database, exclusive use is required. You can either restore either at database or
table space level. You will restore the backup image and roll forward to complete the
process, or leave the database in a pending state. There are two types of rolling forward:

 To the end of logs

 To a point in time

In DB2 UDB, there are two options to do a restore: the Control Center and CLP. The
following steps show you how to perform a restore of an entire database.

 In the Control Center, right click on the Sample database and select Restore.

Figure 51. Using restore from Control Center

 Note that there are three options: restore to an existing database, to a new
database or just restore the RHF. In this case, we just restore to the existing
database. Click Next.
 Figure 52. Restore alternatives

 To restore the entire database, take the default. Click Next.

Figure 53. Restore entire database

 Pick the backup image to restore.

 Figure 54. Pick backup image to restore

 Leave the default. Redirect is need when a container is damaged. Choosing

redirect will put your database in restore pending state. Click Next.

Figure 55. Pick backup image to restore

 You can either restore without rolling forward, or restore with roll forward. You
can either pick from the default log directory or overflow path. In our case, we
restore to local time.
 Figure 56. Roll forward options

 You can leave it either in pending state or active state. Pending state is good for
container redirection. We choose active state. Click Next.

Figure 57. Final state of database

 Take the defaults. Click Next.

 Figure 58. Parameter options

 Take the defaults. Click Next.

Figure 59. Some more parameter options

 Run now without saving task history. Click Finish. Note that if the database is not
in exclusive mode, you will see the error below
 Figure 60. Non-exclusive use during online restore

In the CLP, you will issue the following commands to do a restore and roll forward a full
database.

Listing 11. Restore and roll forward a full database

RESTORE DATABASE SAMPLE FROM "e:\tmp" TAKEN AT 20040629152131

WITHOUT PROMPTING;
ROLLFORWARD DATABASE SAMPLE TO 2004-06-29-15.23.09.000000 USING
LOCAL TIME AND COMPLETE;

However, sometimes it is more economical to do tables space level backup for larger size
databases. Also, restoring a table space will only require exclusive use for that table
space. The remaining table spaces can still be accessed. You can restore more than one
table space at one time. The following steps show how to restore from a table space
(assuming that USERSPACE1 is corrupted):
 Instead of choosing entire database to be restored, choose Restored selected
table spaces. Click Next.

Figure 61. Choosing to restore tablespaces instead of a full database

 Choose the backup image to use. Click Next.

Figure 62. Choose backup image to restore

 The rest of the steps remain the same as restoring from a full database.
 At the page Restore Option, you can restore the table spaces online. Remember, a
full database restore will require exclusive use for the entire restore operation,
whereas online restore of a table space will only require that tablespace to be in
exclusive mode.
 Figure 63. Choosing restore options

In the CLP, you will issue the following to do a restore and roll forward a table space:

Listing 12. Restore and roll forward a full database

RESTORE DATABASE SAMPLE TABLESPACE (USERSPACE1)

ONLINE FROM "e:\tmp" TAKEN AT 20040629152131 WITHOUT PROMPTING;
ROLLFORWARD DATABASE SAMPLE TO END OF LOGS AND COMPLETE
TABLESPACE (USERSPACE1) ONLINE;

Table 4 compares DB2 UDB and Oracle online restore

Table 4. Comparison of online restore for Oracle and DB2 UDB

Online recover (Oracle) Online restore (DB2 UDB)

 Restore from  Restore from the backup
database files image
 Both database  Both database and table
and table space space restore are
recover are supported
supported  Both complete and
 Recover database incomplete recovery will
UNTIL will be be using backup images
used for with or without the roll
incomplete forward enabled
recovery

Incremental backup and recovery

As database size grows into terabyte and petabyte, the time and hardware resources
required will grow substantially. Often times, it's not feasible to back up the entire
database or even few table spaces at one time. For example, in a data warehouse
environment, there may be few changes in the data. In this case, it would be better to just
back up the changed pages instead of the entire database or table spaces.

In Oracle, Recovery Manager is used to do the incremental backup. There are two types
of incremental backups provided by Oracle.

 Differential incremental (default)

 Cumulative incremental

Differential incremental backup backs up all blocks changed after the most recent backup
at level n or lower. You can specify levels 0-4 for differential incremental. The diagram
below illustrates the concept of differential incremental backup.

Figure 64. Oracle differential incremental backup

Here is the explanation:

 For the first Sunday, a base level 0 backup is taken, all data blocks are copied.
 Monday uses level 2 and since 0 is lower than 2, RMAN will back up chances
since Sunday.
 Tuesday uses level 2 and since Monday is at same level, RMAN will back up
changes since Monday.
 Wednesday uses level 2 and since Tuesday is at same level, RMAN will back up
changes since Tuesday.
  Thursday is uses level 1 and since Monday, Tuesday and Wednesday are all
higher than level 1, RMAN will back up chances since Sunday because it is at
level 0 which is a lower level.
 Friday uses level 2 and since Thursday uses level 1, a lower level, RMAN will
backup changes since Thursday.
 Saturday uses level 2 and RMAN will backup changes since Friday.
 Second Sunday, where level 0 is specified. RMAN will backup since last level 0
because there is nothing equal or less than level 0 other than the level 0 since last
Sunday.
 Repeat the process


Cumulative incremental backup on the other hand, backs up all the blocks used since the
most recent backup at level n-1 or lower. Figure 65 illustrates the concept of cumulative
incremental backup.

Figure 65. Oracle cumulative incremental backup

Here is the explanation:

 The first Sunday uses level 0. RMAN will backup all data blocks that have ever
been in use in database.
 Monday uses level 2. RMAN will backup all changes since Sunday for level 0 is
lower than 2.
 Tuesday uses level 2. RMAN will backup all changes since Sunday. This backup
includes those blocks that were copied on Monday.
  Wednesday uses level 2. RMAN will backup all changes since Sunday. This
backup includes those blocks that were copied on Monday and Tuesday.
 Thursday uses level 1. RMAN will backup all changes since Sunday.
 Friday uses level 2. RMAN will backup all changes since Thursday.
 Saturday uses level 2. RMAN will backup all changes since Thursday.
 Second Sunday where level 0 is specified, there is no level lower than 0 other than
the level 0 on previous Sunday. Therefore, all changes since previous Sunday will
be backup.
 Repeat the process.

DB2 UDB has a similar incremental backup and recovery strategy. There are two types
of incremental backups provided.

 Incremental
 Delta

An incremental backup is a backup of all changes since the most recent, successful, full
backup. This form of backup is also known as cumulative backup. Each successive
incremental image contains the entire contents of the previous incremental image, and the
changes since the previous full backup. In the case of a failure for example on Saturday
after the incremental backup is taken, you can just restore the first Sunday full backup
and apply the incremental on Saturday. See the diagram below.

Figure 66. DB2 UDB incremental backup

A delta backup is a backup of changes since the last successful, full, incremental or delta
backup. In the case of a failure on Saturday, you could restore the first Sunday full
backup and apply the delta backups from Monday until Saturday. See the diagram below:
Figure 67. DB2 UDB delta backup

The configuration parameter, TRACKMOD tracks the database updates. When set to NO
(the default), there is no tracking for database page updates. When this parameter is set to
"Yes", the database manager tracks database modifications so that the backup utility can
detect which subsets of the database pages must be examined by an incremental backup
and potentially included in the backup image. After setting this parameter to "Yes", you
must take a full database backup in order to have a baseline against which incremental
backups can be taken.

Note that the combination database and table space incremental backups are permitted.
For table space tracking, a flag for each table space indicates whether a table space is
dirty and need to be back up.

The steps below show you how to do an incremental backup and restore. Assuming we
back up as depicted above — Sunday full backup, Monday to Saturday we do
incremental backups.

 Turn on TRACKMOD. Make sure you disconnect all applications before

reconnect to take effect. Issue the command:

Listing 13. Turning TRACKMOD ON

update db cfg using trackmod on

 Figure 68. Turning TRACKMOD ON

 Do a full database backup as a base for the incremental. This is the backup on
Sunday. Issue the command:

Listing 14. Backup database online

db2 backup database sample to e:\tmp

Figure 69. Online backup of database

 For Monday, do an incremental backup. Issue the command

Listing 15. Backup database incrementally

db2 backup database sample incremental

Figure 70. Incremental backup of database

 For Tuesday to Saturday, repeat the incremental backup process.

 Say, on the next Sunday early morning, media failure happens. To restore without
losing data, you will restore from the first Sunday backup, followed by
incremental backup taken on Saturday and roll forward. Note that you can restore
 either a full backup manually, apply the Saturday incremental backup image and
roll forward. You can use automatic keyword to automatic restore from the full
backup and apply the Saturday backup image. At this moment, you will still be in
roll forward pending mode (SQL1117N) since there will be transactions to be roll
forward.

Listing 16. Restoring from incremental backup automatically

db2 restore database sample incremental automatic

from e:\tmp taken at 20040701112735 without prompting

Figure 71. Incremental restore

Listing 17. Roll forward to end of logs

db2 rollforward database sample to end of logs and complete

Figure 72. Roll forward to end of logs

For Delta backup and restore, in the same scenario, you will restore each day's delta
backup image (Monday through Saturday) and roll forward to complete the recovery.
DB2 UDB provides a utility, db2ckrst to query the database history and generates a list of
timestamps for the backup image that are required for an incremental restore.

Back to top

Backup and recovery utilities

Both Oracle and DB2 UDB provide utilities to safeguard the backup image. The table
below lists some of them.

Table 5. Table comparing utilities to safeguard backup image and database files

Oracle utilities DB2 UDB utilities

 Export - Oracle uses export to do  Not
a logical backup. Export is applicable
especially good to recover from a  Not
dropped table applicable
 Recovery Manager (RMAN) -  Not
checks before copying each applicable
modified block  Not
 DB_BLOCK_CHECKSUM - applicable
this parameter stores checksum at  db2ckbkp -
every block header. However, checks the
setting to true will have an integrity of
impact on performance the entire
 LOG_BLOCK_CHECKSUM - backup
Enables the ARCH process to image.
checksum the archived log files. db2dart -
However, setting to true will examines
have an impact on performance databases for
 DBVerify - Check the integrity architectural
of data files. Issue the command, correctness
dbv and reports
file=c:\oracle\oradata\file1.dbf any
logfile=c:\temp\out.log encountered
errors.

Back to top

Recovery case scenarios

Complete recovery
A complete recovery is a recovery that involves rolling forward the logs to bring the
database to the most current time with no lost of data.

Oracle complete recovery

In the Oracle world, there are numerous ways to accomplish a complete recovery.
Typically this recovery is achieved when database is running in ARCHIVELOG mode
and backup online. Complete recovery can be done at the database level or data file and
tablespace level. There are cases where database level recovery desirable. To do a
database level recovery, you need to do the following:

 Mount the database

 Online all the data files
 Copy back the lost data file or the entire database
 Apply the redo (both online and archived)

There are times you want to do a data file and tablespace level recovery. In this case you
have to do the following:

 Offline the data file or tablespace

 Copy back the data files to be recovered
 Roll forward

For Oracle, depending on the severity of a media failure and the backup strategy
deployed, restoring to a consistent state with no lost of data can sometimes be impossible.
There are few scenarios (not exhaustive) such as below:

 Recovering from the loss of a multiplexed control file member

o Scenario 1 : Disk and filesystem is intact
 Shutdown abort
 Copy good controlfile to original location of bad controlfile:- cp
/path/blah_good.ctl /path/blah_bad.ctl
o Scenario 2 : Disk and filesystem is no good
 Shutdown abort
 Copy good controlfile to a new location:- cp /path/blah_good.ctl
/new_good_path/blah.ctl
 Change the CONTROL_FILES param in init.ora to reflect the new
good path
 Startup
 Recovering from the loss of one member of an online redo log group
o No need to shut down
o To investigate what status is the missing redo log is - Select * from
v$logfile shows which group and member is INVALID
o From step 1, you will have the full path of the member that went
corrupted. Drop this member - Alter database drop logfile member
'fullpath/log_filename.log'
 o Add a new member to the group - Alter database add logfile member
'/fullpath/log_filename.log' reuse to group n; where log_filename.log and
group n follow step 1
 Recovering from a situation where there is no data file backup
o Do a shutdown abort
o Startup mount
o Get the Path and Size of the missing datafile - select df.file#, df.status,
df.enabled, df.create_bytes, df.name from v$recover_file rf, v$datafile df
where rf.file#=df.file# and rf.error = "FILE NOT FILE" (note the path and
size of the missing file)
o Create the datafile - alter database create datafile '/path/filename.dbf' as
'/path/filename.dbf' size xxx reuse (Make sure that the path and size are
the same as step 4)
o If the file is offline, then bring in online - alter database datafile
'/path/filename.dbf' online;
o Recover the database - recover database
o Open the database - alter database open
 Recovering from the loss of a data file that belongs to an indexes-only tablespace
o Restore a good copy of datafile
o Mount the database - startup mount
o Recover the datafile - recover datafile 'fullpath/filename'
o You will be prompted for archived log. Confirm until you receive "Media
Recovery Complete"
 Recovering from the loss of a datafile that belongs to a temporary tablespace
o Offline the tablespace
 In archivelog - alter database datafile xxx offline immediate
 In nonarchivelog - alter database datafile xxx offline drop
o Drop the tablespace
 Drop tablespace xxx
o Remove physical files of the tablespace and recreate them
 Recovering from the loss of a datafile that belongs to a readonly tablespace
o To recover a loss datafile that belongs to READ-ONLY tablespace is an
easy task indeed. Since READ-ONLY tablespace is never modified,
simply restore the datafile to its original location shall do the job.
However, if you change from read-only to read-write vice-versa since last
backup, you have to restore the file and do a media recovery on it.
 Recover datafile xxx
 Apply the logs until you see "Media Recovery Complete"
 Recovering from the loss of an inactive redo log group
o To investigate what status is the missing redo log is - a. select * from
v$logfile shows which group is INVALID. b. select * from v$log shows
the status of the invalid group
o Now that you are confirmed that the lost redo file is an INACTIVE redo
log, shutdown the database - shutdown immediate
o Mount the database - Startup mount
 o Since the redo log group is inactive and is archived, just clear the redo log
- alter database clear logfile group N (where N is the group # of the lost
redo log)
o Open the database - Alter database open
o Check status - select * from v$log shows a new redo with UNUSED status
o Do a full backup if you want
 Recovering from the loss of a data file that belongs to the system tablespace
o Shutdown abort the database if the database is still up
o Copy the corrupted or lost datafile from backup to the original location
o Startup mount
o select v1.group#, member, sequence#, first_change# from v$log v1,
v$logfile v2 where v1.group#=v2.group#;
o Recover the database by Recover datafile '/path/filename.dbf'
o Logs will be prompted. Confirm it until you see "Media Recovery
Complete". If you are asked to enter a non-existence archived log, enter
the full path of a member of the redo group where the sequence number
matches the one being prompted (from step 4) until you see "Media
Recovery Complete".
o Alter database open
 Recovering from the loss of a data file that belongs to a traditional rollback
segment tablespace
o The database was cleanly shut down(All the committed data are written to
disks)
 Comment out the ROLLBACK_SEGMENTS entry in init.ora
 Startup restrict mount
 Alter database datafile '/path/filename.dbf' offline drop;
 Alter database open
 Drop tablespace tablespace_name including contents;
 Recreate the rollback tablespace with all of its rollback segments.
The segment name should correspond to
ROLLBACK_SEGMENTS in init.ora
 Shutdown immediate
 Uncomment the ROLLBACK_SEGMENTS in init.ora
 Startup
 select segment_name, status from dba_rollback_segs just to make
sure all rollback segments are online
o The database was not cleanly shut down (there are active transactions in
the rollback segments)
 Restore the corrupted/lost file from backup using OS cp command
 Startup mount
 Check the status of the datafile: select name, status from
v$datafile; Online the datafile if it's OFFLINE by Alter database
datafile '/path/filename.dbf' ONLINE
 select v1.group#, member, sequence#, first_change# from v$log
v1, v$logfile v2 where v1.group#=v2.group#;
 Recover datafile '/path/fileame.dbf'
  Logs will be prompted. Confirm it until you see "Media Recovery
Complete". If you are asked to enter a non-existence archived log,
enter the full path of a member of the redo group where the
sequence number matches the one being prompted (from step 4)
until you see "Media Recovery Complete".
 Alter database open
o The database is up and running (Simpler)
 Create few additional rollback segments to handle the database
activities. Eg. Create tablespace rbstemp datafile
'/path/rbstemp01.dbf' size 50M'. Create rollback segment xxx
tablespace rbstemp
 Offline the lost datafile: Alter database datafile '/path/filename.dbf'
offline
 Restore the lost datafile from backup using OS cp
 select v1.group#, member, sequence#, first_change# from v$log
v1, v$logfile v2 where v1.group#=v2.group#;
 Recover datafile '/path/filename.dbf'
 Logs will be prompted. Confirm it until you see "Media Recovery
Complete". If you are asked to enter a non-existence archived log,
enter the full path of a member of the redo group where the
sequence number matches the one being prompted (from step 4)
until you see "Media Recovery Complete"
 Online the datafile : Alter database datafile '/path/filename.dbf'
online

Recovery from the above situation has to be taken care of in a case by case manner if you
are using the traditional ALTER TABLESPACE...BACKUP BEGIN. A good plan is to
guard against any of the types of loss mentioned above. However, since Oracle 8i, Oracle
recommends that Recovery Manager (RMAN) be used to do the online backup. There are
advantages of RMAN such as

 Incremental backup
 Redo inflation with traditional backup will not happen
 Integrity check for data to avoid data corruption
 Parallel backup allowed
 Automate the backup and restore process

DB2 complete recovery

Here are the types of recovery without loss of data:

 Online restore for database with a good backup image. Roll forward to the end of
logs and complete. Note that this includes all kind of media failure, including
containers corrupted, and so on. Refer to the steps above to do a database level
recovery.
  Online restore for table space with a good backup image. Roll forward to the end
of logs and complete. Note that this includes all kind of media failures, container
corruption, and so on. Refer to the steps above to do a table space level recovery.
 Dropping a table accidentally. To recover a dropped table, do the following.
o You have to turn on the DROP_RECOVERY option to Y for table spaces
are enabled for dropped table recovery initially. Issue the commands
below to check whether a table space is enabled for dropped table
recovery and if not, turn it on.
 db2 select tbspace, drop_recovery from syscat.tablespaces
 db2 alter tablespace userspace1 dropped table recovery on
o Make sure your LOGRETAIN is ON. If not issue
 db2 update db cfg using logretain on (you need to disconnect all
applications to take effect)
o Do a full offline backup
 db2 backup database sample to e:\tmp

Now at certain point in time, you find out that one of your tables was accidentally
dropped by an amateur DBA, or more precisely a trainee DBA. Do the following:

o list the dropped table history by issuing the command. You will notice few
things; the backup ID (eg 000000000000bb000002000d), dropped table
start and end time (eg. 20040705150008) and the DDL for the dropped
table. You will need the backup ID and the DDL for the dropped table in
the subsequent steps.
 db2 list history dropped table all for sample
o Restore table space using the backup image without rolling forward
 db2 restore database sample tablespace (userspace1) from e:\tmp
taken at 2004070515 without rolling forward
o Roll forward using complete recover dropped table to e:\tmp. You will see
a ROLLFORWARD command complete successfully prompt.
 db2 rollforward database sample to end of logs and complete
recover dropped table 000000000000bb000002000d to e:\tmp.
o Now, create the dropped table from the list dropped table DDL statement.
o Import the exported data, for example:
 db2 import from d:\tmp\node0000\data of del method p
(1,2,3,4,5,6,7,8,9,10,11,12,13,14) messages d:\tmp\imp.loog insert
into employee(empno, firstnme, midinit, lastname, workdept,
phoneno, hiredate, job, edlevel, sex, birthdate, salary, bonus,
comm)

Incomplete recovery

An incomplete recovery is a recovery that involves rolling forward the redo logs to bring
the database to timestamp as far as the roll forward allows you with some lost of data. It
is as the name implied, a partial recovery.
Oracle incomplete recovery

In Oracle world, incomplete recovery is typically caused by

 Lost of a table
 Lost of online redo logs before they are archived
 Lost of archived redo logs preventing a roll forward beyond that point
 Lost of a control file with no backup

The underlying difference for complete and incomplete recovery lies in the inability to
proceed beyond certain timestamp due to various reasons listed above. Incomplete
recovery will require a reset of the logs by issuing Alter Database Open Resetlogs
command. Unlike complete recovery, you have to restore all data files, instead of only
the selected data files to be recovered. When doing incomplete recovery, you have to
make sure data files are online.

 Change-based recovery. Change-based recovery is a recovery that recovers until a

specified SCN. Eg. Recover database until change 87643
 Time-based recovery. Time-base recovery is a recovery that recovers until a
specified SCN. Eg. Recover database until time '2004-06-05:15:20:00'
 Cancel-based recovery. Cancel-based recovery is a recovery that recovers until
user key in cancel.Eg. Recover database until cancel. At this point in time roll
forward will go on until users decided to halt by keying cancel.
 Log sequence-based recovery Log sequence-based recovery is a recovery that
recovers until the specified log sequence number (only available when using
Recovery Manager).

Note that all transactions after the until will be lost. This is the nature of incomplete
recovery. Typically, after an incomplete recovery is carried out, there is a need to do an
offline backup immediately. All the redo logs after the alter database open resetlogs will
render useless and will not be good for recovery. Resetlogs simply means the sequence
number for the redo logs is reset.

We will also see some incomplete recovery case scenarios though not an exhaustive one
later in Recovery Case Scenarios. This article is not meant to address how to recover
from every single failure due to media failure.

Here are some example scenarios that could cause incomplete recovery in Oracle:

 Recovering from the loss of an unarchived online log file

o To investigate what status is the missing redo log is - a. select * from
v$logfile shows which group is INVALID b. select * from v$log shows
the archived status of the invalid group
o Now that you are confirmed that the lost redo file is an unarchived redo
log (archived=NO), shutdown the database - shutdown immediate
o Restore all datafiles from backup
 o Mount the database - Startup mount
o If the media is corrupted where the default filesystem cannot be written,
move the file to other location - a. In OS, find a directory to host the new
file and touch the file (same same) b. alter database rename file
'/oldpath/filename.log' to '/newpath/filename.log'
o Do a cancel based incomplete recovery - a. recover database until cancel
b. Press Enter til you see ora-00308 and ora-27037 c. Rerun recover
database until cancel but type CANCEL at the prompt this time
o Open the database and reset the logs - alter database open resetlogs (Note
after opening using resetlogs will create online log files)
o Do a user managed backups of the entire database
 Recovering from the loss of an only active redo log group
o To investigate what status is the missing redo log is - a. select * from
v$logfile shows which group is INVALID. b. select * from v$log shows
the status of the invalid group
o Now that you are confirmed that the lost redo file is an ACTIVE redo log,
shutdown the database - shutdown immediate
o Restore the backup
o Mount the database - Startup mount
o If the media is corrupted where the default filesystem cannot be written,
move the file to other location - a. In OS, find a directory to host the new
file and touch the file (same name). b. alter database rename file
'/oldpath/filename.log' to '/newpath/filename.log'. If the original filesystem
is good, skip this step.
o Do a cancel based incomplete recovery - a. recover database until cancel.
b. Press Enter until you see ora-00308 and ora-27037. c. Rerun recover
database until cancel but type CANCEL at the prompt this time
o Open the database and reset the logs - alter database open resetlogs
o Do a user managed backups of the entire database
 Recovering from the loss of the current redo log group
o To investigate what status is the missing redo log is - a. select * from
v$logfile shows which group is INVALID. b. select * from v$log shows
the status of the invalid group
o Now that you are confirmed that the lost redo file is a CURRENT redo
log, shutdown the database - shutdown immediate
o Restore the backup
o Mount the database - Startup mount
o If the media is corrupted where the default filesystem cannot be written,
move the file to other location - a. In OS, find a directory to host the new
file and touch the file (same name). b. alter database rename file
'/oldpath/filename.log' to '/newpath/filename.log'. If the original filesystem
is good, skip this step.
o Do a cancel based incomplete recovery - a. recover database until cancel.
b. Press Enter until you see ora-00308 and ora-27037. c. Rerun recover
database until cancel but type CANCEL at the prompt this time.
o Open the database and reset the logs - alter database open resetlogs
 o Do a user managed backups of the entire database

DB2 incomplete recovery

In DB2, an incomplete recovery may be caused by:

 The loss of the active log. This is probably the worst case scenario. It is therefore
imperative to use the database configuration parameter MIRRORLOGPATH to
mirror the active log.
o Seek help from IBM support.
 The loss of the archived log. In this scenario, you can only roll forward to a point
in time, to the last good archived log file, for example:
o db2 rollforward db sample to 2004-06-28-10.30.50.000000

Back to top

Conclusion

Backup and recovery are essential for any business environment where data loss must be
minimized if not totally avoided. Oracle and DB2 UDB both have mechanisms to backup
and restore both small and large databases. For small and medium databases, Oracle
provides both offline and conventional online backup (using Alter Tablespace ...Backup
Begin command). DB2 UDB provides offline and online backup as well. For offline
backup, the exclusive use is required to do a backup whereas online backup allow users
to connect while backup is in progress. The restore for table spaces or database can be
done by restoring a backup image and rolling forward. Both databases provide the roll
forward until a certain point in time and to the end of the logs.

Dealing with huge databases such as those in data warehouse environment, both Oracle
and DB2 provide incremental and differential backup to avoid copying unchanged data
pages. To use incremental backup or automate the online backup, Oracle recommends
Recovery Manager to be used.

Oracle and DB2 UDB both provide effective mechanisms and capabilities for securing
data from loss due to media corruption or human error. Using the information provided in
this article, you should find it easy to transfer your Oracle skills to the DB2 UDB
environment.