SQL Server 2019、服务器 2019 的 ReFS 与 NTFS

Question

最近我们在对数据库进行快照时遇到错误（操作错误665）

该错误的解决方案之一是将底层磁盘类型更改为ReFS。然而，我找不到太多关于人们在 ReFS 上（而不是 NTFS）上运行 SQL Server 生产工作负载的信息。

据我了解，对于 SQL Server 2012 及更早版本 - 它使用文件流而不是稀疏文件来创建 CHECKDB 快照。ReFS 不支持，因此在 SQL Server 2012 上，ReFS 中的文件可能会导致检查 DB 时出错。

我真的很想知道是否有人在 ReFS 上运行他们的生产工作负载，以及是否有任何我们需要考虑的问题。

Answer 1

最近我们在对数据库进行快照时遇到错误（操作错误665）该错误的解决方案之一是将底层磁盘类型更改为ReFS。

是的，NTFS 的属性元数据空间有限。达到该限制将导致发生 665（由于文件系统限制，请求的操作无法完成）。如果您不想放弃 NTFS，那么一件事就是使用大文件记录段 (FRS) 格式化卷，这可以延长使用寿命，但最终会遇到同样的命运。这实际上不是一个“如果”问题，而是一个“何时”问题。

我真的很想知道是否有人在 ReFS 上运行他们的生产工作负载，以及是否有任何我们需要考虑的问题。

实际上有两个主要问题（在第 3 方支持之外，例如，如果您有某种类型的磁盘备份软件，它可能不知道 ReFS）。

1. ReFS 不进行就地元数据更改

这看起来没什么大不了的，但是如果元数据经常更改，那么可以说，每个元数据都将是一次写入放大，因为它需要获取元数据，进行更改，然后将其写入新地点。如果经常发生，成本可能会很高。想象一个日志文件一次扩展 64 MB，数百倍。

2. ReFS以不同的方式存储数据

ReFS 使用不同的内部机制（B+ 树）来存储数据，因此我注意到它的性能不如 NTFS（它使用虚拟集群到物理集群的映射）。这并不是说它不好，只是说它不同。在我的测试中，在相同的工作负载下，NTFS 始终能够推动更多的 IOP，从而减少总体时间。在查看驱动程序性能时，对于相同的工作负载，NTFS 使用的总体 CPU 少于 ReFS。

此外，虽然默认情况下未打开，但请确保管理员不要打开完整性流，因为这会极大地降低 SQL 的性能，而且 SQL 已经包含了自己的页面完整性检查。

3. 奖金：管理

由于 ReFS 不同，因此您无法使用典型的工具，例如 chkdsk（尽管 ReFS 并不真正需要 chkdsk）。这意味着需要了解或探索不同的实用程序和项目。如果这在环境中不常见，则管理员可能需要对管理工作的教育进行一些投资，在这种情况下，主要工具将是refsutil。

总的来说，如果你知道 ReFS 会给驱动程序的 cpu 带来稍高的负担，并且你不会获得任何性能，但在很多情况下实际上会损失一点（但不是全部），那么我对使用 ReFS 没有任何问题！）。

最后一项，ReFS 中的分配单元大小只有两个选项：4k 和 64k，应根据您的磁盘设备进行检查，看看哪一个最适合使用。