My Oracle Support Banner

RAC データベース環境において表領域の read only -> read write により "gc buffer busy acquire" が発生する (Doc ID 2227060.1)

Last updated on AUGUST 04, 2018

適用範囲:

Oracle Database - Enterprise Edition - バージョン 11.2.0.1 から 11.2.0.4 [リリース 11.2]
この文書の内容はすべてのプラットフォームに適用されます。
本文書利用上のご注意
  本文書は英語の文書 <Document 2221999.1> (最終メジャー更新日: 2017年1月15日) の日本語翻訳版です。
  英語の文書の最終メジャー更新日が新しい場合は本文書に適宜反映いたします。

現象

表領域の read only -> read write が行なわれた後に、対象表領域に対する SQL実行セッションが "gc buffer busy acquire" および "latch: cache buffers chains" で待機し続けます。

本現象に該当した場合、以下の状況が確認できます。

1. 表領域の read write 後に SQL を実行したセッションが "gc buffer busy acquire" および "latch: cache buffers chains" で待機する状況が繰り返されます。
待機が発生した RAC インスタンスに対して、複数セッションから同様の SQL を実行した場合にいずれのセッションも同様の待機状態になります。

これは dia0 のトレースファイルに出力される HANG ANALYSIS の情報です。

Suspected Hangs in the System
Root Chain Total Hang
Hang Hang Inst Root #hung #hung Hang Hang Resolution
ID Type Status Num Sess Sess Sess Conf Span Action
----- ---- -------- ---- ----- ----- ----- ------ ------ -------------------
2 HANG VALID 4 17413 2 2 LOW LOCAL Terminate Process

inst# SessId Ser# OSPID Event
----- ------ ----- --------- -----
4 1608 257 59201 latch: cache buffers chains <<<<
4 17413 55785 105526 gc buffer busy acquire <<<<

2. 各待機セッションの、"gc buffer busy acquire" の待機対象のデータブロックを示す V$SESSION および DBA_HIST_ACTIVE_SESS_HISTORY の P1列(データファイル番号)、P2列(ブロック番号)が同じになります。

select sid, serial#, event, p1, p2, p3, BLOCKING_SESSION, ROW_WAIT_FILE#, ROW_WAIT_BLOCK#, SQL_ID from v$session;

SID SERIAL# EVENT P1 P2 P3 BLOCKING_SESSION ROW_WAIT_FILE# ROW_WAIT_BLOCK# SQL_ID
---------- ---------- --------------------------- ---------- ---------- ---------- ---------------- -------------- --------------- -------------
25 5 latch: cache buffers chains 2191605712 177 0 4 155 5fadjf5jgc5ht
141 5 gc buffer busy acquire 4 155 1 4 155 5fadjf5jgc5ht
148 13 SQL*Net message to client 1650815232 1 0 4 149 5fadjf5jgc5ht

select count(BLOCKING_SESSION) from gv$session where BLOCKING_SESSION is not NULL;

COUNT(BLOCKING_SESSION)
-----------------------
0

3. 待機対象のデータブロックについて、GV$BH を確認すると scur または xcur と、read のステータスのバッファキャッシュが存在します。

SQL> select INST_ID, STATUS from gv$bh
where file#=6 and block#=15947
and status != 'free';

INST_ID STATUS
---------- ----------
2 scur
2 read

4. 事象が発生している RACインスタンスで systemstate ダンプを取得すると、対象データブロックの scur または xcur ステータスのバッファのダンプに "flags: logically_flushed" のフラグ情報が表示されます。

事象が発生しいてる RAC インスタンスの systemstate ダンプ確認例(scurの例)

BH (0x88f95c38) file#: 6 rdba: 0x01803e4b (6/15947) class: 1 ba: 0x88c98000 <<<< P1 is 6 and P2 is 15947
set: 5 pool: 3 bsz: 16384 bsi: 0 sflg: 1 pwc: 0,25
dbwrid: 0 obj: 730556 objn: 730556 tsn: 5 afn: 6 hint: f
hash: [0x9b9d0e58,0x7ef56a30] lru: [0x88f87ce8,0x88f87b48]
ckptq: [NULL] fileq: [NULL] objq: [0x91cff1c8,0x91cff1c8] objaq: [0x91cff1b8,0x91cff1b8]
use: [0xa0e0c400,0xa0e0c400] wait: [NULL]
st: SCURRENT md: SHR fpin: 'qeilwhrp: qeilbk' tch: 0 le: 0x84fad970 <<<< st: SCURRENT(scur)
flags: logically_flushed <<<< flag
LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]

* 3. が xcur のケースでは、st: XCURRENT と表示されます。

変更点

以下の条件をすべて満たす場合に発生する場合があります。

原因

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.