oracle 自动调优任务哪里查看

大家好，我是雅善的技术支持工程师黄正勋，是有二十年 oracle 数据库 s q l。 调优工作经验的 d b a。 当我进行数据库性能改善相关项目的时候，经常会遇到这样的问题， s q l。 调优是什么？通过调优能得到什么好处？ 在我看来， s q l。 调优是充分理解调优对象的 s q l， 仔细研究 s q l。 内在信息和逻辑需求，然后提供获取这些需求的最佳方法。最终， s q l。 调优可以提高应用程序的响应时间， 减少数据库资源使用量，从而提高客户满意度，并减少 it 相关的投资。 在后面的一段时间，我计划通过如何确认问题、避免问题、解决问题 三个方面梳理 s q l。 调油相关的技术，希望能给想要学习 s q l。 调油的各位提供一些帮助。今天我们将讨论如何确认问题的。第一章，选择 s q l。 调油的对象的第一部分选择对象的重要性 选择调油对象是调油工作的第一步，如果出现错误，后续工作可能无法达到预期效果，也可能导致更严重的后果。 为了选择正确的调优对象，您需要了解数据库业务环境以及出现的性能问题，并且熟练掌握获取相关信息的工具的使用原理和方法。 首先要确定调优的目的。如果业务上已经有特定的调优需求，或者需要针对数据库的特定情况进行调优时， 选择调优的 s q l 要与需求有强关联，比如某个 s q l 特别慢，或者 c p u 和 i o 资源紧张，或者有大量无法共享的 literal s q l， 这些都是特定的调优需求， 如果没有特定要求的话，一般把重点放在提高数据库整体性能或者处理执行时间比较长的 top s q l。 我们看一下调油对象选择错误的一些案例，比如客户反映数据库系统 cpu 使用量很高，达到了百分之八十左右。针对这个项目，调油工程师需要做的第一步， 选择调优对象时，需要根据数据库系统 cpu 占用时间的 top s q l 作为基准，而不能选择执行时间长。逻辑 艾欧高全表读取的 sql 或者物理艾欧高的 sql 作为基准。如果我们通过上面的 sql 语句，根据平均执行时间长作为基准， 靠排序获取对象 sql 后，通过大量努力减少了 sql 的执行时间，但是数据库 cpu 资源使用量没有明显的变化。 虽然我们调优的是执行时间很长的性能问题 sql， 但由于执行次数很少，对整体数据库的 cpu 资源影响其实是很小的，不是说执行时间减少对 cpu 使用量完全没有影响， 但是作为降低 cpu 使用量为目标的调油对象是不恰当的，也就是没有达到预期的效果。我们调整一下排序条件，通过 cpu 占用率做 为基准进行排序，得出调优对象。进行调优后， cpu 使用量从百分之八十下降到百分之五十以内，达到了预期的调优目标。调优对象越明确，调优失误的可能性越少， 因此这个第一步骤是非常重要的。那么要选择正确的调优对象需要哪些信息和工具呢？最有效的方法是与了解业务和需求的客户担当进行沟通以获取调优对象，这样可以针对性的进行调优，以达到最理想的结果。 但是这个方法在现实案例中通常是很难实现的。调油工程师通常使用 oracle 数据字典视图来分析当前系统的整体性能情况以及业务的特性。我们还可以使用专门的性能管理解决方案，例如 max gauge 软件来确认调优的对象。现在讨论一下选择 sql 调优对象的具体方法。根据不同的需求需要使用不同的方法获取调优对象。这里列出来的七种是比较常用的选择调优对象的基准， 下面会对每项进行详细讲解。首先是最常用的根据 io 和 cpu 资源或者执行时间作为选择对象的基准， 需要使用 dba hist sql stat 视图，通过 buffer gets cpu time 或者 elapsed time 作为排序基准，选择需要调优的对象， 比如通过 cpu raise 有道序来获取占用 cpu 资源最多的 sql。 下面看一下这个方法的案例。案例画面中， 上面的是三月二十三日的 cpu 使用量，下面是第二天三月二十四日的 cpu 使用量，可以明显看出二十四日相比二十三日 cpu 使用量很高， 这是通过 cpu ratio 道序获取的三月二十三日的 top sql， 这是三月二十四日的 top sql， 可以看出二十四日 top sql 当中前面两个 sql 在二十三日是没有出现过的， 因此可以分析出新出现的两个 s q l 是这次性能问题的主要原因，可能是新开发的业务， 也可能是由于执行计划变更导致的性能问题，不管是什么原因，都可以通过之前的 sql 找到调优对象。现在讲一下全表读取相关的调优对象选择方法。 全表读取的问题主要原因是没有恰当的缩影策略，大部分是应用开发初期，表数据量很少，没有造成性能问题，但随着数据增加，全表读取产生严重的性能问题。 如果看到全表读取，就说是有性能问题，也是错误的想法。有些时候调油工程师会有意引导使用全表读取来达到性能提升， 这部分会在后续进行详细讨论。全表读取往往会导致大量物理读取，而物理读取的性能相比逻辑读取要慢很多。所以当数据库系统的物理读取 io 很高时， 需要找到全表读取的 s q l 对象，可以通过上面的 s q l 来获取。全表读取的 s q l 对象需要使用 v dollar s q l area 和 v dollar s q l plan 视图。最核心的是通过 v dollar s q l plan 视图中 operation 字段等于 table， excess 和 option 字段等于 full 来查询执行计划中存在全表读取的 s q l。 我们看一下案例，案例中，在开发阶段，由于 big table 数据量只有五千行，所以就算进行了全表读取，但也只是读取了十四个 block， 所以就算执行次数很多，也不会出现在 top s q l 当中，所以很容易被忽视。 后来数据的持续增加，导致全表读取需要两万五千个 block， 执行时间也超过了四秒，也就是这个表的数据量已经增加到了影响性能的程度， 这就需要考虑锁影的必要性了。当然，添加锁影还需要考虑表大小和 where 条件字段，以及是否会影响其他业务的 s q l 语句。但单独这个 s q l 来说，由于 c 四字段作为 where 的条件， 而且 selectivity 也很好，所以添加锁引后，相同的 s q l 只需要读取四个 block 就很快得出结果了，既减少物理读取 i o， 也提升了执行速度。 下一个是 literal s q l 导致的性能问题。上面三个 s q l 中， e m p n o 字段可能是不同的常量或者变量， 其实是相同逻辑的 sql 语句，也就是通过第三个绑定变量的方式，可以包含所有相同逻辑的 sql。 第一个和第二个没有 使用绑定变量的 s q l 就是 literal s q l。 literal s q l 的性能问题在于，当用常量来复制时， 每个不同常量负值的 s q l 都要进行硬解析，而且占用独立的 library cash 内存空间。为了防止这个问题，我们需要做的是找出相同逻辑但是常量复值的 literal s q l， 然后使用绑定变量来重新编写 s q l 语句。 查找 literal s q l 的方法如上，这里重要的是通过 v dollar s q l area the force matching signature 和 exact matching signature 字段， 需要找出这两个字段的值不一样的 s q l， 然后通过 force matching signature 进行 group by， 在 having 中找出 exact matching signature 的个数大于等于二的条件，得出的就是 literal s q l 的 s q l 列表 表了。如果没有做 force matching signature 的 group by， 也就是没有处理 literal sql 的话，得到的 top sql 是上面的结果，其中 top ten 其实都是相同逻辑的 sql， 这样是无法准确分析。实际上的 top sql 影响性能程度 只有经过 group by 处理 literal s， q l 以后才能看到。前三个 literal s， q l 不仅占用大量 c p u 资源，而且执行次数也是非常多的，每次执行需要执行一次应解析，对这些 literal s， q l 进行绑定变量处理， 这样可以大大降低硬解析的负荷，并且减少共享内存中 library cash 的使用量和竞争。

