[INSIGHT OUT 2011] C22 RAC buffer sharing の仕組み(yamashita)

Block Mode で紐解く
Oracle Real Application Clusters の
Buffer Sharing
要はCR
～要はCR Block ～

Copyright © 2011 Insight Technology, Inc. All Rights Reserved. 1

その前に、、、


What’s Real Application Clusters ?

Real Application Clusters とは、、、
構成における特徴機能における特徴
- 複数サーバで共有ストレージに接続 - 複数ノードで並行処理することによる
- 全てのサーバはACTIVE パフォーマンスアップ
- サーバ間を高速ネットワークで接続 - 複数のACTIVEサーバによる高可用性
- 複数インスタンスでDBを共有 - ノード追加による拡張性



Real Application Clusters とは、、、
パフォーマンスアップに対するソリューション

スケールアップによる性能・コストの限界

スケールアウトによるリソース限界の打破

スケーラビリティーの壁



スケーラビリティーの壁

キーワードは
ブロックの

モード
サーバは分割してもデータは共有


Data Block

ブロックとは、、、、
IOの最小単位
表領域にセグメントを格納
セグメントは複数のエクステントで構成
エクステントはブロックの集まり
ブロック内にレコードを格納
Diskから読み取ったブロックはSGA内の
バッファ・キャッシュで管理

表領域エクステント

セグメントブロック


What’s Block Mode?

Mode とは、
OWNER OBJECT_NAM OBJ BA DBABLK LRU_FLAG CLASS TCH STATUS
---------- ---------- ---------- ---------------- ---------- ---------- ---------- ---------- --------
TTT T_TTT 74984 0000000062152000 4120 1 8 1 xcur
TTT T_TTT 74984 0000000065D08000 4121 1 9 1 xcur
TTT T_TTT 74984 0000000061916000 4122 1 4 8 xcur
TTT T_TTT 74984 000000006BD0E000 4123 1 1 8 xcur
TTT T_TTT 74984 000000006914E000 4124 1 1 8 xcur
TTT T_TTT 74984 0000000068A2C000 4125 1 1 8 xcur
TTT T_TTT 74984 00000000696F4000 4126 1 1 8 xcur
TTT T_TTT 74984 000000006439E000 4127 1 1 8 xcur
TTT I_TTT 74985 00000000638D8000 4128 1 8 1 xcur
TTT I_TTT 74985 0000000069B74000 4129 1 9 1 xcur
TTT I_TTT 74985 000000006267E000 4130 1 4 5 xcur
TTT I_TTT 74985 0000000069558000 4131 1 1 1 xcur



Block Mode とは、
XCUR 排他/カレントモード
CR 読み取り一貫性モード
FREE 開放モード




・ブロックの最新イメージ
・シングルインスタンス環境では SELECT してバッファ・キャッシュに載った時
点で XCUR になる
・行やセグメントに対する”排他”ではなく、インスタンスに対する”排他”




・読み取り一貫性を担保するために生成される一時的なブロック
・ブロック一つに対して複数の CR ブロックが生成される場合がある
・ブロック一つに対して生成される CR ブロックの数には上限がある
キーワード：_db_block_max_cr_dba
・CR ブロックは必ずしも SELECT の際にだけ発生するわけではない

参照：
http://www.insight-tec.com/mailmagazine/ora3/vol171.html




SELECT UPDATE COMMIT

SESSION:1
SCN:10 XCUR SCN:20 XCUR undo SCN:20 XCUR
DATA : AA DATA : BB DATA : BB

SESSION:2
SELECT SELECT
SCN:10 CR
DATA : AA



CRブロックはカレントブロックと同じハッシュチェー
ン上にアロケートされる
.......................
CHAIN: 8669 LOC: 0x7c772878 HEAD: [0x6ebcadf8,0x6d7b0118]
BH (0x6ebcad48) file#: 8 rdba: 0x0200101b (8/4123) class: 1 ba: 0x6ea76000
........
BH (0x61bd0858) file#: 8 rdba: 0x0200101b (8/4123) class: 1 ba: 0x61af2000
........
BH (0x623c3070) file#: 8 rdba: 0x0200101b (8/4123) class: 1 ba: 0x621cc000
........
BH (0x6d7c5528) file#: 8 rdba: 0x0200101b (8/4123) class: 1 ba: 0x6d5fe000
........
BH (0x647ccaa8) file#: 8 rdba: 0x0200101b (8/4123) class: 1 ba: 0x6469e000
........
BH (0x6bbd77f8) file#: 8 rdba: 0x0200101b (8/4123) class: 1 ba: 0x6bb8a000
........
BH (0x6d7b0068) file#: 8 rdba: 0x0200101b (8/4123) class:
rdba: 1 ba: 0x6d42e000 <<< XCUR
ba:
........



