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
FlashSnap configuration parameters
Table: FlashSnap - Configuration Parameters lists the FlashSnap configuration parameters that can be provided in the configuration file. If you want to specify the parameter on the command line, refer to the Command Line Option column of the table.
Table: FlashSnap - Configuration Parameters
Parameter | Description | Accepted Values | Command Line Option |
|---|---|---|---|
VERSION | The version of the configuration file format. | n.n Example: 6.0 | NA |
FLASHSNAP_NAME (*) | A unique identifier of the FlashSnap configuration. | String Example: snap1 | --flashsnap_name snap1 OR --name snap1 |
DB2INSTANCE (*) | The DB2 instance name. | String Example: db2inst1 | --db2instance db2inst1 OR -I db2inst1 |
DB2DATABASE (*) | The DB2 database name. | String Example: proddb | --db2database proddb OR -D proddb |
APP_MODE | The mode of the application when the snapshot operation is being performed. | offline online instant | --app_mode offline OR online OR instant |
SNAPSHOT_PLEX_TAG | The value of the putil2 attribute tag for the plexes that must be a part of the snapshot. | String Example: dbed_snap1 | --snapshot_plex_tag dbed_snap1 OR --plex dbed_snap1 |
SNAPSHOT_VOL_PREFIX | The string prefixed to volume names to create snapshot volume names. | String Example: SNAPVOL_ | --snapshot_vol_prefix SNAPVOL_ |
SNAPSHOT_DG_PREFIX | The string prefixed to disk group names to create snapshot disk group names. | String Example: SNAPDG_ | --snapshot_dg_prefix SNAPDG_ |
SNAPSHOT_MIRROR | The number of mirrors that need to broken off to form the snapshot volumes. | Number Default: 1 | --snapshot_mirror 2 OR --n 2 |
SNAPSHOT_ARCHIVE_LOG | If this parameter is set, the snapshot operation is also performed on the archive log volumes. | Yes No auto (**) Default: auto | --snapshot_archive_log y OR --no_snapshot_archive_log |
SECONDARY_HOST | The host on which the snapshot can be mounted and the application can be cloned. | Host name | --secondary_host sys4 |
MAPPED_MOUNTS | The volume-to-mountpoint mapping that specifies the paths where the snapshot volumes should be mounted. | dg1:volume1=path1; dg2:volume2=path2 Example: mydg:datavol=/tmp/fsnp; | --mapped_mounts mydg:datavol=/tmp/fsnp |
CLONE_PATH | The file system path under which the the clone application instance must be mounted. | Valid path
| --clone_path
|
CLONE_NAME | The name of the clone DB2 database that being created in the clone operation. | String Example: clone1 | --clone_name clone1 |
Note:
(*) denotes that the parameter is mandatory.
Note:
(**) If the SNAPSHOT_ARCHIVE_LOG parameter is set to auto, the snapshot operation is performed on the archive logs depending on whether log archiving is enabled or not. If log archiving is not enabled, the snapshot operation is not performed on archive logs. If log archiving is enabled, and if at least one of the archive log destinations, specified by the logarchmeth1 and logarchmeth2 parameters, is set to a local "DISK:" destination, then the snapshot operation is performed on archive logs.