标签: read-committed-snapshot

在MS SQL Server中,有一种方法可以检测数据库是否通过T-SQL命令设置了隔离级别 ALTER DATABASE <database> SET READ_COMMITTED_SNAPSHOT ON;

我无法在T-SQL或Management Studio的GUI中找到一种简单的方法来检测它.

TIA

我使用的是隔离级别的Microsoft SQL Server 2005数据库READ_COMMITTED和READ_COMMITTED_SNAPSHOT=ON.

现在我想用:

SELECT * FROM <tablename> FOR UPDATE

...以便在尝试访问同一行"FOR UPDATE"时阻止其他数据库连接.

我试过了:

SELECT * FROM <tablename> WITH (updlock) WHERE id=1

...但是即使选择"1"以外的ID,这也会阻止所有其他连接.

SELECT FOR UPDATE对于Oracle,DB2,MySql而言,这是正确的提示吗？

编辑2009-10-03:

这些是创建表和索引的语句:

CREATE TABLE example ( Id BIGINT NOT NULL, TransactionId BIGINT, 
    Terminal BIGINT, Status SMALLINT );
ALTER TABLE example ADD CONSTRAINT index108 PRIMARY KEY ( Id )
CREATE INDEX I108_FkTerminal ON example ( Terminal )
CREATE INDEX I108_Key ON example ( TransactionId )

很多并行进程都这样做SELECT:

SELECT * …

运行需要多长时间

ALTER DATABASE [MySite] SET READ_COMMITTED_SNAPSHOT ON

我跑了它,花了10分钟.

如何检查是否已应用？

有人可以帮我理解何时在SQL Server中使用SNAPSHOT隔离级别而不是READ COMMITTED SNAPSHOT？

据我所知,在大多数情况下,READ COMMITTED SNAPSHOT可以正常工作,但不确定何时进行SNAPSHOT隔离.

谢谢

简单的问题？

为什么READ_COMMITTED_SNAPSHOT默认情况下不启用？

我猜是向后兼容性,性能还是两者兼而有之？

[编辑]请注意,我对与READ_COMMITTED隔离级别有关的效果感兴趣,而不是快照隔离级别.

为什么这会是一个突破性的变化,因为它拥有较少的锁,并且仍然不会读取非提交的行？

我需要以编程方式在SQL Server中启用READ COMMITTED SNAPSHOT.我怎样才能做到这一点？

说,我有一个人桌,它只有一排 -

id = 1, name = 'foo'

在一个连接上

select p1.id, p1.name, p2.name
from person p1 
join person p2 on p1.id = p2.id

在另一个连接上同时:

update person set name = 'bar' where person.id = 1

Q1:是否有可能,因为我的select会根据更新语句的时间返回这样的结果:

id = 1, p1.name = 'foo', p2.name = 'bar'

这两个连接都不使用显式事务,并且都使用默认事务隔离级别READ COMMITTED.

问题实际上是帮助我理解,在语句完成之前,在sql语句开头获取的锁是否继续存在,或者语句是否有可能释放锁并重新获取锁的锁如果在同一语句中使用两次行？

Q2:如果set read_committed_snapshot on在数据库上设置问题,问题的答案是否会改变？

In Microsoft SQL Server, I use the READ_COMMITTED_SNAPSHOT ISOLATION

ALTER DATABASE MyDatabase
SET ALLOW_SNAPSHOT_ISOLATION ON

ALTER DATABASE MyDatabase
SET READ_COMMITTED_SNAPSHOT ON

In Session 1,update the Principal from 4000 to 5000

BEGIN TRAN
Update MyTable Set Principal=5000 Where InvestorId=10 

Now in Session 2, I say

Select Principal from MyTable where InvestorId=10

I get 4000, since the Session 1 Transaction is not committed.

If I do not use the READ_COMMITTED_SNAPSHOT isolation mode, and use

1. READ COMMITTED ISOLATION Mode then my Session 2 …

最近我不得不解决锁定问题,比如事务已经锁定资源与另一个进程死锁,并被选为死锁受害者.重新运行该交易.

在阅读了几篇文章并分析了我的系统背景后,我最终接受了最常用的解决方案: ALTER DATABASE MyDb SET READ_COMMITTED_SNAPSHOT ON; ALTER DATABASE MyDb SET ALLOW_SNAPSHOT_ISOLATION ON;

