recover_start 

Use

You import backups of the database instance and recover the database status that they contain.

To recover the database instance completely, you first import the most up-to-date complete data backup. If you have created one or more incremental data backups after the complete data backup, you have to import them as well. To find out which data backup is the most up-to-date and which incremental data backups were made after it, look in the backup history (see backup_history_open).

After the data backup(s) have been imported, the system will display which log page to start importing the log backups with. You can also find this information in the backup history. On the basis of this information, select the first log backup to be imported. Then import the other log backups in chronological order.

You can look in the restart information to determine up to which log page you need to import the log backups. The system displays which log pages are still in the log area (i.e. beginning with which number) and thus can be restored by the system from that location (see db_restartinfo).

The backups to be imported must, in their entirety, comprise all the contents of the database without any gaps. The database system can only automatically recover the last log entries still in the log area if the log volumes are still intact.

If the log volumes still contain all the log entries since the last data backup import, it is enough to restart the database instance after importing the data backup(s) (see db_restart). The system then imports the content of the log area.

If you need to import more log backups after the data backup(s), the database system recognizes the page starting from which the missing content can be imported from the log area. The log backup import terminates at this point, the system recovers the remaining log pages from the log area and automatically transfers the database instance to the ONLINE operational state.

You can import both data backups that were created sequentially and data backups that were created on more than one data carrier in parallel into the database system.
Import data backups with the recover_start DBM command as well as the first log backup to be imported.

During a restore, you have to import all succeeding log backups with the continuation command recover_replace (after return value -8020).
See Database Administration Tutorial, Restoring the Database Instance

When you set up a standby instance, you have to import all succeeding log backups with recover_start (after return value -7075).
See Database Administration Tutorial, Setting Up and Updating Standby Instances

It is possible to recover the database instance only as far as a certain consistent state before a database or hard disk error occurred. When importing log backups, you can use an option to specify the point in time up to which the system imports the entries from the log backups or from the log area (as the case may be).

If you used another provider’s backup tool to make these backups, use that tool to import the backups. To do so, determine the backup ID of the required backup first (see: backup_ext_ids_get and backup_ext_ids_list). The Database Manager uses this ID to identify the backup that is to be imported.

For parallel import of the backups using this backup tool, the number of data carriers in a group of parallel data carriers must correspond exactly to the number of data carriers used to create the backup. In this case, it is not possible to start using fewer data carriers and to import the others as succeeding data carriers. You can also import all the data carriers of such a backup sequentially.

The reply to the recover_start DBM command displays information about the import of the backup. However, this information is only displayed when the backup has been imported completely, or if the backup was interrupted. This command may therefore take a long time to execute.

If the automatic log backup was activated before the recovery was started, it is not reactivated automatically after the recovery. To reactivate the log backup function, execute DBM command autolog_on.

If you updated the software after the database state that the recovery takes you back to, you need to reload the system tables to adjust them to the new software version.

If a deadlock occurs during the parallel recovery of the database instance with a backup tool, you have to import the data carriers in the group one after the other using the Database Manager.

See also:

Database Administration Tutorial

●      Restoring the Database Instance,

●      Creating a Database Copy (Importing a Data Backup into Another Database Instance)

Concepts of the Database System, Restoring the Database Instance

Prerequisites

●      You have the server authorization Recovery.

●      The database instance is in the ADMIN operational state.

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

If you want to restore the database instance using another provider’s backup tool, the following prerequisites must also be met:

●      You have configured your MaxDB software installation for the backup tool you want to use (see: Installation Manual, Connecting Backup Tools from Other Providers).

●      You have the necessary data and log backups to recover the database instance.

Syntax

Importing a Data Backup

recover_start <medium_name> <backup_type> [LABEL <label>] [EBID <ebid_list>] [AUTOIGNORE]

<ebid_list> :: = <external_backup_ID> | <external_backup_ID>,<external_backup_ID>,...

Importing a Log Backup

recover_start <medium_name> <backup_type> [LABEL <label>]  [<nnn> | EBID <ebid_list>] [UNTIL <date> <time>] [AUTOIGNORE]

<ebid_list> :: = <external_backup_ID> | <external_backup_ID>,<external_backup_ID>,...

Options

Option	Description
<medium_name>	Backup template from which the backup is to be imported When importing a backup that was created on multiple data carriers in parallel, you need to specify the name of the group of parallel data carriers here.
<backup_type>	Type of backup to be imported. Possible values are: DATA: complete data backup PAGES: incremental data backup LOG: log backup
LABEL <label>	Backup ID of the data carrier to be imported
<ebid_list>	List of external backup IDs If the list contains several backup IDs, then these must be separated by commas. If backup IDs contain spaces, the list must be enclosed in double quotation marks.
<external_backup_ID>	Only for importing a backup that was created with a backup tool: name under which the backup is known to the backup tool
<nnn>	Only for log backups to be imported and only for data carriers of the type FILE: version number of the log backup on the data carrier that is to be imported
UNTIL <date> <time> <date> ::= <yyyymmdd> <time> ::= <hhmmss>	Exact time (year, month, day, hour, minutes, seconds) up to which you want to recover
AUTOIGNORE	If you are recovering data in parallel, the process is automatically continued by the system.

Successful Reply

OK

Returncode              0

Date                    [<value>]

Time                    [<value>]

Server                  [<value>]

Database                [<value>]

Kernel Version          [<value>]

Pages Transferred       [<value>]

Pages Left              [<value>]

Volume Count            [<value>]

Mediumname              [<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>]

Database ID             [<value>]

Max Used Data Page      [<value>]

Values for the Reply Fields

Value	Description
Returncode	Return value 0 confirms that the backup was imported successfully.
Date	Date
Time	Time
Server	Name of the database computer
Database	Name of the database instance
Kernel Version	Version of the database software
Pages Transferred	Number of pages transferred
Pages Left	Number of pages still to be transferred
Volumes	Number of data carriers used
Medianame	Name of the backup template
Location	File or device name
Errortext	Error message text
Label	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
Max Used Data Page	Highest page number assigned (indication of minimum database size when backup is imported)

Reply in the Event of an Error

ERR

<err_code>, <err_description>

[<extended_description>]

Values for the Reply Fields

Value	Description
<err_code>	Error Message Number See also: Documentation, Messages
<err_description>	Description of the error
<extended_description>	Cause of error

 

The following errors (among others) may occur:

Error Message Number	Error message text	Explanation
-24927	ERR_TOOLCHK: the external backup tool was not found	The external backup tool could not be found or has been installed incorrectly.
-24926	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.
-24925	ERR_PREPARE: prepare of the backup operation failed	The preparations required to use the backup tool could not be completed correctly.
-24924	ERR_DBREQ: cannot start database kernel request	The database instance was unable to start the recovery operation.
-24923	ERR_TOOLREQ: cannot start external backup tool correctly	The backup tool could not be started correctly.
-24922	ERR_OPCHK: cannot check state of backup operation	Unable to check the status of database instance or backup tool.
-24921	ERR_POSTOP: cannot finish backup operation correctly	Although the recovery was successful, the post-processing steps required could not be performed.
-24920	ERR_BACKUPOP: backup operation was unsuccessful	The recovery failed due to a problem with the database of the backup tool.
-24919	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.