Oracle Databaseが起動できない時の確認ポイント

「データベースが起動できない」というトラブルが発生した際には、データベース起動時に内部的に行われるステップがどこまで進んでいるのかを正確に把握することが解決の時間短縮につながります。本稿では、データベースが起動できなくなってしまった際に確認すべきポイントを、実際のサポート事例と合わせてご紹介します。

最初に、実際にサポートセンターにお問い合わせいただいた「データベースが起動できない」トラブルの事例をご紹介します。

「データベースが起動できない」というお問い合わせの原因を分類分けしたのが図1です。最も多いのは、電源障害によるサーバ停止やディスク障害などによってデータファイルが破損しているケースです。

ここで着目していただきたいのは、人的ミスである設定ミスや操作ミス、リソース不足の3つが50%を占めている点です。つまり、事前の手順確認やリソースの使用状況を確認することでトラブルは半減できるということです。

図2はトラブルを最終的にどのように復旧したのか、原因ごとに表しています。人的なミスの中でも、誤って構成ファイルなどを削除したという操作ミスの場合には、バックアップからの復旧やデータベースの再作成といった大掛かりな復旧作業が必要になるケースがあります。

データベースに対して何かしらの変更を行う際には、必ず影響範囲を確認した上で慎重に行い、万が一の場合に備えてバックアップを取得しておくことが重要です。

また、データベースを構成する要素や、どのようなステップで起動するのかを知っておくことで、起動ができないトラブルが発生した時にも迅速に対応を行うことができます。

データベースを構成する基本的な要素をピックアップしたものが図3です。データベースを起動するにはこれらのコンポーネントが正常に利用可能な状態である必要があります。

つまり、データベースの起動ができない場合にはこのコンポーネントの内のどれか1つ、あるいは複数が利用できない状態にあります。例えば、データベースを構成するファイルが存在しない、メモリが不足していてプロセスの起動ができない、などです。

データベースの起動ができないというのは非常にクリティカルなトラブルです。トラブルが発生した際には一刻も早い復旧が必要であり、とりあえずRECOVER DATABASEコマンドを実行したり、バックアップから一部の構成ファイルを戻した後で、サポートセンターに「起動はできたが原因を追求したい」や「それでも復旧できない」といったお問い合わせをいただくことも少なくありません。

しかし、復旧のために行った作業内容（コマンドや実行時間）が正確に残されていないために、原因追求に至らないケースや、かえって状況が悪化してしまい、最終的にフルバックアップをリストア／リカバリするなどの大掛かりな復旧作業が必要になってしまうケースもあります。

データベースが起動するにはいくつかのステップを経由するため、起動できないというのはこの各ステップのどこかに問題があります。各ステップで実行される内部動作を把握することで、データベースが起動できない状況でも焦ることなく、対応が必要な範囲を特定し、適切な対処を行うことが可能になります。

次の項目からは、データベース・アーキテクチャのおさらいも兼ねて、データベースが起動できないトラブルが発生した際に確認すべきポイントを説明します。

まずはデータベース起動時の内部的なステップと、各ステップで発生する可能性がある問題を説明します。

データベースの起動が完了するまでには「START」、「MOUNT」、「OPEN」の3つのステップが存在します（図4）。SQL*Plusで接続し、STARTUPコマンドを実行すると、各ステップが完了した時点で標準出力に「ORACLE Instance started」、「Database mounted」、「Database opend」が表示されます。STARTUPに「NOMOUNT」や「MOUNT」といった引数を付けることで、どのステップで起動を止めるか制御することができます。

STARTUPコマンドでデータベースの起動を行っている場合には、どのステップまで進んでいるか、この出力から判断することができます。次に、各ステップで行われる内容と、発生する主な問題を見ていきます。具体的に確認するログファイルや調査のポイントはさらに後の章で説明します。

まず、「START」のステップでは初期化パラメータファイルの読み込み、インスタンスの起動に必須となるバックグラウンドプロセスの起動、SGAの割り当てが行われます（図5）。

STARTUPコマンドを実行してから「ORACLE Instance started」の画面出力の前にエラーなどが発生して起動ができないケースとしては、例にあるように初期化パラメータファイルに設定されているパラメータが不適切なケースや、OS側のメモリが不足しており、SGAや起動しようとしたプロセスにメモリが割り当てられないケースが存在します。

次に「MOUNT」のステップでは制御ファイルを読み込みます。制御ファイルの内容からデータファイルやREDOログファイルの場所を確認し、データベースとの対応付けを行います（図6）。

