Articles /

Rajat DBAのブログ

これは、Metalinkのリファレンスノート22908.1のコピーであり、アクセス権を持っていない人のためのものです。

  1. ラッチとは何ですか？
    ラッチは、SGA内の共有データ構造を保護するために使用される低レベルのシリアル化メカニズムです。 ラッチの実装は、特にプロセスがラッチを待機するかどうか、およびどのくらいの期間待機するかに関して、オペレーティングシステムに依存します。

ラッチは、非常に迅速に取得して解放することができるロックの一種です。 通常、ラッチは、複数のプロセスが特定の時間に同じコードを実行するのを防ぐために使用されます。 各ラッチに関連付けられているクリーンアップ手順は、ラッチを保持している間にプロセスが死亡した場合に呼び出されます。 ラッチには、デッドロックを防ぐために使用される関連レベルがあります。 プロセスがあるレベルでラッチを取得すると、その後、そのレベル以下のレベルでラッチを取得することはできません（nowaitを取得しない限り）。

2.ラッチとエンキュー

エンキューは、Oracleで使用される別のタイプのロック機構です。
エンキューは、複数の同時プロセスが”既知の”リソースをさまざまな程度共有することを可能にする、より洗練されたメカニズムです。 同時に使用することができる任意のオブジェクトは、エンキューで保護することができます。 良い例は、テーブルのロックです。 たとえば、2つのプロセスが共有モードまたは共有更新モードなどでテーブルをロックできます。 一つの違いは、エンキューがOS固有のロック機構を使用して取得されることです。 エンキューを使用すると、ユーザーはロックに値、つまり要求しているモードを保存することができます。 OSロックマネージャは、ロックされたリソースを追跡します。 プロセスが要求されたモードと互換性がなく、ロックがwaitで要求されたためにロックを許可できない場合、OSは要求しているプロセスをFIFOで処理され

ラッチとエンキューのもう一つの違いは、ラッチではエンキューのようにウェイターの順序付けられたキューがないことです。 ラッチウェイターは、タイマーを使用してウェイクアップと再試行またはスピンを行うことができます（マルチプロセッサでのみ）。 すべてのウェイターは（スケジューラに応じて）同時に再試行しているので、誰もがラッチを取得する可能性があり、おそらく最初に試してみるのが最後の

  1. ラッチを取得する必要があるのはいつですか？

プロセスは、SGA(System Global Area)内の構造体を操作するときにラッチを取得します。 それは構造と働く一定期間の掛け金を握り続ける。 ラッチは、プロセスが構造で終了するとドロップされます。 各ラッチは、ラッチの名前で識別される異なるデータセットを保護します。

Oracleは、ラッチで動作するために”test and set”のようなアトミック命令を使用します。 他のプロセスによってラッチが既に取得されているコードの一部の実行を待機しているプロセスは、ラッチが解放されるまで待機します。 例としては、redo割当ラッチ、コピーラッチ、アーカイブ制御ラッチなどがあります。 基本的な考え方は、共有データ構造への同時アクセスをブロックすることです。 ラッチを設定および解放する命令はアトミックであるため、OSは1つのプロセスだけがそれを取得することを保証します。 それは唯一の命令であるので、それは非常に高速です。 ラッチは短時間保持され、保持している間にホルダーが異常に死亡した場合に備えてクリーンアップのメカニズムを提供します。 この清掃は、PMONのサービスを使用して行われます。

ラッチ要求は、”willing-to-wait”または”no wait”の二つのモードで行うことができます。 通常、ラッチは”willing-to-wait”モードで要求されます。 “Willing-to-wait”モード
の要求は、ラッチが取得されるまでループし、待機し、再度要求します。 “待機なし”モードでは、プロセスはラッチを要求します。 いずれかが利用できない場合は、待つのではなく、別のものが要求されます。 すべてが失敗した場合にのみ、サーバープロセスは待機する必要があります。

“willing-to-wait”ラッチの例は次のとおりです。共有プールおよびライブラリキャッシュラッチ
“no wait”ラッチの例は、redo copyラッチです。

5. ラッチの競合の原因は何ですか？必要なラッチがビジーである場合、それを要求するプロセスはスピンし、再び試行し、まだ利用できない場合は再びスピンします。 ループは、初期化パラメータ_SPIN_COUNTによって決定される最大回数まで繰り返されます。 このループ全体の後、ラッチがまだ使用できない場合、プロセスはCPUを降伏させてスリープ状態にする必要があります。 最初は一センチ秒のために眠っています。 この時間は、その後のすべての睡眠で倍増します。

