キャッシュ・フュージョン（基本動作編）

前回(キャッシュ・フュージョン（概要編） - 忘れかけのIT備忘録)に引き続き、今回はキャッシュ・フュージョンの基本的なリソースの取得方法について調査しました。
こちらも参考文献を自分なりに解釈してほとんど写経したものです。

基本的なリソースの取得方法は3つです。
①データブロック転送(block 2-way)
②データブロック転送(block 3-way)
③ディスクからの読み込み(block 3-way)

①データブロック転送(2-way)
リソースをキャッシュしているインスタンスが存在している場合、リソース要求側(リクエスター)はリソースマスターにリソース(CURRENTバッファ、CRバッファ)を要求し、プレースホルダ・イベントとして「gc current/cr block request」で待機します。
※リソース要求時点では、リソースをディスクから取得するのか、ブロック転送で取得するのか分からないため、いったんプレースホルダに「gc current/cr block request」イベントを格納します

リソース保持側(リソースホルダー)がブロック転送する際、リソースホルダーのインスタンスでログバッファの変更内容がREDOログファイルに記録されていない場合、ブロック転送前にLGWRにログフラッシュを指示します。
リソースホルダーからリソースを取得するとFixed-up・イベントとして「gc current/cr block 2-way」に変更します。
なお、プレースホルダ・イベントは、AWRの「Top 10 Foreground Events by Total Wait Time（Top 10 Events）」には出力されないようです。

「津島博士のパフォーマンス講座第79回 Real Application Clustersの待機イベントについて」を参考に待機イベントフロー図も書いてみました。

②データブロック転送(3-way)
リソースをキャッシュしているインスタンスが存在している場合、リソース要求側(リクエスター)はリソースマスターにリソース(CURRENTバッファ、CRバッファ)を要求し、プレースホルダ・イベントとして「gc current/cr block request」で待機します。

リソース保持側(リソースホルダー)がブロック転送する際、リソースホルダーのインスタンスでログバッファの変更内容がREDOログファイルに記録されていない場合、ブロック転送前にLGWRにログフラッシュを指示します。
リソースホルダーからリソースを取得するとFixed-up・イベントとして「gc current/cr block 3-way」に変更します。
※データブロックの取得要求は最大3ノード経由となります。要求されたブロックはブロックが持っているアドレスから特定するため、1回リソースマスターに問い合わせれば要求されたブロックの在り処が分かります。「block 4-way」は存在しません。

こちらも「津島博士のパフォーマンス講座第79回 Real Application Clustersの待機イベントについて」を参考に待機イベントフロー図も書いてみました。

③ディスクからの読み込み
リソースをキャッシュしているインスタンスが存在しない場合、リソースマスターからLock Grant(ロック権限)を受け取り、データをディスクから読み込みます。

リソース要求側(リクエスター)はリソースマスターにリソース(CURRENTバッファ、CRバッファ)を要求している間、プレースホルダ・イベントとして「gc current/cr block request」で待機します。
リソースマスターからLock Grantを受け取るとFixed-up・イベントとして「gc current/cr grant 2-way」に変更します。
※リソースマスターでリソース存在有無が確認できるため(別インスタンスへ確認する必要がないため)、「grant 3-way」は存在しません