InfoScale™ 9.0 Storage and Availability Management for DB2 Databases - AIX, Linux
- Section I. Storage Foundation High Availability (SFHA) management solutions for DB2 databases
- Overview of Storage Foundation for Databases
- About Veritas File System
- Overview of Storage Foundation for Databases
- Section II. Deploying DB2 with InfoScale products
- Deployment options for DB2 in a Storage Foundation environment
- Deploying DB2 with Storage Foundation
- Deploying DB2 in an off-host configuration with Storage Foundation
- Deploying DB2 with High Availability
- Deployment options for DB2 in a Storage Foundation environment
- Section III. Configuring Storage Foundation for Database (SFDB) tools
- Configuring and managing the Storage Foundation for Databases repository database
- Configuring the Storage Foundation for Databases (SFDB) tools repository
- Configuring authentication for Storage Foundation for Databases (SFDB) tools
- Configuring and managing the Storage Foundation for Databases repository database
- Section IV. Improving DB2 database performance
- About database accelerators
- Improving database performance with Quick I/O
- About Quick I/O
- Improving DB2 database performance with Veritas Concurrent I/O
- Section V. Using point-in-time copies
- Understanding point-in-time copy methods
- Volume-level snapshots
- Storage Checkpoints
- Considerations for DB2 point-in-time copies
- Administering third-mirror break-off snapshots
- Administering Storage Checkpoints
- Database Storage Checkpoints for recovery
- Backing up and restoring with Netbackup in an SFHA environment
- Understanding point-in-time copy methods
- Section VI. Optimizing storage costs for DB2
- Section VII. Storage Foundation for Databases administrative reference
- Storage Foundation for Databases command reference
- Tuning for Storage Foundation for Databases
- Troubleshooting SFDB tools
Resynchronizing mirror volumes with primary volumes
After creating a clone of your database, you can refresh mirror volumes with primary volumes by using the steps outlined in Figure: Resynchronizing Mirror Volumes.
To resynchronize mirror volumes with primary volumes
- Unmount the clone database.
$ /opt/VRTS/bin/vxsfadm -s flashsnap \ -a db2 -o umount -c dailyconfig Shutting down clone database... Done Retrieving snapshot information ... Done Unmounting snapshot volumes ... Done Deporting snapshot diskgroups ... Done
This command stops the clone database gracefully and unmounts the file systems. The unmounted database can be restarted by using the clone operation.
You can use the -o clone option to restart a clone database after it is unmounted.
$ /opt/VRTS/bin/vxsfadm -s flashsnap \ -a db2 -o clone -c dailyconfig Retrieving snapshot information ... Done Importing snapshot diskgroups ... Done Mounting snapshot volumes ... Done Activating clone database clone1 ... Done
This command mounts the snapshot file systems and restarts the cloned database.
- Refresh mirror volumes with primary volumes.
$ /opt/VRTS/bin/vxsfadm -s flashsnap \ -a db2 -o resync -c dailyconfig resync started at Tue Mar 20 00:46:29 2012. Importing snapshot diskgroups ... Done Joining snapshot diskgroups to original diskgroups ... Done Reattaching snapshot volumes to original volumes ... Done resync ended at Tue Mar 20 00:46:57 2012.
This command resynchronizes all mirror volumes that were broken during snapshot state with primary volumes. After the resync operation is complete and mirror volumes are in the SNAPDONE state, you can take fresh snapshots.
You can use the vxprint command to view the state of the volumes.