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
- Introducing Storage Foundation High Availability (SFHA) Solutions for DB2
- About the File System component
- About the Volume Manager component
- About Dynamic Multi-Pathing (DMP)
- About Cluster Server
- About Cluster Server agents
- About InfoScale Operations Manager
- Feature support for DB2 across InfoScale products
- Use cases for InfoScale products
- Overview of Storage Foundation for Databases
- Section II. Deploying DB2 with InfoScale products
- Deployment options for DB2 in a Storage Foundation environment
- DB2 deployment options in an InfoScale environment
- DB2 on a single system with Storage Foundation
- DB2 on a single system with off-host in a Storage Foundation environment
- DB2 in a highly available cluster with Storage Foundation High Availability
- DB2 in a parallel cluster with SF Cluster File System HA
- Deploying DB2 and Storage Foundation in a virtualization environment
- Deploying DB2 with Storage Foundation SmartMove and Thin Provisioning
- 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
- About the Storage Foundation for Databases (SFDB) repository
- Requirements for Storage Foundation for Databases (SFDB) tools
- Storage Foundation for Databases (SFDB) tools availability
- Configuring the Storage Foundation for Databases (SFDB) tools repository
- Updating the Storage Foundation for Databases (SFDB) repository after adding a node
- Updating the Storage Foundation for Databases (SFDB) repository after removing a node
- Removing the Storage Foundation for Databases (SFDB) 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
- How Quick I/O improves database performance
- Tasks for setting up Quick I/O in a database environment
- Preallocating space for Quick I/O files using the setext command
- Accessing regular VxFS files as Quick I/O files
- Converting DB2 containers to Quick I/O files
- About sparse files
- Displaying Quick I/O status and file attributes
- Extending a Quick I/O file
- Monitoring tablespace free space with DB2 and extending tablespace containers
- Recreating Quick I/O files after restoring a database
- Disabling Quick I/O
- Improving DB2 database performance with VxFS Concurrent I/O
- Section V. Using point-in-time copies
- Understanding point-in-time copy methods
- About point-in-time copies
- When to use point-in-time copies
- About Storage Foundation point-in-time copy technologies
- Point-in-time copy solutions supported by SFDB tools
- About snapshot modes supported by Storage Foundation for Databases (SFDB) tools
- Volume-level snapshots
- Storage Checkpoints
- Considerations for DB2 point-in-time copies
- Administering third-mirror break-off snapshots
- Administering Storage Checkpoints
- About Storage Checkpoints
- Database Storage Checkpoints for recovery
- Creating a Database Storage Checkpoint
- Deleting a Database Storage Checkpoint
- Mounting a Database Storage Checkpoint
- Unmounting a Database Storage Checkpoint
- Creating a database clone using a Database Storage Checkpoint
- Restoring database from a Database Storage Checkpoint
- Gathering data for offline-mode Database Storage Checkpoints
- 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
Creating a snapshot mirror of a volume or volume set used by the database
With Database FlashSnap, you can mirror the volumes used by the database to a separate set of disks, and those mirrors can be used to create a snapshot of the database. These snapshot volumes can be split and placed in a separate disk group. This snapshot disk group can be imported on a separate host, which shares the same storage with the primary host. The snapshot volumes can be resynchronized periodically with the primary volumes to get recent changes of the datafiles. If the primary datafiles become corrupted, you can quickly restore them from the snapshot volumes. Snapshot volumes can be used for a variety of purposes, including backup and recovery, and creating a clone database.
You must create snapshot mirrors for all of the volumes used by the database datafiles before you can create a snapshot of the database. This section describes the procedure used to create snapshot mirrors of volumes.
Use the vxsnap command to create a snapshot mirror or synchronize a snapshot mirror.
Prerequisites |
|
Usage Notes |
Note: Database FlashSnap commands support third-mirror break-off snapshots only. The snapshot mirror must be in the SNAPDONE state. |
The following sample procedure is for existing volumes without existing snapshot plexes or associated snapshot volumes. In this procedure, volume_name is the name of either a volume or a volume set.
Note:
You must be logged in as superuser (root) to issue the commands in the following procedure.
To create a snapshot mirror of a volume or volume set
- To prepare the volume for being snapshot, use the vxsnap prepare command:
# vxsnap -g diskgroup prepare volume \ alloc="storage_attribute ..."
The vxsnap prepare command automatically creates a DCO and DCO volumes and associates them with the volume, and enables Persistent FastResync on the volume. Persistent FastResync is also set automatically on any snapshots that are generated from a volume on which this feature is enabled.
For enabling persistent FastResync on a volume either from the command line or from within a script, use the vxsnap prepare command as described above.
- To verify that FastResync is enabled on the volume, use the vxprint command:
# vxprint -g diskgroup -F%fastresync volume_name
This returns on if FastResync is on. Otherwise, it returns off.
- To verify that a DCO and DCO log volume are attached to the volume, use the vxprint command:
# vxprint -g diskgroup -F%hasdcolog volume_name
This returns on if a DCO and DCO log volume are attached to the volume. Otherwise, it returns off.
- Create a mirror of a volume:
# vxsnap -g diskgroup addmir volume_name alloc=diskname
Example of creating 3 mirrors for a particular volume:
# vxsnap -g diskgroup addmir datavol \ nmirror=3 alloc=disk1,disk2,disk3
- List the available mirrors:
# vxprint -g diskgroup -F%name -e"pl_v_name in \"volume_name\""
- If you require a backup of the data in the snapshot, use an appropriate utility or operating system command to copy the contents of the snapshot to tape or to some other backup medium.
Enable database FlashSnap to locate the correct mirror plexes when creating snapshots:
Set the dbed_flashsnap tag for the data plex you want to use for breaking off the mirror. You can choose any tag name you like, but it needs to match the SNAPSHOT_PLEX_TAG attribute specified in the configuration or snapplan.
# vxedit -g diskgroup set putil2=dbed_flashsnap plex_name
Verify that the dbed_flashsnap tag has been set to the desired data plex:
# vxprint -g diskgroup -F%name -e"pl_v_name in \ \"volume_name\" && p2 in \"dbed_flashsnap\""