なーんでだシリーズ第2弾

1. JPOUG Presents
なーんでだ
at db tech showcase 2015 Tokyo
#2
#dbts2015 #jpoug
/Koji Shinkubo @kouji_s_0808

2. 実行計画と待機イベントの謎

3. 例えば、これは、
どんな状況か想像してみてください。

4. ある日、突然、
バッチ処理が返ってこなくなった。
状況 実行時間
普通の場合 5分
何かおかしい場合 100分+

5. TAB_01
TAB_02
SQL文
update tab_01 a1
set col10 = null
where exists (select 1 from tab_02 a2 where a1.id = a2.id);
ID NUMBER
COL1 VARCHAR2(100)
COL2 VARCHAR2(100)
COL3 VARCHAR2(100)
COL4 VARCHAR2(100)
COL5 VARCHAR2(100)
COL6 VARCHAR2(100)
COL7 VARCHAR2(100)
COL8 VARCHAR2(100)
COL9 VARCHAR2(100)
COL10 VARCHAR2(100)
ID NUMBER
COL1 VARCHAR2(100)
COL2 VARCHAR2(100)

6. 実行計画は？

7. 普通の場合も、何かがおかしい場合も同じ実行計画
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
| Id | Operation | Name |
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
| 0 | UPDATE STATEMENT | |
| 1 | UPDATE | TAB_01 |
|* 2 | HASH JOIN | |
| 3 | VIEW | VW_SQ_1 |
| 4 | SORT UNIQUE | |
| 5 | TABLE ACCESS FULL| TAB_02 |
| 6 | TABLE ACCESS FULL | TAB_01 |
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­

8. 同じ実行計画(基本的に同じデータ)
でも、ものすごく遅い時がある

9. なーんでだ？

10. SQLトレース(の待機イベント)
を見てみますか？

11. 普通の場合
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ Waited ­­­­­­­­­­ ­­­­­­­­­­­­
Disk file operations I/O 16 0.00 0.00
db file sequential read 3 0.00 0.00
gc cr multi block request 37 0.00 0.00
db file scattered read 46 0.00 0.06
SQL*Net message to client 1 0.00 0.00

12. 何かがおかしい場合
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ Waited ­­­­­­­­­­ ­­­­­­­­­­­­
Disk file operations I/O 21 0.00 0.00
db file sequential read 2071 0.00 0.45
gc cr multi block request 37 0.00 0.00
db file scattered read 46 0.00 0.06
SQL*Net message to client 1 0.00 0.00

13. 普通の場合
何かがおかしい場合
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ Waited ­­­­­­­­­­ ­­­­­­­­­­­­
Disk file operations I/O 16 0.00 0.00
db file sequential read 3 0.00 0.00
gc cr multi block request 37 0.00 0.00
db file scattered read 46 0.00 0.06
SQL*Net message to client 1 0.00 0.00
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ Waited ­­­­­­­­­­ ­­­­­­­­­­­­
Disk file operations I/O 21 0.00 0.00
db file sequential read 2071 0.00 0.45
gc cr multi block request 37 0.00 0.00
db file scattered read 46 0.00 0.06
SQL*Net message to client 1 0.00 0.00

14. 少しまとめてみると、
実行計画(FULL SCAN)は同じなのに、
待機イベントが違いますね。
状況 待機イベントの状況
普通の場合 db file sequential readはほとんどない
何かおかしい場合 db file sequential readがとても多い

15. なーんでだ！？(再び)

16. ちなみ私が遭遇した時は、
SQLトレースが取得できる状況ではなかったので、
ASHからこの状況を観察していました。

17. 未整形のSQLトレースを見てみますか？

18. 普通の場合
何かがおかしい場合
WAIT #140537630453352: nam='db file sequential read' ela= 2167 file#=10 block#=92
WAIT #139710261849704: nam='db file sequential read' ela= 283 file#=3 block#=9682
WAIT #139710261849704: nam='db file sequential read' ela= 271 file#=3 block#=9681
WAIT #139710261849704: nam='db file sequential read' ela= 272 file#=3 block#=9680
WAIT #139710261849704: nam='db file sequential read' ela= 258 file#=3 block#=163
WAIT #139710261849704: nam='db file sequential read' ela= 260 file#=3 block#=162
...

19. db file sequential readで待機している対象のセグメントを特定
select segment_name
from dba_extents
where file_id = :file#
and :block# between block_id and block_id + blocks ­ 1
and rownum = 1

