在实践中遇到的 package 相关性能问题（1）

look_w

引言本系列的第一部分用了较长的篇幅来较为深入的探索了 Db2 package 相关概念和内部机制，现在来介绍从 Db2 package                层面来优化性能。其实，有了前文的理论基础再来看问题，很多问题都可以迎刃而解甚至做到知其然并且知其所以然。比如说一个简单的事情，有些时候会利用网络抓包工具然后解析                DRDA 协议来抓取应用发起的 SQL 语句并分析 SQL                请求响应时间，以此来监控和分析数据库系统的性能，而且市场上也有类似功能的产品，请问，对于嵌入式静态 SQL，能用网络抓包方式来抓到具体 SQL                语句以及响应时间吗？
接下来介绍几个与 Db2 package 相关的性能问题场景，都是作者工作中曾经遇到过的。
高并发场景中迟早会遇到的 xhshlatch 问题 这是前几年发生过的事情，一个重要的渠道类银行业务系统，Java 程序使用 JDBC 方式连接 Db2 服务器，典型的高并发、短交易系统，当时还是                Db2 9.7.10 版本，突然某一天交易响应率下降，同时在数据库上看到大量的 latch。如清单 1 所示。
清单 1 问题发生时的                latch 信息

1 2 3 4 5 6 7 8

> db2pd -latches： Address Holder Waiter Filename LOC LatchType HoldCount              0x0A00020001DA22A8 511780     69051      /view/db2_v97fp10_aix64_s141015/vbs/engn/sqp/inc/sqlpLockInternal.h 513        SQLO_LT_SQLP_LHSH__xhshlatch 1          0x0A00020001DA22A8 511780 261703 /view/db2_v97fp10_aix64_s141015/vbs/engn/sqp/inc/sqlpLockInternal.h 513 SQLO_LT_SQLP_LHSH__xhshlatch 1 ……

第一次看到这个 SQLO_LT_SQLP_LHSH__xhshlatch（在本文中简称 xhshlatch），完全不知所云，我们知道分析 latch                问题的最有效的方法就是收集 stack，通过 stack 来分析 latch 堵塞的场景。当问题发生时收的 stack 如清单 2 所示。
清单 2 问题发生时的                latch 信息

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

-------Frame------ ------Function + Offset------ 0x090000002104B258 thread_waitlock@glue881 + 0x8C 0x090000002104AFE0 sqloXlatchConflict + 0x1E8 0x090000002104AD3C sqloXlatchConflict@glue1AB + 0x78 0x0900000020F3D3C4 sqlplrq__FP9sqeBsuEduP14SQLP_LOCK_INFO + 0x24 0x0900000020F85FBC sqlrr_get_lock__FP8sqlrr_cbP14SQLP_LOCK_INFOUiPUi +     0x100 0x0900000020F85DD0     sqlra_pkg_lock__FP8sqlrr_cbPUcsT2T3T2iUiT7P14SQLP_LOCK_INFO + 0xB8 0x0900000020F852C4     sqlra_find_pkg__FP8sqlrr_cbPUcsT2T3T2T3iT8P14SQLP_LOCK_INFOPP20sqlra_cached_package     + 0x190 0x0900000020F84ADC sqlra_revalidate_pkg__FP8sqlrr_cb + 0xA0 0x0900000020F84E24 .sqlra_load_pkg.fdpr.clone.2194__FP8sqlrr_cbPUcsT2T3T2b     + 0x190 0x0900000020F7DB3C     sqlrr_sql_request_pre__FP14db2UCinterfaceUiiP16db2UCprepareInfoP15db2UCCursorInfo     + 0x1678 0x0900000021093F54     sqlrr_sql_request_pre__FP14db2UCinterfaceUiiP16db2UCprepareInfoP15db2UCCursorInfo     + 0x9C

有了本系列第一部分文章的基础，再来看这个 stack 就很好理解，这里看到了熟悉的                sqlra_load_pkg，sqlra_find_pkg，sqlra_pkg_lock 等函数，可以知道这是 package                上相关的竞争。问题解决的具体过程不细说，最后是紧急联系 IBM Db2 国内的支持团队，告知可以设置一个注册变量来解决，db2set                DB2_APM_PERFORMANCE=ON，设置后需要重启数据库实例，性能问题马上得以解决（但是有功能性的副作用）。
本着严谨的态度，后来对这种方案进行了深入的分析。根据相关的 technote 的说明，该注册变量打开之后，Db2 服务器在处理 package                时能够避免 package lock，于是利用 db2trc 工具进行了验证，对比了该注册变量打开和关闭情况下的 trace 情况，结果如清单 3                所示。
清单 3 DB2_APM_PERFORMANCE 开关后不同的 trace

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

# 默认 APM_PERFORMANCE 为 OFF 的 trace | | | | | sqlra_get_section entry | | | | | | sqlra_load_pkg entry | | | | | | | sqlra_revalidate_pkg entry | | | | | | | | sqlra_find_pkg entry | | | | | | | | | sqlra_pkg_lock entry | | | | | | | | | | sqlra_fmt_pkg_lock entry | | | | | | | | | | sqlrr_get_lock entry | | | | | | | | | | | sqlplrq entry …… | | | | | | sqlra_load_pkg exit | | | | | | sqlra_set_stmt_authid_dynrules entry | | | | | | sqlra_set_stmt_authid_dynrules exit | | | | | sqlra_get_section exit              # APM_PERFORMANCE为ON的trace | | | | | sqlra_get_section entry | | | | | | sqlra_set_stmt_authid_dynrules entry | | | | | | sqlra_set_stmt_authid_dynrules exit | | | | | sqlra_get_section exit

清单 3 中，再次看到了感觉眼熟的函数们，例如 sqlra_get_section 和 sqlra_pkg_lock 等，在本系列第一部分的清单 7                中即嵌入式 SQC 的 trace 中出现过，再次说明 JDBC 方式的 package 工作机制和其他类型的 package                工作机制是基本一致的。
经过对比，明显的看到 DB2_APM_PERFORMANCE 为 OFF 时，执行 SECTION 即执行计划时需要有锁定 package（这里是                CLI package）的过程，当应用程序高并发的情况下，这个锁定会导致堵塞。而该注册变量为 ON 时，则完全没有锁定 package                的过程，从而避免了堵塞，解决之前的问题。至于为什么问题发生时体现在 xhshlatch 堵塞，这应该是因为 package 加锁解锁的过程中，Db2                内部 hash 对象上的互斥访问用到了 xhshlatch。
关于这个问题的信息，可以参考 technote " "。
总结一下 DB2_APM_PERFORMANCE 的用法，在 Db2 9.7 版本时，该注册变量还只有 ON 和 OFF 两个值，当设置为 ON                时，所有类型的 package lock 都被避免，包括嵌入式 SQL 的 package，但没有了锁的保护，所有 package                绑定或者重新绑定都无法执行，新的嵌入式 SQL 程序也无法预编译。在 Db2 10.5 版本（或者某个 fix pack）之后，可以设置该注册变量为                16，避免了 CLI package 上的锁定，同样的也就无法对 CLI package 进行重新绑定等操作，该设置对于嵌入式 SQL                没有影响。顺便提一句，设置为 16 的这个功能，只在 technote 中有过介绍，至今在 Db2 11 版本的知识中心的介绍中，还只有 ON 和                OFF。
现在作者所在的银行已全面升级到 Db2 10.5 版本，把 DB2_APM_PERFORMANCE=16 作为标准，在所有上线的 Db2                生产系统进行了配置。
另外，xhshlatch 会在多种场景中出现，并不限于清单 2 中的场景