readbyothersession等待事件。

今天是2014-01-06，从今天开始，打算春节之前每天学习一个等待事件，今天就记录一下read by other session这个等待事件笔记。 什么是read by other session？ This wait event occurs when we are trying to access a buffer in the buffer cache but we fin

今天是2014-01-06，从今天开始，打算春节之前每天学习一个等待事件，今天就记录一下read by other session这个等待事件笔记。

什么是read by other session？

This wait event occurs when we are trying to access a buffer in the buffer cache but we find that the buffer is currently being read from disk by another user so we need to wait for that to complete before we can access it. In previous versions, this wait was classified under the "buffer busy waits" event. However, in Oracle 10.1 and higher, the wait time is now broken out into the "read by other session" wait event.

Excessive waits for this event are typically due to several processes repeatedly reading the same blocks, e.g. many sessions scanning the same index or performing full table scans on the same table. Tuning this issue is a matter of finding and eliminating this contention.

参考文档：文档 ID 732891.1

官方介绍：

read by other session

This event occurs when a session requests a buffer that is currently being read into the buffer cache by another session. Prior to release 10.1, waits for this event were grouped with the other reasons for waiting for buffers under the 'buffer busy wait' event

Wait Time: Time waited for the buffer to be read by the other session (in microseconds)

Parameter Description
file# See "file#"
block# See "block#"
class# See "class"

注意有p1，p2，p3,。

当出现该问题如何解决？

一般出现该问题是由于sql导致的，或者是由于磁盘设备可能导致。

当出现该问题的时候，首先需要定位sql。

方法一：通过ash获得细粒度的报告，查看top sql statement 获得sql。

方法二：通过sql语句直接获得：

1、当前正在发生的问题：

select sql_fulltext from v$sql a,v$session b where a.sql_id=b.sql_id and b.event='read by other session';

2、历史曾经发生的

select a.sql_id,sql_fulltext from v$sql a,dba_hist_active_sess_history b where a.sql_id=b.sql_id and b.event='read by other session';

往往read by other session伴随着db file sequential read事件的出现。

另外可以查看涉及对象信息，此处就是p1,p2,p3

SELECT p1 "file#", p2 "block#", p3 "class#"
FROM v$session_wait WHERE event = 'read by other session';

通过p1,p2,p3获得热点对象：

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;

另外，也可以 直接查看热点块的信息，如查看热点块导致的sql语句：

select sql_text
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 where a.RELATIVE_FNO = b.dbarfil
and a.BLOCK_ID and a.block_id + a.blocks > b.dbablk) b
where a.sql_text like '%' || b.segment_name || '%'
and b.segment_type = 'TABLE'
order by a.hash_value, a.address, a.piece;

查看热点块对象：

<code class="sql keyword">SELECT E.OWNER, E.SEGMENT_NAME, E.SEGMENT_TYPE<br> FROM DBA_EXTENTS E,<br> (SELECT *<br> FROM (SELECT ADDR, TS#, FILE#, DBARFIL, DBABLK, TCH<br> FROM X$BH<br> ORDER BY TCH DESC)<br> WHERE ROWNUM WHERE E.RELATIVE_FNO = B.DBARFIL<br> AND E.BLOCK_ID AND E.BLOCK_ID + E.BLOCKS > B.DBABLK; <code class="sql keyword">找到sql之后需要做的就是查看执行计划，判断问题所在,并进行优化。 <code class="sql keyword">1、对于在shared pool存在的cursor可以通过如下命令查看执行计划 <code class="sql keyword">select * from table(dbms_xplan.display_cursor('sql_id',null,'allstats')); <code class="sql keyword">2、对于历史可以通过查看awr信息获得： <code class="sql keyword">select * from table(dbms_xplan.display_awr('sql_id')); <code class="sql keyword">另外对于设备引起的需要查看磁盘读写信息，可以 通过vmstat 2 200进行判断。

<code class="sql keyword"><code class="sql keyword"><code class="sql keyword"><code class="sql keyword"><code class="sql keyword"><code class="sql keyword"><code class="sql keyword"><code class="sql keyword"><strong>Reducing Number of Waits:</strong>

<code class="sql keyword"><code class="sql keyword"><code class="sql keyword"><code class="sql keyword"><code class="sql keyword"><code class="sql keyword"><code class="sql keyword"><code class="sql keyword">If you are seeing long delays taken to service this wait event then check the amount of I/O being performed on the device identified by the P1 argument of this wait event.<br> The device and / or the controller may be overloaded. If this is the case then take the standard steps of spreading the file across further devices etc. Check that the real problem isn't the amount of time that the operating system is taking to service the system call. Find out which file numbers are causing the highest average waits and then determine which filesystem contains the file Determine why the filesystems are performing poorly. Some common causes are:<br> "hot filesystems" - too many active files on the same filesystem exhausting the I/O bandwidth hardware problem In Parallel Execution (PX) is being used, determine if the I/O subsystem is saturated by having too many slaves in use. 参考文档：<strong>文档 ID 1477229.1</strong> ——————————————————————————————————————————————————————————————————————————————————————————————————Rhys——————————————