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. You have to import all succeeding log backups with the continuation command recover_replace (after return value -8020, see Database Manager CLI 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 Manager CLI 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 a third-party 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.
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.
You can display the ongoing status of the restore operation with the DBM command recover_state.
Note
Pay special attention to the Returncode reply field, which contains a numeric value for a message.
If it is clear from the message number that the restore was interrupted and not finished, you must continue the session with the continuation command (recover_replace) or terminate it with (recover_cancel).
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 (see load_systab).
You have the server authorization Recovery.
The database instance is in the ADMIN operational state.
You have opened a database session (see db_connect).
You have the necessary data and log backups to recover the database instance.
If you want to restore the database instance using a third-party backup tool, you have to have configured your SAP MaxDB software installation for the backup tool you want to use (see: Installation Manual, Connecting Third-Party Backup Tools).
recover_start <medium_name> <backup_type> [LABEL <label>] [EBID <ebid_list>] [AUTOIGNORE]
<ebid_list> :: = <external_backup_ID> | <external_backup_ID>,<external_backup_ID>,...
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>,...
Option |
Description |
---|---|
<medium_name> |
Backup template from which the backup is to be imported When importing a back up created on a group of parallel data carriers, you need to specify the name of the group here. (See medium_put, Database Administration, Backup Templates and Data Carriers) |
<backup_type> |
Type of backup to be imported. Possible values are: DATA | PAGES | LOG 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 backup to be imported and only for data carriers of the FILE type: Version number of the log backup on the data carrier 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 |
This option is only relevant when restoring to a group of parallel data carriers in the background. You use it to define that the system continues restoring automatically to the remaining data carriers only when one of the data carriers is full. This prevents you from having to react interactively (see: recover_config). Note Use this option only if you have the technical prerequisites for importing all data carriers of a backup simultaneously. End of the note. |
OK
Returncode <value>
...
Value |
Description |
---|---|
Date |
Date |
Time |
Start time for backup |
Server |
Name of the database computer |
Database |
Name of the database |
Kernel Version |
Version of the database kernel |
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 See also: Messages documentation |
Label |
Backup ID |
Is Consistent |
Only for data backup: Backup is internally consistent |
First LOG Page |
For data backup: first page of log backup to be read 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 which belong together |
If an error occurs you will receive a reply with the following information:
Value |
Description |
---|---|
<errcode> |
Error Message Number See: Messages documentation |
<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 backup tool could not be found or has been installed incorrectly. |
-24926 |
ERR_MEDIUMCHK: the medium cannot be used with this external backup tool |
The backup template specified cannot be used with this backup tool. |
-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 was unable to start the backup. |
-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 the database or the backup tool. |
-24921 |
ERR_POSTOP: cannot finish backup operation correctly |
Although the backup was successful, the required post-processing steps could not be performed. |
-24920 |
ERR_BACKUPOP: backup operation was unsuccessful |
The backup failed due to a problem with the database or with the backup tool. |
-24919 |
ERR_CLEANUP: cannot clean up correctly after backup operation |
Although the backup was successful, the system resources used during the check could not be released again. |
Database Manager CLI Tutorial, Restoring the Database Instance, Creating a Database Copy (Importing a Data Backup into Another Database Instance)
Database Administration, Restoring Databases