例如.
这会影响数据库的恢复吗？
我们还需要做些什么才能利用这个优势吗？
我计划执行这些命令：
ALTER DATABASE DatabaseName SET READ_COMMITTED_SNAPSHOT ON ALTER DATABASE DatabaseName SET ALLOW_SNAPSHOT_ISOLATION ON
我相信这会给我们更接近oracle的东西,如果一个事务正在更新,其他事务仍然可以读取旧数据.它是否正确？
我正在调查这个因为我厌倦了sql Server 2005中的锁定问题.我希望这可以减少我们的用户偶尔看到的死锁,帮助我们的应用程序的整体性能,并鼓励我们的开发人员每个事务执行多个操作恐惧.
解决方法
>如果您遇到锁定问题,那么您的代码就会出现问题：它不是数据库引擎
>这不是一个神奇的子弹
>您可能会添加更多问题
加载
> “Performance Impact: The Potential Cost of Read_Committed_Snapshot”(Linchi Shea)
安全
最重要的是,默认情况下,快照隔离在许多情况下并不安全.有关写入偏斜异常的更多信息,请阅读“Snapshot isolation” (Wikipedia).下一节是“使快照隔离可序列化”来解决这个问题.
In general,therefore,snapshot isolation puts some of the problem of maintaining non-trivial constraints onto the user,who may not appreciate either the potential pitfalls or the possible solutions. The upside to this transfer is better performance.
另见：
> “The Potential Dangers of the Read Committed Snapshot Isolation Level”(JimMcLeod,Alex Kuznetsov的评论中有争议)
> http://coderjournal.com/2008/08/deadlocked-read-committed-snapshot-explained/
> Serializable vs. Snapshot Isolation Level,the Marble problem(克雷格弗里德曼)
> http://sqlblog.com/blogs/alexander_kuznetsov/archive/2011/08/02/reads-involving-udfs-under-read-committed-snapshot-may-seem-inconsistent.aspx(Alex Kuznetsov)
