HP StorageWorks XP Remote Web Console Software - Manual (Page 220)

NOTE: Make sure that the primary and secondary storage systems are configured to report the
service-level SIMs to the host.
When the primary or secondary storage system suspends a Universal Replicator for Mainframe
pair due to a disaster, the secondary data volume may contain in-process data. A data set could
be open, or transactions may not have completed. Therefore, you need to establish file recovery
procedures. These procedures should be the same as those used for recovering data volume that
becomes inaccessible due to control unit failure.
Universal Replicator for Mainframe does not provide any procedures for detecting and retrieving
lost updates. To detect and recreate lost updates, you must check other current information (for
example, database log file) that was active at the primary site when the disaster occurred. Note
that the journal log file entries of most DBMS have the same system TOD clock information that is
used for the I/O time stamps (when timer type = system). The Universal Replicator for Mainframe
group consistency time can be extremely useful when performing this detection and retrieval. Since
this detection/retrieval process can take a while, your disaster recovery scenario should be designed
so that detection/retrieval of lost updates is performed after the application has been started at
the secondary site.
For details on the timer type option, see “Timer Type Option” (page 27) .
You should prepare for file and database recovery by using:
•
Files for file recovery (for example, database log files which have been verified as current).
•
The sense information with a system time stamp which will be transferred via ERC.
IMPORTANT: Remote copy and disaster recovery procedures are inherently complex. Consult
your HP support representative on sense-level settings and recovery procedures.
NOTE: See “Recovering a Pinned Track on a Journal Volume” (page 205) for information on
recovering a pinned track on a Universal Replicator for Mainframe volume.
Switching Operations to the Secondary Site
If a disaster or failure occurs at the primary site, the first disaster recovery activity is to use Business
Continuity Manager to switch your operations to the remote backup site.
The basic procedures for switching operations to the remote backup site are as follows:
NOTE: If you need to perform an IPL of the secondary host system, delete SIMs and then perform
the IPL before following the procedure below. When the IPL finishes, the secondary data volumes
will usually be varied online. If the secondary volume are not varied online, vary the volumes
online.
NOTE: If you do not need to perform an IPL of the secondary host system, ensure that the secondary
data volumes are varied online before you follow the procedure below.
1. Check whether the restore journal group includes a secondary data volume whose pair status
is Pending duplex or Suspend (equivalent to SUSPOP in Business Continuity Manager).
If such a pair exists, consistency in the secondary data volume is dubious, and recovery with
guaranteed consistency is impossible. In this case, if you want to use the secondary data
volume, you must release the pair.
2. If such a pair does not exist, use Business Continuity Manager to execute the YKSUSPND
REVERSE option on the restore journal group (YKSUSPND is a command for splitting a pair).
If an error occurs, the consistency in the secondary data volume is dubious, and recovery with
guaranteed consistency is impossible. In this case, if you want to use the secondary data
volume, you must release the pair.
220 Usage Scenarios