（转载）使用 TRY/CATCH 语句解决 SQL Server 2005 死锁

对于今天的 RDBMS 体系结构而言，死锁难以避免 — 在高容量的 OLTP 环境中更是极为普遍。正是由于 .NET 的公共语言运行库 (CLR) 的出现，SQL Server 2005 才得以为开发人员提供一种新的错误处理方法。在本月专栏中，Ron Talmage 为您介绍如何使用 TRY/CATCH 语句来解决一个死锁问题。



一个示例死锁


让我们从这样一个示例开始说起，它在 SQL Server 2000 和 2005 中都能引起死锁。在本文中，我使用 SQL Server 2005 的最新 CTP（社区技术预览，Community Technology Preview）版本，SQL Server 2005 Beta 2（7 月发布）也同样适用。如果您没有 Beta 2 或最新的 CTP 版本，请下载 SQL Server 2005 Express 的最新版本，用它来进行试验。

可能发生的死锁情况有很多，[参阅http://msdn.microsoft.com/library/default.asp?url=/library/en-us/acdata/ac_8_con_7a_3xrf.asp以及死锁文章树中的后续文章。— 编者 ]，但最有趣、最微妙的是那些关于阅读器和编写器互相阻塞的死锁。以下代码在 pubs 数据库中就产生了这样一个死锁。（您可以在 SQL Server 2000 的两个 Query Analyzer 窗口中或 SQL Server 2005 的两个 Management Studio queries 中并列运行这段代码。）在其中一个窗口中的代码正文前面添加下列语句：

-- Window 1 header
DECLARE @au_id varchar(11), @au_lname varchar(40)
SELECT @au_id = '111-11-1111', @au_lname = 'test1'

在第二个窗口中添加下列语句，进行第二次连接：

-- Window 2 header
DECLARE @au_id varchar(11), @au_lname varchar(40)
SELECT @au_id = '111-11-1112', @au_lname = 'test2'

在两个窗口中都使用下列语句作为代码正文：

-- Body for both connections:
BEGIN TRANSACTION
INSERT Authors VALUES 
  (@au_id, @au_lname, '', '', '', '', '', '11111', 0)
WAITFOR DELAY '00:00:05'
SELECT *
  FROM authors
  WHERE au_lname LIKE 'Test%'
COMMIT

在第三个窗口中运行下列语句，确保 authors 表格中没有任何包含以下 id 的数据：

DELETE FROM authors WHERE au_id = '111-11-1111'
DELETE FROM authors WHERE au_id = '111-11-1112'

在 5 秒钟内同时执行窗口 1 和 窗口 2。因为每个窗口都要等待至少 5 秒钟的时间才能发出 SELECT 语句，所有每个连接都将完成 INSERT 操作，这样就保证了两个窗口中的 INSERT 操作在各自的 SELECT 语句发布前就已经完成了。每个窗口中的 SELECT 语句都尝试读取 authors 表格中的所有数据，查找 au_lname 字段值中类似“Test%”格式的数据。因此，两个窗口中的 SELECT 语句都将尝试读取各自连接中的插入数据 — 也读取对方连接中的插入数据。 

READ COMMITTED 隔离级别通过发布共享锁确保 SELECT 语句永远不读取未提交的数据。对于同一个资源，共享锁与排它锁互不兼容，请求者在发布共享锁之前必须等待排它锁释放。每个连接对于插入的数据都设置了排它锁，因此尝试读取对方插入数据的 SELECT 语句将试图解除插入数据的共享锁，但它会被阻塞。两个连接将互相阻塞，从而形成一个死锁。SQL Server 的锁定管理器检测到死锁时，将中止其中的一个批处理，回滚它的事务，释放它的阻塞锁，以便其他事务能够完成。作为死锁牺牲品的事务将回滚，其他事务则将成功完成。

返回页首
如何使用 TRY/CATCH 语句避免死锁


现在，让我们来使用 TRY/CATCH 语句修改代码正文。（对于本示例，需要以 SQL Server 2005 版本运行代码。）使用 TRY/CATCH 时，操作代码和错误处理代码是分开的。您应该将执行一个操作的代码放在 TRY 语句块中，将错误处理代码放在 CATCH 语句块中。如果 TRY 语句块中的代码执行失败，代码执行将跳到 CATCH 语句块。（除了那些防碍整个批处理运行的错误（如，丢失对象），该方法几乎适用于所有的错误。）

以下示例使用 TRY/CATCH 语句对前面使用的代码进行了改写。代码标题相同，但是代码正文不同：

BEGIN TRANSACTION
BEGIN TRY
  INSERT Authors VALUES 
  (@au_id, @au_lname, '', '', '', '', '', '11111', 0)
  WAITFOR DELAY '00:00:05'
  SELECT COUNT(*)  FROM Authors 
  COMMIT
END TRY
BEGIN CATCH
  SELECT ERROR_NUMBER() AS ErrorNumber
  ROLLBACK
END CATCH;
SELECT @@TRANCOUNT AS '@@Trancount'

现在，在连接到 SQL Server 2005 的并列窗口中运行这些代码，在此之前您需要确认已经删除了 authors 表格中任何可能阻止插入操作的数据；或者，您可以使用前置 DELETE 语句。

两个窗口返回的 @@TRANCOUNT 级别都为 0，这表明仍然发生了死锁，但 TRY/CATCH 语句捕获了这次发生的死锁。死锁牺牲品的批处理没有再次中止，可在它的输出结果中看到错误：

ErrorNumber
-----------
1205

@@Trancount
-----------
0

您应该已经发现 TRY/CATCH 语句具有的威力了。因为死锁错误能够为 CATCH 语句块所捕获，所以批处理将不再中止，T-SQL 代码也能继续执行。对于死锁牺牲品而言，死锁错误 1205 将代码放入 CATCH 语句块 — 在这里您可以使用新的错误处理函数浏览死锁错误。前置代码仅使用 ERROR_NUMBER() 函数取代 @@ERROR 变量，您也可以使用 ERROR_MESSAGE()、ERROR_PROCEDURE()、ERROR_SEVERITY() 和 ERROR_STATE()。这些函数的功能一目了然，它们提供的功能比我们以往使用的更多。

请注意，这个前置 CATCH 语句块包含一个 ROLLBACK。这样做的原因是，即使捕获了死锁错误，事务也不会回滚。事务仍然要失败，但是，现在您有责任在 TRY/CATCH 语句中回滚事务。那么，区别在哪里？尽管您不能使事务继续进行，但是您能够 重试事务！

返回页首
在 TRY/CATCH 语句中进行重试


在 SQL Server 2000 的 T-SQL 中，错误 1205 令人沮丧之处是它提供的建议：“Rerun the transaction.”问题是，至少在 SQL Server 2000 的 T-SQL 中，您不能做到这一点。但是，由于 SQL Server 2005 的 TRY/CATCH 为我们提供了捕获死锁错误的方法，现在，重试事务是可能实现的。

以下代码正文说明了一种执行重试操作的方法。这段代码仍然使用与前面相同的标题：

DECLARE @Tries tinyint
SET @Tries = 1
WHILE @Tries <= 3
BEGIN
  BEGIN TRANSACTION
  BEGIN TRY
    INSERT Authors VALUES 
      (@au_id, @au_lname, '', '', '', '', '', 
'11111', 0)
    WAITFOR DELAY '00:00:05'
    SELECT * FROM authors WHERE au_lname LIKE 'Test%'
    COMMIT
    BREAK
  END TRY
  BEGIN CATCH
    SELECT ERROR_NUMBER() AS ErrorNumber
    ROLLBACK
    SET @Tries = @Tries + 1
    CONTINUE
  END CATCH;
END

这段代码的功能是通过一个 WHILE 循环添加一个重试操作。我将重试次数设置为 3，重试次数是可以配置的。至少我们现在有了一种在 T-SQL 内重试一个死锁牺牲品代码的方法 — 这是我们过去一直无法做到的。

但是，需要注意整个事务是在 WHILE 循环内进行的 — 而不是在循环外部。因此执行循环时，事务不仅在每个循环体内部开始，而且也在其中结束 — 不是 TRY 语句块执行完毕，返回一个 COMMIT，就是 CATCH 语句块执行，返回一个 ROLLBACK。如果 TRY 成功，TRY 语句块将以一个 BREAK 语句结束，退出 WHILE 循环。否则，CATCH 语句块将重试计数器加 1，以一个 CONTINUE 语句结束本次循环，重新执行下次 WHILE 循环。事实上，您有实现重试事务的代码 — 就像错误 1205 告诉我们做的那样。但现在，重试操作完全在 T-SQL 内部完成。

SQL Server 2005 也提供帮助解决死锁问题的其他方法，例如 SNAPSHOT ISOLATION 级别和用于 READ COMMITTED 的新选项（称为 READ COMMITTED SNAPSHOT）。然而，这一事实 — 现在，通过 SQL Server 2005，您能够对事务进行编码并捕获死锁错误（并重试它们） — 已经意味着您拥有一个可任意支配、功能更加强大的工具。

下载：单击下载按钮来下载代码 (505RON.SQL)

要查找有关 SQL Server Professsional 和 Pinnacle Publishing 的信息，请访问它们的 Web 站点 http://www.pinpub.com/

注：这个网站不是 Microsoft Corporation 的 Web 站点。Microsoft 对该网站的内容不承担责任。
以下为摘录

数据库操作的死锁是不可避免的，本文并不打算讨论死锁如何产生，重点在于解决死锁，通过SQL Server 2005, 现在似乎有了一种新的解决办法。

将下面的SQL语句放在两个不同的连接里面，并且在5秒内同时执行，将会发生死锁。

use Northwind

begin tran
    insert into Orders(CustomerId) values('ALFKI')
    waitfor delay '00:00:05'
    select * from Orders where CustomerId = 'ALFKI'
commit
print 'end tran'

SQL Server对付死锁的办法是牺牲掉其中的一个，抛出异常，并且回滚事务。在SQL Server 2000，语句一旦发生异常，T-SQL将不会继续运行，上面被牺牲的连接中， print 'end tran'语句将不会被运行，所以我们很难在SQL Server 2000的T-SQL中对死锁进行进一步的处理。

现在不同了，SQL Server 2005可以在T-SQL中对异常进行捕获，这样就给我们提供了一条处理死锁的途径：

下面利用的try ... catch来解决死锁。

SET XACT_ABORT ON

declare @r int
set @r = 1
while @r <= 3
begin
    begin tran
    
    begin try       
        insert into Orders(CustomerId) values('ALFKI')
        waitfor delay '00:00:05'
        select * from Orders where CustomerId = 'ALFKI'
        
        commit
        break
    end try
        
    begin catch
        rollback
        waitfor delay '00:00:03'
        set @r = @r + 1
        continue
    end catch
end

解决方法当然就是重试，但捕获错误是前提。rollback后面的waitfor不可少，发生冲突后需要等待一段时间，@retry数目可以调整以应付不同的要求。

但是现在又面临一个新的问题: 错误被掩盖了，一但问题发生并且超过3次，异常却不会被抛出。SQL Server 2005 有一个RaiseError语句，可以抛出异常，但却不能直接抛出原来的异常，所以需要重新定义发生的错误，现在，解决方案变成了这样:

declare @r int
set @r = 1
while @r <= 3
begin
    begin tran
    
    begin try       
        insert into Orders(CustomerId) values('ALFKI')
        waitfor delay '00:00:05'
        select * from Orders where CustomerId = 'ALFKI'
        
        commit
        break
    end try
        
    begin catch
        rollback
        waitfor delay '00:00:03'
        set @r = @r + 1
        continue
    end catch
end

if ERROR_NUMBER() <> 0
begin
    declare @ErrorMessage nvarchar(4000);
    declare @ErrorSeverity int;
    declare @ErrorState int;

    select 
        @ErrorMessage = ERROR_MESSAGE(),
        @ErrorSeverity = ERROR_SEVERITY(),
        @ErrorState = ERROR_STATE();

    raiserror (@ErrorMessage,
               @ErrorSeverity,
               @ErrorState
               );
end

我希望将来SQL Server 2005能够直接抛出原有异常，比如提供一个无参数的RaiseError。

因此方案有点臃肿，但将死锁问题封装到T-SQL中有助于明确职责，提高高层系统的清晰度。现在，对于DataAccess的代码，或许再也不需要考虑死锁问题了。

declare @r int 
set @r = 1 
while true 
begin 
begin tran 

begin try 
insert into Orders(CustomerId) values('ALFKI') 
waitfor delay '00:00:05' 
select * from Orders where CustomerId = 'ALFKI' 

commit 
break 
end try 

begin catch 
rollback 
if @r <= 3 
begin 
waitfor delay '00:00:03' 
set @r = @r + 1 
continue 
end 
else 
begin 
declare @ErrorMessage nvarchar(4000); 
declare @ErrorSeverity int; 
declare @ErrorState int; 

select 
@ErrorMessage = ERROR_MESSAGE(), 
@ErrorSeverity = ERROR_SEVERITY(), 
@ErrorState = ERROR_STATE(); 

raiserror (@ErrorMessage, 
@ErrorSeverity, 
@ErrorState 
); 
end 
end catch 
end 

不知道这个行不行？raiserror应该可以直接退出循环吧？

RAISERROR： 
返回用户定义的错误信息并设系统标志，记录发生错误。通过使用 RAISERROR 语句，客户端可以从 sysmessages 表中检索条目，或者使用用户指定的严重度和状态信息动态地生成一条消息。这条消息在定义后就作为服务器错误信息返回给客户端。 

语法 
RAISERROR ( { msg_id | msg_str } { , severity , state } 
[ , argument [ ,n ] ] ) 
[ WITH option [ ,n ] ] 

参数 
msg_id 
存储于 sysmessages 表中的用户定义的错误信息。用户定义错误信息的错误号应大于 50,000。由特殊消息产生的错误是第 50,000 号。 

msg_str 
是一条特殊消息，其格式与 C 语言中使用的 PRINTF 格式样式相似。此错误信息最多可包含 400 个字符。如果该信息包含的字符超过 400 个，则只能显示前 397 个并将添加一个省略号以表示该信息已被截断。所有特定消息的标准消息 ID 是 14,000。 

severity 
用户定义的与消息关联的严重级别。用户可以使用从 0 到 18 之间的严重级别。19 到 25 之间的严重级别只能由 sysadmin 固定服务器角色成员使用。若要使用 19 到 25 之间的严重级别，必须选择 WITH LOG 选项。 
注意 20 到 25 之间的严重级别被认为是致命的。如果遇到致命的严重级别，客户端连接将在收到消息后终止，并将错误记入错误日志和应用程序日志。 

state 
从 1 到 127 的任意整数，表示有关错误调用状态的信息。state 的负值默认为 1。