ORACLE性能诊断AWR报告的使用和分析
为满足业务的运行要求,高性能要求是目前IT系统普遍面临的最棘手问题,尤其是客户面对着目前越来越庞大系统和数据,系统整合、数据大集中似乎成了趋势.针对系统性能优化的诊断和分析,数据库方向又是其中的重要一环,本文将针对ORACLE中常用的性能诊断工具AWR报告,进行分析说明.
一、ORACLE性能诊断工具
ORACLE数据库的性能的诊断工具有很多种,在9i之前主要通过手工进行采集分析,例如使用动态视图和Statspack报告来获取数据库性能状态信息,10g以后ORACLE数据库的性能诊断和改进建议越来越自动化,不过能够熟悉并掌握ORACLE的相关性能诊断工具的使用,仍对性能问题的准确和有效处理提供有利的帮助.以下是ORACLE中常用的一些分析工具。
动态性能视图
动态性能视图是ORACLE中最常用,也是最简单的一种工具。无论何种性能问题,都能在动态性能视图中到线索,不过仅10g中动态性能视图就高达几百个,每个视图都包括很多诊断
信息,想在众多的视图中到问题的根源,也是一件费力的事情.一般常用的动态性能视图有:v$session、v$session_wait、v$process、v$sql、v$lock、v$latch、v$sysstat、v$system_event、v$sgastat。
Statspack报告
statspack 是Oracle 9i 之前使用的一个数据库收集工具,收集了数据库全面信息,包括负载概览、前五个等待事件、高速缓存的大小、共享池中SQL语句、表空间和文件I/O、库高速缓存、SGA统计等。
AWR和ADDM报告
AWR是10g以后提供的一个新工具,Oracle 建议用户用这个取代 Statspack,它采集与性能相关的统计数据,并从那些统计数据中导出性能量度,以跟踪潜在的问题,并自动生成ADDM(自动数据库诊断监控)报告,为用户提供数据库性能诊断分析建议。
SQL执行计划和建议
数据库中SQL的执行效率可能是对系统影响最大的一个因素,利用ORACLE执行计划的分析,可以准确知道SQL执行的代价,并提供多个方面的调整建议,来进行SQL代码的优化分析.
二、生成AWR报告
以下,本文将针对oracle10g后提供的常用性能分析报告AWR,依此来描述和分析数据库的性能点和优化建议。
AWR由ORACLE自动产生,默认30分钟采集一次,保留5天的记录.但是也可以通过DBMS_WORKLOAD_REPOSITORY包来手工创建、删除和修改.使用脚本awrrpt.sql或awrrpti。sql来查看AWR报告,这两个脚本都在目录$ORACLE_HOME/rdbms/admin中,报告可以保存为文本文件或HTML文件。
生成AWR报告的步骤如下:
sqlplus sys/sys@127。0.0。1/scmis as sysdba
SQL> @c:/oracle/product/10.2。4/db_1/RDBMS/ADMIN/awrrpt.sql
输入 report_type 的值:html    (注:确定报告的格式)
输入 num_days 的值:1    (注:选择快照的天数)
输入 begin_snap 的值:425    (注:起始快照)
输入 end_snap 的值:427    (注:结束快照)
输入 report_name 的值:d:\scmis—awr—2011—10-29。html    (注:报告生成的名称和位置)
三、AWR报告分析
AWR报告头记录了数据库名称和起始快照时间,报告头中主要分析Elapsed(总时间)和DB Time(DB消耗的时间,不包括后台进行的消耗时间),如果DB Time/Elapsed比值较大,说明数据库系统压力较大,例如下图中系统包括16CPU(2*8核),每个cpu耗时26.7min,负载为26.7/60.03=44.5%,说明数据库服务器存在较大的负荷。
即:427。44/60.3*16*100% = 44。5%
1、  sessions
表示采集是实例连接的会话数,这个数可以让我们了解数据库并发用户的大概情况。如果是新接手的数据库,对判断数据库的类型可以做参考
2、  Cursors/Session,平均每个会话卡开的游标数。
3、  DB Time
4、  这个数值比较重要,它表示用户操作花费的时间,包括cpu和等待事件.有时候DB Tim
e会比Elapsed时间要长。因为AWR是一个数据的合集,比如说1分钟内一个用户等待10秒钟,那么10个用户是300秒(5分钟);cpu的时间也是一样一分钟之内,一个cpu处理30秒,那么4个cpu就是1。2分钟,8个就是2.4分钟,这些都以累计的方式记录在awr报告当中的.
AWR报告总览包括了五个部分:缓存尺寸(Cache Sizes)、负载性能(Load Profile)、数据库效率(Instance Efficiency Percentages)、共享池统计(Shared Pool Statistics)、TOP5事件(Top 5 Timed Events).这五个部分也就是整个报告核心,记录了数据库系统的关键性能参数和状况。
1)缓存尺寸(Cache Sizes)
主要记录总的缓存大小Buffer Cache和SGA缓存尺寸Shared Pool Size,SGA是ORACLE中非常重要的内存共享区,对系统内的所有进程都是共享的。当多个用户同时连接到一个例程时,所有的用户进程、服务进程都可以共享使用这个SGA区。Shared pool可以分为库缓存(library cache)和数据字典缓存(dictionary cache).Library cache存放了最近执行的SQL语句、存储过程、函数、解析树以及执行计划等.而dictionary cache则存放了在执行S
QL语句过程中,所参照的数据字典的信息,包括SQL语句所涉及的表名、表的列、权限信息等。
2)负载性能(Load Profile
这个部分记录了数据库负载情况,绝对值的分析意义不大,需要与之前的基线数据比较才具有更多的意义,单个的报告数据只说明应用的负载情况,绝大多数据并没有一个所谓“正确”的值.其中重要的几个对于Logons大于每秒1~2个,表明可能有争用问题;对于Hard parses大于每秒100,parses大于每秒300,表明硬解析太多,SQL重用率不高,需要解决SQL代码变量绑定问题,并调整共享池参数、调整cursor_sharing参数;对于Sorts大于每秒100,表明排序过多,需要减少SQL代码中排序操作,或调整排序空间。
Logons  Logons show how many users are logged onto the database per second
这个表里应该注重:
1logical readsphysical reads,同时也可以得到平均每个逻辑读导致多少物理读,即19。1/37410。4=0。05%.平均每个事务产生了9040.68个逻辑读,这个数字应该越小越好.
2parses hard parses:从表中可以看到cpu平均每秒进行了81。24个解析(超过100个应该注意),每秒进行5.39(超过10个应该注意)次硬解析,即cpu每秒要处理5。39个全新的sql.
3)数据库效率(Instance Efficiency Percentages
记录了Oracle关键指标的内存命中率及数据库实例其它操作的效率,这个部分反应了数据库中最重要指标的命中率。
缓冲区未等待率(buffer nowait %):指在缓冲区中获取buffer的未等待比率.
该指标的值应接近100%,如果该值较低,则可能要增大buffer cache,不应该低于99
redo缓冲区未等待率(redo nowait %):指在redo缓冲区获取buffer的未等待比率。
该指标的值应接近100%,如果该值较低,则有2种可能的情况:
1)online redo log没有足够的空间;
2)log切换速度较慢。
缓冲区命中率(buffer hit %):指数据块在数据缓冲区中的命中率。
该指标的值通常应在90%以上(不应该低于99%),否则,需要调整.如果持续小于90%,可能要加大db_cache_size。但有时,缓存命中率低并不意味着cache设置小了,可能是潜在的全表扫描降低了缓存命中率.
内存排序率(in-memory sort %):指排序操作在内存中进行的比率。该指标的值应接近100%,如果指标的值较低,则表示出现了大量排序时的磁盘i/o操作,可考虑加大sort_area_size参数的值。
共享区命中率(library hit %):该指标主要代表sql在共享区的命中率。该指标的值通常应
在95%以上,否则需要考虑加大共享池(修改shared_pool_size参数值),绑定变量,修改cursor_sharing等参数。
软解析的百分比(soft parse %):该指标是指oracle对sql的解析过程中,软解析所占的百分比。
该指标的值通常应在95%以上,如果低于80%,那么就可能sql基本没被重用,sql没有绑定变量,需要考虑绑定变量。
闩锁命中率oracle游标的使用(latch hit %):指获得latch的次数与请求latch的次数的比率。
该指标的值应接近100%,如果低于99%,需要分析闩锁竞争,明确是应用锁、数据字典锁、内存控制锁的哪一种。通过进一步分析Latch Statistics章节或动态性能视图v$session_wait,v$latch,v$latch_children
sql语句执行与解析的比率(execute to parse %):指sql语句执行与解析的比率。该指标的值应尽可能到高,如果过低,可以考虑设置session_cached_cursors参数。

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。