「バックアップを使って確実にリカバリできる」と自信を持って言えますか？
自信を持って「リカバリできる」と言い切れる人は少ないのではないかと思います。ある外部機関の調査（図1）では84%のデータベース管理者が過去1年以内にリストア・リカバリに失敗した経験があると回答をしています。失敗理由として上位に来るのが、「オペレーションミス」「バックアップの破損・不足」です。オペレーションミスについては、一刻も早い業務再開が求められる緊迫した場面で絶対になくすというのは難しいかもしれません。一方で、バックアップの破損や不足というのは事前に気付くことができます。
Oracle Databaseのバックアップ・リカバリ用ユーティリティであるRecovery Manager(以降RMAN)は、バックアップの破損や不足を事前に検知するための機能が用意されています。以降ではその点について話をしたいと思います。
ファイルの不足を検知する - CROSSCHECKコマンド
いざリカバリをしようとしたけど利用できるバックアップがない—。
意外かもしれませんが、残念なことに良くあるシチュエーションです。もともとアーカイブREDOログのバックアップを取っていなかったケース、NAS上に配置していたはずのバックアップファイルが意図せずに削除・移動されているケースなど理由は様々です。
この対策として、バックアップのスクリプトを正しく書く、あるいは適切なアクセス権を与えることを考えることももちろん大事ですが、「利用できるバックアップが存在する」ことを確認できる仕組みを持っておくことが重要です。
RMAN には CROSSCHECK というコマンドが用意されており、「リカバリカタログ」に格納されているバックアップの管理情報（いつ、どこにバックアップを取り、どういう状態か）と、バックアップファイルの実体との間に乖離がないかをOracle Database インスタンスがチェックする仕組みがあります。
例えば図2のようにバックアップがRMANで取得されている場合に、そのバックアップファイルの実体が意図せず移動・削除されてしまったとします。もし、このCROSSCHECKコマンドを定期的に実行していれば、図3のように管理情報と実体との間に乖離があることを検知（’EXPIRED’が検出されました）することができます。
RMAN> LIST BACKUP
BS Key Type LV Size Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ -------------------
37 Incr 0 379.17M DISK 00:00:12 2017/05/24 15:03:38
BPキー: 37 ステータス: AVAILABLE 圧縮: NO タグ: TEST
ピース名: /fast_recovery_area/orcl/backupset/2017_05_24/o1_mf_nnnd0_TEST_dlb8kg8q_.bkp
バックアップ・セット37のデータファイルのリスト
File LV Type Ckp SCN Ckp時間 Name
---- -- ---- ---------- ------------------- ----
1 0 Incr 3715141 2017/05/24 15:03:26 /oradata/orcl/system01.dbf
2 0 Incr 3715141 2017/05/24 15:03:26 /oradata/orcl/sysaux01.dbf
3 0 Incr 3715141 2017/05/24 15:03:26 /oradata/orcl/undotbs01.dbf
4 0 Incr 3715141 2017/05/24 15:03:26 /oradata/orcl/users01.dbf
5 0 Incr 3715141 2017/05/24 15:03:26 /oradata/orcl/test01.dbf
RMAN> crosscheck backup; リカバリ・カタログのかわりにターゲット・データベース制御ファイルを使用しています チャネル: ORA_DISK_1が割り当てられました チャネルORA_DISK_1: SID=5 デバイス・タイプ=DISK バックアップ・ピースがクロスチェックされました: 'EXPIRED'が検出されました バックアップ・ピース・ハンドル=/fast_recovery_area/orcl/backupset/2017_05_24/o1_mf_nnnd0_TEST_dlb8kg8q_.bkp レコードID=37 スタンプ=944838206 <以降省略> RMAN> list backup; BS Key Type LV Size Device Type Elapsed Time 終了時間 ------- ---- -- ---------- ----------- ------------ ------------------- 37 Incr 0 379.17M DISK 00:00:12 2017/05/24 15:03:38 BPキー: 37 ステータス: EXPIRED 圧縮: NO タグ: TEST ピース名: /fast_recovery_area/ORA11203S/backupset/2017_05_24/o1_mf_nnnd0_TEST_dlb8kg8q_.bkp
RMAN> backup incremental level 1 database; backupが開始されました(開始時間: 17-05-24) チャネルORA_DISK_1の使用 データファイル1の親バックアップまたはコピーが見つかりません データファイル2の親バックアップまたはコピーが見つかりません データファイル3の親バックアップまたはコピーが見つかりません データファイル4の親バックアップまたはコピーが見つかりません データファイル6の親バックアップまたはコピーが見つかりません チャネルORA_DISK_1: 増分レベル0のデータファイル・バックアップ・セットを開始しています
検知さえ出来れば、管理者は必要なバックアップが存在しないものとして以降の運用を行うことができますし、RMANはバックアップが存在しないものとして以降の動作を行いますので、仮に削除されてしまったバックアップを親（レベル0バックアップ）とするような増分バックアップ（レベル1バックアップ）の取得を実行したとしても、バックアップの実体が存在しないことをRMANはすでに知っていますので、レベル0のバックアップから取得しなおしてくれます（図4）。
