ハングしたOracleデータベースをReal-Time ADDMでトラブルシューティングする方法

Oracle® Enterprise Manager（OEM）12cおよび13cには、多数のパフォーマンス分析ツールが搭載されています。その中でも「Real-Time Automatic Database Diagnostic Monitor（Real-Time ADDM）」は、リアルタイムで進行中のパフォーマンス問題をトラブルシューティングおよびチューニングするために、Oracle DBAが活用できる強力なサポートツールです。

本記事では、セッションやプロセスの使用率が100%に達したケース、あるいはI/O、メモリ、インターコネクトに対して事前に設定されたクリティカル制限値を超えたケースなど、さまざまなデータベース障害による緊急事態を、Real-Time ADDMを使って特定し切り抜けるための実践的なノウハウを紹介します。あわせて、従来のADDMとの違いについても比較しながら解説します。

ADDMとは？

ADDM（Automatic Database Diagnostic Monitor）は、Oracle Database 10g以降で提供される診断ツールです。Automatic Workload Repository（AWR）に格納されたデータを自動的に分析し、潜在的なパフォーマンスボトルネックを特定します。検出された各問題については根本原因を突き止め、問題解決のための具体的な推奨策を提示してくれます。

Real-Time ADDMとは？

Real-Time ADDMは、OEM Cloud Control 12cで導入されたツールで、従来であればデータベースの再起動が必要だった「応答なし（ハング）状態」のデータベース問題を、再起動せずに分析・解決できる点が大きな特徴です。

Real-Time ADDMは、事前定義された一連の判定基準に基づいてデータベースの現在のパフォーマンスを分析します。基準に一致する問題（デッドロック、ハング、共有プールの競合、その他の例外状態など）が検出されると、データベースを再起動することなく解決へと導きます。

たとえば、データベースがハング状態に陥り、パフォーマンス低下によってログインすらできないような状況でも、Real-Time ADDMを使えばグローバルリソース上のSQL競合の発生源を特定できます。

また、ADDMと同様のデータベース時間（DB Time）分析も実行可能です。異常に高いデータベースアクティビティが発生している際にReal-Time ADDMを起動すると、現在データベースに影響を与えている主要なパフォーマンス問題を検出し、SQLセッションやアプリケーション接続といったDB Timeの主な消費元を突き止めることができます。

ADDMとReal-Time ADDMの違い

ADDMはデータベースレベルで提供される標準のパフォーマンス診断ツールである一方、Real-Time ADDMはOEM 12c以降で利用できるツールです。Real-Time ADDMを使用するには、対象データベースに接続済みのOEM環境が必要になります。

両者の最大の違いはアクセス方式にあります。Real-Time ADDMは診断モード接続を使用し、通常の接続経路をバイパスして、データベースインスタンスのSystem Global Area（SGA）内にあるActive Session History（ASH）データへ直接アクセスします。この際、ラッチやキューといったグローバルリソースや、大量のホストリソースを消費しません。そのため、ハング状態のデータベースに対しても安全に診断を行えるのです。

Real-Time ADDMを使うべき理由

Real-Time ADDMの主なメリットは以下のとおりです。

• ハング状態や極端な低速化が発生している際に、現在のデータベースパフォーマンスを分析できる
• 深刻な競合（コンテンション）の発生源を特定できる
• DB Time分析により、主要なパフォーマンス問題を検出できる
• 診断接続をSGAへ直接向けられる
• HANGANALYZEやORADEBUG（Oracle Databaseの基本トレースユーティリティ）で巨大なトレースファイルを読み解く作業が不要になる

参考：HANGANALYZEとは？

HANGANALYZEは、ORADEBUGに含まれるオプションの一つで、ハング中またはブロック中のセッションの詳細情報を特定するために使われます。DBAはHANGANALYZEを使ってハングしたデータベースに接続し、トレースファイルを生成できます。生成されたトレースファイルを解析することで、ハングの原因を調査するのが従来からのアプローチでした。ただし、大規模なトレースファイルの読み取りと分析には手間と専門知識が必要です。

Real-Time ADDMによるトラブルシューティング実践デモ

ここでは、OEM 12cがターゲットデータベースに接続された状態で、データベースインスタンスがハングした際にReal-Time ADDM分析を実施する手順を紹介します。

まず、ターミナルセッションを開き、データベースへの接続を試みます。しかし、ハング状態のため接続が確立できず、ログインできないことが確認できます。

次にOEMを開き、ターゲットメニューから「Troubleshooting用のデータベース」を選択し、対象のデータベース名を検索します。ここでは例として CAC****1P を検索しています。

データベース名をクリックします。表示まで多少時間がかかる場合があるため、しばらく待ってから画面を更新してください。すると、次のようにエラーメッセージが表示されます。

このような状況こそ、Real-Time ADDMがDBAにとって絶大な威力を発揮する場面です。早速、該当インスタンスでReal-Time ADDMを使ってみましょう。データベースページからパフォーマンスメニューを開き、「Real-Time ADDM」を選択します。インスタンスがハングしているため、Real-Time ADDMは自動的に直接接続（ダイレクト接続）モードで動作します。

ハング状態のインスタンスに接続する際は、次の画像のようにSYSDBA権限の資格情報を使用する必要があります。

診断モードの接続が確立されると、直近1時間分のASHデータをメモリから直接読み取れるようになります。ログイン後は、画面上部のアクティビティ領域でトップアクティビティを確認できます。

ここで、データベースをハングさせている原因が見えてきます。この例では、アプリケーション由来の待機クラスに問題があることがわかります。さらに詳しく調査するために、診断を開始しましょう。STARTをクリックすると分析が始まり、Real-Time ADDMは直近10分間のASHサンプルをもとに問題を特定します。10分経過したらSTOPをクリックして停止してください。分析完了後、Real-Time ADDMは優先度順に調査結果（Findings）を表示します。次の画像はFindingsタブの分析結果です。

この例では、解消されていないセッション待機チェーンがデータベースのハングを引き起こしていることが示されています。問題を解決するための推奨策は次の画像のとおりです。

この例では、Real-Time ADDMは「特定のセッションを強制終了（KILL）する」ことを推奨しています。終了すべきプロセスの詳細情報を確認するには、Hang Dataタブに移動します。

Final Blockersをクリックすると、ブロックの原因となっているセッション（ブロッカーセッション）の概要が表示されます。推奨に従い、セッションID（SID）、シリアル番号（Serial #）、OSプロセスIDといった詳細情報をもとに、該当セッションをデータベースレベルで強制終了します。それでもデータベースにログインできない場合は、OSプロセスIDを直接killするのが唯一の選択肢となります。ターミナルを開き、問題を引き起こしているプロセスを強制終了してください。

処理後、Real-Time ADDMの分析ウィンドウを見ると、ブロックされていたセッションが処理を再開できていることが確認できます。改めてターミナルからSQL*Plusで接続を試みると、今度は正常に接続できるはずです。

まとめ

OEM Cloud Control 12cのReal-Time ADDMは、クリティカルなデータベース障害を診断するための、Oracleが提供する最も迅速かつ強力なツールの一つです。ハングしたデータベースへの対処において、用途が限られる従来のADDMや、トレース解析に手間のかかるORADEBUGのHANGANALYZEと比較しても、Real-Time ADDMはDBAにとって決定打となる効果的な支援手段といえます。

本記事で紹介した手順を活用すれば、ハングしたデータベースやセッションの問題を迅速に解消し、システムを早期に復旧させることができます。ぜひ日頃の運用に役立ててください。

ご意見やご質問がある場合は、フィードバックタブからお気軽にお寄せください。