Administration Guide
Version recovery using the BACKUP command in conjunction with the RESTORE
command puts the database in a state that has been previously saved.
You use this recovery method with non-recoverable databases (that is,
databases for which you do not have archived logs). You can also use
this method with recoverable databases by using the WITHOUT ROLLING FORWARD
option.
In this section, planning considerations and how to invoke the specific
utilities or commands to carry out the method are reviewed. Then, any
concepts or related issues that allow effective use of this method are
presented.
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 32. 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. Because this recovery method does not support roll-forward
recovery, regularly back up the database on this list of nodes.
In a distributed request system, the BACKUP and RESTORE commands apply to
the distributed request database and the metadata stored within that database
catalog (wrappers, servers, nicknames, etc.). Data source
objects (tables and views) are not backed-up or restored unless those objects
are stored in the distributed request database.
You must keep in mind the recovery method to be used. The following
sections provide 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 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.
| Note: | In OS/2, when backing up a database online to a user exit, 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.
|
- 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.
| Note: | If you use a variable block size with your tape devices, ensure that the DB2
buffer size is either less than or equal to the maximum variable block size
that the device is configured for. Otherwise, the backup will succeed
but the resulting image is not guaranteed to be recoverable.
|
- Multiple files may be created to contain the backed up data from the
database.
- 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.
If you have tables that contain DATALINK columns, also see Backup Utility Considerations.
To use tape devices, DB2 users on SCO UnixWare 7 must specify BUFFER to be
16. The default value of BUFFER is 1024 pages. If BUFFER is set
to zero, the database manager configuration parameter BACKBUFSZ
must be set to 16.
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:
- Increase the value of the PARALLELISM parameter.
Using this parameter can dramatically reduce the amount of time required to
complete the backup. The PARALLELISM parameter defines the number of
processes or threads that are started to read data from the database.
Each process or thread is assigned to back up a specific table space.
When it completes backing up the table space, it requests another. You
should note, however, that each process or thread requires both memory and CPU
overhead: for a heavily loaded system, you should leave the PARALLELISM
parameter at its default value of 1.
- 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.
Refer to Administration Guide, Performance for more information on this configuration parameter.
- Use multiple target devices.
- 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.
- 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. 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.
- 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 33. Restoring a Database Using a Backup Image
You should consider the following:
- You must have SYSADM, SYSCTRL, or SYSMAINT, authority to restore to an
existing database from a full database backup. To restore to a new
database, you must have SYSADM or SYSCTRL authority.
- You can only use this command if the database has been previously backed
up with the BACKUP command.
- If you use the Control Center, you cannot restore backups that were taken
previous to the current version of DB2.
- In OS/2, the RESTORE command can call a user exit program only if a user
exit program was used to backup the database.
- 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 restore of only the recovery history file
- 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.
- The database may be local or remote.
- If the WITHOUT DATALINK option is not specified, and the DB2 Data Links
Manager containing the DATALINK data is not available, then the restore
operation will fail.
If the option is specified and the DB2 Data Links Manager containing the
DATALINK data is not available, all table spaces containing tables with
DATALINK values on the unavailable server are placed in the RESTORE PENDING
state. These table spaces must be restored again when the Data Links
server becomes available.
- To use tape devices, DB2 users on SCO UnixWare 7 must specify BUFFER to be
16. The default value of BUFFER is 1024 pages. If BUFFER is set
to zero, the database manager configuration parameter BACKBUFSZ
must be set to 16.
If you have tables that contain DATALINK columns, see both Restore and Rollforward Utility Considerations and Restoring Databases from an offline Backup without Rolling Forward.
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.
- 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.
Refer to Administration Guide, Performance for more information on this configuration parameter.
- 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 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.
If you use ADSM and do not specify the TAKEN AT parameter, ADSM retrieves
the latest backup copy.
Under OS/2, the backup copy of the database could also be located on
diskette or through a user exit.
Under Windows 95 and Windows NT, the backup copy of the database could also
be located on diskette.
- Once the RESTORE command starts, the database is not usable until the
RESTORE command 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 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, 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.
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 to an existing
database. 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.
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. 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.
| Note: | 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.
|
When you restore to a new database, 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.
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]
[ DB2 List of Books |
Search the DB2 Books ]
