Restoring Clean Log(s) onto the Secondary Database

This procedure enables all clean logs created since the last backup (if you followed the procedure in Rebuilding and Restoring the Secondary Database) or since the system failure (if you recovered the secondary database via Rapid Recovery), except for the current clean log, to be restored on the secondary database (previously failed primary), so as to bring the new secondary up-to-date with the new primary ready for synchronisation using Database Recovery option 4.

Notes:

This procedure must be carried out from the primary database.
If you recovered the secondary database via Rapid Recovery, the secondary may be up-to-date apart from the active clean log. In this case, tlmenu will display a message indicating that there are no clean logs to be restored.

Procedure

Select option 3 on the Database Recovery menu. A message is then displayed describing the purpose of the procedure and prompting you to confirm that you wish to continue.
When you enter y at the confirmation prompt, a check is made to see if the secondary database has been brought up-to-date.

The following error message may indicate that you have restored the wrong backup or that logging has never been run on the restored database. If in doubt, call Support.
```
Warning: Unable to identify remote Clean log and 
unable to continue with this procedure

Hit return to continue:
```
tlmenu then looks for the first clean log.

If the first clean log is still on disk on the new primary, the following is displayed:
```
Clean Log clog_first exists on the primary database.

Do you want to copy it to the secondary (y/n/q) ? :
```
If it has been deleted, then you are prompted with:
```
Clean Log clog_first does not exist on disk, or is incomplete on disk.
Do you want to restore Clean Log clog_first from tape (y/n/q) ? :
```
This is asking if you want to load an archived tape onto the secondary database.

In either case, enter y if you want to copy the first clean log (clog_first) from the new primary to the secondary, or load it from tape onto the secondary.

If clog_first was active when the old primary (now the secondary) failed, then it will already exist on the recently restored secondary, but be corrupted. The corrupt clean log is therefore deleted from the secondary first, before the correct version is copied across. Hence the following message:
```
Deleting Clean Log clog_first from secondary...
```
If you chose to restore a clean log from tape, you will then be prompted to set up the tape device on the secondary database, before retrieving it from tape.
A list of tape devices configured on the remote database is displayed, after which you are prompted to select one to load the clean log. Enter the number of the tape device to use for loading the clean log. The clean log load is then executed.

Once the clean log is on the secondary database, you are asked:

Do you want to tlrestore clog_first  (y/n/q) ? :

Enter y to start the restore. This should result in a number of messages:

Clearing TL-REJECT 
Clearing TL-LIST

Transaction logging restore of clog_first complete
    n Images applied
    m Images rejected

Next log clog_next

is displayed, followed by the prompt:

Do you want to copy clog_next to the secondary (y/n/q) ? :

Do you want to restore Clean Log clog_next from tape (y/n/q) ? :

Steps 3 to 6 are repeated until all clean logs, from the clean log active at the time of backup to the clean log used just before the current active log, are restored onto the secondary database, at which point, if all clean logs have been restored, the following message is displayed:
```
Restore of secondary database complete

Now select option 4 to resynchronise the primary and secondary databases.

Hit return to continue:
```
This returns you to the Database Recovery menu. You must now use option 4 on this menu to resynchronise the secondary with the primary.