调查导致DB2死锁的根本原因和资源

问题:由于死锁,COBOL-DB2程序失败。您将如何查找由于程序失败而导致的资源?

当两个或多个应用程序卡住,彼此等待释放对它们所需资源的锁定时,将发生DEADLOCK条件。可以在DB2系统作业DSNZMSTR作业中找到详细的信息和日志。DSNZ是已安装的DB2子系统的名称,并且因安装而异。该作业的SYSOUT继续显示DB2级别的系统日志。与死锁相关的日志在此作业中也可用。

首先,我们需要找出由于死锁而导致我们的COBOL-DB2程序失败的时间。接下来,我们将在特定时间检查MSTR作业的SYSOUT。

我们将获得死锁信息,例如-死锁中涉及的COBOL-DB2程序/事务/进程,发生死锁的DB2资源等。

让我们看一个死锁情况的例子。

考虑下面的ORDERS和TRANSACTIONS DB2表。

ORDER_ID
订购日期
TRANSACTION_ID
Z22345
2020年10月22日
IRN11236
Z62998
2020年9月14日
IRN77812
Z56990
2020年1月9日
IRN89023
Z56902
2020年9月21日
IRN09663
Z99781
2020年12月8日
IRN88112
Z56112
2020年10月30日
IRN67091

 

TRANSACTION_ID
TRANSACTION_AMOUNT
IRN11236
6754
IRN77812
451
IRN89023
9087
IRN09663
1156
IRN88112
5908
IRN67091
152


如果当前在执行阶段有两个程序-PROG A和PROGB。PROGA正在读取TRANSACTIONS和ORDERS DB2表,并在两个表上都持有SHARED锁。PROG B还在读取TRANSACTIONS和ORDERS DB2表,并且还在两个表上都持有SHARED锁。

PROG A需要更新ORDERS表,因此它将其SHARED锁升级为UPDATE锁,然后将等待PROG B从ORDERS表中释放其SHARED锁,以便将UPDATE锁提升为EXCLUSIVE锁。

同时,PROG B需要更新TRANSACTIONS表,因此它会将其SHARED锁升级为UPDATE锁,并等待PROG A将其SHARED锁从TRANSACTIONS表中释放,以便将其锁从UPDATE升级为EXCLUSIVE。

在上述情况下,PROG A和PROG B正在等待各自释放锁,但实际上它们被卡住并进入称为死锁的状态。