「ORAエラーは出ているが、何をDBAへ伝えればよいか分からない」
「alertログとリスナーログの役割の違いが曖昧だ」
Oracleを利用するシステムでは、アプリケーションが受け取ったORAエラーだけでなく、alertログ、トレースファイル、リスナーログなどが障害調査に使われます。
ログごとに役割が異なるため、むやみに全ファイルを探すより、アプリケーション側で確認したエラー番号、発生時刻、接続先、実行SQLを起点にするのが効率的です。
金融システムでは、DBログを参照できる担当者や権限が分かれていることも多くあります。その場合でも、調査対象を具体的に整理できれば、DBAとの連携は速くなります。
この記事では、Oracleログの使い分けと、ORAエラーから原因候補を絞る手順を解説します。
Oracle調査は「アプリ側エラー」からDB側の証拠へつなぐ
最初に、エラー番号、時刻、実行処理、接続サービス、SQLやバインド条件を記録します。そのうえで、インスタンス全体の問題、接続の問題、個別SQL・データの問題を切り分けます。
本番DBへ負荷の高い診断SQLを実行する場合は、運用ルールと承認に従ってください。調査そのものが性能影響を起こさないことも重要です。
| 情報・ログ | 主な役割 | 確認例 |
|---|---|---|
| アプリ側ORAエラー | 処理で受け取ったDBエラー | 番号、SQL、バインド、発生条件 |
| alertログ | インスタンス全体の重要事象 | 起動停止、領域、内部エラー |
| トレースファイル | 個別事象の詳細診断 | ORA-00600、プロセス詳細 |
| リスナーログ | 接続要求と接続結果 | サービス名、接続元、TNSエラー |
| 監視・性能情報 | 負荷や待機の傾向 | CPU、I/O、セッション、ロック |
Oracleログ調査の4ステップ
1．ORAエラーの番号と発生条件を確定する
メッセージの日本語説明だけでなく、ORA番号を正確に記録します。同じ番号でも、実行したSQL、対象データ、権限、接続先によって原因が異なる場合があります。
スタックトレースに複数のORA番号がある場合は、先頭だけでなく原因連鎖を確認します。アプリケーションが独自例外へ置き換えていないかも見ます。
- ORA番号と全文
- 発生日時
- 処理名・SQL識別情報
- バインド条件・対象データ
- 接続サービス・スキーマ
- 再現性
2．接続エラーか、SQL実行後のエラーかを分ける
接続前に失敗しているなら、リスナー、サービス名、ネットワーク、認証、接続数などを確認します。接続後にSQLで失敗しているなら、SQL、データ、ロック、領域、権限などへ調査を進めます。
TNS系エラーが出ていても、原因はリスナー停止だけとは限りません。接続記述、名前解決、サービス登録、接続先間違いも候補です。
3．alertログとトレースでDB全体の事象を確認する
alertログでは、対象時刻前後のインスタンス再起動、表領域不足、アーカイブ先不足、内部エラーなどを確認します。アプリ一件だけの事象なのか、DB全体の事象なのかを切り分けます。
トレースファイルが出力されている場合は、alertログに記載されたパスや識別情報から対象を特定します。内容の解析が難しい場合は、必要情報を添えてDBAへ依頼します。
- インスタンスの起動・停止・異常終了
- 表領域・アーカイブ領域の不足
- バックグラウンドプロセスの異常
- ORA-00600やORA-07445などの内部エラー
- Data Guardやクラスタの状態変化
4．DBAへ調査対象を具体的に渡す
DBログを直接参照できない場合は、「Oracleを確認してください」ではなく、対象時刻、サービス、スキーマ、ORA番号、処理、再現性、アプリ側ログをまとめます。
依頼時に業務影響と緊急度も伝えると、DBAが調査優先度を判断しやすくなります。
【DBA調査依頼】 発生日時：10時15分23秒 接続サービス：PAYDB スキーマ：APP01 処理：振込受付の登録処理 エラー：ORA-00001 対象：取引番号12345 再現性：同一取引のみ 確認依頼：対象制約と既存キー、同時刻のDB側異常有無
Oracleログ調査メモのテンプレート
アプリ側とDB側の情報を一つのメモで関連付けます。
【アプリ側】 発生日時： 処理・画面・ジョブ： ORA番号・全文： SQL・バインド情報： 【接続】 サービス名： スキーマ： 接続元： 【DB側】 alertログ： トレース： リスナーログ： 監視・性能情報： 【判断】 事実： 仮説： 未確認事項：
SQLやバインド値に個人情報や機密情報が含まれる場合は、共有範囲を限定し、必要に応じてマスキングします。
よくある失敗と改善方法
| 失敗 | 起こる問題 | 改善方法 |
|---|---|---|
| エラーメッセージだけで判断する | 番号や発生条件の違いを見落とす | ORA番号・SQL・条件をセットで記録する |
| alertログだけを見る | 接続や個別SQLの問題を追えない | リスナー・アプリログと役割を分ける |
| 無制限に診断SQLを実行する | 本番DBへ追加負荷を与える | 対象を絞り、運用ルールに従う |
若手SE向けチェックリスト
- ORA番号とメッセージ全文を記録した
- 発生時刻・処理・接続先を特定した
- SQLとバインド条件を確認した
- 接続前エラーとSQL実行後エラーを分けた
- alertログの対象時刻前後を確認した
- 必要なトレースとリスナーログを特定した
- DBAへ業務影響を含めて依頼した
まとめ：Oracleログはエラー番号と処理条件を起点にする
Oracleの障害調査では、ログ名を覚えることより、それぞれの役割を理解して必要な情報をつなぐことが大切です。
権限や知識の範囲を超える場合は、無理に結論を出さず、事実と調査対象を整理してDBAへ連携しましょう。
- ORA番号・時刻・SQL・条件を記録する
- 接続問題とSQL実行後の問題を分ける
- alert・トレース・リスナーログを使い分ける
コメント