由于多种原因,耗用 CPU 时间较长的 SQL 语句偶尔会耗用大量的用户方式 CPU 时间。高使用率可能会导致处理器瓶颈,还会导致 SQL 查询性能下降。
关于此任务
- 诊断
- 有时,个别 SQL 语句可能会耗用大量的用户方式 CPU 时间,这可能由许多情况引起。您无法始终减少 SQL 语句耗用的 CPU 时间量,但是在某些情况下您可以影响此时间量。
- 指示性的信号
- 当查询小型热表或者热表参与连接,但是没有合适的索引时,在缓冲池中频繁运行表扫描会耗用相当多的 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 语句的问题。请遵循“下一步做什么”一节中的链接来解决此问题。
开始之前
为了能够有针对性地评估系统行为是否不正常,您必须要有描述了系统典型行为(基线)的信息。然后,可以将您观察到的可疑异常行为与基线进行比较。通过安排定期的运作监视任务来收集基线数据是故障诊断过程的关键组成部分。有关确定系统的基线操作的更详细信息,请参阅对系统性能进行运作监视。
下一步做什么
在诊断耗用 CPU 时间较长的 SQL 语句很有可能导致您所遇到的问题之后,请通过以下链接来获取有关您可以用来解决此问题的步骤的信息:解决有关耗用 CPU 时间较长的 SQL 语句的问题