Snapshot Isolation 功能帮助我们解决读者在高容量站点上锁定作者的问题。它通过在 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}))
最后，Brent 在 this post 的 The Hidden Costs of Concurrency 一节中指出了他的担忧，他提到当您在 tempdb 中对行进行版本控制时，tempdb 可能会耗尽空间，并且可能会出现性能问题，因为它必须查找版本控制的行。所以我的问题是我知道这个网站使用快照隔离，其他人在大型网站上使用这个功能，你对性能有什么看法？
谢谢，
射线。
最佳答案
正如 https://msdn.microsoft.com/en-us/library/tcbchxcb(v=vs.110).aspx 中所述，这只是“执行以下操作的问题”，“如果 READ_COMMITTED_SNAPSHOT 选项设置为 OFF，则必须为每个 session 显式设置 Snapshot 隔离级别，以便访问版本化行。”您的第二个 ALTER DATABASE 命令将 READ_COMMITTED_SNAPSHOT 设置为 ON，因此代码不需要指定该 TransactionScope。
性能硬币有两个方面，每当有人寻求关于性能“足够”与“不足”的意见时:要么“供应”不足，要么“需求”不堪重负......对于这篇文章，“供应”可以指与 tempdb 使用的性能和空间有关，而“需求”可能与写入 tempdb 的速率有关。在供应方面，可以使用各种硬件(从单轴 5400 RPM 磁盘到 SSD 阵列)。在需求方面，这不是 SQL Server 问题(尽管未能正确规范化数据库设计可能是一个因素)，而是客户端代码问题。
我的 SQL Server 看到客户端并发要求大约 50 次写入/分钟和 2000 个批次/分钟，其中写入通常在 OTLP/短边上。我有 1 TB 的数据库和 30 GB 的 tempdb，每个 SQL Server。所有数据库通常都标准化为第三范式。所有数据库都在 SSD 上运行。我不担心超出 tempdb 磁盘的 IO 吞吐量容量。因此，我对在我的系统上启用快照隔离没有任何顾虑。但是，我看到其他系统尝试启用快照隔离，但很快就放弃了。
您的系统的体验可能与任何其他受访者的系统相差几个数量级。您应该寻求分析/可靠地重放系统的写入，以及重放 tempdb 的其他用途(包括排序)，以便为您自己的系统得出您自己的结论(对于各种硬件，并为您的系统结果提供足够的空间) tempdb 大小)。负载测试不应该是事后的想法:)。您还应该对 tempdb 磁盘的 IO 吞吐量容量进行基准测试 - 请参阅 https://technet.microsoft.com/library/Cc966412 ，如果其 IO 吞吐量容量最终不足，请准备好花更多的钱。
关于sql-server - 如何正确实现快照隔离和 tempdb 问题？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/652378/