CRブロックはカレントブロックと同じハッシュチェー
ン上にアロケートされる

CHAIN: 1
CHAIN: 2
CHAIN: 3

:

CHAIN:8669 cache buffer chain latch

:

CHAIN:nnnnn



Block Mode とは、（RACの場合）
SCUR 共有/カレントモード
PI 過去イメージモード



SCUR 共有/カレントモード

・更新されていない最新イメージ
・RACを構成しているインスタンスの間で共有可能
・更新がかかると XCUR になる
・別インスタンスで更新がかかると CR になる



PI 過去イメージモード

・インスタンスリカバリ用のブロックイメージ
・XCUR ブロックに対して別インスタンスで更新がかかると PI になる
・別インスタンスのXCUR ブロックがディスクに書き出されると CR になる




NODE1 NODE2
SCUR SCUR




NODE1 NODE2
XCUR
SCUR CR
SCUR




NODE1 NODE2
XCUR
PI CR

XCUR




NODE1 NODE2
CR
PI CR

XCUR


Block Concurrent under RAC Environment

Real Application Clusters 環境におけるブロック
競合に対するアプローチ
テーブル
- INSERT 時は ASSM 管理によりインスタンスごとにブロックが分かれるためパフォーマンス問
題は起こりにくい
- 同一ブロック内のレコードに対する UPDATE / DELETE は競合する
- ブロックサイズの調整やパーティション化などで対応する

インデックス
- インデックスの先頭列にシーケンスなどのカウントアップ型の値や、時刻など連続する値を配
置している場合、各インスタンスから INSERT するとリーフブロックが競合する
- パーティション化やインデックスの先頭列の配置を工夫することで対応する


Big Data on Oracle Database 11g

RDBMS としてどうやって大量データに立ち向かうか
そもそも、、、
Oracle Database はキャッシュシステム
でも、、、、
大量データに対しては、むしろメモリ管理がオーバーヘッドに
っじゃ、、、、
大量データの時はバッファ・キャッシュを使わないことにしよう


How dose it work for Full Table Scan?

Oracle 11gR2 で大量データを検索する、、、、
バッファ・キャッシュにはデータブロック
がキャッシュされない！！
---------- ---------- ---------- ---------------- ---------- ---------- ---------- ---------- -------
TTT T_TTT 74298 0000000061252000 129 0 9 1 scur
TTT T_TTT 74298 000000006124C000 130 0 4 1 scur
TTT T_TTT 74298 00000000616BC000 3968 0 8 1 scur
TTT T_TTT 74298 0000000061766000 3969 0 8 1 scur

CLASS BLOCK TYPE
1 DATA BLOCK
4 SEGMENT HEADER
8 FIRST LEVEL BITMAP BLOCK
9 SECOND LEVEL BITMAP BLOCK


Full Table Scan ? Or Direct Path Read ?

困ったときは tkprof
Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
1000000 1000000 1000000 TABLE ACCESS FULL T_TTT (cr=70299 pr=3882 pw=0 time=1454934 us cost=1067
size=23000000 card=1000000)

Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
library cache lock 1 0.00 0.00
library cache pin 1 0.00 0.00
SQL*Net message to client 66668 0.00 0.10
Disk file operations I/O 2 0.00 0.00
3-
gc current block 3-way 2 0.00 0.00
enq: KO - fast object checkpoint 3 0.00 0.00
reliable message 1 0.05 0.05
2-
gc current block 2-way 2 0.00 0.00
direct path read 1 0.01 0.01
SQL*Net message from client 66668 81.79 552.67


How About Direct Path Read?

