善用性能工具进行SQL整体优化

Posted 2022-12-03 街角幸福

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了善用性能工具进行SQL整体优化相关的知识，希望对你有一定的参考价值。

SQL优化是一个复杂的工程，首先要讲究从整体到局部。今天我们首先学习关于数据库整体优化都有哪些性能工具，接着分析这些工具的特点，并结合案例进行探索，最后再进行总结和思考。

总体学习思路如下图所示：

都有哪些性能工具

这里首先要分成两部分：一种是不同调优场景的分析，可分为单纯场景的优化和复杂场景的优化；而另一种是基于这些场景的工具应用，就是针对单纯场景的优化手段和复杂场景的优化手段。

1、不同调优场景分析

我们继续探讨，单纯是有多单纯呢？哦，其实可以理解为无菌真空实验室里的实验。比如一条SQL很慢，原因是未走高效的索引查询而走全表扫描，加个索引就快了，执行速度从10s变成了0.1s；或者一条SQL执行速度被优化到1s左右，逻辑读控制在50个左右，应该就已经OK。这就是单纯的环境，我们差不多无须再考虑优化了。

那啥是复杂呢？那就是，刚才那个语句加了索引后，本应该从10s变成0.1s，结果还是10s，甚至变成30s了，这是咋回事呢？原来，现在系统是整体出问题了，数据库主机资源耗尽，啥语句都跑不快的。

还有那个逻辑读在50左右的SQL，如果一天执行几百几千万次，这要是能将逻辑读降低一点，得省多少的逻辑读啊。原来复杂环境真的很复杂，要考虑SQL本身没问题而是被环境影响，还要考虑SQL的执行频率，判断其调优价值与调优空间，这些在单纯的环境里，是不用考虑的。

2、不同场景对应工具

接下来，我们说说这两种场景对应的工具的使用。关于局部分析调优工具，这个其实就是在说SQL的执行计划了，这是SQL优化最重要的手段之一，通过分析执行计划，我们可以知道SQL语句的访问路径，知道它慢在哪里，从而进行SQL优化。由于在随后的章节中我们会详细介绍执行计划相关知识，这里就不再细述了。

关于整体的调优工具，这里我们先撇开主机、网络、存储等层面的因素，暂时从数据库的整体层面入手。主要工具有AWR、ASH、ADDM、AWRDD这四个工具。其中AWR是关注数据库的整体性能的报告；ASH是数据库中的等待事件与哪些SQL具体对应的报告；ADDM是Oracle给出的一些建议；而AWRDD是Oracle针对不同时段的性能的一个比对报告，比如今天早上9点系统很慢，而昨天这个时候很正常，很多人就想知道今天早上9点和昨天早上9点有什么不同，于是就有了这个报告。

整体分析调优是必需的，那么我们对此的学习也有规律可循。首先是获取系统整体信息的手段，一般通过报告和日志获取。好比破案一样，这就是收集证据的阶段。接下来要找到蛛丝马迹，那就是如何发现问题。在本书中就是需要关注提取到的这些报告的哪些要点、哪些关键字，具体流程图如下：

整体性能工具的要点

现代人对健康都比较重视，每年都会进行健康体检。其实数据库性能工具的应用（报告获取和关注要点）和体检是非常类似的。

1. 报告的获取

Oracle性能报告分成AWR、ASH、ADDM、AWRDD和AWRSQRPT这5个类型。

什么？这么多，好复杂啊，记也记不住，我不想听不想听！

别急，你只要去医院体检过，你就能听懂。

Really?

我们去医院体检，最终会得到一份体检报告，往往能看到很多总体性指标，这些指标会判断你是否健康。没毛病最好，万一有毛病，报告里要进一步判断是什么毛病，是高血压，还是骨质增生，还是胃有毛病……这就是现实中的体检报告。

而Oracle提供的一种性能收集和分析工具，它能提供一个时间段内整个系统资源使用情况的报告，这个报告里有很多总体性指标来判断系统是否健康。没毛病最好，万一有毛病，问题出在什么模块，是日志切换过于频繁，还是硬解析过大，还是某些SQL相关等待事件在耗资源……这就是AWR报告。这样看来，体检报告和AWR报告非常类似。

假设体检报告说你有胃病，很可能只告诉你胃有问题，却无法告诉你具体啥毛病，因为你手上的体检报告不会详细到拥有你胃部所有相关指标。你要得到这些指标需要做进一步信息收集，那就是胃镜。同样假设你的数据库是SQL相关等待事件问题，AWR报告很可能只告诉你有这个问题而无法告诉你是哪些SQL引发的。你要得到这些指标，想了解具体某些SQL和相关等待事件的对应需要做进一步的信息收集，那就是ASH报告。看来对比胃镜和ASH报告，二者也非常类似。

