Gc current split

目次

基本情報

 

gc current splitイベントはgc cr/current requestイベントのFixed-upイベントで、ホルダーのノードがインデックスブロックを送信する過程で、インデックスの分割(Index Split)が発生したことを意味します。gc cr/current requestイベントがgc current splitイベントに変更された流れは、以下の通りです。

リクエストノードのユーザプロセスが特定のインデックスブロックを読もうとします。

・ユーザプロセスは、ブロックの適切なバージョンがローカルバッファキャッシュにないことを確認し、
 マスターノードのLMSプロセスにブロック転送を要求します。ユーザプロセスは、応答を受信するまで、
 gc current requestイベントを待機します。
・ホルダーノードのLMSプロセスがそのインデックスブロックのロックを獲得しようとする時点で、
 インデックスの分割(Index Split)が発生している場合は、インデックスの分割が終わるまで
 待機しなければなりません。インデックスの分割が終わった後、ホルダーノードは、そのブロックと
 インデックスの分割が発生したことを示すメッセージを一緒に送信します。
・ユーザプロセスは、ブロックを送信された後に応答メッセージから送信過程で、インデックスの分割が
 発生していることを確認し、gc cr/ current requestイベントをFixed-upイベント
 gc current splitイベントに変更します。

 

gc current splitイベントは、ルートノード、ブランチノード、リーフノードのブロックに関係なく、そのブロックがインデックスの分割のために、ブロッキングされている状況では、共通して発生することができます。特定のリーフ・ノードを分割する過程では、その親ノードのブロックも変更が禁止されるからです。

gc current splitイベントと関連しているもう一つの待機イベントはenq:TX – index contentionイベントです。テーブルの特定の行を変更しようとするプロセスは、もし関連インデックスブロックが他のプロセスによって分割されている場合、インデックスの分割が完了するまで待たなければなりません。この時、待機するイベントがenq:TX – index contentionイベントです。 次の結果は、複数のプロセスによる同時INSERT操作によるインデックスの分割が頻繁に発生する作業の下でSQL Traceを利用して、特定のプロセスの待機現象をキャプチャしたものでgc current splitイベントとenq:TX – index contentionイベントが観察されていることを確認することができます。

 

WAIT #9: nam='gc current split' ela= 140584 p1=14 p2=28311 p3=33554433
WAIT #9: nam='enq: TX - index contention' ela= 5478 p1=141505 p2=32737 p3=6585
…
WAIT #9: nam='gc current split' ela= 66390 p1=14 p2=28410 p3=33554433
WAIT #9: nam='enq: TX - index contention' ela= 1343 p1=141505 p2=33420 p3=6576
…
WAIT #9: nam='gc current block 2-way' ela= 1139 p1=14 p2=28421 p3=33554433
WAIT #9: nam='enq: TX - index contention' ela= 163 p1=141505 p2=33424 p3=6576
…

パラメータと待機時間

待機パラメータ

gc current splitイベントなどFixed-upイベントは、P1、P2、P3の値が別途付与されず、Placeholderイベント(ここではgc cr requestイベント)と同じ値を持つものと解釈すればよい。

 

待機時間

Check Point & Solution

 

gc current splitの解決

Fixed-upイベントにgc current splitイベントがたくさん目撃されるということは、同じテーブルのブロックのインデックス分割が過度に発生するということを意味します。このイベントの待機を解消する手法は、enq:TX – index contentionイベントを解消する手法と同じです。

シーケンス値を使用して、インデックスキーを生成する場合には、一番右のリーフブロックに挿入が集中して、インデックス分割による競合が多く発生します。この場合には、次のような手法を適用することができます。

1.インデックスキーの組み合わせを変更して右偏向(Right-hand)現象を解消することができます。
2.シーケンスのキャッシュ・サイズを増加させます。シーケンスのキャッシュ・サイズが大きい場合は、
 各ノードで使用されるシーケンスの値のセットが大きな違いを示すため、同一のインデックスのリーフ・ブロックの競合が
 減ります。
3.インデックスブロックのブロックサイズを増加する方法も使用可能です。ブロックサイズが大きいそれだけインデックスの
 分割が少なく発生するためです。しかし、ブロックサイズは、いくつかの状況を考慮した後に決定しなければなら事案なので、
 慎重に決めなければいけません。ブロックのサイズが大きくなると、インデックスの分割回数は減らすことができますが、
 バッファロックによる競合は増加する傾向があるからです。