ORACLE等待事件：read by other session

read by other session簡介

 

官方關於read by other session的介紹以下：

 

When information is requested from the database, Oracle will first read the data from disk into the database buffer cache. If two or more sessions request the same information, the first session will read the data into the buffer cache while other sessions wait. In previous versions this wait was classified under the "buffer busy waits" event. However, in Oracle 10.1 and higher this 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.

 

當從數據庫請求信息時，Oracle將首先將數據從磁盤讀入數據庫緩衝區緩存。若是兩個或多個會話請求相同的信息時，則第一個會話將數據讀入buffer cache的過程當中，而其餘會話出現等待。在以前的數據庫版本中，此等待事件被歸類爲「buffer busy waits」等待事件。 可是，在Oracle 10.1及更高版本中，此等待時間如今劃分爲「read by other session」等待事件。 該等待事件的大量等待一般是因爲一些進程重複讀取相同的數據塊，例如， 許多會話掃描同一索引或在同一個表上執行全表掃描。 調優此問題是找到並消除這種競爭。

 

C.3.114 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 waits' event

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

 

 

read by other session的分析

 

    read by other session等待的出現也說明數據庫存在讀的競爭，等待事件read by other session 一般與等待事件db file scattered read 和db file sequential read同時出現。有時候甚至與等待事件enq: TX - row lock contention同時出現（特殊狀況，一個特殊案例中遇到的，等待read by other session的會話阻塞其它會話），以下截圖所示。

 

 

 

db file scattered read一般顯示與全表掃描相關的等待。當數據庫進行全表掃時，基於性能的考慮，數據會分散(scattered)讀入Buffer Cache。若是這個等待事件比較顯著，可能說明對於某些全表掃描的表，沒有建立索引或者沒有建立合適的索引。

 

db file sequential read一般顯示與單個數據塊相關的讀取操做(如索引讀取)。若是這個等待事件比較顯著，可能表示在多表鏈接中，表的鏈接順序存在問題，可能沒有正確的使用驅動表;或者可能說明不加選擇地進行索引。

 

 

read by other session解決 

 

 

如何查看當前會話處於等待read by other session：

 

使用下面SQL找到當前處於read by other session等待的SQL語句，而後分析SQL，優化SQL

 

SELECT s.username, 

       s.sid, 

       s.serial#, 

       s.osuser, 

       s.machine, 

       s.terminal, 

       s.program, 

       s.last_call_et, 

       s.event, 

       s.seconds_in_wait, 

       s.blocking_session, 

       t.sql_text 

       --,t.SQL_FULLTEXT 

FROM   v$session s, 

       v$sqlarea t 

WHERE  s.sql_address = t.address 

       AND S.sid IN (SELECT sid                    

                     FROM   v$session_wait                   

                     WHERE  event IN ( 'read by other session' ));

或

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

 

 

也能夠經過下面SQL，獲取產生read by other session等待事件的SQL的實際執行計劃，研究執行計劃後，對相關SQL進行調優，例如，對於全表掃描的添加合適索引。

 

SELECT DISTINCT SQL_ID

FROM V$SESSION

WHERE EVENT IN('read by other session', 'db file sequential read');

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('xxxxx'));

 

 

對於非當前會話的read by other session等待事件，咱們能夠經過AWR報告和ASH結合，找到發生read by other session等待的SQL語句。

 

1：首先分析Top 5 Timed Events，分析read by other session、db file scattered read、db file sequential read等待事件

 

 

2：AWR報告中分析Segments by Buffer Busy Waits部份內容

 

    以下截圖所示，基本上能夠判斷第一個表xxx就是出現

 

 

 

3：首先使用下面腳本找到產生了'read by other session'等待事件的SQL，而後生成指定SQL語句的統計報表（awrsqrpt.sql）以及接近採樣點附近的ASH報告

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';

 

AWR報告裏面的SQL ordered by Reads 或SQL ordered by Gets中的TOP SQL找到涉及Segments by Buffer Busy Waits中對象的SQL ，而後結合ASH（細粒度的報告）來判斷、分析！。

 

 

 

另外，若是須要查看涉及對象信息，能夠經過等待事件的字段p1,p2,p3來獲取

 

 

SELECT p1 "file#"

 , p2 "block#"

 , p3 "class#" 

FROM v$session_wait WHERE event = 'read by other session';

或

SELECT p1 "file#" 

      ,p2 "block#"  

      ,p3 "class#"

FROM   dba_hist_active_sess_history 

WHERE  event = 'read by other session';

 

 

官方文檔描述以下：

 

·         P1 = file# Absolute File# (AFN)

·         P2 = block#

·         P3 = class# Block class

·         file# Absolute File Number (AFN)

        This is the file number of the data file that contains the block that the waiting session wants.

·         block#

        This is the block number in the above file# that the waiting session wants access to. See Note:181306.1 to determine the tablespace, filename and object for this file#,block# pair.