ここで行うのはパスの確認と対応付けであり、データファイルやオンラインREDOログファイルが存在しているかどうかのチェックやアクセスは行いません。そのため、起動時に「ORACLE Instance started」が確認でき、「Database mounted」の出力までに問題が発生するケースでは制御ファイルが存在していない、破損している、あるいはウィルス検知のソフトなど別のプロセスでロックされているケースがあります。

MOUNTが正常に完了すると、「OPEN」のステップに進みます。このステップではMOUNTの際に制御ファイルから読み込んだパスを使って、データファイルやREDOログファイルをオープンします（図7）。

「Database mounted」から「Database opened」の間で問題が発生し、起動に失敗するケースとしては、オープンしようとしたファイルに問題がありアクセスできないケースや、データファイル間のSCN（System Change Number）が揃っておらずリカバリを求められるケースがあります。

図8は起動時の各ステップで発生する主なエラーを一覧にしたものです。各ステップで発生するエラーの番号はORA-0044Xや、ORA-0020Xのように問題発生箇所ごとにグルーピングされています。

各エラーの概要や対処策はエラー・メッセージマニュアルから確認できます。その内容から対応方針を検討することも可能です。

サポートセンターにお問い合わせいただく際にも「ORA-XXXXXが発生してデータベースが起動できない」のように、エラー番号を併せてお伝えいただくことで、どの部分で問題が発生しているかをサポートエンジニアが把握できるため、調査に必要な情報や対処策の案内をより円滑に行えます。

次の章では、どのように問題発生箇所やエラー内容を確認するのか解説します。

起動ができないというトラブルが発生した際に、まずはSQL*PlusでのSTARTUPコマンドの標準出力を確認し、エラー内容と「Database mounted」などの出力からどのステップまで起動が進んでいるかを確認します。

問題のステップが判明したら、アラートログを確認します。アラートログにはデータベース・インスタンスの様々な情報が出力されており、起動時の各ステップにおける情報も出力されています。どのような情報がアラートログに出力されるのかを把握しておくことで、より効率的な調査や対応を行うことができます。

データベース起動時のアラートログに出力される内容を表しているのが図9です。バージョンを追うごとに出力される情報は強化されており、2016年2月現在で最新のリリース12.1.0.2では、適用されている個別パッチの情報もアラートログに出力されるようになっています。アラートログファイル1つで広範囲の情報が得られるため、トラブル対応の工数削減に役立っています。

SQL*PlusのSTARTUPコマンドの結果にはサーバプロセスで発生したエラーが返ります。一方、バックグラウンド・プロセスで発生したエラーはアラートログファイルに出力されます。そのため、標準出力とアラートログで確認できるエラーが異なることがあります。

よって、データベースの起動に失敗した際は、画面上に出力される標準出力だけでなく、アラートログファイルの出力も必ずセットで確認します。

上述のように様々な情報がアラートログには出力されますが、特に確認が必要な3つのポイントについて解説をします。

データベースの起動を行うと、アラートログファイルには図10のようにタイムスタンプとともに「Starting ORACLE instance（起動モード）」が出力されます。これがデータベース起動に関する出力の起点です。

各ステップの開始と終了のタイミングでもそれぞれタイムスタンプとともに出力がされるため、標準出力から問題発生ステップが確認できている場合には、そのステップでアラートログファイルにどのような出力があるのか確認します。

「START」のステップでは初期化パラメータファイルの読み込みと、インスタンス起動に必須なバックグラウンドプロセスの起動、そしてSGAの割り当てが行われます。

SQL*PlusからSTARTUPを行った際に「ORACLE Instance started」が出力されずに失敗した場合には、アラートログ内の「Starting ORACLE instance(normal)」から「ALTER DATABASE MOUNT」までの出力に着目します。

「MOUNT」のステップでは制御ファイルの読み込みを行います。標準出力に「Database mounted」の出力がなく失敗した場合には「ALTER DATABASE MOUNT」以降で制御ファイルの読み込みに関するエラーが発生しているはずです。ORA-XXXXXといったエラーコードや警告、メッセージの出力がないか確認します（図11）。

「OPEN」のステップではデータファイル／REDOログファイルのオープンとSCNのチェックを行います。標準出力の結果からMOUNTまでは正常に行えており、「Database opened」の出力が確認できない場合には「ALTER DATABASE OPEN」以降の出力を確認します（図12）。

