Db2 联机备份阻塞截断表

有文献记载，在DB2中，TRUNCATE语句与在线备份不兼容，因为它在表上获得一个Z锁，并阻止在线备份并发运行。 当截断尝试获取内部联机备份对象上的共享锁时，会发生锁定等待

由于这是产品中的设计，我将不得不采取变通办法，所以这篇文章不是关于解决方案，而是为什么它们不能一起工作。我没有找到一个合理的解释来解释为什么db2中存在这样的限制

有什么见解吗

谢谢， 卢西亚诺·莫雷拉来自

当表持有Z锁时，任何并发应用程序都不能读取或删除 更新该表中的数据

现在我们知道Z锁是对表的独占访问，拒绝对表的读写访问

从

独占访问：任何其他会话都不能在表上打开光标或在表上保持锁（SQLSTATE 25001）

从

Delete是日志操作，其中as Truncate在容器级别使表为空。 （日志操作–DML操作记录在日志中（oracle中的重做日志、DB2中的事务日志等）。它存储在日志中，用于提交或回滚操作。）

---

这是最有趣的部分。Truncate只是“忘记”表的内容，而deletes则逐行删除处理所有触发器、钟声和哨声。因此，当您截断所有读取游标时，这些游标将无效。为了防止像这样愚蠢的事情发生，只有当没有人试图访问一张桌子时，你才能完全清空它。在线备份显然需要阅读该表。因此，不可能让两个人同时访问同一个表。

嗨，彼得，谢谢你提供的信息。我对这篇文章做了一个快速的回顾，但它并没有指向我想要的方向。truncate表成功获取表中的Z锁，但被“内部联机备份”锁阻止。Z锁总是试图得到那个锁吗？这个问题的原因是试图探究DB2为何以这种方式工作的一些细节。我不能同意当备份尝试读取截断操作中间的对象时，它应该被阻止。我仍然不同意DBMS实现在备份结束前阻止截断表，例如SQL Server允许这两种操作都发生。在我们的例子中，我有一个15 TB的数据库，每12小时针对一个有500.000行的表发出一个截断表，根据时间安排，它将在截断完成之前被阻塞数小时，生成一个锁链。如果表有500行，可能是标准的删除操作。不过，我不确定锁的问题。顺便说一句，如果你能马上把这个例子放在问题中，这会有帮助的。有时，人们会对现实世界的问题提出创造性的想法。。。。当我想起来的时候，你为什么要把50万行放在一张桌子上，在12小时后扔掉它们？