最後はやっぱり 10046 trace
PARSE #140036514701864:c=13997,e=188175,p=0,cr=6,cu=0,mis=1,r=0,dep=0,og=1,plh=892208080,tim=1318202199367035
EXEC #140036514701864:c=0,e=18,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=892208080,tim=1318202199367143
WAIT #140036514701864: nam='SQL*Net message to client' ela= 2 driver id=1650815232 #bytes=1 p3=0 obj#=13755
tim=1318202199367193
WAIT #140036514701864: nam='Disk file operations I/O' ela= 4 FileOperation=2 fileno=8 filetype=2 obj#=13755
tim=1318202199367910
nam='
='gc 3- ela= obj#=74298 tim=1318202199372868
WAIT #140036514701864: nam='gc current block 3-way' ela= 930 p1=8 p2=130 p3=4 obj#=74298 tim=1318202199372868
WAIT #140036514701864: nam='enq: KO - fast object checkpoint' ela= 446 name|mode=1263468550 2=65569 0=1
obj#=74298 tim=1318202199385235
WAIT #140036514701864: nam='reliable message' ela= 54967 channel context=2105825176 channel handle=2003413296
broadcast message=2106905888 obj#=74298 tim=1318202199440846
obj#=74298 tim=1318202199441635
obj#=74298 tim=1318202199441894
nam='
='gc 2- ela= obj#=74298 tim=1318202199461953
nam='
='gc 3- ela= obj#=74298 tim=1318202199462497
nam='
='gc 2- ela= obj#=74298 tim=1318202199463276
WAIT #140036514701864: nam='direct path read ela= 18383 file number=8 first dba=131 block cnt=13 obj#=74298
direct read'
tim=1318202199487706


Direct Path Read Role.

Direct Path Read の条件は、、、
SMALL TABLE ？ LARGE TABLE ？
_small_table_threshold (blocks)
_very_large_object_threshold (MB)
NAME VALUE DESCRIPTION
------------------------------ ---------- ------------------------------------------------------------
db_block_buffers 0 Number of database blocks cached in memory
_db_block_buffers 23030 Number of database blocks cached in memory: hidden parameter
_small_table_threshold 441 lower threshold level of table size for direct reads
_very_large_object_threshold 500 upper threshold level of object size for direct reads


Direct Path Read Role.

Direct Path Read の条件は、、、
条件１：
セグメントサイズ > 5 x “_small_table_threshold” x blocksize
条件２：
セグメントサイズ > “_very_large_object_threshold”
条件３：
10949 イベントで”条件１”を無効化

参照：
http://www.insight-tec.com/technical-information/11gr2からのフルスキャン.html


Direct Path Read and …

Direct Path Read といえば、、、、


How about PQ ?

PQとは、、、
Coordinator
QC

Consumer Slave
QS QS

Producer
QS QS


How about INPQ ?

Inter Node PQとは、、、
QC

QS QS QS QS


How dose INPQ work ?

Oracle 11gR2 でINPQを実行してみたら、、、、
バッファ・キャッシュにはデータブロック
がキャッシュされない！！
---------- ---------- ---------- ---------------- ---------- ---------- ---------- ---------- -------
TTT T_TTT 74298 0000000061252000 129 0 9 1 scur
TTT T_TTT 74298 000000006124C000 130 0 4 1 scur
TTT T_TTT 74298 00000000616BC000 3968 0 8 1 scur
TTT T_TTT 74298 0000000061766000 3969 0 8 1 scur
読み取り一貫性は
CLASS BLOCK TYPE どうやって保ってい
1 DATA BLOCK るんだろう？
4 SEGMENT HEADER



別インスタンスで更新してINPQを実行してみた、、
でも、バッファ・キャッシュにはデータブロック
も CR ブロックもキャッシュされない！！
---------- ---------- ---------- ---------------- ---------- ---------- ---------- ---------- -------
TTT T_TTT 74298 0000000061252000 129 0 9 1 scur
TTT T_TTT 74298 000000006124C000 130 0 4 1 scur
TTT T_TTT 74298 00000000616BC000 3968 0 8 1 scur
TTT T_TTT 74298 0000000061766000 3969 0 8 1 scur
読み取り一貫性は
CLASS BLOCK TYPE どうやって保ってい
1 DATA BLOCK るんだろう？？？
4 SEGMENT HEADER



困ったときの tkprof 再び.
---------------------------------------- Waited ---------- ------------
PX Deq: Execution Msg 16 1.14 11.95
latch free 2 0.09 0.10
gc cr block 2-way
2- 2955 0.00 0.99
latch: gc element 37 0.10 1.06
PX Deq Credit: send blkd 374 1.66 183.26
PX Deq Credit: need buffer 18 1.62 9.04
gc cr block congested 9 0.00 0.00
PX qref latch 57 0.00 0.00
latch: object queue header operation 1 0.05 0.05
asynch descriptor resize 18 0.00 0.00



