解决死锁问题

在诊断死锁问题之后，下一步是尝试解决两个同时运行并相互锁定对方所需资源的应用程序之间的死锁问题。 这里提供的准则可以帮助您解决您所遇到的死锁问题，并可以帮助您预防将来发生此类意外。

请使用下列步骤来诊断不可接受的死锁问题的原因并应用修正措施：

1. 借助于锁定事件监视器或管理通知日志，获取关于代理程序在其中遇到死锁问题的表的信息。
2. 使用管理通知日志中的信息来决定如何解决死锁问题。
   您可以通过遵循多个准则来减少锁定争用情况并缩短锁定等待时间。 请考虑下列选项：

   • 每个应用程序连接都应该处理它自己的一组行，以避免锁定等待。
   • 有时，可以通过确保所有应用程序按相同顺序访问公共数据来降低死锁频率 - 例如，这意味着它们访问（并因此锁定）表 A 中的行，接着访问表 B 中的行，接着访问表 C 中的行，依此类推。 如果两个应用程序按不同的顺序对相同对象挂起不兼容的锁定，那么它们发生死锁的风险将显著加大。
   • 锁定超时情况并不比死锁好多少，这两者都会导致事务回滚，但如果您必须最大程度地减少死锁数，那么可以通过确保锁定超时通常在相关的潜在死锁能够被检测到之前发生来实现目标。 要做到这一点，请将 locktimeout 数据库配置参数值（单位为秒）设置为远小于 dlchktime 数据库配置参数值（单位为毫秒）。 否则，如果 locktimeout 大于 dlchktime 时间间隔，那么死锁检测器可能会在死锁情况发生后立即被唤醒并在锁定超时发生前检测到死锁。
   • 尽可能避免并发 DDL 操作。 例如，DROP TABLE 语句可能会引起大量的目录更新操作，这是因为，除了为表本身删除行以外，还可能必须为表索引、主键和检查约束等等删除行。 如果其他 DDL 操作是删除或创建对象，那么可能会发生锁定冲突，偶尔甚至会发生死锁。
   • 最佳实践是，尽早落实下列操作：
     • 写操作，例如删除、插入和更新
     • 数据定义语言 (DDL) 语句，例如 ALTER、CREATE 和 DROP
     • BIND 和 REBIND 命令
3. 死锁检测器无法了解和解决下列情况，因此应用程序设计必须对此进行预防。
   应用程序 (尤其是多线程应用程序) 可能发生涉及 Db2® 锁定等待和 Db2 软件外部资源 (例如信号量) 等待的死锁。 例如，连接 A 可能正在等待连接 B 所挂起的锁定，而 B 可能正在等待 A 占用的信号。