Administration Guide
Restore recovery using the BACKUP command in conjunction with the RESTORE
command puts the database or table space in a state that has been previously
saved.
The following topics provide additional information:
To make a backup copy of the database, you use the BACKUP command or the
Control Center. Within the Control Center, you select the database to be
backed up and then select the backup action.
Figure 26. Creating a Database Image
In a partitioned database system, you back up database partitions
individually using the BACKUP DATABASE command. The operation is local to the
database partition server where you issue the command. You can, however, issue
db2_all from one of the database partition servers in the
instance to submit the backup command on a list of servers, which you identify
by their node number. If you do this, you must back up the catalog node first,
then back up the other database partitions. You can also use the Control
Center to backup database partitions.
In a partitioned database system, you can use the LIST NODES command to
determine the list of nodes (database partition servers) that have user tables
on them. If you do not require forward recovery capability, regularly back up
the database on this list of nodes. If you want to be able to do forward
recovery, you must regularly back up the database on the list of nodes, and
you must have at least one backup of the rest of the nodes in the system (even
those that do not contain user data for that database).
Two situations require the backed-up image of a database partition at a
database partition server that does not contain user data for the
database:
- You added a database partition server to the database system after taking
the last backup, and you need to do forward recovery on this database
partition server.
- Point-in-time recovery is used, which requires that all database
partitions in the system are in the roll-forward pending state.
You must keep in mind the recovery method to be used. The following
sections provides requirements and other considerations that apply to this
task:
Your planning considerations should include:
- You must have SYSADM, SYSCTRL, or SYSMAINT authority to use the BACKUP
command.
- The database may be local or remote. The backup remains on the database
server unless a storage management product such as ADSTAR*
Distributed Storage Manager (ADSM) is used.
- You can back up a database or table space to a fixed disk, a tape, or a
location managed by ADSM or another vendor storage management product. See "ADSTAR Distributed Storage Manager" for information on ADSM.
Under OS/2, you can also back up to diskette or to a user exit.
- Under Windows NT and Windows 95, you can back up to diskette.
- Under OS/2, a user exit is used when backing up to tape because the
operating system has no native tape support.
Under UNIX-based operating systems and Windows NT, native tape support is
available.
- Roll-forward recovery is not enabled by the default setting ("Off")
of the logretain and userexit configuration parameters.
The default for both parameters is set to "Off" because, initially, there
is no backup that you can use to recover the database; initially, the
database cannot be recovered, so you cannot perform forward recovery on it.
To enable a new database for roll-forward recovery, you must enable at
least one of these configuration parameters before taking the first backup of
the database. When you change the value of one or both parameters, the
database will be put into the backup pending state, which requires
that you take an offline backup of the database. After the backup operation
completes successfully, the database can be used.
- A table space backup and a table space restore cannot be run at the same
time, even if the backup and restore are working on different table spaces.
- In OS/2, when backing up a database online to a user exit, please note
that the database will be quiesced before the backup starts. As such, the
backup will wait for all transactions to either commit or rollback before it
starts. While the backup is running, all new transactions will wait until the
backup is complete, and, once the backup is completed, all transactions will
continue processing as usual.
- If you have tables that span more than one table space, you should backup
(and restore) the set of table spaces together.
- If your database is enabled for roll-forward recovery and you are using a
tape system that does not support the ability to uniquely reference a backup,
it is recommended that you do not keep multiple backup copies of the same
database on the same tape.
- Multiple files may be created to contain the backed up data from the
database or table space.
In OS/2, when you restore from a user exit and roll forward the database,
the path to the database is the only reference used to locate the containers.
Therefore, all the containers for that database that are on the backup tape
are restored.
- In a partitioned database environment, an offline backup uses an exclusive
connection to the database at that database partition server (that is, the
operation requires an exclusive connection to the database partition), so no
other application can be connected to the database partition. When you do an
offline backup of the catalog node, there can be no activity on the
entire database, including backups of the database on non-catalog
database partition servers. You can use db2_all to back up the
database, but you must ensure that the catalog node is backed up first. After
the catalog node is backed up, the other database partitions can be backed up
at the same time.
- In a partitioned database system, you should also keep a copy of the
db2nodes.cfg file with any backup copies you take, as protection
against possible damage to this file.
The following considerations are useful when running the BACKUP
command:
- You must start the database manager (DB2START) before running the BACKUP
command or API. When using the Control Center, you do not need to explicitly
start the database manager.
- When using the command, API, or task under Control Center, you must
specify a database alias name, not the database name itself.
- To reduce the amount of time required to complete a backup:
- Use table space backups.
- Increase the backup buffer size.
- Increase the number of buffers.
If you use multiple buffers and I/O channels, you should use at least twice
as many buffers as channels to ensure that the channels do not have to wait
for data. The size of the buffers used will also contribute to the performance
of the backup operation. The ideal backup buffer size should be a multiple of
the extent size for the table space(s).
If you have multiple table spaces with different extent sizes, specify a
value that is a multiple of the largest extent size.
You may specify the number of pages to use for each backup buffer when you
invoke the BACKUP command. The minimum number of pages is 16. If you do not
specify the number of pages, each buffer will be allocated based on the
database manager configuration parameter backbufsz. If there is not
enough memory available to allocate the buffer, an error will be returned.
For details about the configuration parameter, see "Default Backup Buffer Size (backbufsz)".
- Use multiple target devices.
- Increase the level of parallelism by using the
intra_parallel database manager configuration parameter. For
more information about this parameter, see "Enable Intra-Partition Parallelism (intra_parallel)".
- You may select to only carry out a backup for part of a database (and
subsequent recovery) by using the TABLESPACE option of the BACKUP command.
This makes administering data, index, and long fields/large objects (LOBs) in
separate table spaces easier.
- In OS/2, when backing up a database to removable media, such as tape, the
database manager writes information to media volume 1. Once the first media is
in the drive, do not remove the media unless the operating system backup
facility prompts you for media 2.
- If each table space is on a different disk, a media error only affects a
particular table space, not the entire database. The table space with the
error is placed in a roll-forward pending state. You are still able to use the
other table spaces in the database.
If the table space in this state has the system catalog tables, you are not
able to connect to the database.
- The system catalog table space can be restored independent of the rest of
the database if a table-space level backup containing the system catalog table
space is available.
- The backup will fail if a list of the table spaces to be backed up
contains a temporary table space.
- You cannot back up a database that is not in a usable state except for a
database in the backup pending state.
- If a system crash occurs during a critical stage of backing up a database,
you cannot successfully connect to the database until you re-issue the BACKUP
command.
- The BACKUP command provides a concurrency control for multiple processes
that are making backup copies of different databases. The control keeps the
backup target device open until the entire backup process has ended.
If an error occurs during a backup process and the open container cannot be
closed, other backup processes to the same target drive may receive access
errors. To correct any access errors, you must completely exit the backup
process that caused the error and disconnect from the target device.
- If you are using the BACKUP command for concurrent backup processes to
tape, ensure that the processes do not target the same tape.
Backup images are created at the target specified when you call the BACKUP
command:
- In the directory for disk or diskette backups
- At the device specified for tape backups
- At an ADSTAR Distributed Storage Manager (ADSM) server
- At another vendor's server
- For OS/2, through the use of a user exit
The recovery history file is updated automatically with summary information
whenever you carry out a backup or restore of a full database or table space.
This file can be a useful tracking mechanism for restore activity within a
database. This file is created in the same directory as the database
configuration file. For more information on the recovery history file, see "Recovery History File Information".
In UNIX-based environments, the file name(s) created on disk will consist
of a concatenation of the following information, separated by periods; on
other platforms a four-level subdirectory tree is used:
- Database alias
- A 1-to-8 character database alias name that was supplied when the backup
command was invoked.
- Type
- Type of backup taken, where: "0" is for full database, "3"
is for table space, and "4" is for copy from a table load.
- Instance name
- A 1-to-8 character name of the current instance of the database manager
that is taken from the DB2INSTANCE environment variable.
- Node number
- The node number.
- Catalog node number
- The node number of the database's catalog node.
- Time stamp
- A 14-character representation of the date and time the backup was
performed. The timestamp is in the format yyyymmddhhnnss,
where:
yyyy is the year (1995 to 9999)
mm is the month (01 to 12)
dd is the day of the month (01 to 31)
hh is the hour (00 to 23)
nn is the minutes (00 to 59)
ss is the seconds (00 to 59)
- Sequence number
- A 3-digit sequence number used as a file extension.
In UNIX-based operating systems, the format would appear as:
Database alias.Type.Instance name.nodennnn.catnnnnn.timestamp.number
On other operating systems, the format would appear as:
Database alias.Type\Instance name.nodennn\catnnnn\yyyymmdd\hhmmss.number
For example in UNIX-based environments, a database named STAFF on the DB201
instance may be backed up on disk to a file named:
STAFF.0.DB201.NODE0000.CATN0000.19950922120112.001
For tape-directed output, file names are not created; however, the above
information is stored in the backup header for later verification purposes.
Notes:
- If you want to use tape media for database back-up and restore operations,
a tape device must be available through the standard operating system
interface. On a large partitioned database system, however, it may not be
practical to have a tape device dedicated to each database partition server.
You can connect the tape devices to one or more ADSM servers, so that access
to these tape devices is provided to each database partition server.
- On a partitioned database system, you can also use products that provide
virtual tape device functions, such as REELlibrarian 4.2 or CLIO/S. You use
these products to access the tape device connected to other nodes (database
partition servers) through a pseudo tape device. Access to the remote tape
device is provided transparently, and the pseudo tape device can be accessed
through the standard operating system interface.
The following sections provide requirements and other considerations that
apply to the RESTORE command:
Figure 27. Restoring a Database Using a Backup Image
| Note: | Because restore is required as part of the roll-forward recovery method, all
information about restore also applies to that method as well.
|
You should consider the following:
- You must have SYSADM, SYSCTRL, or SYSMAINT, authority to restore to an
existing database from a full database, or table space, backup. To restore to
a new database, you must have SYSADM or SYSCTRL authority.
- You can only use this command if the database or table space has been
previously backed up with the BACKUP command.
- If you use the Control Center, you cannot restore backups that were taken
previous to DB2 Version 5.
- In OS/2, the RESTORE command can call a user exit program only if a user
exit program was used to backup the database.
- If you backed up tables that spanned more than one table space, you should
restore the set of table spaces together.
- You can choose at the time of the restore which type of restore is to be
carried out. You can select from the following types:
- A full restore of everything from the backup
- A table space restore
- A restore of only the recovery history file
- When doing a partial or subset RESTORE, you can use either a table space
backup, or a full database backup and choose one or more table spaces from
that image. All the log files associated with the table space (or table
spaces) must exist from the time the backup was created.
In a partitioned database system, if you intend to roll forward a table
space (or table spaces) to the end of the logs, you do not have to restore it
at each database partition (node). You only need to restore it at the database
partitions that require recovery. If you intend to roll forward a table space
to a point in time, you must restore the table space at each database
partition before rolling forward.
- You can perform a partial or subset restore of a backup created using
Version 5 of DB2. This cannot be done with earlier versions of DB2. A partial
or subset restore is only possible with a recoverable database. A recoverable
database has either the logretain or userexit (or both)
configuration parameters enabled to allow roll-forward recovery to occur. With
a recoverable database, once the restore is complete, the table space (or
table spaces) must be rolled forward (at the end of the restore, each table
space that was restored is in the roll-forward pending state).
- In OS/2, a partial or subset restore is not possible when restoring from a
user exit.
- The RESTORE command can use the ADSTAR Distributed Storage Manager (ADSM)
utility, and any restrictions of that utility should also be considered. (See "ADSTAR Distributed Storage Manager".)
- Another vendor storage management product may also be used if that product
was used to store the original backup.
- A database restore requires an exclusive connection: that is, no
applications can be running against the database when the task is started.
Once it starts, it prevents other applications from accessing the database
until the restore is completed.
- A table space restore can be online (share mode) or offline (exclusive
mode).
| Note: | You cannot do an online table space restore of the system catalog tables.
|
- The database may be local or remote.
The following considerations are useful when running the RESTORE
command:
- The database manager must be started before restoring a database.
- The database to which you restore the data may be the same one as the data
was originally backed up from, or it may be different. You may restore the
data to a new or an existing database.
| Note: | If you are restoring a table space (or table spaces), the backup image must
have been taken from the same database that holds the table space (or table
spaces).
|
- A database enabled for roll-forward recovery must be rolled forward after
it is restored, unless a restore without roll-forward is specified through the
RESTORE command. You may not turn roll-forward off if the backup is taken
online or if the backup is taken at the table space level.
- During the restore procedures, you have the ability to optionally select
to use multiple buffers to improve the performance of the restore procedure.
The multiple internal buffers may be filled with data from the backup media.
You may specify the number of pages to use for each restore buffer when you
invoke the RESTORE command. The value you specify must be a multiple of the
number of pages that you specified for the backup buffer. The minimum number
of pages is 16. If you do not specify the number of pages, each buffer will be
allocated based on the database manager configuration parameter
restbufsz. If there is not enough memory available to allocate the
buffer, an error will be returned.
For details about the configuration parameter, see "Default Restore Buffer Size (restbufsz)".
- The TAKEN AT parameter of the RESTORE DATABASE command requires the
timestamp for the backup. The timestamp can be exactly as it was displayed
after the completion of a successful BACKUP command, that is in the format
yyyymmddhhmmss.
You can also specify a partial timestamp. For example, assume that you have
two different backups with the timestamps 19971001010101 and 19971002010101.
If you specify 19971002 for TAKEN AT, the 19971002010101 backup is used.
If TAKEN AT is not specified, there must only be one backup on the source
media.
- The backup copy of the database or table space to be used by the RESTORE
command can be located on a fixed disk, a tape or a location managed by the
ADSTAR* Distributed Storage Manager (ADSM) utility or another vendor
storage management product. See "ADSTAR Distributed Storage Manager" for information on ADSM.
Under OS/2, the backup copy of the database or table space could also be
located on diskette or through a user exit.
Under Windows 95 and Windows NT, the backup copy of the database or table
space could also be located on diskette.
- While restore and roll-forward are independent operations, your recovery
strategy may have restore as the first phase of a complete roll-forward
recovery of a database. After a successful restore, a database that was
configured for roll-forward recovery at the time the backup was taken enters a
roll-forward pending state, and is not usable until the ROLLFORWARD command
has been run successfully.
When the ROLLFORWARD command is issued:
- If the database is in the roll-forward pending state, the database is
rolled forward.
- If the database is not in the roll-forward pending state, but table spaces
in the database are, when you issue the ROLLFORWARD command and specify a list
of table spaces, only those table spaces are rolled forward. If you do not
specify a list, all table spaces that are in the roll-forward pending state
are rolled forward.
Another database RESTORE is not allowed when the roll-forward process is
running.
Notes:
- If you are restoring from a full database backup that was created using
the offline option of the BACKUP command, you can bypass this
roll-forward pending state during the restore process. Using the WITHOUT
ROLLING FORWARD option allows you to use the restored database immediately
without rolling forward the database.
- If you are restoring from a backup that was created using the
online option of the BACKUP command, you cannot bypass
this roll-forward pending state.
- Once the RESTORE command starts, the database is not usable until the
RESTORE command completes successfully.
- Once the RESTORE command starts for a table space backup, the table space
is not usable until the RESTORE command followed by a roll-forward recovery
completes successfully.
- If a system failure occurs during any stage of restoring a database, you
cannot connect to the database until you reuse the RESTORE command and
successfully complete the restore.
- If a system failure occurs during the restoring of a table space backup,
only the table space being restored is unusable. The other table spaces in the
database can still be used.
- If the code page of the database being restored does not match a code page
available to an application; or, if the database manager does not support code
page conversions from the database code page to a code page that is available
to an application; then the restored database will not be usable.
- In OS/2, if you backed up your database using the sqluback API
in a previous release of DB2, then you must use the sqludres API to
restore your database. However, this API is no longer supported by the command
line. To restore a back-level backup from the command line, use the
db2resdb utility provided in the misc subdirectory of
the sqllib directory. This utility will make the call to the
sqludres API on your behalf, restore the database to the target
drive, then attempt to migrate it to the current release.
The syntax for this utility is:
db2resdb <dbname> <source drive> <target drive>
where
dbname = The name of the database which was backed up
source drive = The drive letter where the backup resides
target drive = The drive letter where the database is to be created
During a backup of a database or one or more table spaces, a record is kept
of all the table space containers in use by the table spaces that are backed
up. During a RESTORE, all containers listed in the backup are checked to see
if they currently exist and are accessible. If one or more of the containers
is inaccessible because of a media failure (or for any other reason), the
RESTORE will fail. In order to allow a restore in such a case, the
redirecting of table space containers is supported during the
RESTORE. This support includes adding, changing, or removing of table space
containers.
There are cases in which you want to restore even though the containers
listed in the backup do not exist on the system. An example of such a case is
where you wish to recover from a disaster on a system other than that from
which the backup was taken. The new system may not have the necessary
containers defined. In order to allow a RESTORE in this case, the
redirecting of table space containers at the time of the RESTORE to
alternate containers is supported.
In both situations, this type of RESTORE is commonly referred to as a
redirected restore.
You can redefine table space containers through the restore task from
within the Control Center. You can also use the REDIRECT parameter of the
RESTORE command to specify the redirection. If you are using the Control
Center, one way of performing a redirected restore is to use the Containers
page of the Restore Database notebook. This page provides function that you
can use to add new containers, change the path of an existing container, or
remove a container. If, during the process of the restore database operation
an invalid container path is detected, the Control Center will prompt you to
either change the container path, or remove the container.
A RESTORE is often followed by a ROLLFORWARD to reapply
changes recorded in the database logs after the point in time where the backup
was taken. During a roll-forward operation, you may re-execute or re-run a
transaction which carries out an ALTER TABLESPACE with the ADD
option (to add a container). For the ROLLFORWARD to be successful, the
container to be added must be accessible. If the container is not accessible,
then the roll-forward for the table space is suspended, and the table space is
left in a roll-forward pending state.
You may or may not wish to re-do the add container operations in the
database logs. Recalling our previous disaster recovery example, you may not
know which containers may have been added since the backup was taken.
Therefore, you cannot anticipate which containers are needed. Alternatively,
depending on why you are performing a redirected restore, you may simply
prefer the list of containers you specified at the time of the restore, and do
not want any other containers added. To control this behavior, you can
indicate at the time of the restore whether you want the ROLLFORWARD to
re-create the containers during the roll-forward recovery. This is specified
on the CONTAINERS - CHANGE window where you edit the list of table
space containers.
Notes:
- Directory and file containers are automatically created if they do not
exist. No redirection is necessary unless the containers are inaccessible for
some other reason. The database manager does not automatically create device
containers.
- The ability to perform container redirection on any RESTORE provides
considerable flexibility in managing table space containers. For example, even
though we do not directly support adding containers to SMS table spaces, you
could accomplish this by simply specifying an additional container on a
redirected restore. Similarly, you could move a DMS table space from file
containers to device containers.
- Redirected restore is also supported through a number of APIs. Although
you could write a program to perform redirected restore for a specific case,
these APIs are primarily intended for developers who want to produce a general
purpose utility.
You may restore a backup copy of a full database backup or table space
backup to an existing database or one or more table spaces. To restore to an
existing database, you must have SYSADM, SYSCTRL, or SYSMAINT authority. The
backup image may differ from the existing database in its alias name, its
database name, or its database seed.
A database seed is a unique identifier of a database that remains constant
for the life of the database. This seed is assigned by the database manager
when the database is first created. The seed is unchanged following a restore
of a backup even if the backup has a different database seed. DB2 always uses
the seed from the backup.
| Note: | You can only restore a table space if the table space currently exists, and
it is the same table space. (The "same table space" means that the table
space was not dropped and re-created between taking the backup image and the
attempt to restore the table space.)
|
When restoring to an existing database, the restore task performs the
following functions:
- Delete table, index, and long field contents for the existing database,
and replace them with the contents from the backup.
- Replace table space table entries for each table space being restored.
- Retain recovery history file unless the one on disk is damaged. If the
file on the disk is damaged, the database manager will copy the file from the
backup.
- Retain the authentication for the existing database.
- Retain the database directories for the existing database that define
where the database resides and how it is cataloged.
- When the database seeds are different:
- Delete the logs associated with the existing database
- Copy the database configuration file from the backup
- Change the database configuration file to indicate that the default log
file path should be used for logging
- When the database seeds are the same:
- Retain the current database configuration file, unless the file is
corrupted, in which case this file will be copied from the backup.
- Delete the logs if the image is of a non-recoverable database;
otherwise, the logs will be kept. The log path (which is specified by the
logpath parameter) is also changed to the value specified in the
database configuration file that is in the backup.
As an alternative to restoring a database to a database that already
exists, you may create a new database and then restore the backup of the data.
To restore to a new database, you must have SYSADM or SYSCTRL authority.
Notes:
- You cannot restore a table space backup to a new database.
- The code pages of the backup and the target database must match. If they
do not, first create the new database specifying the correct code page, then
restore it.
In this case, the RESTORE command will perform the following
functions:
- Create a new database, using the database name and database alias name
that was specified by the target database alias parameter. (If this target
database alias was not specified, the RESTORE command will create a database
with the name and alias the same as the source database alias parameter.)
- Restore the database configuration file from the backup.
- Modify the database configuration file to indicate that the default log
file path should be used for logging.
- Restore the authentication type from the backup.
- Restore the database comments from the backup for the database
directories.
- Restore the recovery history file for the database.
A recovery history file is created with each database and is automatically
updated whenever there is a:
- Database or table space backup
- Database or table space restore
- Database or table space roll forward
- Table space quiesce
- Load of a table
Figure 28. Creating and Updating the Recovery History File
The file contains a summary of the backup information that can be used in
the event that all or part of the database must be
recovered to a given point in time. The information in the file
includes:
- The part of the database that was copied and how
- The time the copy was made
- The location of the copy (stating both the device information and the
logical way to access the copy)
- The last time a restore was done.
Every backup operation (both table space and full database) includes a copy
of the recovery history file. The recovery history file is linked to the
database. Dropping a database deletes the recovery history file. Restoring a
database to a new location restores the recovery history file. Restoring does
not overwrite the existing history recovery file.
If the current database is unusable or not available and the associated
recovery history file is damaged or deleted, an option on the RESTORE command
allows only the recovery history file to be restored. The recovery history
file can then be reviewed to provide information on which backup to use to
restore the database.
The size of the file is controlled by the rec_his_retentn
configuration parameter (see "Recovery History Retention Period (rec_his_retentn)") that specifies a retention period (in days) for the entries in the file.
Even if the number for this parameter is set to zero (0), the most recent full
database backup plus its restore set is kept. (The only way to remove this
copy is to use the PRUNE with FORCE option.) The retention period has a
default of 366 days. The period can be set to an indefinite number of days by
using -1. In this case, explicit pruning of the file is required.
You can query and run commands against the recovery history file by using
an API function call, the command line processor, or the Control Center. The
five (5) basic queries and commands are: OPEN, CLOSE, GET NEXT, UPDATE,
and PRUNE. (For more information on the command syntax see the Command Reference. For more information on the API function call, see the API Reference. For more information on the Control Center, access the Control Center from
your workstation.)
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]
[ DB2 List of Books |
Search the DB2 Books ]
