sql-server - 如何正确实现快照隔离和tempdb问题？

Question

快照隔离功能帮助我们解决了高容量站点上读者锁定作者的问题。它通过在 SqlServer 中使用 tempdb 对行进行版本控制来实现这一点。

我的问题是如何正确实现此快照隔离功能，是否只需在我的 SqlServer 上执行以下操作即可

ALTER DATABASE MyDatabase
SET ALLOW_SNAPSHOT_ISOLATION ON

ALTER DATABASE MyDatabase
SET READ_COMMITTED_SNAPSHOT ON

我是否还必须编写包含 TransactionScope 的代码，例如

using (new TransactionScope(TransactionScopeOption.Required, 
    new TransactionOptions { IsolationLevel = IsolationLevel.SnapShot}))

最后，布伦特在 this post 中指出了他的担忧在“并发的隐藏成本”部分中，他提到当您对 tempdb 中的行进行版本控制时，tempdb 可能会耗尽空间，并且可能会出现性能问题，因为它必须查找版本控制的行。所以我的问题是我知道这个网站使用快照隔离，其他人在大型网站上使用此功能，您对性能有何看法？

谢谢，雷。

Answer 1

这“只是执行以下操作的问题”，如 https://msdn.microsoft.com/en-us/library/tcbchxcb(v=vs.110).aspx 中所述。 ，“如果 READ_COMMITTED_SNAPSHOT 选项设置为 OFF，则必须显式设置每个 session 的快照隔离级别才能访问版本控制的行。”您的第二个 ALTER DATABASE 命令将 READ_COMMITTED_SNAPSHOT 设置为 ON，因此代码不需要指定该 TransactionScope。

每当人们寻求关于性能“足够”与“不足”的意见时，性能硬币有两个方面:要么“供应”平淡，要么“需求”压倒性......对于这篇文章，“供应” “”可以指 tempdb 使用的性能和空间，而“需求”可能涉及对 tempdb 进行写入的速率。在供应方面，可以使用各种硬件(从单轴 5400 RPM 磁盘到 SSD 阵列)。在需求方面，这不是 SQL Server 问题(尽管未能正确规范化数据库设计可能是一个因素)，而是客户端代码问题。

My SQL Server 看到客户端同时要求大约 50 次写入/分钟和 2000 批/分钟，其中写入通常在 OTLP/短边。我的每个 SQL Server 有 1 TB 的数据库和 30 GB 的 tempdb。所有数据库通常都标准化为第三范式。所有数据库都在 SSD 上运行。我不担心 tempdb 磁盘的 IO 吞吐量会被超出。因此，我并不担心在我的系统上启用快照隔离。但是，我见过其他系统尝试启用快照隔离，但很快就放弃了。

您的系统的体验可能与任何其他受访者的系统存在几个数量级的差异。您应该寻求分析/可靠地重放系统的写入，以及重放 tempdb 的其他使用(包括排序)，以便为您自己的系统得出您自己的结论(对于具有足够空间用于系统结果的各种硬件)临时数据库大小)。负载测试不应该是事后的想法:)。您还应该对 tempdb 磁盘的 IO 吞吐量进行基准测试 - 请参阅 https://technet.microsoft.com/library/Cc966412 ，如果IO吞吐能力不够，就要做好花更多钱的准备。