0
Kalen最近参加了24 hours of PASS,主题是《Locking, Blocking, Versions: Concurrency for Maximum Performance》。但实际上只讲了locking的一些基本概念,还有很多没有讲到。不过作为回顾,也是不错的。
- 在SQL SERVER,最基本的两种lock是shared lock(S)和exclusive lock(X)
- UPDATE lock是一个混合模式,出现在UPDATE/DELETE的查询过程中,可以和shared lock兼容,但是与其他U和X锁不兼容。
- 对数据进行修改的时候,U锁会升级成为X锁
- 一般情况下,我们讨论的lock是TRANSACTION lock,但除此之外,还有SHARED_TRANSACTION_WORKSPACE (Resource = DATABASE)、EXCLUSIVE_TRANSACTION_WORKSPACE (Resource = DATABASE)、游标锁、Session Locks (Resource = DATABASE)。
- 对于lock的粒度,可以是ROW(RID or KEY)、PAGE、TABLE、PARTITION、EXTENT、DATABASE
- SQL SERVER会在多层上放置lock。比如,修改一条记录,会在TABLE 和 PAGE上方式IX锁,在ROW上放置X锁
- sys.dm_tran_locks可以用来查看当前的所有lock
- ROW锁会升级为更高级别的锁。遇到过一个案例就是锁升级为page锁,进而导致deadlock。
0
Posted on
Tuesday, September 13, 2016
by
醉·醉·鱼
and labeled under
sql
拜读完 https://www.simple-talk.com/sql/t-sql-programming/row-versioning-concurrency-in-sql-server/,快快记录一些东西,方便以后回忆。
- READ_COMMITTED_SNAPSHOT 和 SNAPSHOT都是基于snapshot的隔离级别
- 两种机制都会复制数据一个version到tempdb
- 在物理存储上,每条数据都会增加长度为14bytes的pointer和XSN
- pointer会指向之前的version,之前的version又会指向更早的version,直到最早的version。有点想HEAP里出现page split一样。
- SNAPSHOT机制减少了lock,增加了tempdb开销,间接增加UPDATE和DELETE的代价
- READ_COMMITTED_SNAPSHOT 可以避免脏读。是statement level的snapshot isolation。第二次读是可以读到另外TRAN里提交的改动。
- SNAPSHOT 可以避免脏读,不可重复读和幻读。是transaction level的snapshot isolation。第二次读到的和第一次读到的一致。
- 由于基于version,reader和writer互不block,但是writer还是会block writer。
- 正是由于SNAPSHOT可以重复读,会导致UPDATE CONFLICT。即UPDATE的时候其他session已经提交了改动,这个时候就会UPDATE CONFLICT。
- 开启READ_COMMITTED_SNAPSHOT需要关闭所有ACTIVE SESSION。
- 开启READ_COMMITTED_SNAPSHOT需要将代码里面的NOLOCK抹掉,并默认为READ COMMITTED隔离级别。
0
创建下面的文件
测试
结果是,部分提交,和你在SSMS里面一样,即使你加了-b option。
Posted on
Tuesday, September 13, 2016
by
醉·醉·鱼
and labeled under
sql
项目是用SQLCMD加载文件进行schema部署的,如果部署中间出问题了,会是部分提交,还是全部回滚呢?创建下面的文件
PRINT 'YES'
GO
update test
set someValue = 987
where id = 1
GO
THROW 51000, 'The record does not exist.', 1;
GO
PRINT 'YES AGAIN'
GO
测试
sqlcmd -S .\MSSQLSERVER2012 -d event_service -i ./sqlcmd_test.sql -m-1 -r -I -b
结果是,部分提交,和你在SSMS里面一样,即使你加了-b option。