《ORACLE性能AWR报告的使用和分析》由会员分享，可在线阅读，更多相关《ORACLE性能AWR报告的使用和分析（9页珍藏版）》请在金锄头文库上搜索。
1、本文格式为Word版，下载可任意编辑ORACLE性能AWR报告的使用和分析 ORACLE性能诊断AWR报告的使用和分析 为得志业务的运行要求，高性能要求是目前IT系统普遍面临的最难办问题，尤其是客户面对着目前越来越浩瀚系统和数据，系统整合、数据大集中貌似成了趋势。针对系统性能优化的诊断和分析，数据库方向又是其中的重要一环，本文将针对ORACLE中常用的性能诊断工具AWR报告，举行分析说明。 一、 ORACLE性能诊断工具 ORACLE数据库的性能的诊断工具有好多种，在9i之前主要通过手工举行采集分析，例如使用动态视图和Statspack报告来获取数据库性能状态信息，10g以后ORACLE数据库
2、的性能诊断和提升建议越来越自动化，不过能够熟谙并掌管ORACLE的相关性能诊断工具的使用，仍对性能问题的切实和有效处理供给有利的扶助。以下是ORACLE中常用的一些分析工具。 ? 动态性能视图 动态性能视图是ORACLE中最常用，也是最简朴的一种工具。无论何种性能问题，都能在动态性能视图中找到线索，不过仅10g中动态性能视图就高达几百个，每个视图都包括好多诊断信息，想在众多的视图中找到问题的根源，也是一件吃力的事情。一般常用的动态性能视图有：v$session、v$session_wait、v$process、v$sql、v$lock、v$latch、v$sysstat、v$system_ev
3、ent、v$sgastat。 ? Statspack报告 statspack 是Oracle 9i 之前使用的一个数据库收集工具，收集了数据库全面信息，包括负载概览、前五个等待事情、高速缓存的大小、共享池中SQL语句、表空间和文件I/O、库高速缓存、SGA统计等。 ? AWR和ADDM报告 AWR是10g以后供给的一个新工具，Oracle 建议用户用这个取代 Statspack，它采集与性能相关的统计数据，并从那些统计数据中导出性能量度，以跟踪潜在的问题，并自动生成ADDM（自动数据库诊断监控）报告，为用户供给数据库性能诊断分析建议。 ? SQL执行筹划和建议 数据库中SQL的执行效率可能是对
4、系统影响最大的一个因素，利用ORACLE执行筹划的分析，可以切实知道SQL执行的代价，并供给多个方面的调整建议，来举行SQL代码的优化分析。 二、 生成AWR报告 以下，本文将针对oracle10g后供给的常用性能分析报告AWR，依此来描述和分析数据库的性能点和优化建议。 AWR由ORACLE自动产生，默认30分钟采集一次，留存5天的记录。但是也可以通过DBMS_WORKLOAD_REPOSITORY包来手工创造、删除和修改。使用脚本awrrpt.sql或awrrpti.sql来查看AWR报告，这两个脚本都在目次$ORACLE_HOME/rdbms/admin中，报告可以保存为文本文件或HTM
5、L文件。 生成AWR报告的步骤如下： sqlplus sys/sys127.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-2022-10-29.html （注：报告生成的名称和位置）
6、三、 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、 这个数值对比重
7、要，它表示用户操作花费的时间，包括cpu和等待事情。有时候DB Time会比Elapsed 表示采集是实例连接的会话数，这个数可以让我们了解数据库并发用户的约莫处境。假设是新接手的数据库，对判 时间要长。由于AWR是一个数据的合集，譬如说1分钟内一个用户等待10秒钟，那么10个用户是300秒（5分钟）；cpu的时间也是一样一分钟之内，一个cpu处理30秒，那么4个cpu就是1.2分钟，8个就是2.4分钟，这些都以累计的方式记录在awr报告当中的。 AWR报告总览包括了五个片面：缓存尺寸（Cache Sizes）、负载性能（Load Profile）、数据库效率（Instance Efficie
8、ncy 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）和数据字典缓存（dic
9、tionary cache）。Library cache存放了最近执行的SQL语句、存储过程、函数、解析树以及执行筹划等。而dictionary cache那么存放了在执行SQL语句过程中，所参照的数据字典的信息，包括SQL语句所涉及的表名、表的列、权限信息等。 2) 负载性能（Load Profile） 这个片面记录了数据库负载处境，十足值的分析意义不大，需要与之前的基线数据对比才具有更多的意义，单个的报告数据只说明应用的负载处境，绝大多数据并没有一个所谓“正确”的值。其中重要的几个对于Logons大于每秒12个，说明可能有争用问题；对于Hard parses大于每秒100，parses大于
10、每秒300，说明硬解析太多，SQL重用率不高，需要解决SQL代码变量绑定问题，并调整共享池参数、调整cursor_sharing参数；对于Sorts大于每秒100，说明排序过多，需要裁减SQL代码中排序操作，或调整排序空间。 Logons: Logons show how many users are logged onto the database per second 这个表里理应提防： 1）logical reads和physical reads，同时也可以得到平均每个规律读导致多少物理读，即19.1/37410.4=0.05%。平均每个事务产生了9040.68个规律读，这个数字理应越小
11、越好。 2）parses 和hard parses：从表中可以看到cpu平均每秒举行了81.24个解析（超过100个理应留神），每秒举行5.39（超过10个理应留神）次硬解析，即cpu每秒要处理5.39个全新的sql。 3) 数据库效率（Instance Efficiency Percentages） 记录了Oracle关键指标的内存命中率及数据库实例其它操作的效率，这个片面回响了数据库中最重要指标的命中率。 ? 缓冲区未等待率(buffer nowait %)：指在缓冲区中获取buffer的未等待比率。 ? 该指标的值应接近100%，假设该值较低，那么可能要增大buffer cache,，不
12、理应低 于99%。 ? redo缓冲区未等待率(redo nowait %)：指在redo缓冲区获取buffer的未等待比率。 ? 该指标的值应接近100%，假设该值较低，那么有2种可能的处境： ? 1）online redo log没有足够的空间； ? 2）log切换速度较慢。 ? 缓冲区命中率(buffer hit %)：指数据块在数据缓冲区中的命中率。 ? 该指标的值通常应在90%以上（不理应低于99%），否那么，需要调整。假设持续小 于90%，可能要加大db_cache_size。但有时，缓存命中率低并不意味着cache设置小了，可能是潜在的全表扫描降低了缓存命中率。 ? 内存排序率(
13、in-memory sort %)：指排序操作在内存中举行的比率。该指标的值应接近 100%，假设指标的值较低，那么表示展现了大量排序时的磁盘i/o操作，可考虑加大sort_area_size参数的值。 ? 共享区命中率(library hit %)：该指标主要代表sql在共享区的命中率。该指标的值通常 应在95%以上，否那么需要考虑加大共享池（修改shared_pool_size参数值），绑定变量，修改cursor_sharing等参数。 ? 软解析的百分比(soft parse %)：该指标是指oracle对sql的解析过程中，软解析所占的 百分比。 ? 该指标的值通常应在95%以上，假设
14、低于80%，那么就可能sql根本没被重用，sql 没有绑定变量，需要考虑绑定变量。 ? 闩锁命中率(latch hit %)：指获得latch的次数与苦求latch的次数的比率。 ? 该指标的值应接近100%，假设低于99%，需要分析闩锁竞争，明确是应用锁、数 据字典锁、内存操纵锁的哪一种。通过进一步分析Latch Statistics章节或动态性能视图v$session_wait,v$latch,v$latch_children。 ? sql语句执行与解析的比率(execute to parse %)：指sql语句执行与解析的比率。该指 标的值应尽可能到高，假设过低，可以考虑设置sessio
15、n_cached_cursors参数。 ? % Non-Parse CPU: 说明花费在十几工作的时间和花费在解析上的时间的比较 ? execute to parse%，说明sql语句执行与解析的比率 4) 共享池统计（Shared Pool Statistics） 记录了在采集点时刻，共享池（share pool）内存被使用的比例。这个指标的值应保持在75%90%,假设这个值太低，就滥用内存，假设太高，会使共享池外部的组件老化，假设sql语句被再次执行，那么就会发生硬分析。其中执行次数大于1的sql比率（SQL with executions1），假设此值太小，说明需要在应用中更多使用绑定变量，制止过多SQL解析。 9
