RecoveryManagerの構成を考える

RecoveryManagerの構成を行うにあたって、事前に計画、検討を行う必要があるかな〜?という部分をピックアップしてみます。
いかんせん実運用環境での経験が足りないので、後の検証で修正することもあるかと思うので注意。

  • バックアップ計画、ポリシー
    • レベル0の取得タイミング。リカバリーを行う場合でフルで戻す必要がある場合(例えばデータファイルが全損とか)、レベル0のバックアップをリストアして順次差分のレベル1バックアップを適用する必要がある。なので、余りレベル0バックアップの取得間隔が長いとリカバリが大変になるので適時取得する。この辺はデータの容量とバックアップ時間の兼ね合いになると思う。
    • レベル1、レベル1累積増分の取得タイミング。特にレベル1累積増分は適度に取得しておくと、レベル0をリストア、累積増分を当てる、以降リカバリ地点までレベル1を適用するという手順でリストアできるので、データが大きい場合には時間の節約ができるので、適時取得するのが望ましいと思われる。
    • 取得したバックアップに暗号化が必要か?コンプライアンス等の絡みでバックアップファイルに暗号化が必要である場合、まずファイルシステムの暗号化(NTFSの暗号化等)やテープドライブの暗号化機能での暗号化で十分か確認。それ以上が望まれるのならば、AdvasceSecurityオプションを購入して頂く。ファイルシステムの暗号化を行うとき、高速リカバリ領域を暗号化するのはパフォーマンス上懸念があるので、バックアップ完了後に暗号化された場所に移動、等で対応する。
  • リポジトリの保存方法
    • リポジトリの保存先はターゲットデータベースの制御ファイルに保存するか、リポジトリデータベースを作成してそちらに保存するかを選択できる。(デフォルトでは制御ファイル)それぞれ長所があるので、どちらがよいとは言えないが、制御ファイルの方が構成が簡単なので用件を満たせるなら制御ファイルで管理する方が良いのではないかと思う。(個人的感想)
    • 制御ファイルでの管理は、リポジトリカタログの長期保存には向かない。数ヶ月オーダー?制御ファイルが喪失した場合、同時にカタログも喪失するのでリカバリが大変になる。(不可能ではない。)なので制御ファイルの多重化を強く推奨。
    • リポジトリデータベースでの管理は、リポジトリカタログの長期保存に向く。(制御ファイルで保存できないほど過去の状態にポイント・イン・タイム・リカバリ(PITR)する用件が発生する場合?)DataGuard環境ではこちらでの管理が必須。メタデータの問い合わせが可能になるので管理やレポートの生成を自動化できる(かもしれない)。
  • バックアップの設定
    • 保存ポリシー(RETENTION POLICY)期間または冗長性で設定する。バックアップの最適化(BACKUP OPTIMIZATION)をONにした場合、冗長性で管理した方が状態の理解がしやすい様に思う。保存ポリシーを超過したバックアップセットはカタログ上、不要と"マーク"される。高速リカバリ領域の容量が不足した場合に初めて削除が実施される。
    • 制御ファイルの自動バックアップ(CONTROLFILE AUTOBACKUP)特に理由が無ければONにしておくとバックアップ漏れが発生しないので、それはとっても嬉しいなって。(なぜかデフォルトがOFFなので注意)リファレンスで「リカバリ・カタログを使用せずにRecovery Managerを使用する場合は、制御ファイルの自動バックアップを有効にする必要があります。」と表記されているので該当の場合は必ずONに設定すること。
    • バックアップセットの最大サイズ(MAXSETSIZE)テープにバックアップする際に、テープの容量に合わせておく。また、チャネルがDISKの場合もファイルシステム上サイズに制限がある場合は、そのサイズに制限しておく。

以降、想定シナリオからのリカバリ等を実験していこうかと思います。
それにしても見難いので、はてな記法を勉強しないとなあ…。