问在什么情况下会导致LockAcquisitionException和SQLCODE=-911，SQLSTATE=40001，SQLERRMC=68

EN

您将得到LockAcquisitionException (SQLCODE=-911 SQLERRMC=68)作为锁定超时的结果。

比较dbViz和hibernate的操作可能没有帮助，因为它们可能在jdbc级别使用不同的类/方法和设置，这会影响异常细节。重要的是，在Db2级别，无论他们报告锁定超时的异常名是什么，都经历了SQLCODE=-911和SQLERRMC=68。

根据许多因素，您可以获得诸如UPDATE或DELETE、INSERT或SELECT (以及其他包括DDL和命令)等语句的锁定超时。

所有锁定超时都有一个共同点:一个事务等待太久，由于另一个事务提交不够快而被回滚。

锁定超时诊断和锁定超时避免是不同的主题。

等待锁的时间可以根据所选择的设计在数据库级别、连接级别或语句级别设置，包括混合这些设计。您还可以通过调整数据库参数(如Db2、LOCK_TIMEOUT )和在语句级别或连接级别调整隔离级别来调整锁的行为。

明智的做法是在考虑避免之前确保准确的诊断。

在运行DB2LUW v10.5.0.9时，请仔细研究此页面和所有相关链接：

10.5.0/com.ibm.db2.luw.admin.trb.doc/doc/t0055072.html

有许多情况可能导致锁定超时，因此最好确切地知道哪种情况与您的情况相关。

避免锁冲突是一个配置和事务设计的问题，所以这是一个更大的话题。配置可以是Db2级别的，也可以是应用层的，也可以是两者兼而有之。

有时候，bug会导致锁定超时，例如，当应用程序服务器线程有一个挂起的数据库连接，并且没有提交并且应用程序没有正确清理时。

您应该诊断锁超时中的参与者。在DB2LUW上有不同的方法来进行锁冲突诊断，所以选择适合您的方法。

一个仍然适用于V10.5.0.9的简单诊断工具是使用DB2-注册表变量DB2_CAPTURE_LOCKTIMEOUT=ON，尽管不推荐使用该方法。您可以动态地设置这个变量(并取消它)，而不需要任何服务中断。因此，如果您有一个可重新创建的场景，导致SQLCODE=-911 SQLERRMC=68 (锁超时)，您可以打开这个变量，重复测试，然后关闭变量。如果该变量被打开，并且发生锁定超时，Db2将编写一个新的文本文件，其中包含有关锁定情况中参与者的信息，其中显示有助于您了解正在发生的事情的详细信息，并使您可以考虑在有足够事实时解决问题的方法。您不希望永久设置这个变量，因为如果您获得了大量的锁定超时，它可能会影响Db2诊断文件系统并填充该文件系统。所以你得小心点。在本页的Knowledge Center中阅读这个变量：10.5.0/com.ibm.db2.luw.admin.regvars.doc/doc/r0005657.html您可以通过仔细研究这些文件的内容来诊断锁定超时，当然也有必要理解细节。这是一个经常性的DBA活动。

另一种方法是使用db2pdcfg -catch和自定义db2cos脚本，在Db2抛出-911之后决定该做什么。这需要脚本技巧，它可以让您准确地决定在-911之后收集哪些诊断信息，以及在哪里存储这些诊断信息。

另一种方法是使用event monitor for locking，它涉及更多的工作，但可能带来更多的红利。文档位于：10.5.0/com.ibm.db2.luw.sql.ref.doc/doc/r0054074.html，一定要研究“相关概念”和“相关任务”页面。