“gc cr block 2-way”の正体は、、、
PARSING IN CURSOR #139733560208016 len=62 dep=1 uid=83 oct=3 lid=83 tim=1318820049985006 hv=3663269604 ad='75e32a68' sqlid='g3q0k53d5k3r4‘
select /*+ full (t_ttt) parallel (t_ttt , 4) */ * from t_ttt
END OF STMT
PARSE #139733560208016:c=0,e=584,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,plh=1049962929,tim=1318820049984999
WAIT #139733560208016: nam='PX Deq: Execution Msg' ela= 12913 sleeptime/senderid=268566527 passes=1 p3=2018548888 obj#=-1
tim=1318820050011499
WAIT #139733560208016: nam='Disk file operations I/O' ela= 826 FileOperation=2 fileno=8 filetype=2 obj#=-1 tim=1318820050012533
WAIT #139733560208016: nam='latch free' ela= 91087 address=1610912864 number=497 tries=0 obj#=75802 tim=1318820050191026
WAIT #139733560208016: nam='Disk file operations I/O' ela= 64416 FileOperation=2 fileno=0 filetype=15 obj#=75802 tim=1318820050352159
*** 2011-10-17 11:54:10.956
WAIT #139733560208016: nam='gc cr block 2-way' ela= 755 p1=4 p2=216 p3=139 obj#=0 tim=1318820051444120
nam='
='gc 2- ela= obj#=0 tim=1318820051444120
nam='
='gc 2- ela= obj#=0 tim=1318820051613291
*** 2011-10-17 11:54:11.701
nam='
='gc 2- ela= obj#=0 tim=1318820051701977
nam='
='gc 2- ela= obj#=0 tim=1318820051702529
WAIT #139733560208016: nam='latch: gc element' ela= 12457 address=2080875056 number=192 tries=0 obj#=0 tim=1318820051740024
nam='
='gc 2- ela= obj#=0 tim=1318820051755882
nam='
='gc 2- ela= obj#=0 tim=1318820051797398
nam='
='gc 2- ela= obj#=0 tim=1318820051827351
nam='
='gc 2- ela= obj#=0 tim=1318820051852407
nam='
='gc 2- ela= obj#=0 tim=1318820051869057
nam='
='gc 2- ela= obj#=0 tim=1318820051884177



“obj#=0”の正体は、、、
v$transaction で UNDO セグメントとブロック
を特定
SQL> select xidusn , xidslot , ubablk , ubafil from v$transaction

XIDUSN XIDSLOT UBABLK UBAFIL
---------- ---------- -------- -------
62 10 16366 4



“gc cr block 2-way”の正体は、、、

……………………
*** 2011-10-17 11:57:01.123
WAIT #140517772372624: nam='PX Deq Credit: send blkd' ela= 410107 sleeptime/senderid=268566527 passes=1 qref=2018547544 obj#=0
tim=1318820221123410
nam='
='gc 2- ela= p1=4 p2=16366 obj#=0 tim=1318820221123917
WAIT #140517772372624: nam='asynch descriptor resize' ela= 2 outstanding #aio=0 current aio limit=362 new aio limit=360 obj#=0
tim=1318820221703383
WAIT #140517772372624: nam='PX Deq Credit: free buffer' ela= 8 sleeptime/senderid=0 passes=0 qref=0 obj#=0 tim=1318820221703467
……………………

UNDOセグメント?



“obj#=0”の正体は、、、
UNDOブロックのダンプを取得
SQL>
SQL> alter system dump datafile 4 block 16366;
16366;
.............................
frmt: 0x02 chkval: 0x8c6d type: 0x02=KTU UNDO BLOCK
.............................
*-----------------------------
* Rec #0x2 slt: 0x0a objn: 75802
slt: 75802(0x0001281a) objd: 75802 tblspc: 8(0x00000008)
* Layer: 11 (Row) opc: 1 rci 0x01
Undo type: Regular undo 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: 0x01003fee.0070.01
KDO Op code: URP row dependencies Disabled
xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x02000fff hdba: 0x0200101a
.............................


Consitency Read on INPQ.

つまり
INPQ の読み取り一貫性は、、、、
CR ブロックではなく、UNDOブロックの送信に
よって担保されている。
バッファ・キャッシュ上には載らないのでx$bh
から CR ブロックの存在を確認できない。


How dose Direct Path Read work ?(after flush.)

