SQL Server 2008 R2中的隔离级别

Question

我已经通过整个Microsoft站点来了解SQL Server 2008 R2中的隔离级别.但在采用之前,我想听取SO专家的建议.

我有一个基于PHP的网页,主要用作仪表板.用户(不超过5个)每天将上传批量数据(大约40,000行),大约70个用户只能访问数据库.请注意,我已经为这5个用户上传了固定的时间表,但我想错误地证明任何数据丢失的证据.请帮我解决以下问题:

• 我可以使用的最佳隔离级别是多少？
• 默认的READ COMMITTED隔离是否可以帮助我？
• 还有一种方法可以通过SSMS为特定数据库设置隔离级别,而不是TSQL语句吗？(数据库的通用隔离)

70个用户将拥有下载选项,如果所有或大部分数据库同时尝试下载,是否有可能损坏数据库？我该如何避免？

专家提出的任何建议......

此致,Yuvraj S.

Answer 1

隔离级别实际上是关于保持读取数据的共享锁的时间长度.但正如列文已经提到的那样:那些不是为了防止数据库中的"腐败" - 这些都是为了防止读者和作者互相攻击.

首先:任何写操作(INSERT,UPDATE)总是需要对该行进行独占锁定,并且独占锁与其他任何东西都不兼容 - 所以如果要更新的给定行已经被锁定,任何UPDATE操作都必须等待 - 没办法围绕这个.

对于读取数据,SQL Server取出共享锁 - 隔离级别是关于持有多长时间.

在默认的隔离级别(READ COMMITTED)是指:SQL Server将尝试获取行上的共享锁,如果成功,读取行的内容,并再次释放锁的时候了.因此锁只存在于正在读取的行的短暂时间段内.共享锁与其他共享锁兼容,因此任意数量的读取器都可以同时读取相同的行.但是,共享锁会阻止独占锁,因此共享锁主要阻止UPDATE在同一行上.

然后还有READ UNCOMMITTED隔离级别 - 基本上没有锁; 这意味着,它还可以读取当前正在更新和独占锁定的行 - 因此您可能会获得未提交的数据 - 最终可能不会真正在数据库中结束的数据(如果事务更新它被回滚) - 小心这一个!

下一级是REPEATABLE READ,在这种情况下,获取的共享锁一直保持到当前事务终止.这会锁定更多的行并且持续更长的时间 - 读取是可重复的,因为您读取的那些行被锁定在"背后"的更新中.

最终级别是SERIALIZABLE行的整个范围(由您的WHERE子句定义SELECT)被锁定,直到当前事务终止.

更新:

不仅仅是下载部分(我的辅助部分),我担心有5个用户同时尝试更新一个数据库.

好吧,不要担心 - SQL Server 肯定会毫无困难地处理这个问题!

如果这5个(甚至50个)并发用户正在更新不同的行 - 他们甚至不会注意到其他人在附近.更新将会发生,在此过程中不会有任何数据受损 - 一切都很好.

如果其中一些用户尝试更新同一行 - 它们将被序列化.第一个将能够获得该行的独占锁定,进行更新,释放锁定然后继续.现在第二个用户将有机会获得它 - 获得独占锁定,更新数据,释放锁定,继续.

当然:如果你不做任何事情,第二个用户的数据将只是覆盖第一次更新.这就是需要进行并发检查的原因.您应该检查数据是否在您读取数据和写入数据之间发生了变化; 如果它被改变了,这意味着其他人已经同时更新了它 - >你需要考虑这种情况下的并发冲突解决策略(但这本身就是另一个问题......)