Recovering a shared-disk cluster after data is damaged

If a shared-disk cluster fails, you must perform a restore of affected dbspaces. The type of restore that you need to perform depends on whether critical data is damaged.

Critical data is damaged

About this task

If the primary server experiences a failure that damages the root dbspace, the dbspace that contains logical-log files, or the dbspace that contains the physical log, you must treat the failed database server as if it has no data on the disks. You must perform a full restore of the primary server. In this situation, the primary server and the SD secondary servers are offline.

Procedure

To recover a shared-disk cluster after critical media failure:
  1. Perform a full restore of the primary server. Run one of the following commands, depending on whether the backup was performed with ON-Bar or the ontape utility:
    • onbar -r
    • ontape -r
    The primary server restarts after the restore is complete.
  2. Restart the SD secondary servers.

Results

Alternatively, you can perform a cold restore of the critical dbspaces on the primary server, restart the SD secondary servers, and then perform a warm restore of non-critical dbspaces.

Critical data is not damaged

About this task

If a disk that does not contain critical media fails, you can restore the affected dbspaces with a warm restore. In this situation the primary server and the SD secondary servers are online.

Procedure

To recover non-critical data in a shared-disk cluster:
  1. Shut down and restart the SD secondary servers.
  2. Perform a warm restore of the affected dbspaces. Run one of the following commands, depending on whether the backup was performed with ON-Bar or the ontape utility:
    • onbar -r with the names of the dbspaces to restore
    • ontape -r -D with the names of the dbspaces to restore