例如.
这会影响数据库的恢复吗?
我们还需要做些什么才能利用这个优势吗?
我计划执行这些命令:
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)
原文地址:https://www.jb51.cc/mssql/80105.html
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。