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に よる排他ロックで ロック待ち
ドキュメント内
Microsoft PowerPoint - OptimPerformanceManager構築ガイド_ ppt
(ページ 64-72)