SQL Server support for mounted volumes

This article discusses issue that you must consider when you use mounted folders together with versions of Microsoft SQL Server in stand-alone and clustered environments.

Support policy

The availability of support for mounted folders depends on the version of SQL Server and on whether the instance of SQL Server is a stand-alone or clustered instance:
Note Mounted folders are also known as any of the following:

• Mounted volumes
• Mounted drives
• Mountpoints
• Mount points
• Volume mount points

Stand-alone instance

On a stand-alone instance of SQL Server, data storage on mount points is supported on currently supported versions of Windows Server and SQL Server. However, the SQL Server Setup program requires the base drive of a mounted drive to have an associated drive letter. If the base drive of a mounted drive does not have an associated drive letter, the Setup program will assign the next available drive letter to the drive.

Note If all the drive letters are already assigned, the Setup program will fail.

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

Clustered instance

On a clustered instance of SQL Server 2000, data storage on mount points is not supported. The installation of SQL Server 2000 is not supported on a clustered configuration that has mount points even if the mount points are not meant to be used with the instance of SQL Server 2000.

On a failover clustered instance of SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, or SQL Server 2012, data storage on mount points is supported. However, the clustered installations of SQL Server are limited to the number of available drive letters. Therefore, if you use only one drive letter for the operating system, and if all other drive letters are available as normal cluster drives or as cluster drives that are hosting mount points, you are limited to no more than 25 instances of SQL Server per failover cluster.

A mounted volume, or mount point, lets you to use a single drive letter to refer to many disks or volumes. For example, if you have a drive letter R: that refers to a regular disk or volume, you can connect or "mount" additional disks or volumes as directories under drive letter R: without the additional disks or volumes requiring drive letters of their own.

Additional mount point considerations for SQL Server failover clustering include the following:

• SQL Server Setup requires that the base drive of a mounted drive has an associated drive letter. For failover cluster installations, this base drive must be a clustered drive. Volume GUIDs are not supported in this release.
• The base drive is the drive that is assigned the drive letter. The base cannot be shared among failover cluster instances. This is a usual restriction for failover clusters but is not a restriction on stand-alone, multi-instance servers.
• Be careful when you set up your failover cluster to make sure that both the base drive and the mounted disks or volumes are listed as resources in the resource group. SQL Server Setup validates drive configuration as part of a failover cluster installation.  
  Note As a best practice, do not use the letters A or B for a cluster. However, this reduces the number of possible instance to 23 instances per cluster.
• The SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, and SQL Server 2012 resource depends on the SQL network name resource and on the physical disk resources that hold the data. Mount points and the host drive must be displayed as a cluster physical disk resource. Additionally, the physical disk that has a drive letter and each mounted volume must also be added as a SQL Server dependency.
• If you perform a new installation, the correct dependency permissions are set on the physical disks that have an associated drive letter and on the mount points. The dependency permissions are set automatically during setup.

Note To use this functionality, you must use a slipstreamed SQL Server 2008 or SQL Server2008 R2 installation. This includes the cumulative update and the required service pack.

• A SQL Server 2008 slipstream installation that includes SQL Server 2008 Service Pack 3 and cumulative update package 9 for SQL Server 2008 Service Pack 3.
• A SQL Server 2008 R2 slipstream installation that includes the following:
  • SQL Server 2008 R2 Service Pack 1
  • Cumulative update package 10 for SQL Server 2008 R2 Service Pack 1
  • Cumulative update package 4 for SQL Server 2008 R2 SP2
• A SQL Server 2012 installation that has Product Updates enabled and Cumulative Update Package 6 for SQL Server 2012 installed.  
  
  Note The Product Updates feature in SQL Server 2012 requires Internet access.

Important We recommend that you use the command line switches PCUSOURCE and CUSOURCE when you use a basic slipstream installation.

Important If you use a merged slipstream, that version of the slipstream must remain available in its original location as long as the instance of SQL Server exists.

Important You must manually set the correct dependencies in SQL Server 2005 and in versions of SQL Server 2008 Service Pack 2 and earlier versions. Additionally, you must set the correct dependencies in installations that are missing the required dependencies.

If only the root physical disks dependency is added and the mount points dependency is not added, database corruption will occur on failover. Database corruption may also occur during a SQL Server restart should disk resources go offline and return to online state even without failing over.

Windows Server 2003 supports mounted drives in a cluster. However, because of limitations in SQL Server 2000, using mounted volumes on a failover cluster in which a SQL Server 2000 failover clustered instance exists is not supported on any operating system.

Note The information in this article supersedes the information in the Microsoft Press book "SQL Server 2000 High Availability.” The information that is superseded appears in chapter 4, "Disk Configuration for High Availability," of part 2, "Microsoft SQL Server Technology."

