通过 Shell 脚本自动检测 DB2 的锁等待问题，真的是 DBA 工具箱里的一个小利器。脚本逻辑清晰，执行完能直接告诉你哪条 SQL 在“卡人”，还能顺带抓出锁的持有者，蛮适合线上巡检用的。尤其是配合 DB2 的SNAPSHOT_LOCKWAIT和SNAPSHOT_STATEMENT，基本就能把锁冲突看得一清二楚。

DB2 的锁机制其实挺“细腻”的，读锁、写锁、意向锁各种组合拳，稍有不慎就容易出现锁等待。如果你常在大并发场景下业务，遇到应用慢得要命的情况，不妨先跑跑这个脚本，说不定真能揪出罪魁祸首。

Shell 脚本写得还挺接地气的，用的是ksh，配合几个echo和touch命令，日志和输出文件都能自动生成，文件名里还带时间戳，排查问题的时候特方便。

整个思路也比较实在，先连上数据库，打开一堆 DB2 的监控开关（比如lockON、statementON这些），执行 SQL 拿锁等待的快照数据，再筛出 Top 耗时的那部分 SQL——是不是有点像应用版的“抓包”？

SQL 部分值得夸一下，JOIN 两个快照表，通过ORDER BY STMT_ELAPSED_TIME_MS DESC挑出最占资源的那几条 SQL，还限定前 20 条，挺实用。你拿到这些结果，就能直接是哪个业务点出了问题，响应慢的锅甩得也有理有据。

不过用之前建议先检查下你库的监控设置是不是开了，像DFT_MON_LOCK和DFT_MON_STMT没开的话，是采不到数据的，脚本也跑不出来啥。

如果你日常管着 DB2，还老被人追着问“怎么又卡住了”，这个 Shell 脚本可以说是个还不错的备选方案。手动查锁麻烦又容易漏，有这工具能省下不少心力。

想要进一步了解的话，可以看看这些文章：DB2 锁等待方案详解、使用 Shell 创建 DB2 数据库，都是挺实用的干货。