RDF System Management Manual for J-series and H-series RVUs (RDF 1.10)

Old Audit-Trail Files
When a ZLT takeover operation completes, you should not purge the old audit trail files on the
remote mirrors connected to the standby system if you believe you can recover the primary system.
The old audit trail files are necessary for recovering the primary system.
If you can’t recover the primary system, you might purge the files because they have no further
use.
Because the old audit trail files are not managed by TMF on the standby system, if you choose to
purge them you must do so manually using Snoop.
Recovering the Primary System After an RDF ZLT Takeover
If you had to execute the RDF takeover operation and you are able to bring your former primary
system back online, you must perform these tasks to recover the database on your former primary
system.
1. Determine which disks (the local disk on the primary system or the remote mirror on the standby
system) for all audit trails in the RDF configuration received the most audit records. The example
that follows shows how to do so for the MAT. If your RDF configuration includes one or more
auxiliary audit trails, you must do the same for each auxiliary audit trail.
NOTE: if you had CommitHoldMode configured ON at the time the primary system failed,
then you can omit this step because the mirrors on the remote system will either have more
data or the same data as the local mirrors connected to the primary system. This first step is
only useful if you had turned off CommitHoldMode before the primary system failed.
On the ZLT standby system, use SNOOP READAUDIT to read the final file in the MAT,
positioning at EOF and reading in reverse order for one record. This is sample output from
READAUDIT with the MAT position in bold:
* SEQNO = 8, RBA = 107628804, RBN = 26276 *
AC^RECORD^LENGTH=108, AC_VERSION=7, VERSION_FLAGS=000000 000000, PRIMARY^CPU=0
AUDITING^PROCESS=TMP , VSN=000000 000000 000004 077334
TRANSID=000000 000000 000000 000000, ACTTX=0, TYPE=1033 (DATAVOL STATE)
CREATING^SYSTEM=190, VOLNAME=$DATA13, STATE=8, STATE^TEXT=STARTED
On the former primary system, the last file in the MAT might have been left in the crashopen
state. You can determine that by issuing this command:
$system system 3> fileinfo $*.ztmfat.*
$audit.ztmfat
CODE EOF LAST MODIFIED OWNER RWEP PExt SExt
aa000001 134 125825024 01feb2005 10:15 255,255 gggg 3840 3840
aa000002 134 125829120 01feb2005 10:20 255,255 gggg 3840 3840
aa000003 134 125829120 01feb2005 10:24 255,255 gggg 3840 3840
aa000004 134 125808640 01feb2005 10:31 255,255 gggg 3840 3840
aa000005 134 125829120 01feb2005 10:38 255,255 gggg 3840 3840
aa000006 134 125829120 01feb2005 10:45 255,255 gggg 3840 3840
aa000007 134 125829120 01feb2005 10:54 255,255 gggg 3840 3840
aa000008 134 125829120 01feb2005 11:04 255,255 gggg 3840 3840
aa000009 134 125829120 01feb2005 11:14 255,255 gggg 3840 3840
aa000008 ? 134 107630592 01feb2005 11:04 255,255 gggg 3840 3840
The file marked with the question mark must be fixed. Use the SNOOP FIXUPEOF command
to reset the crashopen flag. Then use SNOOP READAUDIT to read the final record. You cannot
use the MERGE option when specifying the name of the audit trail file. Because the TMF
product is not started, attempting to use the MERGE option results in an error. Using the
example of the MAT above, specify the MAT volume and subvolume when SNOOP issues
this prompt:
Audit trail name or 'MERGE' (MERGE): $AUDIT.ZTMFAT.AA
Compare the MAT position of the two records to determine which disk has the most audit
records.
Recovering the Primary System After an RDF ZLT Takeover 327