标签: isolation-level

因为我正在处理将 SQL SERVER 作为数据库的项目......我在我的项目中维护隔离级别，我为我的项目启用了快照隔离级别......

由于我必须进行一些脏读，我正在使用设置查询它。我已经SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED.在存储过程中实现了它......这是我存储过程的简短版本

ALTER PROCEDURE [dbo].[proc_ReadDirtyData]
@id INT,
@mode VARCHAR(5)

AS
BEGIN
    --Read Dirty Data
    IF (@mode = 'RDD')
    BEGIN
            SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
            SELECT * FROM tbl_transaction
            WHERE id = @id;--@id foreign key in tbl_transaction.
                           --This read has been done during the transaction from C# Apps
    END
END

在我的 C# 应用程序中，保持以下结构

snapshot transaction start

stage1 : tblmaster --generates id
stage2 :tblchild --inserts the data with above id as …

RCSI（读提交快照隔离）是更改 SQL Server 中（默认）读提交隔离级别行为的数据库设置。

据我了解，这是 MSDN 博客文章“并发系列：最小化更新程序之间的阻塞”中的 sripts 的上下文，它告诉我们：

• “使用 RCSI 的第二个技巧也不起作用，并且更新被行上的 session-1 阻塞在 X 锁后面，（C1 = 1）。原因是以下 UPDATE 语句在比读取提交更高的隔离级别执行。

  update basic_locking set c2 = 1000 where c1 = 2

  这是显示阻塞的输出

  

  解决方案：这里有两个选择来解决这个问题：”

“输出”如何说明隐式默认隔离级别（已提交读）的隐式提升？

如何在某些语句的上下文中检查真正的隔离级别“跳跃”？

什么时候期待它们，它们为什么会发生？

1. SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED 位于“BEGIN”的不同部分。以下两个查询的行为是否相同？

2. 视图 viewOne 和 viewTwo 会继承脏读吗？或者视图需要有一个明确的“NOLOCK”

查询 1

set transaction isolation level read uncommitted
begin    
    select col1 from viewOne
    select * from viewTwo
    select * from table1
end

查询 2

begin    
    set transaction isolation level read uncommitted
    select col1 from viewOne
    select * from viewTwo
    select * from table1     
end

据我了解，使用 Read Committed Snapshot，读者不会阻止作者，而作者不会阻止读者。唯一可能发生的阻塞是编写器阻塞编写器。默认情况下，我们的数据库设置为 Read Committed Snapshot。但是，我们有很多用户使用 WITH (NOLOCK) 发出查询（出于不良习惯）。如果我理解正确，使用 WITH (NOLOCK) 的查询会更改隔离级别。当在查询中使用它时，读取器现在是否可以阻止尝试更新正在读取的数据的进程？

乐观读和乐观写有什么区别？

或者可能更重要的是，有人可以定义这 4 个吗？

(a) 乐观阅读

(b) 悲观解读

(c) 乐观写作

(d) 悲观写作

参考这里的问答：https : //stackoverflow.com/questions/2741016/read-committed-snapshot-vs-snapshot-isolation-level

'READ COMMITTED SNAPSHOT 执行乐观读取和悲观写入。相比之下，SNAPSHOT 执行乐观读取和乐观写入。

这是指这个问题：Duplicate records returned from table with no duplicates

“读提交”隔离级别假定一个事务可以以不同的方式读取同一条记录，但并不明确暗示记录可以重复。我同意同一事务中的两个语句可以返回不同的数据集，但返回带有重复记录的相同数据集听起来很疯狂。

据我所知，只有 MS SQL Server 有这种行为。

如果它符合ANSI SQL 标准定义的“Read Committed”隔离级别，请证明或反驳。

我想在 Oracle 11g 中运行这个 SQL：

declare a number;
  begin 
  select count(*) into a  from item w where w.Item_num='MOH601' ; 
  dbms_output.put_line(a);
  end ; 

如何使用隔离可序列化运行此查询？正如我之前所了解的，Oracle 会w.Item_num='MOH601'在使用 Serializable 时锁定行。

我有一个特殊的情况让我使用SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED. （我sp_getapplock用来确保单个进程访问给定的行。）

我正在尽力避免任何类型的锁定升级。我清楚地知道ISOLATION LEVEL READ UNCOMMITTED读取有什么作用，但我不确定删除。

我看到用做删除一些示例代码ROWLOCK和READPAST，连同ISOLATION LEVEL READ UNCOMMITTED但我是没有什么，会做明确的，所以我也没有一直在使用它了。

这是否需要防止我的删除锁定升级或就ISOLATION LEVEL READ UNCOMMITTED足够了？

注意：
如果有兴趣，这里和这里是这个问题的相关 sprocs。

NOLOCK 导致分配顺序扫描而不是索引顺序扫描。

NOLOCK 不会阻止写入，因为它不在表上获取共享锁。

在NOLOCK扫描期间，由于没有共享锁，并且在扫描当前到达的点之前发生了写入（插入/更新），那么这种情况将导致记录丢失。

类似地，在写入（插入/更新）期间，当读取一行后发生页拆分，并且该行现在是下一页的一部分（由于页拆分），那么这种情况将导致重复记录。

我一直在阅读文章，这些文章似乎表明丢失/重复行问题是由于分配顺序扫描造成的。

1. 如上面的示例所示，丢失/重复记录问题是由于没有锁定和页面拆分造成的。正确的？是否也是分配顺序扫描导致的？

2. 如果分配有序扫描确实会导致丢失行/重复项，那么我想问 - 假设引擎使用了索引顺序扫描（我知道引擎不会这样做，但只是为了这个问题而假设）而不是分配顺序扫描，那么它将如何解决丢失/重复行问题？

前几天我在 StackOverflow 上遇到了这个问答。引用问题作者的评论，情况似乎“有些可怕”。本次问答中也设置了类似的情况。

我的经验法则一直是 SQL 中的单个语句“原子地”执行。也就是说，在任何默认配置下，成功执行的单个语句（即没有死锁或中止）不存在任何潜在的并发问题。

然而我链接的两个问答表明并非如此。

说明问题的最基本场景似乎是这种自连接：

SELECT
     t1.*
    ,t2.*

FROM 
    some_table AS t1

FULL OUTER JOIN 
    some_table AS t2
    ON t2.id = t1.id

是否存在不需要t1与 完全一致的情况t2，因此此查询可能会在全连接的一侧或另一侧返回 NULL，因为 t1 的数据与 t2 的数据是在不同的时间获取的因此每个可能引用不同的数据（即使它是在单个语句中引用的同一个表）？

我的假设始终是单个语句（引用多个表，或多次引用某些表）在某个时间步骤获取它所需的所有数据，作为数据库的单个一致快照。如果隔离级别为READ COMMITTED，那么我假设快照是单个语句开始时所有已提交数据的快照。

我对 RCSI 功能的理解是，它将这种假定的快照保证扩展到多语句事务。

我很震惊（虽然并不完全惊讶）发现事实似乎并非如此，而且我多年来的基本理解似乎被颠覆了。

有关这方面的信息似乎非常少。正如2014 年这篇文章的作者所说，这种行为似乎“甚至能够误导经验丰富的数据库从业者”。

该文章表明，即使是非常常见的 SELECT 查询样式似乎也能够在执行过程中修改其基础数据，并返回违反 WHERE 子句的显式逻辑标准的结果。这种行为方式可能成为默认行为，这似乎很荒谬。

问题

Microsoft（或 SQL 标准）是否有任何信息明确指定并确认此行为？

为了保证单个语句相当于所有数据的单个一致快照，需要进行哪些设置（在会话级别或语句级别）？