はじめに
前回のあらすじ
Part1ではオラクルDBの核となる構成要素のOracleインスタンスとデータベースについて整理し、それらの調子を見るためのデータディクショナリ・動的パフォーマンスビューについて解説しました。今回からは、さらにDBの挙動を細分化して見ることで、具体的なDB管理の問題に対応できるよう学んでいきます！
以下がPart1で学んだ内容を整理した図です。
今回扱うこと
DBを扱うには、まずそのDB自体を起動することができなければいけません。そのため今回は、DBの起動時の挙動を具体的に見ていき、その時発生しうる問題にどう対処するかを学びます。
まずデータベースはどのように起動するのか？
まず、DBの起動についての流れを見ていきますが、感覚で理解するために、前回も使った工場と倉庫の例を用いて解説します。データベースの起動を工場の始業に例えて説明していきますね！
工場の始業
1. 工場の準備
まず、工場では業務開始前に始業準備を行うことになるでしょう。例えば、電気がちゃんとつくかの確認、作業台の準備、点呼などです。
2. 倉庫の確認
次に、倉庫との協力関係を結び、在庫の確認を行います。ここでは確認を行うまでにとどまるので、在庫の中身を取り出して実際の作業を行うまでには至りません。
3. 始業
倉庫の確認まで正常にできたら始業します。ここからはクライアントから渡される作業内容をもとに、倉庫の在庫が取り出されて実際の作業が行われます。
上記のようなステップを経て工場で業務を行うことができるようになりますが、これと同じ流れがDBの起動処理でも行われています。
DBの起動
1. oracleインスタンスの起動（NOMOUNT）
工場の準備に対応した動作を行います。先に出した始業準備の具体例は概ね以下のように対応しています。
-
電気がちゃんとつくか確認→初期化パラメータファイルの読み込み
工場が正常に稼動できるためのインフラを支えているのが電気であるように、初期化パラメータファイルが正常なインスタンス起動を支えています。初期化パラメータファイルから初期化パラメータが読み込まれ、必要なインフラ部分が正常に設定されることで、その後の準備が進むというようなイメージです。 -
作業台の準備→SGAの確保
Part1でも述べたようにSGAは作業台の役割をしています。インスタンス起動時にはこの作業台の準備も行います。 -
点呼→バックグラウンドプロセスの生成
点呼というより作業者が出勤してくる感じのほうがイメージとしては近いかもしれません。作業者が出勤するような感じでバックグラウンドプロセスが生成されます。
2. データベースのマウント（MOUND）
始業前に、oracleインスタンスはデータベースのマウントを行います。Part1で確認したように、oracleインスタンスとデータベースは独立した要素なので、協力関係を結ぶことが必要なんでしたね！
制御ファイルを使って、在庫確認のようにデータファイルやREDOログファイルがどこにあるかを確認したら、データベースがマウントされます。ここまでで始業準備が整います。
3. データベースのオープン（OPEN）
始業準備が整ったら、実際に業務を開始します。データファイルやREDOログファイルがオープンされ、一般ユーザがアクセス可能となります。この流れを経ることで、クライアントからのSQLタスクを実行できるようになります。
これが、DB起動の流れです。ここまでの流れを以下の図に示します。
DB起動で障害が起こったら
注意：ここの内容は自分が実際にDBシステムをぶっ壊したときに経験したことを含みます！真似しないほうがいいです！
たとえば、データベースの稼働中に重大な問題が発生し、制御ファイルが破損した状態でDBを停止させてしまったようなシナリオを考えます。この場合DBを再起動する際にどのような影響を及ぼすでしょうか？
制御ファイルの役割はデータファイル・REDOログファイルの存在を確認することでした。そのため、制御ファイルが存在しない状況では、正常にDBをマウントすることができません。DBサーバはデータベースがマウントできない旨のエラーを表示させることになります。
ORA-01113: ファイル1はメディア・リカバリが必要です
ORA-01110: データ・ファイル1: 'C:----.DBF'
するとDB管理者はエラーを見て、DBが正常にマウントされていないことを知ります。つまり問題がデータベースのデータファイルやREDOファイル、制御ファイルにあるだろうと推測できるわけです。となると、管理者は正常に起動したoracleインスタンスを用いて（NOMOUNT状態で）データベースの障害復旧を行うことになります。この時、障害原因のわからない管理者は初期化パラメータや動的パフォーマンスビューを参照しながら、原因が制御ファイルの破損であることを突き止めます。そして管理用のSQLっぽいコマンドを発行することで復旧を進めていきます。もしも制御ファイルが原因であることを突き止め、バックアップからリカバリもしくは再生成することができれば、その設定をデータベースに適応させることで再MOUNTが可能となります。
この例ように、データベースの障害が発生した際は、その障害発生箇所に応じて、NOMOUNTやMOUNT状態のオラクルDBを操作することになります。これによって、Orcleインスタンスの障害、データベースの障害、ファイルOPEN時に起きた問題へ柔軟に対応できるようになるわけです。
上の図で例えるなら、業務停止の原因が工場なのか倉庫なのか、始業時の在庫展開なのかを(DBの起動状態から)まず特定し、(動的パフォーマンスビューで)より詳しく調査しながら業務復旧を進めるようなイメージだと思います。
まとめ
・DBの起動はNOMOUNT（工場の準備）→MOUNT（倉庫の確認）→OPEN（始業）の順番である
・DBが正常に起動できなくなったら、NOMOUNT状態やMOUNT状態のDBを駆使して、復旧作業を行う
・DB起動時の状態をNOMOUNT・MOUNT・OPENと別れていることによって、どの構成要素までは正常に動作するかが明確になり、保守性が向上する
ここまでで、DB起動がわかったので、つぎはクライアントからのタスクを受け付ける「セッション」と「ネットワーク」についてかなぁ。