The NTFS file system supports mounted folders. A mounted folder is an association between a volume and a directory on another volume. When a mounted folder is created, users and applications can access the target volume either by using the path of the mounted folder or by using the volume's drive letter. For example, a user can create a mounted folder to associate drive X: with the R:\Mnt\XDrive folder on drive R. After you create the mounted folder, the user can use the "R:\Mnt\XDrive" path of access drive X: as if it was a folder on the R: drive.

When you use mounted folders, you can unify different file systems such as the NTFS file system, a 16-bit FAT file system, and an ISO-9660 file system on a CD drive into one logical file system on a single NTFS volume. Neither users nor applications need information about the target volume on which a specific file is located. All the information that they must have to locate a specified file is a full path that uses a mounted folder on the NTFS volume. Volumes can be rearranged, substituted, or subdivided into many volumes without requiring users or applications to change settings.

Typically, SQL Server mounted folders use a single physical disk to host the mounted folders. The mount points are added by using descriptive folder names so that all the mounted folders are displayed as being on a single physical disk.

In the following SQL Server 2008 R2 example, the drive letter could refer to either a local drive or a cluster disk:

• X:\Program Files\Microsoft SQL Server\MSSQL10_50.InstanceID\Data
  Note This is the default path.
• X:\Program Files\Microsoft SQL Server\MSSQL10_50.InstanceID\Log
• Y:\Temp
• Z:\MSSQL10_50.InstanceID\Backup

In some scenarios, you may have to use a directory off the root. For example, if drive Z: is a physical disk that hosts the mounted folder, the mounted folder is the root of the mount point. If using the mounted folder as the root is not supported, you must use a directory off the root. For example, you can use the MP1 folder:



In this scenario:

• Z:\MountPoint1 is the container for mounted volumes.
• Z:\MountPoint1\MP1 is the first mounted volume. When you install SQL Server, SQL Server Setup can be directed to a subfolder in a mounted folder. When you install SQL Server, you can specify the following:
  
  Z:\MountPoint1\MP1|DBLog1

This lets you specify additional log locations such as directories that are named DBLog2 or DBLog3. It also lets you add mounted folders such as Z:\MountPoint2\MP1\Log1 or Z:\MountPoint2\MP1\Log2. Additionally, you can add mounted folders that host directories for database files such as tempdb or backups. 

The following is an example of a dependency report that shows a mount point that is being used:



In this diagram:

• Cluster Disk 1 has no required dependencies.
• Cluster Disk 4, Mount point dependencies are Cluster Disk 1.
• Cluster Disk 4, Mount point has no required dependencies.
• IP Address: xxx.xxx.xxx.88 has no required dependencies.
• IP Address: xxx:xxxx:c0:xxxx.xxxx:c597:8cb0:49f2 has no required dependencies.
• Name: SOFTY dependencies are IP Address: xxx:xxxx:c0:xxxx:xxxx:c597:8cb0:49f2 and IP Address: xxx.xxx.xxx.88.
• SQL Network Name (SOFTY) required dependencies are IP Address.
• SQL Server dependencies are Name: SOFTY and Cluster Disk 4, Mountpoint and Cluster Disk 1.
• SQL Server has no required dependencies.

The mounted file is displayed in Failover Cluster Manager under disk drives:




If you previously installed SQL Server to a root directory, we recommend that you create a folder, validate the current database integrity by using the DBCC CHECKDB statement, and then move the database to the folder that you created. For information about how to do this, go to one of the following Microsoft Developer Network (MSDN) websites:

• Move User Databases: SQL Server 2012
  (http://msdn.microsoft.com/en-us/library/ms345483.aspx)
• Moving User Databases: SQL Server 2008
  (http://msdn.microsoft.com/en-us/library/ms345483(v=SQL.100).aspx)
• Moving User Databases: SQL Server 2005
  (http://msdn.microsoft.com/en-us/library/ms345483(v=SQL.90).aspx)

Best practices when you use volume mount points

The following are best practices when you use volume mount points:

• Make a dependency in the mounted volume disk resource that specifies the disk that is hosting the mount point folder. This makes the mounted volume dependent on the host volume, and it makes sure that the host volume comes online first.
• If you move a mount point from one shared disk to another shared disk, make sure that the shared disks are located in the same group.
• Try to use the root (host) volume exclusively for mount points. The root volume is the volume that hosts the mount points. This practice greatly reduces the time that is required to restore access to the mounted volumes if you have to run the Chkdsk.exe tool. This also reduces the time that is required to restore from backup on the host volume.
• If you use the root (host) volume exclusively for mount points, the size of the host volume must be at least 5 megabytes (MB). This reduces the probability that the volume will be used for anything other than the mount points.

For more information about mounted drives, click the following article numbers to view the articles in the Microsoft Knowledge Base:


For more information about volume mount points, go to the following Microsoft website:


For more information about the Product Update feature in SQL Server 2012, go to the following MSDN website:


For more information about mounted drives, see the following topics in Windows Help Online:

• "Windows Server 2003 Help"
• "Disks and Data"
• "Managing Disks and Data"
• "Disk Management"
• "Using NTFS Mounted Drives"