数据结构
网络
关系数据库管理系统
操作系统
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 语言编程
C++
C#
MongoDB
MySQL
Javascript
PHP
物理学
化学
生物学
数学
英语
经济学
心理学
社会学
服装设计
法律研究DB2 死锁的根本原因和负责资源调查
问题：一个 COBOL-DB2 程序由于死锁而失败。您将如何找到导致程序失败的资源？
解决方案
当两个或多个应用程序发生死锁时，它们会互相等待对方释放其所需的资源上的锁。在 DB2 系统作业 DSNZMSTR 作业中可以找到详细的信息和日志。DSNZ 是已安装的 DB2 子系统的名称，它因安装而异。此作业的 SYSOUT 继续显示 DB2 级别的系统日志。与死锁相关的日志也存在于此作业中。
首先，我们需要找出我们的 COBOL-DB2 程序因死锁而失败的时间。接下来，我们将检查该特定时间段内 MSTR 作业的 SYSOUT。
我们将获得死锁信息，例如：参与死锁的 COBOL-DB2 程序/事务/进程、发生死锁的 DB2 资源等。
让我们看一个死锁条件的例子。
考虑以下 ORDERS 和 TRANSACTIONS DB2 表。
| 订单 ID | 订单日期 | 交易 ID |
| Z22345 | 22-10-2020 | IRN11236 |
| Z62998 | 14-09-2020 | IRN77812 |
| Z56990 | 01-09-2020 | IRN89023 |
| Z56902 | 21-09-2020 | IRN09663 |
| Z99781 | 12-08-2020 | IRN88112 |
| Z56112 | 30-10-2020 | IRN67091 |
| 交易 ID | 交易金额 |
| IRN11236 | 6754 |
| IRN77812 | 451 |
| IRN89023 | 9087 |
| IRN09663 | 1156 |
| IRN88112 | 5908 |
| IRN67091 | 152 |
如果有两个程序当前处于执行阶段——PROG A 和 PROG B。PROG A 正在读取 TRANSACTIONS 和 ORDERS DB2 表，并持有这两个表上的共享锁。PROG B 也正在读取 TRANSACTIONS 和 ORDERS DB2 表，并且也持有这两个表上的共享锁。
PROG A 需要更新 ORDERS 表，因此它将把其共享锁提升到更新锁，然后它将等待 PROG B 从 ORDERS 表释放其共享锁，以便更新锁可以提升到独占锁。
同时，PROG B 需要更新 TRANSACTIONS 表，因此它将把其共享锁提升到更新锁，并将等待 PROG A 从 TRANSACTIONS 表释放其共享锁，以便将其锁从更新提升到独占。
在上述场景中，PROG A 和 PROG B 正在等待对方释放锁，但实际上它们被卡住了并进入了一个称为死锁的状态。
更新于： 2020-11-30
1K+ 次查看
广告