Checking/Reconfiguring Databases Prior to Recovery

Caution

Ensure that the old primary has been shutdown before you attempt this.

This procedure when selected on the secondary allows you to reconfigure the secondary database as the primary and enable users to logon while the old primary database is repaired. It also checks that the configuration of the remote database is correct and allows it to be reconfigured, if necessary.

When selected on the primary, this procedure only checks the remote database configuration. Refer to the topic Checking Configuration of Remote Database.

Notes:

The functionality of option 1 is different when selected on primary and secondary databases. See description below. This is reflected by the option name. See FailSafe Database Recovery Menu.
Logging must be inactive before you can perform the operation.

Reconfiguration Procedure On a Secondary Database

On the old secondary/new primary, select option 1 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.

After entering y at the confirmation prompt, the subsequent procedure to re-configure the secondary as a primary depends on the secondary's current status.

The secondary's status may be:

PASSIVE-RESTORING (that is, performing updates in line with the primary)

or
PAUSED (for example, to backup the system)

Re-configuring a Passive-Restoring Secondary

If the secondary is PASSIVE-RESTORING, the procedure to convert the secondary to be an active standalone primary is executed without further user intervention. When you select option 1 on the Database Recovery menu and enter y at the confirmation prompt, the following steps are performed:

The secondary is reconfigured as a primary, which unlocks the database.
Active transactions are discarded.

Reconfiguring a Paused Secondary

If the secondary is PAUSED, the procedure is more complicated, as the secondary database is currently out of sync. with the failed primary. It is necessary, after changing the secondary to a primary, to stop logging and restore the currently active clean log onto the new primary to bring it up to date with the failed primary, then restart logging again.

The procedure is as follows:

The secondary failed flag is cleared.
The paused secondary is reconfigured as a primary and kept locked.
You are prompted for a clean log name to restart Transaction Logging on the new standalone primary database. The prompt is as follows:
```
Restart from

1.  Another Clean Log for today (CLOG990731-02)
2.  Next Day's Clean Log (CLOG990801-01)
3.  Clean Log for named day or date
4.  A named Clean Log

Enter option (1-4) : _
```
Select the option you require. See Clean Log Menu Options for a description of the above menu options.
Logging is stopped. You are then asked if you wish to copy the current active clean log from the failed primary to the new primary.

If you answer y the current active log is restored on the database so that the new primary is brought up-to-date with the failed primary. If you answer n, a message is displayed warning you that updates will be missing from the active clean log on the new primary, if you choose to continue.

Logging to the selected clean log is then restarted and the new standalone primary is unlocked to users.

Checking the Configuration of Remote Database

This procedure is carried out when tlmenu is run on the primary database, or immediately after the re-configuration procedure, described previously, if tlmenu is run on the secondary database. It checks that the remote database is configured as an inactive secondary and that no-one is logged on to it.

If the configuration is incorrect, then it displays the warning prompt:

Warning: Configuration of remote database is incorrect
Do you want to re-configure remote database correctly (y/n/q)?:

Enter y to reconfigure the remote database as an inactive secondary. If you enter n, the FailSafe database configuration will be inconsistent.