刚才说的胃病，或许是医生告诉你的，因为上面有很多指标你无法读懂，这时如果你能拿到一张医生的病历卡记录，这里没有指标，只有白底黑字用文字描述的病情，告诉你要如何治疗，那你一定会看得很明白。同样假设，如果将含各种晦涩的指标的数据库体检报告用一些白底黑字的文字代替，用文字直接说明数据库遇到了什么问题，告诉你该如何去优化，那新手一定会看得很明白，这就是ADDM报告。看来病历卡记录和ADDM报告，二者也非常类似。

假如你在一年前也做过体检，并将报告带到了医院，负责任的医生就一定会让你将旧的体检报告也提供给他。他会认真地比对两张报告，查看他关注的健康指标是否有异常波动，这些波动对医生很有参考意义，往往预示着病情的发展趋势。好了，别紧张，这只是比喻。

假设你有系统新旧两个时段的两份AWR报告，负责任的DBA一定会让你将旧的AWR报告也提供给他。他会认真地比对两份报告，查看他关注的数据库指标是否有异常波动，这些波动对DBA很有参考意义，往往预示着数据库性能瓶颈的发展趋势。Oracle提供了一个工具能够将两个时段的AWR报告合并，并能方便地显示出比对信息，这个工具就是AWRDD。看来医生分析前后两次体检报告的动作和AWRDD报告比起来，两者也非常类似。

大家知道做胃镜是一件很麻烦的事(类似ASH报告)，如果没毛病就没必要让我们遭这罪。可万一体检报告无情地告诉你胃有毛病，甚至是医生分析你前后两次体检报告（类似ADDM）后告诉你胃病在加速中，你被迫无奈只好去做胃镜了。做完后医生发现你胃部有大量息肉，却无法判断这些息肉是否为良性。于是还要做进一步的检查，这就是活检。不要紧张，平时注意健康生活就好。同样ASH报告判断出某些SQL有问题，却无法得到执行计划等更详细的信息，只能依靠AWRSQRPT去获取这些信息。看来活检和AWRSQRPT报告比起来，两者也非常类似。

最后恭喜你，活检报告显示未产生癌变，只要好好治疗，注意身体，胃就能恢复健康！看本书的读者们，你们都是IT人士，生活无规律加班熬夜者居多，一定要注意身体哦！

对了，还有一件最重要的事没交代。大家似乎搞懂了Oracle五大性能报告，可是这些好东西在哪里才能得到呢？别着急，后续章节马上就会告诉你如何获取这五大性能报告。

2. 报告的关注点

如果患者拿着有各种晦涩指标的体检报告来到门诊请教医生，他一定会关注各种指标来判断患者具体是什么毛病。同样你也会对Oracle的性能报告中的各种指标进行关注来判断数据库出了什么毛病。两者非常类似，关注不同的指标，都是为了施救，前者救人，后者救数据库。

听起来是不是很激动，恨不得马上就要开始当救库英雄了！别急，接下来还要告诉你关注什么，然后在案例中让你感受一下什么叫救库英雄。

特别提醒：

这里有一个特别值得注意的地方，那就是性能报告的采样时间。Oracle默认是每小时产生一个采样点，你可以收集每个小时的性能报告。我们对此要敏感，比如你的性能故障是发生在今天早上7点～8点。然后系统自动恢复了，你获取一张8点～9点的性能报告来查问题，就毫无意义了。

3、五大性能报告的获取1AWR的获取与说明

获取AWR报告的方式有两种：一种是直接获取方式，调后台脚本awrrpt.sql来获取，执行方式一般是在sqlplus下执行@?/rdbms/admin/awrrpt.sql；

另一种则是通过调用命令包，获取dbms_workload_repository这个包的awr_report_html程序，用SQL命令的形式输出内容。

Select output from table(dbms_workload_repository.awr_report_html

(v_dbid, v_instance_number,v_min_snap_id,v_max_snap_id))

（1）直接获取

试验1（未使用批量提交）：

接下来通过提示就可以生成AWR报告了，具体步骤略去，详情请扫本章最后的二维码。

试验2（单机下，正确使用批量提交）：

接下来通过提示就可以生成awr报告了，具体步骤略去。

（2）通过调用命令包获取

直接调用工具包的方式，特别适合用在程序自动获取报告的场景。

注：其中977587123是数据库的主机标识，可以在数据库的数据字典中查到，1是标识实例，如果是RAC，就有1和2两个，单机就只有1。1920和1921是两个断点时间，比如9点和10点之间。

2ASH的获取与说明

获取ASH报告的方式也有两种：一种是直接获取方式，调后台脚本ashrpt.sql来获取，执行方式一般是在sqlplus下执行@?/rdbms/admin/ashrpt.sql；另一种则是通过调用命令包，获取dbms_workload_repository这个包的ash_report_html程序。用SQL命令的形式输出内容。

