像前面的例子那样,阻塞事务的语句是必须的:
这个语句代表在查询中等待 10秒,这样我们才能模拟并发的情况,如果事务很快执行完毕了,就无法重现并发的情况。
我在网上看到有些例子是使用 C#、Java 等语言启动多个线程去模拟并发,而不是使用阻塞,虽然这样更接近生产环境,但并不利于简化问题。多个线程模拟并发,取决于线程数和事务执行的速度,难以确认并发发生了,而且编码量稍多。
这大概是防止在数据库有活动会话时,对数据库进行一些影响数据一致性的更改的。
在 id 54 的会话中&#
--延长处理时间
waitfor delay '0:00:10'
这个语句代表在查询中等待 10秒,这样我们才能模拟并发的情况,如果事务很快执行完毕了,就无法重现并发的情况。
我在网上看到有些例子是使用 C#、Java 等语言启动多个线程去模拟并发,而不是使用阻塞,虽然这样更接近生产环境,但并不利于简化问题。多个线程模拟并发,取决于线程数和事务执行的速度,难以确认并发发生了,而且编码量稍多。
然后是使用 sys.dm_tran_locks 视图去查看锁:
--查看 id 54 的会话持有的锁
select * from sys.dm_tran_locks where request_session_id = 54
如果在指定的会话是活动的,没有任何正在执行的事务,可以看一个数据库的共享锁:
这大概是防止在数据库有活动会话时,对数据库进行一些影响数据一致性的更改的。
在 id 54 的会话中&#