DB性能瓶颈分析思路

  在性能分析过程中,经常遇到性能瓶颈出现在SQL的情况,此类问题通常可以分为两大类场景,一是SQL自身性能差导致的慢,如索引缺失、索引失效、统计信息不准确、SQL过于复杂等;二是由于外部原因等待导致的SQL执行慢,如某些系统资源导致的等待、数据资源争用导致的会话阻塞等。

  对于SQL慢的情况,通常可以采用会话跟踪+单独执行验证的方式进行分析。单独执行也就是将慢的SQL拿到plsql、ssms等客户端工具执行看其响应情况;会话跟踪即在SQL执行过程中使用DBSQLMonitor工具跟踪数据库会话,查看SQL执行时段的会话状态及等待类型。

跟踪思路:

(1)问题跟踪

开启DBSQLMonitor,设置跟踪所有会话,监控时间间隔5s,如果目标SQL单次执行耗时较短,可以通过缩短监控时间间隔或多次验证方式进行跟踪。

此处以DBSQLMonitor为例进行示例。对于无法使用DBSQLMonitor工具的环境,在问题跟踪过程中,通过多次手动查询DB会话也可以实现相同目的。

(2)问题分析

对于SQL慢的情况,只需关注running/active状态的会话即可,因此,可以直接过滤status状态为active,并选择执行SQL相关的进程名称。然后查找关注的SQLText即可。

DB性能瓶颈分析思路

 

  找到目标SQL对应的会话之后,检查会话状态即日志中的Blocked列,如果blocked列为0的话,表示当前会话未被阻塞;blocked列不为0,则表示当前会话被blocked列所示值的会话阻塞,如此依次查找直至找到阻塞其他会话,且自身未被其他会话阻塞的即为阻塞源。找到阻塞源后,进一步检查阻塞源会话状态,如果阻塞源会话为running/active等执行中状态,则表示阻塞源会话相关SQL执行慢导致,后续需进一步分析阻塞源SQL慢的原因;如果阻塞源会话为sleeping/Inactive等空闲状态,则表示阻塞源会话SQL已经执行完,但是其所在事务未提交,后续需从事务角度检查是否存在事务未提交等问题。

  如果目标SQL对应的会话未被阻塞,则需要结合等待类型进一步分析,会话等待类型对应会话日志中对应的是lastWaittype列。由于每种数据库等待类型较多,此处不再详细列举,可以直接复制等待类型,查询相关类型含义即可。

(3)SQL优化

         针对(2)分析结论,如果涉及资源瓶颈或数据库配置导致的SQL执行慢,则联系客户或数据库运维团队协助处理即可。

         对于SQL自身性能差导致的执行慢的场景,则可以检查下索引是否完整、有效、统计信息是否过旧等。如通过索引等手段优化无效,则建议考虑对SQL进行等价改写,降低SQL复杂度。

 DB性能瓶颈分析思路

 

常见数据库会话查询脚本:https://www.cnblogs.com/wang-xiaohui/p/14613312.html

 

DB性能瓶颈分析思路

上一篇:Python-MySql


下一篇:[Oracle工程师手记] 备份恢复双城记(一)