更新（未コミット）状態で、バッファ・キャッシュを
flush した状態で、Direct Path Read したら、、、 call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
SQL ID: 94ya02q4qvw95 Plan Hash: 892208080
Parse 1 0.01 0.18 0 6 0 0
select * from t_ttt
Execute 1 0.00 0.00 0 0 0 0
call count cpu elapsed disk query current rows
Fetch 66668 0.91 2.44 3882 70299 0 1000000
------- ------ -------- ---------- ---------- ---------- ---------- ----------
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.02 14.57 0 0 0 0
total 66670 0.92 2.63 3882 70305 0 1000000
Execute 1 0.00 0.00 0 0 0 0
Fetch 66668 8.00 1201.26 15509 1074144 0 1000000
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 66670 8.03 1215.83 15509 1074144 0 1000000
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 83
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
---------- ---------- ---------- ---------------------------------------------------
1000000 1000000 1000000 TABLE ACCESS FULL T_TTT (cr=1074144 pr=15509 pw=0 time=1095448521 us
cost=1067 size=23000000 card=1000000)



flush した状態で、Direct Path Read したら、、、
---------------------------------------- Waited ---------- ------------
library cache lock 1 0.25 0.25
KJC: Wait for msg sends to complete 2 0.00 0.00
library cache pin 1 0.03 0.03
SQL*Net message to client 66668 0.00 0.11
gc cr grant 2-way 4 0.00 0.00
db file sequential read 11627 0.48 792.21
enq: KO - fast object checkpoint 2 0.00 0.00
reliable message 1 0.58 0.58
gc cr block 2-way 1 0.00 0.00
gc cr disk read 11623 0.00 3.96
SQL*Net message from client 66668 51.74 117.64
latch: gc element 7 0.57 0.68
latch: row cache objects 2 0.44 0.46
os thread startup 1 0.78 0.78
KSV master wait 2 14.68 14.73
ASM file metadata operation 1 0.03 0.03
latch: cache buffers lru chain 2 0.02 0.02
latch: object queue header operation 2 0.02 0.03
********************************************************************************


flush した状態で、Direct Path Read したら、、、
select * from t_ttt
………………
obj#=75802 tim=1318830775444681
………………
obj#=75802 tim=1318830776242317
………………
WAIT #140098314552216: nam='gc cr disk read ela= 578 p1=4 p2=2314 p3=140 obj#=0 tim=1318830780982193
gc read'
WAIT #140098314552216: nam='db file sequential read ela= 72697 file#=4 block#=2314 blocks=1 obj#=0
db read'
tim=1318830781133792
gc read'
db read'
tim=1318830781277868
gc read'
db read'
tim=1318830781391595
gc read'
db read'
tim=1318830781455143
FETCH
#140098314552216:c=16998,e=6643732,p=36,cr=319,cu=0,mis=0,r=1,dep=0,og=1,plh=892208080,tim=1318830781480
092
………………

Conculution

Block Mode

Concurrent under RAC Environment

Direct Path Read on 11gR2

Parallel Query (INPQ)


Conclution

Block Mode
・Oracle Database はブロックという単位でデータにアクセスしている
・ブロックには処理に応じたモードがある
・読み取り一貫性を担保するための専用のブロックがある（CRブロック）

Concurrent under RAC Environment
・RAC環境ではブロックのモードを切り替えながらインスタンス間で排他・共有
の状態を制御している
・共有モードのブロックは各インスタンスで同時にキャッシュすることができる
・排他モードのブロックは一つのインスタンスでのみキャッシュすることができる


Conclution

Direct Path Read on 11gR2
・11gでは全件検索時に自動的に Direct Path Read を選択する場合がある
・Direct Path Read でアクセスした場合バッファ・キャッシュにはデータブロック
はキャッシュされない

Parallel Query (INPQ)
・RAC環境で Parallel Query を実行すると複数のノードに処理が分散される
・Parallel Query で Direct Path Read が実行された場合でも読み取り一貫
性は担保される（ただし、CRブロックではなく UNDO セグメントを使って）
・ただし、、、CRブロックがキャッシュから追い出されている場合は、UNDOセグ
メントの読み込みに膨大な時間がかかるのでくれぐれも注意すること


Any Question ?


[INSIGHT OUT 2011] C22 RAC buffer sharing の仕組み(yamashita)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie [INSIGHT OUT 2011] C22 RAC buffer sharing の仕組み(yamashita)

Ähnlich wie [INSIGHT OUT 2011] C22 RAC buffer sharing の仕組み(yamashita) (20)

Mehr von Insight Technology, Inc.

Mehr von Insight Technology, Inc. (20)

[INSIGHT OUT 2011] C22 RAC buffer sharing の仕組み(yamashita)