请选择 进入手机版 | 继续访问电脑版

快速熟悉 Oracle AWR 报告解读

[复制链接]
苍野狼步 发表于 2021-1-2 19:45:30 | 显示全部楼层 |阅读模式 打印 上一主题 下一主题
目次

 
  本文面向没有太多 Oracle 底子知识,但是需要通过 AWR 陈诉来分析数据库性能或排盘问题人员,通过对 AWR 陈诉的简介,相识其包罗的主要信息,然后对一些可以大概资助我们分析定位问题的章节做一点稍微详细的先容。通过阅读本文,盼望使读者可以大概快速抓住阅读 AWR 陈诉的重点,为分析判定命据库性能是否有问题提供资助。
  本文示例陈诉基于 Oracle 11.2.0.3.0 版本生成。
AWR陈诉简介

AWR是Oracle 10g版本推出的特性,全称叫做 Automatic Workload Repository 全自动负载信息库 。Oracle启动后,会有背景进程定时收罗并生存系统快照信息,也可以手工创建快照。AWR通过对比两个时间点的快照信息,生成该时间段的AWR陈诉,资助DBA或开发人员相识 Oracle 数据库的运行情况。Oracle 还提供了 ASH、ADDM等工具,本文不举行探讨。
AWR陈诉布局

AWR陈诉根天职为四部门:


  • 根本信息部门,包罗了DB实例、主机的信息以及陈诉收罗时间段的信息。
  • Main Report部门,第一部门Report Summary被单独放在了根本信息背面,其他的信息则放在整个陈诉较后的位置,个人以为最重要的部门是SQL Statistcs。
  • RAC statistics部门,包罗RAC相关的统计信息。
  • Wait Event Statistics部门。

根本信息

陈诉一开始部门为根本信息,显示了DB实例、主机信息。DB Time 指标可以用来判定命据库是否繁忙,如果 Elapsed 时间乘以CPU个数小于DB Time 体现数据库比力繁忙。

Report Summary

Report Summary 分为8个部门,最主要的是 Load Profile。

Load Profile 主要用来显示当前系统的一些指示性能的总体参数,部门先容如下:


  • Redo Size :用来显示均匀每秒的日志巨细平静均每个事务的日志巨细,有时候可以联合 Transactions 每秒事务数,分析当前事务的繁忙水平
  • Logical Read:逻辑读耗CPU,主频和CPU核数都很重要,逻辑读高则DB CPU往往高,也往往可以看到 latch: cache buffer chains 期待。
  • Physical Read:物理读消耗IO读,体现在IOPS和吞吐量等差异纬度上。但淘汰物理读大概意味着消耗更多CPU。
  • Parses:分析次数,包罗软分析 + 硬分析,软分析优化得欠好险些即是每秒SQL执行次数, 即执行分析比1:1。理想状态是分析一次随处运行。
  • Hard Parses:硬分析次数,最好少于没秒20次。
  注意 Load Profile 中的指标提供了 Per second 和 Per transaction 两个维度。Per second 主要是把快照抓到的值除以两个快照之间的秒数。这是我们用来判定性能的主要维度。Per transaction 是基于事务的维度,主要是把快照抓到的值除以两个快照之间的事务数。

Instance Efficiency Percentages 是一些掷中率指标。Buffer Hit、Library Hit 等体现SGA ( System global area )的掷中率。Soft Parse 指标体现共享池的软分析率,如果小于90%,就说明存在未绑定变量的情况。这些指标应当尽大概靠近100%,如果过低一定是发生了性能问题。
<ul>Buffer Nowait ** 体现在内存得到数据的未期待比例。在缓冲区中获取Buffer的未期待比率。Buffer Nowait的这个值一般需要大于99%**。否则大概存在争用,可以在背面的期待事件中进一步确认。
Buffer Hit 体现进程从内存中找到数据块的比率,监视这个值是否发生重大变革比这个值自己更重要。对于一般的OLTP系统,如果此值低于80%,应该给数据库分配更多的内存。数据块在数据缓冲区中的掷中率,通常应在95%以上。
Redo NoWait 体现在Log 缓冲区得到Buffer的未期待比例。如果太低可思量增加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 Cache确定是否存在分析过的版本,如果存在Oracle立刻执行语句;如果不存在Oracle分析此语句,并在Library Cache中为它分配共享SQL区。低的Library Hit Ratio会导致过多的分析,增加CPU消耗,低沉性能。如果Library Hit Ratio低于90%,大概需要调大Shared pool区。
Latch Hit:Latch是一种掩护内存布局的锁,可以认为是Server进程获取访问内存数据布局的许可。要确保Latch Hit>99%,否则意味着Shared Pool latch争用,大概由于未共享的SQL,大概Library Cache太小,可使用绑定变动或调大Shared Pool管理。要确保>99%,否则存在严重的性能问题。当该值出现问题的时候,我们可以借助背面的期待时间和latch分析来查找管理问题。
Parse CPU to Parse Elapsd:分析实际运行时间/(分析实际运行时间+分析中期待资源时间),越高越好。如果该比率为100%,意味着CPU期待时间为0,没有任何期待。
Non-Parse CPU :SQL实际运行时间/(SQL实际运行时间+SQL分析时间),太低体现分析消耗时间过多。如果这个值比力小,体现分析消耗的CPU时间过多。
Execute to Parse:是语句执行与分析的比例,如果要SQL重用率高,则这个比例会很高。该值越高体现一次分析后被重复执行的次数越多。
In-memory Sort:在内存中排序的比率,如果过低说明有大量的排序在暂时表空间中举行。思量调大PGA(10g)。如果低于95%,可以通过适当调大初始化参数PGA_AGGREGATE_TARGET大概SORT_AREA_SIZE来管理,注意这两个参数设置作用的范围时差异的,SORT_AREA_SIZE是针对每个session设置的,PGA_AGGREGATE_TARGET则时针对所有的sesion的。
Soft Parse:软分析的百分比(Softs/Softs+Hards),近似当作sql在共享区的掷中率,太低则需要调解应用使用绑定变量。sql在共享区的掷中率,小于
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则


专注素材教程免费分享
全国免费热线电话

18768367769

周一至周日9:00-23:00

反馈建议

27428564@qq.com 在线QQ咨询

扫描二维码关注我们

Powered by Discuz! X3.4© 2001-2013 Comsenz Inc.( 蜀ICP备2021001884号-1 )