【Oracle Database 12c対応】トラブル未然防止／迅速解決のための「アラートログ監視の5大キーワード」：Oracleサポート出張所（3）（1/2 ページ）

本連載は、「Oracle Database」で発生するトラブルをどう解決すればいいのか。データベースの運用管理において、より円滑に業務を進めるために必要なノウハウを紹介していきます。今回は「アラートログで監視しておくべき5大キーワード」を解説します。

[大野高志，株式会社アシスト]

連載バックナンバー

　本連載「Oracleサポート出張所」は、「Oracle Database」で発生するトラブルを「どんな方法で」「どのように」解決していくか。長年、筆者がOracle Databaseのサポート業務で培ってきた経験を基に、Oracle Databaseの運用管理をする上で「より円滑に、かつ成長を見据えて業務を推進していく」ために必要なノウハウを紹介していきます。

　前回は、トラブル解決の第一歩となる「アラートログの見方」を解説しました。今回は、「そのアラートログから、何を監視すべきか」のポイントを解説します。

アラートログの的確な監視は、トラブルの未然防止や迅速解決につながる

　サポートセンターには、トラブルだけでなく運用管理に関する問い合わせも数多く寄せられます。中でも多いのが「アラートログに問題のあるメッセージが出力された場合にメンバーに通知して共有することを検討しています。この場合、どんなメッセージを対象にして監視すべきでしょうか」といったものです。実はこちら、意外と多くの方から問い合わせがあります。

　アラートログはOracle Databaseで発生したさまざまなイベントが記録されたログです。つまり、アラートログを的確に監視しておくことが、トラブルを未然に防ぎ、迅速なトラブル対応を実現する第一歩になります。

　ここではアラートログの監視で有効となるキーワードと、その理由を解説します。監視すべきメッセージは環境ごとに異なるので、全てではなく、必要に応じて取捨選択をし、監視する時間帯なども検討するのがポイントです。キーワードは以下の通りです。

アラートログのメッセージ	監視すべき理由
Oracle Databaseエラーメッセージ（ORA-“エラー番号”）	データベースで発生したエラーはORA-00600のように接頭辞「ORA-」と5桁の数字で表される。エラーごとに必要な対処が異なるので、以下いずれかで監視するようにする （1）「ORA-」から始まる全てのエラー番号を監視の対象としておき、運用の中で検知が不要なエラーがある場合には除外していく （2）「V$DIAG_CRITICAL_ERROR」（11g R1以降）で確認できるクリティカルな「ORA-“エラー番号”」と「ORA-00600」「ORA-00700」のみを対象とし、必要に応じて追加していく
cannot allocate new log	オンラインREDOログのアーカイブ処理が完了しておらず、ログスイッチができない（待機している）場合に発生するメッセージのこと。主に次のような理由で発生する。運用中に突然頻発するようになった場合には、「処理パフォーマンスに影響が出ている可能性がある」ので注意する ・アーカイブ先のディスクに空き容量がない　→初期化パラメーターLOG_ARCHIVE_DESTで指定したディスクの空き領域を確認する ・I/O速度などに問題があり、アーカイブ処理のパフォーマンスが悪い　→OS、ハードウェアに問題がないかを確認する ・更新が多過ぎるためにログスイッチの頻度が高くなり、アーカイブ処理が追い付いていない　→意図しない高負荷処理の実行がないかどうかを確認する なお「夜間バッチの実行」など、あらかじめ更新処理が多くなる時間帯が分かっている場合には、特定の時間帯は監視対象外とすることも検討する。ただし、このメッセージの出力は「パフォーマンスダウンの発生とイコールではない」ので、監視の優先度としては低めでよい。実際にパフォーマンスダウン（処理の待機）が発生しているかどうかは、該当時間帯のAWR／ASHやStatspackなどから処理の待機傾向を確認する必要がある
Checkpoint not complete	LGWRプロセスがログスイッチを行おうとした際に前回のチェックポイントが完了しておらず、その完了を待っている状態が発生していることを示す。ログスイッチが待機している状況では、以下のパフォーマンス問題が発生している可能性がある ・新規接続の待機 ・処理が待機イベント「log file switch (checkpoint incomplete) 」で待機 ただし、このメッセージの出力は「パフォーマンスダウンの発生とイコールではない」ので、監視の優先度としては低めでよい。実際にパフォーマンスダウン（処理の待機）が発生しているかどうかは、該当時間帯のAWR/ASHやStatspackなどから処理の待機傾向を確認する必要がある
Instance shutdown cancelled	データベースインスタンスのシャットダウンが行われたが、アクティブセッションが残留していたなどの理由で長時間シャットダウンが行えずにキャンセルされた場合に出力される。このメッセージが出力されてシャットダウンがキャンセルされたときに、データベースインスタンスが「shutdown実行中のステータスのまま」となる この対処は、システム／データベース管理者が「アクティブセッションをKILLした上で再度停止する」「shutdown abortで停止する」などで行う
Instance terminated	データベースインスタンスの稼働に必須のプロセスがエラーによって停止した場合には、データベースが異常終了してしまう。エラーによってデータベースインスタンスの停止にまで至った場合に、次のようなメッセージが出力される 　PMON: terminating instance due to error 472 　Instance terminated by PMON, pid = このように異常終了した場合には、単純に再起動するだけでは直らず、再度異常終了してしまう可能性があるので、正しく原因を確かめ、対処を行った上で再起動を試行することが必要となる