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

1. Execute a process that opens the image trail file with shared read access. This can be a simple
process that you supply to perform only this operation. When the purger determines that all
updaters are finished with this image trail file (named, say, AA000007), and have moved
on to the next image trail file (named, say, AA000010), then it might try to purge AA000007.
The purge operation will fail, however, because your process still has AA000007 open. The
purger will terminate the purge attempt and try it again later. As long as your process keeps
AA000007 open, the purger cannot purge it.
2. When the purger tries to purge AA000007 and fails, it writes a message denoting this error
to the EMS event log. This message implies that all updaters have moved from AA000007 to
AA000010 (or beyond), and will never need AA000007 again; it is your only way to know
for certain that AA000007 will never be needed again. When this message is written, you
can start the backup process to dump AA000007 to tape.
3. When the backup process opens AA000007 and the backup is in progress, you can stop
the file-opening process run in Step 1. The purger will continue its attempts to purge AA000007,
but these attempts also will fail as long as the backup process has AA000007 open. Eventually,
when the backup is complete and AA000007 is successfully copied to tape, no processes
will have this file open. After this point, the purger will be able to purge AA000007
successfully.
Repeat the preceding steps for each image trail file you want to back up.
TMF and Online Dumps on the Backup System
While taking online dumps of your backup database on your backup system is not required, you
are nevertheless strongly urged to do so for the following two reasons:
• If you were to have the complete failure of both mirrors of an updater's volume on your backup
system, you can perform a TMF Recover Files operation to recover the files onto a new disk.
Without the online dump, you will have to stop RDF, reinitialize RDF, and then perform a
partial database synchronization, online or offline (see Chapter 7). If your database files are
smallish, then perhaps database synchronization is a more viable solution to recovery from
a media failure. If your database files are very large, then TMF File Recovery might be an
easier and faster way to rebuild the file set on the affected disk.
NOTE: Using TMF online dumps to recover files updated by RDF for any other reason does
not work because RDF updaters apply audit to the backup database with a completely different
transaction profile. For example, suppose you have discovered data corruption in the database
on your primary system, you can use TMF Recover Files to a timestamp on your primary system,
but you then cannot do the same operation on the backup system to recover the backup
database to the same location as on your primary system. For this type of File Recovery, you
will have to resynchronize the affected files on your backup system with the newly recovered
files on your primary system.
• Having online dumps of your backup database can allow you to start application processing
on your backup system much faster when you experience a planned or unplanned outage of
your primary system. See the related discussions in “Carrying Out a Planned Switchover” and
“Takeover Operations” sections.
To take online dumps of your backup database, you must first alter the global RDF UPDATEROPEN
configuration attribute to SHARED with RDFCOM.
] ALTER RDF UPDATEROPEN SHARED
By default, the RDF UPDATEROPEN attribute is set to PROTECTED, and this is the recommended
value. When the dump has completed, you can then alter the attribute back to PROTECTED or
PROTECTED OPEN. Previously you needed to stop the updaters before modifying this attribute,
but you can now modify it online, without stopping the updaters. See the SET RDF command in
Chapter 8 for further details.
TMF and Online Dumps on the Backup System 145