20. db file sequential readで待機している対象セグメント
状況 対象ブロック 待機の対象オブジェクト
普通の場合 file#=10,
block#=nnn
TAB_01
何かがおか
しい場合
file#=3 ,
block#=nnn
_SYSSMU3_4004931649$

21. もう分かりましたね！

22. いや！ まだ早い！

23. 何かがおかしい場合
例えば、
file#=3, block#=9682の
UNDOセグメント="_SYSSMU3_4004931649$"は、
どのオブジェクトを格納しているUNDOセグメントか？
WAIT #139710261849704: nam='db file sequential read' ela= 283 file#=3 block#=9682
WAIT #139710261849704: nam='db file sequential read' ela= 271 file#=3 block#=9681
WAIT #139710261849704: nam='db file sequential read' ela= 272 file#=3 block#=9680
WAIT #139710261849704: nam='db file sequential read' ela= 258 file#=3 block#=163
WAIT #139710261849704: nam='db file sequential read' ela= 260 file#=3 block#=162
...

24. DUMP
alter system dump undo header '_SYSSMU3_4004931649$';
********************************************************************************
Undo Segment: _SYSSMU26_3270072861$ (26)
********************************************************************************
...
TRN TBL::
index state cflags wrap# uel scn dba parent­
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
0x00 9 0x00 0x062c 0x000d 0x0000.00c4ffaa 0x00c0013a 0x0000.000.000
^^^^^^^^^^
0x01 9 0x00 0x062c 0x0005 0x0000.00c4fba5 0x00c00139 0x0000.000.000
0x02 9 0x00 0x062c 0x0021 0x0000.00c4f514 0x00c00135 0x0000.000.000
0x03 9 0x00 0x062c 0x000f 0x0000.00c4fcd9 0x00c00139 0x0000.000.000
0x04 9 0x00 0x062c 0x0010 0x0000.00c4f885 0x00c00136 0x0000.000.000
0x05 9 0x00 0x062c 0x001d 0x0000.00c4f018 0x00c00135 0x0000.000.000
0x06 9 0x00 0x062c 0x001b 0x0000.00c4ee33 0x00c00134 0x0000.000.000
0x07 9 0x00 0x062b 0x0014 0x0000.00c4ecd4 0x00c00134 0x0000.000.000
0x08 9 0x00 0x062b 0x0018 0x0000.00c4f379 0x00c00135 0x0000.000.000

25. UNDO BLOCKはどこ？
select
dbms_utility.data_block_address_file(
to_number('00c0013a','xxxxxxxx')) file#,
dbms_utility.data_block_address_block(
to_number('00c0013a','xxxxxxxx')) block#
from dual;
FILE# BLOCK#
­­­­­­­­­­ ­­­­­­­­­­
3 314

26. DUMP その2
alter system dump datafile 3 block 314;
*­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
* Rec #0xc slt: 0x11 objn: 76102(0x00012946) objd: 76102 tblspc: 0(0x00000000
^^^^^^^^^^^
* Layer: 11 (Row) opc: 1 rci 0x0b
Undo type: Regular undo User Undo Applied Last buffer split: No
Temp Object: No
Tablespace Undo: No
rdba: 0x00000000
*­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
KDO undo record:
KTB Redo
op: 0x02 ver: 0x01
compat bit: 4 (post­11) padding: 1
op: C uba: 0x00c0013a.0085.0b
KDO Op code: LKR row dependencies Disabled
xtype: XA flags: 0x00000000 bdba: 0x00416dd9 hdba: 0x00416dd8
itli: 3 ispac: 0 maxfr: 4863
tabn: 0 slot: 2 to: 0

27. オブジェクトID=76102は誰？
select object_name from dba_objects where object_id=76102;
OBJECT_NAME
­­­­­­­­­­­
TAB_02

28. やっと、分かりましたね！

29. 少なくとも、このUPDATE文が実行された際、
tab_02テーブルにはアクティブなトランザクションが
あったという事。
このUPDATE文による更新対象の行を検索する際に、
UNDOからCRブロックを生成して読み取り一貫性を
保障しようとするのでUNDOブロックへの
db file sequential readが多発しているという事。
update tab_01 a1
set col10=null
where exists (select 1 from tab_02 a2 where a1.id = a2.id);

30. 実行計画だけで判断できないパターン
もあります。
待機イベントとそのパラメーターの理
解も大事ですね。

31. Finish!