Entering content frame

Procedure documentation Performing Logical Restore for a Full-System Cold Restore (ON-Archive) Locate the document in its SAP Library structure

Use

This is the final stage in a full-system cold restore if you use ON-Archive as your data recovery tool (that is, for your archives and backups). This section includes how to do a "Point-in-Time" (PIT) restore.

Note

The logical restore is not compulsory. For example, if you cannot use the logical logs for some reason (that is, they have been damaged or lost), you can restart the database after the physical restore but it is less up-to-date. Refer to the step "Bring the database server back up without a logical restore" in Performing Physical Restore for Full-System Cold Restore (ON-Archive).

However, when you restore from a parallel archive, you must also perform logical restore, because the data in the logical log is needed to synchronize the different parts of the archive.

Prerequisites

Procedure

  1. Start ondatartr with first volume of logical-log backup.
  2. After physically restoring all dbspace sets, you need to restore the logical log to bring your database up-to-date with the most recent transactions from before the restore situation.

  3. To perform the logical restore, enter a command like the following:
  4. $ ondatartr 'retrieve/logfile/tape=(/dev/rmt/1m)'

    You see a response like the following:

    Executing...

    Logical restore started with log number 345

    Make sure that the tape device specified ( /dev/rmt/1m in this example) is present or you might run into problems later.

    ondatartr recognizes the first logical-log file needed for the logical restore. This is the logical-log file that was either current or contained the oldest open transaction at the time of the most recent level-0, level-1 or level-2 archive.

  5. Identify the tape volume that contains the first logical-log file.
  6. You need to find the save set ID of the tape containing the first logical-log file. In this example, the save set ID 202 corresponds to the logical-log file 345. To find the save set ID, use the SAPDBA recovery report, look in the archive.log file, or use physical tape labels (assuming you wrote details on your tapes when they were created).

  7. Mount the tape and enter the save set ID for the first logical-log file when prompted:
  8. Mount the volume with the archived data.

    Press the return key when ready.

    What saveset ID is to be used on volume /dev/rmt/1m?: 202

    You cannot change the tape drive once started so make sure you get the correct tape mounted first time.

    Note

    You can specify a PIT restore, in which data is restored only up to the point in time that you specify. In this case, you must add an additional parameter to the end of the ondatartr command shown above. The following example shows how you would specify a recovery up to 13:48:00 on 25th January 1999:

    $ ondatartr 'retrieve/logfile=SET0000010/tape=(/dev/rmt/1m)/
    until=(25-Jan-1999:13:48:00)'

    If you specify a PIT before the last checkpoint for the relevant level-0 archive (or level-1 or level-2 archive, whichever is used), you receive an error message from ondatartr .

    Logical restore starts after you enter the save set ID for the first logical-log file.

  9. Continue with remaining logical-log files.
  10. The database server processes the logical-log files in the first save set and then prompts for more logical-log files when it reaches the end of the save set:

    Do you have more log backups to process? (Y/N):

    Answer yes if either of the following is true:

    · You have another save set containing logical-log files that you need to restore.

    · You are now ready to restore the files that you salvaged earlier in the restore process.

    Make sure that the tape is available. If you answer yes and there is no tape, you might encounter problems later. In the example, the save set ID of the salvaged logs is 1345.

    Note

    If you are doing a point-in-time (PIT) restore, you are only prompted for backup tapes between the time of the level-0 archive (or level-1 or level-2, whichever is used) and the time of the PIT. If the PIT is later than the most recent tape, then the recovery runs as usual and you do not receive any extra messages.

    If the PIT is reached, look in the message-log file. You see a sequence such as in the following example:

    PIT - reached:

    --------------

     

    12:53:47 Logical Recovery Started.

    12:53:47 Checkpoint Completed: duration was 0 seconds.

    12:53:47 Start Logical Recovery - Start Log 17, End Log ?

    12:53:47 Starting Log Position - 17 0x2f6378

    12:56:23 PIT reached - logid: 17, logpos: 0x2f7098

    12:56:32 Logical Recovery Complete.

    0 Committed, 1 Rolled Back, 0 Open, 0 Bad Locks


    12:56:32 Dropping temporary TBLspace 100020, recovering 64 pages.

    12:56:32 Dropping temporary TBLspace 100021, recovering 64 pages.

    12:56:32 Dropping temporary TBLspace 100022, recovering 64 pages.

    12:56:32 Logical Recovery Complete.

    12:56:33 Quiescent Mode

    12:56:33 Checkpoint Completed: duration was 0 seconds.

  11. Bring the database server online after the restore.
  12. When the logical restore is finished, enter no to the prompt Do you have more log backups to process? (Y/N) . The database server is now in quiescent mode and you are returned to the operating system command line.

    Use SAPDBA to bring the database server online. Refer to Changing Server Mode with SAPDBA.

    Note

    If you are doing a point-in-time (PIT) recovery and the PIT is reached during the restore, you are simply returned to the operating system command line without a message, and the database server goes into quiescent mode. You can check the following:

    · That the PIT recovery has functioned correctly by looking in the online message-log file (see the note in step " Continue with remaining logical-log files" above)

    · That quiescent mode has been reached by entering the following command:

    $ onstat -

  13. Check the results of the logical restore.

You can see the results by looking in the archive.log file. An example from this file is given below:

Apr 07 1995 09:47:20 #00000016# <28282> ondatartr (informix) Begin retrieve logfiles

09:47:26 #00000015# <27332> Retrieve LF00000013 #00000003# from LOGTAP:0001

09:47:54 #00000015# <27332> Retrieve LF00000014 #00000003# from LOGTAP:0001

09:48:39 #00000015# <27332> Retrieve LF00000015 #00000008# from LOGTAP:0001

Apr 07 1995 09:49:03 #00000015# <27332> ondatartr (informix) End retrieve logfiles: SUCCESS

Result

The database is now restored and you can use the R/3 System productively again.

 

See also:

Informix documentation

Leaving content frame