AP サーバからの 3 層構造での性能問題分析3-a. Optim Query Workload Tunerの活用

OPM を利用したデータベースの問題判別

• 問題判別例

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

アクションと確認事項 OPM画面遷移

１．デッドロック発生の特定と原因解析

正常性の要約 ・ロックアラートの発生を検知

ロックのアラート画面 ・ロックイベントの発生回数や時刻を確認

ロッキングダッシュボード ・解析対象のイベントを選択して分析画面へ遷移

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

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

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

• 問題解析の流れ

１．デッドロック発生の特定と原因解析

• Locking Alert の発生を確認

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

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

（SQL0911,RC=2を検知）となる場合もある

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

Lockingのアラートをクリック

し、Alert Summaryに遷移

１．デッドロック発生の特定と原因解析

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

10:30から10:35にかけて4回 のデッドロックが発生

Lockingの発生状況を見るた めLocking Dashboardへ遷 移

Analyzeから直接デッドロッ

クの詳細へ飛ぶことも可能

１．デッドロック発生の特定と原因解析

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

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

Analyze画面へ遷移

１．デッドロック発生の特定と原因解析

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

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

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

本番環境ではWAS/WASや WAS/バッチ処理といった接続 元の情報から両者の関連を類 推可能

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

この例では、RES_A表への全

件スキャンが2つのアプリケー

ションで重なっている

１．デッドロック発生の特定と原因解析

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

• Statements画面の上半分

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

時 系 列

時 系 列

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

Participantsタブの情報から、デッド ロックの直接の原因となったSQLの 一方が特定できる。

これを手がかりに、問題となる処理

順序や処理対象行の特定を行う

１．デッドロック発生の特定と原因解析

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

• Statements画面の下半分

• 前ページの各SQLごとに詳細情報が確認可能

複数のSQLが同じUOW IDの場合、１トランザクションで実 行されており、複数SQL分のロックが保持される

READ ONLYのSQLだが、NSロックが要求してい るため、他のアプリが排他ロックを保持する場合、

競合しロック待ちが発生する

１．デッドロック発生の特定と原因解析

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

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

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

相手のINSERTに

よる排他ロックで

ロック待ち