Veritas InfoScale™ 8.0.2 Storage and Availability Management for Oracle Databases - AIX, Linux, Solaris
- Section I. Storage Foundation High Availability (SFHA) management solutions for Oracle databases
- Overview of Storage Foundation for Databases
- About Veritas File System
- Overview of Storage Foundation for Databases
- Section II. Deploying Oracle with Veritas InfoScale products
- Deployment options for Oracle in a Storage Foundation environment
- Deploying Oracle with Storage Foundation
- Setting up disk group for deploying Oracle
- Creating volumes for deploying Oracle
- Creating VxFS file system for deploying Oracle
- Deploying Oracle in an off-host configuration with Storage Foundation
- Deploying Oracle with High Availability
- Deploying Oracle with Volume Replicator (VVR) for disaster recovery
- Deployment options for Oracle 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 Oracle database performance
- About database accelerators
- Improving database performance with Veritas Extension for Oracle Disk Manager
- About Oracle Disk Manager in the Veritas InfoScale products environment
- Improving database performance with Veritas Cached Oracle Disk Manager
- About Cached ODM in SFHA environment
- Configuring Cached ODM in SFHA environment
- Administering Cached ODM settings with Cached ODM Advisor in SFHA environment
- Generating reports of candidate datafiles by using Cached ODM Advisor in SFHA environment
- Generating summary reports of historical activity by using Cached ODM Advisor in SFHA environment
- Generating reports of candidate datafiles by using Cached ODM Advisor in SFHA environment
- Improving database performance with Quick I/O
- About Quick I/O
- Improving database performance with Cached Quick I/O
- Section V. Using point-in-time copies
- Understanding point-in-time copy methods
- Volume-level snapshots
- About Reverse Resynchronization in volume-level snapshots (FlashSnap)
- Storage Checkpoints
- About FileSnaps
- Considerations for Oracle point-in-time copies
- Administering third-mirror break-off snapshots
- Administering space-optimized snapshots
- Creating a clone of an Oracle database by using space-optimized snapshots
- Administering Storage Checkpoints
- Database Storage Checkpoints for recovery
- Administering FileSnap snapshots
- Backing up and restoring with Netbackup in an SFHA environment
- Understanding point-in-time copy methods
- Section VI. Optimizing storage costs for Oracle
- Understanding storage tiering with SmartTier
- Configuring and administering SmartTier
- Configuring SmartTier for Oracle
- Optimizing database storage using SmartTier for Oracle
- Extent balancing in a database environment using SmartTier for Oracle
- Configuring SmartTier for Oracle
- SmartTier use cases for Oracle
- Compressing files and databases to optimize storage costs
- Using the Compression Advisor tool
- Section VII. Managing Oracle disaster recovery
- Section VIII. Storage Foundation for Databases administrative reference
- Storage Foundation for Databases command reference
- Tuning for Storage Foundation for Databases
- About tuning Veritas Volume Manager (VxVM)
- About tuning VxFS
- About tuning Oracle databases
- About tuning Solaris for Oracle
- Troubleshooting SFDB tools
- About troubleshooting Storage Foundation for Databases (SFDB) tools
- About the vxdbd daemon
- Resources for troubleshooting SFDB tools
- Manual recovery of Oracle database
- Storage Foundation for Databases command reference for the releases prior to 6.0
- Preparing storage for Database FlashSnap
- About creating database snapshots
- FlashSnap commands
- Creating a snapplan (dbed_vmchecksnap)
- Validating a snapplan (dbed_vmchecksnap)
- Displaying, copying, and removing a snapplan (dbed_vmchecksnap)
- Creating a snapshot (dbed_vmsnap)
- Backing up the database from snapshot volumes (dbed_vmclonedb)
- Cloning a database (dbed_vmclonedb)
- Guidelines for Oracle recovery
- Database Storage Checkpoint Commands
- Section IX. Reference
- Appendix A. VCS Oracle agents
- Appendix B. Sample configuration files for clustered deployments
- Appendix C. Database FlashSnap status information
- Appendix D. Using third party software to back up files
Storage Checkpoints and Rollback process
A Storage Checkpoint is a disk and I/O efficient snapshot technology for creating a "clone" of a currently mounted file system (the primary file system). Like a snapshot file system, a Storage Checkpoint appears as an exact image of the snapped file system at the time the Storage Checkpoint was made. However, unlike a snapshot file system that uses separate disk space, all Storage Checkpoints share the same free space pool where the primary file system resides.
Note:
A database Storage Checkpoint can be mounted as read only or read-write, allowing access to the files as if it were a regular file system.
Initially, a Storage Checkpoint contains no data. The Storage Checkpoint only contains the inode list and the block map of the primary fileset. This block map points to the actual data on the primary file system. Because only the inode list and block map are required and no data is copied, creating a Storage Checkpoint takes only a few seconds and very little space.
A Storage Checkpoint initially satisfies read requests by finding the data on the primary file system, using its block map copy, and returning the data to the requesting process. When a write operation changes a data block in the primary file system, the old data is first copied to the Storage Checkpoint, and then the primary file system is updated with the new data. The Storage Checkpoint maintains the exact view of the primary file system at the time the Storage Checkpoint was taken. Subsequent writes to block n on the primary file system do not result in additional copies to the Storage Checkpoint because the old data only needs to be saved once. As data blocks are changed on the primary file system, the Storage Checkpoint gradually fills with the original data copied from the primary file system, and less and less of the block map in the Storage Checkpoint points back to blocks on the primary file system.
Database Storage Rollback restores a database, a tablespace, or datafiles on the primary file systems to the point-in-time image created during a Storage Checkpoint.
Database Storage Rollback is accomplished by copying the "before" images from the appropriate Storage Checkpoint back to the primary file system. As with Storage Checkpoints, Database Storage Rollback restores at the block level, rather than at the file level. Database Storage Rollback is executed using the vxsfadm command with the -o restore operation.
For example:
$ $ /opt/VRTSdbed/bin/vxsfadm -s checkpoint / -a oracle -o restore --checkpoint_name checkpoint1
Mountable Storage Checkpoints can be used for a wide range of application solutions including the following:
Backups
Investigations into data integrity
Staging upgrades
Database modifications
Data replication solutions
If you mount a Storage Checkpoint as read-write, the command will not allow you to roll back to this Storage Checkpoint. This ensures that any Storage Checkpoint data that has been modified incorrectly cannot be a source of any database corruption. When a Storage Checkpoint is mounted as read-write, then a "shadow" Storage Checkpoint of the original Storage Checkpoint gets created, and this "shadow" Storage Checkpoint is mounted as read-write. This allows the database to still be rolled back to the original Storage Checkpoint.