当事情变得棘手时,DB2 LUW 工具可用于诊断问题

当事情变得棘手时,DB2 LUW 工具可用于诊断问题

我不是 DBA,而且对于 DB2 来说还是个新手,因此对于这个问题,即使是“显而易见”的答案也欢迎提出:

我喜欢 db2top,但有时如果 db2 LUW 上的平均负载很高,我就无法让它运行。

今天早上,我正在查看一个问题,其中平均负载突然上升,我无法让 db2top 启动,我需要找出发生了什么。

在这种情况下,我该怎么做才能找出谁在做什么?我怀疑有人在运行一个非常糟糕的查询...在这种情况下,有没有一种好的方法可以即时找到有关性能不佳的 SQL 的信息?

如果平均负载如此之高,是否有任何好的方法可以收集良好、可操作的统计数据,了解坏 SQL 来自谁/哪里?我知道 db2pd,但我不知道如何有效地使用它,而且费力地浏览数万行原始数据可能不是找到问题核心的最有效方法。

有什么提示或资源吗?

答案1

我也不是 DB2 粉。但我的 Google 功夫很强。正在搜索

force db2 LUW long running query

找到大量优秀数据,其中包括一个看起来正是您想要的数据,以及一个关于如何学习的精心编写的教程:

http://www.dbisoftware.com/blog/db2_performance.php?id=122

他们还出售一些价格高得离谱的软件,它们也能为你做同样的事情。以下是一些有趣的内容:

db2 "list applications show detail"

这将提示您哪些连接当前正在执行,以及是否有多个连接处于锁定等待状态。

如果您观察到锁等待,则接下来应该使用以下命令深入研究锁争用:

db2 "get snapshot for locks on DBNAME"

此详细报告将显示哪些应用程序连接正在持有锁以及哪些正在等待。更糟糕的是,一些正在等待的连接可能还有其他连接正在等待它们。如果您将 LOCKTIMEOUT 设置为 -1(无穷大,永不超时)或设置高于 30 秒,则可能会产生真正的滚雪球效应。

在发生锁争用的情况下,补救措施通常是使用以下命令来解决问题:

db2 "force application (application-handle) "

相关内容