《OracleAWR与ASH性能报告深入解析》一数据库版本LEO1@LEO1>select*fromv$version;BANNER--------------------------------------------------------------------------------OracleDatabase11gEnterpriseEditionRelease11.2.0.1.0-64bitProductionPL/SQLRelease11.2.0.1.0-ProductionCORE11.2.0.1.0ProductionTNSforLinux:Version11.2.0.1.0-ProductionNLSRTLVersion11.2.0.1.0-Production二AWR性能诊断报告AWR：AutomaticWorkloadRepository自动工作负载信息库通常在诊断数据库性能的时候分三个阶段第一阶段：SQL语句级性能优化第二阶段：session级性能优化，这时我们可以用ASH来做分析第三阶段：DB级性能优化，AWR就是数据库层性能诊断报告，当我们无法判断数据库哪里性能出现问题时我们可以做一个全身体检报告来找到我们瓶颈所在。AWR机制：通过对系统整体动态采样收集快照信息，存储在SYSAUX表空间，每小时采样一次，可以保存7天，MMON进程实施，快照分析后写入DBA_HIST_%开头的数据字典。AWR信息来源：DBA_HIST_%开头的数据字典，请见下图LEO1@LEO1>selecttable_namefromdictionarywheretable_namelike'DBA_HIST_%';TABLE_NAME------------------------------------------------DBA_HIST_ACTIVE_SESS_HISTORYDBA_HIST_ASH_SNAPSHOTDBA_HIST_BASELINEDBA_HIST_BASELINE_DETAILSDBA_HIST_BASELINE_METADATADBA_HIST_BASELINE_TEMPLATEDBA_HIST_BG_EVENT_SUMMARYDBA_HIST_BUFFERED_QUEUESDBA_HIST_BUFFERED_SUBSCRIBERSDBA_HIST_BUFFER_POOL_STATDBA_HIST_CLUSTER_INTERCONDBA_HIST_COLORED_SQLDBA_HIST_COMP_IOSTATDBA_HIST_CR_BLOCK_SERVERDBA_HIST_CURRENT_BLOCK_SERVERDBA_HIST_DATABASE_INSTANCEDBA_HIST_DATAFILEDBA_HIST_DB_CACHE_ADVICE…………………………………………………109rowsselected.AWR信息就是来自上面这些数据字典表，它是把这些表中数据进行汇总统计后生成HTMLorTXT格式LEO1@LEO1>selectsnap_id,name,valuefromDBA_HIST_SGAwheresnap_id>=173andsnap_id<=174;SNAP_IDNAMEVALUE--------------------------------------------------------------------------------------------------------------------------------------------173DatabaseBuffers117440512173FixedSize2214856173RedoBuffers8052736173VariableSize385877048174DatabaseBuffers117440512174FixedSize2214856174RedoBuffers8052736174VariableSize385877048上面这个例子显示了173-174快照中SGA的信息OEM可以生成图形化性能分析图，UI版AWRAWR基线：我们可以在数据库平稳正常的状态下创建AWR基线（参照物），在实际生产中可以作为性能指标曲线的一个参照物，有了基线对比，我们就可以很方便的了解到系统的一个真实的性能趋势。AWR创建：sqlplus/assystem@下面的脚本就可以创建AWR报告了创建脚本目录：/u01/app/oracle/product/11.2.0/db_1/rdbms/admin/awrrpt.sqlAWR报告分析说明1.WORKLOADREPOSITORYreportfor2.DBNameDBIdInstanceInstnumStartupTimeReleaseRACEMSTA433507400emsta1114-Aug-1222:0811.2.0.2.0YESHostNamePlatformCPUsCoresSocketsMemory(GB)emsta1Solaris[tm]OE(64-bit)64328128.00SnapIdSnapTimeSessionsCursors/SessionBeginSnap:602307-Sep-1214:00:0917882.8EndSnap:602607-Sep-1217:00:0617932.9Elapsed:179.94(mins)DBTime:79.25(mins)数据库名：EMSTADBID：433507400实例名：emsta1第一个实例启动时间版本是RAC主机名：emsta1操作系统平台：Solaris64位64颗CPU32核内存：128GB由上述硬件判断这是2台小机组成的RAC模式数据库，上面的是实例1，下面的是实例2，名称后缀不同。起始快照id：6023终止快照id：6026快照与快照间隔1小时从14：00~17：00一共3小时采样信息起始快照与终止快照间隔时间：180分钟所有用户使用数据库时间总和（累加值）：80分钟起始时间有1788个会话，每个会话使用2.8个游标结束时间有1793个会话，每个会话使用2.9个游标DBNameDBIdInstanceInstnumStartupTimeReleaseRACEMSTA433507400emsta2214-Aug-1222:0811.2.0.2.0YESHostNamePlatformCPUsCoresSocketsMemory(GB)emsta2Solaris[tm]OE(64-bit)64328128.00SnapIdSnapTimeSessionsCursors/SessionBeginSnap:602307-Sep-1214:00:0913633.0EndSnap:602607-Sep-1217:00:0613783.0Elapsed:179.94(mins)DBTime:136.61(mins)实例2中各个部分的含义值和实例1相同，这里不再另外说明2.cachesizeBeginEndBufferCache:15,360M15,360MStdBlockSize:8KSharedPoolSize:6,272M6,272MLogBuffer:111,456KInstance1：数据库缓冲区15360M共享池6272Mredolog缓冲区111.456M数据块大小8KBufferCache:13,696M13,696MStdBlockSize:8KSharedPoolSize:6,144M6,144MLogBuffer:111,456KInstance2：数据库缓冲区13696M共享池6144Mredolog缓冲区111.456M数据块大小8K2个实例的SGA有一点点的大小差异，但是差距不大。3.Loadprofile数据库负载属性信息美秒每个事物每次执行每次调用PerSecondPerTransactionPerExecPerCallDBTime(s):0.40.30.010.00DBCPU(s):0.40.20.010.00Redosize:15,275.98,983.0Logicalreads:13,716.18,065.8Blockchanges:79.246.6Physicalreads:365.3214.8Physicalwrites:4.52.7Usercalls:232.7136.8Parses:11.46.7Hardparses:0.30.2W/AMBprocessed:2.71.6Logons:0.00.0Executes:54.332.0Rollbacks:0.00.0Transactions:1.7Instance1：逻辑读和物理读较多，是以读为主Instance2：物理写较多，是以写为主如果我们有一个基线值，就好比较性能优略了PerSecondPerTransactionPerExecPerCallDBTime(s):0.80.10.000.00DBCPU(s):0.40.10.000.00Redosize:102,788.511,594.5Logicalreads:4,287.6483.6Blockchanges:436.449.2Physicalreads:100.511.3Physicalwrites:40.64.6Usercalls:261.729.5Parses:108.912.3Hardparses:0.10.0W/AMBprocessed:0.90.1Logons:3.10.4Executes:263.129.7Rollbacks:0.00.0Transactions:8.9业务类型不同关注数据指标也不同OLAP：关注IO指标OLTP：关注内存CPU指标4.Top5TimedForegroundEventsInstance1：这是排名前五位的前台等待事件（用户SQL的等待事件）DBCPU：数据库消耗CPU时间（所有用户使用CPU的累加值）Waits：等待了多少次Times：等待了多少秒Avgwait（ms）：平均等待一次多少毫秒%DBtime：占整体数据库时间的百分比，我们看到CPU消耗占了82%，应该解析的SQL语句比较多WaitClass：等待类型Instance2：%DBtime54%也是排名第一，说明解析和执行的SQL语句很多5.CPU&MEMORY统计信息Instance1CPU%Idle：空闲率98%看来CPU的使用率不高啊%BusyCPU：忙时CPU占用53.9%而且CPU等待时间占整体等待时间比例很小SGA+PGA使用率占物理内存的19%，内存空闲空间还很高，我们还可以增加SGA+PGA容量缓存更多的SQLInstance2与Instance1还是很相近的6.RAC性能报告AWR信息太多，这里简要截图举例说明实例数从快照开始到快照结束都是2Instance1每秒全局缓冲区接收块数6个每个事物接收块数3个DBRWFusionwrite0.2写的不是很多，大部分动作都在读Instance2每秒全局缓冲区接收块数21个，这个要比Instance1的多每个事物接收块数2个，比Instance1的少7.按照消耗时间排名Instance1：SQL执行处理时间，消耗时间最多CPU使用时间排第二从这2点可以推断出，这是一个OLTP系统，主要消耗资源在CPU上而不是IO上Instance2：CPU使用时间最多8.ForegroundWaitClass前台进程等待事件（用户触发的）Instance1按等待类型分类：还是CPU消耗的时间最多Instance2：Network资源等待时间较长，说明数据块在2个实例间交叉复制和传输较多9.BackgroundWaitEvents后台进程等待事件（数据库后台进程触发的）这里列举了数据库后台进程的等待事件排名，我们可以看这些来判断哪些资源使用的较多10.InstanceActivityStat实例活跃度IO向量统计排名最多小结：我们从上面的各种指标参数来分析CPU资源消耗的较多，IO资源相对较少，根据不同业务类型关注指标类型不同判断这个RAC系统是一个OLTP系统。（1）.我们首先要了解系统的业务种类AWR报告才能定位准确。（2）.OLTP多关注CPU&MEMORY指标（软硬解析cursor共享绑定变量SGA命中率）OLAP多关注IO指标（物理/逻辑读写一致性数据块大小数据块吞吐量追踪SQL进行优化）（3）.面->线->点：AWR->TOP5->哪块资源有问题三产生一个ASH报告，并进行分析，给出最后的结论。ASH：ActiveSessionHistory活动会话历史记录ASH是一个会话级别的性能诊断报告，可以提供更细粒度的时间区间，可以精确到分钟，ASH可以提供比AWR更详细的关于历史会话的信息，可以作为AWR的补充。ASH信息来源“v$active_session_history”保存当前会话的采集信息（一秒钟一次快照），视图容量满后可以被覆盖，可以从下面的数据字典中寻找“dba_hist_active_sess_history”保持历史会话的采集信息生成ASH报告创建脚本目录：/u01/app/oracle/product/11.2.0/db_1/rdbms/admin/ashrpt.sqlASH创建：sqlplusleo1/leo1@创建脚本[oracle@leonarding1~]$sqlplusleo1/leo1@/u01/app/oracle/product/11.2.0/db_1/rdbms/admin/ashrpt.sqlCurrentInstance~~~~~~~~~~~~~~~~DBIdDBNameInstNumInstance-------------------------------------------1678393804LEO11LEO1数据库id数据库名实例数量实例名SpecifytheReportType~~~~~~~~~~~~~~~~~~~~~~~Enter'html'foranHTMLreport,or'text'forplaintext指定生成ASH报告类型HTMLorTXTDefaultsto'html'默认是HTMLEntervalueforreport_type:我们直接回车生成HTML类型SpecifythetimeframetogeneratetheASHreport指定ASH报告采集时间区间~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Enterbegintimeforreport:--Validinputformats:--Tospecifyabsolutebegintime:--[MM/DD[/YY]]HH24:MI[:SS]--Examples:02/23/0314:30:15样例--02/2314:30:15--14:30:15--14:30--Tospecifyrelativebegintime:(startwith'-'sign)---[HH24:]MI--Examples:-1:15(SYSDATE-1Hr15Mins)可以当前时间减去指定的分钟数---25(SYSDATE-25Mins)Defaultsto-15mins默认减去15分钟Entervalueforbegin_time:03/11/1300:00:00我指定开始时间是2013年3月11日零点Reportbegintimespecified:03/11/1300:00:00Enterdurationinminutesstartingfrombegintime:DefaultstoSYSDATE-begin_time默认是当前时间-03/11/1300:00:00PressEntertoanalyzetillcurrenttimeEntervalueforduration:现在是03/11/1300:35:00，我们按回车SpecifytheReportName指定ASH报告名称，可以加创建到哪的路径~~~~~~~~~~~~~~~~~~~~~~~Thedefaultreportfilenameisashrpt_1_0311_0035.html.Tousethisname,默认名称presstocontinue,otherwiseenteranalternative.Entervalueforreport_name:/home/oracle/ashrpt_leo1_0000_0035.htmlReportwrittento/home/oracle/ashrpt_leo1_0000_0035.html报告已经创建到指定目录LEO1@LEO1>我们打开ASH报告ashrpt_leo1_0000_0035.html1.数据库概括信息数据库名：LEO1数据库id：1678393804实例名：LEO1实例数：1版本：11.2.0.1.0RAC：NO主机名：leonarding1.oracle.comCPUs：2核SGASize：490M其中data_buffer_cache112Msharedpool184MASHbuffersize4MASH采样开始时间：2013-03-1100:00:00ASH信息来源“v$active_session_history”ASH采样结束时间：2013-03-1100:35:00间隔时间：36分钟采样数：416平均活动会话：0.19每个CPU执行平均会话数：0.10这么一看跟AWR上来阐述系统概括信息差不多2.TopUserEvents前5名等待事件事件名事件类型占整体百分比平均会话数CPU等待时间最长CPU37.260.07这是我自己的实验环境，没有很多并发会话，所以活动会话数比较少这是等待事件的详细信息3.TopSQL性能最差SQL排名按等待事件排名SQL按数据处理方式排名SQL4.TopSessions按会话信息排名一个会话由：sid+serial#来唯一定位的5.TopObjects&Files按数据库对象和数据文件排名看第二行就是我们经常使用的LEO5表，object_id=74268因为我们刚刚做了AWR和ASH报告，用sysaux表空间较多，因此排第一位小结：ASH主要是针对会话级的一个体检报告，它可以追踪历史会话，从会话的角度分析数据库性能瓶颈，从而找到SQL，优化SQL语句。四分析说明ASH和AWR报告的使用场景AWR：如果想全面了解数据库各个方面性能的话（包括硬件软件应用数据库）可以使用AWR报告，实例级别诊断报告ASH：如果想了解关于历史会话的信息可以使用ASH报告，会话级别诊断报告场景功能对比AWRVSASHInstancewidedata实例级广泛数据YesYesTimebaseddata基于时间统计数据YesYesCounts/occurrencedata计数/统计数据NoYesAnalyzeanytimeperiod在任何时间段做分析YesNoDetailedsessionleveldata会话级详细数据YesNoIndividualWaiteventdata个别等待事件YesNoSampleddata采集样本数据YesNoTimebasedanalysis基于时间分析YesYesAWRASHsessionOLTPOLAPRepositoryLeonarding2013.3.10天津&spring分享技术~成就梦想Blog：www.leonarding.com