データベースの起動を試みるということは、その時点ではデータベースは停止しています。起動ができない原因には、直前のデータベースの停止が正常に行われておらずデータが破損してしまったことに起因するケースもあります。

データベースが正常に停止している場合のアラートログファイルには、図13のように「Shutting down instance（停止モード）」の出力に続いて、起動とは逆の順序で「DATABASE CLOSE」「DATABASE DISMOUNT」「Instance shutdown」のステップで停止が行われたことがタイムスタンプと共に出力されます。

起動ができなくなる直前のデータベース停止時に「Instance shutdown complete」の出力がない場合には、停止が正常に行われていないことで制御ファイルやデータファイルの破損、SCNの不一致などが発生し、起動ができない可能性があります。特に「MOUNT」や「OPEN」のステップで起動に失敗するようなケースでは、前回の停止が正常に行われていたかも重要な確認のポイントです。

問い合わせ事例中には、初期化パラメータに不適切な値を設定してしまったためにデータベースの起動ができなくなっているケースも少なくありません。先述のとおり、インスタンス起動時のアラートログファイルには初期化パラメータファイルから読み込んだデフォルト値以外の初期化パラメータが出力されます（図14）。

過去に正常に起動ができた際のアラートログファイル内の初期化パラメータと、現在のパラメータを比較し、追加／削除／変更されたパラメータがないかを確認します。該当するパラメータがある場合には、その設定値の妥当性を確認します。

実際の問い合わせ事例ではMEMORY_TARGETやSGA_TARGETなどのメモリサイズに関する初期化パラメータが変更された後から起動ができなくなったというケースが数多くあります。

今まで解説した内容を踏まえ、次の章では設定ミス、操作ミス、リソース不足それぞれに起因してデータベースが起動できなかった3つの事例をご紹介します。

この事例では「データベースがより多くのメモリを使えるようにMEMORY_TARGETのパラメータを変更したところ、データベースが起動できなくなった」とお問い合わせをいただきました。サポートセンターからは起動時の標準出力とアラートログの提供を依頼したところ、起動時の標準出力からORA-00845のエラーが確認できました（図15）。

STARTUPコマンドの直後にORA-00845エラーが発生しており「ORACLE Instance started」の出力はありません。よって、初期化パラメータファイルの読み込み、バックグラウンド・プロセスの起動、SGAの割り当てのいずれかでエラーがあることが推測できます。

ORA-00845エラー発生時のアラートログファイルの出力からは、/dev/shmの増加が必要な旨の警告が確認できます（図16）。

Linux環境での自動メモリ管理では、共有メモリファイルシステム（/dev/shm）が用いられるため、MEMORY_MAX_TARGETおよびMEMORY_TARGETの値は共有メモリファイルシステムの割当てよりも小さい値にする必要があります。この事例では/dev/shmを増加させずにMEMORY_TARGETのみを増加させてしまったため、制限を超えてしまいORA-00845エラーが発生していました。

この制限についてはインストレーション・ガイドにも記載されていますが、インストール時だけでなく、運用中でもMEMORY_TARGETパラメータの変更を行う際には注意が必要です。

MEMORY_TARGET自体は動的なパラメータですが、MEMORY_TARGETの上限を決めるMEMORY_MAX_TARGETは静的なパラメータです。

MEMORY_MAX_TARGETを明示的に設定していない場合、自動的にMEMORY_TARGETと同じ値が設定されます。その状態でMEMORY_TARGETを増加させるにはMEMORY_MAX_TARGETの増加も必要なため、インスタンスの再起動が必要です。

この事例では、ORA-00845エラーが発生したために復旧を優先して一度MEMORY_TARGETを変更前の値に戻し、サポートセンターにお問い合わせをいただいていました。そのため、本来行いたかったMEMORY_TARGET変更作業は延期されていました。

データベースを管理する上で何らかのパラメータの変更を行う際には、他に影響がないか、併せて変更する必要があるパラメータが存在しないかを事前に確認しておくことをお奨めします。

次に紹介するのは、データベースを起動しようとした際にORA-03113が発生したというお問い合わせです。

起動時の標準出力を確認すると「Database mounted」の出力があるため制御ファイルのマウントまでは成功していて、データファイル／REDOログファイルのオープン、あるいはSCNのチェックで失敗していると推測できます（図17）。

ただ、ORA-03113は一般的にはクライアントとサーバ間の通信が切れてしまった際に、クライアント側に返るエラーであり、通信が切れた原因についてはアラートログファイルを確認する必要があります。

