Drives vs. Mount Points?

The previous Senior DBA set up mount points for all of our drives across every SQL Server throughout the company. The new Senior DBA is horrified by mount points wants to change our standard (mainly, I think, because he has no experience with them).

Based on the results of numerous internet searches, I can't find any (post-SQL Server 2000) reason to not use mount points.

Is anyone aware of Windows OS limitations regarding this topic?

• I've been hearing the claim "the OS doesn't recognize mount points" a

lot lately. (Untrue, based on my research into the versions of Windows Server we use).

Is there any evidence- or experience-based reason NOT to use mount points with SQL Server?

• Assume that running out of drive letters is not an issue for us.

It's my understanding that mount points are incredibly useful for segregating workloads.

Can anyone confirm or refute my understanding that mount points actually segregate/isolate workloads of the different types of data and log files (system database files, user database files, tempDB) more efficiently than one drive each for data files, log files, and tempdb?

It depends on what's at the other end of the mount point. If the mounts are all LUNS spread across the same physical drives, then no gains. If the LUNS are all over a shared, slow, iSCSI channel, maybe no gains. If the LUNS are all under 1 controller...you see how many variables are at play. There's no one answer.

To determine the configuration of the mount points, see Locating Mount Points Using PowerShell by Boe Prox.

SQL Server has no problem with mount points. These are defined at the OS level and SQL Server "doesn't know1" they're not the same volume as the drive they appear to be mounted in.

Some Monitoring tools might give you bad information based on that last sentence, however.

For example if you have three mount points like

• C:\SQLData\SQL_Data where all your .MDB files are stored

• C:\SQLData\SQL_Logs where all your .LDF files are stored

• C:\SQLData\SQL_Backups where all of your .BAK and .TRN backup files are stored

Then SQL Server will work without any issues. But if you run some sort of tool that warns you when disks are low in space, it may check the C: and not the mounted volumes below it, so you may not know when those mount points are low on disk space. Also, various "best practices" queries will throw false warnings telling you that you shouldn't have your data, logs, and backups all on the same disk because SQL Server thinks they are on the same disk. Those are false flags, and can be ignored.

But you'd basically want to set up some additional steps in your server monitoring to make sure the C: drive has enough space and that each mount point does, too.

The times I've used mount points in SQL Server, that's been the only issue I've run into: SQL Server system health reports that give false data about free space available, and false errors saying you shouldn't have all of your data on the same drive. Since you know those are false errors, they are easy enough to ignore.

1 SQL Server has data that makes it aware of the mount point, but from a practical use viewpoint, there's no difference in behavior. It "just works," trusting the OS to handle the specifics. Just as it trusts the OS to handle the specifics for iSCSI LUNs that are connected as local drives.

StackExchange Database Administrators Q#164311, answer score: 13