Latch: redo allocation

チェンジベクトルを、REDOバッファにコピーするために、REDOバッファ内にスペースを確保しようとする過程で、redo allocationラッチを獲得しなければなりません。 8iまでは、インスタンス全体で一つのredo allocationラッチのみが使用可能であり、これにより、ラッチの競合による性能低下現象が発生する確率が高くなります。 Oracle 9iのから全体のREDOバッファを複数のRedo strandsという空間的に分割して使用することができ、一つのredo allocationラッチが一つのredo strandを管理します。複数のredo allocationラッチを使用可能なので、ラッチの競合を多少減らすことができるのです。Redo strandsの数はLOG_PARALLELISMというパラメータによって決定され、デフォルト値は1です。Oracle 10gのから_LOG_PARALLELISMという名前の隠しパラメータで変更されました。CPUの数が多い（例えば、16個以上）のシステムの場合には、redo allocationラッチと関連競合が発生する確率が高くなるため、_LOG_PARALLELISMの値を大きくして、複数のredo strandとredo allocationラッチを使用するのが良い選択となります。Oracleは_LOG_PARALLELISMパラメータ値を（CPUの数/8）だけ変更させることを勧めています。

Oracle 10gのからDynamic Parallelismという新しい機能を導入しました。 Dynamic Parallelism機能は_LOG_PARALLELISM_DYNAMIC隠しパラメータの値をTRUEに指定すると、有効になり、デフォルトはTRUEです。（実際のデフォルトはマイナーバージョンごとに異なる場合がありますので、チェックしてください。）この機能を使用すると、動的にredo strandsの数を調整することでに見えます。 「見える」という表現を使った理由は、まだこの機能について正式に説明されたドキュメントがないからです。生成可能な最大redo strandsの数は、Oracle 10g R2から、基本的に18 + _LOG_PARALLELISM_MAXであり、この値だけredo allocationラッチを生成します。 _LOG_PARALLELISM_MAXのデフォルト値は2であり、CPUの数を超えることはできません。しかし、生成されたラッチが常にある使用されるわけではなく、Oracleによって動的に使用されます。Oracle 9iので使用可能なredo allocationラッチの数CPUの数/8を推奨することに比べれば、使用可能なredo allocationラッチの数が大幅に増えたという事実も注目に値します。

次のテストは、CPUの数が4であるシステムで同時に10個のセッションでのREDOデータを生成した後、redo allocationラッチの活動性を照会した結果です。

SQL> select name, gets, misses, immediate_gets, immediate_misses
from v$latch_children
where name = 'redo allocation';

NAME                  GETS     MISSES IMMEDIATE_GETS IMMEDIATE_MISSES
--------------- ---------- ---------- -------------- ----------------
redo allocation       1264          1           7368                6
redo allocation        889          0            533                0
redo allocation        134          0              0                0
redo allocation         72          0              0                0
redo allocation         10          0              0                0
redo allocation         12          0              0                0
redo allocation         12          0              0                0
redo allocation        882          0              0                0
redo allocation        198          0              0                0
redo allocation          6          0              0                0
redo allocation          6          0              0                0
redo allocation          6          0              0                0
redo allocation        117          0              0                0
redo allocation          5          0              0                0
redo allocation          5          0              0                0
redo allocation          5          0              0                0
redo allocation          5          0              0                0
redo allocation          5          0              0                0
redo allocation          5          0              0                0
redo allocation          5          0              0                0

redo allocationラッチを獲得する過程で競合が発生した場合latch：redo allocationイベントを待機することになります。

latch freeイベントと同じです。

latch freeイベントと同じです。

latch：redo writingのRedo関連競合を参照してください。

Oracle 10gのからprivate redo strandsという機能を導入して、複数のstrandsの概念をさらに拡張させました。一般的に、REDOデータを生成するには、チェンジベクターをPGAに作成した後、必要なラッチを確保して、REDOバッファにコピーする一連の過程を経なければなら一方、private redo strandsを使用すると、REDOレコードがShared Pool内private strands領域に生成されます。Private strands領域は、プロセス間で共有されていないため、REDOを生成する過程でラッチを獲得する必要がなく、LGWRによってREDOログ・ファイルに直接書き込まれるため、PGAでREDOバッファにコピーするプロセスが不要となります。これを「zero copy redo」と表現することもあります。隠しパラメータである_LOG_PRIVATE_PARALLELISM値をTRUEに変更すると、この機能が有効になります。この機能については、まだ正式に知られていません。また、REDOログを利用するLogminer、Logical Standby、Streamsなどまだ互換性がないことが知られています。この機能は、広く使用される場合、REDO関連ラッチの競合は、もはや問題ではないことが期待されます。 V$SGASTATビューを使用してShared Pool内に生成されたprivate strands領域を確認することができます。