一貫性バックアップ
- リストア操作の直後にデータベースをオープンできる。（リカバリ必要なし）
- REDOログ内の全ての変更がデータファイルに適用されている必要がある。（だからリカバリ必要なし）
- DBをクローズして、インスタンスを停止しなくてはいけない。インスタンスを停止しているので、全てのデータファイルは同じ状態？
非一貫性バックアップ
DBオープン中に行うことができる。
データファイルに適用されていない変更が、オンラインREDOログファイルまたはアーカイブREDOログファイルに含まれている場合あり。（オープンしてると新しい更新がどんどん来るため）
リストア後にメディアリカバリ（明示的なリカバリ）を実行する必要がある。（REDOログなどの差を無くすため）
バックアップファイルのタイプ
OEMで使用可能なバックアップファイルのタイプは、
OEMホームページ＞メンテナンス＞バックアップ/リカバリ＞現行バックアップの管理 「現行バックアップの管理」の「コンテンツ」を見るとどの種類のファイルをバックアップしてるのかわかる。
- イメージコピー・・・OSのコピーコマンドと同じ。データファイル制御ファイル、アーカイブREDおログファイルのコピー。データファイルのイメージコピーは、未使用のブロックも含め、データファイルのすべてのブロックで構成されます。イメージコピーには1つのファイルのみを含められる。1回のコピーでは多重化できない
- バックアップセット・・・Recovery Managerで使用するファイル形式。1つ以上のデータファイル、制御ファイル、REDOログファイルを含められる。セットだから、まとめて取れる。
データベース全体のバックアップ
DB（制御ファイル、アーカイブREDO ログファイル、SPファイル、データファイル）の全内容をバックアップ。
大規模なDBの場合、時間がかかるので、頻繁にするのは向いてない。そのためアーカイブログファイルが使用できない（もしくはできなくなる）次のような時には、全体バックアップを取る。
- 新規DBの作成直後
- ARCHIVELOGモードとNOARCHIVELOGモード間の切り替え時
データファイルのバックアップ
- 全体バックアップ・・・1つ以上のファイルの全ての使用ブロックがバックアップされる。データベース内の全てのデータファイル、制御ファイル、アーカイブREDOログファイル、SPFILEがバックアップ対象。オンラインREDOログファイルは対象ではない。
- 増分バックアップ・・・変更されたブロックのみを含む差分バックアップ。
- 差分増分バックアップ・・・前回からの変更部分だけをバックアップ。ファイルがいくつも分かれるので、リカバリにその文の時間がかかる。
- 累積増分バックアップ・・・最初の全体バックアップからの変更点をバックアップ。だんだんバックアップ時間は長くなっていく。リカバリに使うファイル数は少なめなので、リカバリは早め。
増分更新バックアップ
データファイルのイメージコピーを作成した後、定期的にデータベースの増分バックアップをイメージコピーに適用する方法。データファイルの状態が定期的に新しいものになるので、リカバリ時間を短くできる。
バックアップの流れ
- バックアップ先の構成・・・バックアップ先はどこか。バックアップファイルのタイプはどっちか。
- ポリシーの設定・・・増分バックアップするか？バックアップとらなくてもいいファイルはあるのか？何日分バックアップするか？
- バックアップ計画の作成・・・何をいつからどのくらいの間隔でバックアップするか決める。
- バックアップの管理・・・バックアップが存在してるか？アクセスできるか？不要になったバックアップの削除。
OEMを使用してのバックアップ設定と方法
設定
OEMホームページ＞メンテナンス＞バックアップ/リカバリ設定＞バックアップ設定 「ディスク・バックアップの場所」をNULLにするとフラッシュリカバリ領域にバックアップされる。
方法
OEMホームページ＞メンテナンス＞バックアップ/リカバリ＞バックアップのスケジュール
ポリシーの設定
バックアップポリシー・・・バックアップ方法や場所などの制御情報。
リテンション（保存）ポリシー・・・バックアップとコピーの保存期間を決めるもの。冗長性（複数の世代）とリカバリ期間で定義できる。たとえばDBを過去3日の任意の時点にりかばりできればいいのなら、4日以上前のバックアップは要らなくなる。
OEMホームページ＞メンテナンス＞バックアップ/リカバリ設定＞バックアップ設定＞ポリシー
データファイルは「データベース全体のバックアップから除外される表領域」を指定できる。一時表や索引のみの表領域も除外して平気。
バックアップの管理
ディスクまたはテープ上にあるバックアップファイルそのものとバックアップレコード（バックアップ情報）の管理をさす。
バックアップレコードはRman(Recovery Manager)のリポジトリに格納され、OEMを使用して管理できる。リポジトリの場所は通常、制御ファイルになる。オプションでリカバリカタログデータベース内に格納することもできる。
OEMでできること
- リポジトリに記憶されているバックアップ（バックアップセットとイメージコピーのリスト表示）
- リポジトリのクロスチェック
- リポジトリにリストされているバックアップが実際に物理的に存在しているか、またはアクセス可能かをチェック
- クロスチェック時にアクセスできないバックアップが存在した場合、そのバックアップを期限切れとする。
クロスチェックの結果表示
- AVAILABLE（使用可能）・・・リポジトリに記録された位置にちゃんとあり、ファイルヘッダーの破損が無い。（テープ上のはファイルヘッダーの破損のチェックは無い。）
- EXPIRED（期限切れ）・・・リポジトリに記録されてるが、その記録位置にファイルがない、確認できない！
- UNAVAILABLE（使用不可）・・・バックアップのステータスをUNAVAILABLE（使用不可）にすることができる。一時的に使用できなくなったことを示す。リカバリ操作でこのファイルは使われない。フラッシュリカバリ領域に格納されているバックアップはUNAVAILABLEできない。
- 期限切れになったバックアップをリポジトリから削除。「期限切れになったものを削除」ボタンをクリックすると、期限切れのバックアップセットもイメージコピーのどちらも削除される。
- 不要になったバックアップレコードをリポジトリから削除とディスクからファイル削除。
- フラッシュリカバリ領域にあるものは手動で削除する必要が無い。必要になったら勝手に削除される。
- 追加ファイルのカタログ化・・・OS上でコピーしてとったバックアップやリカバリ領域内にあるバックアップファイルをリカバリ操作で使用できるように、リポジトリ内でカタログ化することができる。
バックアップのスケジュール
対象
- データベース全体
- 表領域
- データファイル
- アーカイブログファイル
- ディスク上の全てのリカバリファイル
推奨のバックアップ計画
- 最初に全DBのバックアップ作成。
- 2回目以降は、毎日増分バックアップが実行。
- Point-In-Timeリカバリできる。
