Recovery LOG Script
Hi we have copied our PRD system into a new box.
The new system is not a standby system of the PRD system, just a copy.
We have build a script that sends logbackups to tape and to this new system for recovery.
Is there a way to recover the log on the copied system with a script without user interaction?
I have tried this but no sucess
dbmcli -d PRD -u superdba,******* recover_start Autologbackup LOG
-24991,ERR_NODBSESSION: no database session available
Lars Breddemann replied
I knew this question would come up...
Fortunately I've written a note on this some time ago.
Restore log delivers message -7075
SAP Note Number: 1008304
When you reload log backups using recover_start or recover_replace, the system issues message -7075 and does not import the log backups.
-7075, Current SAVE SKIPPED, next is ready to take on this tape, standby DB, shadow database, log shipping
Reason and Prerequisites
You execute a log recover and receive return message -7075. (This may be the case, for example, for the permanent recovery of a shadow database.)
The MaxDB documentation describes the cause of the message stating that instead of the current log backup file (version file) one of the following files should be used.
In many cases, this is the correct response because the message can often be traced back to the fact that the log backup currently in use was already imported.
However, this is not always correct.
The message actually means that, at the current point in the recovery chain, it is not the turn of the log backup currently in use.
Therefore, it may be necessary to import a preceding log backup to enable you to import the current log backup.
One important feature of the recovery of log backups is that these must always be imported in the same sequence in which they were created.
The database generated the log backups LOG.001, LOG.002, LOG.003 and LOG.004.
When performing a recovery, they must be imported in the sequence in which they were generated: 001 - 002 - 003 - 004.
If the sequence is changed (for example 001 - 003 - 004 - 002), the MaxDB issues the following message for log 003: "-3004,invalid log-backup: IOSequence mismatch".
However, this is valid only if the recovery was not interrupted in the meantime (restore_cancel).
If you stop the recovery and start it again for log 003, the MaxDB returns the output:
Pages Transferred 0
Pages Left 0
First LOG Page
Last LOG Page
DB Stamp 1 Date
DB Stamp 1 Time
DB Stamp 2 Date
DB Stamp 2 Time
Page Count 0
Max Used Data Page
Converter Page Count
Although log 002 is required here, the system issues message -7075.
To determine which log backup is required next, the MaxDB uses the log pages in the log backup and the "First LOG Page" in the log area of the DB.
In the backup history, you can determine which log pages are contained in a log backup - for example in dbmcli:
backup_history_list -c LABEL,FIRSTLOG,LASTLOG -l LOG
The output then appears roughly as follows:
LOG_00001| 0| 995|
LOG_00002| 996| 1914|
As you can easily see, log backup 1 contains the log pages 0 to 995 and log backup 2 seamlessly follows on with log pages 996 to 1914.
You can use the command db_restartinfo to determine which log pages are still in the log area of the DB:
Used LOG Page 5245
First LOG Page 2147483647 (* see below)
Therefore, the DB has a status that is more advanced than log backup 1 or 2.
Therefore, you must import a log backup to which the following applies: "FIRSTLOG" <= "Used LOG Page".
This functions in the same way if the log backups were imported in succession "in one go"; that is, in a recovery session.
If the recovery was stopped in the meantime (recover_cancel), the DB requires a known starting point for the next time the recovery is started. This is the last imported log page, that is "Used LOG Page".
However, this last imported log page is in the last recovered log backup and not in the next logical one.
Therefore: If the log backup is started again (after a recover_cancel), you must first reimport the last imported log backup to provide the DB with the starting point.
Therefore, if a shadow database (standby DB) was provided with log backups using a script, the sequence should be as follows:
recover_start <medium name> LOG <X-1>
recover_replace <medium name> <path for the log backup> <X>
In doing so, keep in mind that log backup X must be imported here. Since the preceding log backup is already imported, it contains the starting point and therefore must be reentered (X-1) beforehand.
(*) Comment: This value for "First LOG Page" occurs if the log area of the DB was not yet described or there is a history-lost situation.
I hope this helps.