如何正确实现快照隔离和tempdb问题?
快照隔离功能帮助我们解决高容量站点上读者锁定作者的问题。 它通过在 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 在 这篇文章位于“并发的隐藏成本”部分,他在其中当您对 tempdb 中的行进行版本控制时提到,tempdb 可能会耗尽空间,并且可能会出现性能问题,因为它必须查找版本控制的行。 所以我的问题是我知道这个网站使用快照隔离,其他人在大型网站上使用此功能,您对性能有何看法?
谢谢, 射线。
The Snapshot Isolation feature helps us to solve the problem where readers lock out writers on high volume sites. It does so by versioning rows using tempdb in SqlServer.
My question is to correctly implement this Snapshot Isolation feature, is it just a matter of executing the following on my SqlServer
ALTER DATABASE MyDatabase
SET ALLOW_SNAPSHOT_ISOLATION ON
ALTER DATABASE MyDatabase
SET READ_COMMITTED_SNAPSHOT ON
Do I still also have to write code that includes TransactionScope, like
using (new TransactionScope(TransactionScopeOption.Required,
new TransactionOptions { IsolationLevel = IsolationLevel.SnapShot}))
Finally, Brent pointed out his concern in this post under section The Hidden Costs of Concurrency, where he mentioned as you version rows in tempdb, tempdb may run out of space, and may have performance issues since it has to lookup versioned rows. So my question is I know this site uses Snapshot Isolation, anyone else uses this feature on large sites and what's your opinion on the performance?
Thx,
Ray.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这“只是执行以下操作的问题”,如 https://msdn.microsoft.com/en-us/library/tcbchxcb(v=vs.110).aspx, "如果 READ_COMMITTED_SNAPSHOT 选项设置为 OFF,则必须显式设置快照每个会话的隔离级别,以便访问版本化的行。” 您的第二个 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吞吐能力不够,就要做好花更多钱的准备。
It is "just a matter of executing the following", as stated in https://msdn.microsoft.com/en-us/library/tcbchxcb(v=vs.110).aspx, "If the READ_COMMITTED_SNAPSHOT option is set to OFF, you must explicitly set the Snapshot isolation level for each session in order to access versioned rows." Your second ALTER DATABASE command sets the READ_COMMITTED_SNAPSHOT ON so code does not need to specify that TransactionScope.
There are two sides to a performance coin, whenever one seeks an opinion about performance is "sufficient" versus "insufficient": Either "supply" is underwhelming or "demand" is overwhelming.... For this post, "supply" could refer to the performance and space used by tempdb, while the "demand" could concern the rate at which writes to tempdb occur. On the supply side, a variety of HW (from a single spindle 5400 RPM disk to arrays of SSDs) can be used. On the demand side, this isn't a SQL Server concern (although failing to properly normalize a database design can be a factor) as much as its a client code concern.
My SQL Servers see clients concurrently demanding approximately 50 writes/minute and 2000 batches/minute, where the writes are usually on the OTLP/short side. I have 1 TB of databases and a 30 GB tempdb, per SQL Server. All databases are in general normalized to 3rd normal form. All databases are running on SSDs. I have no concerns about the tempdb disk's IO throughput capacity being exceeded. As a result, I have had no concerns about enabling snapshot isolation on my systems. But, I have seen other systems where enabling snapshot isolation was attempted, but quickly abandoned.
Your system's experience can vary from any other respondent's system, by orders of magnitude. You should seek to profile/reliably replay your system's writes, along with replaying other uses of tempdb (including sorts), in order to come up with your own conclusions for your own system (for a variety of HW with sufficient space for your system's resulting tempdb size). Load testing should not be an afterthought :). You should also benchmark your tempdb disk's IO throughput capacity - see https://technet.microsoft.com/library/Cc966412, and be prepared to spend more money if its IO throughput capacity ends up being insufficient.