Skip to Content

Archived discussions are read-only. Learn more about SAP Q&A

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

Any help?

Former Member
replied

I knew this question would come up...

Fortunately I've written a note on this some time ago.

-


8<--snip----- Restore log delivers message -7075 SAP Note Number: 1008304 Symptom When you reload log backups using recover_start or recover_replace, the system issues message -7075 and does not import the log backups. Other terms -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.) Solution 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. For example: 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: OK Returncode -7075 Date Time Server Database Kernel version Pages Transferred 0 Pages Left 0 Volumes Medianame Location Errortext Label Is Consistent 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 Devices Used Database ID 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_open 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: db_restartinfo 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: db_admin recover_start <medium name> LOG <X-1> recover_replace <medium name> <path for the log backup> <X> recover_cancel 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. -
>8--snap---

I hope this helps.

regards,

Lars

0 View this answer in context
Not what you were looking for? View more on this topic or Ask a question