Server 2008 R2中的隔离级别

Question

我已经浏览了整个微软站点，以了解Server 2008 R2中的隔离级别。然而，在通过一项建议之前，我想听取专家们的建议。

我有一个基于PHP的网页，主要用作仪表板。用户(不超过5)每天将上传大量数据(约40,000行)，大约70名用户将只能随时访问数据库。请注意，我有固定的时间表这5个用户上传，但我想错误的证明同样的任何数据丢失。请帮助我回答以下问题：

• 我能使用的最好的隔离级别是什么？
• 默认的READ提交隔离会在这里帮助我吗？
• 另外，是否有一种方法可以通过SSMS为特定数据库设置隔离级别，而不是TSQL语句？(数据库的通用隔离)

70个用户将拥有下载选项，如果所有或大多数用户同时尝试下载，数据库是否会被破坏？我怎样才能避免同样的情况？

任何专家的建议..。

你好，Yuvraj S

Answer 1

隔离级别实际上是关于正在读取的数据上的共享锁保持多长时间。但正如Lieven已经提到的:这些都是，而不是，是关于防止数据库中的“腐败”--它们是关于防止读者和作者相互妨碍的。

首先，任何写操作(INSERT、UPDATE)都将总是需要该行上的独占锁，而排他锁与其他任何内容都不兼容--因此，如果要更新的给定行已经锁定，则任何UPDATE操作都必须等待--这是无法避免的。

对于读取数据，Server取出共享锁-并且隔离级别大约保持这些锁的时间。

默认隔离级别(READ COMMITTED)意味着: Server将尝试获取行上的共享锁，如果成功，则立即读取行的内容并再次释放该锁。因此，锁只存在于正在读取的行的短时间内。共享锁与其他共享锁兼容，因此任意数量的读取器都可以同时读取相同的行。然而，共享锁阻止独占锁，因此共享锁主要防止同一行上的UPDATE。

还有READ UNCOMMITTED隔离级别--基本上不取出锁；这意味着它还可以读取当前正在更新和独占锁定的行--因此您可能会得到未提交的数据--最终可能甚至不会真正进入数据库中的数据(如果更新的事务被回滚)--小心处理这个数据！

下一个级别是REPEATABLE READ，在这种情况下，一旦获得共享锁，将一直保持到当前事务结束为止。这会锁定更多的行，并且在更长的一段时间内，读取是可重复的，因为您已经读取的行是针对“幕后”更新而锁定的。

最终级别是SERIALIZABLE，其中整个行范围(由SELECT中的WHERE子句定义)被锁定，直到当前事务结束。

更新：

除了下载部分(对我来说是次要的)，我还担心有5个用户试图同时更新一个数据库。

好吧，别担心-- Server绝对会来处理这个问题，不会有任何麻烦！

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

如果其中一些用户试图更新同一行--它们将被序列化。第一个将能够获取行上的独占锁，执行其更新，释放锁，然后继续。现在，第二个用户将获得它的机会-获得独占锁，更新数据，释放锁，继续。

当然:如果不对它做任何事情，，那么第二个用户的数据就会简单地覆盖第一个更新。这就是为什么需要进行并发检查。您应该检查数据在读取数据的时间和写入数据的时间之间是否发生了变化；如果数据发生了更改，就意味着其他人已经在->中更新了数据，同时您需要为这种情况考虑并发冲突解决策略(但这本身就是另一个问题.)