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.