07谁影响了性能-刘旭.docx

【谁影响了性能】全面诊断Cache buffers chains详细诊断过程这是对于两个节点的RAC环境，数据库版本为11.2.0.4 for HP-UX IA（64-bit）。在2014年11月5日16点至18点间，节点一的CPU使用率从平时的40%增长到60%左右，部分业务办理缓慢甚至超时。经过详细分析，发现是一个低效的、高并发的核心业务的SQL语句引起的。通过询问业务人员得知，业务系统从17:00至17:30感觉慢得更为明显，因此我们导出了该时间段节点二的AWR报告。下图显示了实例名为crmdb21的采样时间、数据库版本、CPU个数和内存大小等概要信息，通过简单的换算DB Time和Elapsed可知（2807.24/29.7=94），这台64 Cores的小型机的确很忙。Load Profile中的Logical read（blocks）973915.2/Per Second表明平均每秒产生的逻辑读blocks数约为97万，每秒的逻辑读约有7.6GB（973915*db_block_size=7.6GB/s），一般来说，逻辑读高CPU的使用率也会随之升高，通常会在Top 10中出现诸如latch: cache buffers chains、db filescattered read等事件。在Top 10Foregrand Events by Total Wait Time的部分，可以看到在该时间段的主要等待事件是latch:cache buffers chains 和 db filesequential read。它们的%DB Time分别占到38.9%和24.3%。后者代表单块读，是一种比较常见的物理IO等待事件，通常在数据块从磁盘读入到相连的内存空间中时发生，也可能是SQL语句使用了selectivity不高的索引，从而导致访问了过多不必要的索引块或者使用了错误的索引，这些等待说明SQL语句的执行计划可能不是最优的。前者是导致数据库逻辑读高的根本原因，由此推断某个或者某些SQL语句出现了性能衰变。在接下来的SQLStatistics部分，分别截取了SQL ordered by Elapsed Time和 SQL orderedby Gets，可以发现SQL Id=g5z291fcmwz08的语句分别占了42.50%的DB Time和35.19%的逻辑读，而其他SQL所占的DB Time和逻辑读分别在0.1%～5%。由此可以确定，就是该SQL语句影响系统性能，但还需要详细了解该SQL的执行计划、绑定变量和当时的逻辑读等信息。SELECT TO_CHAR(A.CUSTID) CUSTID,TO_CHAR(A.REGION) REGION,A.CUSTNAME CUSTNAME,?A.SHORTNAME SHORTNAME,A.CUSTTYPE CUSTTYPE,A.VIPTYPE VIPTYPE,TO_CHAR(A.FOREIGNER) FOREIGNER,A.CUSTCLASS1 CUSTCLASS1,A.CUSTCLASS2 CUSTCLASS2,A.NATIONALITY NATIONALITY,A.ADDRESS ADDRESS,A.CERTID CERTID,A.CERTTYPE CERTTYPE,A.CERTADDR CERTADDR,A.LINKMAN LINKMAN,A.LINKPHONE LINKPHONE,A.HOMETEL HOMETEL,A.OFFICETEL OFFICETEL,A.MOBILETEL MOBILETEL,A.POSTCODE POSTCODE,A.LINKADDR LINKADDR,A.EMAIL EMAIL,A.HOMEPAGE HOMEPAGE,TO_CHAR(A.ISMERGEBILL) ISMERGEBILL,A.ORGID ORGID,A.CREATEDATE CREATEDATE,A.NOTES NOTES,A.STATUS STATUS,A.STATUSDATE STATUSDATE,A.RESPONSECUSTMGR RESPONSECUSTMGR,A.CURRENTCUSTMGR CURRENTCUSTMGR,A.CREDITLEVEL CREDITLEVEL,TO_CHAR(A.INLEVEL) INLEVEL,A.REGSTATUS REGSTATUS,A.OWNERAREAID OWNERAREAID,A.CERTSTARTDATE CERTSTARTDATE,A.CERTENDDATE CERTENDDATE,A.COUNTRYID COUNTRYIDFROM CUSTOMER A, PERSON_CUSTOMER BWHERE A.CUSTID =