SQL*_*ood 13 sql-server storage architecture mount-point
以前的高级 DBA 为我们整个公司的每个 SQL Server 中的所有驱动器设置了挂载点。新的高级 DBA被挂载点吓坏了想改变我们的标准（我认为主要是因为他没有使用它们的经验）。
根据大量 Internet 搜索的结果，我找不到任何（SQL Server 2000 后）不使用挂载点的理由。
有没有人知道有关此主题的 Windows 操作系统限制？
是否有任何基于证据或经验的理由不将挂载点与 SQL Server 一起使用？
我的理解是挂载点对于隔离工作负载非常有用。
任何人都可以确认或反驳我的理解，挂载点实际上比一个驱动器更有效地隔离/隔离不同类型的数据和日志文件（系统数据库文件、用户数据库文件、tempDB）的数据文件、日志文件和 tempdb ?
CaM*_*CaM 13
这取决于挂载点另一端的内容。如果装载都是分布在相同物理驱动器上的所有 LUN，则没有任何收益。如果 LUN 全部位于共享的、缓慢的 iSCSI 通道上，则可能没有任何收益。如果 LUN 都在 1 个控制器下……您会看到有多少变量在起作用。没有一个答案。
要确定挂载点的配置，请参阅Boe Prox使用 PowerShell 定位挂载点。
SQL Server安装点没有问题。这些是在操作系统级别定义的，并且 SQL Server“不知道1 ”它们与它们似乎安装在其中的驱动器不同。
但是，某些监控工具可能会根据最后一句话为您提供错误信息。
例如，如果您有三个挂载点，例如
C:\SQLData\SQL_Data 您所有 .MDB 文件的存储位置C:\SQLData\SQL_Logs 您所有 .LDF 文件的存储位置C:\SQLData\SQL_Backups 您所有 .BAK 和 .TRN 备份文件的存储位置 然后 SQL Server 将正常工作。但是，如果您运行某种工具在磁盘空间不足时向您发出警告，它可能会检查 C:而不是它下面的已安装卷，因此您可能不知道这些安装点何时磁盘空间不足。此外，各种“最佳实践”查询会抛出错误警告，告诉您不应将数据、日志和备份都放在同一个磁盘上，因为SQL Server 认为它们在同一个磁盘上。这些是错误标志，可以忽略。
但是您基本上希望在服务器监控中设置一些额外的步骤，以确保 C: 驱动器有足够的空间并且每个挂载点也有足够的空间。
我在 SQL Server 中使用挂载点的次数，这是我遇到的唯一问题：SQL Server 系统健康报告提供有关可用空间的错误数据，以及错误的错误说您不应该拥有所有数据在同一个驱动器上。由于您知道这些是错误的错误，因此很容易忽略它们。
1 SQL Server 有数据使其知道挂载点，但从实际使用的角度来看，在行为上没有区别。它“正常工作”，信任操作系统来处理细节。正如它信任操作系统来处理作为本地驱动器连接的 iSCSI LUN 的细节一样。
根据大量 Internet 搜索的结果，我找不到任何（SQL Server 2000 后）不使用挂载点的理由。
主要原因是有人对他们有不好的经历（或者，相反，没有与他们的经历）并且完全摆脱了他们......永远。这也称为个人偏好。
现在，是你不能使用他们的一些原因。我能想到的第一个原因是第 3 方驱动程序或应用程序/工具（想想过滤器驱动程序、磁盘复制等）不支持它。一个简单的例子是一个块级磁盘复制工具，它不支持 NTFS 以外的任何东西，只有特定的集群大小，对于任何特定的卷都不能超过 2 TB。
有没有人知道有关此主题的 Windows 操作系统限制？
不，你可以制作很多很多挂载点。事实上，在达到 Windows Server 内部的任何明显限制之前，您的设备接口通常会出现问题（假设您没有使用超过 17 年的 Windows Server 版本......）。
• 我最近经常听到“操作系统无法识别挂载点”的说法。（不真实，基于我对我们使用的 Windows Server 版本的研究）。
如果操作系统无法识别挂载点，那么它如何让您使用挂载点？那是没有意义的。
如果操作系统不能识别挂载点，它为什么要跟踪它们并查询它们的元数据？另外，请注意挂载点是操作系统可能支持或不支持的文件系统结构。并非您遇到的所有文件系统都可能支持挂载点，但是 Windows Server 中最常见的文件系统是NTFS，它实际上支持挂载点并且已经有一段时间了。
只是为了把这个不真实的东西带回家更远；Windows 集群有一种叫做集群共享卷 (CSV) 的东西，它实际上使用卷的安装点......这是使用技术的本机项目。我不得不说，无论是谁告诉你的，都需要在这个问题上接受教育。
是否有任何基于证据或经验的理由不将挂载点与 SQL Server 一起使用？
是的，总是有一台运行 Windows NT 4 的服务器......不要在那里使用它。您可能还想确保您正在运行受支持的 Windows Server 版本并保持最新的更新。
但是，如上所述，可能存在不受支持或无法正常使用的第 3 方项目。我会说放弃那个提供者并找到一个新的。
我的理解是挂载点对于隔离工作负载非常有用。
挂载点非常有用。有很多方法可以使用它们，最常见的是绕过 Windows 的驱动器号限制（因为只有这么多）。下一个最常见的用途是拥有更小的可管理大小的驱动器（想想 LUN、虚拟磁盘 [VMDK、VHDX]），以帮助摆脱非常大且难以管理的整体卷（管理 10TB 范围内的驱动器确实成为一个问题，因为单个 LUN、虚拟磁盘等），尤其是在较旧版本的 NTFS 上，其实现低于可能的使用量……例如，在较旧版本的 Windows 中，最大 NTFS 大小为 2TB。
工作负载隔离是另一个很好的用途。您绝对可以看到，有很多用途，这取决于您的个人用例。也有不正确的使用方法......例如，做出一个笼统的声明，一切都需要成为一个挂载点。那时这只是疯狂的管理开销。
除了 CM_Dayton 的回答和 Sean Gallardy 的回答之外，Mount Points 尚未确定的一个问题与安全有关。引用在挂载点文件夹上设置 SQL 权限的指南：
尽管挂载点根文件夹可能看起来像常规文件夹并且以访问文件夹的相同方式访问，但它们不是常规文件夹。因此，当您对挂载点根文件夹设置权限时，权限不会像常规文件夹一样从“父卷”继承。事实上，它们根本不是遗传的。这是因为虽然看起来安装的卷是“父卷”的子卷，但事实并非如此。您只需通过“父卷”的路径访问已安装的卷。
简而言之，如果您想使用挂载点根文件夹，您必须以不同的方式为挂载文件夹分配权限。您必须为卷分配权限，而不是像对普通文件夹那样分配权限。同样，来自同一篇文章（突出显示的是微软的）：
陷阱
不幸的是，仍然可以通过 Windows 资源管理器设置/查看挂载点根文件夹的权限，这可能会导致意外结果，因为挂载点根文件夹的权限可能看起来是有效的，您可以看到“正确”的继承权限，但是这些不是应用于已安装卷的权限。
指南
- 建议您不要将任何文件直接放在挂载点根文件夹中。这将使权限管理更加简单，因为倾向于始终检查文件夹权限，在这种情况下会产生误导。相反，在挂载点根文件夹下创建一个子文件夹，并为该子文件夹设置适当的权限。由于子文件夹是常规文件夹，您观察和设置的文件夹权限确实是正在应用的权限。因此，使用前面的示例，您需要创建一个新文件夹：D:\FolderForVol3**SubfolderXYZ**。现在，像往常一样针对新的SubfolderXYZ文件夹设置文件夹权限。
- 如果您绝对必须将项目直接放在挂载点根文件夹中（不是推荐的方法），那么您将需要设置卷权限，而不是文件夹权限。回想一下，这是因为挂载点根文件夹权限不是实际在挂载卷上设置的权限（因为挂载点根文件夹不是真正的文件夹）。您可以按如下方式设置卷权限：
- 开始->运行->diskmgmt.msc（查看卷的属性 http://technet.microsoft.com/en-us/library/cc740097.aspx）
- 选择音量->属性->安全选项卡
- 如果您要添加一个新文件夹供 SQL 使用，请注意 SQL 访问所需的权限：
- 从 SQL Server 2012 开始，权限被分配给每个服务的每个服务 SID。 http://msdn.microsoft.com/en-us/library/jj219062.aspx
- 配置 Windows 服务帐户和权限 http://msdn.microsoft.com/en-us/library/ms143504.aspx
如果您不想按照 MS 的建议将所有内容都嵌套在 Mount Point 下的子文件夹中，我发现分配权限的最简单方法是通过该cacls.exe实用程序。有关详细说明，请参阅您无法在 Windows Server 2003 中对 NTFS 文件系统卷的根目录应用权限。
我认为这还不是一个完全解决的问题。这个最近的问题SQL Server FCI 安装与装载点权限问题表明它仍然可以在 Windows 2012 和 SQL Server 2016 上发生。
根据您想要分配的安全性，命令可能会有所不同，但测试是成功的关键，因此在针对实时挂载点运行它之前先熟悉该命令，因为如果您忘记了像\E标志这样简单的事情，您可以快速破坏安全性。
| 归档时间： |
|
| 查看次数： |
9216 次 |
| 最近记录： |