Resynchronizing your database to the snapshot<a class="indexterm" name="id445350"></a><a class="indexterm" name="id445357"></a><a class="indexterm" name="id445361"></a><a class="indexterm" name="id445368"></a><a class="indexterm" name="id445375"></a>


Resynchronizing your database to the snapshot
Prev	Using Database FlashSnap for backup and off-host processing	Next

Resynchronizing your database to the snapshot

If your database becomes corrupted, you can use reverse resynchronization to recover the database from a clone. The reverse resynchronization feature of Veritas Database FlashSnap enables you to resynchronize the primary database or volume with a clone database or snapshot volume.

Reverse resynchronization requires the primary database to be inactive so that it remains unchanged.

Warning:

Upon completion of reverse resynchronization, the content of the original database is discarded. Storage Checkpoints taken on the original database before or after the snapshot was created are discarded. The db2ed_vmsnap -o reverse_resync_commit command cannot be undone and should be used with extreme caution.

Before resynchronizing a database to a snapshot, make sure the following conditions have been met:

Prerequisites

You must be logged in as the DB2 instance owner.

Before you can reverse resynchronize the snapshot image, review the database snapshot procedure and create the snapshot.
Before you execute the reverse_resync_commit command, you must remove the old archive log when ODM is enabled.
The mount point for the primary database must be owned by the DB2 instance owner.
If a clone database has been created, you must shut it down and unmount the file systems using the command before you can reverse resynchronize the snapshot image. This command also deports the disk group.

See Shutting down the clone database and unmounting file systems.
The primary database must be inactive.

Usage notes

The db2ed_vmsnap command can only be executed on the primary host.

To begin reverse resynchronization

Use the -o reverse_resync_begin option to the db2ed_vmsnap command:
```
$ /opt/VRTS/bin/db2ed_vmsnap -D DB2DATABASE -f SNAPPLAN \
-o reverse_resync_begin
```
Any mounted storage checkpoints must be unmounted before running db2ed_vmsnap -o reverse_resync.

After executing reverse_resync_commit, checkpoints created on the original database will be deleted.

The -o reverse_resync_begin option imports the disk group that was deported from the secondary host and joins it back to the original disk group. The command unmounts the original volumes, mounts the snapshot volumes with the file systems that are configured for the primary database, and brings up the database snapshot image as the primary database. This operation requires the primary database to be offline so that its contents remain unchanged.

To abort reverse resynchronization

Use the -o reverse_resync_abort option of the db2ed_vmsnap command:
```
$ /opt/VRTS/bin/db2ed_vmsnap -D DB2DATABASE -f SNAPPLAN \
-o reverse_resync_abort
```
If your snapshot was created with SNAPSHOT_MODE set to online_mirror, you cannot run db2ed_vmsnap -o reverse_resync_begin after running db2ed_vmsnap -o reverse_resync_abort. You must take a new snapshot before performing reverse resynchronization again.

The -o reverse_resync_abort option aborts -o reverse_resync_begin, unmounts the snapshot volumes, and mounts the original volumes back with the file systems that are configured to use the volume. This operation is only allowed after -o reverse_resync_begin has been executed and cannot be used after reverse resynchronization has been committed (-o reverse_resync_commit).

To commit reverse resynchronization changes

Use the -o reverse_resync_commit option of the db2ed_vmsnap command:
```
$ /opt/VRTS/bin/db2ed_vmsnap -D DB2DATABASE -f SNAPPLAN \
-o reverse_resync_commit
```
The -o reverse_resync_commit option commits the reverse resynchronization changes after you have verified that they are acceptable. The operation resynchronizes the original volume from the data in the snapshot.

This example is valid only for the online_snapshot mode.

Reverse resynchronization is started on the primary host:

$ /opt/VRTS/bin/db2ed_vmsnap -D PROD -f snap1 \
-o reverse_resync_begin

db2ed_vmsnap started at 2006-05-26 13:37:11
Files and control structures were changed successfully.
Database was catalogued successfully.
DBT1000I  The tool completed successfully.
db2ed_vmsnap ended at 2006-05-26 13:37:48

Reverse resychronization is aborted on the primary host.

$ /opt/VRTS/bin/db2ed_vmsnap -D PROD -f snap1 \
-o reverse_resync_abort

db2ed_vmsnap started at 2006-05-26 13:38:16
DB20000I  The FORCE APPLICATION command completed successfully.
DB21024I  This command is asynchronous and may not be effective
immediately.

DB20000I  The UNCATALOG DATABASE command completed successfully.
DB21056W  Directory changes may not be effective until the
directory cache is refreshed.
Files and control structures were changed successfully.
Database was catalogued successfully.
DBT1000I  The tool completed successfully.
DB20000I  The UNCATALOG DATABASE command completed successfully.
DB21056W  Directory changes may not be effective until the
directory cache is refreshed.
DB20000I  The CATALOG DATABASE command completed successfully.
DB21056W  Directory changes may not be effective until the
directory cache is refreshed.
The option reverse_resync_abort has been completed.
db2ed_vmsnap ended at 2006-05-26 13:39:31

Reverse resychronization changes are committed on the primary host.

$ /opt/VRTS/bin/db2ed_vmsnap -D PROD -f snap1 \
-o reverse_resync_commit

db2ed_vmsnap started at 2006-05-26 13:40:32
DB20000I  The FORCE APPLICATION command completed successfully.
DB21024I  This command is asynchronous and may not be effective
immediately.

DB20000I  The UNCATALOG DATABASE command completed successfully.
DB21056W  Directory changes may not be effective until the
directory cache is refreshed.
DB20000I  The CATALOG DATABASE command completed successfully.
DB21056W  Directory changes may not be effective until the
directory cache is refreshed.
db2ed_vmsnap ended at 2006-05-26 13:41:35

Prev	Up	Next
Resynchronizing the snapshot to your database	Home	Removing a snapshot volume