Oracle的AWR报告分析

* 定义:awr报告是oracle 10g下提供的一种性能收集和分析工具,它能提供一个时间段内整个系统资源使用情况的报告,通过这个报告,我们就可以了解一个系统的整个运行情况,这就像一个人全面的体检报告。 如何分析: * 在看awr报告的时候,我们并不需要知道所有性能指标的含义,就可以判断出问题的所在,这些性能指标其实代表了oracle内部实现,对oracle理解的越深,在看awr报告的时候,对数据库性能的判断也会越准确 * 在看性能指标的时候,心里先要明白,数据库出现性能问题,一般都在三个地方,io,内存,cpu,这三个又是息息相关的(ps:我们先假设这个三个地方都没有物理上的故障),当io负载增大时,肯定需要更多的内存来存放,同时也需要cpu花费更多的时间来过滤这些数据,相反,cpu时间花费多的话,有可能是解析sql语句,也可能是过滤太多的数据,到不一定是和io或内存有关系了 * 当我们把一条sql送到数据库去执行的时候,我们要知道,什么时候用到cpu,什么时候用到内存,什么时候用到io 1. cpu:解析sql语句,尝试多个执行计划,最后生成一个数据库认为是比较好的执行计划,不一定是最优的,因为关联表太多的时候,数据库并不会穷举所有的执行计划,这会消耗太多的时间,oracle怎么就知道这条数据时你要,另一个就不是你要的呢,这是需要cpu来过滤的 2. 内存:sql语句和执行计划都需要在内存保留一段时间,还有取到的数据,根据lru算法也会尽量在内存中保留,在执行sql语句过程中,各种表之间的连接,排序等操作也要占用内存 3. io:如果需要的数据在内存中没有,则需要到磁盘中去取,就会用到物理io了,还有表之间的连接数据太多,以及排序等操作内存放不下的时候,也需要用到临时表空间,也就用到物理io了 这里有一点说明的是,虽然oracle占用了8G的内存,但pga一般只占8G的20%,对于专用服务器模式,每次执行sql语句,表数据的运算等操作,都在pga中进行的,也就是说只能用1.6G左右的内存,如果多个用户都执行 多表关联,而且表数据又多,再加上关联不当的话,内存就成为瓶颈了,所有优化sql很重要的一点就是,减少逻辑读和物理读

如何生成awr报告: * 1:登陆对应的数据库服务器 2:找到oracle磁盘空间(d:oracle\product\10.2.0\db_1\RDBMS\Admin) 3:执行cmd-cd d:回车 4: cd d:oracle\product\10.2.0\db_1\RDBMS\Admin 回车 5:sqlplus 用户名/密码@服务连接名(例:sqlplus carmot_esz_1/carmot@igrp) 6:执行@awrrpt.sql 回车 第一步输入类型: html 第二步输入天数: 天数自定义(如1,代表当天,如果2,代表今天和昨天。。。) 第三步输入开始值与结束值:(你可以看到上面列出的数据,snap值) 这个值输入开始,与结束 第四步输入导出表的名称:名称自定义 回车 第五步,由程序自动导完。 第六:到d:oracle\product\10.2.0\db_1\RDBMS\Admin 目录下。找到刚才生成的文件。 XXXX.LST文件 具体分析过程:  * 在分析awr报告之前,首先要确定我们的系统是属于oltp,还是olap(数据库在安装的时候,选择的时候,会有一个选项,是选择oltp,还是olap) 对于不同的系统,性能指标的侧重点是不一样的,比如,library hit和buffer hit,在olap系统中几乎可以忽略这俩个性能指标,而在oltp系统中,这俩个指标就非常关键了 * 首先要看俩个时间 Elapsed: 240.00 (mins) 表明采样时间是240分钟,任何数据都要通过这个时间来衡量,离开了这个采样时间,任何数据都毫无疑义 DB Time: 92,537.95 (mins) 表明用户操作花费的时候,包括cpu时间喝等待时间,也许有人会觉得奇怪,为什么在采样的240分钟过程中,用户操作时间竟然有92537分钟呢,远远超过了 采样时间,原因是awr报告是一个数据的集合,比如在一分钟之内,一个用户等待了30秒,那么10个用户就等待了300秒,对于cpu的话,一个cpu处理了30秒,16个cpu就是4800秒,这些时间都是以累积的方式记录在awr报告中的。 再看sessions,可以看出连接数非常多 * 为了对数据库有个整体的认识,先看下面的性能指标

1. Buffer Nowait 说明在从内存取数据的时候,没有经历等待的比例,期望值是100% 2. Buffer Hit 说明从内存取数据的时候,buffer的命中率的比例,期望值是100%,但100%并不代表性能就好,因为这只是一个比例而已,举个例子,执行一条 sql语句,# 执行计划是需要取10000个数据块,结果内存中还真有这10000个数据块,那么比例是100%,表面上看是性能最高的,还有一个执行计划是需要500 个数据块,内存中有250个,另外250个需要在物理磁盘中取, 这种情况下,buffer hit是50%,结果呢,第二个执行计划性能才是最高的,所以说100%并不代表性能最好 3. Library Hit 说明sql在Shared Pool的命中率,期望值是100% 4. Execute to Parse 说明解析sql和执行sql之间的比例,越高越好,说明一次解析,到处执行,如果parse多,execute少的话,还会出现负数,因为计算公式是100*(1-parse/execute) 5. Parse CPU to Parse Elapsd 说明在解析sql语句过程中,cpu占整个的解析时间比例,,期望值是100%,说明没有产生等待,需要说明的是,即使有硬解析,只要cpu没有出现性能问题,也是可以容忍的,比较硬解析也有它的好处的 6. Redo NoWait 说明在产生日志的时候,没有产生等待,期望值是100% 7. Soft Parse 说明软解析的比例,期望值是100%,有一点要说明的是,不要单方面的追求软解析的高比例,而去绑定变量,要看性能的瓶颈在哪里 8. Latch Hit 说明latch的命中率,期望值是100%,latch类似锁,是一种内存锁,但只会产生等待,不会产生阻塞,和lock还是有区别的,latch是在并发的情况下产生的 9. Non-Parse CPU 说明非解析cpu的比例,越高越好,用100减去这个比例,可以看出解析sql所花费的cpu,100-99.30=0.7,说明花费在解析sql上的cpu很少 * 结合Time Model Statistics

