开 Oracle 调节敌鹰眼 ， 深入理解AWR 能力报告 - 第二讲

开Oracle调优鹰眼，深入理解AWR性能报告- 第二讲刘相兵(Maclean Liu) liu. maclean @ gmail. comORA - ALLSTARS Exadata用QQ群:23549328 关于我博客 ： www. askmaclean. com Oracle 认证数据库管理员 Master 10g 和 11g 7 年以上 Oracle DBA 技术经验 8 年以上 Linux 技术经验独立成员 Oracle 用户组所有中国用户组成员介绍高级 Oracle 主题 ： RAC 、 DataGuard 、性能调整和 Oracle 内部。 关于我 大侠请循序渐进，别漏了第一讲：2086 - 1 - 1. html 鹰眼看AWR的鹰眼= 基础理论夯实+看过500份以上AWR 预备知识- CPU 插座插座 物理CPU数目 预备知识- CPU 内核核心 CPU核数一个物理CPU可以对应多个核心 预备知识- CPU这里的CPU数是指逻辑CPU数（ 可用逻辑 CPU 的数量 （ 如果硬件线程已打开 ， 则包括硬件线程 ） ）当硬件线程技术打开时，例如：英特尔 HT （ 超线程 ） POWER SMT （ 同时多线程 ）此时一个CPU 核心被视作2个或更多个逻辑CPUNUM _ LCPUS仅在11.2.0.2之后的报告中出现 主机 CPU“平均负载 ” 开始 / 结束值代表CPU的大致运行队列大小。上图中快照开始CPU负载增加了。% User +% System = >总的CPU使用率，在这里是29.0%经过的时间 * NUM _ CPUS * CPU 利用率 = 299.70 （ 分钟 ） * 64 * 29 ％ = 5562.4 分钟 = 忙碌时间与《操作系统统计信息》中的LOAD相呼应 实例 CPU% 总 CPU, 该事实所利用的 CPU 占总 CPU 的比例 占总 CPU 的百分比实例% Busy CPU ， 该事实所利用的 Cpu 占总的被利用 CPU 的比例 % 的实例繁忙 CPU例如共4个逻辑CPU，其中3个被完全使用，3个中的1个完全被该实例使用，总 CPU 百分比 = ？ = 25%，而% 繁忙 CPU = 1 / 3 = 33%当CPU高时一般看% CPU 繁忙可以确定CPU到底是否是本实例消耗的，还是主机上其他程序 % 的实例繁忙 CPU实例的繁忙 CPU 百分比 =（DB CPU + 后台 CPU 时间) / (BUSY _ TIME / 100) = (250, 777.19 + 7, 195.70) / (33, 448, 718 / 100) = 77.1% 实例的总 CPU 的百分比实例的总 CPU 百分比 =（DB CPU + 后台 CPU 时间) / ((BUSY _ TIME + IDLE _ TIME) / 100) = (250, 777.19 + 7, 195.70) / ((33, 448, 718 + 81, 844, 586 / 100) = 22.4% 等待 CPU 的% DB 时间 (资源管理器)等待 CPU （ 资源管理器 ） 的% DB 时间 = (RSRC _ MGR _ CPU _ WAIT _ TIME / 100) / DB TIME = (138, 776, 449 / 100) / (61, 052* 60)= 37.88% 真实案例resmgr: cpu 量子resmgr: cpu 量子等待事件是当资源管理器控制CPU调度时，需要CPU而进程到内部运行队列中，以保证该进程对应的消费者组 (消费组)没有消耗比指定资源管理器指令更多的CPU。 操作系统统计信息数据来源于V $OSSTATDBA _ HIST _ OSSTAT，, TIME相关Busy _ Time = SYS _ TIME + USER _ TIMEAVG _ BUSY _ TIME = BUSY _ TIME / NUM _ CPUSBUSY _ TIME + IDLE _ TIME = ELAPSED _ TIME * CPU _ COUNT = 299.7 * 60 * 64 = 1150848s = (33, 448, 718 + 81, 844, 586) / 100OS _ CPU _ WAIT _ TIME进程等操作系统调度，CPU 队列 VM _ IN _ BYTES 2.6 GB PGAE INVM _ OUT _ BYTES 3.6 GB PGAE OUT部分版本下并不准确，例如错误 11712010 摘要 ： 11.2. 0.2 数据库上的虚拟内存分页，仅供参考 内存统计信息11g以后才有的一个节，可以了解SGA、PGA、主机物理内存的大致使用情况。如上例PGA在快照时间内从23677MB增长到26301MB ， pga _ aggregate _ target = 16GB，存在overalloc用于 SGA + PGA 的主机内存%可以大致反映本实例占用主机物理内存的情况。注意主机 Mem也可能起伏，如使用DLPAR时 时间模型统计时间模型统计几个特别有用的时间指标：• 经过的解析时间、硬解析经过时间结合起来看解析是否是主要矛盾，若是则重点是软解析还是硬解析• 顺序荷载经过时间顺序序列争用是否是问题焦点• PL / SQL 编译经过时间 PL / SQL对象编译• 注意PL / SQL 执行经过时间纯耗费在PL / SQL解释器上的时间。不包括花在执行和解析其包含SQL上的时间 时间模型统计• 连接管理呼叫已用时间建立数据库会话连接和断开• 解析失败经过时间解析失败，例如由于ORA - 4031• 硬解析 （ 共享标准 ） 经过时间由于无法共享游标造成的硬解析• 硬解析 （ 绑定不匹配 ） 经过时间由于绑定类型或绑定大小不一致造成的硬解析 时间模型统计树形图存在包含关系所以时间模型统计加起来超过100%再正常不过 操作系统统计信息 - 详细信息每个快照对应一行记录，简易了解操作系统负载情况针对CPU 尖峰毛刺问题有点用，也可看做大致的cpu走势虽然替代不了nmon、osw，但胜在AWR自带。特别是对哪些没任何操作系统性能监控的”处女环境”来说是个宝。 等待类SQL > 从 v $event _ name 中选择不同的 wait _ class;WAIT _ CLASS并发用户 I / O 系统 I / O 管理其他配置调度程序群集应用程序排队空闲网络提交选择 name, wait _ class 从 v $event _ name 中排序 2; AWR RAC特定环节RAC 缓存融合我为人人，人人为我 预备知识-纵览RAC AWR 预备知识- 全局缓存等待事件全局缓存传输就像巧克力，若不打开，你永远不知道下一颗是什么？ RAC 全局缓存负载配置文件（RAC特有)真实大型：应用的一个例子，0.03%的的逻辑读由其他节点上的缓存满足全局缓存接收 / 服务器的原因一般是节点间缓存争用或本地无此缓存(接收 + 发送) * db _ block _ size = 901 * 8k = 7.04 MB / s = 56.32 Mb / s注意这仅仅是粗略估算，一般建议专用网络选用10 Gb带宽一条GCS / GES 消息大约200 字节 RAC 全局缓存负载配置文件（RAC特有)评估的发送流量(MB) = (((GES _ SENT + GCS _ SENT) * 200) + ((CR _ SENT + CURRENT _ SENT) * BLOCK _ SIZE) * 1.2 * 8 / 1048576Estd 互连流量 （ KB ） = （ （ 'gc cr 接收块' + 'gc 当前块接收' + 'gc cr 块服务 '+' gc 当前服务块 ') * 块大小)+ (('gcs 消息已发送' + 'gcs 消息已发送' + 'gcs 消息已收到' + 'gcs 消息已收到') * 200) / 1024 / 已用时间11g DBA _ HIST _ IC _ DEVICE _ STATS、 DBA _ HIST _ CLUSTER _ INTERCON反应专用网络性能的2个维度：)可用带宽b)网络延迟 EM监控群集互连•比你手动去查效率高•并可定制互连告警 全局缓存效率百分比 (目标本地 + 远程 100%)（RAC特有)对 RAC 而论响应时间响应时的要求比单节点更高 ， 所别别的期望用 <unk> 硬件 <unk> 出的 RAC 性能比单好 !如果互连的网络延迟 > IO子系统的延迟，那么RAC本身就是性能瓶颈但是IO响应时间对RAC也非常重要，例如上一讲中所述日志文件同步 = > gc 缓冲区忙，所以千万别用垃圾储存去搭RAC!! 全局缓存效率百分比 (目标本地 + 远程 100%)（RAC特有)平均全局缓存 cr 块接收时间 (毫秒): 0.7平均全局缓存当前块接收时间 (毫秒): 1.0至关重要的2个指标，结合其他节点的AWR报告一起分析这2个指标， 一般要求小2ms若在RAC实例之间这2个指标差异很大，一般说明互连问题出现于操作系统缓冲区层或者网卡上 平均全局缓存 cr 块接收时间 (毫秒)该指标反映平均每个全局 cr块从申请到收到的耗时平均全局缓存 cr 块接收时间 (ms) = 10 * gc cr 块接收时间 / gc cr 块接收 = 228, 252 / 134, 978 * 10 = 16.91 ms在缓存中处理 CR 块请求的时间 = (构建时间 + 刷新时间 + 发送时间)相关指标：•gc cr 块冲洗时间•gc cr 块构建时间•gc cr 块发送时间 平均全局缓存当前块接收时间 (毫秒)该指标反映平均每个全球电流块从申请到收到的耗时平均全局缓存 cr 块接收时间 (ms) = 10 * gc 当前块接收时间 / gc 当前块接收时间 = 116, 862 / 790, 899 * 10 = 1.47 ms在缓存中处理当前块请求的时间 = (引脚时间 + 刷新时间 + 发送时间)相关指标：•gc 电流块引脚时间•gc 电流块冲洗时间•gc 当前块发送时间 群集缓存一致性 Apex - High 集群等待真实案例平均全局 cr / 当前块接收时间高 本实例出现大量群集等待平均全局缓存固定 / 发送 / 刷新时间高 本实例服务器全局缓存也不给力啊，其他节点的性能大致也和此处一副德性 Apex - High 集群等待真实案例平均消息已发送队列时间一条信息进入队列到发送它的时间上的平均消息发送队列时间ksxp对端收到该信息并返回ACK的时间，这个指标很重要，直接反应了网络延迟，一般小于1ms发送消息有2种方式：kjccsmg () - 发送消息 (FG 直接发送) kjccqmg () - 队列消息 (LMS 间接发送)% 的间接发送的消息 间接发送信息一般是排序或大的信息，流控制也可能引起间接发送消息% 的流控制消息 流控制最常见的原因是网络状况不佳， % 流量受控消息应当小于1% Apex - High 集群等待真实案例大量群集等待，平均每次等241ms，而一个事务平均等9.2次，则一个事务平均等群集 2秒，换句话说如果不是RAC，每个事务提速2s!!群集等待并不孤立，会影响应用程序类型的enq: TX - 行锁争用等待事件出现的频率和单次等待耗时如上例中 平均 每个事务要等一次的enq: TX - 行锁定内容，每次平均耗时0.5 s，100~200个会话等在enq: TX和gc 缓冲区忙上很壮观哦！ 待解冻的 gcs 资源目录真实案例待解冻的 gcs 资源目录与DRM有直接关系 某银行 gc cr 块丢失真实案例 某银行 gc cr 块丢失真实案例Ierrs 是系统识别为已损坏的接收数据包的数量。全局缓存问题一定要和操作系统和网络层结合起来看，ifconfig、netstat、sy