诊断耗用 CPU 时间较长的 SQL 语句的问题

指示性的信号

• 当查询小型热表或者热表参与连接，但是没有合适的索引时，在缓冲池中频繁运行表扫描会耗用相当多的 CPU 时间。包括下列信号：
  • 语句执行时间相对较短
  • 耗用的用户 CPU 时间等于执行时间
  • 在说明方案中存在关系扫描
  • db2pd -tcbstats 中的扫描次数不断上升
  • 该语句的缓冲池物理数据读取次数较少
  • 数据库快照中“读取的行数”快速增加。
  尽管通常不会认为此类型的语句导致瓶颈，但是，频繁执行和耗用 CPU 时间较长会使此类型的语句成为问题。
• 如果 SQL 语句仅使用所生成的一小部分行，那么在该 SQL 语句中不使用 OPTIMIZE FOR n ROWS 或者 FETCH FIRST n ROWS 子句可能会导致耗用 CPU 时间较长。
• 使用从文化角度而言正确的整理顺序和 Unicode 代码页会产生大量开销，尤其是耗用 CPU 时间。
• 通常，只根据冲突和等待时间来考虑锁定问题。但是，即使在冲突很少甚至完全没有冲突的情况下，获取锁定和释放锁定的过程也会耗用大量 CPU 时间。请考虑下面这种情况：应用程序或语句需要检查一个表中的许多行，但是由于此应用程序或语句单独运行，因此只产生很少的锁定冲突；单独运行的原因是它对所引用的表进行互斥访问，也可能是因为所有并发应用程序都仅以只读方式使用该表。

注： 如果单个 SQL 语句似乎未耗用大量 CPU 周期，那么更广泛的潜在问题可能会导致 CPU 使用率总体上升。

要监视的内容

检查从数据库和操作系统收集的信息，以获取先前提到的指示性信号。

• 通过事件监视器或者利用表函数来检查下列监视元素：
  • total_cpu_time
  • cputime_threshold_violated

如果您观察到所列示的一个或多个指示性信号，那么您很有可能遇到有关耗用 CPU 时间较长的 SQL 语句的问题。请遵循“下一步做什么”一节中的链接来解决此问题。