Use Deduplication Database (DDB) Resynchronization to bring the DDB online and revert it to a reusable state from maintenance mode.
The DDB is flagged in maintenance mode when there is an inconsistency between the DDB and the CommServe database. Additionally, when the CommServe disaster recovery (DR) restore process is complete, all eligible active and sealed DDBs are flagged as in maintenance mode. When DDBs are in maintenance mode, pruning will not happen, and backups or auxiliary copy jobs cannot access the DDB and go into waiting state.
DDB Resynchronization is useful in the following situations:
-
To reconcile inconsistencies between the DDB and the CommServe database. You want to bring the DDB online from maintenance mode.
-
To avoid the need to seal the DDB after the CommServe DR restore.
After a successful completion of DR restore, when the CommCell services are started, the DDBs are automatically marked for Resynchronization. The Resynchronization job is triggered by the software when the CommCell services are up and running.
Notes:
-
The DDB sealing can be avoided only if the CommServe DR restore was completed using the DR backup within the past five days. The resynchronization job runs in the background. It starts within 15 minutes of initiation and you may monitor the Event Viewer to see the resynchronization job progress.
-
For CommServe disaster recovery, there are two different scenarios for the CommServe DR restores that starts the DDB resynchronization process automatically without user intervention.
-
For a planned CommServe restore from a DR backup (for example, CommServe Hardware Refresh), we recommend you to run the DR backup with DDB Activity disabled. See, Shut Down the CommServe Database in the Old Hardware for more information. In this scenario, after the DR restore, re-enabling the DDB activity runs the DDB resynchronization process automatically without any user intervention.
-
For an unplanned recovery of CommServe or test disaster recovery scenarios, the CommServe restores from a DR backup where the DDB activity is not disabled before the backup. In these scenarios, after DR restore is completes, re-enabling the DDB activity runs the DDB resynchronization process automatically without any user intervention.
-
How DDB Resynchronization Works
Following is the high-level process for DDB Resynchronization:
-
The data in the DDB is validated against the CommServe database to ensure that both the databases are synchronized.
-
If the CommServe database and the DDB are not synchronized, the resynchronization process removes the additional data entries in the DDB to reconcile inconsistencies in the CommServe database.
-
When the DDB entries are removed successfully, the DDB is marked online.
After DDB resynchronization, you can verify the status of the DDBs in the Event Viewer window.
To verify the status of the DDBs, on the ribbon in the CommCell Console, click the Home tab, and then click Event Viewer.
An Event Viewer window is displayed in the CommCell Console.
A description of the synchronization process appears in the Event Viewer as follows:
|
Result of DDB resynchronization |
Event message |
|---|---|
|
Successful |
|
|
Failed |
During DDB resynchronization, if the DDB MediaAgent or Index Cache or DDB access path is offline, the resynchronization might fail. The resynchronization process attempts to run five times, every 15 minutes, on each failed DDB. During this attempts, if the DDB MediaAgent or Index Cache or DDB access path are back online, the resynchronization process will succeed. Contact your software provider if the resynchronization process exceeds five attempts. |
The following event message appear for each DDB that is involved in the DDB Resynchronization.
|
Result of DDB resynchronization for each DDB |
Event message |
|---|---|
|
Successful |
|
|
Failed |
If the resynchronization process of a DDB exceeds maximum (five) attempts, the following message is displayed: dContact your software provider to resolve this issue. |