• 検索結果がありません。

非効率なアクセスプランによるリソースの占有

Dash Board

3. 非効率なアクセスプランによるリソースの占有

アクションと確認事項

OPM画面遷移

1.デッドロック発生の特定と原因解析

Heath Summary

・Locking Alertの発生を検知

Locking

Alert Summary

・Lockingイベントの発生回数や時刻を確認

Locking Dashboard

・解析対象のイベントを選択してAnalyze画面へ遷移

Analyze

・デッドロックに関係するアプリケーションの詳細を確認

・時系列でのSQLステートメント情報

・デッドロックに至ったロックの詳細情報

• 問題解析の流れ

1.デッドロック発生の特定と原因解析

Locking Alert の発生を確認

• OPMによる監視対象データベースを横串でサマリーする「Health Summary」から PEDEMOデータベースに複数のアラートが発生していることを確認

デッドロックによる問題発生の場合、アプリケーション側でのエラー検知

(SQL0911,RC=2を検知)となる場合もある

PEDEMO

データベースのみ アラートが発生

Locking

のアラートをクリック し、

Alert Summary

に遷移

1.デッドロック発生の特定と原因解析

Locking イベントの発生状況や時刻を確認

10:30

から

10:35

にかけて

4

回のデッドロックが発生

Locking

の発生状況を見るた

Locking Dashboard

へ遷

Analyze

から直接デッドロッ クの詳細へ飛ぶことも可能

1.デッドロック発生の特定と原因解析

• 解析対象のイベントを選択して Analyze 画面へ遷移

最新のデッドロック発生を選択

Analyze

画面へ遷移

1.デッドロック発生の特定と原因解析

• デッドロックに関係するアプリケーションの詳細を確認

デッドロックの原因となったアプ リケーション名を確認

ここではサンプル・アプリ同士の デッドロックとなっている。

本番環境ではWAS/WASや

WAS/バッチ処理といった接続

元の情報から両者の関連を類 推可能

パネルの最下部にデッドロック の原因となったSQLステートメン トが表示される。

この例では、RES_A表への全 件スキャンが2つのアプリケー ションで重なっている

1.デッドロック発生の特定と原因解析

• 時系列での SQL ステートメント情報を取得

• Statements画面の上半分

• 2つの接続から発行されたSQLが時系列で表示される

時系列 時系列

デッドロックに関連する2つのアプリ ケーションで実行されたSQLが、時

Participantsタブの情報から、デッド

ロックの直接の原因となったSQLの 一方が特定できる。

これを手がかりに、問題となる処理 順序や処理対象行の特定を行う

1.デッドロック発生の特定と原因解析

• デッドロックに関連する SQL とロックの詳細情報

• Statements画面の下半分

前ページの各

SQL

ごとに詳細情報が確認可能

複数のSQLが同じUOW IDの場合、1トランザクションで実

READ ONLYのSQLだが、NSロックが要求して

いるため、他のアプリが排他ロックを保持する場 合、競合しロック待ちが発生する

1.デッドロック発生の特定と原因解析

• デッドロック発生原因の特定

• 「 statements 」タブからデッドロックに直接関係する SQL を抽出

• 両方のアプリケーションが相手の INSERT コミットを待つ状態となっている

相手のINSERTに よる排他ロックで ロック待ち

関連したドキュメント