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 clone of a database by using Database FlashSnap
You can use Database FlashSnap to create a clone of a database by performing the steps outlined in Figure: Creating a Clone - Workflow .
For details, refer to vxsfadm-flashsnap(1M) and vxsfadm-db2-flashsnap(1M) man pages.
To create a clone of a DB2 database by using FlashSnap
- Create a configuration file.
$ /opt/VRTS/bin/vxsfadm -s flashsnap \ -a db2 -o setdefaults --db2instance db2inst1 \ --db2database proddb --flashsnap_name daily_snap -c dailyconfig Written config file dailyconfig
This command creates a default configuration file with all the parameters and default values. You can change the parameters, if required.
Note:
If you have exported in environment the DB2INSTANCE and DB2DATABASE parameters, you do not need to include them on the command line. In the following steps, it is assumed that DB2INSTANCE and DB2DATABASE are available from the environment.
- Validate the setup.
$ /opt/VRTS/bin/vxsfadm -s flashsnap \ -a db2 -o validate -c dailyconfig Validating database configuration for third-mirror-break-off snapshot: DB2INSTANCE = db2inst1 DB2DATABASE = proddb APP_MODE = online SNAPSHOT_ARCHIVE_LOG = auto ARCHIVELOG_DEST = /db2arch/ Database validation successful. Validating database volume layout for third-mirror-break-off snapshot: Data volumes ready for snapshot: Volume/volume-set db2datavol of diskgroup db2dg mounted on /db2data. Archivelog volume ready for snapshot: Volume/volume-set db2archvol of diskgroup db2dg mounted on /db2arch. Storage units to be used for snapshot from diskgroup db2dg: ds4100-0_9 ds4100-0_7 SNAPSHOT_VOL_PREFIX = SNAP_ SNAPSHOT_DG_PREFIX = SNAP_ Database volume layout validated successfully.
This command validates the configuration file and the database environment. In case of any problem, appropriate error messages are displayed that you can use to correct the problem and then retry.
- Create a snapshot of the database.
$ /opt/VRTS/bin/vxsfadm -s flashsnap \ -a db2 -o snap -c dailyconfig Validating database configuration for third-mirror-break-off snapshot: DB2INSTANCE = db2inst1 DB2DATABASE = proddb APP_MODE = online SNAPSHOT_ARCHIVE_LOG = auto ARCHIVELOG_DEST = /db2arch/ Database validation successful. snapshot started at Tue Mar 20 00:39:41 2012. Putting database in write-suspend mode... Done Validating database volume layout for third-mirror-break-off snapshot: Data volumes ready for snapshot: Volume/volume-set db2datavol of diskgroup db2dg mounted on /db2data. Archivelog volume ready for snapshot: Volume/volume-set db2archvol of diskgroup db2dg mounted on /db2arch. Storage units to be used for snapshot from diskgroup db2dg: ds4100-0_9 ds4100-0_7 SNAPSHOT_VOL_PREFIX = SNAP_ SNAPSHOT_DG_PREFIX = SNAP_ Database volume layout validated successfully. Creating snapshot volumes for data volumes ... Done Taking database out of write-suspend mode... Done Creating snapshot volume for archivelog volume ... Done Copying snapshot information to snapshot volume ... Done Creating snapshot diskgroups ... Done Deporting snapshot diskgroups ... Done SNAP_db2dg snaphot ended at Tue Mar 20 00:40:23 2012.
This command breaks the user-specified mirror ( parameter SNAPSHOT_PLEX_TAG ) from the primary volumes and creates a new disk group with the name starting with the string defined in the snap_dg_prefix parameter. The default value of this parameter is SNAP_.
Note:
At the validation stage, all the parameters, including the mandatory parameters --db2instance, --db2database, and --flashsnap_name, are read and stored in the repository.
If you need to change any parameter, change the configuration file and specify it with the -c option.
- Mount the snapshot.
$ /opt/VRTS/bin/vxsfadm -s flashsnap \ -a db2 -o mount -c dailyconfig Retrieving snapshot information ... Done Importing snapshot diskgroups ... Done Mounting snapshot volumes ... Done
Note:
This command mounts the snapshot on the host running the DB2 instance. The secondary host is the system defined in the SECONDARY_HOST parameter of the configuration file.
By default, volumes are mounted under the
/var/tmpfile system.If you need to specify an alternate location for mounting snapshot volumes, either provide CLONE_PATH on the command line or from the configuration file.
For performing off-host operations, specify the SFDB repository host using the -r option of the vxsfadm command.
Note:
Ensure that the DB2 user has the required permissions to create the
/clonedb2directory, if it does not exist. - Clone the database based on the snapshot.
$ /opt/VRTS/bin/vxsfadm -s flashsnap \ -a db2 -o clone -c dailyconfig Retrieving snapshot information ... Done Importing snapshot diskgroups ... Done Mounting snapshot volumes ... Done Relocating/ Renaming clone database clone1 ... Done Initializing clone database clone1 ... Done Activating clone database clone1 ... Done
If you have not specified clone_name, it is automatically generated.
Note:
If you have already specified the clone_name and the clone_path parameters in the configuration file that was used during the validate operation, the clone_name parameter is not required on the command line.