使用 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 的最新版本，用它来进行试验。

　　可能发生的死锁情况有很多，但最有趣、最微妙的是那些关于阅读器和编写器互相阻塞的死锁。以下代码在 pubs 数据库中就产生了这样一个死锁。（您可以在 sql server 2000 的两个 query analyzer 窗口中或 sql server 2005 的两个 management studio queries 中并列运行这段代码。）在其中一个窗口中的代码正文前面添加下列语句：

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

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

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

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

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

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

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

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

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

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

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

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

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

　　这段代码的功能是通过一个 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，您能够对事务进行编码并捕获死锁错误（并重试它们） — 已经意味着您拥有一个可任意支配、功能更加强大的工具。