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
Scheduling the relocation of archive and Flashback logs
As are the primary mechanism for recovering from data corruption, database logs are normally kept on premium storage, both for I/O performance and data reliability reasons. Even after they have been archived, logs are normally kept online for fast recovery, but the likelihood of referring to an archived log decreases significantly as its age increases. This suggests that archived database logs might be relocated to lower-cost volumes after a certain period of inactivity.
Similarly, Storage Foundation Flashback technology creates logs that can be used for quick recovery from database corruption by restoring a database to its state at a previous time. Flashback logs are normally kept for a shorter period than archived database logs, if used at all, they are typically used within a few hours of creation. Two or three days are a typical Flashback log lifetime.
The rapidly decaying probability of use for archive and Flashback logs suggests that regular enforcement of a placement policy that relocates them to lower-cost storage after a period of inactivity can reduce an enterprise's average cost of online storage.
For example procedures, a customer could be using a large OLTP Oracle database with thousands of active sessions, which must be up and running 24 hours a day and seven days a week with uptime of over 99%. The database uses Flashback technology to correct any accidental errors quickly and generates a large number of archive logs per day. If the database goes down for any reason, there is a business requirement to bring the database back online and get it functional with in 15 minutes. To prevent Oracle log switch delays during transactions, the archive logs need to be created in a fast EMC array. Archive logs older than a week can be moved to a mid-range Clarion array. Archive logs older than 15 days can be moved to slow JBOD disks. Archive logs are purged after 30 days. Current Flashback logs are created manually by the database administrator on fast EMC storage and can be moved to Clarion storage after two days. The database administrator then deletes the Flashback logs after a week. To set up a system like this, see the following example. Assume that archive logs and Flashback logs are created on the same file system, /oralog. On the file system, /oralog/archive1 contains archive logs and /oralog/flashback contains Flashback logs.
Figure: Database storage configuration suitable for automatic relocation of archive and Flashback logs illustrates a three-tier volume configuration that is suitable for automatic relocation and deletion of archive logs and Flashback logs.
Figure: Database storage configuration suitable for automatic relocation of archive and Flashback logs
The file system used by the production database in this example originally resides on the single volume oralog, which must be prepared by adding volumes and placement classes assigned to the volumes.
To add the NEW, MEDIUM, and OLD storage classes
- Use the dbdst_admin command as follows:
$ /opt/VRTS/bin/dbdst_admin -S PROD -o addclass=\ NEW:"EMC Storage for Production DB"
$ /opt/VRTS/bin/dbdst_admin -S PROD -o addclass=\ MEDIUM:"Clarion Storage for Production DB"
$ /opt/VRTS/bin/dbdst_admin -S PROD -o addclass=\ OLD:"JBOD Storage for Production DB"
To convert the database's file system and add volumes for use with SmartTier for Oracle
- Use the dbdst_convert command as follows:
$ /opt/VRTS/bin/dbdst_convert -S PROD \ -M /dev/vx/dsk/oradg/oralog -v emc_v1,clarion_v1,jbod_v1
To classify volumes into storage classes
- Use the dbdst_classify command as follows:
$ /opt/VRTS/bin/dbdst_classify -S PROD \ -M /dev/vx/dsk/oradg/oralog -v emc_v1:NEW
$ /opt/VRTS/bin/dbdst_classify -S PROD \ -M /dev/vx/dsk/oradg/oralog -v clarion_v1:MEDIUM
$ /opt/VRTS/bin/dbdst_classify -S PROD \ -M /dev/vx/dsk/oradg/oralog -v jbod_v1:OLD
Once the volumes are configured, an administrator can define file placement policy rules that specify access age-based relocation of selected files and assign them to the database's file system.
To define rules that periodically relocate Flashback and archive logs
- Use the dbdst_file_move command as follows:
$ /opt/VRTS/bin/dbdst_file_move -S PROD -o flashback -c MEDIUM:2
This command relocates files in the Flashback directory that have not been accessed for two days to the MEDIUM volume.
$ /opt/VRTS/bin/dbdst_file_move -S PROD -o archive1 -c MEDIUM:7 \ -c OLD:15
This command relocates files in the archive1 directory that have not been accessed for seven days to the MEDIUM volume, and files that have not been accessed for 15 days to the OLD volume.
SmartTier for Oracle translates these commands into SmartTier access age-based policy rules, merges them with the file system's placement policy, and assigns the resulting policy to the file system. By default, SmartTier for Oracle enforces the active policy daily. During enforcement, the new rules relocate qualifying files to the destination storage tiers specified in the dbdst_file_move commands used to create the policies.