Oracleのファイル障害とリカバリの方法

Oracleのファイル障害とリカバリについて。

今回は、Oracleのファイル障害とリカバリについて紹介します！

Oracleのファイル障害とリカバリの方法

Oracleのファイル障害とリカバリの流れは初心者には少し難しいかもしれませんが、わかってしまえば難しい事ではありません。Oracleでデータ障害が発生した際のリカバリの流れをおさえましょう！

ファイル障害が発生したら？

例えば、更新とコミットを10回繰り返したとします。Oracleはコミットしてもメモリへ展開するだけでなので、すぐにデータファイル(.dbf)に書き込みません。

よってデータファイル(.dbf)に10回分の「更新データ」はありません。REDOログファイル（.log）に「更新履歴」だけがある状態です。「更新履歴」はあるが、「更新データ」はない状態。

さて、ここで「データファイル」に何かしらの問題が発生し使用できなくなってしまう「ファイル障害」が発生し、チェックポイントが発生しないまま落ちてしまったとしたらどうなるでしょうか？

「データファイル」には更新データがありません。この状態で起動したら先ほどの10回分の更新はなかったことになり消えてしまうのでしょうか？

ファイル障害後にOracleは起動できない

では、この状態でOracleを起動してみます。どうなると思いますか？

では、どのように整合性をチェックしているか？Oracleは更新した回数を番号で管理し、この番号で整合性を確認しています。この番号のことをSCN(system change number)と呼びます。

制御ファイルのSCNでチェックしている

正常時はこのSCNがデータファイルに書き込まれています。そしてSCNはデータファイル以外にも書き込まれています。それが制御ファイル(.ctl)です。制御ファイルとは文字通りOracleを制御するためのファイルで、更新回数であるSCNを管理しています。

今回のケースでみていきます。更新前のSCNが「100」だったとしたら、10回更新したので「110」となります。正常時はこの「110」がデータファイルと制御ファイルに書き込まれます。今回はデータファイルに障害が発生したのでSCNが書き込まれず「100」のまま、制御ファイルだけが「110」となります。

更新前

更新後

「100」と「110」・・・SCNが違う！不整合だ！ということになりOracleは起動できません。大事なことなので、もう一度流れを追ってみます。

Oracleは起動時に制御ファイルを読み込み、SCNが「110」と認識します。次に、データファイルのSCNをチェックし、同じ「110」であれば起動します。今回はデータファイルが「100」なので起動できないという流れです。これでデータファイル障害時のOracleのデータ整合性チェックの仕組みが理解できたかと思います。

リストアとリカバリで復旧する

それでは次へ進めます。この起動できない状態・・どうしたらOracleが起動できるようになるのでしょうか？ざっくりいうと、「リストアしてマウント状態でリカバリする」と起動できるようになります。

意味わかりますか？わからなくても大丈夫です。順番にひとつずついきますよ。

1.データベースをシャットダウン

まず、データベースをシャットダウンします。

shutdown immediate;

2.リストアする

データ障害によりデータファイルが壊れているので、前日のデータファイル(***.dbf)のバックアップで上書きコピーします。このように、正常なファイルで上書きすることを「リストア」といいます。「リストア」はコピーのことです。ちなみにバックアップがないのはご法度ですよ。必ず物理ファイルのバックアップは毎日とるようにしてください。ここではデータファイルのバックアップのSCNが90だったとして進めます。

3.マウントで起動する

次に、マウント状態で起動します。

startup mount;

このマウント状態は制御ファイルを読み込むので、OracleはSCNが「110」と認識します。

4.リカバリする

次にOPENしたら？もちろん前日のバックアップデータファイルのSCN「90」と制御ファイルのSCN「110」が一致しないので起動できません。起動できないのでリカバリをします。

recovery automatic database;

このコマンドでOracleが自動的にバックアップのデータファイルへSCN「90」以降の更新分を適用し、SCNを「110」へ更新してくれます。もう少し踏み込むと、更新情報はREDOログファイル、もしくはアーカイブログファイルにあるので、この更新情報を使ってデータファイルへ適用していきます。もちろん、このコマンドでOracleが勝手にやってくれます。これによりデータファイルのSCNが「90」から「110」へ変更されます。このリカバリ処理で制御ファイルとデータファイルのSCNが「110」となり整合性がとれました。

5.起動する

これでOracleが起動できるようになりました。

alter database open;

以上で完了です。

Oracleにデータ障害が発生した場合のリカバリの流れを説明しました。更新回数であるSCNで障害を検知し、REDOログファイルからデータをリカバリするという流れは抑えておきたいポイントです。

ちなみに「OracleのREDOログファイルの役割」ではOracleはクラッシュリカバリで自動起動でき、ここではOracleが起動できませんでした。なぜかわかりますか？

ここまで理解された方ならおわかりかと思います。そう、前者では「更新データ」は「データファイル」にありませんが「制御ファイル」のSCNも更新されていないので「データファイル」と「制御ファイル」のSCNが一致しているため起動時できるのです。ここではSCNが一致していないため起動きなかったのです。

SCNがキーポイントになるので、これさえ理解していまえば決して難しい内容ではありません。

以上、Oracleのファイル障害とリカバリの方法でした。