これにより、ラッチが使用可能になるまで、cpu使用率が低下し、CPU使用率が増加します。 CPU使用率は、プロセスの「回転」の結果です。 “回転”とは、プロセスが一定の時間間隔の後にラッチの利用可能性を探し続けることを意味し、その間にスリープ状態になります。

  1. 内部ラッチの競合を特定するにはどうすればよいですか？

関連するデータディクショナリ照会するビュー:

V$LATCH
V$LATCHHOLDER
V$LATCHNAME

V.LATCHテーブルの各行には、異なるタイプのラッチの統計が含まれています。 テーブルの列には、さまざまなタイプのラッチ要求のアクティビティが反映されます。

willing-to-wait willing-to-wait
要求で要求されたラッチが利用できない場合、要求元プロセス
は短時間待機し、ラッチを再度要求します。
プロセスは
ラッチが使用可能になるまで待機し要求を続けます。

待機なし即時要求で要求されたラッチが
使用できない場合、要求プロセスは
待機せず、処理を続行します。

V$LATCHNAMEキー情報:

ラッチに対する成功した待機待機要求の数を取得します。

は、最初のwilling-to-waitリクエスト
が失敗した回数をミスします。

は、最初のwiling-to-wait要求の後に、プロセスが要求されたラッチ
を待機した回数をスリープします。

IMMEDIATE_GETS各ラッチの成功した即時要求の数。

IMMEDIATE_MISSES各ラッチの失敗した即時要求の数。

ラッチヒット率の計算

ラッチのヒット率を取得するには、次の式を適用します。

“willing-to-wait”Hit Ratio=(GETS-MISSES)/GETS
“no wait”Hit Ratio=(IMMEDIATE_GETS-IMMEDIATE_MISSES)/IMMEDIATE_GETS

この数は1に近いはずです。 そうでない場合は、ラッチ名

  1. に従って調整して、ラッチ情報を取得するのに便利なSQLスクリプト

/*
** システム全体のラッチ統計情報を表示します。
*/
列名フォーマットA32見出し”ラッチ名”を切り捨て
列pid見出し”ホルダー PID”
選択c.name a.addr,a.gets,a.misses,a.sleeps,
a.immediate_gets,a.immediate_misses,b.pid
from v$latch a,v$latchholder b,v$latchname c
ここで、a.addr=b.laddr(+)
およびa.latch#=c.latch#
a.latchによる順序#;

/*
** ラッチアドレスが指定されている場合は、ラッチ名を調べます。
*/
列名書式a64見出し’名前’
選択a.name ここで、b.addr=’&addr’
およびb.latch#=a.latch#;

/*
** ラッチの統計情報をラッチ名で表示します。
*/
列名フォーマットa32見出し’ラッチ名’
列pid見出し’ホルダー PID’
select c.nameここで、a.addr=b.laddr(+)およびa.latch#=c.latch#
およびa.latch#=c.latch#
となります。c.name ‘&latch_name%’のように.latchによる順序#;

  1. すべてのラッチのリスト

Oracleのバージョンは、既存のラッチに割り当てられたラッチ#で異なる場合があります。
次のクエリは、すべてのラッチと割り当てられた番号を識別するのに役立ちます。

列名フォーマットa40見出し’ラッチ名’
select latch#,name from v$latchname;

  1. DBAにとって最も懸念されるラッチのリスト
  • バッファーキャッシュラッチ:バッファーキャッシュ内のデータブロックを保護する2つの主なラッチがあります。 これらの2つのラッチの競合は、通常、データベースのI/Oレートが高い場合に発生します。 これらのラッチの競合を減らし、特定のinitを調整することで調整することができます。oraパラメータ。

キャッシュバッファチェーンラッチ:

このラッチは、バッファキャッシュ内のブロックがアクセス(固定)されるたびに取得されます。

キャッシュバッファチェーンラッチの競合を減らすには、通常、関係するSQLのI/O要件を調整して最小化することによって論理I/Oレートを減らす必 高いI/Oレートは、ホットブロック(高度にアクセスされるブロックを意味する)の兆候である可能性があります。

