A damaged or structurally inconsistent database file can and often will result when a system crashes. Before image journaling, normal MUPIP recovery/rollback will repair such damage automatically and restore the database to the logically consistent state as of the end of the last transaction committed to the database by the application. Certain benign errors may also occur (refer to the "Maintaining Database Integrity" chapter). These can be repaired on the secondary system at an appropriate time, and are not considered "damaged" for the purpose of this discussion.

	Note
	If the magnetic media of the database and/or the journal file is damaged (e.g., a head crash on a disk that is not mirrored), automatic repair is problematic. For this reason, it is strongly recommended that organizations use hardware mirroring for magnetic media.

Considering the high level at which replication operates, the logical dual-site nature of GT.M database replication makes it virtually impossible for related database damage to occur on both primary and secondary systems.

There are two cases to consider in the unlikely event that there is database damage needing manual repair: damage on the primary and damage on the secondary. If the database needing repairs is operating as the primary, Fidelity recommends a failover so that the damaged database begins operating as the secondary. Then shut down replication, repair the database, and resume replication. The secondary system will automatically "catch up," assuming that the replication fields in the database file headers are correct.

To maintain application consistency, do not change the logical content of a replicated region when using DSE to repair a damaged database.

	Note
	Before attempting manual database repair, Fidelity strongly recommends backing up the entire database (all regions).

After repairing the database, bring the secondary back up and backup the database with new journal files. MUPIP backup online will allow the secondary to come back online and resume operation while the backup takes place. The old journal files prior to the backup are not usable for recovery.