latch：cache buffers lru chain

1.概要

ワーキング・セット（LRU + LRUW）の参照や変更するをプロセスは、必ずそのワーキング・セットを管理しているcache buffers lru chainラッチを獲得しなければなりません。このラッチを獲得する時に競合が発生すると、latch：cache buffers lru chain 待機イベントで待機します。

Oracleは、次のような場合にcache buffers lru chainラッチを獲得しなければなりません。

1)フリーバッファの割り当てするためにLRUリストを参照する場合
2)DBWRが使用済バッファをファイルに記録するために、LRUWリストを参照して、そのバッファをLRUリストに移動する場合

DBWRは、次のような場合に使用済バッファをファイルに記録します。

• Oracleのプロセスがフリーバッファを獲得するために、DBWRに使用済バッファの記録が必要な場合
• Oracleのプロセスがパラレルクエリー、表領域のバックアップ、TRUNCATE、DROPなどのタスクを実行する場合
• 定期的にまたは管理上の理由でチェックポイント処理が実行される場合
  FAST_START_MTTR_TARGET（または LOG_CHECKPOINT_TIMEOUT）によって指定された時間での回復を確保するために、定期的にチェックポイントを実行または、管理者がチェックポイントのコマンドを実行したり、ログファイルのスイッチによってもチェックポイントが発生します。

cache buffers lru chainラッチ競合の最も主な原因は、過度なフリーバッファが必要な場合です。非効率的なSQL文がフリーバッファを過度に必要とする最も典型的なケースですが、同時に複数のセッションが非効率的なSQL文を実行するようになればフリーのバッファに移動する過程や、使用済バッファを記録する過程で、cache buffers lru chain ラッチを獲得するために競合することになります。

cache buffers chainsラッチとcache buffers lru chainラッチの違いを理解する必要があります。
同じ表や索引を複数のセッションが同時にスキャンする場合は、cache buffers chainsラッチの競合が発生する可能性が高く、同じチェーンの競合が発生します。
しかし、別の表や索引を複数のセッションが同時にスキャンする場合は、cache buffers lru chainラッチの競合が発生する可能性が高くなります。
複数のセッションがすべて、他のブロックをメモリに読み込もうとし、フリーバッファを確保する必要が増えた場合、ワーキング・セットの競合が発生しやすくなります。
特に、データの変更を頻繁に行ったため使用済バッファの数が多く、DBWRがチェックポイントのためにLRUWリストを参照する回数が多い場合は、cache buffers lru chainラッチの競合はさらに激しくなります。

cache buffers lru chainラッチ競合のもう一つの重要な特徴は、物理的なI/Oを伴うということです。非効率的な索引のスキャンによる、db file sequential read 待機とcache buffers lru chainラッチの競合が同時に発生することになります。
不要なプール・スキャンの形の表が多い場合は、db file scattered read待機とcache buffers lru chainラッチの競合が同時に発生することになります。実際には、cache buffers chainsラッチの競合とcache buffers lru chainラッチの競合が同時に発生する場合が多いです。
バッファキャッシュのサイズがあまりに小さいか、チェックポイントの周期があまりに短い場合でも、cache buffers lru chainラッチの競合が増加します。

2.待機パラメータと待機時間

2.1.待機パラメータ

latch：cache buffers lru chain待機イベントの待機パラメータは以下の通りです。

• P1：プロセスが待機しているラッチのメモリアドレス
• P2：ラッチの番号（V $ LATCHNAME.LATCH＃と同じ）に対応するラッチ名を探すには、以下のSQLステートメントを実行するとされている。

SELECT * FROM v $ latchname WHERE latch＃=＆p2_value;

• P3：トライアル回数。すなわち、ラッチを獲得するために、プロセスがトライアル回数を示す。

2.2.待機時間

イベントの待機時間は指数増加します。

3.チェックポイントとソリューション

3.1.非効率的なSQL文をチューニングする。

非効率的なSQL文をチューニングして論理読み取りを小さくすると、自然にバッファキャッシュへのアクセスが減り、その分cache buffers lru chain latch競合も減少します。

3.2.バッファキャッシュのサイズを十分に大きくする

バッファキャッシュサイズが小さすぎる場合、フリーバッファを割り当てるための作業が非常に頻繁に発生し、この過程でcache buffers lru chain latch競合が増加します。

3.3.チェックポイントパラメータの見直し

チェックポイントの周期があまりに短い場合は、DBWRが盛んに使用済バッファを記録するようになり、この過程でcache buffers lru chain latchの競合が発生します。この場合には、チェックポイントのサイクルを適切に調整しなければなりません。 FAST_START_MTTR_TARGET パラメータを使用すると、チェックポイントの周期を調整することができます。

4.豆知識

4.1.バッファキャッシュの構造

latch：cache buffers chains＃バッファキャッシュの構造を参照してください。

ツイートする

< 前へ ｜ 次へ >
▲ページトップへ

 

この情報は、すべてのOracleバージョン、プラットフォームをサポートする物ではございません。実際の検証などを行う場合、十分なテストの上、自己責任での対応をお願いします。

Oracleの事なら日本エクセムホームへ | 会社情報 | 製品情報 | お問い合わせ | プライバシーポリシー

Copyright (C) EXEM JAPAN Corp. All Rights Reserved.