Hitachi TrueCopy for IBM z/OS User and Reference Guide (T5211-96001, June 2007)

TrueCopy for z/OS Usage Scenarios 7-7
Hitachi Universal Storage Platform V TrueCopy for IBM z/OS User’s Guide
File and Database Recovery Procedures
When a TrueCopy for z/OS Sync pair is suspended, or when the MCU fails due
to a disaster, the R-VOL may contain in-process data. A data set could be
open, or transactions may not have completed. Even if you use the Data fence
level for all TCz Synchronous pairs, you need to establish file recovery
procedures. These procedures should be the same as those used for
recovering any volume which becomes inaccessible due to control unit failure.
These procedures are more important if the Status or Never fence level
settings are used.
TCz Asynchronous does not provide any procedure for detecting and retrieving
lost updates. To detect and recreate lost updates, you must check other
current information (e.g., database journal log file that was active at the
primary system 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 TCzA 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 and retrieval of lost
updates is performed after the application has been started at the secondary
system.
You should prepare for file and database recovery by using:
• Files for file recovery (e.g., DB2 log files which have been verified as
current). To ensure the currency of these files, use the Data fence level
setting for the TCz pairs which contain these important files.
• The sense information with system time stamp which will be transferred via
ERC.
Important:
Remote copy and disaster recovery procedures are inherently
complex. Consult your Hitachi account team on sense-level settings and
recovery procedures.