InfoScale™ 9.0 Storage Foundation Quick Recovery Solutions Guide for Microsoft SQL Server - Windows
- Introducing Quick Recovery for SQL Server
- Methods of implementing Quick Recovery snapshots for SQL Server
- About the components used in Quick Recovery
- Preparing to implement Quick Recovery for SQL Server
- Implementing Quick Recovery for SQL Server with the configuration wizard
- About the Quick Recovery Configuration Wizard
- Scheduling SQL Server snapshot sets
- Scheduling or creating an individual snapshot set for SQL Server
- Maintaining or troubleshooting snapshots
- Recovering a SQL Server database
- Recovering missing volumes
- Vxsnap utility command line reference for SQL Server
Configuration requirements and best practices
Review the following configuration requirements and best practices:
The system and boot volumes must reside on a separate disk (Harddisk0) from the dynamic volumes used for the SQL user-defined databases and split-mirror snapshots.
Disk groups must be of a Storage Foundation 4.0 or later version. Upgrade any disk groups created using an earlier version of Volume Manager for Windows before creating Quick Recovery snapshots.
Quick Recovery snapshots are supported only on volumes belonging to an SFW dynamic disk group. They are not supported on volumes belonging to a Microsoft Disk Management Disk Group. For more information on Microsoft Disk Management Disk Groups, see Storage Foundation Administrator's Guide.
Database, transaction logs, and FILESTREAM filegroups must be stored on disks within a single dynamic disk group.
Database, transaction logs, and FILESTREAM filegroups should be on separate disks so that disk failure does not affect anyone of these filegroups.
User-defined database, transaction logs, and FILESTREAM filegroups may not be stored in the same volume as the SQL Server program files or system data files.
In order to perform a roll-forward recovery to the point of failure, database, transaction logs, and FILESTREAM filegroups must be in separate volumes.
Locate snapshot volumes on separate disks from any database, log, and FILESTREAM filegroup volumes so that the snapshot process will not interfere with database operations.
Locate the snapshot volumes for each database on separate disks from snapshots of other databases. This is recommended so that the process of creating the snapshot of one database doesn't interfere with any operations on another database.
Warning:
The snapshot XML files must be stored separately from the volumes that are included in snapshots, otherwise a restore will fail.
Transaction logs should always be configured in a redundant layout. The preferred software layout is RAID 0+1 (mirrored striped) volumes as this provides better read and write performance than RAID 1 (mirrored) alone. The transaction log will generate the most I/O and thus should use the highest performance disks available.
The preferred layout for the database is hardware RAID 5, software RAID 1 (mirrored with logging enabled) or software RAID 0+1 (mirrored striped).
Note:
FlashSnap is not supported for software RAID 5 volumes.