!--a11y-->
Performing Logical Restore for a Full-System Cold Restore (ON-Archive) 
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.
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
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
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.
$ 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.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).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.

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.
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.

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.
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.
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 -You can see the results by looking in the
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