AWR实战分析之readbyothersession.docxVIP

AWR实战分析之read?by?other?session 下班前做数据库巡检时，发现系统负载有些异常，取了一下当时的AWR报告，显示数据库负载非常大，会话数也稍有增加，如下图所示. ????????服务器CPU CORE是16 ，从这来看数据库基本上处于HUNG停的状态，我们通过TOP 5来看一下数据库发生了什么等待事件 ????????从TOP 5上看，最主要的问题是在dblink消耗上，但是我们先不管dblink的问题，从平均等待上看，read by other session也是等待比较严重的，要想解决read by other session等待我们必须先搞懂原理才好下手解决，通过baidu和metalink查询，总结如下 ????当多个进程访问同一个数据块，而此数据库不在内存，当第一个进程将它从磁盘读到内存时，其它进程的状态就是read by other session 因为ORACLE内存不允许多个进程同时读到同一个数据块到内存，其它进程只能等待，其实read by other session是在10g新引入的，在10g以前版本，等待为buffer busy wait，10g以后做的细分，所以才有了read by other session。 ????那么从AWR上看我们需要关注的部分是Segments by Buffer Busy Waits，本案例如下图所示 ?? 解决方案：????首先需要明确一点，发生这种问题并不是说我们的存储设计不合理，解决此类方法最优最有效的方法就是找到对应的SQL进行优化，减少不必要的读取，从而杜绝此类问题，解决步骤如下： 1.查询等待事件详细信息 ??SELECT p1 file#, p2 block#, p3 class#????FROM v$session_wait WHERE event = read by other session; 2.如果上述查询是热块造成的，进行如下查询具体对像信息，其实这部分可以直接从AWR的Segments by ??Buffer Busy Waits看出来 ??SELECT relative_fno, owner, segment_name, segment_type FROM dba_extents???WHERE file_id = file?????AND block BETWEEN block_id AND block_id blocks - 1;3.查看对应的SQL? SELECT?HASH_VALUE, SQL_TEXT??FROM V$SQLTEXT?WHERE (HASH_VALUE, ADDRESS) IN???????(SELECT A.HASH_VALUE, A.ADDRESS??????????FROM V$SQLTEXT A,???????????????(SELECT DISTINCT A.OWNER, A.SEGMENT_NAME, A.SEGMENT_TYPE??????????????????FROM DBA_EXTENTS A,???????????????????????(SELECT DBARFIL, DBABLK??????????????????????????FROM (SELECT DBARFIL, DBABLK??????????????????????????????????FROM X$BH?????????????????????????????????ORDER BY TCH DESC)?????????????????????????WHERE ROWNUM 11) B?????????????????WHERE A.RELATIVE_FNO = B.DBARFIL???????????????????AND A.BLOCK_ID = B.DBABLK???????????????????AND A.BLOCK_ID A.BLOCKS B.DBABLK) B?????????WHERE A.SQL_TEXT LIKE % || B.SEGMENT_NAME || %???????????AND B.SEGMENT_TYPE = TABLE)?ORDER BY HASH_VALUE, ADDRESS, PIECE; 4.查看对应SQL执行计划是否最优，必要时通过DBMS_SQLTUNE包进行优化，通过sql_profile文件稳固执行计划 5.查看表和索引统计信息是否陈旧，必要时重统收集统计信息 6.如果以上方法仍然无法解决热块问题，那么只能调整pctfree参数，将数据重新导入，打散热块，说实话，这 ??种方法都知道，但是这样做的人