select output from table(dbms_workload_

repository.ash_report_html( dbid,inst_num,l_btime,l_etime)

（1）直接获取

说明：

如果你是一路回车，就是获取最近5分钟的ASH报告。
如果你根据Oldest ASH sample available 时间，然后回车，选择的是目前可收集的最长ASH运行情况。
你可以选择Oldest ASH sample available和Latest ASH sample available之间时间，然后输入时长，比如30表示30分钟，取你要取的任何时段的ASH报告。
ASH报告的获取不同于AWR的地方在于，快照之间有无重启动作不影响报告的获取。
ASH报告可以直接手工获取，比如select output from table(dbms_workload_ repository.ash_report_html( dbid,inst_num,l_btime,l_etime)。

（2）通过调用命令包获取

直接调用工具包的方式，特别适合用在程序自动获取报告的场景。

注：其中977587123是数据库的主机标识，可以在数据库的数据字典中查到，1是标识实例，如果是RAC，就有1和2两个，单机就只有1。SYSDATE-30/1440,SYSDATE-1/1440 分别是开始时间和结束时间。

3ADDM的获取与说明

获取ADDM报告的方式也有两种，一种是直接获取方式：调后台脚本addmrpt.sql来获取，执行方式一般是在sqlplus下执行@?/rdbms/admin/addmrpt.sql。另一种则是通过调用命令包的方式获取：调用dbms_workload_repository这个包的addm_report_html程序。用SQL命令的形式输出内容。

- Create an ADDM task.

DBMS_ADVISOR.create_task (

advisor_name => 'ADDM',

task_name => 'MYADDM',

task_desc => 'MYADDM');

（1）直接获取

@?/rdbms/admin/addmrpt.sql

具体执行过程略去。

（2）通过调用命令包获取

注：直接调用工具包的方式，适合用在自动获取报告的场景。

4AWRDD的获取与说明

获取AWRDD报告一般是用直接获取的方式，这个脚本的交互部分需要输入要进行对比的两个awr报告的begin snap_id与end snap_id，然后输入对比结果报告的名称，这里就不详细介绍了，请读者自行试验完成。

直接获取：

@?/rdbms/admin/awrddrpt.sql

具体略去。

5AWRSQ获取与说明

获取AWRSQRPT报告的关键之处在于，交互部分要输入所要分析的SQL的SQL_ID，这是关键之处。而这个SQL_ID可以从AWR报告中获取。

以上5个报告的获取本身并不难，操作一遍就会了，笔者也会再提供在线操作视频，让大家实际体会一遍。现在关键在于，要明白这5个报告的作用和相互之间的区别，搞懂这些，调优之路就算完成过半了。当然，接下来如何分析读懂这五大报告的关键指标就非常重要了，有一些指标你必须关注，否则你就当不了“医生”了。

4、五大报告关注的要点1AWR的关注点

AWR报告是五大报告中最全面最重要的一个报告，它的相关指标也显得格外重要。这里我们列出DB Time、load_profile、efficiency percentages、top 5 events、SQL Statistics、Segment_statistics这6个指标入手分析。

（1）AWR关注点1之DB Time

DB Time这个指标主要用来判断当前系统有没有遇到相关瓶颈，是否较为繁忙导致等待时长很长。一般来说，Elapsed时间乘以CPU个数的时间如果结果大于DB Time，我们认为系统压力不大，反之则压力较大。如下例子中，60.11×64=3847.04<5990.6，说明系统现在还是比较繁忙的。

（2）AWR关注点2之load_profile

load_profile这个指标主要用来展现当前系统的一些指示性能的总体参数，比如经典的Redo size就是用来显示平均每秒的日志尺寸和平均每个事务的日志尺寸，结合Transactions这个每秒事务数的指标，就可以分析出当前事务的繁忙程度。

下图中显示每秒有6777.1个事务数，这在现实中几乎不可能，现实中的运营商系统一般在200上下比较正常，超过1000就属于非常繁忙了。

把上图和下面的图进行比较，就非常明显了，下图显示每秒有0.6个事务，平均每个事务产生的日志尺寸是7位数。这说明系统是一个提交不频繁的处理大任务事件的系统。而上图的尺寸是3位数。这里非常容易看出，这是一个提交非常频繁且每个事务都非常小的密集提交系统。

（3）AWR关注点3之efficiency percentages

efficiency percentages是一些命中率指标，其中Buffer Hit、Library Hit等都表示SGA（System global area）的命中率。在下图中Soft Parse指标表示共享池的软解析率，在OLTP系统中如果该指标低于90%应当引起你的注意，这表示存在未使用绑定变量的情况。我们通过比对两个报告，可以看出明显差异，如下面系列图所示。

报告1（未有效地使用绑定变量，产生大量硬解析的场景）。