基于以下链接：
我打开DB2_CAPTURE_LOCKTIMEOUT=ON，然后我检查我是否成功更改它db2set -all，我可以看到它已经打开了。
之后，我通过以下链接成功模拟了锁定超时：
https://db2forum.wordpress.com/2011/10/17/new-options-for-analyzing-lock-timeouts-in-db2-9-5/
我成功得到Reason code "68". SQLSTATE=40001.
但是，我仍然无法db2locktimeout在/home/db2inst1/sqllib/db2dump.
我只能db2diag.log在这条路径中看到，但不能在db2locktimeout日志中看到。
我可以知道我犯了什么错误吗？
当您引用 V10.5 页面时，我假设您的 Db2 服务器至少是该版本。寻求帮助时，始终编写您的 Db2 版本和修订包。
这个已弃用（但仍在工作）的变量仅对新编译的SQL 语句有效。这意味着如果您的包缓存已经缓存了 SQL 语句（用于重新创建 -911 原因代码 68 的语句），那么如果这些 SQL 涉及到 -911，则不会出现任何文件。
如果您的娱乐场景可以在开发或测试数据库上运行，那么您可以刷新动态语句缓存（不要在生产环境中执行此操作），或者您可以反弹 Db2 实例（具有清除包缓存的副作用）。
如果您的娱乐场景仅使用静态 SQL，则需要重新绑定这些包（不要在生产环境中执行此操作），或者您可以重新绑定 Db2 实例。
如果您只能在生产环境中重新创建问题，并且刷新、弹跳或重新绑定对该环境的侵入性太大，那么建议使用事件监视器进行锁定的替代方法，尽管它需要更多的努力。
要详细了解 Db2 如何编译 SQL，以及动态 SQL 语句如何连同它们的访问计划一起存储在内存中（称为包缓存），请研究 Db2 知识中心或查阅任何 Db2 参考书。