reconcil Example: Perform Disaster Recovery
The steps in the following scenario provide an example of how you can perform disaster recovery with the reconcil command:
1. A system failure occurring between 10:25 a.m. and 10:30 a.m. on September 20 destroys a disk on database lon::europe. A disk containing the transaction log file is also destroyed.
As a result, there is an estimated five-minute gap in committed transactions that were in the log file after the journals were re-run.
2. The DBA recovers the database from checkpoint which brings the database lon::europe to consistency as of 10:25 a.m.
3. To recover lost data in the database from the transaction log file, the DBA selects two databases to use with the reconcil command, nyc::hq and hkg::asia, both of which are full-peer replicas of the original lon::europe database.
The database lon::europe shares CDDS numbers 0 and 1 with nyc::hq and CDDS number 2 with hkg::asia.
4. The DBA removes databases nyc::hq and hkg::asia from user service and quiets their Replicator Servers.
5. In both databases, the DBA ensures that all the entries in the input queue have been moved to the distribution queue.
6. The DBA invokes the reconcil command on the nyc::hq and hkg::asia databases. For example, the DBA issues the following command respectively on the nyc::hq and hkg::asia Linux machines:
Linux:
reconcil nyc::hq 20 '(0,1)' '16-nov-98 10:20'
reconcil hkg::asia -uwong 20 2 '16-nov-98 10:20' 
The target database number for both these commands is 20 (the number for lon::europe). On the nyc::hq machine, the CDDS set specified is ‘(0,1)’, while on the hkg::asia machine, only CDDS number 2 is specified.
Note: Since data was lost between 10:25 and 10:30, the DBA starts the reconcil command at 10:20, providing an overlap of at least five minutes to ensure the gap of missing data is recovered.
7. The DBA configures CDDSs 0, 1, and 2 with collision mode BenignResolution.
8. The DBA starts the Replicator Servers to bring the database back in synch.
Last modified date: 11/09/2022