《数据库原理及应用-(SQLServer2008版)》唐国良蔡中民-.pptVIP

ROLLBACK TRANSACTION; END CATCH; END; -- End WHILE loop. GO （3）会话2代码输入在第3个【查询】窗口 USE tempdb; GO -- Declare and set variable -- to track number of retries -- to try before exiting. DECLARE @retry INT; SET @retry = 5; --Keep trying to update -- table if this task is -- selected as the deadlock -- victim. WHILE(@retry 0) BEGIN BEGIN TRY BEGIN TRANSACTION; UPDATE my_sales SET sales = sales + 1 WHERE itemid = 2; WAITFOR DELAY 00:00:07; UPDATE my_sales SET sales = sales + 1 图12-18 死锁图 接下来我们更详细的看图里面的数据说明。 先看右边作为优胜者的这椭圆形，可以看到内容的有： 服务器进程 ID： 服务器进程标识符(SPID)，即服务器给拥有锁的进程分配的标识符。 服务器批 ID： 服务器批标识符(SBID)。 执行上下文 ID： 执行上下文标识符(ECID)。与指定SPID相关联的给定线程的执行上下文ID。ECID = {0,1,2,3, ...n}，其中0始终表示主线程或父线程，并且{1,2,3, ...n}表示子线程。 死锁优先级： 进程的死锁优先级，请参阅SET DEADLOCK_PRIORITY(Transact-SQL)。 已用日志： 进程所使用的日志空间量。 所有者 ID： 正在使用事务并且当前正在等待锁的进程的事务 ID。 事务描述符： 指向描述事务状态的事务描述符的指针。 下面来看左边作为牺牲品的这椭圆形处理节点，它告诉我们以下信息： 1.它是一个失败的事务。（蓝色的叉号表示） 2.它是作为牺牲品的T-SQL代码。 3.它对右下方的资源节点占有一个排它锁(X). 4.它对右上方的资源节点请求一个排它锁（X）. 再来看中间两个矩形的资源节点,两个处理节点对它们都有使用权，来执行它们各自的代码，同时又有对对方独占资源的请求，从而发生了资源的竞争，造成了死锁的发生。 下面我们根据SQL Server Profiler监视到的数据来具体分析死锁发生全过程。 （10）如图12-19所示，跟踪结果的第10行，SQL:BatchStarting，SPID 56，表示会话1的事务启动，对1:109:1即id=2的行获得一个排它锁，独占至少50秒，(因为在这个实例中设置了Waitfor Delay 00:00:050)。 图12-19 SQL Server Profiler 跟踪窗口 （11）如图12-20，在第11行SQL:BatchStarting，进程SPID 51 （会话2）启动，对“1:109:0”即id=1的行获得一个排它锁，独占至少5秒，(因为在这个实例中设置了Waitfor Delay 00:00:005) 图12-20 SQL Server Profiler 跟踪窗口 （12）两个进程都各自获得一个排它锁(X),约5秒过去，SPID 51（会话2）先对表的ID =2的行请求排它锁(X),但ID=2行当前已经给SPID 56（会话1）获得，还在独占，没有解锁。SPID 51（会话2）要等待。 再过约若干秒后，SPID 56 （会话1）,开始对ID =1的行请求一个排它锁(X),但ID =1的行当前已经给SPID 51 （会话2），还在独占。SPID 56（会话1）要等待。 这里就出现了进程阻塞，从而发生死锁，如图12-21所示。 图12-21 SQL Server Profiler 跟踪窗口 再继续执行，SPID 56 （会话1）先锁定ID =2行的资源且时间太长，SPID 51 （会话2）因请求不到ID =2行的资源而先被SQL Server引擎按先来先服务优先级原则结束执行，被回滚(Rollback)并释放ID =1行的资源，SPID 56 （会话1）此后可以申请到欲独占的资源（ID =1）行而执行成功。 进程51（会话2）申请独占id=2（Deadlock Chain SPID = 51，1:109:1）的行，进程56（会话1）申请独占id=1（Deadlock Chain SPID