アラートログファイルの出力からは、ORA-00313とエラーが発生していることが確認できます。ORA-00313のエラーメッセージからREDOログファイルのオープンに失敗している状況であり、更にOSエラーとして「Linux-x86_64 Error： 2: No such file or directory」が出力されていました（図18）。

対象のREDOログファイルの有無を確認したところ、「redo03.log」はOSレベルで削除されていました。オンラインREDOログファイルを操作ミスで削除することはあり得ないと思われる方もいらっしゃるかも知れませんが、同様のお問い合わせは年に数件いただきます。

その多くは不特定多数の利用者がいる開発環境で発生しています。普段メンテナンスが行われていないためにディスク使用量が増加し、空き領域確保のために".log"の拡張子のファイルをまとめて削除した際にオンラインREDOログ（ファイル名：REDO01.logなど）も削除されてしまうという流れです。

稼働中のデータベースで現在使用中のオンラインREDOログファイルが削除された場合には、バックアップからの復旧が必要です。しかし、開発環境ではバックアップを取得していないケースも多く、データベースの再作成を行い、本番環境からサンプルデータのEXPORT／IMPORTといった大掛かりな復旧作業が必要になることもあります。

オンラインREDOログファイルのデフォルトの拡張子が".log"というのも要因の1つではありますが、開発環境の場合でもファイルの移動や削除を行う際には十分な注意が必要です。

このケースでも同様に、「Database mounted」の後にORA-03113が発生しています（図19）。

アラートログファイルを確認すると、「OPEN」のステップにおいてアーカイブログファイルの作成がORA-16038エラーで失敗、原因は19809エラーであることが出力されており、最終的にインスタンスが停止させられています（図20）。

ORA-19809エラーは高速リカバリ領域の空き容量が不足していることを表すエラーです。Oracle Database 10g以降はアーカイブログファイルやRMANで取得したバックアップのデフォルトの出力先は高速リカバリ領域に設定されています。高速リカバリ領域の上限はDB_RECOVERY_FILE_DEST_SIZEによって決められているため、不要なアーカイブログファイルの削除やバックアップの世代管理を行わなければ、空き領域が不足してアーカイブログファイルの作成が行えなくなります。

データベース稼働中にアーカイブログファイルが作成できなくなった場合、REDOを生成する処理（DML/DDL）は待機状態となるため、ほとんどのSQLが実行できず、ユーザから見るとハングのような状態となります。この状態でインスタンスの再起動を行うと、本事例のように「OPEN」のステップでORA-19809エラーが発生し、起動に失敗します。

高速リカバリ領域の空き状況は、データベースがMOUNTもしくはOPENの状態でV$RECOVERY_FILE_DESTビューから確認可能です。また、ORA-19809が発生する前にはアラートログファイルに「ORA-19815: 警告: db_recovery_file_dest_size(nバイト)は n%バイトが使用され、残りnバイトが使用可能です。」のメッセージも出力され、空き領域が少なくなっていることが警告されます（図21）。

ORA-19809エラーの対処としてはRMANを使用した不要なアーカイブログファイルの削除、あるいは初期化パラメータDB_RECOVERY_FILE_DEST_SIZEの増加による高速リカバリ領域の拡張です。

長期間運用しているとデータベースに格納されるオブジェクトや処理の数も増え、アーカイブログファイルの出力量も運用開始時と大きく変わっている可能性もあります。意図しない障害を発生させないよう平時からディスク使用量などのリソースやアラートログファイル内の警告を監視しておくことが重要です。

また、事例２、事例３ではどちらも標準出力にはORA-03113エラーが返されていますが、アラートログファイルの出力や原因は全く異なります。正確な状況把握には、標準出力だけでなく、アラートログファイルも確認が必要です。

はじめにお伝えしたとおり、データベースが起動ができない場合は起動のステップのどこかで問題が発生しています。そのため、起動の各ステップと処理内容を把握することで、何故起動できないのかを理解した上での適切な対応が可能になります。

データベースの起動ができない場合には、闇雲にリカバリや再起動を行うのではなく、データベースの起動時のどのステップで問題が発生しているか、どのような問題（エラー）が発生しているかを正確に把握することが、解決までの時間短縮につながります。

昨年寄稿させていただいた接続障害も同様ですが、基本的なアーキテクチャを把握するだけでもトラブルに対する心構えと、初動のスピードが大きく変わります。トラブルは発生しないことが一番ですが、本稿がアーキテクチャおさらいの機会となり、起動ができないトラブルが発生した際の解決の早期化に少しでも繋がれば幸いです。

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。