当谈到DB2时，我不是DBA，也不是新手，所以即使是“明显”的答案，也欢迎这个问题：
我喜欢db2top，但有时如果db2 LUW上的负载平均值很高，我不能运行它。
今天早上我看到的是一个平均负载突然上升的问题，我不能得到db2top，我需要找出发生了什么事情。
我能做些什么来找出谁在这种情况下做什么？ 我怀疑一个可怕的糟糕的查询是由某个人运行的…有没有一种很好的方式来在这种情况下在运行中发现性能差的SQL的信息？
有没有什么好的方法来收集好的，可操作的统计信息谁负载平均值如此之高的事件？ 我知道db2pd，但是我不确定如何有效地使用它，并且通过成千上万行的原始数据闯入可能不是解决问题的核心的最有效方式。
任何提示或资源？
我也不是DB2的人。 但是我的小福很强。 寻找
force db2 LUW long running query find很好的数据，包括一个看起来像你想要的东西，一个关于如何学习的书面教程：
http://www.dbisoftware.com/blog/db2_performance.php?id=122
他们还出售一些疯狂高价的软件，为你做同样的事情。 这里是多汁的一点：
db2 "list applications show detail"
这将提示您当前正在执行哪些连接以及是否有多个处于locking等待状态的连接。
如果观察到locking等待，则应该使用以下命令深入研究locking争用：
db2 "get snapshot for locks on DBNAME"
这个详细的报告将显示哪些应用程序连接持有锁，哪些正在等待。 更为重要的是，一些正在等待的连接可能有其他连接在等待。 如果将LOCKTIMEOUT设置为-1（无穷大，从不超时）或设置为高于30秒，则可能会出现真正的雪球效应。
在争用的情况下，你的补救措施通常包括用命令杀死大象：
db2 "force application (application-handle) "