隔离级别和 DIRT READ SQL SERVER 2005(高级问题)

发布于 2024-08-29 09:38:12 字数 271 浏览 1 评论 0原文

我将描述我的问题以获得更简单的解释:

我有一个表,我的软件正在使用事务访问它(更新、插入)。

问题是我想在此表中启用 DIRT READ。但我不能在我的 sql 语句中使用 with (nolock),因为我无法更改软源。所以我正在考虑在开始事务的sql进程中启用脏读。

可以看到命令“SET ISOLATION LEVEL ...”和“WITH (NOLOCK)”在访问锁定表的语句中执行...这就是我试图避免的。我想在开始交易的语句中启用脏读...

提前致谢!

I will describe my problem for an easier explanation:

I have a table and my soft is accessing it (update, insert) using transaction.

The problem is that I want to enable DIRT READ in this table. But I cant use with (nolock) in my sql statements because I cant change the soft source. So I was thinking in enable dirty read in the sql process that begin the transaction.

It seens that the command "SET ISOLATION LEVEL ..." and "WITH (NOLOCK)" are executed in the statements that do access the locked table... that's what I'm try to avoid. I want to enable dirt read in the statement that begin the transaction...

thanks in advance!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

追星践月 2024-09-05 09:38:12
  1. 更改写入的隔离级别(例如插入或更新)是没有意义的。写操作总是对其更新的任何内容采取独占锁定。您可以做的是更改读取(即 SELECT 语句)的隔离级别。
  2. 脏读永远是不必要的。 99% 的情况下,它们表明架构和查询设计不佳,导致端到端扫描肯定会阻塞锁定的行。解决方案是正确更改架构,添加必要的索引以避免扫描。这不需要更改源。
  3. 对于争用确实不可避免且架构设计正确的极少数情况,答案永远不是启用脏读,而是转向 快照隔离

    更改数据库...设置 ALLOW_SNAPSHOT_ISOLATION ON;
    ALTER DATABASE ... SET READ_COMMITTED_SNAPSHOT ON;

对于少数由快照隔离引入的行版本控制开销可见的部署,他们有专业人员来缓解该问题。

  1. There is no point in changing the isolation level of your writes, like insert or update. Writes always take exclusive locks on anything they update, period. What you can do is to change the isolation level of your reads, your SELECT statements.
  2. Dirty reads are never necessary. 99% of the times they are the indication of bad schema and query design that results in end-to-end scans that are guaranteed to block on locked rows. The solution is to properly change the schema, add necessary indexes to avoid scans. This does not require source changes.
  3. For the rare cases when contention is indeed unavoidable and the schema is correctly designed, the answer is never to enable dirty reads, but to turn to snapshot isolation:

    ALTER DATABASE ... SET ALLOW_SNAPSHOT_ISOLATION ON;
    ALTER DATABASE ... SET READ_COMMITTED_SNAPSHOT ON;

For the few deployments where the overhead of row-versioning introduced by snapshot isolation is visible, they have professionals at their disposal to alleviate the problem.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文