HP NonStop RDF, Руководство по управлению

Страница: 130 / 478

File Recovery on the Primary System
A file recovery operation occurs whenever a TMFCOM RECOVER FILES command is issued at
the primary system. A simple file recovery operation does not affect RDF nor does it require
database synchronization. A file recovery operation to a timestamp or a first purge, however,
does require you to stop RDF, reinitialize, and resynchronize the affected files.
The file recovery TOMATPOSITION is a special usage that achieves synchronization itself. If
your RDF primary system has failed, you have executed an RDF takeover operation on your
backup system without RDF/ZLT, and you have subsequently brought your primary system
back online, you can resynchronize the database on your recovered primary system with file
recovery TOMATPOSITION. When the takeover has completed on your backup system, RDF
normally logs an RDF event 888. This event provides you with a master audit trail sequence
number and relative byte address that you can use for file recovery TOMATPOSITION on your
recovered primary system. The result of this operation puts the database on your primary system
into synchronization with the database on your backup system at the time when the takeover
operation completed. If you started application processing on your backup system after the
completion of the takeover operation, you then need to configure a new RDF subsystem to
replicate all changes made to the database on your backup system to the database on your primary
system.
WARNING!
File Recovery with TOMATPOSITION should only be used when recovering your
primary system after an RDF Takeover operation on your backup system. If you use the
TOMATPOSITION for any other reason, it will require database synchronization just like File
Recovery to a timestamp or first purge.
File Recovery on the Backup System
You are encouraged to take online dumps on your backup database on a regular basis for the
following reasons:
• If you have lost your primary system and have taken over on your backup system, the online
dumps can be used for any type of file recovery operation provided the redo end point is
located after all audit data that was generated during the RDF takeover. For example, a file
recovery to a timestamp must be to a timestamp after the time when the RDF takeover
completed.
• If RDF is running from your primary to your backup system and you lose one or more disks
on your backup system, you should stop the RDF updating, perform a simple file recovery
on the backup system to recover the files on the affected disks, and then restart RDF updating.
You should not perform a file recovery to a timestamp, first purge, or TOMATPOSITION on
your backup system if the location occurs prior to an RDF takeover location. Those file recovery
operations normally are used to recover a database that has been corrupted.
Under normal circumstances, the best way to recover the backup database is to resynchronize
it with your primary database. Because that can involve significant time and effort, you should
consider using the following method instead (assume that the system clocks on the primary and
backup systems are set to the same time):
• Stop RDF.
• Perform file recovery to a timestamp on the backup system.
• Determine the duration of the longest running transaction on your primary system. Subtract
this amount of time from the time used for the start of the file recovery operation. If you
don't know the duration of the longest transaction, it is better to overestimate than to
underestimate (use an arbitrary number, such as 10 minutes). There is nothing wrong with
initializing RDF to a point further back in time than is necessary.
130 Critical Operations, Special Situations, and Error Conditions