无法称之为SQL监控的问题，无法证实之SQL优化

对于SQL，我们一般讲SQL审计、SQL优化，很少讲SQL监控。确实，SQL很难监控，因为在一个复杂的系统中，每天的SQL执行次数高达几千万，甚至上百亿，不同的SQL执行次数可能高达几万或数十万。如果大量 SQL 是动态生成的或不使用绑定变量的，那么几分钟内可能会执行数以万计的不同 SQL。

在这种情况下，如果我们需要开发一个通用的SQL监控产品是非常困难的。当然，如果我们的业务系统比较稳定，需要监控的SQL数量比较稳定，那么对这些SQL进行针对性的监控就比较容易了。事实上，对于大多数企业来说，我们需要监控的数据库系统有成百上千个oracle 数据库设计软件，业务系统也在不断变化。在这种环境下，确实很难实现一般的 SQL 监控。.

对于DBA来说，对SQL语句的监控也会有一定的要求，也会掌握一些SQL语句的监控和分析技巧。对于Oracle数据库的DBA，我们非常习惯通过AWR上报的TOP SQL相关内容来分析SQL的运行情况，发现有问题的SQL。但是，这种分析只能算是SQL优化，不能称为SQL监控。

今天，我们来讨论一下SQL监控的问题。随着硬件、云平台、数据库技术和应用架构的不断优化和演进，由硬件资源或数据库配置引起的数据库问题占比相对较小，而由于SQL运维引起的问题占比越来越大部分。SQL的监控需求一直存在，需求的种类也五花八门。前段时间有个客户想知道某条SQL在一定时间内的具体执行次数，问我们D-SMART是否支持。另一位客户问我D-SMART是否支持跟踪任何SQL的执行计划的变化，发现问题及时报警。

其实SQL监控的目的还是为了及时发现系统中可能存在的风险。我和我的第一个朋友谈过为什么他需要如此精确的监控，但他说不出为什么。事实上，这个要求最好从应用的角度来完成。通过应用系统的模块中的钩子进行统计的成本是最低的，从数据库做的成本可能太高了。如果我们要从数据库的角度进行统计，准确率会大大降低，因为存储在数据库内存中的SQL统计数据是不完整的，所以我们去采样的时候会出现错误。当某条 SQL 有一段时间没有执行时，很可能会从内存统计缓冲区中清除，而下一次它再次出现可能会从头开始计算。目前，我们的TOP SQL采集工作也是每5分钟进行一次，对这段时间比较活跃的SQL进行统计。因为大型系统中的SQL量可能非常大，为了避免生产系统负载过大，这个收集也必须是轻量级的，只收集一些非常重要的TOP SQL的细节。

至于第二个需求，如果要跟踪全量SQL的执行计划，那肯定是不现实的。如果系统中有几万条SQL，几十万条执行计划，收集一次的成本太高了。对于一些高并发和业务对SQL执行延迟稳定性有要求的系统，是难以承受的。

Oracle数据库的SQL语句存储在共享内存的CURSOR结构中，而很多开源和国内的数据库并没有使用全局共享CURSOR的方式，CURSOR只在会话内共享。因此，收集 SQL 语句和执行计划之间的接口不是很完整，有些数据库甚至需要启用一些特殊的跟踪功能来实现这一点。对于不同的数据库产品，我们需要采取不同的手段来收集TOP SQLoracle 数据库设计软件，所以SQL监控的实现还是需要精心设计的。

还有一点，我们SQL监控的目的不是SQL监控本身，SQL监控的目的是防止SQL异常，导致数据库系统出现问题。因此，我们不能将SQL监控作为最初的目标，而将SQL监控作为一种手段和方法。因此，在一个系统中，监控某条SQL在一定时间内的确切执行次数在大多数场景下是没有意义的。我们只需要知道某些可能影响系统的 SQL 语句的大概执行次数，以及每次执行的平均执行次数。开销以及执行次数和开销的历史波动，足以支撑我们需要的运维分析场景。

如果某条SQL语句的执行计划发生了变化，如果它的执行成本没有增加，并且对数据库的稳定运行没有太大影响，那么我们不需要实时检测这个变化，只要定期审计有一些变化，足以发现和分析其​​潜在风险。并且因为执行计划的改变，导致系统负载过高，导致系统性能下降，所以我们也可以从其他方面观察。我们可以使用数据库可观察性的一些其他方面来发现此类问题。比如我们可以观察到整个系统的逻辑读/物理突然增加，CPU使用率的增加，活跃会话数的增加等等。相对容易观察，并且由于SQL执行计划的变化，也可以找到监控成本相对较低的可观察性指标。通过分析定位，可以很快发现是因为SQL不好导致的问题，问题是因为SQL执行计划不好导致的。那么我们就可以解决这个问题了。

例如，在D-SMART中，使用了两种方法来查找相关问题，例如关键SQL平均逻辑读突发和每秒逻辑读次数超过正常水平。让我们来看看D-SMART是如何分析这个问题的，并以临界SQL平均逻辑读取突然增加的警报来分析这个问题。

从 SQL 的历史分析来看，确实存在每个逻辑读突变的平均值。我们来看看SQL执行计划，看看是否有多个执行计划。

从分析来看，确实存在两个不同的子游标，一个游标的执行成本明显大于另一个。正是因为这个问题，才出现了刚才的警报。这种方法是针对关键 SQL 的，也就是系统中对应用可用性或 SLA 有关键影响的 SQL，我们可以在每个采样周期对其进行监控。因为一个系统中关键SQL的数量不是很大，所以这种特殊监控的成本并不高。

而如果问题不是关键SQL，而是任何一个SQL，突然因为统计信息不准确或者表数据量发生变化，或者系统变化后应用出现bug，导致执行计划发生变化. ，进而导致系统资源不足，导致关键SQL因系统资源（内存、CPU、IO等）不足而导致性能问题。这种情况也很常见。如果这个 SQL 问题没有触发系统资源不足，导致核心业务失败，那么这个问题不一定需要立即发现并处理。

只要在定期 SQL 审计（比如每周）中发现这个问题，它就可以完全解决。如果比较严重，可能会导致系统故障，那么我们还是要尽早发现此类问题。在 D-SMART 中，我们针对逻辑读突发、物理读突发、R 队列突发、活跃会话突发、同一条 SQL 并发执行达到一定阈值（此类 SQL 执行计划必须在执行计划异常后执行）。如果时间过长，如果对系统影响很大，大概率会同时执行多条SQL）等，会产生告警。并且在这些告警中，可以有执行计划变化的诊断路径，可用于根因追踪。这样，