Oracle Databaseの障害対策を調べていると、ARCHIVELOG（アーカイブログ）モードなら完全リカバリができるのかという疑問が出てくることがあります。結論からいうと、ARCHIVELOGモードは完全リカバリ（Complete Recovery）を実現するうえで重要な仕組みであり、必要なバックアップとREDO情報がそろっていれば、障害発生前の最新状態までデータベースを復旧できる可能性があります。
ただし、ARCHIVELOGモードに設定しているだけで、どのような障害からでも必ず完全リカバリできるわけではありません。完全リカバリにはデータファイルのバックアップだけでなく、復旧に必要なアーカイブREDOログやオンラインREDOログなどが欠けずに残っていることが重要です。本記事ではOracle Databaseの公式ドキュメントを基に、ARCHIVELOGモードと完全リカバリの関係を整理します。
Oracle DatabaseのARCHIVELOGモードとは
Oracle Databaseでは、REDOログにデータベースへ加えられた変更内容が記録されます。オンラインREDOログは循環して再利用されますが、ARCHIVELOGモードでは、再利用される前のREDOログをアーカイブREDOログとして保存できます。
つまり、過去の変更履歴をアーカイブREDOログとして残しておくことで、バックアップ取得後に行われた変更を復旧時に再適用できるようになります。Oracleの公式ドキュメントでも、REDOログのアーカイブはデータベースがARCHIVELOGモードで動作している場合に可能と説明されています。
ARCHIVELOGの基本的な仕組みについては、Oracle公式ドキュメントの[参照] Managing Archived Redo Log Filesでも確認できます。
ARCHIVELOGモードなら完全リカバリを行える
Oracle Databaseにおける完全リカバリ（Complete Recovery）とは、バックアップからデータファイルを復元した後、必要なREDO情報を適用し、可能な限り最新の状態までデータベースを戻す処理です。Oracleの現行ドキュメントでは、完全リカバリを「コミット済みトランザクションを失うことなく、データベースを最新時点までリカバリすること」と説明しています。
たとえば日曜日にデータベースのバックアップを取得し、水曜日にデータファイルが破損したとします。日曜日のバックアップをRESTOREしただけでは、月曜日から水曜日までの変更は反映されません。しかし、必要なアーカイブREDOログなどが残っていれば、それらの変更を適用してデータファイルをロールフォワードできます。
したがって、「ARCHIVELOGモードでは完全リカバリが可能か」という点では、必要なバックアップとREDOがすべて利用可能であることを前提として可能と考えるのが正確です。Oracle公式の[参照] Performing Complete Database Recoveryでも、RMANを使用した完全リカバリの条件と手順が説明されています。
完全リカバリに必要な条件
ARCHIVELOGモードであっても、アーカイブREDOログの一部が失われている場合などは、目的とする最新時点まで完全リカバリできないことがあります。そのため、ARCHIVELOGモード＝自動的に完全リカバリが保証されると理解しないことが重要です。
代表的には、次のような要素を適切に確保しておく必要があります。
- 復元対象となるデータファイルのバックアップ
- バックアップ取得後の変更を適用するために必要なアーカイブREDOログ
- 必要に応じてオンラインREDOログ
- リカバリに必要な制御ファイルなどのデータベース構成情報
- RMANを使用する場合は、必要なバックアップやログへアクセスできる環境
Oracle公式ドキュメントでは、完全リカバリの前提として、データファイルのバックアップから復旧するために必要となるアーカイブREDOログや増分バックアップの完全なセットが存在することなどが示されています。
RMANではRESTOREとRECOVERを使い分ける
Oracle Databaseのバックアップ・リカバリでは、Recovery Manager（RMAN）が広く利用されます。ここで理解しておきたいのがRESTOREとRECOVERは同じ処理ではないという点です。
RESTOREはバックアップからデータファイルなどを復元する処理です。一方、RECOVERでは、復元したデータファイルにREDOや必要に応じて増分バックアップを適用し、データを進めていきます。
典型的な全データベースの復旧では、状況に応じた準備やMOUNTなどを行ったうえで、概念的には次のようなRMANコマンドを利用します。
RESTORE DATABASE;
RECOVER DATABASE;実際の障害対応では、失われたファイル、制御ファイルの状態、REDOログの状態、Oracle Databaseのバージョンなどによって手順が変わるため、本番環境では個別の障害状況に合わせた手順確認が必要です。RMANのRECOVERコマンドについてはOracle公式の[参照] RECOVERも参考になります。
完全リカバリと不完全リカバリの違い
Oracle Databaseのリカバリを理解する際には、完全リカバリと不完全リカバリ（Point-in-Time Recoveryなど）を区別することも重要です。
| 種類 | 主な目的 |
|---|---|
| 完全リカバリ | 利用可能な必要REDOを適用し、最新状態まで復旧する |
| Point-in-Time Recovery | 指定した時刻やSCNなど、過去の特定時点まで復旧する |
たとえばストレージ障害によってデータファイルだけが破損し、必要なREDOがすべて残っているケースでは、完全リカバリが適しています。一方、誤操作で重要なデータを削除し、その削除操作より前の状態へデータベースを戻したい場合には、Point-in-Time Recoveryなどが検討対象になります。
RMANのRECOVERはデフォルトでは完全リカバリを行います。一方、過去の特定時点まで戻す場合にはSET UNTILなどを使用する方法があります。両者は目的が異なるため、単に「復元したい」というだけでなく、どの時点まで戻す必要があるのかを最初に明確にすることが大切です。
ARCHIVELOGモードでもログ管理が重要
ARCHIVELOGモードを利用していても、生成されたアーカイブREDOログを保存せず削除してしまい、そのログが復旧に必要だった場合には完全リカバリが困難になります。そのため、バックアップ戦略ではデータファイルだけでなくアーカイブREDOログも対象にする必要があります。
RMANでは、たとえばBACKUP DATABASE PLUS ARCHIVELOG;を利用してデータベースとアーカイブREDOログをバックアップする方法があります。Oracle公式ドキュメントでも、アーカイブREDOログはメディアリカバリを成功させるうえで重要であり、定期的なバックアップが推奨されています。
さらに、本番環境ではバックアップを取得しただけで安心せず、復元可能性の確認やリカバリ手順のテストも重要です。障害発生後に初めて手順を確認するのではなく、RPO（目標復旧時点）やRTO（目標復旧時間）に合わせてバックアップ・リカバリ設計を行うことが望まれます。
まとめ：ARCHIVELOGモードは完全リカバリを可能にする重要な仕組み
Oracle Databaseでは、ARCHIVELOGモードでアーカイブREDOログを保存し、必要なバックアップとREDO情報がそろっていれば、完全リカバリを実行できます。バックアップをRESTOREした後、REDOなどを適用するRECOVER処理によって最新状態まで復旧するのが基本的な考え方です。
ただし、ARCHIVELOGモードにしていること自体が完全リカバリの保証になるわけではありません。必要なログの欠損、バックアップの破損、オンラインREDOログや制御ファイルを含む障害状況によって、実行できる復旧方法は変わります。
実運用では、ARCHIVELOGモードの設定に加えて、RMANによるデータベースとアーカイブREDOログの定期バックアップ、バックアップの検証、復旧テストまでを一つのリカバリ戦略として設計することが重要です。
コメント