·         class# Block class#

        This is the class of block being waited on. In particular:

        class 1 indicates a "data block", which could be table or index

        class 4 indicates a "segment header"

        class >=15 indicate undo blocks

         

另外，下面一些SQL來自惜分飛的「Read by other session等待事件」，很是有用。

 

根據FILE#，BLOCK#查詢熱塊對象

 

SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, A.PARTITION_NAME

FROM DBA_EXTENTS A

WHERE FILE_ID = &FILE_ID

AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS – 1;

 

 

 

直接查找熱點塊對象語句

SELECT *

  FROM (SELECT O.OWNER, O.OBJECT_NAME, O.OBJECT_TYPE, SUM(TCH) TOUCHTIME

          FROM X$BH B, DBA_OBJECTS O

         WHERE B.OBJ = O.DATA_OBJECT_ID

           AND B.TS# > 0

         GROUP BY O.OWNER, O.OBJECT_NAME, O.OBJECT_TYPE

         ORDER BY SUM(TCH) DESC)

 WHERE ROWNUM <= 10

--或者

SELECT E.OWNER, E.SEGMENT_NAME, E.SEGMENT_TYPE

  FROM DBA_EXTENTS E,

       (SELECT *

          FROM (SELECT ADDR, TS#, FILE#, DBARFIL, DBABLK, TCH

                  FROM X$BH

                 ORDER BY TCH DESC)

         WHERE ROWNUM < 11) B

 WHERE E.RELATIVE_FNO = B.DBARFIL

   AND E.BLOCK_ID <= B.DBABLK

   AND E.BLOCK_ID + E.BLOCKS > B.DBABLK

 

直接查找熱點塊操做語句 SELECT /*+rule*/ 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;

   

 

其它一些官方或英文資料：

 

 

Solutions

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.

 

1. Tune the SQL statement so that it reads fewer blocks. If the top objects listed in SolarWinds DPA are indexes, determine if there is a more efficient index that can be used more efficiently. If the top objects are tables, a full table scan or index randge scan is being performed. Look for efficient indexing opporunties.

 

2. Increase the buffer cache so that more blocks are already in memory rather having to be read from disk. The query will still need to read the same number of blocks so tuning is the first recommendation, but if you cannot tune the statement, a query reading blocks from memory is much faster than from disk.

 

3. Increase the PCTUSED / PCTFREE for the table storage parameters via ALTER TABLE or rebuild. This will result in less rows per block and possibly reduce contention.

 

 

WAITEVENT: "read by other session" Reference Note (文檔 ID 732891.1)

 

Reducing Waits / Wait times:

 

Reducing waits typically involves application tuning and/or IO tuning.

Contention does not mean that there is necessarily a problem, but it is more likely that selects against the objects involved are reading more blocks than they have to. These unnecessary reads can then contend. To find such selects, look for the queries that are waiting frequently for 'read by other session'. Active Session History (ASH) reports during the period where contention is seen are a useful source of this sort of information. Alternatively look for those queries that read a lot of buffers when querying these tables; it is possible that these queries are poorly optimized and perhaps a different access path may read fewer buffers and cause less contention.

eg: if lots of sessions scan the same unselective index this can show as "read by other session" waits for "data blocks":

·         the first session processes the blocks that are in the buffer cache quickly but then a block has to be read from disk

·         the other sessions (scanning the same index) quickly 'catch up' and want the block which is currently being read from disk - they wait for the buffer as someone is already reading the block in.

Since the 'read by other session' wait event is an indicator that the buffers being waited for are popular (and are being "read by another session"), if queries are properly optimized, then an undersized buffer cache may mean that there is insufficient space to retain all the buffers required by queries. Make sure that the buffer cache is adequately sized to keep the buffers required by the current SQL statements from being aged out.

 

Resolving Issues Where 'read by other session' Waits When I/O is Slow (文檔 ID 1477229.1)

 

Reducing Number of Waits:

1. 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. 
   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.
2. Check that the real problem isn't the amount of time that the operating system is taking to service the system call.
3. Find out which file numbers are causing the highest average waits and then determine which filesystem contains the file
4. Determine why the filesystems are performing poorly. Some common causes are:
   
   • "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.

 

 

參考資料：

http://www.xifenfei.com/2011/07/read-by-other-session%E7%AD%89%E5%BE%85%E4%BA%8B%E4%BB%B6.html

https://docs.oracle.com/database/121/REFRN/GUID-DCEB3FA4-57A9-4EBE-A349-BBCA1BA49281.htm#REFRN00610

http://www.dbdream.com.cn/2015/01/%E5%85%B3%E4%BA%8Eread-by-other-session%EF%BC%8Cdb-file-scattered-read%EF%BC%8Cdb-file-sequential-read%E7%AD%89%E5%BE%85%E6%97%B6%E9%97%B4%E7%9A%84%E4%BC%98%E5%8C%96/