これまではOracleを扱う機会が多かったので、今日はOracleのRecoveryManagerという機能について書きたいと思います。

データベースってテーブルの論理構造が壊れたり、物理的にブロック破損が起こったり、様々な障害ケースがありますが、そんな中Oracleには、Recovery Managerという、データブロック単位での復旧が可能な機能があります。RecoveryManagerでは、バックアップの保存期間や保存形式、バックアップを取得する際のチャネル数を指定することができたり、フルバックアップや差分増分バックアップがあったりと、結構痒いところに手が届く機能になっています。

バックアップは「backup database」コマンド一つで、ターゲットデータベースのデータファイルを全取得できます。plus archivelogオプションを指定すると、アーカイブログファイルも一緒に取得してくれるので、こっちのほうが一般的ですね。

次に障害時のリカバリーの種類としては、

障害直前時点へ戻す：取得したデータファイルをリストアし、可能な限りのアーカイブログファイルを適用し、その後REDOログファイル内の変更情報を適用し、障害直前状態までリカバる。
バックアップ取得時点へ戻す：取得したデータファイルをリストアし、バックアップセット内のアーカイブログファイルを適用し、バックアップ時点にリカバる。その後、REDOログファイルを再作成して、resetlogs openでデータベースを復旧する。

大きく二種類があります。

これぐらいを前提として、自身がバックアップ・リカバリの設計をやっていて気をつけていたこととかハマったこととか、気をつけていたことをザクッと書いていきたいと思います。

リカバリカタログデーターベースを活用する。

リカバリカタログ上のバックアップ情報は、ターゲットデーターベースの制御ファイルと同期を取ります。
このバックアップ情報は、制御ファイルのみで運用することも可能ですがこの場合幾つか注意点があります。

機能制限が出る。（RecoveryManagerのこの機能使うならカタログデータベースを立ててねと言われる。）
CONTROL_FILE_RECORD_KEEP_TIMEのチューニングを適切に行う必要がある。
CONTROLFILE AUTOBACKUPを必ずONにする必要がある。

いくつか書きましたが、特にCONTROL_FILE_RECORD_KEEP_TIMEの設定周りは要注意です。制御ファイルは予め設定した一定期間を経過すると、制御ファイル自身に登録されたバックアップ情報を忘れます。そのため、例えばDELETE OBSOLETEコマンドを発行すると、タイミングによっては思わぬファイルを削除してしまう可能性もあります。(必ずREPORTで対象ファイルを確認するようにしいましょう　）
この理由により、CONTROL_FILE_RECORD_KEEP_TIMEパラメータの設計を適切に行うことが必須です。
ベストとしては、リカバリカタログ表領域を保有する、専用のデータベースを採用することが望ましいです。リカバリカタログ情報の保有のみなので、比較的小規模な容量でOKです。

NOARCHIVELOG運用は避ける。

NOARCHIVELOGモード運用での障害時は、まれなケースを除いて復旧が困難です。というのも、変更情報を保有するファイルが存在しないため、REDOログファイルしか頼りになるものがなくなるんですよね。で、REDOログファイルも破損しているなどの全破損している場合の復旧は困難を極めます。
なので、相当な要件、例えばコールドバックアップ、コールドリカバリが出来れば良い、など特別な要件がない限り、ARCHIVELOG_MODEの有効設定は必須です。

RETENTION POLICYの設定と、ディスク設計を適切に行う。

データベースを復旧する際、どの時点に向けた復旧が要件かに従って、RETENTION POLICYを設定することが必要です。デフォルトでは1が設定されていますが、数世代分持ちたい場合は任意の値に変更します。
(バックアップ時には一時的に+1日分の余剰を見込むことが必要です。)
また、RecoveryManagerには保存期限を過ぎたバックアップセットを削除してくれる機能がありますが、先述した制御ファイルのみで運用する場合は、REPORT OBSOLETEコマンドで削除対象を十分に確認するのがベターです。

Real Application Cluster(RAC)構成の場合はアーカイブログファイルの取扱に注意する。

RAC構成でデータベースが破損もしくは状態戻しのためにリカバリーを実施しようとする際は、ちょっと厄介です。ASM領域への不要なアクセスを防ぐために単一インスタンスでのリカバリー作業が必要になるので複数インスタンスが存在する場合は、その事前準備をしたりとか、ディスクグループそのものが破損しているという深刻なケースの場合はrecover database前に、create diskgroupが必要だったりとか。
中でも私がハマったのはアーカイブログファイルの取扱いでした。RACにおけるアーカイブログファイルの扱いなんですが、単一のデータベースとは言え、複数ノードから共有され、各スレッドでアーカイブログファイルが出力がされていきます。各スレッドに対して交互に出力されていくイメージです。そのため、リカバリー時に特定の時間を指定して実行した際に、「スレッド2のアーカイブログファイルが破損していてリカバリーできませんでした。」、なんていうことが発生したことがあります。2ノード以上のRAC構成では、アーカイブログファイルの存在を確認し、どのシーケンス番号まで復旧が可能かを確認し、オペレーションを行うことが必要です。

また機会みてOracleネタ書いていけたらなと思います。