db_activate RECOVER


You initialize data and log volumes of the current database instance and import the data backed up in a complete data backup into the database instance. All the data previously contained in the current database instance is overwritten.

This command is also used to create a copy of a database instance, as is required for the creation of a standby database instance, for example.

In contrast to the DBM command for restoring a database instance (see: recover_start), when you execute db_activate RECOVER, all the catalog information and application data is deleted, along with the entries in the log area of the current database instance. Then the complete data backup is imported and the database state it contains is recreated.

After recovery with initialization, you need to load the system tables. (See: load_systab).

When you import the backup you overwrite all the original database user data of the destination instance with the data of the source instance. This is particularly significant if the source database from which the backup was created is different to the destination database into which the backup is imported. To continue working with the destination database instance, and in particular to load the system tables after importing the backup, you require the user data of the database system administrator of the source database instance. Only with this user data can you completely restore the data in the destination database instance. The DBM operator data of the destination database instance are retained.

If you used another provider’s backup tool to make the backups to be imported, you must use that tool to recover the database instance with initialization.

Once db_activate RECOVER has been executed, information on the recovery is displayed. This only happens when the backup has been completely imported or the process was interrupted. For this reason, the response to this DBM command can take a long time.

If the automatic log backup was activated before the recovery was started, it is not reactivated automatically after the recovery. To reactivate the log backups, execute the DBM command for activating automatic log backup (see: autolog_on).

See also:

Database Administration Tutorial, Restoring the Database Instance, Creating a Database Copy, Setting Up and Updating Standby Instances

Concepts of the Database System, Restoring the Database Instance, Database Copy, Shadow Database


?     You have the server authorization Recovery.

?     The database instance is in the ADMIN operational state.

?     You have opened a database session (see: db_connect).


db_activate RECOVER <medium_name> DATA [ExternalBackupID <external_backup_ID>] [AUTOIGNORE]





Name of the backup template that refers to the data carrier or the group of parallel data carriers from which the backup is to be imported.


Type of backup to be imported is DATA (complete data backup)

You only need to specify an entry here if you want to import a data carrier in whose backup template the backup type was not specified.

ExternalBackupID <external_backup_ID>

To restore a backup created with a backup tool, enter the backup ID name known to this tool.


The operation to restore multiple parallel data carriers is automatically continued by the system when it has finished importing the data from a single data carrier.



Returncode              <value>

Date                    [<value>]

Time                    [<value>]

Server                  [<value>]

Database                [<value>]

Kernel Version          [<value>]

Pages Transferred       [<value>]

Pages Left              [<value>]

Volume Count            [<value>]

Medianame               [<value>]

Location                [<value>]

Errortext               [<value>]

Label                   [<value>]

Is Consistent           [<value>]

First LOG Page          [<value>]

Last LOG Page           [<value>]

DB Stamp 1 Date         [<value>]

DB Stamp 1 Time         [<value>]

DB Stamp 2 Date         [<value>]

DB Stamp 2 Time         [<value>]

Page Count              [<value>]

Devices Used            [<value>]

Values for the Reply Fields






Start time for the creation of the imported data backup


Name of the database computer


Name of database instance

Kernel Version

Version of database kernel

Pages Transferred

Number of pages transferred

Pages Left

Number of pages still to be transferred


Number of data carriers used


Name of the backup template.


File or device name


Error message text


Backup ID

Is Consistent

For data backup only: backup is internally consistent

First LOG Page

For data backup: first page of log backup to be imported

For log backup: first page saved in log

Last LOG Page

For log backup only: last page saved in log

DB Stamp 1 Date
DB Stamp 1 Time

Time stamp for first page of log backup

DB Stamp 2 Date
DB Stamp 2 Time

Time stamp for last page of log backup

Page Count

Total number of pages backed up

Devices Used

Number of backup devices used

Database ID

Database ID used to identify data and log backups that belong together

Reply in the Event of an Error

If an error occurs while you are using a backup tool, you will receive a reply in the following format:

<errcode>, <err_description><NL>

Values for the Reply Fields




Error Message Number

See: Messages


Error message text


Cause of error

The following errors may occur:

Error Message Number

Error message text

Cause of error


ERR_TOOLCHK: the external backup tool was not found

The backup tool could not be found or has been installed incorrectly.


ERR_MEDIUMCHK: the medium cannot be used with an external backup tool

The specified backup template cannot be used with the backup tool referred to by the name of the backup template.


ERR_PREPARE: prepare of the backup operation failed

The preparations required to use the backup tool could not be completed correctly.


ERR_DBREQ: cannot start database kernel request

The database instance was unable to start the recovery operation.


ERR_TOOLREQ: cannot start external backup tool correctly

The backup tool could not be started correctly.


ERR_OPCHK: cannot check state of backup operation

Unable to check the status of database instance or backup tool.


ERR_POSTOP: cannot finish backup operation correctly

Although the recovery was successful, the post-processing steps required could not be performed.


ERR_BACKUPOP: backup operation was unsuccessful

The recovery failed due to a problem with the database of the backup tool.


ERR_CLEANUP: cannot clean up correctly after backup operation

Although the recovery was successful, the system resources used during the check could not be freed up again.