reconcil Command—Assist in Recovering Lost Data

The reconcil command is used with standard DBMS recovery methods to recover lost data from journals, the transaction log file, or dump areas. The cause of lost data is usually irrecoverable disk failure.

The reconcil command works only on a replicated database that is restored to a consistent state using one of the standard recovery methods, such as checkpointing, journaling, and operating system backup.

Caution! Do not use the reconcil command as your only means of disaster recovery. It should be used only with other standard disaster recovery tools and only if the conventional methods alone are unable to recover the data.

In the event of a system failure, it is standard procedure to restore the affected database from checkpoints; however, if journals, log files, or dump areas are lost, a gap of missing data will exist on the failed database. This gap of data may still exist on one of the database replicas. The reconcil command can recover this gap using the shadow and archive tables on the affected database, if those records still exist on these tables and reflect the data that was lost for the duration of the gap.

Note: Since the arcclean command purges records from the archive and shadow tables, you cannot use the reconcil command to recover lost data if you have executed arcclean on all of the replicated databases for the time of the information gap.

The reconcil command looks at each shadow table in the replicated database from a user-specified start time. If a record belongs to a CDDS that is common to the failed database, the command places an operation (insert, update, delete) for that record in the distribution queue, if the operation does not already exist in the queue. Set the collision mode of the CDDS to BenignResolution and start the necessary servers to allow the lost data to be retransmitted to the failed database.

Before you use the reconcil command, be sure you have:

• Quieted all Replicator Servers in the environment by excluding users from replicated databases.
• Ensured that all the entries in the input queue have been moved to the distribution queue.

The reconcil command has the following format:

Windows, VMS:

reconcil [vnode::] dbname target_db_number cdds_no|"(x,y,z,…)" |all "start_time" [-udba_name]

UNIX:

reconcil [vnode::] dbname target_db_number cdds_no|'(x,y,z,…)' |all 'start_time' [-udba_name]

• target_db_number

  Specifies the Ingres Replicator database number of the failed database. It must be a valid database name and Ingres Net virtual node name.

• -udba_name

  Identifies the name of the DBA who owns the replicated database specified in dbname.

• cdds_no | "(x,y,z,…)" |all

  Specifies the CDDSs that are to be transmitted to the failed database to bring it back in synch with its replica.

  To specify the CDDS, use one of the following formats:

  • cdds_no to send a single CDDS number
  • '(x,y,z,…)' to send a set of CDDS numbers
  • all to send all CDDS numbers

    Note: If you specify more than one CDDS number, provide single quotes for UNIX and double quotes for OpenVMS and Windows.

• 'start_time'

  Specifies the start time, in Ingres date and time format, used for recovering the lost data. Provide single quotes around the date and time for UNIX and double quotes for OpenVMS and Windows.

  To ensure that the start time covers the duration of the information gap, be sure to specify a start time prior to the database failure. It is better to have overlapping data that can be reconciled than risk an information gap in the target database.

• [vnode::]dbname

  Identifies the name of the replicated database that is to provide the lost data to the failed database. The replicated database must have a Replicator Server configured to transmit the lost data to the failed database.

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 UNIX machines:

   UNIX:

   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.