SnapManager databases can be configured on one or more storage systems. This section shows the various ways that you can place the data of your SQL Server on storage system volumes.
If you archive a database to a SnapVault backup (clustered Data ONTAP only), the database and SnapInfo directory must be on separate volumes.
For example, you can place any number of databases on the same SMB share and you can span a database across multiple SMB shares.
You cannot spread a database's files across LUNs and SMB shares.
SnapManager does not recognize a share by the CIFS server's IP address. It recognizes a share by the CIFS server's name.
For example, the name of a CIFS server is FOX_VS01. The Vserver also has an IPv6 data LIF called fd20-8b1e-b255-303---ac11-5b5.ipv6-literal.net. The database files need to use \\FOX_VS01\sharename as a file path to the share. The files cannot use \\fd20-8b1e-b255-303--ac11-5b5.ipv6-literal.net\sharename as a path to the share.
If the database already uses a path with an IP address in the share name, manually detach the database, then attach the database using the SMB share path with the CIFS server name in its share name. Since both share paths point to same share, no files are moved.
The following supported configuration
shows multiple SQL Server databases sharing the same volume but
residing on different LUNs.
following illustration shows multiple SQL Server databases and all
their associated files and transaction logs on one LUN.
This is a simple configuration, and it can be applied to an SQL Server that supports about 35 databases per volume.
following illustration shows an example of multiple SQL Server databases
and all their associated files and transaction logs sharing exactly
two LUNs. The database files cannot reside on any other LUNs. The
LUNs can be located on the same or different storage system volumes.
The illustration shows an example in which each LUN is located on
a different volume.
By placing the data files for multiple databases on one LUN and the transaction logs for those databases on the other LUN, SQL database performance is improved by separating the random I/O patterns of the data files from the sequential I/O patterns of the transaction log files.
The following illustration shows a configuration
in which the data and transaction log files of an SQL Server database
reside on separate storage system volumes. Placing all transaction
logs on one volume and using another volume for all the database
files is partly due to performance. If the volume with the data
files fails, it is still possible to back up the log file, restore
the last full backup, and then apply all backed-up current transaction
logs. This configuration requires another volume for the SnapInfo
When the SQL Server environment does not generate high I/O load, a single volume can optimize the use of disk and volume space. However, this configuration has two disadvantages:
For information about busy Snapshot copies, see "Busy
Snapshot error prevents deletion of backup set" in Explicitly deleting backup sets using SnapManager.
The following illustration
shows a storage system volume with LUNs containing the data files
of multiple SQL Server instances residing on a storage system volume
that is different from the volume on which the LUNs for the transaction
log files reside.
The following illustration
shows multiple file groups belonging to the same database residing
on different LUNs within the same storage system volume.
The following illustration shows multiple file
groups belonging to the same database residing on different VMDKs
on the same datastores.