注163424を参照してください。1この問題を正しく識別するために、データベース内のホットブロックを識別する方法。

キャッシュバッファLRUチェーンラッチ:

キャッシュバッファlruチェーンラッチは、バッファキャッシュに新しいブロックを導入するために取得され、バッファをディスクに書き戻すとき、特にバッファキャッシュ内のすべてのダーティブロックを含むLRU(最も最近使用されていない)チェーンをスキャンしようとするときに取得されます。

バッファキャッシュのサイズを増やし、新しいブロックがバッファキャッシュに導入される速度を減らすことにより、キャッシュバッファlruチェー バッファキャッシュのサイズは、DB_BLOCK_SIZEとDB_BLOCK_BUFFERSの2つのパラメータで指定されます。 実際には、データベースを再作成せずに変更できるのはDB_BLOCK_BUFFERSだけです。 バッファープールを調整するときは、キャッシュヒット率にほとんどまたは何も寄与しない追加のバッファの使用を避けてくださ よくある間違いは、DB_BLOCK_BUFFERSの値を増やし続けることです。 このような増加は、完全なテーブルスキャンまたはバッファキャッシュを使用しないその他の操作を実行している場合には効果がありません。 複数のバッファプールは、このラッチの競合を減らすのに役立ちます。構成パラメータDB_BLOCK_LRU_LATCHESを調整することにより、追加のキャッシュバッファlruチェーンラッチを作成できます。 構成パラメータ_DB_BLOCK_HASH_BUCKETS

  • REDOLOGバッファー-ラッチを増やすことで、キャッシュ-バッファー-チェーン-ラッチの負荷を軽減できる場合があります。 バッファ内の領域を割り当てるには、redo割り当てラッチを取得する必要があります。 作成されるredoログエントリが構成パラメータLOG_SMALL_ENTRY_MAX_SIZEより大きい場合、redo割り当てラッチを取得するセッションは、割り当てラッチを保持したまますぐにredoバッファにエントリをコピーすることができます。 ログエントリがLOG_SMALL_ENTRY_MAX_SIZEより大きい場合、セッションはredo割り当てラッチを解放し、エントリをコピーするためにredoコピーラッチを取得します。 Redo割り当てラッチは1つだけですが、最大LOG_SIMULTANEOUS_COPIES割り当てラッチが存在する可能性があります。

Redo allocation latch:

このラッチは、redoログ-バッファ内のredoエントリの領域の割り当てを制御します。 インスタンスごとに1つのredo割り当てラッチがあります。マルチcpuシステムのLOG_SMALL_ENTRY_MAX_SIZEの値を小さくして、
redo copyラッチを強制的に使用することで、Oracle7でのこのラッチの競合を減らすことができます。 Oracle8Iでは、このパラメータは廃止されているため、可能な場合は、NOLOGGING機能を使用してLOG_BUFFERのサイズを増やすか、ログ・バッファの負荷を軽減することを検討

Redo copy latch:

このラッチは、redologバッファにredoレコードを書き込むために使用されます。 このラッチは、シングルcpuシステムとマルチcpuシステムの両方で待機されます。マルチcpuシステムでは、LOG_SIMULTANEOUS_COPIESの値(Oracle8Iでは非表示)を増やすか、LOG_ENTRY_PREBUILD_THRESHOLD(Oracle7では文書化されていません)を増やすことで、競合を減らすことができます。

  • ライブラリキャッシュ

ライブラリキャッシュラッチ:

ライブラリキャッシュラッチは、共有プール内のライブラリキャッシュに保持されているキャッ 新しい文をライブラリキャッシュに追加するには、ライブラリキャッシュのラッチを取得する必要があります。 解析中に、Oracleはライブラリ・キャッシュで一致する文を検索します。 見つからない場合、OracleはSQL文を解析し、ライブラリ・キャッシュ・ラッチを取得して新しいSQLを挿入します。

このラッチの競合を減らすための最初のリソースは、アプリケーションが可能な限りSQL文表現を再利用していることを確認することです。 アプリケーションで可能な限りバインド変数を使用します。 このラッチのミスは、アプリケーションがSQLを高いレートで解析しており、解析CPUのオーバーヘッドが多すぎる可能性があることを示す兆候でもあります。アプリケーションがすでに調整されている場合は、SHARED_POOL_SIZEを増やすことができます。 アプリケーションがライブラリキャッシュを適切に使用していない場合、処理する構造が大きくなると競合が悪化する可能性があることに注意し