大家好，我是杨老师，同时也是企业 it 运为建设者。 前段时间给大家分享过波尔古数据库 awr 报告，他的一个分析这一块 主要讲的是他可以分析数据库的一些性能问题，也能分析一些硬件等等相关的问题，还有一些耗时的 c 款女据啊，可以分析好多这一块的问题。但是呢，之前是不讲分析的一些案例 啊，有人说，一般你要分析了上千份的数据库的 a 大报告，那么你的水平才能达到一个比较好的一个水平，那么通过多年啊，分析了好多的一些报告， 总结了一些经验。那么今天呢，给大家来分享一个案例啊，主要是分享一个案例就是 a 大报告啊这一块，这个案例来了解一下如何 通过一份 a 大报告来分析出数据库的信用，有的时候你会发现一条 c 口女据，就会把你整个数据库的资源耗掉，数据库给当机都不可用， 哎，那么我们怎么通过这个报告来分析呢？那么接下来大家可以随着我的这个分享，一起来听一听，看是怎么进行分析的。 接下来我给大家分享一个欧尔国数据库那个 a 大报告分析这一块， 也就是说之前我们有分析过，说过 a 大报告这一块相关的内容，说过 a 大报告他可以用来分析数据库的性能等相关的问题， 那么还有很多人觉得那一块，嗯，非常有用。那今天呢，呃，给大家分享一个案例，这是一个实际的案例， 怎么通过数据库的 awr 报告去分析数据库的性能， 从哪些点去分析啊？能够一下子就看出是哪里有问题。好，那我们开始今天的分享，就是案例的分享。 首先这就是一份 awr 报告的前面的一些内容， 在这个报告里面我们可以看到数据库的名，比如说 db 内幕，它是叫 wy esdb 数据库的 id 实力名。这个数据库开始运行的时间是二零二一年十二月七号十一点十二分，他的数据库版本是十一点二零点四，属于奥 ac 集群 这个机器的一些硬件配置， cpu 有一百四十四盒，就是带有有物理和逻辑 cpu 和数一起是 一百四十四盒，那么物理 cpu 和数是七十二盒。福星内存 memory memory 就是那个内存这一块是显示是五百零四点五二击币， 由于内存这一块他会操系统显示会少一点，他是五百一十二 g 内存。好，这是这个我们看到的这个数据库相关的一些信息， 当我们看一下对于在性能这一块怎么去分析数据库有没有问题， 那么我们是看下面，我们看到有一个叫 db time， 还有叫啊 elephant， 这这个这边的这个时间可以看到这个 a 大报告收集的时间是十一点到十八点，就是 二零二二年一月十三号的收集了七个小时，我们一般是收集有性能问题的，两个小时之内是最好的。这个报告收集的有点长，跨度范围有点长，可能会有点失真， 当我们看 dbtem 的这个时间的话，是非常长的，他用了两万七千九百二十七啊分钟，其实他七个小时是四百二十二十分钟左右哈， 我们看到 dbtem 时间非常长，说明这个数据库的负载非常高，数据库出现了严重的性能， 那么我们会通过一个公式，就是 a a s， 它是等于 dbtem 除以啊 eleventy 这个时间 是等于六十六点四倍，可见数据库的性能非常严重，一般是 a s 等于三倍左右算正常的。从这里这个里就可以看出来数据库存在严重的性能问题， 那么光这个还是不能说明数据库的性能问题在哪个地方。那我们接着再看一下拓补时的数据库的等待事件， 我们从这个事件里面看到最前面的是 event 是指事件，嗯，事件很多，比如说这里包含了嗯 derek pass 这里的啊，直接读， 还有下面的呃， db fl six show read， 就是数据文件串型读，还有控制文 文件串型读，还有 dbcpu 磁盘文件操作系统 io， 还有因为它是集群，还有 gc 八分是吧，返存这一块的获取繁忙度。还有就是在别的绘画里面读， i ll look fall as well as sense 这个字是日文件的一个同步， 还有 dp five party 的数据文件并行读，还有最后一个叫 g c current block two 位就是 g， c 就是全局， 那全局返程这边的话，他的当前快的第二种方式啊，最快的这个方式，那么我们从这里面是前面是事件，紧接着是 white 就可以事件，他的等待次数， 等待是越高，说明也比较严重，后面就有一个总的一个时间叫嗯 title weight time， 以秒为单位。再就是后面比较关键的是叫 weight a v g 是 heven g， 这个是平均等待时间， 再就是这个事件在整个时间里面占的时间比，占比百分之， db time 到后面的 weight class 就是 weight class 就是等待的事，这里就是等待的累，那就是说 the user iphone o 就是用户 io， this is team io 指的是系统 io， 还有底下的 class， 集群， come 的提交等等相关的内容。那么从这个里面我们可以看到的一些数据啊， 我们可以看到的一些数据就是平均等待的时间，平均等待的这个，呃，时间这一块平均等待时间，我们可以看到 直接读啊，这一块平均等待时间的话每次达到了二十六秒，二十六毫秒不是秒。那么维特克拉斯指的是用户 io， 下面也有好多是跟读相关的词吧。 io 的性能， 从这里可见，磁盘 io 存在问题，那么存在问题是是不是磁盘本身的问题 啊？磁盘这个性能比较差，还是因为一些耗时、塞克、铝具等导致的呢？这要后面继续看后面相关信息，这里 看到的主要是顶级事件，看完顶级事件以后我们再继续看， 前面讲到我们 io 压力比较高，那么我们现在就可以看到了，有一个叫 report summer， 就是一个报告的汇总，我们可以看叫 load profile， 这是一个张仔的概要相关内容，这里面有包含看到 cpu 时间， db 时间啊，这里第五就是从这这文件大小，这里看到是幺九八八幺六，这是一百九十八 k， 不大。 那我们看到在瑞的 io， 瑞的 io 这一块的话是一千五百零八兆，就是说明磁盘每秒读达到一千五百零八兆，相当于 一点一个 g 左右，物理毒非常高，因为是一 g 是一零二四兆，说明瓷盘毒非常高，有大量的数据在物理毒 啊，其实下面还有 rat io， 血很低，才零点六兆。好，我们再看这这个图片也是可以看出来，磁盘 io 这一块压力非常大，磁盘 io 我们要着重在磁盘 io 这一块进行分析， 那么前面讲的是物理毒，那么我们就要看到找塞克女具了，我们从物理毒这块的排序找塞克女具哪些是最高是吧， 就是那个 cico 叫啊 old by race race 是吧，就是那个 cico 排序这一块，那么 可以看到这里面好多些空军句都是叫斯莱克斯 f i d for m c t 杠下发现 g l 下发现 virtual n 球等等相关的内容，就是讲的是 跟凭证相关的二开表，在查询的时候频率非常高，很多这样的女据，但是每个女据执行一次，每次执行呢，用了在这物理读的话，读了六八七三六七个款啊，也不少了，它的量一多，那么整个这个 磁盘的 io 就压力很高，物理毒就非常高，那这样一来的话，就我们找到了问题的 c 口女锯了， 哎，我们再继续再看一下女具里面用的是哪些表啊，它是物理毒比较高，那我们看的，我们看的 就是叫，嗯 segments by， 嗯， director 叫 physical congress 啊，这就是物理读啊，物理读的段，我们可以看到， 在这个物理读的段的时候，我们可以看到对象名句，一个 c t 下发现那 g l 下发现 rachel e s p a d 这么一个表，那么这个表的直接物理读，迪瑞卡瑞斯是四三八三八零五八八五，很高了哈，这个数据是非常非常高， 拿总的物理度占比百分之九十九点八啊，可见是这张二开的表，他的这物理度非常高，那么整个这个数据库的性能慢就跟他有关，其他还有其他的几个表，那是他的占比很低，百分之零点零六啊，百分 六，百分之啊，四，是吧？是很低了，嗯， 啊，不是这个啊，不是百分之零点零六，百分之零点零四啊，这已经有个百万号了，这个是完全是不一样了。 好，这就是从这个 a 大报告我们一分析就知道这个私房用户 l 高，并不是私房 l 本身的私房的信用存储性能有问题，而是因为存在大量的二开塞口女锯，是同一个塞口女锯啊，频繁的执行，而女锯里面 可以看到啊，这个表可能会存在全苗扫描物理毒，非常非常的高。 好，我们再往前面去翻一下，那么这一块是怎么去解决呢？啊？那我们这里可以看到我这里解决的方 方法啊，以及女据，你看看，我们找到了这个女据，就叫十来个 fid from 一个，这么一个表啊，它里面其实有两个字段啊，两个字段，嗯，有两个字段进行过滤， 那么最后我们确认是因为这个缩影失效了啊，当时是我们是要给他重新再建一个缩影，据说他已经有这个缩影了，但是他失效了啊，我们最终的优化方式就是 对这个缩影再删掉，再重建一下啊。呃，客户说他是失效了啊，但是呢，不管是失效还是他本来就缺失了，我们最终都可以 再用 credit index 进行见一下这个缩影。 online 就是从就相当来说 online， 意思就是 如果这个对，那表还在用，那有可能你缩影键可能就是不好，键上的话，那么你要加上哦烂甚是在线唱键，这个把这个缩影键上去以后，那么数据库的系统 他就很快恢复了。然后对于业务这一块，业务指的就是这主要主要讲的是一个凭证相关入账，他们做了个接口，这块的性能就很快就恢复了。之前啊相当于说一个小时我可以录几百万啊这样的一个 这个凭证导入进来，一旦出问题的话才能导，每次只能导啊，几百张 啊，每个小时只能找几百张，本来每个小时可以找这里导入几百万张啊，相差非常大， 经过优化以后，这个问题我们就得到了解决啊，这个就主要就分享的就是 aw 报告分析的一个案例，由这个我们怎么去看这个报告来分析出数据库是不是硬件有问题，还是数据库的 c 口有问题，或者是业务有问题 啊？这一块的这个案例呢？就先分享到这，谢谢大家。

