想快速查db2数据库锁表情况，这些方法你得知道怎么用才行

直接查询DB2数据库的锁表情况是数据库管理员和开发人员在遇到性能问题或应用挂起时经常需要进行的操作,当发现某个应用执行特别慢，或者干脆不响应了，很可能是遇到了锁等待，也就是我们常说的“锁表”，这时候，你需要一些直接有效的方法来快速定位问题所在，下面这几种方法非常实用，但关键是你得知道在什么情况下用哪个，以及怎么去解读结果。

一个非常直接和常用的方法是使用DB2的命令行处理器（CLP）来查看快照，这个方法就像给数据库当前的状态拍一张照片，你能看到所有和锁相关的信息，具体的命令是db2 get snapshot for locks on <数据库名>（来源：IBM DB2官方文档关于快照监视器的部分），这个命令会输出大量的信息，包括哪个应用持有锁、锁的类型、锁在哪个表上、哪个行上，以及哪些应用在等待锁，对于刚接触的人来说，输出内容可能会显得很多很乱，你需要重点关注的是“应用程序句柄”（Application Handle），这是每个连接的唯一标识；然后是“锁对象类型”（Lock Object Type），看是表锁还是行锁；“锁模式”（Lock Mode），比如是共享锁（S）还是排他锁（X）；以及“锁状态”（Lock Status），如果是“等待”（WATING），那就说明这个应用被卡住了，这个方法的好处是信息全面，适合在问题已经发生，你需要进行全面排查的时候使用。

第二个方法更侧重于动态监控,类似于实时监控系统，那就是使用DB2的管理视图（Management Views），DB2提供了一系列以SYSIBMADM开头的管理视图，你可以直接用SQL语句来查询它们，这对于习惯写SQL的人来说非常友好（来源：IBM DB2知识中心关于管理视图的介绍），查询锁信息最常用的视图是SYSIBMADM.LOCKWAITS 和 SYSIBMADM.SNAPLOCK，当你感觉数据库可能正在发生锁等待时，可以立刻执行一条简单的SQL：*SELECT FROM SYSIBMADM.LOCKWAITS，这个视图的美妙之处在于，它只显示当前正在发生的锁等待关系，结果非常清晰，直接告诉你谁在等谁，一目了然，而SYSIBMADM.SNAPLOCK**则提供了更详细的锁信息，类似于快照，但以表的形式返回，方便你进行筛选和排序，你可以写SQL只查询某个特定表上的锁，或者只查排他锁，这种方法非常适合集成到监控脚本中，实现自动化的锁监控和告警。

第三个方法是在你已经大概知道是哪个应用导致问题时的“精准打击”方法，就是使用db2pd工具，这个工具是一个底层的诊断工具，功能非常强大（来源：IBM DB2故障诊断文档），在数据库服务器上，你可以在命令行中执行db2pd -db <数据库名> -locks 来快速获取锁信息。db2pd输出的信息非常原始，但速度极快，对系统性能影响很小，因为它不需要获取复杂的快照，它的输出会清晰地展示锁的链状关系，特别是锁等待链，让你很容易看出是哪个应用持有了一个锁，导致后面一串应用都在等待，当你从管理视图或者快照中找到了可疑的应用句柄（Application Handle）后，可以用db2pd -db <数据库名> -applications 找到该句柄对应的详细应用信息，甚至可以用db2pd -db <数据库名> -agents 看到更底层的执行代理信息，这个方法通常用于深度诊断，当其他方法无法满足需求时，它能提供更底层的信息。

除了查询,知道如何解决问题同样重要，当你找到了导致锁等待的“罪魁祸首”应用句柄后，最直接的解决方式就是强制断开这个连接，命令是db2 force application (应用程序句柄)（来源：DB2基础管理命令），这个操作要非常谨慎，因为它会回滚该应用正在进行的所有事务，相当于强制终止一个程序，在执行之前，最好能确认这个应用是否是可以中断的，比如是一个已经挂起的测试环境应用，在生产环境中，需要与相关开发或业务人员沟通确认。

这几个方法各有千秋：快照适合全面复盘；管理视图适合实时监控和集成；db2pd适合快速定位和深度分析，要想快速处理锁表问题，光知道命令不行，还得理解它们分别能告诉你什么故事，最好的方式是结合使用，比如先用SYSIBMADM.LOCKWAITS视图快速确认是否有锁等待以及主要参与者，然后用db2 get snapshot或者db2pd获取更详细的信息来分析根本原因，最后在必要时采取强制措施，平时多在自己的测试环境练习使用这些命令，等到真正出现问题的时候，你就能做到心中有数，快速反应了。