アーカイブログモードの重要性とアーカイブログモード運用のすすめ

01.はじめに

本番環境では、アーカイブログモードでの運用が原則的に必須です。非アーカイブログモードでの運用はお勧めできません。
SQL*Plusからarchive log listコマンドを実行して、「データベースログモード」欄に「非アーカイブ・モード」と表示された場合は非アーカイブログモードです。

SQL> archive log list
データベース・ログ・モード     非アーカイブ・モード←★
自動アーカイブ                 使用禁止
アーカイブ先                    USE_DB_RECOVERY_FILE_DEST
最も古いオンライン・ログ順序   9
現行のログ順序               11

以下の手順を実行して、非アーカイブログモードからアーカイブログモードに変更することを検討してください。

SQL> shutdown immediate
SQL> startup mount
SQL> ALTER DATABASE ARCHIVELOG;

02.アーカイブログモードとは

アーカイブログモードとは、障害発生直前までの復旧や、運用中のバックアップ取得を可能にするためのデータベースの運用モードです。本番環境では、たいていの場合「障害発生直前までの復旧」が必須要件であるため、原則的にアーカイブログモードでの運用が必須です。非アーカイブログモードでは、バックアップ取得時点にしか復旧できません。バックアップ取得後に加えられた変更は失われるため、これらの変更の復旧をあきらめるか、アプリケーションのログや、オペレータの記憶を頼りに、手動でデータを変更する必要があります。
アーカイブログモードでは、データベースに対して適用された更新履歴が失われることがないように、更新履歴を記録したアーカイブログファイルが定期的に出力されます。このため、運用を継続するとアーカイブログファイルの数が増えてゆき、ディスク容量を圧迫するため、定期的に削除を実行することが必要でした。このようなメンテナンス作業が必要であることを懸念し、アーカイブログモードで運用することを躊躇されるお客様もいらっしゃいました。
しかし、Oracle Database 10g以降では、RMANで適切にバックアップを取得し、適切なサイズのフラッシュリカバリ領域を構成すると、アーカイブログファイルの定期的な削除作業をOracle Databaseが自動的に実行してくれるため、通常運用ではメンテナンス作業は不要です。

03.アーカイブブログファイルのメンテナンス負荷を軽減する設定方法

具体的には、以下の作業または事前構成が必要となります。

RMANによる定期的なデータベース全体バックアップ

RMANで、定期的にデータベース全体のバックアップを取得します。
例) データベース全体のバックアップを取得

RMAN> BACKUP DATABASE;

RMANのバックアップ保存方針(RETENTION POLICY)の設定

RMANの設定項目であるバックアップ保存方針(RETENTION POLICY)を運用ポリシーに合わせて設定します。
例) 過去2世代分のバックアップを保存する場合

RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

例) 7日前までの状態に復旧できるだけのバックアップを保存する場合

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

もっとも一般的な要件である、障害発生直前に戻せればよいのであれば、REDUNDANCYを指定して、過去1世代分のバックアップを保存しておけば十分です。障害発生直前だけではなく、過去のある時点（障害発生直前のX日前)に戻したい要件がある場合は、RECOVERY WINDOW OFを指定します。
なお、REDUNDANCY とRECOVERY WINDOW OFを併用することはできません。

フラッシュリカバリ領域の構成

データベース構成ファイルとは別のディスク装置上に、フラッシュリカバリ領域（11.2より高速リカバリ領域に名称変更）を構成します。
例) データベース構成ファイルをC:ドライブに配置している場合のフラッシュリカバリ領域の構成

RECOVERY_FILE_DEST=D:¥FRA 

加えて、フラッシュリカバリ領域に、バックアップファイル、アーカイブログファイルを保管できるだけの適切なサイズを割り当てます。具体的には、RMANのバックアップ保存方針の観点から保持される、定期的なデータベースのバックアップ、バックアップ保持期間に出力されるアーカイブログファイルを保管するのに十分なサイズを割り当てます。
例)
RMANのバックアップ保存方針が2世代分で、バックアップをイメージコピー形式で取得する場合で、データベースのサイズが1.5GB、出力されるアーカイブログファイルの総サイズが500MBの場合

1.5GB x 2 + 500MB = 3.5GB

バックアップファイル、アーカイブログファイルの出力先をフラッシュリカバリ領域に構成

フラッシュリカバリ領域は、リカバリ関連のファイルを一括して管理するための専用の領域ですので、この領域にバックアップファイル、アーカイブログファイルを出力するように構成します。なお、通常この条件は満たされています。たとえば、特にアーカイブログファイル関連の初期化パラメータを変更せずにDBCAをDBを作成し、RMANで明示的にバックアップファイルの出力先を指定していない場合で、フラッシュリカバリ領域が構成済みであれば、バックアップファイル、アーカイブログファイルはフラッシュリカバリ領域に出力されます。
フラッシュリカバリ領域に出力されたバックアップファイル、アーカイブはOracle Databaseにより自動的に管理され、不要な古いファイルは自動的に削除されます。このため、管理者が手動で不要な古いファイルを削除する作業が不要です。

(オプション) 制御ファイル自動バックアップの有効化

制御ファイル自動バックアップを有効化すると、データベースの構成変更が行われると、自動的に制御ファイルのバックアップが取得されます。
例) 制御ファイル自動バックアップの有効化

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

制御ファイルにはデータベースの構成情報が含まれています。障害発生時点のデータベースの構成と、バックアップされた制御ファイルに記録されたデータベースの構成情報に乖離があると、復旧作業が複雑になり、復旧に時間を要する場合があります。自動的に制御ファイルのバックアップが取得することで、このような事態を避けられます。

04.まとめ

最近はOS, ハードウェアの品質が向上したため、データベースが破損する危険性は減っていますが、万が一破損した場合の影響は甚大です。上記のように適切に構成すればアーカイブログファイルの管理コストの増加を抑えられますので、アーカイブログモードでの運用をお勧めいたします。