分享
分享赚钱 收藏 举报 版权申诉 / 65

类型ORACLE-AWR报告结果分析.doc

  • 上传人:精品资料
  • 文档编号:10580431
  • 上传时间:2019-12-02
  • 格式:DOC
  • 页数:65
  • 大小:1.92MB
  • 配套讲稿:

    如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。

    特殊限制:

    部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。

    关 键  词:
    ORACLE-AWR报告结果分析.doc
    资源描述:

    1、ORACLE-AWR 报告结果分析AWR 是 Oracle 10g 版本推出的新特性, 全称叫Automatic Workload Repository (自动负载信息库), AWR 是通过对比两次快,照(snapshot)收集到的统计信息,来生成报表数据,生成的报表包括多个部分。定义awr 报告是 oracle 10g 下提供的一种性能收集和分析工具,它能提供一个时间段内整个系统资源使用情况的报告,通过这个报告,我们就可以了解一个系统的整个运行情况,这就像一个人全面的体检报告。 生成 awr 报告1:登陆对应的数据库服务器 2:找到 oracle 磁盘空间( d:oracleproduct1

    2、0.2.0db_1RDBMSAdmin) 3:执行 cmd-cd d:回车 4: cd d:oracleproduct10.2.0db_1RDBMSAdmin 回车 5:sqlplus 用户名 /密码服务连接名(例:sqlplus carmot_esz_1/carmotigrp) 6:执行awrrpt.sql 回车 第一步输入类型: html 第二步输入天数: 天数自定义(如 1,代表当天,如果 2,代表今天和昨天。) 第三步输入开始值与结束值:(你可以看到上面列出的数据,snap 值) 这个值输入开始,与结束 第四步输入导出表的名称:名称自定义 回车 第五步,由程序自动导完。 第六:到 d:

    3、oracleproduct10.2.0db_1RDBMSAdmin 目录下。找到刚才生成的文件。 XXXX.LST 文件 如何分析* 在看 awr 报告的时候,我们并不需要知道所有性能指标的含义,就可以判断出问题的所在,这些性能指标其实代表了 oracle 内部实现,对 oracle 理解的越深,在看 awr 报告的时候,对数据库性能的判断也会越准确 * 在看性能指标的时候,心里先要明白,数据库出现性能问题,一般都在三个地方,io,内存,cpu,这三个又是息息相关的(ps :我们先假设这个三个地方都没有物理上的故障),当 io 负载增大时,肯定需要更多的内存来存放,同时也需要 cpu 花费更多

    4、的时间来过滤这些数据,相反,cpu 时间花费多的话,有可能是解析 sql 语句,也可能是过滤太多的数据,到不一定是和 io 或内存有关系了 * 当我们把一条 sql 送到数据库去执行的时候,我们要知道,什么时候用到 cpu,什么时候用到内存,什么时候用到 io 1. cpu:解析 sql 语句,尝试多个执行计划,最后生成一个数据库认为是比较好的执行计划,不一定是最优的,因为关联表太多的时候,数据库并不会穷举所有的执行计划,这会消耗太多的时间,oracle 怎么就知道这条数据时你要,另一个就不是你要的呢,这是需要 cpu 来过滤的 2. 内存:sql 语句和执行计划都需要在内存保留一段时间,还有

    5、取到的数据,根据 lru 算法也会尽量在内存中保留,在执行 sql 语句过程中,各种表之间的连接,排序等操作也要占用内存 3. io:如果需要的数据在内存中没有,则需要到磁盘中去取,就会用到物理 io 了,还有表之间的连接数据太多,以及排序等操作内存放不下的时候,也需要用到临时表空间,也就用到物理 io 了 这里有一点说明的是,虽然 oracle 占用了 8G 的内存,但 pga 一般只占 8G 的20%,对于专用服务器模式,每次执行 sql 语句,表数据的运算等操作,都在pga 中进行的,也就是说只能用 1.6G 左右的内存,如果多个用户都执行 多表关联,而且表数据又多,再加上关联不当的话,

    6、内存就成为瓶颈了,所有优化 sql 很重要的一点就是,减少逻辑读和物理读具体分析过程* 在分析 awr 报告之前,首先要确定我们的系统是属于 oltp,还是olap(数据库在安装的时候,选择的时候,会有一个选项,是选择 oltp,还是olap) 对于不同的系统,性能指标的侧重点是不一样的,比如,library hit 和buffer hit,在 olap 系统中几乎可以忽略这俩个性能指标,而在 oltp 系统中,这俩个指标就非常关键了 * 首先要看俩个时间 Elapsed: 240.00 (mins) 表明采样时间是 240 分钟,任何数据都要通过这个时间来衡量,离开了这个采样时间,任何数据都

    7、毫无疑义 DB Time: 92,537.95 (mins) 表明用户操作花费的时候,包括 cpu 时间喝等待时间,也许有人会觉得奇怪,为什么在采样的 240 分钟过程中,用户操作时间竟然有 92537 分钟呢,远远超过了 采样时间,原因是 awr 报告是一个数据的集合,比如在一分钟之内,一个用户等待了 30 秒,那么 10 个用户就等待了 300 秒,对于 cpu 的话,一个cpu 处理了 30 秒,16 个 cpu 就是 4800 秒,这些时间都是以累积的方式记录在awr 报告中的。 再看 sessions,可以看出连接数非常多 WORKLOAD REPOSITORY report for

    8、 DB Name DB Id Instance Inst num Release RAC HostICCI 1314098396 ICCI1 1 10.2.0.3.0 YES HPGICCI1Snap Id Snap Time Sessions Cursors/SessionBegin Snap: 2678 25-Dec-08 14:04:50 24 1.5End Snap: 2680 25-Dec-08 15:23:37 26 1.5Elapsed: 78.79 (mins) DB Time: 11.05 (mins) DB Time 不包括 Oracle 后台进程消耗的时间。如果 DB T

    9、ime 远远小于Elapsed 时间,说明数据库比较空闲。db time= cpu time + wait time(不包含空闲等待) (非后台进程)说白了就是 db time 就是记录的服务器花在数据库运算(非后台进程)和等待(非空闲等待) 上的时间DB time = cpu time + all of nonidle wait event time在 79 分钟里(其间收集了 3 次快照数据),数据库耗时 11 分钟,RDA 数据中显示系统有 8 个逻辑 CPU(4 个物理 CPU),平均每个 CPU 耗时 1.4 分钟,CPU 利用率只有大约 2%(1.4/79)。说明系统压力非常小。列

    10、出下面这两个来做解释:Report A:Snap Id Snap Time Sessions Curs/Sess- - - -Begin Snap: 4610 24-Jul-08 22:00:54 68 19.1End Snap: 4612 24-Jul-08 23:00:25 17 1.7Elapsed: 59.51 (mins)DB Time: 466.37 (mins)Report B:Snap Id Snap Time Sessions Curs/Sess- - - -Begin Snap: 3098 13-Nov-07 21:00:37 39 13.6End Snap: 3102 1

    11、3-Nov-07 22:00:15 40 16.4Elapsed: 59.63 (mins)DB Time: 19.49 (mins)服务器是 AIX 的系统,4 个双核 cpu,共 8 个核:/sbin bindprocessor -qThe available processors are: 0 1 2 3 4 5 6 7先说 Report A,在 snapshot 间隔中,总共约 60 分钟,cpu 就共有 60*8=480 分钟,DB time为 466.37 分钟,则:cpu 花费了 466.37 分钟在处理 Oralce 非空闲等待和运算上(比方逻辑读)也就是说 cpu 有 466

    12、.37/480*100% 花费在处理 Oracle 的操作上,这还不包括后台进程看 Report B,总共约 60 分钟,cpu 有 19.49/480*100% 花费在处理 Oracle 的操作上很显然,2 中服务器的平均负载很低。从 awr report 的 Elapsed time 和 DB Time 就能大概了解 db 的负载。可是对于批量系统,数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内,或者快照周期跨度太长而包含了大量的数据库空闲时间,所得出的分析结果是没有意义的。这也说明选择分析时间段很关键,要选择能够代表性能问题的时间段。Report SummaryCac

    13、he Sizes Begin EndBuffer Cache: 3,344M 3,344M Std Block Size: 8KShared Pool Size: 704M 704M Log Buffer: 14,352K显示 SGA 中每个区域的大小(在 AMM 改变它们之后),可用来与初始参数值比较。shared pool 主要包括 library cache 和 dictionary cache。library cache 用来存储最近解析(或编译)后 SQL、PL/SQL 和 Java classes 等。library cache 用来存储最近引用的数据字典。发生在 library

    14、cache 或 dictionary cache 的 cache miss 代价要比发生在 buffer cache 的代价高得多。因此 shared pool 的设置要确保最近使用的数据都能被 cache。Load ProfilePer Second Per TransactionRedo size: 918,805.72 775,912.72Logical reads: 3,521.77 2,974.06Block changes: 1,817.95 1,535.22Physical reads: 68.26 57.64Physical writes: 362.59 306.20User

    15、calls: 326.69 275.88Parses: 38.66 32.65Hard parses: 0.03 0.03Sorts: 0.61 0.51Logons: 0.01 0.01Executes: 354.34 299.23Transactions: 1.18 % Blocks changed per Read: 51.62 Recursive Call %: 51.72Rollback per transaction %: 85.49 Rows per Sort: #显示数据库负载概况,将之与基线数据比较才具有更多的意义,如果每秒或每事务的负载变化不大,说明应用运行比较稳定。单个的

    16、报告数据只说明应用的负载情况,绝大多数据并没有一个所谓“正确”的值,然而 Logons 大于每秒12 个、Hard parses 大于每秒 100、全部 parses 超过每秒 300 表明可能有争用问题。Redo size:每秒产生的日志大小(单位字节),可标志数据变更频率, 数据库任务的繁重与否。Logical reads:每秒/每事务逻辑读的块数.平决每秒产生的逻辑读的 block 数。Logical Reads= Consistent Gets + DB Block Gets Block changes:每秒/ 每事务修改的块数Physical reads:每秒/每事务物理读的块数Ph

    17、ysical writes:每秒/每事务物理写的块数User calls:每秒 /每事务用户 call 次数Parses: SQL 解析的次数.每秒解析次数,包括 fast parse,soft parse 和 hard parse 三种数量的综合。 软解析每秒超过 300 次意味着你的“应用程序“效率不高,调整 session_cursor_cache。在这里,fast parse 指的是直接在 PGA 中命中的情况(设置了 session_cached_cursors=n);soft parse 是指在 shared pool 中命中的情形;hard parse 则是指都不命中的情况。Ha

    18、rd parses:其中硬解析的次数,硬解析太多,说明 SQL 重用率不高。每秒产生的硬解析次数, 每秒超过 100 次,就可能说明你绑定使用的不好,也可能是共享池设置不合理。这时候可以启用参数 cursor_sharing=similar|force,该参数默认值为 exact。但该参数设置为 similar 时,存在 bug,可能导致执行计划的不优。Sorts:每秒/每事务的排序次数Logons:每秒/每事务登录的次数Executes:每秒/ 每事务 SQL 执行次数Transactions:每秒事务数.每秒产生的事务数,反映数据库任务繁重与否。Blocks changed per Rea

    19、d:表示逻辑读用于修改数据块的比例 .在每一次逻辑读中更改的块的百分比。Recursive Call:递归调用占所有操作的比率 .递归调用的百分比,如果有很多PL/SQL,那么这个值就会比较高。Rollback per transaction:每事务的回滚率 .看回滚率是不是很高,因为回滚很耗资源 ,如果回滚率过高,可能说明你的数据库经历了太多的无效操作 ,过多的回滚可能还会带来 Undo Block 的竞争 该参数计算公式如下: Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% 。Rows per Sort:每次

    20、排序的行数注:Oracle 的硬解析和软解析 提到软解析(soft prase)和硬解析(hard prase),就不能不说一下 Oracle 对 sql的处理过程。当你发出一条 sql 语句交付 Oracle,在执行和获取结果前,Oracle对此 sql 将进行几个步骤的处理过程:1、语法检查(syntax check)检查此 sql 的拼写是否语法。2、语义检查(semantic check)诸如检查 sql 语句中的访问对象是否存在及该用户是否具备相应的权限。3、对 sql 语句进行解析(prase)利用内部算法对 sql 进行解析,生成解析树(parse tree)及执行计划(exec

    21、ution plan)。4、执行 sql,返回结果(execute and return)其中,软、硬解析就发生在第三个过程里。Oracle 利用内部的 hash 算法来取得该 sql 的 hash 值,然后在 library cache里查找是否存在该 hash 值;假设存在,则将此 sql 与 cache 中的进行比较;假设“相同”,就将利用已有的解析树与执行计划,而省略了优化器的相关工作。这也就是软解析的过程。Comment FF1: OLAP:联机分析处理OLTP:联机事务处理OLAP是主要应用数据仓库系统OLTP是一般的项目开发用到的基本的、日常的事务处理;比如数据库记录的增、删、改

    22、、查。诚然,如果上面的 2个假设中任有一个不成立,那么优化器都将进行创建解析树、生成执行计划的动作。这个过程就叫硬解析。创建解析树、生成执行计划对于 sql的执行来说是开销昂贵的动作,所以,应当极力避免硬解析,尽量使用软解析。Instance Efficiency Percentages (Target 100%) Buffer Nowait %: 100.00Redo NoWait %: 100.00Buffer Hit %: 98.72In-memory Sort %: 99.86Library Hit %: 99.97Soft Parse %: 99.92Execute to Parse

    23、 %: 89.09Latch Hit %: 99.99Parse CPU to Parse Elapsd %: 7.99% Non-Parse CPU: 99.95本节包含了 Oracle关键指标的内存命中率及其它数据库实例操作的效率。其中 Buffer Hit Ratio 也称 Cache Hit Ratio,Library Hit ratio 也称 Library Cache Hit ratio。同 Load Profile一节相同,这一节也没有所谓“正确”的值,而只能根据应用的特点判断是否合适。在一个使用直接读执行大型并行查询的 DSS环境,20%的 Buffer Hit Ratio是可

    24、以接受的,而这个值对于一个 OLTP系统是完全不能接受的。根据 Oracle的经验,对于 OLTP系统,Buffer Hit Ratio 理想应该在90%以上。Buffer Nowait表示在内存获得数据的未等待比例。在缓冲区中获取 Buffer的未等待比率。Buffer Nowait 的这个值一般需要大于 99%。否则可能存在争用,可以在后面的等待事件中进一步确认。buffer hit表示进程从内存中找到数据块的比率,监视这个值是否发生重大变化比这个值本身更重要。对于一般的 OLTP系统,如果此值低于 80%,应该给数据库分配更多的内存。数据块在数据缓冲区中的命中率,通常应在 95%以上。否

    25、则,小于 95%,需要调整重要的参数,小于 90%可能是要加 db_cache_size。一个高的命中率,不一定代表这个系统的性能是最优的,比如大量的非选择性的索引被频繁访问,就会造成命中率很高的假相(大量的 db file sequential read),但是一个比较低的命中率,一般就会对这个系统的性能产生影响,需要调整。命中率的突变,往往是一个不好的信息。如果命中率突然增大,可以检查 top buffer get SQL,查看导致大量逻辑读的语句和索引,如果命中率突然减小,可以检查 top physical reads SQL,检查产生大量物理读的语句,主要是那些没有使用索引或者索引被删

    26、除的。Redo NoWait表示在 LOG缓冲区获得 BUFFER的未等待比例。如果太低(可参考 90%阀值),考虑增加 LOG BUFFER。 当 redo buffer达到 1M时,就需要写到 redo log文件,所以一般当 redo buffer设置超过 1M,不太可能存在等待 buffer空间分配的情况。当前,一般设置为 2M的 redo buffer,对于内存总量来说,应该不是一个太大的值。library hit表示 Oracle从 Library Cache中检索到一个解析过的 SQL或PL/SQL语句的比率,当应用程序调用 SQL或存储过程时, Oracle检查 Library

    27、 Cache确定是否存在解析过的版本,如果存在,Oracle 立即执行语句;如果不存在,Oracle 解析此语句,并在 Library Cache中为它分配共享 SQL区。低的library hit ratio会导致过多的解析,增加 CPU消耗,降低性能。如果 library hit ratio低于 90%,可能需要调大 shared pool区。STATEMENT 在共享区的命中率,通常应该保持在 95%以上,否则需要要考虑:加大共享池;使用绑定变量;修改 cursor_sharing 等参数。Latch Hit:Latch 是一种保护内存结构的锁,可以认为是 SERVER 进程获取访问内存

    28、数据结构的许可。要确保 Latch Hit99%,否则意味着 Shared Pool latch 争用,可能由于未共享的 SQL,或者 Library Cache 太小,可使用绑定变更或调大 Shared Pool 解决。要确保99%,否则存在严重的性能问题。当该值出现问题的时候,我们可以借助后面的等待时间和 latch 分析来查找解决问题。Parse CPU to Parse Elapsd:解析实际运行时间/(解析实际运行时间+解析中等待资源时间) ,越高越好。计算公式为:Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse tim

    29、e elapsed)。即:解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。如果该比率为 100%,意味着 CPU 等待时间为 0,没有任何等待。Non-Parse CPU :SQL 实际运行时间/(SQL 实际运行时间+SQL 解析时间),太低表示解析消耗时间过多。计算公式为:% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果这个值比较小,表示解析消耗的 CPU 时间过多。与 PARSE_CPU 相比,如果 TOT_CPU 很高,这个比值将接近 100%,这是很好的,说明计算机执行的大部分工作是执行查询的工作,而不是分析查询的

    30、工作。Execute to Parse:是语句执行与分析的比例,如果要 SQL 重用率高,则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。计算公式为:Execute to Parse =100 * (1 - Parses/Executions)。本例中,差不多每execution 5 次需要一次 parse。所以如果系统 Parses Executions,就可能出现该比率小于 0 的情况。该值1: 88.48 79.81% Memory for SQL w/exec1: 79.99 73.52Memory Usage %:对于一个已经运行一段时间的数据库来说,共享池内存使用率,

    31、应该稳定在 75%-90%间,如果太小,说明 Shared Pool 有浪费,而如果高于 90,说明共享池中有争用,内存不足。这个数字应该长时间稳定在75%90%。如果这个百分比太低,表明共享池设置过大,带来额外的管理上的负担,从而在某些条件下会导致性能的下降。如果这个百分率太高,会使共享池外部的组件老化,如果 SQL 语句被再次执行,这将使得 SQL 语句被硬解析。在一个大小合适的系统中,共享池的使用率将处于 75%到略低于 90%的范围内.SQL with executions1:执行次数大于 1 的 sql 比率,如果此值太小,说明需要在应用中更多使用绑定变量,避免过多 SQL 解析。

    32、在一个趋向于循环运行的系统中,必须认真考虑这个数字。在这个循环系统中,在一天中相对于另一部分时间的部分时间里执行了一组不同的 SQL 语句。在共享池中,在观察期间将有一组未被执行过的 SQL 语句,这仅仅是因为要执行它们的语句在观察期间没有运行。只有系统连续运行相同的 SQL 语句组,这个数字才会接近 100%。Memory for SQL w/exec1:执行次数大于 1 的 SQL 消耗内存的占比。这是与不频繁使用的 SQL 语句相比,频繁使用的 SQL 语句消耗内存多少的一个度量。这个数字将在总体上与% SQL with executions1 非常接近,除非有某些查询任务消耗的内存没有

    33、规律。在稳定状态下,总体上会看见随着时间的推移大约有 75%85%的共享池被使用。如果 Statspack 报表的时间窗口足够大到覆盖所有的周期,执行次数大于一次的 SQL 语句的百分率应该接近于 100%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。小结:通过 ORACLE 的实例有效性统计数据,我们可以获得大概的一个整体印象,然而我们并不能由此来确定数据运行的性能。当前性能问题的确定,我们主要还是依靠下面的等待事件来确认。我们可以这样理解两部分的内容,hit 统计帮助我们发现和预测一些系统将要产生的性能问题,由此我们可以做到未雨绸缪。而 wait 事

    34、件,就是表明当前数据库已经出现了性能问题需要解决,所以是亡羊补牢的性质。Top 5 Timed Events Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait ClassCPU time 515 77.6 SQL*Net more data from client 27,319 64 2 9.7 Networklog file parallel write 5,497 47 9 7.1 System I/Odb file sequential read 7,900 35 4 5.3 User I/Odb file parallel

    35、write 4,806 34 7 5.1 System I/O这是报告概要的最后一节,显示了系统中最严重的 5 个等待,按所占等待时间的比例倒序列示。当我们调优时,总希望观察到最显著的效果,因此应当从这里入手确定我们下一步做什么。例如如果buffer busy wait是较严重的等待事件,我们应当继续研究报告中 Buffer Wait 和 File/Tablespace IO 区的内容,识别哪些文件导致了问题。如果最严重的等待事件是 I/O 事件,我们应当研究按物理读排序的 SQL 语句区以识别哪些语句在执行大量 I/O,并研究Tablespace 和 I/O 区观察较慢响应时间的文件。如果有

    36、较高的 LATCH 等待,就需要察看详细的 LATCH 统计识别哪些 LATCH 产生的问题。一个性能良好的系统,cpu time 应该在 top 5 的前面,否则说明你的系统大部分时间都用在等待上。在这里,log file parallel write 是相对比较多的等待,占用了 7%的 CPU 时间。通常,在没有问题的数据库中,CPU time 总是列在第一个。更多的等待事件,参见本报告 的 Wait Events 一节。RAC StatisticsBegin EndNumber of Instances: 2 2Global Cache Load Profile Per Second P

    37、er TransactionGlobal Cache blocks received: 4.16 3.51Global Cache blocks served: 5.97 5.04GCS/GES messages received: 408.47 344.95GCS/GES messages sent: 258.03 217.90DBWR Fusion writes: 0.05 0.05Estd Interconnect traffic (KB) 211.16 Global Cache Efficiency Percentages (Target local+remote 100%) Buff

    38、er access - local cache %: 98.60Buffer access - remote cache %: 0.12Buffer access - disk %: 1.28Global Cache and Enqueue Services - Workload Characteristics Avg global enqueue get time (ms): 0.1Avg global cache cr block receive time (ms): 1.1Avg global cache current block receive time (ms): 0.8Avg g

    39、lobal cache cr block build time (ms): 0.0Avg global cache cr block send time (ms): 0.0Global cache log flushes for cr blocks served %: 3.5Avg global cache cr block flush time (ms): 3.9Avg global cache current block pin time (ms): 0.0Avg global cache current block send time (ms): 0.0Global cache log

    40、flushes for current blocks served %: 0.4Avg global cache current block flush time (ms): 3.0Global Cache and Enqueue Services - Messaging Statistics Avg message sent queue time (ms): 0.0Avg message sent queue time on ksxp (ms): 0.3Avg message received queue time (ms): 0.5Avg GCS message process time

    41、(ms): 0.0Avg GES message process time (ms): 0.0% of direct sent messages: 14.40% of indirect sent messages: 77.04% of flow controlled messages: 8.56Main Report Wait Events Statistics SQL Statistics Instance Activity Statistics IO Stats Buffer Pool Statistics Advisory Statistics Wait Statistics Undo

    42、Statistics Latch Statistics Segment Statistics Dictionary Cache Statistics Library Cache Statistics Memory Statistics Streams Statistics Resource Limit Statistics init.ora Parameters Wait Events Statistics Time Model Statistics Wait Class Wait Events Background Wait Events Operating System Statistic

    43、s Service Statistics Service Wait Class Stats Back to Top/* oracle 等待事件是衡量 oracle 运行状况的重要依据及指示,等待事件分为两类:空闲等待事件和非空闲等待事件, TIMED_STATISTICS = TRUE 那么等待事件按等待的时间排序,= FALSE 那么事件按等待的数量排序。运行 statspack 期间必须 session 上设置 TIMED_STATISTICS = TRUE,否则统计的数据将失真。空闲等待事件是 oracle 正等待某种工作,在诊断和优化数据库时候,不用过多注意这部分事件,非空闲等待事件专

    44、门针对 oracle 的活动,指数据库任务或应用程序运行过程中发生的等待,这些等待事件是我们在调整数据库应该关注的。对于常见的等待事件,说明如下:1) db file scattered read 文件分散读取该事件通常与全表扫描或者 fast full index scan 有关。因为全表扫描是被放入内存中进行的进行的,通常情况下基于性能的考虑,有时候也可能是分配不到足够长的连续内存空间,所以会将数据块分散(scattered)读入 Buffer Cache 中。该等待过大可能是缺少索引或者没有合适的索引(可以调整 optimizer_index_cost_adj) 。这种情况也可能是正常的

    45、,因为执行全表扫描可能比索引扫描效率更高。当系统存在这些等待时,需要通过检查来确定全表扫描是否必需的来调整。因为全表扫描被置于 LRU(Least Recently Used,最近最少适用)列表的冷端(cold end),对于频繁访问的较小的数据表,可以选择把他们 Cache 到内存中,以避免反复读取。当这个等待事件比较显著时,可以结合 v$session_longops 动态性能视图来进行诊断,该视图中记录了长时间(运行时间超过 6 秒的)运行的事物,可能很多是全表扫描操作(不管怎样,这部分信息都是值得我们注意的)。关于参数 OPTIMIZER_INDEX_COST_ADJn:该参数是一个百

    46、分比值,缺省值为 100,可以理解为 FULL SCAN COST/INDEX SCAN COST。当 n%* INDEX SCAN COST select parameter1,parameter2,parameter3 from v$event_name where name=buffer busy waitsPARAMETER1 PARAMETER2 PARAMETER3- - -file# block# idOracle 10gPARAMETER1 PARAMETER2 PARAMETER3- - -file# block# class#在诊断 buffer busy waits 事件

    47、的过程中,获取如下信息会很有用:1.获取产生 buffer busy waits 事件的等待原因编号,这可以通过查询该事件的 p3参数值获得2.获取产生此事件的 SQL 语句,可以通过如下的查询获得:select sql_text from v$sql t1,v$session t2,v$session_wait t3where t1.address=t2.sql_address and t1.hash_value=t2.sql_hash_valueand t2.sid=t3.sid and t3.event=buffer busy waits;3.获取等待的块的类型以及所在的 segment

    48、,可以通过如下查询获得:PHP code:select Segment Header class,a.segment_type,a.segment_name,a.partition_name from dba_segments a,v$session_wait bwhere a.header_file=b.p1 and a.header_block=b.p2 and b.event=buffer busy waitsunionselect Freelist Groups class,a.segment_type,a.segment_name,a.partition_name from dba_segments a,v$session_wait bwhere a.header_file=b.p1 and b.p2 between a.header_block+1 and (a.header_block+a.freelist_groups) and a.freelist_groups1 and b.event=buffer busy waitsunionselect a.segment_ty

    展开阅读全文
    提示  道客多多所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
    关于本文
    本文标题:ORACLE-AWR报告结果分析.doc
    链接地址:https://www.docduoduo.com/p-10580431.html
    关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

    道客多多用户QQ群:832276834  微博官方号:道客多多官方   知乎号:道客多多

    Copyright© 2025 道客多多 docduoduo.com 网站版权所有世界地图

    经营许可证编号:粤ICP备2021046453号    营业执照商标

    1.png 2.png 3.png 4.png 5.png 6.png 7.png 8.png 9.png 10.png



    收起
    展开