应用程序可以安全地使用 READ_COMMITTED_SNAPSHOT 吗？
我有一个大型 Web 应用程序，使用针对 SQL Server 2005 数据库的 COM 数据访问层。默认情况下，隔离级别为 READ_COMMITTED。现在我明白了 READ_COMMITTED_SNAPSHOT 隔离级别是如何工作的，并且阅读 MSDN 它说你可以透明地打开它。然而，我仍然持怀疑态度。 :) 如果我从 READ_COMMITTED 更改为 READ_COMMITTED_SNAPSHOT，是否以实现方式保证我的应用程序不会中断（不要假设应用程序按照书本执行所有操作）？不会向COM层抛出额外的异常吗？事务语义是一样的吗？
附言。通过实现方式，我的意思是，READ_COMMITTED_SNAPSHOT 隔离级别是故意实现为完全作为READ_COMMITTED，只是使用行版本控制而不是锁？
感谢您提供任何见解或您自己切换到这种隔离模式的经历。
I have a large web application using a COM data access layer against an SQL Server 2005 database. By default, the isolation level is READ_COMMITTED. Now I understand how READ_COMMITTED_SNAPSHOT isolation level works, and reading MSDN it says you can turn it on transparently. However, I'm still sceptical. :) Is it guaranteed, in an implementational manner, that my application will not break (do not assume the application does everything by the book) if I change from READ_COMMITTED to READ_COMMITTED_SNAPSHOT? No additional exceptions will be thrown to the COM layer? Transaction semantics are the same?
PS. By an implementational manner, I mean something along the lines that the READ_COMMITTED_SNAPSHOT isolation level was implemented intentionaly to work exactly as READ_COMMITTED, just using row versioning instead of locks?
Thank you for any insights or your own experiences switching to this isolation mode.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不，它们没有相同的行为：READ_COMMITTED 通过锁定保证没有脏读，READ_COMMITTED_SNAPSHOT 通过拍摄表的快照来实现这一点。
使用 READ_COMMITTED_SNAPSHOT，您的事务可以读取已被与您的事务并行运行的另一个会话更改的旧数据。
虽然大多数情况下这不会破坏应用程序逻辑，但不能保证您的特定应用程序不依赖于锁定行为。
安全更改隔离级别的唯一方法是审核所有数据库代码并检查是否存在问题。
No, they do not have the same behaviour: READ_COMMITTED guarantees there are no dirty reads by locking, READ_COMMITTED_SNAPSHOT does so by taking a snapshot of the tables.
With READ_COMMITTED_SNAPSHOT your transactions could read old data which has been changed by another session running in parallel with your transaction.
While is most cases this won't break application logic, it's not guaranteed that your particular application does not relies on the locking behaviour.
The only way to safely change the isolation level is to audit all database code and check if there could be issues.