RecoveryManagerがオススメな件について

自分用のメモも兼ねて。

今まで「RecoveryManagerって構成が面倒くさそうだし、導入する労力に見合うかと聞かれるとちょっとなあ」と思ってたんですが、勉強のために構成とか実際の操作をやってみて「間違えとった〜！ワシのバカー」ってな感じになったので、オススメポイントなどをまとめておこうかと思います。

みなさん、バックアップの手順と運用ってどうしてますか？
思いつくだけ挙げてみますと、

Exp/Impによるエクスポート/インポート。(10g以降はDataPump。「論理バックアップ」)
Alter Database Begin Backup;発行後にOSでデータファイルのコピー。コピー後にEnd Backup;を発行。(ArcServeのBackupAgent for Oracleオプション等もやってる事は同じっぽいです。「物理バックアップ」(ホットバックアップ))
インスタンスをシャットダウンしてOSでデータファイルのコピー。(「物理バックアップ」(コールドバックアップ))

くらいですかね。(他にもアイデアがあったら教えてください。)

上記の手順(「ユーザ管理バックアップ」と表現されます)で困るところを考えてみると

エクスポート以降、障害発生地点までの変更は失われてしまう。(＝不完全リカバリしかできない。)
手動でやったら管理が面倒。End Backup;後に生成されたアーカイブREDOログをきちんと取得しないと完全リカバリできない。
バックアップ中はデータベースを利用できない。オフピーク時に取得する運用になるでしょうが、バッチとの兼ね合いでスケジュールがタイトになるかもしれない。(結果、夜間バッチ処理が営業開始まで完了しない、というケースが発生したりする。)

RecoveryManagerを使用すると、バックアップ毎にリカバリ時に必要となるファイルを圧縮書庫にまとめてくれるので扱いが楽という大きいメリットがあるのです。(またArchive log運用が必須になるので、完全リカバリと不完全リカバリどちらも可能になるという副次効果もあります。)

さらにRecoveryManagerを利用することによって可能になるのが

増分バックアップが可能になる
メディア障害からの復旧時にデータファイルの破損箇所が少ない場合はデータブロック単位で修復できる(ブロック・チェンジ・トラッキングが必要なのでEnterpriseEditionのみ)
データファイル中の未使用ブロックの圧縮が可能(EnterpriseEditionのみ。)
バックアップセットの圧縮が可能
バックアップセットの暗号化が可能(AdvanceSecurityOptionが必要なのでEnterpriseEditionのみ。11gR2よりCloudModuleというコンポーネントが追加になり、AmazonS3へのバックアップが可能になった模様。)
障害復旧に対して最善(と思われる)復旧方法の提案、実装を行ってくれる
DUPLICATEでインスタンスをまるごとコピーした環境を別マシンに作ったりできる(本番環境の復旧テストを行いたいケース等に使用するようです。)

なんで、「もっと気軽にRecoveryManagerを使えばいいのに。楽できるのに。」と思う訳です。
今後何回かに分けて、構成方法と実際の障害シナリオからの復旧手順を整理してみようかと思います。(自分用メモも兼ねて)

斜体部分を追記。11gR2のライセンス情報(B56284-04)を調べたら未使用ブロックの圧縮もEnterpriseEditionのみの機能でした。