如果我们在sql-server中启用read committed snapshot会有什么风险？

我已经阅读了 here,每行将存储一些额外的数据,因此我们可能会看到性能下降但其他风险是什么？

例如.
这会影响数据库的恢复吗？
我们还需要做些什么才能利用这个优势吗？

我计划执行这些命令：

ALTER DATABASE DatabaseName SET READ_COMMITTED_SNAPSHOT ON
ALTER DATABASE DatabaseName SET ALLOW_SNAPSHOT_ISOLATION ON

我相信这会给我们更接近oracle的东西,如果一个事务正在更新,其他事务仍然可以读取旧数据.它是否正确？

我正在调查这个因为我厌倦了sql Server 2005中的锁定问题.我希望这可以减少我们的用户偶尔看到的死锁,帮助我们的应用程序的整体性能,并鼓励我们的开发人员每个事务执行多个操作恐惧.

解决方法

摘要

>如果您遇到锁定问题,那么您的代码就会出现问题：它不是数据库引擎
>这不是一个神奇的子弹
>您可能会添加更多问题

加载

它还会增加tempdb和CPU的负载.另见：

> “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)