The following are recommended best practices when using PowerMax local replications with SQL Server databases. Unless specified otherwise, references to storage snapshots apply similarly to storage clones.
- Separate storage volumes allocated to system and user databases. This practice allows snapshots to include the user database (or databases) alone. As a result, if the snapshot is restored or attached as a database copy, the SQL Server instance and its system databases are not interrupted.
- When multiple databases share the same storage volumes for their data and log files, a snapshot of these volumes contains all the databases. Only share storage volumes between databases that are meant to be in the same snapshot or are not meant to be used with snapshots.
- When attaching a database copy to another instance, install and configure the target instance with its system databases ahead of time so that the database copy can be added using the Attach command without delays associated with creating the instance (including the creation of WSFC and FCI on Windows).
- As explained earlier, irrespective of the choice of original database file placement or file system structure, the Attach command allows a new choice of database files location and database name.
- When using a target WSFC to attach multiple copies of the original database, a resource bottleneck might occur because the instance is on one cluster node at a time. In such a case, consider using multiple SQL Server instances for the copies to balance the workload and resource consumption across the target WSFC nodes.
- When using mount points file placement for SQL Server on Windows with WSFC, set disk dependencies correctly so the instance service has dependency on the disks that are mounted, and the disks have a dependency on the root-mount disk. This practice ensures the correct order of startup operations for the instance services.