我想要ALLOW_SNAPSHOT_ISOLATION,因为这种隔离在我的系统上是有意义的.

我成功实现了https://www.databasejournal.com/features/mssql/article.php/3566746/Controlling-Transactions-and-Locks-Part-5-SQL-2005 "允许快照隔离"一节中描述的流程-Snapshots.htm在SQL Server Management Studio中的两个会话上.

伪代码:

SET TRANSACTION ISOLATION LEVEL SNAPSHOT
BEGIN TRAN 1
select value from MyTable where ID=1 --reads original value 

  --On another session:
  BEGIN TRAN 2
  update mytable set value=2 where ID=1
  COMMIT TRAN2

-- back to session 1
select value from MyTable where ID=1 --still reads original value 

上面的示例按预期工作.这告诉我数据库配置正确.

我的问题在于C#代码.虽然我能够防止锁定情况(READ_COMMITTED_SNAPSHOT正在工作),但我无法在我的c#代码上复制"允许快照隔离"行为.我尝试使用TransactionScope而没有它.我的目标是让它与TransactionScope …

我想在我的SQL Azure数据库上将READ_COMMITTED_SNAPSHOT设置为ON,但Azure中不支持以下与其他版本的SQL Server一起使用的代码:

ALTER DATABASE [database_name]
SET READ_COMMITTED_SNAPSHOT ON
GO

第一个问题:在SQL Azure中将READ_COMMITTED_SNAPSHOT设置为ON仍然是一个好主意(或者是什么实现相同的结果)？我的目的不是在刚刚阅读时锁定记录,以提高性能.

第二个问题:如果这是一个好主意,那么Azure的语法是什么？

我知道快照隔离可以解决这个问题,但我想知道在这种特殊情况下NOLOCK是否安全,这样我就可以避免开销.

我有一个看起来像这样的表:

drop table Data

create table Data
(
    Id BIGINT NOT NULL,
    Date BIGINT NOT NULL,
    Value BIGINT,
    constraint Cx primary key (Date, Id)
)

create nonclustered index Ix on Data (Id, Date)

表格没有任何更新.删除可能会发生,但它们永远不应该与SELECT竞争,因为它们会影响表的另一个较旧的末尾.插入是常规的,并且(Id,Date)索引的页面拆分非常常见.

我有一个标准INSERT和SELECT之间的死锁情况,如下所示:

select top 1 Date, Value from Data where Id = @p0 order by Date desc

因为INSERT获取关于CX(日期,标识;值)一个锁,然后IX(ID,日期),但SELECT获取关于IX(ID,日期),然后CX(日期,标识;值)的锁.这是因为SELECT首先寻找Ix然后加入到Cx上的搜索.

交换聚集和非聚集索引会打破这个循环中,但它不是可接受的解决方案,因为它会与其他(更复杂)选择引入周期.

如果我将NOLOCK添加到SELECT中,在这种情况下是否会出错？它可以返回:

1. 不止一排,即使我要求TOP 1？
2. 没有行,即使存在并且已经提交了？
3. 最糟糕的是,一行不满足WHERE子句？

我已经在网上做了很多关于这个的阅读,但是我看到的(一个,两个)过度或不足的异常的唯一复制涉及扫描.这只涉及寻求.杰夫阿特伍德有一篇关于使用NOLOCK 的帖子,引起了很好的讨论.我对Rick Townsend的评论特别感兴趣:

其次,如果您读取脏数据,那么您运行的风险就是读取完全错误的行.例如,如果您的select读取索引以查找您的行,那么更新会更改行的位置(例如:由于页面拆分或对聚簇索引的更新),当您选择读取实际数据行时,它要么不再存在,要么完全不同!

这是否可以仅使用插入,并且没有更新？如果是这样,那么我想即使我在一个只插入表上的搜索也可能是危险的.

更新:

我试图找出快照隔离的工作原理.它似乎是基于行的,其中事务读取表(没有共享锁!),找到他们感兴趣的行,然后看看他们是否需要从tempdb中的版本存储中获取旧版本的行.

但在我的情况下,没有行会有多个版本,所以版本存储似乎没有意义.如果找到没有共享锁的行,那么仅使用NOLOCK会有什么不同？

当我阅读快照技术时……我发现写时复制（COW）和写时重定向（ROW）对于理解他们承诺的实际操作非常令人困惑……有人请解释我如何他们实际上正在工作......

谢谢