_KGL_LATCH_COUNTパラメーターは、ライブラリキャッシュラッチの数を制御します。 デフォルト値は十分である必要がありますが、ライブラリキャッシュラッチの競合が解決できない場合は、この値を増やすことをお勧めします。 _KGL_LATCH_COUNTのデフォルト値は、CPU_COUNTの後の次の素数です。 この値は66を超えることはできません(:を参照)。

ライブラリキャッシュピンラッチ:

ライブラリキャッシュピンラッチは、ライブラリキャッシュ内の文を再実行するときに取得する必要があります。 このラッチのミスは、SQLの実行率が非常に高い場合に発生します。

ライブラリキャッシュpinラッチの負荷を軽減するためにできることはほとんどありませんが、publicシノニムではなくprivateまたはOWNERなどの直接オブジテーブルが役立つかもしれません。

  • 共有プール関連ラッチ

共有プールラッチ:

ライブラリキャッシュラッチはライブラリキャッシュを使用して操作を保護しますが、共有プールラッチは共有プール内のメモリを割り当てたり解放したりする際に重要な操作を保護するために使用されます。
アプリケーションがリテラル(非共有)SQLを使用する場合、スケーラビリティとスループットが大幅に制限される可能性があります。 新しいSQLステートメントを解析するコストは、CPU要件と、ライブラリキャッシュと共有プールのラッチを取得して解放する必要がある回数の両方の点で Oracle9より前は、ライブラリ-キャッシュ内のメモリーの割り当てを保護するために、データベース全体にこのようなラッチが1つだけ存在していました。 Oracle9では、このリソースの競合を緩和するために複数のchildが導入されました。

共有プールのラッチを減らす方法は、可能な場合はハード解析を避け、一度解析し、多くを実行することです。 リテラルSQLを削除すると、共有プールのラッチを回避するのにも役立ちます。 Shared_poolのサイズとMTS(共有サーバーオプション)の使用も、共有プールのラッチに大きく影響します。 注62143.1では、共有プールおよび共有プールラッチの問題を特定して修正する方法について説明します。

Row cache objects latch:

このラッチは、ユーザープロセスがキャッシュされたデータディクショナリ値にアクセスしようとしているときに機能します。

このラッチに競合があることは一般的ではなく、このラッチの競合を減らす唯一の方法は、共有プールのサイズを増やすことです(SHARED_POOL_SIZE)。

  1. チューニング_SPIN_COUNT(Oracle7の_LATCH_SPIN_COUNT))

SPIN_COUNTは、プロセスがバックオフしてスリープ状態になる前にラッチを取得しようとする回数を制御します。 これは基本的に、プロセスがspin_COUNT試行のラッチを取得しようとしているタイトなCPUループにあることを意味します。 単一のCPUシステムでOracleプロセスがラッチを取得しようとしたが、それが他の誰かによって保持されている場合、プロセスはCPUを解放し、再試行する前 しかし、マルチプロセッサシステム(SMP)では、ラッチを保持しているプロセスが他のCpuのいずれかで実行されている可能性があるため、次のいくつかの命令でラッチを解放する可能性があります(ラッチは通常、非常に短い期間しか保持されません)。

SPIN_COUNTの値を変更することでパフォーマンスを調整できます。 高い値が使用される場合、ラッチは低い値を使用する場合よりも早く達成されます。 ただし、SPIN_COUNTに高い値を使用すると、より多くのCPU時間を使用してラッチを取得することができます。 構成パラメーター_LATCH_SPIN_COUNTまたはSPIN_COUNTの値を増やすことで、このセッションがスリープする確率を減らすことができます。 このパラメータは、セッションがスリープ前にラッチを取得するための試行回数を制御します。 ラッチを回転させるとCPUが消費されるため、このパラメータを大きくすると、システム全体のCPU使用率が増加することがあります。 お使いのコンピュータが100％のCPUに近く、アプリケーションが応答時間駆動ではなくスループットである場合は、CPUを節約するためにSPIN_COUNTを減らすことを検討 SPIN_COUNTの調整は試行錯誤です。 一般に、システム上に十分な空きCPUリソースがある場合にのみSPIN_COUNTを増やし、空きCPU容量がない場合にのみ減少させます。

Leave a Reply