大家好，我是雅善公司的黄正勋，今天继续进行 oracle sql 调优的第二讲，第一章节选择 sql 调优的对象的第二部分。 现在来看一下批处理程序的调优对象。选择沃尔口的批处理一般是通过存储过程来进行的。我们需要做的是，在 v dollar sql area 中，哪些 sql 是特定存储过程所执行的。 当存储过程或者函数执行的时候，包含在该存储过程的 s q l 会在第一次 parsing 后，会在 v dollar s q l area 中用 program id 字段来保存该存储过程的 object id。 所以通过 v dollar s q l area 中的 program id 字段于 d b a objects 里的 object id 式 join 以后，能够得出 s q l 与存储过程或 或者函数的对应关系。如果相同的 s q l 包含在多个存储过程的话，第一次执行的存储过程的 object id 会成为 v dollar s q l area 中的 program id。 所以用这种方法的时候，不能完全确定 sql 属于哪个存储过程或者函数，这一点要注意。让我们做一个测试，创建 plsqlte 的表，插入一百万数据， 创建 ce 字段的锁引，然后收集统计信息，创建存储过程 p i s q l bat 之一，内容是删除 p i s q l t e 表中 c 二等于 a a 的数据， 然后创建另一个存储过程 p l s q l batch 二，内容是重复插入 p l s q l t 一的 c 二等于 a 的值，然后 c 二值等于 a 的数据，修改成 a a。 在这里我们看到单独 s q l 语句中添加了注视，这是非常好的开发习惯，非常容易就能确认 s q l 的用途和模块。 而且在存储过程开始阶段，通过 dbms application info the set module 系统存储过程给这个存储过程指定了 module 名字，这对于管理程序以及以后对性能问题存储过程进行 trace 都是非常方便的， 这部分以后再进行详细讨论。我们执行了存储过程，假设执行的两个存储过程性能有问题时， 可以通过之前的 s q l 在 v dollar s q l area 中查询这两个存储过程所执行过的 s q l 语句的执行情况，包括执行次数、执行时间、 i o 的使用情况等信息，这样 就可以快速分析出存储过程中导致性能问题对象的 s q l。 如果批处理是复杂的存储过程，比如 batch 三存储过程内调用 batch 一和 batch 二，这时就无法简单通过 v dollar s q l area 的 program id 来进行确认了。 因为 batch 一和 batch 二虽然属于一个相同的批处理程序当中，但是 v dollar sql area 中无法通过 batch 三的 object id 来查询批处理中包含所有的 sql 了。 batch 一里面的 sql 或 batch 二里面的 sql 是会采用 batch 一或 batch 二的 object id 来表示 program id， 而类似的通过 shell 脚本或者 java 来编写的批处理程序就无法通过 v dollar sql area 找到对应关系了。这种多层次的存储过程，如果我们可以手动执行 的话，开启进程后先执行幺零零四六 event trace， 然后执行多层次的存储过程批处理，执行结束后关闭幺零零四六 trace。 不方便手动运行的批处理，需要在批处理执行开始的时候在 v dollar session 当中确认批处理的 s， i， d 和 cereal， 然后通过 d， b， m s monitor 系统包的 session trace enable 来针对这个进程开启 trace。 如果批处理程序是用 share 或者 java 编写时，可以在批处理步骤之前添加 dbms application info 系统包的 set module 存储过程， 指定这个程序是属于什么模块和 action 的。这样就可以在 v dollar sql area 中通过 module 和 action 字段来查询这个批处理中包含的 sql 信息 了。如果不方便修改程序的话，也可以在批处理程序执行的时候通过 v dollar session 来查看 c 和 serial 值。通过 dbm s monitor session trace enable 来开启 trace。 以上通过针对批处李晋城进行 tris 以后会在数据库服务器上产生 tris 文件，通过分析 tris 文件，可以确认哪个 sql 是主要的性能问题，原因 tris 相关的内容今天只是简单提一下，下个章节会单独拿出来进行讲解。 然后我们讨论一下如何找出执行计划变更的 s q l 语句的方法。目前在 c b o 的环境下， optimiser 的发展导致需要考虑的因素很多，执行计划会根据多种原因变更，是常见而且 不可避免的。大部分的执行计划变更后效率不会有太大变化，也存在变得更好的情况。变好了没有太多人会在意，但是也会发生执行计划变更导致性能变差的情况， 所以执行计划变更是需要管理的对象。可以通过上面的 s q l 快速找到执行计划变更的 s q l 列表，关键在于 dba hist sql stat 中找出 sql id 相同但是 plan hash value 不同的 sql。 我们可以查询 v dollar sql shared cursor 来确认执行计划变更的原因。更准确地说是不同 sql child number 的原因。 这里 child number 不同，执行计划可能是相同的，但是执行计划不同时， child number 肯定是不同的。 v dollar sql shared cursor 中每个字段是不同的原因，为了查看方便，可以用上面的 s q l 通过 on pivot 进行列转行。根据 oracle 版本的升级， v dollar s q l share cursor 里的字段可能会进行变更，需要根据实际情况适当调整。 如上结果所示，可以看到相同的 s q l 语句。由于执行计划不同，平均执行时间可能是零点一四秒，也可能是六十四秒，而且 i o 的使用量也是八十七个 block 和七十九万个 block， 所以不受管理的执行计划变更可能会导致相当严重的性能问题。那执行计划变更的普遍原因是什么呢？除了统计信息变更、创建星索引等最常见的原因以外，还有一些其他的 原因导致的执行计划变更。比如上图中通过 v dollar s q l shared cursor 来确认执行计划变更的原因是 use feedback stats。 这是由于 optimizer use feedback 的参数 使得 oracle 第一次执行 sql 以后， optimizer 觉得实际执行的统计数据返回值与之前生成执行计划时的数据不一致， 然后根据这次执行的统计数据重新生成了新的执行计划。类似的 optim peak user binds 和 optimizer adaptive cursor sharing 等参数也会导致执行计划的变更， 而且根据 oracle 版本的升级，会不断有一些自动化的功能，比如十二 c 新增加的 optimizer adaptive plants 和 optimizer adaptive statistics 等参数也 会影响执行计划的变更，所以不少数据库管理员会把这些参数设置成 force。 但这些参数导致的执行计划变更也有可能产生更好的性能， 所以也不是一定要把这些参数都设置成 force。 我们需要定期确认执行计划变更的 s q l， 然后找出原因。 通过 oracle 提供的 s q l t 工具设置 profile， 或者通过 hint 等方式固定执行计划，防止执行计划变更。之前的 optimizer 相关的参数也可以通过 o p t parent hint 在 s q l 执行级别修改为 force， 不让执行计划随意变更。 现在介绍 a s h 试图，这个试图全称是 v dollar active session history 会保留每秒数据库中执行的 活动绘画的信息，包括执行时间、 io 执行计划等有用的信息，并且每十秒的进程信息会记录到 a w r 的 d b a hist active says history 当中。 通过 a s h， 我们可以对当前或者历史的活动进程进行查看。对故障原因分析是非常有用的， 只是 a s h 的数据保留时间根据 s g a 内存大小以及活动进程的数量级有关，只能保留几个小时或者更短的历史数据。 从十一据版本开始，视图中提供的 blocking session 字段可以确定除了一般航所表所以外的一些其他等待事件的 holder 进程 s i d， 以便进行关联分析，对分析等待事件是非常有帮助的。 这些 s q l 是通过 s h 来确认性能问题时常用的一些语句，在这里就不做更详细的解释了，大家可以看一下掌握使用方法。 我最经常使用的是最后一个特定区间执行历史记录，不管是对 batch 性的作业或者特定一个性能问题 s q l 进行调优时，我会对特定 s i d 或者特定 s q l i d 进行 a s h 分析。 通过特定 sqlid 的出现频率和特定执行计划步骤、 sql planlineid 的出现频率来初步判断性能问题的原因，以后案例分析的时候再进行详细说明。 通过 i s h 得出来的数据，我们可以统计在特定时间段内的性能数据，可以确定最近执行 型的 sql 信息，也可以查看有性能问题的 sql， 还能做出等待事件分布等有用的分析工作。 ish 试图是对 dba 管理数据库非常有用的工具， 在网络上也有很多详细的使用方法介绍，大家可以自己去深入地了解。现在我们讨论一下 top table， 这个概念不是 oracle 官方的概念，所以可能大家不太熟悉。 我们做出这个 top table 的概念的初衷是快速了解数据库中的业务性质，确认访问最多的最核心的表对象， 根据业务重要程度来选择表，然后改善这个表相关的 s q l 也可以快速分析性能问题 s q l 中涉及到的表索引、统计信息等相关的信息。这个是 获取 top table 的方法，会使用 dba segments、 dba tables 等等很多数据字典， 这个是通过 top table 获得的结果，这个结果是按照表的大小来进行排序的。如果数据架构设计人员规范操作的话，在表明和 comments 字段当中可以看到表的大概的业务和用途。从商品评论日志、订单详细信息、 商品基本信息等 command 当中可以初步判断这个数据库是网上商城相关的业务。而第一个 et m b 二 process his 表可能是历史数据表，采用了范围分区结构， 物理读取量占据整个逻辑读取量的百分之六十以上，可以推测主要进行单分区全表读取的可能性高。相对整个表的大小来看，如 逻辑读取的量不大，因此查询频率可能不太多。考虑到有两个锁引，所以特定自断的数据也可能用于 o l t p 业务查询。再来看第三个表， p r good space 也是分区表，但是拥有七个锁引， 而且物理读取只占用整个逻辑读取的百分之一点四九，可以猜测是主要通过索引来进行 oltp 的业务查询， 所以通过 top table 可以快速了解数据库以及各种表的性质，为调优提供必要的信息。在这个单元的最后，我们来总结一下调优时候经常用到的工具。 首先，为了获取 s q l 信息，可以查看 v dollar s q l。 可以获取 s q l text， 执行次数、执行计划、 io 使用量等重要信息。 v dollar sql area 类似于对 v dollar sql 做了 sql id 的 group by， 由于没有执行计划，所以我用的不多。 a s h 的两个视图，由于能确认每秒实际执行的性能情况，所以确认 s q l 性能是非常有用的。 all sorts 里面可以查看存储过程和函数的创建语句，对性能问题是否发生在存储过程是很有帮助的。 表的大小和统计信息对 s q l 性能是非常重要的。相对于表的行数，我更在乎的是表的大小和字段的分布情况。因为 oracle 性能问题很大一部分是 i o 的问题，不同表相同行数的 i o 是不一样的。在 altables 和 altep column columns 中查看表的统计信息。在 all segments 中确认表的大小。 out have partitions her all part key columns 中确认分区表的情况。 dbms metadata 系统包可以确认表等对象的创建语句。 索引在性能当中扮演非常重要的角色，这个以后会单独拿出来进行讲解。个人认为表的数据结构和索引策略如果建立得非常好的话， 几乎可以杜绝百分之八十的性能问题。 bowling decks 和 all i n d columns 可以确认锁影和锁影字段的信息。 d b a i n d expression 可以确认函数锁影的函数信息。 为了获缺 s q l 的执行信息，我们需要查看 v dollar s q l plan 来确认执行计划。但是最近有 用 dbms x plan display cursor 来确认执行计划，在可读性和获取信息量是更加方便的。 v dollar s q l bind capture 和 v dollar s q l monitor 是获取绑定变量的两个方法。 v dollar sql band capture 不会对所有的执行情况保留绑定变量，而只是周期性的进行获取。 v dollar s q l monitor 是实效性更好的，可以通过 bind x m l 字段来获取每次执行的绑定变量，但是这个功能是 monitor in database operation 功能提供的，一般保存 c p u。 执行时间超过五秒以上的 s q l。 执行信息。 幺零零四六 trace 和 dbms x plan 系统包都是用于收集 s q l。 的 trace 信息的工具，而 d b m s s q l tune report s q l。 monitor 则是可视化展示 monitor in database operation 自动收集的 s q l。 执行信息，展示方法类似于 d b m s x plan display cursor。 对于不方便做 trace， 但是要分析执行时间长的性能问题， s q l。 是非常有用的， 可以跟 d b m s x plan display cursor 互补使用。下一章节会对 s q l。 执行信息相关的部分进行详细讲解。 all scheduler jobs 和 all scheduler job run details。 仕途是分析定时任务的工具，对分析一些周期性的性能问题是非常有帮助的。 除了 orco 动态视图以外，我们经常用到的工具有 s q l plus， s q l developer， 这两个是免费的 s q。 编辑工具。还有 told 是 quest 公司的工具，功能非常多，但是工具有点重。 max gauge 和 light plus 是我们公司的产品，个人认为是市面上最好的性能管理软件和调油工具。 到现在，我们完成了第一章节选择 sql 调优对象的学习。下一章节我们要讨论的是 sql 性能信息分析方法，也就是如何分析我们找到的这些问题 sql， 以便于找出问题原因。谢谢大家，下一课再见！