可以看出,在整个sql执行时间(sql execute elapsed time)时间为5552019秒中,解析时间(parse time elapsed)用了36秒,硬解析时间(hard parse elapsed time)用了34秒虽然硬解析时间占了整个解析时间的绝大部分,但解析时间是花的很少的,所以可以判断出,sql的解析没有成为性能的瓶颈,进一步推测,sql在获取数据的过程中遇到了瓶 颈 * 继续看Top 5 Timed Events,从这里可以看出等待时间在前五位的是什么事件,基本上就可以判断出性能瓶颈在什么地方

1. buffer busy waits 说明在获取数据的过程中,频繁的产生等待事件,很有可能产生了热点块,也就是说,很多会话都去读取同样的数据块,这一事件等待了5627394次,总共等待了5322924秒,平均等待时间为946毫秒,而且频率也是最高的,有95.9%,等待类别是并发 这里有一个概念:oracle操作的最小单位是块,当一个会话要修改这个块中的一条记录,会读取整个块,如果另一个会话要修改的数据也正好在这个块中,虽然这俩个 2. 会话修改的记录不一样,也会产生等待direct path write temp和direct path read temp 说明用到了临时表空间,那我们再看一下Tablespace IO Stats

各项指标都是非常高的,再根据上面的In-memory Sort是100%,没有产生磁盘排序,也就在排序的时候没有用到临时表空间,进一步推测,多个session,每个session执行的sql语句中多表关联,产生了很多中间数据,pga内存中放不下, 用到了临时表空间,也有可能是用到了lob字段,在用lob字段的时候,也会用到临时表 * 继续看SQL Statistics 根据buffer busy waits等待次数,时间,频率都是最高的,我们重点看逻辑读,物理读,和执行时间最长的sql,把排在前几位的拿出来优化 优化的原则为降低物理读,逻辑读,sql语句中的子操作执行次数尽量少,在看oracle估计出来的执行计划是看不出子操作的执行次数的,要看运行时的执行计划 * 有兴趣的话还可以看一下Segment Statistics 列出了用到的索引和表的使用情况,从这里也能看出索引和表的使用频率 * 也可以看一下Load Profile 里面列出了每秒,每个事务所产生的日志,逻辑读和物理读等指标

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏码代码的陈同学

Spring Cloud 网关异常处理实践

有余力可以自建异常处理平台,有一套异常处理流程,有个炫酷且实用的Dashboard。

69820
来自专栏Java后端技术栈

面试必备:如何将一个长URL转换为一个短URL?

前几天整理面试题的时候,有一道试题是《如何将一个很长的URL转换为一个短的URL,并实现他们之间的相互转换?》,现在想起来这是一个绝对不简单的问题,需要考虑很多...

4312
来自专栏社区的朋友们

深入浅出 Nodejs ( 一 ) :Nodejs 的简介

我认为 Node 是一门独具风格的技术,它的特点很有意思,本章我们主要讲 Node 的特点,Node 应用场景以及 Node 的使用者。

6571
来自专栏python开发者

Linux及文件系统基本介绍

Linux及文件系统基本介绍 1   互联网行业现状 在服务器端市场: 超级计算机 2014年11月的数据显示前500系统中的485个系统都在运行着 Linu...

2697
来自专栏FreeBuf

子域名枚举的艺术

写在前面的话 当我们在查找某个域名的有效子域名时,我们通常需要使用子域名枚举这项技术。但是,除非DNS服务器暴露了完整的DNS空间(涉及到AXFR协议),否则我...

4409
来自专栏顶级程序员

什么是 C 和 C ++ 标准库?

简要介绍编写C/C ++应用程序的领域,标准库的作用以及它是如何在各种操作系统中实现的。

2213
来自专栏VMCloud

【解析向】腾讯云的Windows Server日志配置收集工具是个什么鬼?(2)

继上一篇,上一篇重点介绍了腾讯云Windows Server日志收集工具的“场景”功能,那么场景功能究竟是以什么标准来分级的呢?

4277
来自专栏北京马哥教育

Python老司机带你快速搞定日志分析工具

转载自:Python中文社区 ID:python-china 日志分析在web系统中故障排查、性能分析方面有着非常重要的作用。该工具的侧重点不是通常的P...

3245
来自专栏带你撸出一手好代码

神奇的Java

使用java开发一个socket服务器,使用protocol buffer作为和客户端通信的数据格式。然后,问题就来了,这个socket服务器要如何调试?换句话...

1092
来自专栏后端技术探索

另一篇mysql防止库存超卖

今天王总又给我们上了一课,其实MySQL处理高并发,防止库存超卖的问题,在去年的时候,王总已经提过;但是很可惜,即使当时大家都听懂了,但是在现实开发中,还是没这...

1561

扫码关注云+社区

领取腾讯云代金券