BACKUP IS ONE THING, RECOVERY IS EVERYTHING
本連載の第1回でお伝えした通り、リストア・リカバリに失敗した主な理由として上位にくるのが「バックアップの破損、ファイルの不足」です。そのためにOracle RMANでは、CROSSCHECKコマンドやVALIDATEコマンドを用意しており、バックアップが確実にリストア・リカバリに使えるものであることをチェックする仕組みを提供しています。
Recovery Appliance においてはこのようなチェックの仕組みが図1のように内部に組み込まれています。いずれのチェックタスクも定期実行されるようにスケジュールされており（図2）、本番データベースに影響を与えることなくRecovery Appliance内のリソースを使ってRecovery Applianceに保持しているバックアップの破損やファイル不足のチェックが行なわれています。
Real Time REDO 転送機能により通常のバックアップ運用の延長でRPOはニアゼロに
取得されたバックアップが健全なものだと保証できたとして、次に気にしたいのはデータロスの可能性についてです。本番データベースの障害発生時にデータロスをどこまで許容できるかという指標をRPO(Recovery Point Objective)と呼びます。コストとのバランスでデータベースとしてデータロスを仕方なく許容するケース（代わりにアプリからデータを再投入する仕組みを持つか、文字通りデータロスを許容するか）もありますが、消失して嬉しいデータはないはずです。Recovery Applianceを使えば通常のバックアップ運用の延長でこのRPOを限りなくゼロに近づけることができます。
本連載の第4回でデータベースの復旧の鍵となるのはREDOログであるという話をしました。Recovery Applianceでは、Oracle Databaseの機能であるOracle Data Guardの機能の一部を使って本番データベースからリアルタイムにREDOログを受け取ることができます（本番データベースがEnterprise EditionのデータベースだけでなくStandard EditionでもRecovery Applianceに対してREDOログをリアルタイムに送信できます）。これによって、図3のように本番データベースが全損するような大規模な障害が発生したとしても、直近に取得したバックアップと、Recovery Applianceにリアルタイムに送られていたREDOログを使って、障害発生直前までデータベースを復旧することができます。
