0

检查从指向 z/OS 上 DB2 数据库实例的两个 DbVisualizer 实例启动的两个事务的行为，我注意到在从表中删除记录期间的以下行为。

假设我有一个MYTABLE带有主键的表MYID，并假设执行

select MYID from MYTABLE

给出类似的东西（数字是任意的，写下来只是让事情变得具体）

112
119
...
...
789
...

在试验 A 中，我从第一个事务（使用第一个 DBVisualizer 实例）开始执行，并且没有提交，

DELETE FROM MYTABLE WHERE MYID=112

然后我从第二个事务执行（使用第二个 DBVisualizer 实例）

DELETE FROM MYTABLE WHERE MYID=119

然而，这会阻止第二笔交易，并在一段时间后产生错误

UNSUCCESSFUL EXECUTION CAUSED BY DEADLOCK OR TIMEOUT. 
REASON CODE 00C9008E, TYPE OF RESOURCE 00000302, AND...

在类似的试验中，试验 B，当我使用MYIDs112而789代替（789是“不靠近” 112）时，第二笔交易不会阻塞。查找TYPE OF RESOURCE 00000302一个发现的含义，在https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/codes/src/tpc/db2z_resourcetypes.html，“表空间页面”（链接是针对 DB2在 z/OS 上）。

所以看起来在试验 A中，第一个 DELETE “锁定”了一些“页面”，记录都属于该页面，MYID 112并且119该锁定随后阻塞了第二个事务。而在试验 B中，两条记录属于不同的“页面”，第一个 DELETE 不会阻止第二个。

拿一本关于 DB2 的著名书籍，我读到“根据请求的操作，数据库管理器可以获取表行、表块、表、表空间、缓冲池和数据库上的锁”。然后解释存在各种“锁定模式”。

我的问题是：上面引用中的“表块上的锁”是指在试验中观察到的“表空间页上的锁”，还是引用中没有提到的其他锁类型？为什么使用的锁是“表空间页面锁”而不是行级锁，它可能不会导致第二个事务在试验 A期间阻塞？（我读到了 DB2 中的锁升级，但据我所知，当时没有涉及到的事务进行MYTABLE）

所涉及的 DB2 版本在“兼容模式”下是 10，这会将其降级为类似于 DB2 版本 8。我认为配置应该是“默认”或“标准”。

（这个问题是我努力理解前面问题中描述的问题的结果，一个删除多行的删除语句会导致死锁吗？）

编辑

刚刚在我的 Windows 笔记本上的 DB2 Express 上尝试过，我看到的行为是不同的；正如我所期望的那样，锁是行锁（所以只有当我尝试删除同一行时，第二个 DELETE 才会阻塞）。那么这确实是关于 z/OS 上的 DB2 吗？还是 DB2 的旧版本？或者也许观察暗示了 DB2 的某些特殊配置？

4

1 回答 1

3

我相信 DB2 z/OS 表空间的默认设置是LOCKSIZE ANY，这实际上意味着LOCKSIZE PAGE，也就是说，如果该页面上的任何行被更新，则整个表空间页面都会被锁定。文档参考。这将解释您所看到的行为。

ALTER TABLESPACE ... LOCKSIZE ROW为保存有问题的表的表空间发出（或要求您的 DBA 发出）语句。对于 z/OS 上的 DB2，通常的做法是每个表空间有一个表，因此这种更改不会对其他工作负载产生太大影响（除非您设法用完数据库中的所有锁定内存）。

在 DB2 for LUW 中，只有行级和表级锁是可能的，所以这也解释了您在 Windows 上看到的 DB2 Express 的不同之处。

于 2017-03-31T15:53:52.537 回答