欢迎大家来到动力节点下面呢，我们来学习 d m r 当中的 delete 语句删除表当中的数据行。 例如说我们的表当中有很多很多数据，那么我不想要这么多的数据了。例如说我想把第四行数据删除，那怎么样去删除呢？这个删除语句的格式非常好记啊。 delete from 表明 well， 字短等于多少就可以了啊。例如 delete form 后头跟上表明 well id 等于第四行， id 是不等于六，那么这行记录就会被我们给删除 掉啊。运行你看看是不 id 等于六的就消失了啊。当然呢，我强调一下要点啊。强调一下要点第一就是微小条件啊，你要删除哪一行记录，你必须指明出来，如果不指明出来，后果非常非常严重 啊。我们看一下后果会怎样？运行他问你是不是要删除所有的记录，因为你没有说你要删哪行吗？啊我这就我这就不点确定了啊，因为一点数据就没有了 啊。所以这个 word 条件是不能去掉的啊。当然呢，我们 word 条件不只是一个条件对吧？我们会看到文档当中有自断一等于自断一的值，自断二等于自断二的值，自断三等于自断三的值啊。那么我们举一个 使用了两个字段的例子啊。我的 word 条件是 name 等于填七， 并且年龄等于二十二岁，那是不这行记录就消失了。 好，我们再来查询啊。你看是不就把姓名叫做填期，并且年龄是二十二岁的 就删掉了啊。注意 what 条件一定不能丢，丢了的话后果很严重，他会删除，会删除所有的表当中的数据啊。那么我再强调一点，有的同学可能并没有写 forum delete student well， id 等于三，它能运行吗？它一样能运行啊，点击入改变，那么 id 等于三的 这条记录就消失了啊。也就说这个 form 你写出来它也对，你不写出来它也对。 那么这两个有区别吗？肯定是有区别的啊。我们不能投机取巧啊。因为有些同学哎，说，那这个词可以不写，我为什么要写出来呢？啊，不能这么想啊，不能这么想，我告诉你他们区别在哪。 那么如果你写出来 floor， 那么这条语句将是一条标准的 circle 语句，符合 circle 九二标准的 circle 语句。如果你没有写出来这个 form， 那么它将是 oracle 的方言。 那 circle 九二标准是什么意思呢？啊？在以前，我们有很多很多的数据库啊，不止以前，现在也是有很多很多的数据库，每个数据库跟每个数据库的语言都不一样。 那么这会给我们程序员造成很大很大的一个负担。因为每个数据数据库跟每个数据库的思考语句写出来的都不一样，语言都不一样 啊。所以呢，在一九九二年就出了一个标准，叫 circle 九二标准啊，叫 circle 九二标准，他把市面 面上几乎所有的数据库的语言全部都统一了，也就说四个九二标准。其实就是普通话，市面上几乎所有的数据库都懂你的意思。 那如果啊，如果你没有写福尔摩，那么是二口的方言，也只有二口听得懂。 那么其他的数据库呢？是不懂的，这是区别。所以我们学我们当然要学 circle 九二标准的 circle 语句。这样的话，就算我们以后换成 my circle 数据库，我们一样可以这样写。因为这是普通话嘛。 我们换成微软的 school server， 我们一样可以这样去写。我们换成 i b m 的 d b two， 我们一样可以这样去写。那否则的话， 如果你为了少写几个字母，把 circle 语句写成这个样子，你到 mesco 就会报错，你到 circle server 就会报错，因为其他的数据库不认啊。这是我们的 delete 语句，非常简单啊。

你们用的是哪个数据库呢？奥瑞口吗？啊，不是，用的是麦斯口。那你主要是哪些数据库操作呢？增山奶茶还是其他的？嗯， 是用的单表查，也有多表查。嗯，关联查询这些。嗯，那主要还是查询操作是吧？ 啊，对的啊，查询操作室比较多，也有山根感。拿查询来说吧。啊，如果啊，我们有一个表，这个表呢有我们的学生的姓名以及分数。那么你怎么用最后一句查询出这个班级里面一个分数最高的学生信息呢？在他的后面跟学生信息自断，然后放入这个表，然后为了条件， 条件是成绩等于最高分，最高分要最高分要用到麦克斯函数。呃，那如果还要查询每科最高分的学生信息呢？嗯， style 在后面除了跟学生信息之段呢？ 嗯，还要增加科目自断呢，还要增加麦克斯函数，统计最高分，然后放入这个表，然后格瑞巴还对科目进行分组。嗯， 你的意思是先分组，然后呢取每个分组里面的最高分？嗯，对，是这个意思。嗯，这些是你们经常会去做的查询操作是吧？对的，用到过这些查询。嗯，好的。