前言
在我工作的公司，我们在 ETL 流程中使用数据库快照来确保数据处于一致状态。快照文件被放置在一个单独的磁盘上（在我们的例子中是 X:）。
其中一个源数据库是一个 3TB 的数据库，其数据经常更新。在创建此数据库的数据库快照时，我们遇到了快照文件增加并且出现错误的时刻：
“遇到操作系统错误 112（磁盘空间不足。）。”
该错误始终出现在索引维护窗口中，或者在源数据库中运行批量进程时。从那时起，我们增加了 X:\ 驱动器上的可用磁盘空间，并更改了索引维护/dbcc checkdb 作业的计划。正如预期的那样，错误不再发生。
问题
有时我们需要一些大型表的初始加载（600.000.000 行/每个表 300GB）。本周我们在加载这些大表时遇到了不同的错误：
在文件“X:\Data\DatabaseName_snapshot.ss”中的偏移量 0x000056fb976000 处写入期间，操作系统向 SQL Server 返回错误 665（请求的操作由于文件系统限制而无法完成）。
SQL Server 错误日志和系统事件日志中的其他消息可能会提供更多详细信息。
此错误仅在创建快照后 18 到 25 小时内发生。
已经尝试过的事情
- 禁用所有索引维护/dbcc checkdb 作业和其他更改大量数据的进程（用户输入除外）。
- 监控快照磁盘上的可用空间（X:\ 400GB）。发生错误时，大约 80% 的可用空间是可用的。
- 在 stackexchange 上寻找类似的问题。发现的数据库快照进入未回答的可疑模式（WIN2K8R2 上的 SQL 2014） 。
- 立即查看文章https://blogs.msdn.microsoft.com/psssql/2015/06/10/operating-system-error-665-file-system-limitation-not-just-for-dbcc-anymore/。
有没有人有更多的想法来解决这个问题？
我们使用的是 SQL Server 2014 SP2 CU1，企业版和 Windows Server 2012。
问题在于 NTFS 分配映射及其用于文件分配的空间量。通常，文件碎片越多，需要的分配映射就越多。
默认情况下，当卷被格式化为 NTFS 时，选择小分配映射大小（1024 字节），而使用 /L 选择大分配映射大小（4096 字节）。
通常这不会发挥作用或以任何明显的方式显示出来......但是，一旦卷变得越来越大或使用创建许多小型随机分配的技术（例如数据库快照或 checkdb），它就会抬起它的丑陋脑袋.
为了解决这个问题，可以选择几个不同的选项：
在大多数情况下，选择使用 /L:Enable 进行格式化将是最简单、最快的选项。