Oracle Databaseバックアップおよびリカバリ基礎, 10gリリース2（10.2）

Transcription

1 Oracle Database バックアップおよびリカバリ基礎 10g リリース 2(10.2) 部品番号 : B 年 3 月 Oracle データベースのバックアップおよびリカバリの基礎について 一般的なバックアップ タスクおよびリカバリ タスクで Recovery Manager を使用する場合を重点的に説明します

2 Oracle Database バックアップおよびリカバリ基礎, 10g リリース 2(10.2) 部品番号 : B 原本名 : Oracle Database Backup and Recovery Basics, 10g Release 2 (10.2) 原本部品番号 : B 原本著者 : Antonio Romero 原本協力者 : Lance Ashdown Tammy Bednar Anand Beldalker Timothy Chien Raymond Guzman Alex Hwang Ashok Joshi J. William Lee Valarie Moore Muthu Olagappan Samitha Samaranayake Francisco Sanchez Steven Wertheimer Wanli Yang Copyright 2003, 2006, Oracle. All rights reserved. 制限付権利の説明 このプログラム ( ソフトウェアおよびドキュメントを含む ) には オラクル社およびその関連会社に所有権のある情報が含まれています このプログラムの使用または開示は オラクル社およびその関連会社との契約に記された制約条件に従うものとします 著作権 特許権およびその他の知的財産権と工業所有権に関する法律により保護されています 独立して作成された他のソフトウェアとの互換性を得るために必要な場合 もしくは法律によって規定される場合を除き このプログラムのリバース エンジニアリング 逆アセンブル 逆コンパイル等は禁止されています このドキュメントの情報は 予告なしに変更される場合があります オラクル社およびその関連会社は このドキュメントに誤りが無いことの保証は致し兼ねます これらのプログラムのライセンス契約で許諾されている場合を除き プログラムを形式 手段 ( 電子的または機械的 ) 目的に関係なく 複製または転用することはできません このプログラムが米国政府機関 もしくは米国政府機関に代わってこのプログラムをライセンスまたは使用する者に提供される場合は 次の注意が適用されます U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR , Commercial Computer Software--Restricted Rights (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA このプログラムは 核 航空産業 大量輸送 医療あるいはその他の危険が伴うアプリケーションへの用途を目的としておりません このプログラムをかかる目的で使用する際 上述のアプリケーションを安全に使用するために 適切な安全装置 バックアップ 冗長性 (redundancy) その他の対策を講じることは使用者の責任となります 万一かかるプログラムの使用に起因して損害が発生いたしましても オラクル社およびその関連会社は一切責任を負いかねます Oracle JD Edwards PeopleSoft Retek は米国 Oracle Corporation およびその子会社 関連会社の登録商標です その他の名称は 他社の商標の可能性があります このプログラムは 第三者の Web サイトへリンクし 第三者のコンテンツ 製品 サービスへアクセスすることがあります オラクル社およびその関連会社は第三者の Web サイトで提供されるコンテンツについては 一切の責任を負いかねます 当該コンテンツの利用は お客様の責任になります 第三者の製品またはサービスを購入する場合は 第三者と直接の取引となります オラクル社およびその関連会社は 第三者の製品およびサービスの品質 契約の履行 ( 製品またはサービスの提供 保証義務を含む ) に関しては責任を負いかねます また 第三者との取引により損失や損害が発生いたしましても オラクル社およびその関連会社は一切の責任を負いかねます

3 目次 はじめに はじめに... xi 対象読者... ドキュメントのアクセシビリティについて... 関連ドキュメント... 表記規則... サポートおよびサービス... xii xii xii xiii xiii 1 バックアップおよびリカバリの概要 バックアップおよびリカバリとは何か 物理バックアップと論理バックアップ バックアップからのリカバリが必要なエラーおよび障害 ユーザー エラーの理解 メディア障害の理解 Oracle のバックアップおよびリカバリ ソリューション : Recovery Manager およびユーザー管理のバックアップ バックアップおよびリカバリ : 基本概念 データのリカバリで使用されるデータベースの物理構造 データ ファイルおよびデータ ブロック REDO ログ 制御ファイル UNDO セグメント データベースのリカバリ処理 : 基本概念 データ リカバリの方式 データ ファイルのメディア リカバリ : データ ファイルのリストアと REDO の適用 完全 不完全および Point-in-Time リカバリ インスタンス障害後の自動リカバリ : クラッシュ リカバリ Recovery Manager を使用したバックアップおよびリカバリ Recovery Manager によるバックアップが可能なファイル Recovery Manager のバックアップ先 : ディスクおよびメディア マネージャ Recovery Manager での Oracle データベースのバックアップのタイプ 一貫性バックアップおよび非一貫性バックアップ 全体バックアップおよび増分バックアップ イメージ コピー バックアップ セットおよびバックアップ ピース 自動ディスク ベース バックアップおよびリカバリ : フラッシュ リカバリ領域 Oracle Flashback Technology: Point-in-Time リカバリの代替方法 リストア ポイント 障害とバックアップおよびリカバリ方法との対応付け i

4 メディア障害への対処 ユーザー エラーへの対処 バックアップおよびリカバリ方式のシステム要件 各バックアップ方式の機能の比較 バックアップおよびリカバリ計画 バックアップ計画を決定するデータ リカバリ計画 データ リカバリ計画の立案 ユーザー エラーへの対処方法の立案 : Point-in-Time リカバリおよびフラッシュバック機能 Oracle Flashback Database 通常のリストア ポイントと保証付きリストア ポイントの作成 データベースの Point-in-Time リカバリ 論理バックアップからの消失したオブジェクトのインポート メディア障害対策の立案 : リストアおよびメディア リカバリ 例 : オンライン REDO ログのリカバリ データ ファイル ブロック破損に対する対策の立案 : ブロック メディア リカバリ バックアップ計画の立案 冗長性セットの保護 フラッシュ リカバリ領域の使用の有無の決定 ARCHIVELOG および NOARCHIVELOG モードの決定 NOARCHIVELOG モードでの稼働の影響 ARCHIVELOG モードでの稼働の影響 Oracle のフラッシュバック機能とリストア ポイントの使用の決定 バックアップ保存方針の選択 Recovery Manager によるバックアップ保存方針の実装 リカバリ期間ベースのバックアップ保存方針 冗長性ベースのバックアップ保存方針 古いバックアップのアーカイブ バックアップ頻度の決定 構造の変更前と後のバックアップの実行 頻繁に更新される表領域のバックアップのスケジューリング NOLOGGING 操作後のバックアップ 保護と柔軟性の強化のためのデータベース データのエクスポート オンライン REDO ログのバックアップの防止 サーバーのハードウェアおよびソフトウェア構成に関する情報の保持 データ リカバリ計画の検査 BACKUP... VALIDATE の使用 Recovery Manager バックアップの検査 : VALIDATE および RESTORE VALIDATE データベースのリストアおよびリカバリ手順のテスト バックアップおよびリカバリの設定と構成 Recovery Manager クライアントの操作の概要 Recovery Manager の起動および終了 Recovery Manager のグローバリゼーション サポート環境変数の設定 コマンド プロンプトでの Recovery Manager コマンドの入力 Recovery Manager でのコマンド ファイルの使用 Recovery Manager コマンドおよびコマンド ファイルの構文のチェック : CHECKSYNTAX ii

5 コマンドラインでの Recovery Manager コマンド構文のチェックの例 コマンド ファイル内の Recovery Manager コマンド構文のチェックの例 Recovery Manager を使用したデータベースの起動および停止 データベースへの Recovery Manager クライアントの接続 Recovery Manager で使用するデータベース接続のタイプ データベース接続の認証 コマンドラインからのターゲット データベースへの接続 Recovery Manager プロンプトからのターゲット データベースへの接続 Recovery Manager バックアップ用のデータベースの設定 永続的な構成設定 : Recovery Manager の動作の制御 Recovery Manager の現行の構成設定の表示 : SHOW Recovery Manager のデフォルトの構成設定のリストア : CONFIGURE... CLEAR バックアップ用のデフォルト デバイス タイプの構成 ディスク バックアップ用のデフォルト バックアップ タイプの構成 テープまたはディスクに対する圧縮バックアップ セットのデフォルトの構成 ディスク デバイスとチャネルの構成 テープ デバイスとチャネルの構成 制御ファイルおよびサーバー パラメータ ファイルの自動バックアップの構成 制御ファイルの自動バックアップ書式の構成 制御ファイルの構成済自動バックアップ書式の変更 Recovery Manager 用のフラッシュ リカバリ領域の設定 フラッシュ リカバリ領域の位置の選択 フラッシュ リカバリ領域 自動ストレージ管理および Oracle Managed Files フラッシュ リカバリ領域に格納できるファイル フラッシュ リカバリ領域のサイズの計画 フラッシュ リカバリ領域のサイズと位置の初期化パラメータの設定 フラッシュ リカバリ領域のサイズ : DB_RECOVERY_FILE_DEST_SIZE フラッシュ リカバリ領域の位置 : 初期化パラメータ DB_RECOVERY_FILE_DEST 複数のデータベース間でのフラッシュ リカバリ領域の共有 フラッシュ リカバリ領域使用時の初期化パラメータの制限 既存データベースへのフラッシュ リカバリ領域の追加 V$RECOVERY_FILE_DEST および V$FLASH_RECOVERY_AREA_USAGE の使用 フラッシュ リカバリ領域の無効化 バックアップ保存方針の構成 リカバリ期間ベースの保存方針の構成 冗長性ベースの保存方針の構成 現在のバックアップ保存方針の表示 保存方針の無効化 フラッシュ リカバリ領域における Oracle のディスク領域の管理方法 フラッシュ リカバリ領域のファイルが削除の対象となる場合 フラッシュ リカバリ領域で領域が使用不可の場合 ディスク ベースのバックアップ用のフラッシュ リカバリ領域の構成 : 例 フラッシュ リカバリ領域での多重化ファイルを使用したデータベースの作成 : 例 フラッシュ リカバリ領域でのアーカイブ ログのみを使用したデータベースの作成 : 例 Recovery Manager を使用したデータベースのバックアップ Recovery Manager バックアップの概要 Recovery Manager によるバックアップが可能なファイル iii

6 Recovery Manager バックアップの形式 : イメージ コピーおよびバックアップ セット イメージ コピー バックアップ セット Recovery Manager によるデータ ファイルの全体バックアップおよび増分バックアップ Recovery Manager の BACKUP コマンドの出力に影響するオプションの指定 Recovery Manager の BACKUP に対する出力デバイス タイプの指定 Recovery Manager の BACKUP に対するイメージ コピーまたはバックアップ セットの出力のディスクへの指定 Recovery Manager の BACKUP に対する出力ファイルの場所の指定 Recovery Manager の BACKUP に対するタグの指定 Recovery Manager によるバックアップでの圧縮バックアップ セットの使用 Recovery Manager を使用したデータベース ファイルおよびアーカイブ ログのバックアップ Recovery Manager を使用した一貫性バックアップおよび非一貫性バックアップの作成 Recovery Manager を使用したデータベース全体のバックアップの作成 Recovery Manager を使用した個々の表領域のバックアップ Recovery Manager を使用した個々のデータ ファイルおよびデータ ファイルのコピーのバックアップ データ ファイルのバックアップ データ ファイルのコピーのバックアップ Recovery Manager を使用した制御ファイルのバックアップ 他のファイルの現行の制御ファイルをバックアップに含める 現行の制御ファイルの手動バックアップ 制御ファイルのコピーのバックアップ Recovery Manager を使用したサーバー パラメータ ファイルのバックアップ Recovery Manager を使用したアーカイブ REDO ログのバックアップ BACKUP ARCHIVELOG を使用したアーカイブ REDO ログ ファイルのバックアップ アーカイブ ログのバックアップ時のオンライン REDO ログの自動切替え DELETE INPUT または DELETE ALL INPUT を指定した BACKUP ARCHIVELOG の使用 BACKUP... PLUS ARCHIVELOG を使用したログのバックアップ Recovery Manager の増分バックアップ 増分バックアップ アルゴリズム レベル 0 およびレベル 1 の増分バックアップ 差分増分バックアップ 累積増分バックアップ 基本的な増分バックアップ計画 増分バックアップの作成 : BACKUP INCREMENTAL 増分更新バックアップ : イメージ コピーのバックアップのロールフォワード 増分更新バックアップ : 基本的な例 増分更新バックアップ : 1 週間の例 増分バックアップのパフォーマンスの改善 : チェンジ トラッキング チェンジ トラッキングの有効化および無効化 チェンジ トラッキングが有効かどうかの確認 チェンジ トラッキング ファイルの移動 ディスク上のチェンジ トラッキング ファイルのサイズの見積り Recovery Manager を使用したデータベース ファイルの検証 バックアップおよび Recovery Manager リポジトリのレポートの概要 Recovery Manager バックアップ アーカイブ ログおよびデータベース インカネーションの表示 LIST コマンドによって生成された Recovery Manager レポート iv

7 バックアップの表示 バックアップごとの表示 ファイルごとの表示 サマリー モードでのバックアップの表示 選択したバックアップの表示 データベース インカネーションの表示 バックアップおよびデータベース スキーマのレポート Recovery Manager バックアップのレポート 保存方針に基づくバックアップが必要なファイルのレポート 様々な保存方針での Recovery Manager の REPORT NEED BACKUP の使用 表領域およびデータ ファイルでの Recovery Manager の REPORT NEED BACKUP の使用 テープまたはディスク上のバックアップのみでの REPORT NEED BACKUP の使用 リカバリ不能な操作の影響を受けるデータ ファイルのレポート 不要なバックアップのレポート データベース スキーマのレポート リストア ポイントおよび Oracle Flashback Database を使用したデータ保護 リストア ポイントおよび Oracle Flashback Database の概要 Oracle Flashback Database データベースのフラッシュバックの期間 通常のリストア ポイント リストア ポイントを使用できるコマンド 保証付きリストア ポイント ストレージ スナップショットの代替方法としての保証付きリストア ポイントの使用 Oracle Flashback Database および保証付きリストア ポイントのロギング 保証付きリストア ポイントおよびフラッシュ リカバリ領域の領域使用状況 フラッシュバック ロギングが無効な場合の保証付きリストア ポイントのロギング 保証付きリストア ポイントを定義している場合の Oracle Flashback Database のロギング 通常のリストア ポイントと保証付きリストア ポイントの使用 保証付きリストア ポイントの使用の要件 通常のリストア ポイントと保証付きリストア ポイントの作成 リストア ポイントのリスト リストア ポイントの削除 保証付きリストア ポイントの領域使用状況の監視 Oracle Flashback Database の設定とメンテナンス Oracle Flashback Database の制限事項 Oracle Flashback Database の有効化の要件 Oracle Flashback Database のロギングの有効化 フラッシュバック ログを格納するためのフラッシュ リカバリ領域のサイズ設定 データベースのフラッシュバック ログのディスク領域要件の見積り フラッシュ リカバリ領域におけるフラッシュバック ログ用の領域管理 フラッシュバック ログの保持と削除の規則 現行のデータベースのフラッシュバックの期間の確認 Oracle Flashback Database のパフォーマンス チューニング Oracle Flashback Database のパフォーマンスの影響の監視 I/O エラーの場合の Flashback Writer(RVWR) の動作 v

8 6 データベースの完全リストアおよび完全リカバリの実行 Recovery Manager を使用したデータベースのリストアおよびリカバリの概要 この章の内容 Enterprise Manager を使用したリストアおよびリカバリ データベースのリストアおよびリカバリの基本使用例 データベース全体のリストアおよびリカバリ : 使用例 読取り専用表領域を含むデータベースのリカバリ データベース全体のリストアおよびリカバリでの一時表領域の再作成 個々の表領域またはデータ ファイルのリストアおよび完全リカバリ : 使用例 データベースのリストアおよびリカバリの準備および計画 データベースのリストアおよびリカバリ手順の概要 リストアまたはリカバリするデータベース ファイルの決定 消失した制御ファイルの確認 メディア リカバリが必要なデータ ファイルの識別方法 読取り専用表領域のリカバリ DBID の決定 リストア操作で使用するバックアップの確認 : RESTORE PREVIEW RESTORE... PREVIEW の使用 RESTORE... PREVIEW SUMMARY の使用 RESTORE... PREVIEW RECALL の使用 バックアップのリストアの検査 : RESTORE VALIDATE および VALIDATE BACKUPSET RESTORE... VALIDATE を使用したバックアップからのリストアの検査 VALIDATE BACKUPSET を使用したバックアップ セットの検査 Recovery Manager の RESTORE: 消失したデータベース ファイルのバックアップからのリストア バックアップからの制御ファイルのリストア 制御ファイルのデフォルトのリストア先 制御ファイルの自動バックアップからの制御ファイルのリストア フラッシュ リカバリ領域を使用した場合の制御ファイルのリストア リカバリ カタログを使用した場合の制御ファイルのリストア 既知の場所からの制御ファイルのリストア 新しい場所への制御ファイルのリストア バックアップ制御ファイルを使用した場合の制限 バックアップからのサーバー パラメータ ファイル (SPFILE) のリストア 制御ファイルの自動バックアップからの SPFILE のリストア Recovery Manager によるクライアント側初期化パラメータ ファイル (PFILE) の作成 データ ファイルおよび表領域のリストアとリカバリ バックアップから新しい場所へのデータ ファイルのリストア リストア済データベース 表領域またはデータ ファイルのメディア リカバリの実行 新しい場所への単一のデータ ファイルのリストアおよびリカバリ : 例 バックアップからのアーカイブ REDO ログのリストア 新しい場所へのアーカイブ REDO ログのリストア 複数の場所へのアーカイブ REDO ログのリストア フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 Point-in-Time リカバリとフラッシュバックの機能 データベースの Point-in-Time リカバリ Oracle Flashback Technology: Point-in-Time リカバリの代替方法 Oracle Flashback Query: 行レベルでのリカバリ Oracle Flashback Table: 個々の表の過去の状態へのリカバリ vi

9 Oracle Flashback Table を使用する場合の前提条件 Oracle Flashback Table の実行 Oracle Flashback Drop: DROP TABLE 操作の取消し ごみ箱の概要 ごみ箱への表およびその他のオブジェクトの移動 ごみ箱内のオブジェクトのネーミング規則 ごみ箱の有効化および無効化 ごみ箱内のオブジェクトの表示および問合せ ごみ箱の容量と領域圧迫 領域圧迫の理解 データベースによる領域圧迫の処理 ごみ箱のオブジェクトとセグメント ごみ箱内の表に対する削除のフラッシュバックの実行 元の名前が同じ複数のオブジェクトに対する削除のフラッシュバック ごみ箱からのオブジェクトの消去 PURGE TABLE: 表および依存オブジェクトの消去 PURGE INDEX: ごみ箱内の領域の解放 PURGE TABLESPACE: 表領域内の削除したすべてのオブジェクトの消去 PURGE RECYCLEBIN: ユーザーのごみ箱内のすべてのオブジェクトの消去 PURGE DBA_RECYCLEBIN: ごみ箱内のすべてのオブジェクトの消去 表領域 クラスタ ユーザーまたは型の削除とごみ箱 Oracle Flashback Drop のための権限およびセキュリティ Oracle Flashback Drop の制限事項 Oracle Flashback Database を使用したデータベースの変更の取消し Oracle Flashback Database の実行例 Oracle Flashback Database 操作が正常に終了した後に実行可能な操作 誤った時刻へのデータベースのフラッシュバック後に実行可能な操作 Oracle Flashback Database およびインカネーションをまたがった不明確な SCN 保証付きリストア ポイントまでのデータベースのフラッシュバックの実行 Oracle Flashback Database の実行による OPEN RESETLOGS の取消し スタンバイ データベースにおける OPEN RESETLOGS に対する Oracle Flashback Database OPEN RESETLOGS の右側へのデータベースのフラッシュバックの例 データベースの Point-In-Time リカバリの実行 データベースの Point-in-Time リカバリの要件 Point-in-Time リカバリおよびデータベース インカネーションの概要 親 祖先および兄弟のデータベース インカネーションの理解 データベースのインカネーション履歴の例 兄弟インカネーション 不明確な SCN および RESET DATABASE INCARNATION データベース インカネーションと孤立したバックアップ 孤立したバックアップの使用 データベースの Point-in-Time リカバリの準備 現行のインカネーション内での Point-in-Time リカバリ データベースの Point-in-Time リカバリでの目標時点の指定 データベースの Point-in-Time リカバリ後に実行可能な操作 祖先インカネーションまでの Point-in-Time リカバリ vii

10 8 Recovery Manager のメンテナンス作業 制御ファイルのみを使用した Recovery Manager リポジトリのメンテナンス 制御ファイルのバックアップおよびリストア 制御ファイル レコードの上書きの監視 制御ファイル レコードの上書きの管理 フラッシュ リカバリ領域と CONTROL_FILE_RECORD_KEEP_TIME の相互作用 CROSSCHECK を使用した Recovery Manager リポジトリの更新 Recovery Manager のクロスチェック バックアップ セットおよびイメージ コピーでの CROSSCHECK の基本的な使用 特定のバックアップ セットおよびコピーのクロスチェック 特定のデータベース ファイルのバックアップのクロスチェック Recovery Manager の CROSSCHECK における特定の時点以降のバックアップへの制限 バックアップの削除 指定したバックアップの削除 CROSSCHECK 後の期限切れの Recovery Manager のバックップの削除 Recovery Manager のバックアップでの DELETE FORCE の使用 保存方針に基づいて不要になった Recovery Manager のバックアップの削除 KEEP UNTIL に指定した期限が切れたときの DELETE OBSOLETE の動作 メンテナンス操作に対する複数の Recovery Manager チャネルの使用 複数の Recovery Manager チャネルのメンテナンス コマンドへの割当て 複数のチャネルでの Recovery Manager のクロスチェックおよび削除方法 回のコマンドによるディスク チャネルおよびテープ チャネルのクロスチェック : 例 複数の Oracle Real Application Clusters ノードのクロスチェック : 例 回の DELETE コマンドによるディスク チャネルおよびテープ チャネルでの削除 : 例 複数のチャネルの解放 : 例 Recovery Manager を使用したデータベースの削除 バックアップ レコードの状態の変更 バックアップ状態のマーク付け 保存方針からの長期バックアップの除外 アーカイブ ログおよびユーザー管理コピーのカタログへの追加 アーカイブ ログおよびユーザー管理コピーのカタログへの追加 ユーザー管理データ ファイルのコピーのカタログへの追加 バックアップ ピースのカタログへの追加 ディスクの場所にあるすべてのファイルのカタログへの追加 フラッシュ リカバリ領域の内容のカタログへの追加 Recovery Manager レコードのカタログからの削除 Recovery Manager レコードのカタログからの削除 オペレーティング システムのユーティリティを使用して削除したファイルのレコードの削除 フラッシュ リカバリ領域のメンテナンス フラッシュ リカバリ領域が一杯になった場合の解決方法 フラッシュ リカバリ領域の位置の変更 ファイル作成時にインスタンスがクラッシュした場合のフラッシュ リカバリ領域の動作 A Recovery Manager ベースのディスクおよびテープのバックアップ計画の例 フラッシュ リカバリ領域へのバックアップ : 基本的な例... A-2 ディスク専用バックアップのスクリプト作成... A-2 少数のデータ ブロックが変更される場合のバックアップ スクリプト... A-2 viii

11 初期設定... A-2 毎日実行するスクリプト... A-3 ブロックが頻繁に変更される場合のバックアップ スクリプト... A-5 半数のブロックが毎週変更される場合のバックアップ スクリプト... A-6 初期設定... A-7 毎週実行するスクリプト... A-7 フラッシュ リカバリ領域およびテープへのバックアップ : 基本的な例... A-8 ディスクまたはテープにバックアップするための Recovery Manager 環境の構成... A-8 ディスクおよびテープへのバックアップ スクリプトの作成例... A-9 少数のデータ ブロックが変更される場合のバックアップ スクリプト... A-9 初期設定... A-9 毎日実行するスクリプト... A-9 多くブロックが変更される場合のバックアップ スクリプト... A-10 初期設定... A-11 毎週実行するスクリプト... A-11 毎日実行するスクリプト... A-11 半数のブロックが変更される場合のバックアップ スクリプト... A-11 初期設定... A-12 毎週実行するスクリプト... A-12 毎日実行するスクリプト... A-12 データベースのバックアップ用に十分なディスク領域がない場合のバックアップ スクリプト... A-14 毎週実行するスクリプト... A-14 毎日実行するスクリプト... A-15 用語集索引 ix

12 x

13 はじめに このマニュアルでは Oracle データベースのバックアップおよびリカバリの基本的な概念について説明します ここでは 次の項目について説明します 対象読者 ドキュメントのアクセシビリティについて 関連ドキュメント 表記規則 サポートおよびサービス xi

14 対象読者 このマニュアルは Recovery Manager を使用して Oracle データベース サーバーのバックアップおよびリカバリを実行するデータベース管理者を対象としています このマニュアルを使用するには 次の知識が必要です リレーショナル データベースの概念および基本的なデータベース管理 ( Oracle Database 概要 および Oracle Database 管理者ガイド を参照 ) Oracle データベースを実行するオペレーティング システム環境 第 1 章 バックアップおよびリカバリの概要 に示す概念は Recovery Manager を使用しない場合でも バックアップおよびリカバリを実行するすべてのユーザーに重要です 第 2 章以降では Recovery Manager を使用したバックアップ リカバリおよびメンテナンスの方法について説明します Recovery Manager を使用せずにバックアップおよびリカバリを管理する予定のユーザーは 第 1 章に示す概念を確認した後 さらなる概念について Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド の第 I 部を参照し ユーザー管理のバックアップおよびリカバリ方法について第 IV 部の章を参照してください ドキュメントのアクセシビリティについて オラクル社は 障害のあるお客様にもオラクル社の製品 サービスおよびサポート ドキュメントを簡単にご利用いただけることを目標としています オラクル社のドキュメントには ユーザーが障害支援技術を使用して情報を利用できる機能が組み込まれています HTML 形式のドキュメントで用意されており 障害のあるお客様が簡単にアクセスできるようにマークアップされています 標準規格は改善されつつあります オラクル社はドキュメントをすべてのお客様がご利用できるように 市場をリードする他の技術ベンダーと積極的に連携して技術的な問題に対応しています オラクル社のアクセシビリティについての詳細情報は Oracle Accessibility Program の Web サイト を参照してください ドキュメント内のサンプル コードのアクセシビリティについてスクリーン リーダーは ドキュメント内のサンプル コードを正確に読めない場合があります コード表記規則では閉じ括弧だけを行に記述する必要があります しかし JAWS は括弧だけの行を読まない場合があります 外部 Web サイトのドキュメントのアクセシビリティについてこのドキュメントにはオラクル社およびその関連会社が所有または管理しない Web サイトへのリンクが含まれている場合があります オラクル社およびその関連会社は それらの Web サイトのアクセシビリティに関しての評価や言及は行っておりません Oracle サポート サービスへの TTY アクセスアメリカ国内では Oracle サポート サービスへ 24 時間年中無休でテキスト電話 (TTY) アクセスが提供されています TTY サポートについては (800) にお電話ください 関連ドキュメント 詳細は 次の Oracle ドキュメントを参照してください Oracle Database バックアップおよびリカバリ クイック スタート Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド Oracle Database バックアップおよびリカバリ リファレンス Oracle Database SQL リファレンス Oracle Database ユーティリティ xii

15 このマニュアルの多くの例では Oracle をインストールするときにデフォルトでインストールされるシード データベースのサンプル スキーマを使用します 作成されるサンプル スキーマの詳細と ユーザーがサンプル スキーマを使用する方法については Oracle Database サンプル スキーマ を参照してください 表記規則 このマニュアルで使用されている表記規則は 次のとおりです 規則太字イタリック体固定幅フォント 意味 太字は 操作に関連付けられている Graphical User Interface あるいは本文中または用語集で定義されている用語を示します イタリック体は 特定の値を指定する必要があるプレースホルダや変数を示します 固定幅フォントは 段落内のコマンド URL コード例 画面上に表示されるテキストまたはユーザーが入力するテキストを示します サポートおよびサービス 次の各項に 各サービスに接続するための URL を記載します Oracle サポート サービスオラクル製品サポートの購入方法 および Oracle サポート サービスへの連絡方法の詳細は 次の URL を参照してください 製品マニュアル製品のマニュアルは 次の URL にあります 研修およびトレーニング研修に関する情報とスケジュールは 次の URL で入手できます その他の情報オラクル製品やサービスに関するその他の情報については 次の URL から参照してください 注意 : ドキュメント内に記載されている URL や参照ドキュメントには Oracle Corporation が提供する英語の情報も含まれています 日本語版の情報については 前述の URL を参照してください xiii

16 xiv

17 1 バックアップおよびリカバリの概要 この章では バックアップおよびリカバリの概念の全般的な概要と バックアップおよびリカバリに関連する Oracle データベースのファイルについて説明します また データベースのバックアップの作成 データ消失またはその他のエラーからのリカバリおよびバックアップのレコードのメンテナンスに使用可能なツールについても説明します この章では 次の項目について説明します バックアップおよびリカバリとは何か バックアップおよびリカバリ : 基本概念 データベースのリカバリ処理 : 基本概念 データ リカバリの方式 Recovery Manager を使用したバックアップおよびリカバリ 自動ディスク ベース バックアップおよびリカバリ : フラッシュ リカバリ領域 Oracle Flashback Technology: Point-in-Time リカバリの代替方法 障害とバックアップおよびリカバリ方法との対応付け バックアップおよびリカバリ方式のシステム要件 各バックアップ方式の機能の比較 バックアップおよびリカバリの概要 1-1

18 バックアップおよびリカバリとは何か バックアップおよびリカバリとは何か バックアップおよびリカバリとは一般に データ消失からデータベースを保護し なんらかのデータ消失が発生したときにはデータを再構築するための 様々な計画および手順を指します 物理バックアップと論理バックアップ バックアップとは データベースからコピーしたデータで そのデータを再構築するために使用できます バックアップは 物理バックアップ物理バックアップと論理バックアップ論理バックアップに分類されます 物理バックアップとは データベースの保存およびリカバリに使用する物理ファイルをバックアップしたもので データ ファイル 制御ファイル アーカイブ REDO ログなどを対象とします つまり 他の場所にデータベース情報を保存するファイルのコピーは すべて物理バックアップです 他の場所とは ディスクや オフラインの記憶域 ( テープなど ) を指します 論理バックアップには Oracle エクスポート ユーティリティを使用してデータベースからエクスポートし バイナリ ファイルに格納した論理データ ( 表 ストアド プロシージャなど ) が含まれます このデータは 対応する Oracle インポート ユーティリティを使用してデータベースに再インポートできます 参照 : Oracle のエクスポート ユーティリティおよびインポート ユーティリティを使用して論理バックアップを行う方法の詳細は Oracle Database ユーティリティ を参照してください 物理バックアップは 安全なバックアップおよびリカバリ計画の基礎になります 論理バックアップは 様々な状況で物理バックアップを補足するために役立ちますが 物理バックアップがなければデータ消失に十分に対処することはできません 特に指定がないかぎり このマニュアルでは バックアップという用語は物理バックアップを指します また データベースの一部または全体のバックアップバックアップとは 各種の物理バックアップをとることを意味します バックアップおよびリカバリに関するマニュアル セットでは 主に物理バックアップについて説明します バックアップからのリカバリが必要なエラーおよび障害 Oracle データベースの正常な稼働を停止させたり データベースの I/O 処理に影響を与える問題の種類はいくつかありますが 通常 DBA が介入してメディア リカバリを行う必要があるのは メディア障害およびユーザー エラーの 2 つの問題が発生した場合のみです 他の問題が発生した場合にも DBA はデータベースを再起動するか ( インスタンス障害が発生した場合 ) またはディスク領域を追加して割り当てる必要がありますが ( データ ファイルが一杯になるなどで 文障害が発生した場合 ) 通常こうした状況でデータ消失が発生することはなく バックアップからリカバリする必要はありません ユーザー エラーの理解 ユーザー エラーは アプリケーション ロジックのエラーまたは誤操作のため データベースのデータが誤って変更または削除された場合に発生します ユーザー エラーによるデータ消失とは 誤操作によって重要な表を削除したり 表の内容を削除または変更することを指します ユーザー トレーニングの実施や 慎重な権限管理によって ほとんどのユーザー エラーは回避できますが ユーザー エラーによるデータ消失が発生したときに 消失したデータをすみやかにリカバリできるかどうかは バックアップ計画にかかっています メディア障害の理解 メディア障害とは データベースの稼働に必要なディスク ファイルに対する読取りまたは書込みの障害で ヘッド クラッシュなどのディスクの物理的な問題によって発生します すべてのデータベース ファイルは メディア障害の影響を受けやすくなっています メディア障害からの適切なリカバリ方法は 障害の影響を受けたファイル および使用できるバックアップのタイプによって異なります 1-2 Oracle Database バックアップおよびリカバリ基礎

19 バックアップおよびリカバリ : 基本概念 Oracle のバックアップおよびリカバリ ソリューション : Recovery Manager およびユーザー管理のバックアップ 物理バックアップに基づくバックアップおよびリカバリを実行するために 次の 2 つのソリューションが提供されています Recovery Manager は コマンドライン クライアント インタフェースおよび Enterprise Manager GUI インタフェースを備えたツールで Oracle サーバー上で動作するセッションと一体になって 各種のバックアップおよびリカバリ操作を実行し バックアップに関する履歴データのリポジトリの管理を行います 従来のユーザー管理のバックアップとリカバリユーザー管理のバックアップとリカバリは ホスト オペレーティング システムのコマンドと SQL*Plus のバックアップおよびリカバリ関連機能の両方を使用して データベースを構成するファイルを直接管理する方法です オラクル社は いずれの方法も完全にサポートしており 関連するマニュアルを提供しています ただし データベースのバックアップおよびリカバリのソリューションには Recovery Manager の使用をお薦めします このツールは ユーザー管理の方法でも実行できるバックアップおよびリカバリをより容易に実行し 異なるホスト オペレーティング システム上でも同じバックアップ作業用インタフェースを備えていて ユーザー管理の方法では実行できないバックアップ手段を多数提供します バックアップおよびリカバリに関するマニュアル セットの大部分では Recovery Manager ベースのバックアップおよびリカバリ方法について説明します ユーザー管理のバックアップおよびリカバリ方法の詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド の後半の章を参照してください Recovery Manager またはユーザー管理の方法のいずれを使用した場合でも データ エクスポート ユーティリティを使用して作成したスキーマ オブジェクトの論理バックアップによって 物理バックアップを補足できます 論理バックアップとして保存したデータは 後でインポートして リストアおよびリカバリ後にそのデータを再作成するために使用できます ただし このマニュアルでは 論理バックアップの詳細は説明しません バックアップおよびリカバリ : 基本概念 データベースの物理構造と データベースのリカバリ処理でそれぞれが果たす役割によって ユーザー管理の方式および Recovery Manager を使用して実行できる バックアップおよびリカバリの形態が決まります データのリカバリで使用されるデータベースの物理構造 Oracle データベースを構成するファイルおよびその他の構造は データを格納し 障害が発生した場合にはデータを保護します この項では Oracle データベースを構成する物理構造と バックアップからデータベースを再構成する際のそれぞれの役割について説明します この項では次の項目を取り上げます データ ファイルおよびデータ ブロック REDO ログ UNDO セグメント 制御ファイル データ ファイルおよびデータ ブロック Oracle データベースは 表領域と呼ばれる 1 つ以上の論理記憶単位で構成されます Oracle データベース内の各表領域は データ ファイルと呼ばれる 1 つ以上のファイルで構成されます データ ファイルは データベースを実行しているホスト オペレーティング システムの配下にある物理ファイルです 最も単純な Oracle データベースは 1 つの表領域で構成され 1 つのデータ ファイルに格納されます バックアップおよびリカバリの概要 1-3

20 バックアップおよびリカバリ : 基本概念 データベースは データベースのデータ ファイル内の記憶域を データ ブロックと呼ばれる単位で管理します また データベースによって使用または割当て可能な記憶域の最小単位です 変更データまたは新規データは すぐにはデータ ファイルに書き込まれません 更新情報はメモリー内のバッファに蓄積されて 時間を置いてデータ ファイルに書き込まれます データベースが正常に停止されなかった場合 ( つまり オープンしているか インスタンス障害または SHUTDOWN ABORT によって異常終了した場合 ) 通常はメモリー内の変更はデータ ファイルにまだ書き込まれていません バックアップからリストアされたデータ ファイル あるいは一貫性のある停止一貫性のある停止によってクローズされていないデータ ファイルは 通常は最新の状態になっていません データベースのデータ ファイルのコピーは どのバックアップでも重要な部分です REDO ログ 参照 : データ ファイルおよびデータ ブロックの構造および内容の詳細は Oracle Database 概要 を参照してください REDO ログは データベースのデータ ファイルに対する変更をすべて記録します データベースのデータが変更されるたびに その変更はオンライン REDO ログに記録されてから データ ファイルに適用されます Oracle データベースには 2 つ以上のオンライン REDO ログ グループと 各グループに 1 つ以上のオンライン REDO ログ メンバー ( 変更を記録する個々の REDO ログ ファイル ) が必要です データベースでは 定期的にオンライン REDO ログ グループが切り替えられ 現行のオンライン REDO ログ内に変更が格納されます REDO ログにはデータ ファイルに対するすべての変更記録が格納されるため ある時点からのデータ ファイルのコピーと その時点以降の完全な REDO ログのセットが使用できる場合 データベースは REDO ログに記録された変更を再適用することで バックアップの時点から最後の ERDO ログの終了時点までの任意の時点でデータ ファイルの内容を再構築できます ただし これが可能なのは REDO ログが保持されている場合のみです このため REDO ログの保持は ほとんどのバックアップ計画において重要です 最初に REDO ログの保持は アーカイブアーカイブと呼ばれるプロセスを介して行われます データベースでは 現在使用していないオンライン REDO ログ グループをディスクにある 1 つ以上のアーカイブ場所 ( アーカイブ REDO ログ ) にコピーすることができます 個々のファイルをアーカイブ REDO ログ ファイルといいます アーカイブした REDO ログ ファイルは 長期間保存したり 将来のリカバリ作業で使用するために ディスクやテープ上の別の場所にバックアップできます アーカイブ REDO ログがない場合 データベースのバックアップおよびリカバリの方法は大幅に制限されます データベースをバックアップするには まずデータベースをオフラインにする必要があります また バックアップからデータベースをリストアする必要がある場合でも データベースで使用できるのはバックアップした時点での内容のみとなります データベースの状態を ある時点と別の時点のバックアップの間の時点の状態に再構築するには アーカイブ ログが必要です 参照 : オンライン REDO ログおよびアーカイブ REDO ログの詳細は Oracle Database 管理者ガイド を REDO ログ ファイルをアーカイブまたは廃棄した場合の影響の詳細は 2-7 ページの ARCHIVELOG および NOARCHIVELOG モードの決定 を参照してください 1-4 Oracle Database バックアップおよびリカバリ基礎

21 データベースのリカバリ処理 : 基本概念 制御ファイル 制御ファイルには データベースの物理構造とその状態に関する記録が格納されています 制御ファイルに格納される バックアップおよびリカバリに関連する主な情報は 次のとおりです データベース情報 (RESETLOGS SCN およびタイムスタンプ ) 表領域およびデータ ファイルのレコード ( ファイル名 データ ファイル チェックポイント 読取り / 書込みの状態 オフライン範囲 ) REDO スレッド ( 現行のオンライン REDO ログ ) に関する情報 ログ レコード ( ログ順序番号 各ログの SCN 範囲 ) 過去の Recovery Manager バックアップのレコード データ ファイルのブロック破損情報 データ ファイルのリカバリ処理の一部では データベース チェックポイント 現行のオンライン REDO ログ ファイルおよびデータ ファイルのデータ ファイル ヘッダーデータ ファイル ヘッダーのチェックポイントなどの 制御ファイル内のステータス情報が使用されます 制御ファイルを失うと データ消失からのリカバリは非常に困難になります 参照 : 制御ファイルの詳細は Oracle Database 概要 を参照してください UNDO セグメント 通常 データ ファイル内のデータを更新すると そのデータの変更前のイメージが UNDO セグメントに書き込まれます トランザクションがロールバックされると この UNDO 情報を使用して 元のデータ ファイルの内容がリストアされます リカバリの処理では UNDO 情報は データ ファイルのすべての変更が REDO ログからデータ ファイルに適用された直後に コミットされていないトランザクションの影響を元に戻すために使用されます データベースは UNDO が適用される前にオープンされます バックアップおよびリカバリ処理の中では UNDO セグメントに関与する必要も これを直接管理する必要もありません 参照 : UNDO セグメントの詳細は Oracle Database 概要 を参照してください データベースのリカバリ処理 : 基本概念 データベースの全体または一部の内容をバックアップから再構築する手順には 通常 次の 2 つの段階があります まず バックアップからデータ ファイルのコピーを取得します 次に アーカイブおよびオンライン REDO ログから バックアップ以降の変更をファイルに再適用して データベースをバックアップ以降の任意の SCN( 通常は現在 ) まで戻します データ ファイルまたは制御ファイルのバックアップからのリストアリストアとは テープ ディスクまたはその他のメディアのバックアップ場所からディスクへファイルを取り出して データベース サーバーがそのファイルを使用できるようにすることを指します データ ファイルのリカバリ ( またはデータ ファイルに対するリカバリの実行 ) とは そのデータ ファイルのリストアされたコピーを取得して そのコピーに対してデータベースの REDO ログに記録された変更を適用することを指します データベース全体のリカバリとは そのデータベースに含まれるデータ ファイルのそれぞれに対してリカバリを実行することを指します 図 1-1 に データベースにおける バックアップ リストアおよびリカバリの基本原則を示します Oracle データベースがサポートするデータ リカバリ処理の多くは この図に示す処理に変更を加えたものです バックアップおよびリカバリの概要 1-5

22 データ リカバリの方式 図 1-1 データベースのリストアおよびリカバリ SCN REDO REDO この例で データベースの全体バックアップ ( データ ファイルおよび制御ファイルのコピー ) を作成したときの SCN は 100 です データベースの稼動中に生成された REDO ログは SCN100 ~ 500 で発生したすべての変更を記録しています 稼動中に 一杯になったいくつかのログがアーカイブされます SCN500 で メディア障害によって データベースのデータ ファイルが消失しました データベースを SCN500 の トランザクションに一貫性がある状態に戻すには SCN100 で作成したバックアップからデータ ファイルをリストアし 次にアーカイブおよびオンライン REDO ログに記録されたトランザクションを適用して コミットされていないトランザクションを元に戻します データ リカバリの方式 前述の例では リストアおよびリカバリ処理の基本概念について説明しました この例を部分的に変更したいくつかの方式は バックアップおよびリカバリ作業のために重要なものです この項では次の項目を取り上げます データ ファイルのメディア リカバリ : データ ファイルのリストアと REDO の適用 完全 不完全および Point-in-Time リカバリ インスタンス障害後の自動リカバリ : クラッシュ リカバリ データ ファイルのメディア リカバリ : データ ファイルのリストアと REDO の適用 データ ファイルのメディア リカバリ ( 多くの場合 単にメディア リカバリメディア リカバリと呼ぶ ) は ユーザーが開始するデータ リカバリの最も基本的な方式です データ ファイルのメディア リカバリは 現行のデータ ファイルまたは SPFILE 制御ファイルの消失または破損からリカバリするときに使用します また OFFLINE NORMAL オプションを使用せずにオフライン 1-6 Oracle Database バックアップおよびリカバリ基礎

23 データ リカバリの方式 にしたために REDO ログには記録されていても 表領域のデータ ファイルには書き込まれなかった変更をリカバリするためにも使用できます データ ファイルのメディア リカバリは Recovery Manager またはユーザー管理のバックアップおよびリカバリの いずれの方法でも実行できます ( ユーザー管理のバックアップおよびリカバリでは 主にこの方式を実行します ) データ ファイルをバックアップからリストアする必要があるかどうかは 自動的には検出されません メディア リカバリの最初の手順では バックアップからデータ ファイルをコピーして手動でリストアします バックアップからデータ ファイルをリストアすると そのデータ ファイルが古いものであり メディア リカバリを実行する必要があることが データベースで自動的に検出されます 次のような状況では メディア リカバリを実行する必要があります データ ファイルのバックアップをリストアする場合 バックアップ制御ファイルをリストアする場合 ( すべてのデータ ファイルが現行のものである場合も含む ) OFFLINE NORMAL オプションを指定せずにデータ ファイルを ( 手動またはデータベースによって自動で ) オフラインにした場合 データ ファイルをメディア リカバリが可能な状態にするには 次のいずれかの条件を満たす必要があります そのデータ ファイルが属するデータベースをオープンしていないこと または データベースがオープンしている場合は リカバリするデータ ファイルがオフラインであること メディア リカバリが必要なデータ ファイルは メディア リカバリが完了するまではオンラインにできません オンライン データ ファイルのいずれかにメディア リカバリが必要なデータベースはオープンできません メディア リカバリの予想される期間は バックアップおよびリカバリ計画の一部として管理できます これは バックアップの頻度 パラレル リカバリ パラメータなどによって影響を受けます 完全 不完全および Point-in-Time リカバリ 完全リカバリとは コミットされたトランザクションによる変更を失うことなく データベースを最新の時点までリカバリすることです 通常 リカバリとは完全リカバリを指します しかし 場合によっては データベースを過去のある時点の状態に戻したいこともあります たとえば 表または表の内容の削除などのユーザー エラーの結果を元に戻したい場合には データベースを内容が削除される前の状態に戻す必要があります 不完全リカバリ不完全リカバリは Point-in-Time リカバリとも呼ばれ データベースを過去のターゲット SCN または時刻までリストアするための機能です Point-in-Time リカバリは ユーザー エラー 気付かぬうちに進行した論理的な破損などによって発生したデータ消失に対処する方法の 1 つです また Point-in-Time リカバリは リカバリを実行する際に リストアしたバックアップから リカバリのターゲット SCN までの間を埋めるアーカイブ ログがないことに気付いたときに実行できる唯一の方法です 必要なログがなければ その期間のデータ ファイルの更新を記録したものはありません 唯一できることは リストアされたバックアップの時点から 破損していないアーカイブ ログが残っているところまでデータベースをリカバリして 次に OPEN RESETLOGS を実行して消失したログ以降の変更をすべて廃棄することです ( アーカイブ ログがないことに気付いたときに データベースがまだ稼働していれば ただちに全体バックアップを実行する必要があります ) バックアップおよびリカバリの概要 1-7

24 データ リカバリの方式 注意 : データ消失の影響を受ける表領域が 1 つだけである場合には データベース全体のリカバリではなく 該当する表領域の Point-in-Time リカバリを実行することもできます 表領域の Point-in-Time リカバリ ( 略して TSPITR と呼ぶ ) は高度な手法です 詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください インスタンス障害後の自動リカバリ : クラッシュ リカバリ クラッシュ リカバリ処理は 特殊なリカバリの方式で クラッシュ後 ( または SHUTDOWN ABORT 後 ) 初めて Oracle データベース インスタンスを起動するときに実行されます クラッシュ リカバリは データ ファイルをトランザクションの一貫性がある状態に戻し インスタンス障害が発生した時点までのコミットされた変更をすべて維持することを目的とします クラッシュ リカバリと同様に データ ファイルのメディア リカバリは データベースの整合性を回復するために使用します ただし この 2 つの方式には 次に示すようないくつかの重要な違いがあります メディア リカバリは ユーザーが明示的に起動する必要があります データベースで 自動的にメディア リカバリが実行されることはありません メディア リカバリは バックアップからリストアしたデータ ファイルに必要な変更を適用しますが クラッシュ後に残ったオンライン データ ファイルには適用しません メディア リカバリでは オンライン ログだけでなくアーカイブ ログも使用して データ ファイルをバックアップした時点にさかのぼって変更を探す必要があります データ消失後に手動で実行するリカバリの方式とは異なり クラッシュ リカバリは インスタンス障害後にディスク上に残っているオンライン REDO ログ ファイルと最新のオンライン データ ファイルだけを使用します アーカイブ ログがクラッシュ リカバリで使用されることはなく データ ファイルがバックアップからリストアされることもありません データベースでは オンライン REDO ログ内の保留になっているすべての更新情報が そのデータベースのオンライン データ ファイルに適用されます そのため クラッシュ後にデータベースを再起動すると データ ファイルには障害が発生した時点までにコミットされた変更がすべて反映されます ( データベースのオープン後 クラッシュ発生時にコミットされていなかったトランザクションに関する変更はロールバックされています ) クラッシュ リカバリの継続時間は リカバリを必要とするインスタンスの数 最終チェックポイント取得後にクラッシュしたインスタンスの REDO スレッドで生成された REDO の量 およびユーザーによる構成が可能な要因 (REDO ログ ファイルの数およびサイズ チェックポイントの頻度 パラレル リカバリ設定など ) と相関関係があります パラメータをデータベース サーバーに設定することで クラッシュ リカバリの継続時間をチューニングできます また リカバリ時間を最適化するために チェックポイントをチューニングすることもできます 注意 : Real Application Clusters(RAC) データベースのクラッシュ リカバリは クラスタ内のすべてのインスタンスに障害が発生したときに実行されます インスタンス リカバリインスタンス リカバリに関する処理は 一部のインスタンスに障害が発生したときに実行されます 1-8 Oracle Database バックアップおよびリカバリ基礎

25 Recovery Manager を使用したバックアップおよびリカバリ Recovery Manager を使用したバックアップおよびリカバリ 前述したとおり Recovery Manager を使用すると ユーザー管理のバックアップおよびリカバリでは実行できない データのバックアップおよびリカバリ方式と機能を取り扱えます 特に注目すべき機能は 次のとおりです 増分バックアップは バックアップの容量をより小さくまとめ ( 変更されたブロックのみを格納し ) データ ファイルのメディア リカバリを高速化します( データ ファイルのメディア リカバリ中に適用する必要のある REDO の量を削減します ) ブロック メディア リカバリは 破損データ ブロックが少ないデータ ファイルを オフラインにすることも バックアップからリストアすることもなく修復します 未使用ブロックの圧縮は Recovery Manager がバックアップ時に未使用のデータ ファイル ブロックをスキップできます ( ただし 特定の場合 ) バイナリ圧縮は Oracle データベース サーバーに統合されている圧縮メカニズムを使用して バックアップのサイズを小さくします 暗号化バックアップは Oracle データベースに統合されている暗号化機能を使用して バックアップを暗号化された形式で格納します Recovery Manager と ユーザー管理のバックアップおよびリカバリの機能の違いについては 1-15 ページの 各バックアップ方式の機能の比較 を参照してください Recovery Manager を使用すると バックアップ計画に関連する管理作業も軽減できます Recovery Manager は バックアップ アーカイブ ログおよびそれ自体のアクティビティに関するメタデータの詳細な記録を保持しています これを Recovery Manager リポジトリと呼びます リストア操作では Recovery Manager でこの情報を使用することによって ほとんどの状況のリストアにおいてバックアップファイルを特定する手間をなくすことができます また このリポジトリ内の情報を使用して バックアップ処理のレポートを生成することもできます Recovery Manager リポジトリ情報の主な格納場所は 本番データベースの制御ファイルになります 独立したリカバリ カタログ (1 つ以上のデータベースの Recovery Manager リポジトリ情報を格納するスキーマ ) をリカバリ カタログ データベースリカバリ カタログ データベースに設定することもできます このマニュアルの以降の章では Recovery Manager を使用してバックアップおよびリカバリ計画を実装する方法について説明します Recovery Manager によるバックアップが可能なファイル Recovery Manager では 障害が発生した場合に効率的にリカバリするために必要なすべてのデータベース ファイルをバックアップできます Recovery Manager では 次のファイルのバックアップがサポートされています データ ファイル およびデータ ファイルのイメージ コピー 制御ファイル および制御ファイルのイメージ コピー アーカイブ REDO ログ 現行のサーバー パラメータ ファイル バックアップ ピース (Recovery Manager で作成された他のバックアップを含む ) 注意 : データベースの操作には その他のファイル ( ネットワーク構成ファイル パスワード ファイル Oracle ホームの内容など ) も必要ですが これらのファイルは Recovery Manager ではバックアップできません 同様に Oracle の一部の機能 ( 外部表や BFILE データ型など ) では ここで示したファイル以外のファイルにデータが格納されます Recovery Manager は これらのファイルをバックアップできません リストにないファイルについては Recovery Manager 以外の方法でバックアップしてください バックアップおよびリカバリの概要 1-9

26 Recovery Manager を使用したバックアップおよびリカバリ Recovery Manager のバックアップ先 : ディスクおよびメディア マネージャ Recovery Manager では ディスクおよびテープでのバックアップの作成と管理 最初にディスクで作成したバックアップのテープへのバックアップ およびディスクまたはテープにあるバックアップからのデータベース ファイルのリストアを実行できます テープ バックアップに使用されるデバイスは 多くの場合 SBT(System Backup to Tape) デバイスと呼ばれます Recovery Manager は メディア管理レイヤーまたはメディア マネージャと呼ばれるソフトウェアを使用して SBT デバイスと相互作用します Recovery Manager での Oracle データベースのバックアップのタイプ 物理バックアップの分類方法はいくつかあり バックアップを作成したときのデータベースの状態 データベースの具体的なバックアップ部分 および作成したバックアップの保存方法によって分類します 一貫性バックアップおよび非一貫性バックアップ 物理バックアップは 一貫性バックアップ一貫性バックアップと非一貫性バックアップ非一貫性バックアップに分類することもできます 一貫性バックアップは データベースに一貫性がある状態 つまり REDO ログ内のすべての変更がデータ ファイルに適用されているときに作成されたバックアップです 一貫性バックアップからリストアしたデータベースは メディア リカバリを実行することなく すぐにオープンできます ただし 一貫性バックアップは 一貫性のある状態で停止した後にのみ作成できます クラッシュの発生後 または SHUTDOWN ABORT の実行後には作成できません 可用性を高めるため Oracle データベースは データベースをオープンしたままで作成できる非一貫性バックアップを使用した場合でも 正常に動作するように設計されています ただし データベースを非一貫性バックアップからリストアした場合は メディア リカバリを実行して オンラインおよびアーカイブ REDO ログ内の保留になっているすべての更新情報をそのデータベースで適用できるようにしてから データベースを再度オープンする必要があります メディア リカバリにはアーカイブ ログが必要なため 非一貫性バックアップを使用するには データベースを ARCHIVELOG モードで実行する必要があります 全体バックアップおよび増分バックアップ 全体バックアップは データ ファイル全体のバックアップです 全体バックアップは Recovery Manager またはオペレーティング システム レベルのコピー コマンドを使用して作成できます 増分バックアップは データ ファイル内の変更されたデータ ブロックだけのコピーを作成するという考え方に基づいています リカバリでは バックアップで対処できる時間内に REDO を適用して個々のデータ ファイルを更新するかわりに 増分バックアップから変更されたブロック全体を抽出することで リカバリに要する時間を大幅に短縮できます 増分バックアップは Recovery Manager によってのみ作成できます 参照 : データ ファイルをバックアップする他の方法については 4-3 ページの Recovery Manager によるデータ ファイルの全体バックアップおよび増分バックアップ を参照してください イメージ コピー バックアップ セットおよびバックアップ ピース Recovery Manager を使用して作成した Oracle データベースのバックアップの結果は イメージ コピーまたはバックアップ セットのいずれかで出力できます イメージ コピーイメージ コピーは データベース ファイルと完全に同一のコピーです Recovery Manager を使用して イメージ コピーのバックアップを作成できます ただし 作成時に オペレーティング システム固有のファイル コピー ユーティリティでは実行できない内容の破損状況の確認が実行されます Recovery Manager では 作成されたイメージ コピーが Recovery Manager リポジトリに記録されるため データベースのリストア時に使用できます イメージ コピーは cp (UNIX の場合 ) COPY(Windows の場合 ) など オペレーティング システムのコマンドを使用しても作成できます 1-10 Oracle Database バックアップおよびリカバリ基礎

27 Oracle Flashback Technology: Point-in-Time リカバリの代替方法 注意 : Recovery Manager 以外でイメージ コピーを作成した場合 Recovery Manager でこれらのコピーを使用できるようにするには CATALOG コマンドを使用して これらのコピーを Recovery Manager リポジトリに記録する必要があります Recovery Manager を使用して バックアップ セットバックアップ セットと呼ばれる Recovery Manager 固有の形式でバックアップを格納することもできます バックアップ セットは バックアップ ピーバックアップ ピースと呼ばれるファイルの集合で 各バックアップ ピースには 1 つ以上のデータベース ファイルが含まれます Recovery Manager で実行するバックアップ作業で 1 つ以上のバックアップ セットを作成できます これらのバックアップ セットは Recovery Manager リポジトリに記録されます また バックアップ セットは Recovery Manager によって テープ ライブラリなどのメディア マネージャ デバイスにバックアップを書き込む場合に使用できる唯一の形式です バックアップ セットを作成して取り扱うには Recovery Manager を使用する必要があります 参照 : イメージ コピーおよびバックアップ セットの詳細は 4-2 ページの Recovery Manager バックアップの形式 : イメージ コピーおよびバックアップ セット を参照してください 自動ディスク ベース バックアップおよびリカバリ : フラッシュ リカバリ領域 異なるバックアップおよびリカバリ関連ファイルを作成するコンポーネントは 互いを認識しないか データの格納先になるファイル システムのサイズを知りません 自動ディスク ベース バックアップおよびリカバリを使用すると フラッシュ リカバリ領域を作成して バックアップ関連ファイルの管理を自動化できます ディスク上の場所と 記憶域の上限を選択し 保存方針を設定してそのバックアップ ファイルがリカバリに必要な期間を制御すると データベースによって バックアップに使用する記憶域 アーカイブ REDO ログ 同じ記憶域内にあるデータベースのその他のリカバリ関連ファイルが管理されるようになります 不要になったファイルは Recovery Manager が新しいファイル用の領域を要求したときに削除されます フラッシュ リカバリ領域を使用すると バックアップ関連ファイル用のディスク領域を手動で管理したり ファイルのタイプごとに使用する領域を調整する必要が最小限になります フラッシュ リカバリ領域を使用可能にして バックアップの管理を簡略化することをお薦めします Oracle Flashback Technology: Point-in-Time リカバリの代替方法 Oracle Flashback Technology では データベースの大部分をバックアップからリストアしたり Point-in-Time リカバリを実行せずに データの過去の状態を表示したり データを過去の任意の時点にリカバリすることができる 有効な代替機能が提供されます Oracle のフラッシュバック機能が使用可能なほとんどの環境では これらの機能はメディア リカバリよりも効率的で簡単です Oracle のほとんどのフラッシュバック機能は論理レベルで動作して データベース オブジェクトの表示および操作を行います 次に例を示します Oracle Flashback Query を使用すると 目標時点を指定してデータベースに対する問合せを実行し その時点での状態を示す結果を表示できます 表に対する誤った更新などの不要な変更からリカバリするには その変更が発生する前の目標時点を選択し 問合せを実行して消失または変更した行の内容を取得します Oracle Flashback Version Query を使用すると 指定した期間に 1 度でも表に存在したすべての行のすべてのバージョンを 表に更新が適用された状態で表示できます また 異なるバージョンの行のメタデータ ( そのバージョンを作成したトランザクションの開始時刻 終了時刻 操作 トランザクション ID など ) を取得できます この機能は 消失したデータの値のリカバリおよび問い合せた表への変更の監査の両方に使用できます バックアップおよびリカバリの概要 1-11

28 Oracle Flashback Technology: Point-in-Time リカバリの代替方法 Oracle Flashback Transaction Query を使用すると 1 つのトランザクションまたは一定期間内のすべてのトランザクションによる変更を表示できます Oracle Flashback Table を使用すると 表を過去の時点の状態に戻すことができます データベースがオンラインである間に表データをリストアし 指定した表に対する変更のみを取り消すことができます Oracle Flashback Drop を使用すると DROP TABLE 文の影響を無効にできます Oracle Flashback Table Oracle Flashback Query Oracle Flashback Transaction Query および Oracle Flashback Version Query は いずれも UNDO データ (Oracle データベースに対する各更新の影響および更新時に上書きされた値の記録 ) に依存します これらの UNDO レコードは 主に SQL 問合せに対する読取り一貫性の提供やトランザクションのロールバックなどのために使用され データを過去のある時点の状態に再構築したり 過去のある時点からのすべての変更を再構築するために必要な情報を含みます Oracle Flashback Drop は ごみ箱ごみ箱というメカニズムを使用して構築されます Oracle は ごみ箱を使用して 削除されたデータベース オブジェクトによって使用されていた領域に新しいデータを格納することが必要になるまで これらのデータベース オブジェクトを管理します 注意 : Oracle の論理レベルのフラッシュバック機能は Recovery Manager に依存していないため Recovery Manager をバックアップ計画で使用しているかどうかに関係なく使用できます 物理レベルでは Oracle Flashback Database を使用すると データベースの Point-in-Time リカバリより効率的で直接的なリカバリを実行できます 所有しているデータ ファイルの内容が不要な変更のみである場合 Oracle Flashback Database を使用して 現行のデータ ファイルを過去の時点の内容に戻すことができます 結果は Point-in-Time リカバリの結果とほぼ同じになりますが バックアップからデータ ファイルをリストアする必要がなく メディア リカバリと比較して 適用が必要な REDO が限られているため 一般的には より短時間でリカバリが行われます Oracle Flashback Database では フラッシュバック ログフラッシュバック ログを使用して データ ブロックの過去のバージョン およびアーカイブ REDO ログに含まれる情報の一部にアクセスします Oracle Flashback Database では データベースに対してフラッシュ リカバリ領域を構成する必要があります これは フラッシュバック ログを格納できるのはこの領域のみであるためです デフォルトでは フラッシュバック ロギングは有効ではありません フラッシュバック ログ用に使用される領域はデータベースによって自動的に管理され フラッシュ リカバリ領域内の他ファイルで必要となる領域に対して調整が行われます 注意 : Oracle Flashback Database は Recovery Manager と統合されており データベースのフラッシュバック時に必要なアーカイブ ログをバックアップから自動的に取得できます これは Recovery Manager を使用せずに SQL*Plus 内から使用することもできますが このモードで使用する場合は ユーザー自身ですべての必須アーカイブ ログをディスクで使用できるようにする必要があります フラッシュ リカバリ領域に割り当てられた領域が不十分である場合 フラッシュ ログが削除され バックアップおよびアーカイブ ログ ファイル用に領域が確保される場合があります 通常 データベースの Point-in-Time リカバリはデータベースのフラッシュバック操作と同じ結果をもたらし データベースを過去のある時点の内容に戻します 1-12 Oracle Database バックアップおよびリカバリ基礎

29 障害とバックアップおよびリカバリ方法との対応付け リストア ポイント Oracle データベースでは データベースのフラッシュバック機能 リストアおよびリカバリ機能とともに リストア ポイントリストア ポイントもサポートされています 通常のリストア ポイントは SCN に相当する別名で データベースの一部または全体をその時点に戻す必要が予測される場合に いつでも作成することができます Point-in-Time リカバリ Oracle Flashback Table および Oracle Flashback Database の操作のためにターゲット SCN を検索または記録する必要がないため 将来行うこれらの操作が簡単になります 保証付きリストア ポイントを作成すると Oracle Flashback Database を使用してデータベースをリストア ポイントの時点に確実に戻すことができます 参照 : 通常および保証付きリストア ポイントの使用については 5-7 ページの 通常のリストア ポイントと保証付きリストア ポイントの使用 を参照してください データをリカバリする際の Oracle のフラッシュバック機能の使用については 第 7 章 フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 を参照してください UNDO データおよび自動 UNDO 管理の詳細は Oracle Database 概要 および Oracle Database 管理者ガイド を参照してください Oracle Flashback Query Oracle Flashback Transaction Query および Oracle Flashback Version Query の詳細は Oracle Database アプリケーション管理者ガイド - 基礎編 を参照してください 障害とバックアップおよびリカバリ方法との対応付け データベースのバックアップおよびリカバリ計画を立てるときは 発生する可能性のあるエラーを予測して それらのエラーからリカバリするために必要なバックアップを準備する必要があります Oracle データベースの正常な稼働を停止させたり データベースの I/O 処理に影響を与える問題の種類はいくつかありますが 通常 DBA が介入してメディア リカバリを行う必要があるのは メディア障害およびユーザー エラーの 2 つの問題が発生した場合のみです インスタンス障害 ネットワーク障害 Oracle データベースのバックグラウンド プロセスの障害および文の実行による障害 ( たとえば データ ファイルの空き領域などのリソース不足による障害 ) が発生したときには DBA の介入が必要になる可能性があり データベース インスタンスのクラッシュにつながる可能性もありますが 通常はデータ消失が発生することはなく バックアップからのリカバリは必要ありません この項では次の項目を取り上げます メディア障害への対処 ユーザー エラーへの対処 メディア障害への対処 オンライン REDO ログ ファイルまたは制御ファイルにメディア障害が発生した後のデータベース稼働は 該当するファイルが推奨されたとおりに多重化多重化機能で保護されているかどうかによって異なります 多重化している場合は そのファイルの複数のコピーがシステム上に維持されています 多重化したファイルは それぞれ別のディスクに格納します ディスクが 多重化したオンライン REDO ログのコピーの 1 つを含むメディア障害の影響を受けた場合 データベースは通常 長時間の中断を伴わずに稼働を続行できます 多重化していないオンライン REDO ログが破損すると データベース稼働が停止し 場合によってはデータが完全に失われることがあります 多重化しているかどうかにかかわらず 制御ファイルが破損した場合にデータベースで破損ファイルの読取りまたは書込みが試行されると データベースの稼働は停止します このデータベースの稼働の停止は チェックポイントごと ログ スイッチごとなど 頻繁に発生します バックアップおよびリカバリの概要 1-13

30 障害とバックアップおよびリカバリ方法との対応付け メディア障害は 読取りエラー読取りエラーまたは書込みエラー書込みエラーのいずれかです 読取りエラーでは インスタンスでデータ ファイルの読取りができないため ファイルの検出 オープンまたは読取りができないことを示すエラーとともに オペレーティング システム エラーがアプリケーションに戻されます データベースは継続して実行されますが 読取りが失敗するたびにエラーが戻されます 次のチェックポイントで 通常のチェックポイント プロセスの一環としてデータベースによってファイル ヘッダーへの書込みが試行されると 書込みエラーが発生します データ ファイルの書込みエラーの影響は そのデータ ファイルが含まれる表領域によって左右されます インスタンスで システム表領域システム表領域のデータ ファイル UNDO 表領域 ( データベースが Oracle10g で推奨される自動 UNDO 管理モードの場合 ) またはアクティブなロールバック セグメントを含む表領域のデータ ファイル ( 手動 UNDO 管理モードの場合 ) に書き込めない場合は データベースによって エラーが発行され インスタンスが停止されます SYSTEM 表領域内のすべてのファイルと ロールバック セグメントを含むすべてのデータ ファイルは データベースを正しく稼働させるためにオンラインにしておく必要があります インスタンスで前述のデータ ファイル以外に書き込めない場合 その結果は データベースが ARCHIVELOG モードで稼働しているかどうかによって異なります ARCHIVELOG モードの場合 データベースでは データベース ライター トレース ファイルにエラーが記録され 影響を受けるデータ ファイルがオフラインになります ( このデータ ファイルを含む表領域内の他のデータ ファイルは すべてオンラインのままです ) 次に根本的な問題を解決して 影響を受けた表領域をリストアおよびリカバリします NOARCHIVELOG モードの場合 データベース ライター バックグラウンド プロセス DBWR は失敗し インスタンスに障害が発生します 必要な対処は 問題の原因によって異なります この問題が一時的なものである場合 ( ディスク コントローラの電源がオフになっていた場合など ) は 通常 オンライン REDO ログ ファイルを使用したクラッシュ リカバリが実行されます このような状況では インスタンスはメディア リカバリを行うことなく再起動できます ただし データ ファイルが破損した場合は データベース全体の一貫性バックアップをリストアする必要があります ユーザー エラーへの対処 通常 表の削除 表内の行の削除などのユーザー エラーには 次のいずれかの対処が必要です 適切なエクスポート ファイルが存在するか スタンバイ データベースでそのオブジェクトを使用できる場合は 削除したオブジェクトを再インポートする 1 つ以上の表領域の表領域の Point-in-Time リカバリ (TSPITR) を実行する 消失したデータの記録があれば そのデータを手動で再入力する データベースの Point-in-Time リカバリを使用して データベースを過去の状態に戻す Oracle データベースのいずれかのフラッシュバック機能を使用し 影響を受けたオブジェクトを過去の状態に戻して論理的な破損からリカバリする 使用できるリカバリ オプションは バックアップ計画と関係があります たとえば NOARCHIVELOG モードで実行している場合は Point-in-Time リカバリのオプションに制限があります 1-14 Oracle Database バックアップおよびリカバリ基礎

31 各バックアップ方式の機能の比較 参照 : データベース全体に対して Point-in-Time リカバリを実行する方法は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください 表領域に対して Point-in-Time リカバリを実行する方法は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください Oracle データベースのフラッシュバック機能を使用する方法は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください バックアップおよびリカバリ方式のシステム要件 バックアップおよびリカバリ ソリューションは データベース環境に適したものを選択します たとえば リリース 8.0 以上のデータベースのみを管理する場合は Recovery Manager を使用してバックアップおよびリカバリ要件を管理できます リリース 8.0 より前のデータベースは Recovery Manager 以外の方式で管理する必要があります 表 1-1 に データベースの様々なバックアップおよびリカバリ方式のバージョンとシステム要件を示します 表 1-1 バックアップ方式の種類と要件バックアップ方式種類 使用できるバージョン 要件 Recovery Manager (RMAN) オペレーティング システム 物理的 各バックアップ方式の機能の比較 Oracle バージョン 8.0 以上 サード パーティ製メディア マネージャ ( テープへのバックアップの場合のみ ) 物理的 全バージョン オペレーティング システムのバックアップ ユーティリティ ( 例 : UNIX の dd コマンド ) Export 論理的全バージョン該当せず 選択するバックアップおよびリカバリ ソリューションは システム要件によって限定される他 必要な機能によっても左右されます 表 1-2 に 各バックアップ方式の機能の比較を示します 表 1-2 各バックアップ方式の機能の比較機能 Recovery Manager ユーザー管理 Export クローズ状態のデータベースのバックアップ オープン状態のデータベースのバックアップ サポートしています インスタンスをマウントする必要があります サポートしています BEGIN/END BACKUP 文を使用する必要はありません サポートしています サポートしています BEGIN/END BACKUP 文を使用する必要があります サポートしていません 一貫性バックアップを生成するには ロールバック セグメントまたは UNDO セグメントが必要です 増分バックアップサポートしています サポートしていません サポートしていません 破損ブロックの検出 サポートしています 破損ブロックを識別して V$DATABASE_BLOCK_ CORRUPTION に記録します サポートしていません サポートしています エクスポート ログ内で 破損ブロックを特定します バックアップおよびリカバリの概要 1-15

32 各バックアップ方式の機能の比較 表 1-2 各バックアップ方式の機能の比較 ( 続き ) 機能 Recovery Manager ユーザー管理 Export バックアップ対象ファイルの自動記録 サポートしています バックアップ対象のすべてのファイル ( データベース全体または表領域 データ ファイル 制御ファイルのバックアップ ) の名前と位置を自動的に識別します サポートしていません バックアップ対象のファイルは 手動で指定する必要があります サポートしています 全体 ユーザー単位または表単位でバックアップを実行します リカバリ カタログ サポートしています バッサポートしていません クアップは Recovery DBA はバックアップの記録 Manager リポジトリに記録を自分で保持しておく必要されます このリポジトリがあります は 制御ファイルおよび任意でリカバリ カタログ データベースに含まれます サポートしていません メディア マネージャへのバックアップ 初期化パラメータ ファイルのバックアップ パスワード ファイルおよびネットワーク ファイルのバックアップ サポートしています メディア マネージャとインタフェースをとります Recovery Manager は プロキシ コピーもサポートしています これは メディア マネージャによるデータ転送を可能にする機能です サポートしています テープへのバックアップは手動で行うか あるいはメディア マネージャで制御します サポートしています サポートしています サポートしています サポートしていません サポートしていません サポートしています サポートしていません プラットフォームに依存しないバックアップ用言語 サポートしています サポートしていません サポートしています 1-16 Oracle Database バックアップおよびリカバリ基礎

33 2 バックアップおよびリカバリ計画 この章では 効果的なバックアップおよびリカバリ計画を立案するにあたっての 指針および考慮点について説明します この章では 次の項目について説明します バックアップ計画を決定するデータ リカバリ計画 データ リカバリ計画の立案 バックアップ計画の立案 データ リカバリ計画の検査 バックアップおよびリカバリ計画 2-1

34 バックアップ計画を決定するデータ リカバリ計画 バックアップ計画を決定するデータ リカバリ計画 バックアップ計画を決定するには まずデータ リカバリ要件およびデータ リカバリ計画を検討します データ リカバリのタイプごとに 特定のタイプのバックアップを実行する必要があります 障害には ユーザー エラーから データ ファイル ブロック破損 メディア障害 データ センターを完全に失うような状況まで 様々な種類があります データベースの正常な稼働をいかにすばやく回復できるかは 計画に含めるリストアおよびリカバリ方式の種類に関係します リストアおよびリカバリ方式によって バックアップの作成 保存および管理に使用する Oracle データベースの機能を含めて バックアップ計画の要件が決まります リカバリ計画を検討するときは 次の点を確認してください ディスクに障害が発生し データ ファイル REDO ログなどの一部のデータベース ファイルが破損した場合に 消失したファイルをどのようにリカバリしますか 2-5 ページの メディア障害対策の立案 : リストアおよびメディア リカバリ で説明するように データ ファイル 制御ファイルおよびオンライン REDO ログの消失に対処できるようにする必要があります アプリケーションのロジック エラーまたはユーザー エラーによって 1 つ以上の表または表領域から重要なデータが消失した場合に どのようにデータをリカバリできますか また エラー発生後のデータベースの更新情報はどうなりますか エラーの原因を特定し 再発を防止できますか 2-3 ページの ユーザー エラーへの対処方法の立案 : Point-in-Time リカバリおよびフラッシュバック機能 で説明するように データベース全体または 1 つ以上の表領域の Point-in-Time リカバリ データ インポート ユーティリティを使用した過去の論理エクスポートからのデータのインポート Oracle データベースのフラッシュバック機能などの方式を使用できます インスタンスのアラート ログが 1 つ以上の表に破損ブロックがあることを示している場合に この破損をどのように修復できますか 修復作業中に その表領域を使用可能な状態にしておく必要がありますか 2-5 ページの データ ファイル ブロック破損に対する対策の立案 : ブロック メディア リカバリ で説明するように このような状況では Recovery Manager の BLOCKRECOVER コマンドが役に立ちます また リカバリのトラブルシューティングには SQL*Plus の RECOVER... TEST コマンドを使用します データ センター全体が破壊された場合に 障害時リカバリを実行できますか バックアップが記録されたアーカイブ テープのみが残されたとします データベースをどのようにリカバリしますか そのリカバリには どれだけの時間がかかりますか あなたがデータベースをリカバリできないとき かわりの誰かがリカバリを実行できますか リカバリ作業は 十分に自動化されドキュメント化されていますか これらの要件に留意しながら バックアップおよびリカバリに関する機能を活用する方法を決定し 各機能をバックアップ計画の要件に合わせる方法を検討します 次に例を示します Recovery Manager を使用すると ほとんどのバックアップおよびリカバリ処理はユーザー管理のバックアップおよびリカバリに比べて簡略になります また ほとんどのバックアップ ファイルの管理を自動化できます これには リカバリの目的に合わなくなった場合の ディスクまたはテープからのバックアップおよびアーカイブ REDO ログの削除が含まれます バックアップ処理に関する詳細なレポートが提供され このレポートによって バックアップを使用してデータベースをリカバリできることを確認できます 最後に Recovery Manager を使用すると 増分バックアップなど ユーザー管理のバックアップとリカバリでは実行できない多くのリカバリ方式を使用できるようになります Oracle Flashback Database は メディア リカバリより迅速に データベースを過去の時点までリストアするために役立ちます ただし フラッシュバック ログの保存は 前もって決定しておく必要があります また フラッシュバック ログを保存するには フラッシュ リカバリ領域を構成する必要があります 可用性を重視する場合には データ ファイルのメディア リカバリより ブロック メディア リカバリを使用する方が適切である可能性があります バックアップおよびリカバリ計画が Recovery Manager ベースでない場合もブロック メディア リカバリを実行できますが Recovery Manager ベースにすると ブロック メディア リカバリをより簡単に迅速に実行できます 2-2 Oracle Database バックアップおよびリカバリ基礎

35 データ リカバリ計画の立案 リカバリ計画で使用する機能を決定したら 次の点を確認することで バックアップ計画を立案できます リカバリ関連ファイルは どこに どのように保存しますか フラッシュ リカバリ領域を使用しますか 冗長性を提供するために ASM ディスク グループを使用しますか バックアップは テープなどのオフライン記憶域に保存しますか またはディスクのみに保存しますか スケジュールしたバックアップは どのような間隔で実施しますか 各状況において どのような形式の物理バックアップを作成しますか 通常のスケジュール以外に どのような状況でデータベースのバックアップを作成しますか 状況によっては 確実にデータをリカバリするために スケジュールされていないバックアップを作成する必要があります たとえば OPEN RESETLOGS を実行した後や REDO ログには記録されない NOLOGGING 操作などデータベースを変更した後などです また 監査目的またはデータベース リカバリとは関連のない理由でバックアップを必要とする ビジネス上の要件もあります 必要なときに確実にデータベースのリカバリを行うには バックアップの有効性をどのように維持しますか バックアップの記録をどのように管理しますか リカバリ カタログで Recovery Manager を使用しますか 各種の障害に対処できる詳細なリカバリ計画がありますか 緊急事態が発生したとき DBA はこのリカバリ計画をどのように実行できますか 緊急事態が発生したときのリカバリ計画の実行を自動化するスクリプトを作成できますか Data Guard Real Application Clusters などの Oracle データベースの可用性テクノロジを適用して データベース障害の発生時に可用性を高めることができますか これらの可用性テクノロジの使用は バックアップおよびリカバリ計画にどのように影響しますか これらは 検討すべき項目の一部にすぎません 使用可能なリソース ( ハードウェア メディア スタッフ 予算など ) も判断要素となります データ リカバリ計画の立案 データ リカバリ計画には データベース障害への対処方法をできるだけ多く含める必要があります 効果的で効率のよい計画を立案するために重要なのは 障害の状態を想定し その障害の状態に役立つ Oracle データベースのリカバリ方式およびツールを対応付けて そのリカバリ方式をサポートするために必要なバックアップのタイプを組み込むことです 各障害の状態の解決に役立つリカバリ方式については 次の項を参照してください ユーザー エラーへの対処方法の立案 : Point-in-Time リカバリおよびフラッシュバック機能 メディア障害対策の立案 : リストアおよびメディア リカバリ データ ファイル ブロック破損に対する対策の立案 : ブロック メディア リカバリ ユーザー エラーへの対処方法の立案 : Point-in-Time リカバリおよびフラッシュバック機能 ユーザーまたはアプリケーションが 誤った更新 表の内容の削除 データベース オブジェクトの削除などの データベースに不要な変更を加える可能性があります 適切なバックアップおよびリカバリ計画は Oracle データベースの多くの機能を使用して データベースの可用性に及ぼす影響および DBA への負担を最小限に抑え データベースを目的の状態に戻します 予測する状況に基づいて データの消失に対処するために次の各オプションを組み込むことを検討した後 これらのオプションを使用できるようにデータベースを設定します バックアップおよびリカバリ計画 2-3

36 データ リカバリ計画の立案 Oracle Flashback Database Oracle Flashback Database を使用すると データ ファイルの以前のコピーをバックアップからリストアせずに データベース全体を過去のある時点の状態に戻すことができます ただし これは前もってデータベースのフラッシュバック ロギングを有効にしている場合にかぎります フラッシュバック ロギングを有効にして 使用可能なフラッシュバック ログが許容する範囲内で過去の任意の SCN に戻せるようにしたり またはデータベースの大規模な更新前など 特定の SCN で保証付きリストア ポイントを作成し Oracle Flashback Database を使用してデータベースを特定の時点の状態に確実に戻せるようにすることができます データベースのフラッシュバック ロギング用または保証付きリストア ポイント用にフラッシュ リカバリ領域を構成しておく必要があります 通常のリストア ポイントと保証付きリストア ポイントの作成 前述のとおり 保証付きリストア ポイントでは Oracle Flashback Database を使用して確実にデータベースを以前の特定の時点に戻すことが可能です 通常のリストア ポイントでは データの保護は行われませんが便利です これは 通常のリストア ポイントを作成することで Point-in-Time リカバリまたは Oracle Flashback Table を使用したリカバリの操作を行う前にデータベースの SCN を記録する必要がなくなったり 適切な SCN を特定する操作を行った後に調査する必要がなくなるためです 通常のリストア ポイントを使用するには特別な設定は必要ありませんが リストア ポイントが必要になる前に作成を計画する必要があります データベースの Point-in-Time リカバリ Point-in-Time リカバリを実行すると 1 つの表領域またはデータベース全体を エラーが発生する前の状態に戻すことができます いずれの場合も エラーが発生する前の状態のバックアップに加えて バックアップ時からエラー発生時までの REDO ログが必要です 論理バックアップからの消失したオブジェクトのインポート 影響を受けた表の内容をエクスポートして論理バックアップを実行した場合 そのデータを再び表にインポートできることがあります この方式は データの論理バックアップを定期的にエクスポートすることと エクスポート間での変更は重要でないことが前提となります 注意 : Oracle のフラッシュバック テクノロジは 様々な状況でのメディア リカバリにおいて 高速かつ確実な手段を提供します Oracle Flashback Database は メディア リカバリに類似した物理レベルのリカバリ メカニズムです ただし 通常 メディア リカバリよりも高速で バックアップからのデータのリストアを必要としません Oracle Flashback Table および Oracle Flashback Drop は論理レベルで動作し DROP TABLE 文による処理など 表に対する不要な変更を元に戻します Oracle Flashback Query および Oracle Flashback Version Query は 表の過去の内容を参照したり 論理的な破壊によって データベースにいつ どのような影響があったかを調べるのに有効です これらの機能の詳細は 第 7 章 フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 を参照してください このマニュアルでは これらの機能についての有効な情報および参照先を示しています これらの機能は非常に有効であり また一部高度な計画が必要になるため バックアップおよびリカバリ計画を作成する前にこれらの機能についてよく理解しておいてください 2-4 Oracle Database バックアップおよびリカバリ基礎

37 データ リカバリ計画の立案 メディア障害対策の立案 : リストアおよびメディア リカバリ メディア障害は データベースの外部の問題によって データベースの操作中に Oracle のファイル読取りまたは書込みが妨げられた場合に発生します 通常 メディア障害には ヘッド クラッシュ データベース ファイルの上書き 削除 破損などの 物理的な障害が含まれます メディア障害は ユーザー エラーまたはアプリケーション エラーほど一般的ではありませんが バックアップおよびリカバリ計画では メディア障害への対策を準備しておく必要があります メディア障害のタイプによって 使用するリカバリ方式が決まります たとえば 破損データ ファイルのリカバリ方法と 消失した制御ファイルのリカバリ方法は異なります 例 : オンライン REDO ログのリカバリ オンライン ログ グループの全メンバーの消失からリカバリする方法は 次のように多数の要因によって異なります データベースの状態 ( オープン クラッシュ 一貫性のあるクローズなど ) 消失した REDO ログ グループが現行のものかどうか 消失した REDO ログ グループがアーカイブされているかどうか 次に例を示します 現行のグループが消失し データベースが一貫性のある状態でクローズされていない場合 ( オープン状態またはクラッシュした場合 ) は 古いバックアップをリストアし Point-in-Time リカバリを実行してから OPEN RESETLOGS を使用してオープンする必要があります 消失したログに含まれていたトランザクションはすべて失われます OPEN RESETLOGS を実行した後は データベースの新規の全体バックアップを即時に行う必要があります OPEN RESETLOGS を実行する前のバックアップは ログが消失しているため 以降のリカバリには使用できません 現行の REDO ログ グループが消失しても データベースが一貫性のある状態でクローズされている場合は トランザクションを失うことなく OPEN RESETLOGS を実行できます ただし データベースの新規の全体バックアップを行う必要があります OPEN RESETLOGS を実行する前のバックアップは ログが消失しているため 以降のリカバリには使用できません 現行以外の REDO ログ グループが消失した場合は ALTER DATABASE CLEAR LOGFILE 文を使用してグループ内のすべてのメンバーを再作成できます トランザクションは消失しません 消失した REDO ログ グループが消失前にアーカイブされていた場合は これ以上の操作は必要ありません ただし データベースの新規の全体バックアップを即時に行う必要があります ログが消失する前のバックアップは ログが消失しているため 以降のリカバリには使用できません データ ファイル ブロック破損に対する対策の立案 : ブロック メディア リカバリ 1 つ以上のデータ ファイル内の少数のブロックが破損した場合 それらのファイルをバックアップからリストアして完全なメディア リカバリを実行するかわりに ブロック メディア リカバリを使用できます Recovery Manager の BLOCKRECOVER コマンドを使用すると データベースをオープンし 破損データ ファイルがオンラインのときに 指定したデータ ブロックをリストアおよびリカバリできます 参照 : Recovery Manager によるブロック メディア リカバリの実行方法は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください バックアップおよびリカバリ計画 2-5

38 バックアップ計画の立案 バックアップ計画の立案 冗長性セットの保護 立案したデータ リカバリ計画は バックアップ計画の立案の基礎となります ここでは データベースのバックアップを実行する時期 データベース内のバックアップが必要な部分 Oracle が提供するバックアップ用のツール および確実性を高めバックアップおよびリカバリを簡易にするためのデータベースの構成方法を決定するために役立つ 一般的なガイドラインについて説明します 計画の詳細は コスト リソース 要員 その他の要因について リストア計画の要件に合わせて調整する必要があります Oracle データベースを障害からリカバリする際に必要なファイルである データ ファイル 制御ファイル オンライン REDO ログをまとめて冗長性セットと呼びます 冗長性セットに含まれるものは次のとおりです 制御ファイルおよびすべてのデータ ファイルの最終バックアップ 最終バックアップ後に生成された全アーカイブ REDO ログ Oracle データベースの多重化機能とオペレーティング システムのミラー化機能のいずれか またはその両方で生成した現行の制御ファイルおよびオンライン REDO ログ ファイルの複製 サーバー パラメータ ファイル tnsnames.ora listener.ora などの構成ファイルのコピー 注意 : 冗長性セットは データベースのデータ ファイル オンライン ログおよび制御ファイルが含まれているディスクには格納しないでください 同じディスクに格納すると ディスクはデータベースにおけるシングル ポイント障害となります このディスクに障害が発生した場合は コミット済のトランザクションが失われます このため 最小限の実働レベルのデータベースでも少なくとも 2 つのディスク ドライブが必要で 一方は冗長性セットのファイル保存に もう一方はデータベース ファイルの保存に使用します 冗長性セットとプライマリ ファイルは 別々のボリューム 別々のファイル システム 別々の RAID デバイスなど 可能なかぎり様々な方法で分離して保管することをお薦めします 最も簡易な冗長性セットの管理方法は フラッシュ リカバリ領域を使用して 使用中のファイルのセットとは別のデバイス上に置くことです ただし フラッシュ リカバリ領域の使用の有無にかかわらず 次の事例に従うことをお薦めします オンライン REDO ログ ファイルおよび現行の制御ファイルは データベース レベルで多重化します ( たとえば オンライン ログを 2 つ以上の保存先に書き込むようにデータベースを構成して オペレーティング システム レベルまたはハードウェア レベルの冗長性ではなく 各書込みがデータベースの個別の操作として実行されるようにします ) データベース レベルで多重化すると I/O 障害や書込みの消失が発生しても コピーのいずれか 1 つが破損するのみです 多重化されたファイルは 異なるディスク コントローラにマウントされた 別のディスクに保存することをお薦めします フラッシュ リカバリ領域は これらのファイルの 1 つをコピーするために最適な場所です オンライン REDO ログおよび現行の制御ファイルは オペレーティング システム レベルまたはハードウェア レベルでミラー化することもできますが これはデータベース レベルの多重化の代替手段にはなりません ARCHIVELOG モードで稼働している場合は REDO ログを複数の場所にアーカイブします 異なるディスクにアーカイブすることをお薦めします フラッシュ リカバリ領域を使用している場合は これをアーカイブ先の 1 つとして使用します 制御ファイルには オペレーティング システムまたはハードウェアのミラー化を使用します データベース レベルで多重化された制御ファイルのすべてのコピーは 常に使用 2-6 Oracle Database バックアップおよびリカバリ基礎

39 バックアップ計画の立案 可能にする必要があります そうしないと インスタンスのクラッシュが発生します 制御ファイルをオペレーティング システムまたはハードウェアによってミラー化している場合 ディスク障害が発生してオペレーティング システム レベルでミラー化された制御ファイルの 1 つが使用できなくなっても データベースは稼働を継続できます 単純なディスク障害にメディア リカバリを実行することを避けるため プライマリ データ ファイルではオペレーティング システムまたはハードウェアのミラー化機能の使用をお薦めします 最新のバックアップを含む冗長性セット全体の 1 つ以上のコピーを ディスクに保存します フラッシュ リカバリ領域は 冗長性セットを保存するための最適な場所です ターゲット データベースを RAID デバイスに格納する場合は その RAID デバイスとは別のディスクのセットに冗長性セットを格納してください 冗長性セットをテープに格納する場合は テープ障害の危険性への対策として データの 2 つ以上のコピーを保存します また 同じデータのバックアップを複数作成する場合は 異なる時点でのバックアップをお薦めします このようにすると データベースが破損していたときに バックアップが 1 つ作成されたり ミラーの分割が行われた場合でも データベースが破損していなかった時点からのバックアップを確保できます フラッシュ リカバリ領域の使用の有無の決定 ディスク バックアップおよびアーカイブ REDO ログを含む できるだけ多くのバックアップおよびリカバリ関連ファイルを格納するために フラッシュ リカバリ領域を使用することをお薦めします Oracle データベースのバックアップおよびリカバリ機能 (Oracle Flashback Database 保証付きリストア ポイントなど ) には フラッシュ リカバリ領域を使用する必要があるものがあります ただし これらの機能が使用するフラッシュ リカバリ領域を確保していても この領域を使用してすべてのリカバリ関連ファイルを格納する必要はありません フラッシュ リカバリ領域を使用する必要がない場合でも フラッシュ リカバリ領域にはディスク上のその他のバックアップ記憶域の方式よりもメリットがあります フラッシュ リカバリ領域からテープに移動したバックアップは その他の必須ファイル用の領域が必要になるまでディスク上に残るため テープからバックアップをリストアする必要性が少なくなります 同時に リカバリ可能性の目的に合わなくなった不要なファイル およびテープにバックアップされているファイルは削除対象となり 領域が不足した際に削除されます DBA が古いバックアップを手動で削除する必要はなくなり DBA が誤って冗長性セット ファイルを削除する可能性も低くなります 参照 : フラッシュ リカバリ領域の使用およびメリットについては 3-13 ページの Recovery Manager 用のフラッシュ リカバリ領域の設定 を参照してください ARCHIVELOG および NOARCHIVELOG モードの決定 データベースの REDO ログは そのデータベースのデータ ファイルに対する変更の完全な記録を提供します ( ダイレクト パス ロードなどの 一部の例外はあります ) データベースは ARCHIVELOG モードまたは NOARCHIVELOG モードのいずれかで稼働します ARCHIVELOG モードでは 使用済のオンライン REDO ログ グループは 1 つ以上のアーカイブ先にコピーされた後に再利用できるようになります REDO ログをアーカイブすると そのログに保存されたすべてのトランザクションが保持されるので 後でリカバリ操作に使用できます NOARCHIVELOG モードでは オンライン REDO ログ グループは ログが再利用されるときに単純に上書きされます この REDO ログ グループに保存されたトランザクションに関する情報は すべて消失します バックアップおよびリカバリ計画 2-7

40 バックアップ計画の立案 NOARCHIVELOG モードでの稼働の影響 データベースを NOARCHIVELOG モードで稼働することは バックアップおよびリカバリ計画に対する厳しい制約になります データベースのオンライン バックアップを実行できません NOARCHIVELOG モードでバックアップを取るには データベースを正常に停止しておく必要があります アーカイブ REDO ログを必要とするデータ リカバリ方式は使用できません 使用できない方式には 1-6 ページの データ リカバリの方式 で説明する完全リカバリおよび Point-in-Time メディア リカバリや 個々の表領域の Point-in-Time リカバリ Oracle Flashback Database などのさらに高度なリカバリ方式があります ( Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照 ) NOARCHIVELOG モードでデータベースを稼働していて ディスク障害によって破損したデータ ファイルをリカバリする必要がある場合には 主に次の 2 つのリカバリ方式で対処します 影響を受けたファイル内にエクステントのあるオブジェクトをすべて削除し 次にファイルを削除します データベースの残りの部分は使用できますが 影響を受けたファイル内のデータはすべて消失します 最新のバックアップからデータベース全体をリストアして バックアップ以降のデータベースの変更は失います ( バックアップ以降の変更をリカバリするには メディア リカバリを実行する必要がありますが これにはアーカイブ REDO ログが必要です ) ARCHIVELOG モードでの稼働の影響 データが消失した後 より柔軟なリカバリ オプション ( データベースや一部の表領域の Point-in-Time リカバリなど ) を使用できるため ほとんどの場合は NOARCHIVELOG モードでの稼働より ARCHIVELOG モードでの稼働をお薦めします ただし ARCHIVELOG モードで稼働すると 次のコストがかかります アーカイブ先 ( アーカイブ REDO ログを格納するディスク上の場所 ) の領域を確保する必要があります 更新数が多いと データベース内のアーカイブ先の領域は非常に大きくなる可能性があります 保存したアーカイブ REDO ログを管理する必要があります アーカイブ REDO ログが使用するディスク領域を制限するため 長期間の保存にはアーカイブ REDO ログをテープに移します リカバリ可能性の目的に合わなくなった古いログは削除します (Recovery Manager はアーカイブ REDO ログの管理のほとんどを自動化します すべてのアーカイブ REDO ログの保存場所および内容を記録し アーカイブ ログのテープへの移動を簡易にし リカバリ可能性の目的に合わなくなった REDO ログを削除します ) パフォーマンスのオーバーヘッドの一部は 一杯になったオンライン REDO ログをアーカイブ先にコピーする バックグラウンド プロセス ARC0 ~ ARCn に関連するものです パフォーマンスが要求される場合や ディスク領域の制限が厳しい場合に リカバリ オプションに制約があっても NOARCHIVELOG モードで稼働する方が適切な場合があります Oracle のフラッシュバック機能とリストア ポイントの使用の決定 Oracle のフラッシュバック機能を使用すると データベースでの不要な変更による影響を修復する場合に データベースの可用性が向上します 論理レベルのフラッシュバック機能を使用すると 影響を受けていないオブジェクトを使用可能な状態のままにすることができ Oracle Flashback Database を使用すると Point-in-Time リカバリよりもデータベース全体のリカバリ時間を短くすることができます Oracle の論理レベルのフラッシュバック機能を利用する場合は データベースでどのように UNDO データが管理されているかを考慮する必要があります UNDO データおよび自動 UNDO 管理の詳細は Oracle Database 概要 および Oracle Database 管理者ガイド を参照してください Oracle Flashback Database または保証付きリストア ポイントを計画に組み込む場合は フラッシュ リカバリ領域を有効にするとともに 適切な時点で保証付きリストア ポイントを作成するか またはフラッシュバック ロギングを構成する必要があります これらの機能が 2-8 Oracle Database バックアップおよびリカバリ基礎

41 バックアップ計画の立案 データ保護計画で果たす役割と これらの機能を個別または同時に使用するための要件については 第 5 章 リストア ポイントおよび Oracle Flashback Database を使用したデータ保護 を参照してください バックアップ保存方針の選択 バックアップ保存方針とは リカバリおよびその他の要件を満たすために ( ディスク上またはその他のバックアップ メディアのいずれかに ) 残す必要のあるバックアップを判断するための規則です バックアップ保存方針は 冗長性冗長性またはリカバリ期間リカバリ期間に基づいて設定できます 冗長性ベースの保存方針には 数値 n を指定します これによって データベース内の各ファイルのバックアップが 常に n 種類以上保持されるようになります リカバリ期間ベースの保存方針では 過去の期間 (1 週間 1 か月など ) を指定します 指定した期間内の任意の時点までの Point-in-Time リカバリを実行できるように 必要なすべてのバックアップが保持されます バックアップ保存方針に合わなくなったバックアップを 不要バックアップ不要バックアップと呼びます Recovery Manager によるバックアップ保存方針の実装 Recovery Manager は バックアップ保存方針の実装を自動化します これには 次のコマンドを使用します CONFIGURE RETENTION POLICY コマンドを使用すると すべてのデータベース ファイルにデフォルトで適用する保存方針を設定できます REPORT OBSOLETE コマンドを使用すると 現在ディスク上にある 保存方針に合わなくなった不要バックアップの一覧を表示できます また パラメータを指定して どのファイルが別のバックアップ保存方針に合わなくなったかを参照することもできます DELETE OBSOLETE コマンドは REPORT OBSOLETE で不要と報告されたファイルを削除します CHANGE... KEEP コマンドを使用すると アーカイブ用に保存されている長期バックアップなど 特定のバックアップに対して個別の保存方針を設定できます 指定したバックアップを任意の時間まで保存することも または永続的に保存することも可能です CHANGE... NOKEEP コマンドを使用すると 以前 CHANGE... KEEP によって保護されたバックアップに対して保存方針を適用できます バックアップの保存にフラッシュ リカバリ領域を使用すると 新しいバックアップ アーカイブ ログおよびその他のファイル用のディスク領域が不足したときに データベースが自動的に不要バックアップを削除します バックアップをフラッシュ リカバリ領域の外部のディスクまたはテープ上に格納する場合は 定期的に DELETE OBSOLETE コマンドを実行して不要なバックアップを削除する必要があります リカバリ期間ベースのバックアップ保存方針 リカバリ期間ベースの保存方針を使用すると 指定した日数までは 過去の任意の時点への Point-in-Time リカバリを実行できることが保証されます 保存方針に設定された データベースをリカバリできる最も古い時点を リカバリ可能ポイントリカバリ可能ポイントと呼びます リカバリ可能ポイントまでのリカバリまたは Point-in-Time リカバリに必要なすべてのバックアップが 保持されます ビジネス上の要件で 指定期間内に検出されたデータベースのすべての論理破損が修復されるように要求されている場合 リカバリ期間ベースの保存方針を使用します リカバリ期間をその期間に設定します 通常 リカバリ期間ベースの保存方針を満たすには リカバリ期間の開始時点より古いバックアップを保持する必要があることに注意してください リカバリ期間の開始時点までの Point-in-Time リカバリでは この古いバックアップからリストアした後で バックアップ作成時とリカバリ可能ポイント間のすべての変更を適用します たとえば リカバリ期間を 3 日間に設定するには 次のコマンドを実行します RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS; バックアップおよびリカバリ計画 2-9

42 バックアップ計画の立案 データベースの最後の全体バックアップを作成したのが 6 日前だとすると Recovery Manager は 6 日前の古いバックアップ データベースをリカバリ期間の開始時点である 3 日前までロールフォワードするために必要なすべての REDO ログと さらにデータベースを 3 日間のリカバリ期間のすべての時点までリカバリするために必要なバックアップおよび REDO ログを保持しています リカバリ期間ベースのバックアップ保存方針は 最も確実なデータのリカバリ可能性を提供します この方法の欠点は ディスク領域の計画をより慎重に検討する必要があることです これは リカバリ期間を保証するために保持する必要のあるデータ ファイルのバックアップおよびアーカイブ ログがいくつ作成されるかわからないためです 冗長性ベースのバックアップ保存方針 冗長性ベースのバックアップ保存方針は 現在ディスク上にあるバックアップの数に基づいて バックアップが不要かどうかを判断します たとえば 冗長性レベルを 3 に設定するには 次のコマンドを実行します RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3; この場合 Recovery Manager はデータベース ファイルごとに 3 つのバックアップを保持し 保存されたすべてのデータ ファイルをリカバリするために必要なすべての REDO ログを現時点の状態までバックアップします 古いバックアップは不要とみなされます たとえば データ ファイルを月曜日から毎日バックアップするとします 木曜日にデータ ファイルの 4 つ目のバックアップを作成します 火曜日 水曜日 木曜日からのバックアップがあるため 月曜日からのバックアップは不要となります 金曜日には 水曜日 木曜日 金曜日からのバックアップがあるため 火曜日からのバックアップは不要となります 古いバックアップのアーカイブ データ ファイルおよびアーカイブ ログの古いバックアップを保存する理由はいくつかあります データ ファイルおよびアーカイブ ログの古いバックアップは 最新のバックアップより以前の時点までの Point-in-Time リカバリを実行するために必要です 最新のバックアップが破損した場合でも 古いバックアップとそのバックアップ以降のアーカイブ ログの完全なセットを使用して データベースをリカバリできます アーカイブ用にデータベースのコピーを保存する場合があります 現在のリカバリ可能ポイントより前の時点をターゲットとする Point-in-Time リカバリを実行するには ターゲットとする時点より前に完了したデータベースのバックアップと バックアップの開始からターゲットとする時点までに作成されたすべてのアーカイブ ログが必要です たとえば 2 月 1 日 (SCN 10000) および 2 月 14 日の午前 1 時 (SCN 20000) にバックアップを開始してデータベースの全体バックアップを作成し 2 月 28 日の時点で Point-in-Time リカバリを実行して 2 月 7 日午前 9 時 (SCN 13500) の状態のデータベースに戻すことを決定した場合は 2 月 1 日のバックアップと バックアップ開始時 (SCN 10000) から 2 月 7 日午前 9 時 (SCN 13500) までの変更を含むすべての REDO ログが必要になります バックアップ頻度の決定 リカバリ計画においては 頻繁なバックアップが重要です バックアップの頻度は データベースの次のような変更の割合または頻度に基づいて決定します 表の追加および削除 既存の表における行の追加および削除 表におけるデータの更新 データベースを更新する頻度が高いほど データベースのバックアップをより頻繁に実行する必要があります データベースを毎週バックアップする場合の例は A-5 ページの ブロックが頻繁に変更される場合のバックアップ スクリプト を参照してください 2-10 Oracle Database バックアップおよびリカバリ基礎

43 バックアップ計画の立案 データベースの更新の頻度が比較的低い場合は データベース全体のバックアップの頻度も低くして 増分バックアップで補足することができます ( 変更されたブロックがわずかなので サイズがより小さくなります ) 単一のデータベース全体のバックアップに基づいてバックアップ計画を立てる方法の例は A-9 ページの 少数のデータ ブロックが変更される場合のバックアップ スクリプト を参照してください 構造の変更前と後のバックアップの実行 通常のバックアップ スケジュールに関係なく データベースのバックアップを作成する必要がある場合があります 次に示すような構造上の変更をする場合は 変更の直前および変更完了の直後に データベースの該当部分のバックアップを作成してください 表領域の作成または削除 既存の表領域内でのデータ ファイルの追加または名前の変更 オンライン REDO ログ グループまたはオンライン REDO ログ メンバーの追加 名前の変更または削除 データベースを NOARCHIVE モードで稼働している場合は このような変更を行った後 データベースを停止して 一貫性のあるデータベース全体のバックアップを実行する必要があります ARCHIVELOG モードで稼動している場合は このような変更を行った後 Recovery Manager の BACKUP CONTROLFILE コマンドまたは SQL の ALTER DATABASE BACKUP CONTROLFILE 文のいずれかを使用して 制御ファイルのバックアップを作成する必要があります 頻繁に更新される表領域のバックアップのスケジューリング ARCHIVELOG モードで稼働している場合は 個々の表領域のバックアップを作成することも 1 つのデータ ファイルのみのバックアップを作成することもできます SYSTEM 表領域および自動 UNDO 表領域のように データベースで更新回数が多い 1 つ以上の表領域に対してこの操作を実行できます よく使用されるデータ ファイルをより頻繁にバックアップすることで リカバリに要する時間を短縮できる場合があります ほとんどの更新がわずかな表領域に限定されているデータベースがあるとします 毎週日曜日にデータベースの全体バックアップを行うとすると 金曜日に最も頻繁に更新される表領域に影響を与えるメディア障害からのリカバリを行うには 大量の REDO を再適用する必要があります 頻繁に更新される表領域のバックアップを毎日作成すると データベースの全体バックアップを毎日行わなくても 適用する REDO の量を削減できます NOLOGGING 操作後のバックアップ 参照 : A-1 ページの付録 A Recovery Manager ベースのディスクおよびテープのバックアップ計画の例 参照 : UNDO 表領域の管理の詳細は Oracle Database 管理者ガイド を参照してください データベースを移入するためにダイレクト パス ロードを実行する場合 これらのデータベース変更に関する REDO データは記録されません バックアップからのリストア後に 従来のメディア リカバリを使用して これらの変更をリカバリすることはできません 同様に 表および索引を NOLOGGING として作成した場合 データベースはこれらのオブジェクトに関する REDO データを記録しないため 既存のバックアップからこれらのオブジェクトをリカバリすることはできません そのため REDO データが記録されない操作を実行した後は データ ファイルをバックアップする必要があります 注意 : データ ファイルの全体バックアップまたは増分バックアップのいずれかを使用できます いずれもリカバリ不能操作によって変更されたブロックを含む すべての変更済ブロックが取得されます バックアップおよびリカバリ計画 2-11

44 バックアップ計画の立案 参照 : CREATE TABLE... AS SELECT 文および CREATE INDEX 文の UNRECOVERABLE オプションの詳細は Oracle Database SQL リファレンス を参照してください 保護と柔軟性の強化のためのデータベース データのエクスポート Oracle データベースのインポート ユーティリティおよびエクスポート ユーティリティは データベースからデータベース オブジェクト ( 表 ストアド プロシージャなど ) をエクスポートして ファイルとして格納し それらのファイルからオブジェクトを再インポートします エクスポートは エクスポートを実行した時点のオブジェクトの論理レベルのスナップショットを ソース データベースまたはその他のデータベースにインポートできるバイナリ ファイルとして提供します データベースのバックアップ計画において保護と柔軟性を強化するために データベースの一部または全部のエクスポートを検討してください データベースのエクスポートは 有用ではありますが データベースの全体バックアップの代替手段にはなりません エクスポートは 物理レベルのバックアップの完全なリカバリ機能は提供できません たとえば アーカイブ ログを論理バックアップに適用して 失われた変更を更新することはできません 参照 : 論理バックアップに対するデータのエクスポートおよびインポートについては Oracle Database ユーティリティ を参照してください オンライン REDO ログのバックアップの防止 オンライン REDO ログは アーカイブ ログとは異なり バックアップされることはありません オンライン REDO ログをバックアップすることの最大の問題は そのバックアップを意図せず誤ってリストアして データベースが破損する可能性があることです また 次の理由から オンライン REDO ログのバックアップは特に有効でもありません ARCHIVELOG モードでデータベースを稼働している場合は アーカイバが自動的に 一杯になった REDO ログをすでにアーカイブしています データベースが NOARCHIVELOG モードの場合 実行できる物理バックアップは クローズ状態で 一貫性のある データベース全体のバックアップのみです このタイプのバックアップのファイルは一貫性があり リカバリの必要がないため オンライン ログはバックアップからのリストア後は有効ではありません メディア障害からオンライン ログを保護する最適な方法は 各グループのログ メンバーを複数にし それぞれ異なるディスク コントローラに接続された異なるディスクに保持して オンライン ログを多重化することです 注意 : Recovery Manager ではオンライン REDO ログのバックアップは作成できません REDO ログをアーカイブして これをバックアップする必要があります サーバーのハードウェアおよびソフトウェア構成に関する情報の保持 リカバリが必要な状況では 必要な情報をすべて揃えておくことが重要です このことは 識別できない問題が発生してオラクル社カスタマ サポート センターへの問合せが必要になった場合に特に該当します 次のハードウェア構成に関するドキュメントが必要です データベースをホストするマシンの名前 メーカーおよびモデル オペレーティング システムのバージョンとパッチ ディスクおよびディスク コントローラの数 ディスク容量と空き領域 すべてのデータ ファイルの名前 メディア管理ソフトウェアの名前およびバージョン ( サード パーティ製のメディア マネージャを使用している場合 ) 2-12 Oracle Database バックアップおよびリカバリ基礎

45 データ リカバリ計画の検査 さらに 次のソフトウェア構成に関するドキュメントが必要です データベース インスタンス (SID) の名前 データベース識別子 (DBID) Oracle データベース サーバーのバージョンとパッチ リリース ネットワーキング ソフトウェアのバージョンとパッチ リリース データベース バックアップの方法 (Recovery Manager またはユーザー管理 ) と頻度 リストアおよびリカバリの方法 (Recovery Manager またはユーザー管理 ) これらの情報は 電子的な形式とハードコピーの両方で保持してください たとえば これらの情報をネットワーク上のテキスト ファイルや電子メールに保存していると システム全体が停止したときに利用できなくなる場合があります 特に これは DBID のレコードを保持するために重要です データベース (SPFILE と制御ファイルの消失を含む ) をリストアおよびリカバリする必要がある場合は リカバリ処理中に DBID が必要になります リカバリ中の DBID の使用方法については 6-3 ページの データベースのリストアおよびリカバリの基本使用例 を参照してください データ リカバリ計画の検査 本番システムへの移行前と移行後に 作成したバックアップおよびリカバリ方法をテスト環境で実行してください これにより 計画が完全なものであるかどうかを判断でき 実際の環境における問題を最小限に抑えることができます テスト リカバリを定期的に実行することにより アーカイブおよびバックアップ リカバリ作業の動作を確認できます また リカバリ作業に日頃から慣れておくことにもなるので 実際に緊急事態が起こった場合にもミスをする危険性が少なくなります Recovery Manager を使用している場合は 選択肢の 1 つとして 本番データベースのバックアップを使用して DUPLICATE コマンドでテスト データベースを作成できます ユーザー管理のバックアップとリカバリを実行する場合は バックアップをテストするために 新しいデータベース スタンバイ データベースまたは既存のデータベースのコピーのいずれかを作成できます BACKUP... VALIDATE の使用 参照 : Recovery Manager のテスト方法 SQL*Plus リカバリのトラブルシューティングの方法 ブロック メディア リカバリおよび Recovery Manager の障害時リカバリについては Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください Recovery Manager の BACKUP... VALIDATE コマンドを使用すると Recovery Manager は出力として実際にバックアップを作成せずに 指定されたすべてのデータベース ファイルを読み取ります これらのファイルは特定のバックアップ タスクで入力されたものです たとえば BACKUP DATABASE VALIDATE を使用すると Recovery Manager はデータベース全体のバックアップ時にバックアップされたすべてのファイルを読み取り これらが正常で損失のない状態であることを確認します 入力ファイルのすべてのデータ ブロックが 実際のバックアップを実行したときと同様に検査されます このプロセスによって データベースに対し有効な整合性チェックを行うことができます Recovery Manager バックアップの検査 : VALIDATE および RESTORE VALIDATE Recovery Manager の VALIDATE および RESTORE VALIDATE コマンドは リカバリ計画の継続的なテストの一部にする必要があります VALIDATE では Recovery Manager はディスクまたはテープに格納されている指定されたバックアップを読み取り これらが正常な状態で リストア操作に使用できるかどうかをレポートします RESTORE... VALIDATE では Recovery Manager は使用可能なバックアップのセットが指定されたデータベース オブジェクトをリストアするのに十分かどうかをチェックします たとえば RESTORE TABLESPACE TBS_1 バックアップおよびリカバリ計画 2-13

46 データ リカバリ計画の検査 VALIDATE は Recovery Manager が実際のリストア操作で行うのと同じように 指定された表領域のリストアに十分なバックアップを選択して そのバックアップを読み取り 存在していること および損失がないことを確認します 参照 : BACKUP VALIDATE および RESTORE VALIDATE の使用方法の詳細は 4-21 ページの Recovery Manager を使用したデータベース ファイルの検証 を参照してください データベースのリストアおよびリカバリ手順のテスト 異なるハードウェアでリストアおよびリカバリ計画の完全テストを実行して バックアップをテストすることもできます テストで使用するハードウェアおよびソフトウェア構成は 実際の障害時リカバリの際に使用可能な環境とできるかぎり同じようにすることをお薦めします 2-14 Oracle Database バックアップおよびリカバリ基礎

47 3 バックアップおよびリカバリの設定と構成 この章では Recovery Manager クライアントの起動方法と操作方法 およびバックアップおよびリカバリ計画を実施するために必要な Recovery Manager 環境の準備作業について説明します この章では 次の項目について説明します Recovery Manager クライアントの操作の概要 データベースへの Recovery Manager クライアントの接続 Recovery Manager バックアップ用のデータベースの設定 Recovery Manager 用のフラッシュ リカバリ領域の設定 注意 : Oracle Flashback Database および保証付きリストア ポイントは 真のバックアップではありませんが データ保護計画の重要な一部です これらの機能では いくつかの初期設定が必要な場合があります この初期設定は バックアップ計画にこれらの機能をどのように組み込んでいるかによって異なります これらの機能を使用するためのデータベースの設定方法の詳細は 第 5 章 リストア ポイントおよび Oracle Flashback Database を使用したデータ保護 を参照してください バックアップおよびリカバリの設定と構成 3-1

48 Recovery Manager クライアントの操作の概要 Recovery Manager クライアントの操作の概要 この項では Recovery Manager クライアントの起動と終了 コマンド プロンプトでのコマンドの入力 コマンドライン引数の使用など Recovery Manager クライアントの基本的な操作方法について説明します この項では次の項目を取り上げます Recovery Manager の起動および終了 Recovery Manager のグローバリゼーション サポート環境変数の設定 コマンド プロンプトでの Recovery Manager コマンドの入力 Recovery Manager でのコマンド ファイルの使用 Recovery Manager コマンドおよびコマンド ファイルの構文のチェック : CHECKSYNTAX Recovery Manager の起動および終了 Recovery Manager の起動には 次の基本的なオプションがあります オペレーティング システムのコマンドラインで 接続オプションを指定せずに Recovery Manager の実行可能ファイルを起動します 次に例を示します % rman オペレーティング システムのコマンドラインで Recovery Manager の実行可能ファイルを起動し ターゲット データベースや 必要に応じてリカバリ カタログに接続します 次に例を示します % rman TARGET / % rman TARGET SYS/oracle@trgt NOCATALOG % rman TARGET / CATALOG rman/cat@catdb 注意 : Recovery Manager を 1 つ以上のターゲット データベースに接続しないと ほとんどの Recovery Manager コマンドは適切に動作しません Recovery Manager を様々なタイプのデータベースに接続する方法の詳細は 3-6 ページの データベースへの Recovery Manager クライアントの接続 を参照してください Recovery Manager やプログラムを終了するには Recovery Manager プロンプトで EXIT または QUIT と入力します 次に例を示します RMAN> EXIT Recovery Manager のグローバリゼーション サポート環境変数の設定 Recovery Manager を起動する前に 環境変数 NLS_DATE_FORMAT および NLS_LANG を設定しておくと役に立つ場合があります これらの変数は RESTORE RECOVER REPORT などの Recovery Manager コマンドの時間パラメータで使用される書式を決定します 次の例は 言語および日付書式の代表的な設定を示しています NLS_LANG=american NLS_DATE_FORMAT='Mon DD YYYY HH24:MI:SS' Recovery Manager を使用してマウントされていないデータベースに接続し その後 Recovery Manager が接続された状態でそのデータベースをマウントする場合は NLS_LANG 環境変数にデータベースが使用するキャラクタ セットを指定してください マウントされていないデータベースのキャラクタ セットは デフォルトの US7ASCII とみなされます キャラクタ セットがデフォルトと異なる場合 データベースをマウントすると 3-2 Oracle Database バックアップおよびリカバリ基礎

49 Recovery Manager クライアントの操作の概要 Recovery Manager はエラーを戻します たとえば キャラクタ セットが WE8DEC である場合 NLS_LANG パラメータは次のように設定できます NLS_LANG=american_america.we8dec NLS_LANG および NLS_DATE_FORMAT は 使用される NLS_DATE_FORMAT に対して設定する必要があります コマンド プロンプトでの Recovery Manager コマンドの入力 Recovery Manager クライアントがコマンド入力可能な状態になると コマンド プロンプトが表示されます 次に例を示します RMAN> 参照 : NLS_LANG および NLS_DATE_FORMAT パラメータの詳細は Oracle Database リファレンス を参照してください Oracle Database グローバリゼーション サポート ガイド 実行する Recovery Manager コマンドを入力します 次に例を示します RMAN> CONNECT TARGET / RMAN> CONNECT CATALOG rman/rman@inst2 RMAN> BACKUP DATABASE ; ほとんどの Recovery Manager コマンドは複数のパラメータを取ります また コマンドの末尾にセミコロンを入力する必要があります (STARTUP SHUTDOWN CONNECT など いくつかの例外は セミコロンの有無に関係なく使用できます ) 不完全なコマンドのテキスト文を入力すると 行番号が表示され コマンドの続きを入力するように求められます 次に例を示します RMAN> BACKUP DATABASE 2> INCLUDE CURRENT 3> CONTROLFILE 4> ; Recovery Manager でのコマンド ファイルの使用 繰返し作業の場合は Recovery Manager コマンドを含むテキスト 引数の後にファイル名を続けて Recovery Manager クライアントを起動します たとえば 現行のディレクトリに次のテキスト行を含むテキスト ファイル cmdfile1 を作成します BACKUP DATABASE INCLUDE CURRENT CONTROLFILE; このコマンド ファイルをコマンドラインから実行すると ファイルに含まれるコマンドが実行されます 次に例を示します % rman TARGET コマンドが完了すると Recovery Manager は終了します Recovery Manager コマンド コマンドを使用して Recovery Manager セッション中にコマンド ファイルの内容を実行することもできます Recovery Manager は ファイルを読み取り ファイル内のコマンドを実行します 次に例を示します バックアップおよびリカバリの設定と構成 3-3

50 Recovery Manager クライアントの操作の概要 Recovery Manager は コマンド ファイル内のコマンドの実行後 次のメッセージを表示します RMAN> **end-of-file** オペレーティング システムのコマンドラインからコマンド ファイルを実行した場合と異なり Recovery Manager は終了しません Recovery Manager コマンドおよびコマンド ファイルの構文のチェック : CHECKSYNTAX コマンド プロンプトに Recovery Manager コマンドを入力するか またはコマンド ファイルからコマンドを読み取って コマンドを実行せずに そのコマンドの構文が正しいかどうかをテストする必要がある場合があります その場合 コマンドライン引数 CHECKSYNTAX を使用して Recovery Manager クライアントを起動します このモードでは Recovery Manager は入力されたコマンドの解析のみを行い 不正な Recovery Manager コマンド構文に RMAN エラーを戻します コマンドラインでの Recovery Manager コマンド構文のチェックの例 コマンドラインでコマンドをテストするには CHECKSYNTAX パラメータを指定して Recovery Manager を起動し テストするコマンドを入力します 次に例を示します % rman CHECKSYNTAX Recovery Manager: Release Production on Sun Jun 12 02:41: Copyright (c) 1982, 2005, Oracle. All rights reserved. RMAN> run [ backup database; ] RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-00558: error encountered while parsing input commands RMAN-01006: error signalled during parse RMAN-02001: unrecognized punctuation symbol "[" RMAN> run { backup database; } The command has no syntax errors RMAN> 参照 およびコマンド ファイルを使用する方法の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください コマンド ファイル内の Recovery Manager コマンド構文のチェックの例 コマンド ファイル内のコマンドをテストするには CHECKSYNTAX パラメータを指定して Recovery Manager 引数を使用して解析するコマンド ファイルを指定します たとえば テキスト エディタを使用して次の内容のコマンド ファイル /tmp/goodcmdfile を作成します #command file with legal syntax restore database; recover database; さらに 次の内容のコマンド ファイル /tmp/badcmdfile を作成します #command file with bad syntax commands restore database recover database 3-4 Oracle Database バックアップおよびリカバリ基礎

51 Recovery Manager を使用したデータベースの起動および停止 CHECKSYNTAX を指定してから Recovery Manager コマンド ファイルを実行すると 出力は次のようになります % rman Recovery Manager: Release Production on Sun Jun 12 02:41: Copyright (c) 1982, 2005, Oracle. All rights reserved. RMAN> # command file with legal syntax 2> restore database; 3> recover database; 4> The cmdfile has no syntax errors Recovery Manager complete. % rman Recovery Manager: Release Production on Sun Jun 12 02:41: Copyright (c) 1982, 2005, Oracle. All rights reserved. RMAN> #command file with syntax error 2> restore database 3> recover RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS=============== RMAN-00571: =========================================================== RMAN-00558: error encountered while parsing input commands RMAN-01005: syntax error: found "recover": expecting one of: "archivelog, channel, check, controlfile, clone, database, datafile, device, from, force, high, (, preview, ;, skip, spfile, standby, tablespace, until, validate" RMAN-01007: at line 3 column 1 file: /tmp/badcmdfile Recovery Manager を使用したデータベースの起動および停止 Recovery Manager のプロシージャでデータベースを起動または停止したり MOUNT または NOMOUNT 状態にする必要がある場合は Recovery Manager クライアントを使用してターゲット データベースを起動および停止することができます 次の例では Recovery Manager の SHUTDOWN および STARTUP コマンドを使用して ターゲット データベースを正常に停止した後 バックアップ準備用にマウントします % rman TARGET / RMAN> SHUTDOWN IMMEDIATE # closes database consistently RMAN> STARTUP MOUNT NOMOUNT または MOUNT 状態のターゲット データベースの状態を変更するには SQL*Plus または Recovery Manager の SQL コマンドを使用して SQL 文を発行する必要があります 次に例を示します RMAN> SQL 'ALTER DATABASE OPEN'; RMAN> SQL 'ALTER DATABASE OPEN'; RMAN> SQL 'ALTER DATABASE OPEN'; バックアップおよびリカバリの設定と構成 3-5

52 データベースへの Recovery Manager クライアントの接続 データベースへの Recovery Manager クライアントの接続 この項では Recovery Manager クライアントをターゲット データベースに接続する方法について説明します この項では次の項目を取り上げます Recovery Manager で使用するデータベース接続のタイプ データベース接続の認証 コマンドラインからのターゲット データベースへの接続 Recovery Manager プロンプトからのターゲット データベースへの接続 この項の例で使用される一般的な値の意味は 次のとおりです 例で使用される値 SYS oracle trgt 意味 SYSDBA 権限を持つユーザー ターゲット データベースの orapwd ファイルに指定された SYSDBA で接続する場合のパスワード ターゲット データベースのネット サービス名 Recovery Manager で使用するデータベース接続のタイプ 適切な作業を行うために Recovery Manager クライアントをターゲット データベース ( バックアップまたはリカバリ対象のデータベース ) に接続する必要があります 実行する作業や特定のバックアップ計画によっては Recovery Manager クライアントをさらに次の 2 つのデータベースに接続する場合もあります リカバリ カタログ データベース 制御ファイルとは別の Recovery Manager リポジトリのオプションのバックアップ先です 補助データベース スタンバイ データベースである場合があります または データベースを複製したり データベースを読取り専用にせずに表領域をトランスポートしたり 表領域の Point-in-Time リカバリを実行するなどの特定の作業を実行するために作成されたインスタンスである場合もあります 注意 : 補助データベースを使用する多くの作業では Recovery Manager が作業時に使用する自動補助インスタンスを作成し その補助インスタンスに接続して作業を実行した後 作業の完了時にそのインスタンスを破壊します 自動補助データベースへ接続するための明示的なコマンドはありません データベース接続の認証 ターゲット データベースまたは補助データベースに接続するには SYSDBA 権限が必要です パスワード ファイルまたはオペレーティング システム認証を使用して SYSDBA として接続できます 注意 : SQL*Plus とは異なり Recovery Manager ではデータベースへの接続時に SYSDBA 権限を指定する必要はありません これは すべての Recovery Manager データベースへの接続には SYSDBA 権限が必要であり Recovery Manager は常に暗黙的にこの権限で接続しようとするためです ターゲット データベースがパスワード ファイルを使用している場合は パスワードを使用して接続できます ローカルまたはリモート アクセスのいずれかで パスワード ファイルを使用してください ネット サービス名を指定して SYSDBA でリモート接続する場合は パスワード ファイルを使用する必要があります 3-6 Oracle Database バックアップおよびリカバリ基礎

53 データベースへの Recovery Manager クライアントの接続 オペレーティング システム認証を使用してデータベースに接続する場合は Oracle SID を指定する環境変数を設定する必要があります たとえば SID を trgt に設定するには UNIX のコマンドラインで次のように入力します % ORACLE_SID=trgt; export ORACLE_SID リカバリ カタログへの接続では SYSDBA 権限は必要ありません スキーマの所有者には RECOVERY_CATALOG_OWNER ロールを付与する必要があります 自動補助インスタンスについては Recovery Manager によって インスタンスの設定時に SYSDBA 権限を持っているかどうかが確認されます 参照 : データベースでのユーザーの認証方法は Oracle Database 管理者ガイド を参照してください コマンドラインからのターゲット データベースへの接続 オペレーティング システムのコマンドラインからターゲット データベースに接続するには 次のように入力します # example of operating system authentication % rman TARGET / NOCATALOG # example of Oracle Net authentication % rman TARGET SYS/oracle@trgt NOCATALOG また NOCATALOG や CATALOG を指定せずに Recovery Manager を起動することもできます # example of operating system authentication % rman TARGET / # example of Oracle Net authentication % rman TARGET SYS/oracle@trgt コマンドラインで NOCATALOG を指定しなかった場合や Recovery Manager を起動した後 CONNECT CATALOG を指定していない場合は Recovery Manager リポジトリを使用する必要があるコマンドを初めて実行したときに Recovery Manager は NOCATALOG モードで操作を開始します 注意 : NOCATALOG モードで Recovery Manager リポジトリを使用するコマンドを実行した後は Recovery Manager を終了して再起動しないと リカバリ カタログに接続できません オペレーティング システムのコマンドラインでターゲット データベースに接続した場合は Recovery Manager プロンプトが表示されるとコマンドの実行が可能になります Recovery Manager プロンプトからのターゲット データベースへの接続 ターゲット データベースに接続せずに Recovery Manager を起動した場合 ターゲット データベースに接続して適切な作業の実行を開始するには Recovery Manager プロンプトで CONNECT TARGET コマンドを発行する必要があります この例では オペレーティング システム認証を使用してターゲット データベースに接続します % rman RMAN> CONNECT TARGET / この例では データベースレベルの資格証明を使用してターゲット データベースに接続します % rman RMAN> connect target SYS/oracle@trgt バックアップおよびリカバリの設定と構成 3-7

54 Recovery Manager バックアップ用のデータベースの設定 Recovery Manager バックアップ用のデータベースの設定 Recovery Manager でのデータベースのバックアップは単純です そのため Recovery Manager バックアップで必要なほとんどのパラメータには 詳細に構成しなくても基本的なバックアップおよびリカバリを実行できる有効なデフォルト値があります ただし Recovery Manager ベースのバックアップ計画を実装する場合 一般的に使用可能なオプションについて理解しておくと Recovery Manager をより有効に使用できます これらのほとんどのオプションは Recovery Manager 環境に永続的に設定できます そのため コマンドを発行するたびに同じオプションを指定する必要はありません 次に Recovery Manager のデフォルトの動作をバックアップおよびリカバリ環境と計画に合わせて変更する方法 および主な設定項目とその値について説明します この項では 次の項目について説明します 永続的な構成設定 : Recovery Manager の動作の制御 ディスク バックアップ用のデフォルト バックアップ タイプの構成 ディスク デバイスとチャネルの構成 テープ デバイスとチャネルの構成 テープまたはディスクに対する圧縮バックアップ セットのデフォルトの構成 制御ファイルおよびサーバー パラメータ ファイルの自動バックアップの構成 永続的な構成設定 : Recovery Manager の動作の制御 Recovery Manager を使用して継続的に行うバックアップおよびリカバリを簡略化するには 各ターゲット データベースに対して永続的な構成を設定します これらの設定によって バックアップ保存方針 デフォルトのバックアップ先 ( テープまたはディスク ) デフォルトのバックアップ デバイス タイプ ( テープまたはディスク ) など データベースで作業する際の Recovery Manager の多くの動作が制御されます これらの構成設定のデフォルト値を使用すると 構成設定を変更することなく Recovery Manager を有効に使用できます ただし より高度なバックアップおよびリカバリ計画を立てる場合は これらの設定を変更してその計画を実装する必要があります Recovery Manager の SHOW および CONFIGURE コマンドを使用すると Recovery Manager の構成設定を参照および変更できます 参照 : CONFIGURE 構文の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください Recovery Manager の現行の構成設定の表示 : SHOW SHOW コマンドを使用して Recovery Manager の構成設定の 1 つまたはすべての現行の値と これらが現在デフォルト値に設定されているかどうかを表示します ターゲット データベースとリカバリ カタログ ( 使用している場合 ) に接続してから 表示する設定の名前を指定して SHOW コマンドを実行します 次に例を示します RMAN> SHOW RETENTION POLICY; RMAN> SHOW DEFAULT DEVICE TYPE; SHOW ALL コマンドは CONFIGURE コマンドで設定可能なすべてのパラメータの現行の設定を表示します 変更したパラメータと Recovery Manager のデフォルト設定のままのパラメータがどちらも表示されます すべての構成設定を表示するには Recovery Manager の SHOW ALL コマンドを実行します 次に例を示します RMAN> SHOW ALL; # shows all CONFIGURE settings, both user-entered and default 3-8 Oracle Database バックアップおよびリカバリ基礎

55 Recovery Manager バックアップ用のデータベースの設定 SHOW ALL の出力例を 次に示します RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; # default CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET; CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'SBT_ LIBRARY=mylibrary.disksbt,ENV=(BACKUP_PARAM=value)'; CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/disk1/oracle/dbs/snapcf_ev.f'; # default 構成の再作成に必要となる一連の Recovery Manager コマンドが表示されます SHOW ALL の出力をテキスト ファイルに保存して そのコマンド ファイルを使用して同じターゲット データベースまたは別のターゲット データベース上で構成を再作成することができます 参照 : SHOW 構文の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください Recovery Manager のデフォルトの構成設定のリストア : CONFIGURE... CLEAR CONFIGURE... CLEAR を使用すると 任意の設定をデフォルト値に戻すことができます 次に例を示します RMAN> CONFIGURE BACKUP OPTIMIZATION CLEAR; RMAN> CONFIGURE RETENTION POLICY CLEAR; RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR; バックアップ用のデフォルト デバイス タイプの構成 デフォルトでは Recovery Manager はディスク上のオペレーティング システム固有のディレクトリにバックアップをすべて送信します テープなどのメディアにバックアップするように Recovery Manager を構成することもできます メディア管理ベンダーのマニュアルの指示に従って sbt( テープまたはメディア管理 ) デバイスを構成してから メディア マネージャをデフォルトのデバイスに設定できます CONFIGURE DEFAULT DEVICE TYPE TO sbt; デフォルト デバイス タイプを構成すると バックアップ先のデバイス タイプを指定せずに BACKUP コマンドを実行して作成されたバックアップは デフォルト デバイス タイプに構成されます たとえば 次のコマンドを実行すると テープに一連のバックアップが生成されます CONFIGURE DEFAULT DEVICE TYPE TO sbt; BACKUP DATABASE; BACKUP DATAFILE 3; BACKUP DATABASE PLUS ARCHIVELOG; バックアップおよびリカバリの設定と構成 3-9

56 Recovery Manager バックアップ用のデータベースの設定 ディスクをバックアップ用のデフォルト デバイスとして構成するには CONFIGURE... CLEAR を使用してデフォルト設定をリストアするか または次のように明示的にデフォルト デバイスを構成します CONFIGURE DEFAULT DEVICE TYPE TO DISK; 注意 : BACKUP コマンドの DEVICE TYPE 句を使用すると 特定のデバイス タイプ (DISK または SBT のいずれか ) に常にバックアップを行うことができます 次に例を示します BACKUP DEVICE TYPE sbt DATABASE; BACKUP DEVICE TYPE DISK DATABASE; DEVICE TYPE 句を指定した BACKUP コマンドを使用する方法の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください ディスク バックアップ用のデフォルト バックアップ タイプの構成 次のいずれかのコマンドを使用して バックアップ セットまたはイメージ コピーをデフォルトとして構成できます RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY; # image copies RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET; # uncompressed ディスクおよびテープへのバックアップのデフォルトはバックアップ セットです Recovery Manager が バックアップ セットとしてのメディア マネージャ デバイスに対して実行できるのはバックアップの書込みのみであるため メディア マネージャ デバイスには同様のオプションがないことに注意してください テープまたはディスクに対する圧縮バックアップ セットのデフォルトの構成 次の例に示すように BACKUP TYPE TO COMPRESSED BACKUPSET オプションを指定した CONFIGURE DEVICE TYPE コマンドを使用して 特定のデバイス タイプに対して圧縮バックアップ セットをデフォルトで使用するように Recovery Manager を構成することができます RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET; RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO COMPRESSED BACKUPSET; 圧縮バックアップを無効にするには その他の設定を指定する引数とともに CONFIGURE DEVICE TYPE コマンドを使用します ただし COMPRESSED キーワードは指定しません 次に例を示します RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET; RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO BACKUPSET; ディスク デバイスとチャネルの構成 Recovery Manager チャネル ( ターゲット データベース上のサーバー セッションへの接続 ) は すべての Recovery Manager タスクを実行します デフォルトでは Recovery Manager はすべての処理に対して 1 つのディスク チャネルを割り当てます 次のコマンドは /backup ディレクトリにディスクのバックアップを書き込むように Recovery Manager を構成しています ( 詳細は 4-7 ページの Recovery Manager を使用したデータベース ファイルおよびアーカイブ ログのバックアップ を参照 ) CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backup/ora_df%t_s%s_s%p'; 書式指定子の %t は 4 バイトのタイム スタンプ %s はバックアップ セット番号 %p はバックアップ ピース番号に置き換えられます 3-10 Oracle Database バックアップおよびリカバリ基礎

57 Recovery Manager バックアップ用のデータベースの設定 次の例のように 自動ストレージ管理ディスク グループを宛先として構成することもできます CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+dgroup1'; 注意 : フラッシュ リカバリ領域を構成済の場合に ディスク チャネルの明示的な形式を構成すると フラッシュ リカバリ領域にバックアップされなくなります フラッシュ リカバリ領域のディスク領域管理機能が失われます テープ デバイスとチャネルの構成 メディア マネージャによっては CONFIGURE コマンドに PARMS 文字列を指定して 構成設定を渡す必要がある場合があります CONFIGURE CHANNEL DEVICE TYPE sbt PARMS='ENV=mml_env_settings'; PARMS 文字列の内容は ご使用のメディア管理ライブラリに応じて異なります 詳細は メディア マネージャのマニュアルを参照してください CONFIGURE DEVICE TYPE SBT を使用して SBT デバイスの並列化の設定 バックアップ セットの圧縮およびその他のオプションを構成できます ( デバイス タイプに対するこれらの設定は 前述の例のデバイス セットのチャネル構成に関係なく設定されます ) 次のコマンドでは Recovery Manager のジョブで使用する 2 つの sbt チャネルを構成します CONFIGURE DEVICE TYPE sbt PARALLELISM 2; old RMAN configuration parameters: CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1; new RMAN configuration parameters: CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET; new RMAN configuration parameters are successfully stored RMAN> configure device type sbt backup type to backupset; old RMAN configuration parameters: CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET; new RMAN configuration parameters: CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO BACKUPSET PARALLELISM 2; new RMAN configuration parameters are successfully stored この例で使用されている並列化およびバックアップ タイプを設定するための CONFIGURE コマンドは 指定していない設定の値には影響しないことに注意してください つまり CONFIGURE DEVICE TYPE SBT PARALLELISM 1 コマンド実行しても 圧縮バックアップ セットのデフォルトのバックアップ タイプは変更されません 制御ファイルおよびサーバー パラメータ ファイルの自動バックアップの構成 制御ファイル内のデータベースの構造メタデータが変更されたり バックアップ レコードが追加されると Recovery Manager は 制御ファイルおよびサーバー パラメータ ファイルを自動的にバックアップするように構成できます 制御ファイル カタログおよびサーバー パラメータ ファイルが消失した場合でも 自動バックアップを使用して Recovery Manager はデータベースをリカバリできます 自動バックアップのファイル名には既知の書式が使用されるため Recovery Manager はリポジトリにアクセスすることなく自動バックアップを検索し サーバー パラメータ ファイルをリストアできます サーバー パラメータ ファイルをリストアしてインスタンスを起動すると Recovery Manager は自動バックアップから制御ファイルをリストアできます 制御ファイルをマウントした後 Recovery Manager リポジトリが有効になり Recovery Manager によってデータ ファイルのリストアおよびアーカイブ REDO ログの検索が可能になります バックアップおよびリカバリの設定と構成 3-11

58 Recovery Manager バックアップ用のデータベースの設定 次のコマンドを実行すると 自動バックアップ機能が有効になります CONFIGURE CONTROLFILE AUTOBACKUP ON; 次のコマンドを実行すると 自動バックアップ機能が無効になります CONFIGURE CONTROLFILE AUTOBACKUP OFF; 参照 : 制御ファイルの自動バックアップの概要については Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください CONFIGURE 構文の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください 制御ファイルの自動バックアップ書式の構成 すべての構成済デバイスに対する自動バックアップ ファイルの書式は デフォルトでは置換変数 %F になります この変数の書式は c-iiiiiiiiii-yyyymmdd-qq に変換されます この各部分の意味は 次のとおりです IIIIIIIIII は DBID を表します YYYYMMDD は バックアップが生成された日のタイム スタンプです QQ は 00 から始まる 16 進の順序です 最大値は FF です 次のコマンドを使用して デフォルトの書式を変更できます この場合 devicespecifier には DISK や sbt などの有効なデバイスを指定します また 'string' には 置換変数 %F を含む ( 他の置換変数は含まれません ) デバイスに対して有効なハンドルを指定します CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE devicespecifier TO 'string'; たとえば 次のコマンドを実行できます CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '?/oradata/cf_%f'; 次の例では 自動ストレージ管理ディスク グループに自動バックアップを書き込むように構成します CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK TO '+dgroup1/%f'; デバイスの制御ファイルの自動バックアップ書式を削除するには 次のコマンドを使用します CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE sbt CLEAR; データベースにフラッシュ リカバリ領域を設定済の場合 ディスクの制御ファイルの自動バックアップ書式を削除することによって 制御ファイルの自動バックアップ先をフラッシュ リカバリ領域に指定できます 制御ファイルの構成済自動バックアップ書式の変更 RUN ブロックまたは Recovery Manager プロンプトのいずれかで指定可能な SET CONTROLFILE AUTOBACKUP FORMAT コマンドを使用すると 現行のセッションのみで構成済の自動バックアップ書式を変更できます 優先順位は次のとおりです 1. SET CONTROLFILE AUTOBACKUP FORMAT(RUN ブロック内 ) 2. SET CONTROLFILE AUTOBACKUP FORMAT(RMAN プロンプト ) 3. CONFIGURE CONTROLFILE AUTOBACKUP FORMAT 3-12 Oracle Database バックアップおよびリカバリ基礎

59 Recovery Manager 用のフラッシュ リカバリ領域の設定 次の例では 2 つの形式の SET CONTROLFILE AUTOBACKUP FORMAT の相互作用を示します RMAN> SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'controlfile_%f'; RMAN> BACKUP AS COPY DATABASE; RMAN> RUN { SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/tmp/%f.bck'; BACKUP AS BACKUPSET DEVICE TYPE DISK DATABASE; } 最初の SET CONTROLFILE AUTOBACKUP FORMAT は 制御ファイルのすべての構成済自動バックアップ書式より優先され Recovery Manager クライアントが終了するまで制御ファイルの自動バックアップの名前を制御します RUN ブロックの SET CONTROFILE AUTOBACKUP FORMAT は RUN ブロックが存在する間は RUN ブロック以外の SET CONTROLFILE AUTOBACKUP FORMAT より優先されます Recovery Manager 用のフラッシュ リカバリ領域の設定 1-11 ページの 自動ディスク ベース バックアップおよびリカバリ : フラッシュ リカバリ領域 で説明したとおり フラッシュ リカバリ領域の機能によって データベースがリカバリに関連する各種ファイルの作成および管理に使用できるディスクの位置を設定できます フラッシュ リカバリ領域を使用すると リカバリ関連ファイルを命名したり リストアおよびリカバリ操作に必要な間はそのファイルを保持しておく操作を自動化できます また データベースのリストアにそれらのファイルが不要になった場合や 他のバックアップおよびリカバリ関連操作で領域が必要になった場合に 不要なファイルを削除する操作を自動化することもできます これによって 継続して行うデータベースの管理を簡略化できます フラッシュ リカバリ領域を使用すると 長期バックアップおよびリカバリ管理を大幅に簡略化できるため フラッシュ リカバリ領域を使用することをお薦めします バックアップ計画を実装する際の最初の手順の 1 つとして フラッシュ リカバリ領域を設定します この項では フラッシュ リカバリ領域の機能の概要と この領域に格納されるファイルおよびそのファイルの管理方法の規則について説明します また 最も重要な構成オプションも説明します フラッシュ リカバリ領域の位置の選択 フラッシュ リカバリ領域を設定する場合 ファイルを保持する位置 ( ディレクトリまたは自動ストレージ管理ディスク グループ ) を選択する必要があります フラッシュ リカバリ領域を RAW ファイル システムに格納することはできません また フラッシュ リカバリ領域のディスク割当て制限 ( フラッシュ リカバリ領域に格納されたすべてのファイルが使用する領域の最大値 ) を決定する必要もあります 必要なディスク割当て制限に適応できるだけの十分な大きさの領域を選択してください ディスク領域の制限に達すると Oracle は 保存方針の制限に従って 重要でないファイルを削除して新規ファイル用の領域を確保します フラッシュ リカバリ領域は データ ファイル 制御ファイル オンライン REDO ログなどのアクティブなデータベース ファイルが格納されているデータベース領域データベース領域とは異なるディスク上に確保してください データベース領域と同じディスク上にフラッシュ リカバリ領域を保持すると メディア障害が発生した場合に 使用中のデータベース ファイルとバックアップの両方が失われることになります 注意 : RAC 環境でフラッシュ リカバリ領域の位置を選択する場合は 特別に注意が必要です クラスタ ファイル システム ASM または NFS を介して構成された共有ディレクトリの位置を選択する必要があります 位置およびディスク割当て制限は すべてのインスタンスで同一である必要があります バックアップおよびリカバリの設定と構成 3-13

60 Recovery Manager 用のフラッシュ リカバリ領域の設定 フラッシュ リカバリ領域 自動ストレージ管理および Oracle Managed Files フラッシュ リカバリ領域は Oracle の機能である Oracle Managed Files および自動ストレージ管理と密接に関係し これらの機能とともに使用できます Oracle Managed Files(OMF) は いくつかの初期化パラメータに基づいて 制御ファイル REDO ログ ファイル データ ファイルなどのデータベース ファイルの命名 配置 作成および削除を自動化するサービスです 各操作ごとに詳細に独自の方針を検討する必要がなくなり 多くの面で DBA の作業を簡略化できます フラッシュ リカバリ領域は OMF の最上位に構築されます このため Oracle 管理ファイルを格納できる任意の場所に フラッシュ リカバリ領域を確保できます Oracle Managed Files は 従来のファイル システム (VxFS ODM など ) の最上位で使用されます また フラッシュ リカバリ領域は Oracle の自動ストレージ管理 (ASM) でも使用できます ASM は ストレージ デバイスを管理ディスク グループに簡単に統合し サード パーティ製の論理ボリューム マネージャを使用せずにミラー化やストライプ化などを行えるというメリットがあります ASM 記憶域にフラッシュ リカバリ領域を設定しないように選択している場合でも Oracle Managed Files を使用して ASM ディスク グループのバックアップ ファイルを管理するこができます より新しいバックアップのために領域が必要になった場合 リカバリ可能性の目的に合わなくなったファイルを自動削除するという フラッシュ リカバリ領域の主なメリットの 1 つがなくなります ただし その他の OMF の自動機能は使用できます 注意 : バックアップ ファイルを格納する場合 フラッシュ リカバリ領域を使用せずに 自動ストレージ管理の最上位で OMF を使用することは可能ですが お薦めする方法ではありません これは 自動ストレージ管理下のファイルは直接操作しにくいためです フラッシュ リカバリ領域に格納できるファイル フラッシュ リカバリ領域内のファイルは 永続的なもの永続的なものと一時的なもの一時的なものに分類できます 永続ファイルは 現行の制御ファイルとオンライン REDO ログの多重化コピーのみです ( ただし これらのファイルがフラッシュ リカバリ領域に格納されるように構成していることを前提とします ) これらのファイルを削除すると インスタンスに障害が発生します これ以外のファイルはすべて一時ファイルです 通常 これらのファイルは 保存方針のもと不要になった後やテープにバックアップされた時点で 最終的には削除されるためです 一時ファイルには アーカイブ REDO ログ データ ファイルのコピー 制御ファイルのコピー 制御ファイルの自動バックアップおよびバックアップ ピースが含まれます 注意 : Point-in-Time リカバリに代わる Oracle Flashback Database の機能によって フラッシュバック ログが生成されます このログは 一時ファイルとみなされ フラッシュ リカバリ領域に格納される必要があります ただし 他の一時ファイルとは異なり フラッシュバック ログは他のメディアにバックアップすることはできません これらは フラッシュ リカバリ領域で他のファイルのために領域が必要になった場合に自動的に削除されます Oracle Flashback Database の詳細は 第 5 章 リストア ポイントおよび Oracle Flashback Database を使用したデータ保護 を参照してください フラッシュ リカバリ領域のサイズの計画 フラッシュ リカバリ領域は 大きいほど有効です 次のすべてのファイルを格納できるだけの十分な大きさにすることをお薦めします すべてのデータ ファイルのコピー 増分バックアップ ( 選択したバックアップ計画で使用 ) オンライン REDO ログ 3-14 Oracle Database バックアップおよびリカバリ基礎

61 Recovery Manager 用のフラッシュ リカバリ領域の設定 テープにまだバックアップされていないアーカイブ REDO ログ 制御ファイル 制御ファイルの自動バックアップ ( 制御ファイルおよび SPFILE のコピーを含む ) この大きな領域が現実的でない場合は 最も重要な表領域のバックアップと まだテープにコピーされていないすべてのアーカイブ ログを保持できるだけの領域を作成するようにしてください 少なくとも テープにまだコピーされていないアーカイブ ログを格納できる大きさは確保してください フラッシュ リカバリ領域のディスク割当て制限と現行のディスク使用量を確認するには V$RECOVERY_FILE_DEST ビューを問い合せます 有効なフラッシュ リカバリ領域のサイズを見積もるための式は 次に示すバックアップおよびリカバリ計画のいくつかの要因によって異なります 頻繁に変更されるデータベース内のデータ ブロックの数 バックアップをディスクのみに保存するか ディスクとテープの両方に保存するか 使用する保存方針が冗長性ベースかリカバリ期間ベースか 論理エラーからリカバリするための Point-in-Time リカバリの代替方法として Oracle Flashback Database または保証付きリストア ポイントの使用を計画しているかどうか 様々なバックアップ計画に固有の式については 付録 A Recovery Manager ベースのディスクおよびテープのバックアップ計画の例 を参照してください Oracle Flashback Database を使用する場合 フラッシュ リカバリ領域用に記憶域を追加する必要があります (5-11 ページの フラッシュバック ログを格納するためのフラッシュ リカバリ領域のサイズ設定 を参照 ) フラッシュ リカバリ領域のサイズと位置の初期化パラメータの設定 フラッシュ リカバリ領域を有効にするには 2 つの初期化パラメータ DB_RECOVERY_FILE_ DEST_SIZE( ディスク割当て制限またはこのデータベースのフラッシュ リカバリ領域のファイルが使用する領域の最大値を指定 ) および DB_RECOVERY_FILE_DEST( フラッシュ リカバリ領域の位置を指定 ) を設定する必要があります 注意 : DB_RECOVERY_FILE_DEST_SIZE は DB_RECOVERY_FILE_DEST. を指定する前に指定する必要があります RAC データベースのすべてのインスタンスでは これらのパラメータに同一の値を指定する必要があります 初期化パラメータは次のいずれかの方法で指定できます ターゲット データベースの初期化パラメータ ファイルに含める SQL 文 ALTER SYSTEM SET で指定する データベース コンフィギュレーション アシスタントを使用して設定する 参照 : データベースの初期化パラメータの設定および変更については Oracle Database 管理者ガイド を参照してください フラッシュ リカバリ領域の現在の位置を確認するには V$RECOVERY_FILE_DEST を問い合せます 参照 : ALTER SYSTEM 構文の詳細は Oracle Database SQL リファレンス を参照してください バックアップおよびリカバリの設定と構成 3-15

62 Recovery Manager 用のフラッシュ リカバリ領域の設定 フラッシュ リカバリ領域のサイズ : DB_RECOVERY_FILE_DEST_SIZE この初期化パラメータは このデータベースのフラッシュ リカバリ領域で使用するデータの記憶域の最大値をバイト単位で指定します 注意 : 指定した値には 特定の種類のディスクのオーバーヘッドは含まれません ブロック 0 または各 Oracle ファイルの OS ブロック ヘッダーは このサイズに含まれません フラッシュ リカバリ領域で必要な実際のディスク使用量を計算する場合 このデータ用に 10% 多く見積もります 基礎となるファイル システムがミラー化または圧縮されている場合 あるいは Oracle では認識されないオーバーヘッドの影響を受けている場合 DB_RECOVERY_FILE_DEST_SIZE は ディスクで占有される実際のサイズではありません たとえば 通常の冗長性 ( 双方向のミラー化 ) ASM ディスク グループにフラッシュ リカバリ領域を構成する場合 X バイトの各ファイルが ASM ディスク グループの 2X バイトを占有します このような場合 DB_RECOVERY_FILE_DEST_SIZE には ASM ディスク グループのディスクの 1/2 未満のサイズを設定する必要があります 同様に 高度な冗長性 (3 方向のミラー化 )ASM ディスク グループを使用する場合 DB_RECOVERY_FILE_DEST_SIZE には ディスク グループのディスクの 1/3 未満のサイズを指定する必要があります フラッシュ リカバリ領域の位置 : 初期化パラメータ DB_RECOVERY_FILE_ DEST このパラメータは ファイルを作成するためのディスク上の有効な位置を指定します ファイル システム上のディレクトリまたは自動ストレージ管理ディスク グループを指定できます 複数のデータベース間でのフラッシュ リカバリ領域の共有 次のいずれかの条件を満たす場合 複数のデータベースで DB_RECOVERY_FILE_DEST に同じ値を指定できます DB_UNIQUE_NAME に同じ値が指定されているデータベースがない DB_UNIQUE_NAME が指定されていないデータベースで DB_NAME に同じ値が指定されているデータベースがない このようにしてデータベースが単一のフラッシュ リカバリ領域を共有する場合 フラッシュ リカバリ領域を保持しているファイル システムまたは ASM ディスク グループには すべてのデータベースのすべてのリカバリ ファイルを保持できる十分な大きさが必要です 別のデータベースの DB_RECOVERY_FILE_DEST_SIZE のすべての値を追加した後 3-16 ページの フラッシュ リカバリ領域のサイズ : DB_RECOVERY_FILE_DEST_SIZE で説明するように 実際のディスク領域を割り当てる際のミラー化や圧縮などのオーバーヘッドについて考慮します フラッシュ リカバリ領域使用時の初期化パラメータの制限 フラッシュ リカバリ領域を使用する際は その他の初期化パラメータの影響を受けます REDO ログのアーカイブ先を指定するのに LOG_ARCHIVE_DEST および LOG_ARCHIVE_ DUPLEX_DEST パラメータを使用することはできません かわりに 新しい LOG_ ARCHIVE_DEST_n パラメータを使用する必要があります LOG_ARCHIVE_DEST_n パラメータのセマンティクスについては Oracle Database リファレンス を参照してください リカバリ領域を作成し ローカルのアーカイブ先を他に設定しない場合は LOG_ ARCHIVE_DEST_10 は暗黙的に USE_DB_RECOVERY_FILE_DEST に設定されます ( アーカイブ REDO ログ ファイルはフラッシュ リカバリ領域に送信されます ) 3-16 Oracle Database バックアップおよびリカバリ基礎

63 Recovery Manager 用のフラッシュ リカバリ領域の設定 DB_RECOVERY_FILE_DEST を DB_CREATE_FILE_DEST パラメータ またはいずれかの DB_CREATE_ONLINE_LOG_DEST_n パラメータと同じ値に設定しないことをお薦めします DB_RECOVERY_FILE_DEST がこれらのパラメータと同じ場合 アラート ログに警告が記録されます 既存データベースへのフラッシュ リカバリ領域の追加 フラッシュ リカバリ領域を作成するには 初期化パラメータ ファイル (PFILE) に必要なパラメータを設定し データベースを再起動します また この例に示すとおり ALTER SYSTEM を使用して DB_RECOVERY_FILE_DEST および DB_RECOVERY_FILE_DEST_SIZE 初期化パラメータを設定して オープン状態のデータベースにフラッシュ リカバリ領域を追加することもできます 注意 : DB_RECOVERY_FILE_DEST_SIZE は DB_RECOVERY_FILE_DEST を指定する前に指定する必要があります 1. SQL*Plus を起動してデータベースに接続してから フラッシュ リカバリ領域のサイズを設定します たとえば 10GB に設定します SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 10G SCOPE=BOTH SID='*'; SCOPE に BOTH を設定して メモリーとサーバー パラメータ ファイルの両方に変更を適用しています ( シングル インスタンス データベースでは SID を * に設定しても影響はありませんが RAC データベースではすべてのインスタンスで変更が有効になります ) 2. フラッシュ リカバリ領域の位置を設定します たとえば フラッシュ リカバリ領域の位置がファイル システム ディレクトリ /disk1/flash_recovery_area である場合は 次のように設定できます SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/disk1/flash_recovery_area' SCOPE=BOTH SID='*'; フラッシュ リカバリ領域の位置が自動ストレージ管理ディスク グループ disk1 である場合は 次のように設定できます SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '+disk1' SCOPE=BOTH SID='*'; V$RECOVERY_FILE_DEST および V$FLASH_RECOVERY_AREA_USAGE の使用 V$RECOVERY_FILE_DEST および V$FLASH_RECOVERY_AREA_USAGE ビューを使用すると フラッシュ リカバリ領域に十分な領域を割り当てているかどうかを判断できます V$RECOVERY_FILE_DEST ビューを問い合せて フラッシュ リカバリ領域の現在の位置 ディスク割当て制限 使用領域 ファイル削除による再利用可能な領域 およびファイルの合計数を確認します SQL> SELECT * FROM V$RECOVERY_FILE_DEST; NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES /mydisk/rcva V$FLASH_RECOVERY_AREA_USAGE ビューを問い合せて ファイルのタイプごとに使用されているディスク割当て制限の合計の割合 および各タイプのファイルの領域で 不要なファイル 冗長なファイルまたはテープにバックアップ済であるファイルを削除することによって再利用可能となるサイズを確認できます SQL> SELECT * FROM V$FLASH_RECOVERY_AREA_USAGE; FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES CONTROLFILE ONLINELOG バックアップおよびリカバリの設定と構成 3-17

64 Recovery Manager 用のフラッシュ リカバリ領域の設定 ARCHIVELOG BACKUPPIECE IMAGECOPY FLASHBACKLOG V$RECOVERY_FILE_DEST および V$FLASH_RECOVERY_AREA ビューの詳細は Oracle Database リファレンス を参照してください フラッシュ リカバリ領域の無効化 フラッシュ リカバリ領域を無効にするには DB_RECOVERY_FILE_DEST 初期化パラメータを NULL 文字列に設定します たとえば 次の SQL*Plus 文を使用して 稼働中のデータベースのパラメータを変更します ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='' SCOPE=BOTH SID="*"; これで データベースは以前の DB_RECOVERY_FILE_DEST の位置に格納されているファイルにフラッシュ リカバリ領域の領域管理機能を提供しなくなります ただし ファイルは Recovery Manager リポジトリに認識され バックアップおよびリストア操作を実行できます バックアップ保存方針の構成 バックアップ保存方針では データのリカバリ要件に従って 保存する必要があるバックアップを指定します この方針は リカバリ期間 ( リカバリ可能な過去の最大日数 ) または冗長性 ( 保持するバックアップ ファイルのコピーの数 ) に基づいています 保存方針を設定するには CONFIGURE コマンドを使用します 参照 : CONFIGURE 構文の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください リカバリ期間ベースの保存方針の構成 CONFIGURE コマンドの RECOVERY WINDOW パラメータでは 現時点と最初のリカバリ可能ポイント間の日数を指定します Recovery Manager は リカバリ期間内の全体バックアップやレベル 0 の増分バックアップを必要なものとみなします また すべてのアーカイブ ログと 期間内の任意の時点にリカバリする必要のあるレベル 1 の増分バックアップも保持します Recovery Manager プロンプトで CONFIGURE RETENTION POLICY コマンドを実行します 次の例では データベースを過去 1 週間のどの時点の状態にでもリカバリできます RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; Recovery Manager は リカバリ期間によって不要となったバックアップを自動的には削除しません かわりに REPORT OBSOLETE の出力や V$OBSOLETE_BACKUP_FILES の OBSOLETE 列に OBSOLETE として表示します DELETE OBSOLETE コマンドを実行すると Recovery Manager は不要なファイルを削除します 冗長性ベースの保存方針の構成 CONFIGURE RETENTION POLICY コマンドの REDUNDANCY パラメータでは Recovery Manager が保持する必要がある各データ ファイルおよび制御ファイルのバックアップの数を指定します つまり 特定のデータ ファイルまたは制御ファイルのバックアップの数が REDUNDANCY の設定を超えると Recovery Manager は余分なバックアップを不要とみなします デフォルトの保存方針は REDUNDANCY=1 です さらにバックアップが作成されると Recovery Manager は保存するバックアップと不要なバックアップを追跡します Recovery Manager は すべてのアーカイブ ログと 必要なバックアップのリカバリに必要な増分バックアップを保持します データ ファイル 7 を月曜日 火曜日 水曜日および木曜日にバックアップすると仮定します データ ファイルのバックアップは 4 つ作成されます REDUNDANCY が 2 の場合 月曜日と火 3-18 Oracle Database バックアップおよびリカバリ基礎

65 Recovery Manager 用のフラッシュ リカバリ領域の設定 曜日のバックアップは不要になります 金曜日にさらにバックアップを作成すると 水曜日のバックアップが不要になります 次の例のように Recovery Manager プロンプトで CONFIGURE RETENTION POLICY コマンドを実行します CONFIGURE RETENTION POLICY TO REDUNDANCY 3; 現在のバックアップ保存方針の表示 SHOW RETENTION POLICY コマンドを使用して 現在の構成済の保存方針を表示できます 出力例は次のとおりです RMAN> SHOW RETENTION POLICY; RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 3; 保存方針の無効化 保存方針を無効にすると Recovery Manager はすべてのバックアップを必要とみなします 保存方針を無効にするには 次のコマンドを実行します CONFIGURE RETENTION POLICY TO NONE; 保存方針を NONE に構成することは 保存方針を消去することとは異なります 保存方針を消去すると デフォルトの REDUNDANCY=1 の設定に戻りますが NONE では保存方針が完全に無効になります 保存方針を無効にし コマンドに保存方針のオプションを指定せずに REPORT OBSOLETE または DELETE OBSOLETE を実行した場合 不要なバックアップを判断するための保存方針が存在しないため Recovery Manager はエラーを発行します 注意 : フラッシュ リカバリ領域を使用している場合 保存方針が無効な状態でデータベースを稼働しないでください ファイルが必要であるとみなされていると ディスクの他の位置や テープなど 3 次ストレージ デバイスにファイルをバックアップ済の場合は フラッシュ リカバリ領域からファイルを削除できます これによって リカバリ領域のすべての領域が使用される可能性があります データベースの通常の操作への影響については 3-20 ページの フラッシュ リカバリ領域で領域が使用不可の場合 を参照してください フラッシュ リカバリ領域における Oracle のディスク領域の管理方法 他の目的のために領域を再利用する必要がないかぎり 削除対象のファイルはフラッシュ リカバリ領域からは削除されません そのため 最近テープに移動されたファイルはディスク上に存在するため リカバリで使用可能です リカバリ領域は テープに対するキャッシュの一種として使用できます フラッシュ リカバリ領域の使用率が 100% になると Oracle は対象ファイルを自動的に削除し 必要に応じてフラッシュ リカバリ領域を再利用します フラッシュ リカバリ領域のファイルが削除の対象となる場合 フラッシュ リカバリ領域から削除するファイルを決定する規則は 比較的単純です 永続ファイルは削除の対象になりません 構成済の保存方針によって不要とみなされているファイルは削除対象です テープにコピーされた一時ファイルは削除対象です Data Guard 環境では アーカイブ REDO ログの削除方針によって フラッシュ リカバリ領域からアーカイブ REDO ログが削除される時期が決定されます アーカイブ REDO ログの削除方針の詳細は Oracle Data Guard 概要および管理 を参照してください バックアップおよびリカバリの設定と構成 3-19

66 Recovery Manager 用のフラッシュ リカバリ領域の設定 注意 : 領域の要求を満たすために削除が必要となるファイルは 正確には予測できません 削除するために 特定のファイルの選択を決定するこの規則は リリースによって異なる可能性があります また 構成によっても異なります フラッシュ リカバリ領域から削除するファイルを制御する安全で確実な方法は 保存方針を変更することです 予測されるリストアおよびリカバリの回数を最小限にするために テープに移動したファイルをディスクにも保持し続ける可能性を大きくする場合は フラッシュ リカバリ領域の割当て制限を大きくしてください フラッシュ リカバリ領域で領域が使用不可の場合 たとえば Recovery Manager の保存方針でフラッシュ リカバリ領域のディスク割当て制限よりも大きいバックアップのセットを保持する必要がある場合 または保存方針が NONE に設定されている場合 フラッシュ リカバリ領域は 再利用可能な領域がない状態で 領域を 100% 使用することができます 再利用可能な領域が 15% 未満になると警告アラートが発行され 3% 未満になると重大アラートが発行されます この状況を DBA に警告するために アラート ログおよび DBA_ OUTSTANDING_ALERTS 表 (Enterprise Manager で使用 ) にエントリが追加されます ただし データベースはフラッシュ リカバリ領域内に再利用可能な領域がなくなるまで領域を使い続けます リカバリ領域が完全に一杯になると 次のエラー メッセージが表示されます ORA-19809: limit exceeded for recovery files ORA-19804: cannot reclaim nnnnn bytes disk space from mmmmm limit nnnnn は必要なバイト数 mmmm はフラッシュ リカバリ領域のディスク割当て制限です 再利用可能な領域が不足しているフラッシュ リカバリ領域は 一杯になった状態のディスクと同じように処理されます 通常はデータベースがハングアップしますが これ以外の場合もあります たとえば 必須の REDO ログのアーカイブ先の 1 つであるフラッシュ リカバリ領域が一杯になったために新しいログをアーカイブできない場合 構成によっては リカバリ領域に空き領域が確保されるまで アーカイバがリカバリを定期的に再試行することがあります 一杯になった状態のディスクに対して Oracle の特定の機能がどのように応答するかについては その機能に関するマニュアルを参照してください 参照 : フラッシュ リカバリ領域が頻繁に割当て制限を越え 削除対象のファイルがない場合の対処方法については 8-19 ページの フラッシュ リカバリ領域が一杯になった場合の解決方法 を参照してください ディスク ベースのバックアップ用のフラッシュ リカバリ領域の構成 : 例 ここで示す例では データベースが次のように構成されています アーカイブ ログおよび Recovery Manager バックアップは フラッシュ リカバリ領域に格納されます 制御ファイルとオンライン REDO ログのコピーは フラッシュ リカバリ領域の外部にあるファイル システム内のディレクトリに格納されます データ ファイルのサイズは 3GB 以下と想定されます 保持されるアーカイブ REDO ログ ファイルは 4GB 以下です この例のバックアップ計画は 増分バックアップに基づいています 制御ファイルは フラッシュ リカバリ領域に自動的にバックアップされます フラッシュ リカバリ領域のサイズは 10GB に指定されています これは 制御ファイルの自動バックアップ データベース全体のレベル 0 の増分バックアップ (3GB のデータ ファイルのイメージ コピーで構成される ) の他に いくつかのレベル 1 の増分バックアップを格納するのに十分な大きさです 3-20 Oracle Database バックアップおよびリカバリ基礎

67 Recovery Manager 用のフラッシュ リカバリ領域の設定 この計画を実装するため パラメータ ファイルには次のエントリが含まれます DB_NAME=sample # set location for current datafiles: DB_CREATE_FILE_DEST = '/u02/oradata/wrk_area' # set location for control files and online redo logs: DB_CREATE_ONLINE_LOG_DEST_1 = '/u03/oradata/wrk_area' DB_CREATE_ONLINE_LOG_DEST_2 = '/u04/oradata/wrk_area' # set flash recovery area location and size DB_RECOVERY_FILE_DEST = '/u01/oradata/rcv_area' DB_RECOVERY_FILE_DEST_SIZE = 10G このパラメータ ファイルでは LOG_ARCHIVE_DEST_n パラメータのいずれも設定されていないため アーカイブ ログはフラッシュ リカバリ領域にのみ送信されます ターゲット データベースを起動すると 次の Recovery Manager コマンドによって 保存方針 バックアップの最適化および制御ファイルの自動バックアップが構成されます RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 1; RMAN> CONFIGURE BACKUP OPTIMIZATION ON; RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON; これで すべてのディスクベースのバックアップがフラッシュ リカバリ領域に保存されます 参照 : この環境で実行可能なバックアップ ジョブの例は A-2 ページの ディスク専用バックアップのスクリプト作成 を参照してください フラッシュ リカバリ領域での多重化ファイルを使用したデータベースの作成 : 例 次のプロパティを持つデータベースを作成すると想定します 単一のファイル システム ディレクトリに 制御ファイル データ ファイルおよびオンライン REDO ログが Oracle 管理ファイルとして格納されます 制御ファイルの多重化コピーの 1 つが フラッシュ リカバリ領域に保持されます オンライン REDO ログの多重化コピーが フラッシュ リカバリ領域に保持されます REDO ログ ファイルが フラッシュ リカバリ領域と 作業領域とは別のファイル システムの両方にアーカイブされます デフォルトで Recovery Manager バックアップがフラッシュ リカバリ領域に保存されます 参照 : フラッシュ リカバリ領域でのファイルの作成については Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください フラッシュ リカバリ領域でデータベースを作成する方法 1. フラッシュ リカバリ領域を使用するために必要な初期化パラメータを含むデータベースの PFILE を作成し オンライン ログ アーカイブ ログおよび制御ファイルのコピーを指定します 次のように設定するとします # set DB_NAME DB_NAME=sample # set destination for OMF datafiles, control file and online redo logs DB_CREATE_FILE_DEST = /u01/oradata/wrk_area/ # set log archiving destinations to a file system location # and the flash recovery area LOG_ARCHIVE_DEST_1 = 'LOCATION=/arc_dest1' LOG_ARCHIVE_DEST_2 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST' # multiplexed copies of control file and online logs in flash recovery area バックアップおよびリカバリの設定と構成 3-21

68 Recovery Manager 用のフラッシュ リカバリ領域の設定 # rman backups also go here DB_RECOVERY_FILE_DEST = 'LOCATION=/u01/oradata/rcv_area' DB_RECOVERY_FILE_DEST_SIZE = 10G DB_CREATE_FILE_DEST パラメータでは すべてのデータ ファイル オンライン ログおよび制御ファイルのデフォルト ディレクトリを設定します 制御ファイルおよびオンライン ログのもう 1 つのコピーは フラッシュ リカバリ領域に作成されます 2. 初期化パラメータの設定後 データベースを作成します たとえば SQL*Plus を起動し 次のように入力します SQL> CREATE DATABASE sample; この文の結果を次に示します データ ファイルが DB_CREATE_FILE_DEST に Oracle 管理ファイルとして作成されます LOGFILE 句が含まれていなかったため デフォルトでオンライン ログ グループが作成されます 各グループが 2 つのメンバーで構成されます 1 つは DB_CREATE_FILE_DEST で もう 1 つは DB_RECOVERY_FILE_DEST にあります CONTROL_FILES パラメータが設定されていなかったため Oracle は DB_CREATE_FILE_DEST( プライマリ ) と DB_RECOVERY_FILE_DEST( 多重化コピー ) に制御ファイルを作成します Linux システムでは ファイル名は次のようになります /u02/oradata/wrk_area/sample/controlfile/o1_mf_3ajeikm_.ctl #primary ctlfile /u01/oradata/rcv_area/sample/controlfile/o1_mf_6adjkid_.ctl #ctl file copy /u02/oradata/wrk_area/sample/logfile/o1_mf_0_orrm31z_.log #log grp1, mem 1 /u01/oradata/rcv_area/sample/logfile/o1_mf_1_ixfvm8w9).log #log grp 1 mem 2 /u02/oradata/wrk_area/sample/logfile/o1_mf_2_2xyz16am_.log # log grp2, mem 1 /u01/oradata/rcv_area/sample/logfile/o1_mf_2_q89tmp28_.log #log grp 2, mem 2 REDO ログのアーカイブ先として LOG_ARCHIVE_DEST_1 および LOG_ARCHIVE_DEST_2 を使用します LOG_ARCHIVE_DEST_2 がフラッシュ リカバリ領域として構成されているため アーカイブ REDO ログ ファイルはフラッシュ リカバリ領域に作成されます ローカルの REDO ログのアーカイブ先を使用可能にしたため Oracle は 自動的には LOG_ARCHIVE_DEST_10 をフラッシュ リカバリ領域には設定しません フラッシュ リカバリ領域のアーカイブ REDO ログのファイル名は LOG_ARCHIVE_FORMAT パラメータには基づかない Oracle 管理のファイル名になります たとえば 次のようにアーカイブ ログを作成します ALTER SYSTEM ARCHIVE LOG CURRENT; アーカイブ ログ ファイルは プライマリのアーカイブ先の他に 次のフラッシュ リカバリ領域のサブディレクトリにも作成されます /u01/oradata/rcv_area/sample/archivelog/yyyy_mm_dd YYYY_MM_DD は作成日の書式です 3. このデータベースに対し さらにオンライン REDO ログ グループを作成することもできます これを行うには SQL*Plus で ALTER DATABASE ADD LOGFILE 文を使用します ファイル名を指定しないと すでに指定済のオンライン ログのアーカイブ先 ( フラッシュ リカバリ領域を含む ) にログ ファイル メンバーがもう 1 つ作成されます たとえば 次の文では DB_CREATE_FILE_DEST に 1 つと DB_RECOVERY_FILE_DEST に 1 つのメンバーを持つ新しいログ グループが作成されます ALTER DATABASE ADD LOGFILE; 3-22 Oracle Database バックアップおよびリカバリ基礎

69 Recovery Manager 用のフラッシュ リカバリ領域の設定 フラッシュ リカバリ領域でのアーカイブ ログのみを使用したデータベースの作成 : 例 単一のファイル システム ディレクトリに Oracle 管理ファイルの制御ファイル データ ファイルおよびオンライン REDO ログで構成されるデータベースを作成すると仮定します さらに 次の作業も実行する必要があると仮定します フラッシュ リカバリ領域への各 REDO ログのアーカイブ ( フラッシュ リカバリ領域のみ ) フラッシュ リカバリ領域への Recovery Manager バックアップのデフォルトの送信 参照 : フラッシュ リカバリ領域でのファイルの作成については Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください フラッシュ リカバリ領域でデータベースを作成する方法 1. 関連する初期化パラメータを設定します 次のように設定するとします DB_NAME=sample DB_CREATE_FILE_DEST = '/u02/oradata/wrk_area' DB_RECOVERY_FILE_DEST = '/u01/oradata/rcv_area' DB_RECOVERY_FILE_DEST_SIZE = 10G # if you set the following parameters, then the online redo logs *and* # current control file are located here DB_CREATE_ONLINE_LOG_DEST_1 = '/u03/oradata/wrk_area' DB_CREATE_ONLINE_LOG_DEST_2 = '/u04/oradata/wrk_area' DB_CREATE_FILE_DEST パラメータでは データ ファイルのデフォルトのファイル システム ディレクトリを設定します DB_CREATE_ONLINE_LOG_DEST_n パラメータでは オンライン REDO ログと制御ファイルのデフォルトのファイル システム ディレクトリを設定します DB_RECOVERY_FILE_DEST パラメータでは アーカイブ ログのファイル システム ディレクトリを設定します 2. 初期化パラメータの設定後 データベースを作成します たとえば SQL*Plus を起動し 次のように入力します CREATE DATABASE sample; オンライン REDO ログや制御ファイルの多重化コピーは フラッシュ リカバリ領域に作成されません 3. フラッシュ リカバリ領域を使用可能にしたため Oracle は 自動的に LOG_ARCHIVE_DEST_10 をフラッシュ リカバリ領域に設定します フラッシュ リカバリ領域のファイル名は LOG_ARCHIVE_FORMAT パラメータには基づかない Oracle 管理のファイル名になります たとえば 次のようにアーカイブ ログを作成します ALTER SYSTEM ARCHIVE LOG CURRENT; Linux の場合 この文では 次のフラッシュ リカバリ領域のサブディレクトリにアーカイブ ログが作成されます /u01/oradata/rcv_area/sample/archivelog/yyyy_mm_dd (YYYY_MM_DD は作成日の書式 ) 4. オンライン REDO ログ グループをさらに追加する必要がある場合は ALTER DATABASE ADD LOGFILE 文を実行します ファイル名を指定しないと DB_CREATE_ONLINE_LOG_DEST_n のそれぞれの位置に 別のログ ファイル メンバーが作成されます ( ただしフラッシュ リカバリ領域には作成されません ) たとえば 次のように入力します ALTER DATABASE ADD LOGFILE; バックアップおよびリカバリの設定と構成 3-23

70 Recovery Manager 用のフラッシュ リカバリ領域の設定 Linux の場合 この文では /u03/oradata/wrk_area/sample/logfile に 1 つと /u04/oradata/wrk_area/sample/logfile に 1 つのメンバーが作成されます その他のプラットフォームでは 特定のファイルとディレクトリがプラットフォーム依存の名前になります 3-24 Oracle Database バックアップおよびリカバリ基礎

71 4 Recovery Manager を使用したデータベースのバックアップ この章では Recovery Manager を使用した最も一般的なバックアップ タスクを実行する方法およびバックアップ計画を実装する方法について説明します この章では 次の項目について説明します Recovery Manager バックアップの概要 Recovery Manager を使用したデータベース ファイルおよびアーカイブ ログのバックアップ Recovery Manager の増分バックアップ Recovery Manager を使用したデータベース ファイルの検証 バックアップおよび Recovery Manager リポジトリのレポートの概要 Recovery Manager バックアップ アーカイブ ログおよびデータベース インカネーションの表示 バックアップおよびデータベース スキーマのレポート 注意 : ディスクのみのバックアップ計画およびディスクとテープを使用するバックアップ計画の詳細な例およびスクリプトは 付録 A Recovery Manager ベースのディスクおよびテープのバックアップ計画の例 を参照してください これらの計画は データベースの更新アクティビティのレベル バックアップに割り当てられるディスク領域およびデータベースのリカバリ可能性の要件によって分類されます それぞれの計画に対して 初期設定 および毎日または毎週のバックアップに関する Recovery Manager コマンドが提供されています 増分更新バックアップやフラッシュ リカバリ領域の使用など Recovery Manager でサポートされる様々な形式のバックアップについてよく理解した後 独自のバックアップ計画を立案するために付録 A に示す例を参照してください この章で説明する多くのバックアップ方法は Oracle Enterprise Manager で提供されるバックアップ計画にも使用されます ( Oracle Database 2 日でデータベース管理者 を参照 ) リストア ポイントおよび Oracle Flashback Database では ここで示すバックアップ機能を補完する機能が提供されます これらの機能を使用すると 不要な変更を後で元に戻すことができるように データベースを事前に設定しておくことができます バックアップおよびリカバリ計画にこれらを組み込むことをお薦めします これらの機能の詳細は 第 4 章 Recovery Manager を使用したデータベースのバックアップ を参照してください Recovery Manager を使用したデータベースのバックアップ 4-1

72 Recovery Manager バックアップの概要 Recovery Manager バックアップの概要 データベースの全体または一部をバックアップするには Recovery Manager クライアント内から BACKUP コマンドを実行します Recovery Manager は データベースの構成設定とチャネル Recovery Manager リポジトリの以前のバックアップの記録 および制御ファイルのデータベース構造の記録を使用して BACKUP コマンドに対応して実行する特定の手順の効率的なセットを決定し その手順を実行します 多くの場合 データベースがバックアップ計画に従って構成されていれば 次のような単純なコマンドを使用してデータベース全体の Recovery Manager バックアップを実行できます RMAN> BACKUP DATABASE; Recovery Manager によるバックアップが可能なファイル Recovery Manager の BACKUP コマンドでは 次のファイルのバックアップがサポートされています データベース ファイル ( データ ファイル 制御ファイルおよびサーバー パラメータ ファイル (SPFILE) を含む ) アーカイブ REDO ログ Recovery Manager によって作成された他のバックアップ ( データ ファイルと制御ファイルのイメージ コピーや SPFILE 制御ファイル データ ファイルおよびアーカイブ ログを含むバックアップ セットなど ) データベースの操作には その他のファイル ( ネットワーク構成ファイル パスワード ファイル Oracle ホームの内容など ) も必要ですが これらのファイルは Recovery Manager ではバックアップできません 同様に Oracle の一部の機能 ( 外部表など ) には 情報を格納するために データ ファイル 制御ファイルおよび REDO ログ以外のファイルが必要な場合があります Recovery Manager では これらのファイルをバックアップできません リストにないファイルについては Recovery Manager 以外の方法でバックアップします Recovery Manager バックアップの形式 : イメージ コピーおよびバックアップ セット Recovery Manager バックアップは イメージ コピーイメージ コピーまたはバックアップ セットバックアップ セットのいずれかの形式で格納できます イメージ コピー イメージ コピーとは データベース ファイルをビット単位で正確に複製したものであり オペレーティング システムのコマンドで作成されたコピーと同じです ( ただし オペレーティング システム レベルのコマンドを使用して作成されたファイルのコピーとは異なり Recovery Manager で作成されたイメージ コピーは Recovery Manager リポジトリに記録されます ) イメージ コピーのバックアップは ディスク上に作成できます Recovery Manager では データ ファイル データ ファイルのコピー 制御ファイル 制御ファイルのコピー アーカイブ REDO ログおよびバックアップ ピースのイメージ コピーが作成されます Recovery Manager は BACKUP コマンドで AS COPY オプションを使用した場合に イメージ コピーを作成します 参照 : Recovery Manager でのイメージ コピーの処理の詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください 4-2 Oracle Database バックアップおよびリカバリ基礎

73 Recovery Manager バックアップの概要 バックアップ セット Recovery Manager では バックアップ セットバックアップ セットという論理構造にバックアップ情報を格納することもできます バックアップ セットには データ ファイル アーカイブ REDO ログ 制御ファイルまたは SPFILE のデータが格納されます ( データ ファイルおよびアーカイブ ログを同じバックアップ セットに格納することはできません ) 既存のバックアップ セットを別のバックアップ セットにバックアップすることもできます バックアップ セットは Recovery Manager 固有の形式のファイルであるバックアップ ピースというファイルで構成されます デフォルトでは バックアップ セットは 1 つのバックアップ ピースで構成されます たとえば 10 個のデータ ファイルを 単一のバックアップ ピースで構成される単一のバックアップ セットにバックアップできます ( つまり 1 つのバックアップ ピースが出力として作成され バックアップ ピースを含む単一のファイルで構成されるバックアップ セット およびバックアップ ピースとそのバックアップ ピースを含むバックアップ セットが Recovery Manager リポジトリに記録されます ) ファイルを複数のバックアップ セットに分割することはできません 注意 : バックアップ セットは バックアップの最小単位です Recovery Manager は 完全なバックアップ セットのみをリポジトリに記録します 部分バックアップ セットのような操作はありません 個々のバックアップ ピースを操作することはできません バックアップ セットの作成や バックアップ セットからのリカバリを実行できるのは Recovery Manager のみです 複数のファイルが同じバックアップ セットにバックアップされている場合 それらのファイルは同時に読み取られ そのデータは多重化されます バックアップ セットは Recovery Manager がテープなどのメディア マネージャ デバイス上で実行できる唯一のバックアップ タイプです バックアップ セットは ディスク上に作成することもできます Recovery Manager では デフォルトでディスクおよびテープの両方に バックアップがバックアップ セットとして作成されます データ ファイルをバックアップ セットにバックアップする場合 Recovery Manager では 現在データが含まれていないデータ ファイル ブロックをいくつかスキップして バックアップ セットのサイズを小さくし バックアップ セットの作成に必要な時間を短縮することができます この動作は 未使用ブロックの圧縮未使用ブロックの圧縮と呼ばれ バックアップ セットによるデータ ファイルのバックアップは 通常 イメージ コピーのバックアップより小さくなり 書込み時間も短縮されます この動作は Recovery Manager がバックアップ ピースにデータ ファイルを書き込む際の基本的な方法であり 無効にすることはできません 未使用ブロックをスキップする方法とタイミングについては Oracle Database バックアップおよびリカバリ リファレンス を参照してください Recovery Manager は バックアップ セットのバイナリ圧縮もサポートします この圧縮では バックアップ セットの内容はディスクに書き込まれる前に データ ファイルおよびアーカイブ ログ ファイルの圧縮用にチューニングされた圧縮アルゴリズムを使用して圧縮されます バイナリ圧縮の使用方法については 4-6 ページの Recovery Manager によるバックアップでの圧縮バックアップ セットの使用 を参照してください Recovery Manager によるデータ ファイルの全体バックアップおよび増分バックアップ Recovery Manager によるデータ ファイルのバックアップは データ ファイルの全体バックアップまたは増分バックアップのいずれかにすることができます データ ファイルの全体バックアップは ファイル内のすべての使用済データ ブロックを含むバックアップです データ ファイルの全体バックアップをイメージ コピーとして作成する場合は ファイルの内容全体がそのまま再作成されます ( データ ファイルをバックアップ セットにバックアップする場合は 未使用ブロックをスキップすることができます 4-3 ページの バックアップ セット を参照してください ) Recovery Manager を使用したデータベースのバックアップ 4-3

74 Recovery Manager の BACKUP コマンドの出力に影響するオプションの指定 データ ファイルの増分バックアップでは 特定の時点 ( 通常は前回の増分バックアップの時点 ) 以降に変更されたデータ ファイル内のブロックのイメージが取得されます 増分バックアップは 常にバックアップ セットとして格納されます その結果 データ ファイル内のすべてのブロックを変更しないかぎり バックアップ セットはデータ ファイルの全体バックアップより小さくなります Recovery Manager が作成できるのはデータ ファイルの増分バックアップのみで アーカイブ REDO ログ ファイルなどのファイルの増分バックアップは作成できません メディア リカバリ時には Recovery Manager は増分バックアップのブロック イメージを使用し 変更されたブロックを そのブロックが作成されたときの SCN の内容に対して 1 回の手順で更新します 増分バックアップがない場合は すべての変更をアーカイブ REDO ログから 1 つずつ適用する必要があります したがって 増分バックアップを使用するリカバリは 変更をアーカイブ REDO ログから 1 つずつ適用するよりも短時間で行うことができます また 増分バックアップでは NOLOGGING 操作によって行われ REDO ログには記録されないデータ ブロックに対する変更も取得されます このため メディア リカバリ時に増分バックアップが使用できる場合 Recovery Manager ではアーカイブ ログのかわりに増分バックアップが常に使用されます Recovery Manager の BACKUP コマンドの出力に影響するオプションの指定 Recovery Manager コマンドに対して最小限の必須オプションのみを指定した場合 (BACKUP DATABASE など ) Recovery Manager によって バックアップ先デバイス バックアップ出力の場所 およびバックアップ用のタグが 構成済の環境と Recovery Manager の組込み済のデフォルト値に基づいて自動的に決定されます ただし BACKUP に引数を指定して これらのデフォルト値と構成済の設定を上書きするこができます この項では 一般的な次の項目を説明します Recovery Manager の BACKUP に対する出力デバイス タイプの指定 Recovery Manager の BACKUP に対するイメージ コピーまたはバックアップ セットの出力のディスクへの指定 Recovery Manager の BACKUP に対する出力ファイルの場所の指定 Recovery Manager の BACKUP に対するタグの指定 Recovery Manager の BACKUP に対する出力デバイス タイプの指定 BACKUP コマンドでは DEVICE TYPE 句を使用して バックアップ先をディスクにするか SBT デバイスにするかを指定します 次に例を示します BACKUP DATABASE DEVICE TYPE DISK; DEVICE TYPE 句を指定しないで BACKUP を使用すると バックアップは構成済のデフォルトのデバイス (DISK または sbt) に格納されます このデバイスは CONFIGURE DEFAULT DEVICE TYPE を使用して設定されます 詳細は 3-9 ページの バックアップ用のデフォルト デバイス タイプの構成 を参照してください Recovery Manager の BACKUP に対するイメージ コピーまたはバックアップ セットの出力のディスクへの指定 前述のとおり Recovery Manager では バックアップをイメージ コピーまたはバックアップ セットとしてディスクに作成できます デフォルトの出力タイプの設定については 3-10 ページの ディスク バックアップ用のデフォルト バックアップ タイプの構成 を参照してください このデフォルト値は AS COPY 句または AS BACKUPSET 句を BACKUP コマンドに指定して上書きできます データをイメージ コピーとしてディスクにバックアップするには BACKUP AS COPY を使用します BACKUP AS COPY DEVICE TYPE DISK DATABASE; 4-4 Oracle Database バックアップおよびリカバリ基礎

75 Recovery Manager の BACKUP コマンドの出力に影響するオプションの指定 データをバックアップ セットにバックアップするには BACKUP AS BACKUPSET 句を使用します バックアップ セットは構成済のデフォルトのデバイスに作成したり バックアップ セットをディスクまたはテープに明示的に指定することもできます 次に例を示します BACKUP AS BACKUPSET DATABASE; BACKUP AS BACKUPSET DEVICE TYPE DISK DATABASE; BACKUP AS BACKUPSET DEVICE TYPE SBT DATABASE; Recovery Manager の BACKUP に対する出力ファイルの場所の指定 Recovery Manager では 優先順位の順序で示されている次のルール セットに基づいて バックアップからの出力に一意のファイル名が生成されます 個々の BACKUP コマンドで FORMAT 句を指定して 出力を特定の場所に指定できます 次に例を示します BACKUP DATABASE FORMAT="/tmp/backup_%U"; この場合のバックアップは 生成された一意のファイル名が付けられ /tmp/backups/ に格納されます %U は必須で ファイル名のこの位置で一意の文字列を生成するために使用されます また 次のように FORMAT 句を使用して バックアップ先として ASM ディスク グループを指定することもできます RMAN> BACKUP DATABASE FORMAT '+dgroup1'; # sets an ASM disk group この場合 %U は必須ではありません これは ASM が必要に応じて一意のファイル名を生成するためです FORMAT 設定がバックアップで使用される特定のチャネル用に構成されている場合 生成されるファイル名の制御はこの設定によって行われます FORMAT 設定がバックアップで使用されるデバイス タイプ用に構成されている場合 生成されるファイル名の制御はこの設定によって行われます バックアップがディスク バックアップであり フラッシュ リカバリ領域が構成されている場合 バックアップは自動的に生成された名前でフラッシュ リカバリ領域に格納されます このリストの前述の条件が適用されない場合 デフォルトの場所とファイル名の形式はプラットフォームによって異なります Recovery Manager の BACKUP に対するタグの指定 Recovery Manager で作成されたすべてのバックアップには 将来 Recovery Manager コマンドで使用可能なバックアップであることを示す方法として タグタグと呼ばれる識別子が添付されます BACKUP コマンドを使用する場合 特定のコマンドを使用して 作成したバックアップに割り当てるタグを指定できます 特定の時間に作成したバックアップを識別するためにこのタグを使用できます たとえば 2003_year_end のように使用します また 長期にわたって作成される一連のバックアップに対し 1 つのタグを繰り返して使用することもできます たとえば 毎週作成する一連の増分バックアップに weekly_incremental などのタグをラベル付けできます 実際に タグを使用して 増分バックアップ計画など 単一の計画の一部として作成された一連のバックアップであることを区別する場合があります BACKUP コマンドの様々な形式を使用して タグとバックアップを関連付けることができます また 多くの RESTORE および RECOVER コマンドでは タグを指定して RESTORE または RECOVER 操作で使用するバックアップを制限できます タグを指定しないで BACKUP コマンドを使用すると Recovery Manager によって一意のタグが生成され このコマンドで作成されたバックップに割り当てられます Recovery Manager を使用したデータベースのバックアップ 4-5

76 Recovery Manager の BACKUP コマンドの出力に影響するオプションの指定 バックアップのグループを識別するためにタグを指定するには BACKUP コマンドの TAG 句を使用します 次に例を示します RMAN> BACKUP DATABASE TAG = 'weekly_backup'; # gives the backup a tag identifier BACKUP コマンドで TAG 句を使用してタグをバックアップに割り当てていない場合は Recovery Manager によって自動的にタグが生成され バックアップに割り当てられます 注意 : タグに使用される文字は ターゲット ファイル システムのファイル名で正しく使用できる文字に制限する必要があります たとえば ASM では内部的に使用するファイル名で - という文字の使用がサポートされないため ASM ディスク グループにバックアップを格納する場合 - が含まれるタグ (weekly-incremental など ) は正しいタグ名ではありません 参照 : BACKUP... TAG のデフォルト形式については Oracle Database バックアップおよびリカバリ リファレンス を参照してください Recovery Manager によるバックアップでの圧縮バックアップ セットの使用 バックアップ セットを作成する BACKUP コマンドを使用すると AS COMPRESSED BACKUPSET オプションを指定することで Recovery Manager でサポートされているバックアップ セットのバイナリ圧縮を利用できます その結果 バックアップ セットは Oracle データベース ファイルの効果的な圧縮用に最適化されたアルゴリズムを使用して圧縮されます Recovery Manager の統合された圧縮を使用すると リカバリ時に他の解凍手順は必要ありません Recovery Manager のバイナリ圧縮の使用での主なデメリットは バックアップ時およびリストア時のパフォーマンスのオーバーヘッドです 圧縮バックアップ セットを作成する際のパフォーマンスは CPU に依存します 複数の CPU を使用している場合は 複数の CPU でジョブを実行するために並列度を増やすことができるため パフォーマンスを改善できます 注意 : テープにバックアップしている場合で テープ デバイスが独自の圧縮を実行する場合は Recovery Manager のバックアップ セット圧縮およびメディア マネージャ ベンダーの圧縮の両方を使用しないでください ほとんどの場合 メディア マネージャの圧縮を使用する方が 精度の高い圧縮が可能です 詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド の Recovery Manager によるテープ バックアップのパフォーマンス チューニングの説明を参照してください 次の例では データベース全体とアーカイブ ログを 構成済のデフォルトのバックアップ先 ( ディスクまたはテープ ) にバックアップし 圧縮バックアップ セットを作成します BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG; 次の例では バイナリ圧縮を使用して 複数のデータ ファイルをデフォルトのデバイスにバックアップします BACKUP AS COMPRESSED BACKUPSET DATAFILE 1,2,4; 圧縮バックアップ セットを作成すると バックアップ時およびリストア時に非常に大きい余分な CPU オーバーヘッドが発生します これによって バックアップの処理速度が低下する場合があります ただし 次のような状況では パフォーマンスが低下しても有効な場合があります ディスクベースのバックアップを使用している場合で フラッシュ リカバリ領域またはその他のディスクベースのバックアップ先のディスク領域が制限されている場合 4-6 Oracle Database バックアップおよびリカバリ基礎

77 Recovery Manager を使用したデータベース ファイルおよびアーカイブ ログのバックアップ あるデバイスにネットワーク経由でバックアップを実行している場合で 削減されたネットワーク帯域幅が CPU 使用量より重要な場合 CD や DVD などのアーカイブ バックアップ メディアを使用している場合 ( この場合 バックアップ サイズが縮小されるので メディアのコストおよびアーカイブ領域を削減できます ) バックアップ セットのバイナリ圧縮を使用する場合のパフォーマンスについては Oracle Database バックアップおよびリカバリ リファレンス にある BACKUP コマンドの AS COMPRESSED BACKUPSET オプションの説明を参照してください Recovery Manager を使用したデータベース ファイルおよびアーカイブ ログのバックアップ この項では次の項目を取り上げます Recovery Manager を使用した一貫性バックアップおよび非一貫性バックアップの作成 Recovery Manager の BACKUP コマンドの出力に影響するオプションの指定 Recovery Manager を使用したデータベース全体のバックアップの作成 Recovery Manager を使用した個々の表領域のバックアップ Recovery Manager を使用した個々のデータ ファイルおよびデータ ファイルのコピーのバックアップ Recovery Manager を使用した制御ファイルのバックアップ Recovery Manager を使用したサーバー パラメータ ファイルのバックアップ Recovery Manager を使用したアーカイブ REDO ログのバックアップ Recovery Manager を使用した一貫性バックアップおよび非一貫性バックアップの作成 データベースの一貫性バックアップ一貫性バックアップは データベースに一貫性がある状態 つまり SHUTDOWN NORMAL SHUTDOWN IMMEDIATE または SHUTDOWN TRANSACTIONAL を使用して正常に停止された後で行われるバックアップです 正常に停止した時点で REDO ログのすべての変更はデータ ファイルに適用されています データベースをマウントし この時点のバックアップを作成すると 将来 メディア リカバリを実行しないで このバックアップからデータベースをリストアしてオープンすることができます データベースが正常に停止されていないときに作成されたバックアップは すべて非一貫性バックアップです 非一貫性バックアップからデータベースをリストアする場合 Oracle では データベースをオープンする前に メディア リカバリを実行し REDO ログ内の保留中の更新情報を適用する必要があります データベースが ARCHIVELOG モードで実行されていて アーカイブ REDO ログ ファイルとデータ ファイルがバックアップされているかぎり 非一貫性バックアップは 適切なバックアップおよびリカバリ計画の基礎となります 非一貫性バックアップには優れた可用性があるため ほとんどのデータベースのバックアップ計画で重要な役割を果たします たとえば データベースをオープンさせたまま作成するバックアップは非一貫性バックアップです 注意 : ユーザー管理のバックアップを実行する場合 オンライン バックアップを取るには ALTER DATABASE/TABLESPACE BEGIN BACKUP 文を使用して データ ファイルをバックアップ モードにする必要がありました Recovery Manager では オンライン バックアップを作成するために バックアップ モードを使用する必要はありません Recovery Manager バックアップの前に ALTER DATABASE/TABLESPACE BEGIN BACKUP 文を使用しないでください Recovery Manager を使用したデータベースのバックアップ 4-7

78 Recovery Manager を使用したデータベース ファイルおよびアーカイブ ログのバックアップ Recovery Manager を使用したデータベース全体のバックアップの作成 データベース全体のバックアップは データベースをマウントまたはオープンして実行できます データベース全体のバックアップを実行するには Recovery Manager プロンプトで BACKUP DATABASE コマンドを実行します このコマンドの最も単純な形式ではパラメータは必要ありません 次に例を示します RMAN> BACKUP DATABASE; 次に デフォルトの宛先にデータベース全体のバックアップを取るプロシージャの例を示します RMAN> BACKUP DATABASE; # uses automatic channels to make backup RMAN> SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; # switches logs and archives all logs バックアップ直後にログをアーカイブすることで このバックアップでアーカイブ ログの完全なセットができます これによって このバックアップのリストア後にメディア リカバリを実行できます Recovery Manager を使用した個々の表領域のバックアップ BACKUP TABLESPACE コマンドを使用すると 個々の表領域をバックアップできます このコマンドは データベースがマウントまたはオープンされているときに使用できます 表領域をバックアップする方法 Recovery Manager を起動した後 Recovery Manager プロンプトで BACKUP TABLESPACE コマンドを実行します 次の例では 10MB を超えるバックアップ セットがないことを指定する MAXSETSIZE パラメータを使用して users および tools 表領域をテープにバックアップします BACKUP DEVICE TYPE sbt MAXSETSIZE = 10M TABLESPACE users, tools; 表領域名が 内部的にデータ ファイルのリストに変換されます Recovery Manager を使用した個々のデータ ファイルおよびデータ ファイルのコピーのバックアップ データ ファイルおよびデータ ファイルのコピーは データベースがマウントまたはオープンされているときにバックアップできます データ ファイルのバックアップ Recovery Manager をターゲット データベースに接続し BACKUP DATAFILE コマンドを使用して 個々のデータ ファイルをバックアップします データ ファイルは 名前または番号で指定できます 次の例では sbt チャネルを使用して データ ファイル 1 ~ 4 および /tmp/system01.dbf に格納されているデータ ファイルのコピーをテープにバックアップします BACKUP DEVICE TYPE sbt DATAFILE 1,2,3,4 DATAFILECOPY '/tmp/system01.dbf'; CONFIGURE CONTROLFILE AUTOBACKUP が ON の場合 Recovery Manager は 現行の制御ファイルおよび SPFILE を別々の自動バックアップ ピースに書き込みます それ以外の場合 これらのファイルは データ ファイル 1 を含むバックアップ セットに自動的に含められます 4-8 Oracle Database バックアップおよびリカバリ基礎

79 Recovery Manager を使用したデータベース ファイルおよびアーカイブ ログのバックアップ データ ファイルのコピーのバックアップ BACKUP DATAFILECOPY コマンドを使用して データ ファイルのコピーをバックアップします データ ファイルのコピーは ディスク上にのみ存在します データ ファイルのコピーをバックアップする方法ターゲット データベースに接続し Recovery Manager プロンプトで BACKUP DATAFILECOPY コマンドを実行します 次の例では データ ファイル /tmp/system01.dbf をテープにバックアップします BACKUP DEVICE TYPE sbt DATAFILECOPY '/tmp/system01.dbf'; Recovery Manager を使用した制御ファイルのバックアップ 制御ファイルは データベースがマウントまたはオープンされているときにバックアップできます Recovery Manager は スナップショット制御ファイルを使用して 読取り一貫性のバージョンを保証します CONFIGURE CONTROLFILE AUTOBACKUP が ON( デフォルトでは OFF) の場合 Recovery Manager は バックアップするたび およびデータベースの構造を変更するたびに 制御ファイルおよびサーバー パラメータ ファイルを自動的にバックアップします 制御ファイルの自動バックアップには 以前のバックアップに関するメタデータが含まれます このメタデータは 障害時リカバリに重要です 自動バックアップ機能が設定されてない場合は 次のいずれかの方法で 制御ファイルを手動でバックアップする必要があります BACKUP CURRENT CONTROLFILE を実行する BACKUP コマンドの INCLUDE CURRENT CONTROLFILE オプションを使用して 制御ファイルのバックアップをいずれかのバックアップに含める Recovery Manager は自動的に制御ファイルおよび SPFILE をデータ ファイル 1 のバックアップに含めるため データ ファイル 1 をバックアップする 注意 : 制御ファイルのブロック サイズがデータ ファイル 1 のブロック サイズと異なる場合は 制御ファイルをデータ ファイルと同じバックアップ セットに書き込むことはできません ブロック サイズが異なる場合 Recovery Manager は制御ファイルを単独でバックアップ セットに書き込みます 制御ファイルの手動バックアップは 制御ファイルの自動バックアップとは異なります 手動バックアップでは 現行の Recovery Manager セッションでバックアップする Recovery Manager リポジトリのデータのみが制御ファイルのバックアップに含められ 手動でバックアップされた制御ファイルを自動的にリストアすることはできません 参照 : 制御ファイルの自動バックアップの詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください 他のファイルの現行の制御ファイルをバックアップに含める 現行の制御ファイルをバックアップに含めるには バックアップ オブジェクトを指定した後 INCLUDE CURRENT CONTROLFILE オプションを指定します 次の例では デフォルトの構成済チャネルは sbt デバイスに設定されています このコマンドによって 表領域 users がテープにバックアップされ 現行の制御ファイルがバックアップに含められます BACKUP DEVICE TYPE sbt TABLESPACE users INCLUDE CURRENT CONTROLFILE; 自動バックアップ機能が有効な場合 Recovery Manager は BACKUP TABLESPACE コマンドが完了した後 制御ファイルの自動バックアップも作成します これによって 制御ファイルの自動バックアップには 作成されたバックアップの記録も含まれます Recovery Manager を使用したデータベースのバックアップ 4-9

80 Recovery Manager を使用したデータベース ファイルおよびアーカイブ ログのバックアップ 現行の制御ファイルの手動バックアップ Recovery Manager を起動した後 BACKUP CURRENT CONTROLFILE コマンドを実行します 次の例では 現行の制御ファイルをデフォルトのディスク デバイスにバックアップし タグを割り当てます BACKUP CURRENT CONTROLFILE TAG = mondaypmbackup; この例では 制御ファイルの自動バックアップ機能が有効な場合 Recovery Manager が 2 つの制御ファイルのバックアップを作成します 1 つは明示的な制御ファイルのバックアップ (BACKUP CURRENT CONTROLFILE) で もう 1 つは制御ファイルとサーバー パラメータ ファイルの自動バックアップです 制御ファイルのコピーのバックアップ 次の例では BACKUP CONTROLFILECOPY コマンドを使用して 制御ファイルのバックアップを作成します 制御ファイルのコピーをバックアップする方法 Recovery Manager を起動した後 Recovery Manager プロンプトで BACKUP CONTROLFILECOPY コマンドを実行します 次の例では 制御ファイルのコピー '/tmp/control01.ctl' をディスクに作成した後 テープにバックアップします BACKUP AS COPY CURRENT CONTROLFILE FORMAT '/tmp/control01.ctl'; BACKUP DEVICE TYPE sbt CONTROLFILECOPY '/tmp/control01.ctl'; Recovery Manager を使用したサーバー パラメータ ファイルのバックアップ 4-9 ページの Recovery Manager を使用した制御ファイルのバックアップ で説明したとおり Recovery Manager は 特定の状況下で 現行のサーバー パラメータ ファイルを自動的にバックアップします BACKUP SPFILE コマンドは パラメータ ファイルを明示的にバックアップします 次に例を示します BACKUP DEVICE TYPE sbt SPFILE; バックアップされる SPFILE は インスタンスが使用中のファイルです インスタンスがクライアント側の初期化パラメータ ファイルを使用して起動されている場合 このコマンドを使用しても Recovery Manager は何もバックアップしません Recovery Manager を使用したアーカイブ REDO ログのバックアップ アーカイブ REDO ログは メディア リカバリを正常に実行するために重要です アーカイブ REDO ログのバックアップは 定期的に行います ログは BACKUP ARCHIVELOG を使用してバックアップできます または データ ファイルおよび制御ファイルのバックアップ時に BACKUP... PLUS ARCHIVELOG を指定してバックアップできます BACKUP ARCHIVELOG を使用したアーカイブ REDO ログ ファイルのバックアップ アーカイブ REDO ログをバックアップするには Recovery Manager プロンプトで BACKUP ARCHIVELOG コマンドを実行します 次の例では 構成済ディスクまたは sbt チャネルを使用して すべてのアーカイブ REDO ログのログ順序番号ごとに 1 つのコピーをバックアップします BACKUP ARCHIVELOG ALL; REDO ログが複数の宛先にアーカイブされており Recovery Manager を使用してアーカイブ REDO ログをバックアップする場合でも Recovery Manager は アーカイブ REDO ログ ファイルの 1 つのコピーのみを選択して バックアップ セットに含めます ( 同じログ順序番号を持つログは同一のものであるため 複数のコピーを含める必要はありません ) 4-10 Oracle Database バックアップおよびリカバリ基礎

81 Recovery Manager を使用したデータベース ファイルおよびアーカイブ ログのバックアップ また 次に示すように アーカイブ REDO ログを 時間 SCN またはログ順序番号で範囲指定することもできます BACKUP ARCHIVELOG FROM TIME 'SYSDATE-30' UNTIL TIME 'SYSDATE-7'; アーカイブ ログのバックアップ時のオンライン REDO ログの自動切替え最新のログを含むアーカイブ REDO ログのバックアップを取る ( つまり UNTIL または SEQUENCE オプションを指定せずに BACKUP... ARCHIVELOG コマンドを実行する ) 場合 データベースがオープンされていると Recovery Manager は バックアップを開始する前に 現行のオンライン REDO ログ グループ およびコマンド発行時に最新だった REDO ログ グループを含む アーカイブされていないすべての最新オンライン REDO ログを切り替えます これによって バックアップには コマンドの実行前に生成されたすべての REDO が確実に含められます DELETE INPUT または DELETE ALL INPUT を指定した BACKUP ARCHIVELOG の使用 BACKUP ARCHIVELOG コマンドに DELETE INPUT または DELETE ALL INPUT 句を指定すると バックアップ後にアーカイブ ログを削除できるため 手動でアーカイブ REDO ログを削除する必要がなくなります DELETE INPUT を指定すると Recovery Manager は バックアップ セット用に選択されたアーカイブ REDO ログの特定のコピーのみを削除します DELETE ALL INPUT を指定すると Recovery Manager は バックアップされた各アーカイブ REDO ログ ファイルをログのすべてのアーカイブ先から削除します たとえば 次のコマンドを実行して /arc_dest1 /arc_dest2 および /arc_dest3 にアーカイブするとします BACKUP DEVICE TYPE sbt ARCHIVELOG ALL DELETE ALL INPUT; この場合 Recovery Manager は これらのディレクトリで各ログ順序番号の 1 つのコピーのみをバックアップした後 アーカイブ先からバックアップ済のログのすべてのコピーを削除します DELETE ALL INPUT ではなく DELETE INPUT を指定した場合 Recovery Manager は バックアップ済の特定のアーカイブ REDO ログ ファイルのみを削除します ( たとえば /arc_dest1 のアーカイブ REDO ログ ファイルがバックアップのソースとして使用されたファイルの場合 そのアーカイブ先のアーカイブ REDO ログ ファイルのみ削除し /arc_ dest2 および /arc_dest3 の内容はそのまま残します ) BACKUP ARCHIVELOG ALL または BACKUP ARCHIVELOG LIKE '...' を発行した場合 バックアップするアーカイブ REDO ログ ファイルが存在しなくても Recovery Manager はエラーを表示しません BACKUP... PLUS ARCHIVELOG を使用したログのバックアップ BACKUP... PLUS ARCHIVELOG 句を使用すると アーカイブ REDO ログを他のファイルのバックアップに追加できます BACKUP... PLUS ARCHIVELOG を追加すると Recovery Manager は次の操作を実行します 1. ALTER SYSTEM ARCHIVE LOG CURRENT コマンドを実行します 2. BACKUP ARCHIVELOG ALL を実行します バックアップの最適化が有効な場合 Recovery Manager は 特定のデバイスにバックアップ済のログをスキップします 3. BACKUP コマンドに指定された残りのファイルをバックアップします 4. ALTER SYSTEM ARCHIVE LOG CURRENT コマンドを実行します 5. バックアップ中に生成された残りのアーカイブ ログをバックアップします これによって コマンドの実行時に取られたデータ ファイルのバックアップを 一貫性のある状態にリカバリ可能であることが保証されます Recovery Manager を使用したデータベースのバックアップ 4-11

82 Recovery Manager の増分バックアップ BACKUP... PLUS ARCHIVELOG を使用してアーカイブ REDO ログをバックアップする方法 Recovery Manager を起動した後 Recovery Manager プロンプトで BACKUP... PLUS ARCHIVELOG コマンドを実行します 次の例では データベースおよびすべてのアーカイブ ログをバックアップします BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG; 注意 : バックアップの最適化が有効な場合 Recovery Manager は 特定のデバイスにバックアップ済のアーカイブ ログのバックアップをスキップします Recovery Manager の増分バックアップ Recovery Manager による増分バックアップでは 以前の特定のバックアップ以降に変更されたデータ ファイル ブロックのみがバックアップされます データベース 個々の表領域またはデータ ファイルの増分バックアップを作成できます 増分バックアップは 以前のバックアップ以降に変更されたデータ ブロックのみバックアップすることを目的としています 増分バックアップは 主に次の場合に作成します 増分更新バックアップに基づく計画で使用する場合 この場合 これらの増分バックアップは データベースのイメージ コピーを定期的にロールフォワードするために使用されます 毎日のバックアップに必要な時間を削減する場合 ネットワーク経由でバックアップする際のネットワーク帯域幅を削減する場合 テープ書込み I/O で使用可能な集計テープ帯域幅が ディスク読込み I/O の集計ディスク帯域幅より大幅に少ない場合に 適切なバックアップ パフォーマンスを得る場合 NOLOGGING オプションを使用して作成されたオブジェクトへの変更をリカバリ可能にする場合 たとえば ダイレクト ロード インサートでは REDO ログ エントリは作成されないため それらの変更はメディア リカバリでは再作成できません ただし データ ブロックは変更されるため 増分バックアップによって取得されます NOARCHIVELOG データベースのバックアップ サイズを削減する場合 データベース全体のバックアップを毎回作成するかわりに 増分バックアップを作成できます 全体バックアップと同様に データベースが ARCHIVELOG モードでオープンされている場合に増分バックアップを作成できます データベースが NOARCHIVELOG モードの場合は 一貫性のある状態で停止した後にのみ 増分バックアップを作成できます 参照 : NOLOGGING モードの詳細は Oracle Database 概要 を参照してください ディスクに増分バックアップを作成した後 BACKUP AS BACKUPSET を使用して 作成されたバックアップ セットをメディア マネージャにバックアップする方法もあります 通常 増分バックアップは全体バックアップより小さく テープに移動するまで格納に必要な領域を抑えることができます また ディスク上の増分バックアップをテープにバックアップすると 増分バックアップのすべてのブロックがテープにコピーされるため テープ ストリーミングを維持できる可能性が高くなります Recovery Manager ではデータ ファイル内で変更されたブロックの特定に必要な時間があるため 遅延することはありません 4-12 Oracle Database バックアップおよびリカバリ基礎

83 Recovery Manager の増分バックアップ 増分バックアップ アルゴリズム データ ファイルの各データ ブロックには システム変更番号 (SCN) が含まれます これは ブロックが最後に変更されたときの SCN です 増分バックアップ中 Recovery Manager は 入力ファイルの各データ ブロックの SCN を読み取り 親増分バックアップのチェックポイント SCN と比較します 入力データ ブロックの SCN が親のチェックポイント SCN 以上である場合 Recovery Manager はそのブロックをコピーします ブロック チェンジ トラッキング機能を有効にすると Recovery Manager は チェンジ トラッキング ファイルを参照して データ ファイルの内容全体をスキャンしなくても データ ファイル内の変更されたブロックを識別できます ブロック チェンジ トラッキング機能を有効にすると パフォーマンスは向上しますが 増分バックアップの取り方や使用方法は変更されません ブロック チェンジ トラッキングについては 4-18 ページの 増分バックアップのパフォーマンスの改善 : チェンジ トラッキング を参照してください レベル 0 およびレベル 1 の増分バックアップ 増分バックアップは レベル 0 またはレベル 1 のいずれかです レベル 0 の増分バックアップは データを含むすべてのブロックをコピーし 全体バックアップと同様に データ ファイルをバックアップ セットにバックアップします レベル 0 の増分バックアップは 後続の増分バックアップの基になります レベル 0 の増分バックアップと全体バックアップの違いは 全体バックアップは増分計画には含まれないということです レベル 1 の増分バックアップは 次のいずれかです 差分バックアップ レベル 1 または 0 で最新の増分バックアップが行われた後 変更されたすべてのブロックをバックアップします 累積バックアップ レベル 0 で最新の増分バックアップが行われた後 変更されたすべてのブロックをバックアップします 増分バックアップは デフォルトでは差分バックアップです 注意 : ディスク領域よりリカバリ時間が重要な場合は 差分バックアップより累積バックアップが適しています これは リカバリ時に 各差分バックアップを継続的に適用する必要があるためです 累積増分バックアップを格納できる十分なディスク領域がある場合は 差分バックアップではなく累積増分バックアップを使用してください バックアップ ファイルのサイズは 変更されたブロックの数と増分バックアップのレベルに依存します 差分増分バックアップ レベル 1 の差分バックアップでは Recovery Manager は レベルが 0 か 1 かにかかわらず 最新の累積または差分増分バックアップが行われてた後 変更されたすべてのブロックをバックアップします Recovery Manager は レベル 1 の最新のバックアップを判断し そのバックアップ後に変更されたすべてのブロックをバックアップします レベル 1 のバックアップが有効でない場合 Recovery Manager は レベル 0 のバックアップ以降に変更されたすべてのブロックをコピーします 次のコマンドを実行すると データベースのレベル 1 の差分増分バックアップが実行されます RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE; レベル 0 のバックアップが有効でない場合 互換性モードの設定によって動作が異なります 互換性が >= の場合 Recovery Manager は ファイル作成後に変更されたすべてのブロックをコピーし その結果をレベル 1 のバックアップとして格納します つまり 増分バックアップが取られたときの SCN は ファイル固有の SCN になります 互換性が < の場合 以前のリリースでの動作との一貫性が保持されるように Recovery Manager は バックアップ時点でのファイルの内容のレベル 0 のバックアップを生成します Recovery Manager を使用したデータベースのバックアップ 4-13

84 Recovery Manager の増分バックアップ 図 4-1 差分増分バックアップ ( デフォルト ) 図 4-1 には 次のことが示されています 日曜日 レベル 0 の増分バックアップが実行され このデータベースで使用されていたすべてのブロックがバックアップされます 月曜日 ~ 土曜日 月曜日 ~ 土曜日は レベル 1 の差分増分バックアップが毎日実行され レベル 1 または 0 の最新の増分バックアップが実行された後 変更されたすべてのブロックがバックアップされます つまり 月曜日のバックアップでは 日曜日のレベル 0 のバックアップの後変更されたブロックがコピーされ 火曜日のバックアップでは 月曜日のレベル 1 のバックアップの後変更されたブロックがコピーされます このサイクルが 次の週も繰り返されます 累積増分バックアップ レベル 1 の累積バックアップでは Recovery Manager は レベル 0 の最新の増分バックアップが行われた後 使用されたすべてのブロックをバックアップします 特定のレベルからの増分バックアップが 1 回のみ必要なため 累積増分バックアップによって リストアに必要な作業が削減されます ただし 同じレベルの以前のバックアップで行われた操作が重複するため 累積バックアップで必要な領域と時間は 累積バックアップと比べて多くなります 次のコマンドを実行すると データベースのレベル 1 の累積増分バックアップが実行されます BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE; # blocks changed since level Oracle Database バックアップおよびリカバリ基礎

85 Recovery Manager の増分バックアップ 図 4-2 累積増分バックアップ 図 4-2 には 次のことが示されています 日曜日 レベル 0 の増分バックアップが実行され このデータベースで使用されていたすべてのブロックがバックアップされます 月曜日 ~ 土曜日 レベル 1 の累積増分バックアップで レベル 0 の最新のバックアップが行われた後 変更されたすべてのブロックがコピーされます レベル 0 の最新のバックアップは日曜日に作成されているため 月曜日 ~ 土曜日に毎日行われるレベル 1 のバックアップでは 日曜日のバックアップの後 変更されたすべてのブロックがバックアップされます このサイクルが 次の週も繰り返されます 基本的な増分バックアップ計画 許容可能な平均リカバリ時間 (MTTR) に従って バックアップ方法を選択します たとえば 全体バックアップまたはレベル 0 のバックアップを毎月実行する レベル 1 の累積バックアップを毎週実行する レベル 1 の差分バックアップを毎日実行する という 3 レベルのバックアップを実装できます この方法では 完全リカバリのために 毎日 REDO を適用するだけで十分です 全体バックアップまたはレベル 0 のバックアップの実行頻度を決定する場合 50% 以上のデータが変更されるたびに レベル 0 の新しいバックアップを実行することをお薦めします データベースへの変更の割合を予測できる場合は 増分バックアップのサイズを調べて レベル 0 の新しいバックアップの実行時期を判断します 次の問合せでは 50% 以上のブロックがバックアップされたデータ ファイルごとに バックアップ セットに書き込まれたブロックの数が表示されます SELECT FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, BLOCKS, DATAFILE_BLOCKS FROM V$BACKUP_DATAFILE WHERE INCREMENTAL_LEVEL > 0 AND BLOCKS / DATAFILE_BLOCKS >.5 ORDER BY COMPLETION_TIME; Recovery Manager を使用したデータベースのバックアップ 4-15

86 Recovery Manager の増分バックアップ 差分バックアップまたは累積バックアップのブロック数と レベル 0 のベース バックアップを比較します たとえば レベル 1 の累積バックアップを作成する場合に レベル 1 の最新のバックアップのサイズがレベル 0 のベース バックアップの約半分であれば レベル 0 の新しいバックアップを実行します 増分バックアップの作成 : BACKUP INCREMENTAL Recovery Manager を起動した後 Recovery Manager プロンプトで BACKUP INCREMENTAL コマンドを実行します 次の例では データベースのレベル 0 の増分バックアップを作成します BACKUP INCREMENTAL LEVEL 0 DATABASE; 次の例では SYSTEM 表領域およびデータ ファイル tools01.dbf のレベル 1 の差分バックアップを作成します このバックアップでは レベル 1 またはレベル 0 の最新のバックアップの後 変更されたデータ ブロックのみバックアップします BACKUP INCREMENTAL LEVEL 1 TABLESPACE SYSTEM DATAFILE 'ora_home/oradata/trgt/tools01.dbf'; 次の例では 表領域 users のレベル 1 の累積バックアップを作成し レベル 0 の最新のバックアップの後 変更されたすべてのブロックをバックアップします BACKUP INCREMENTAL LEVEL = 1 CUMULATIVE TABLESPACE users; 増分更新バックアップ : イメージ コピーのバックアップのロールフォワード Oracle の増分更新バックアップ機能を使用すると イメージ コピーのバックアップと同じリカバリ機能が提供され データ ファイルのイメージ コピーの全体バックアップを実行する際のオーバーヘッドを回避できます バックアップ計画の開始時に Recovery Manager はデータ ファイルのイメージ コピーのバックアップを作成します その後 ( 毎日など ) 定期的にレベル 1 の増分バックアップを取り イメージ コピーのバックアップに適用して レベル 1 の増分バックアップが作成された時点にロールフォワードします データベースのリストアおよびリカバリ中に Recovery Manager はこの増分更新コピーからリストアし その後で REDO ログから変更を適用できます この結果は 最後に適用されたレベル 1 の増分バックアップの SCN で作成された全体バックアップからデータベースをリストアするのと同じです 増分更新バックアップに基づくバックアップ計画によって データベースのメディア リカバリに必要な時間を最小限にできます たとえば スクリプトを実行してこの計画を毎日実装すると リカバリ時に適用する REDO は 1 日に 1 回で済みます 増分更新バックアップ : 基本的な例 増分更新バックアップ計画で使用する増分バックアップを作成するには BACKUP コマンドの BACKUP... FOR RECOVER OF COPY WITH TAG 形式を使用する必要があります コマンドの動作方法は この計画を実装するサンプル スクリプトで最もよく理解できます 定期的にこのスクリプトを実行することが 増分更新バックアップに基づく計画を実装するために必要なすべてのことです RUN { RECOVER COPY OF DATABASE WITH TAG 'incr_update'; BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE; } 4-16 Oracle Database バックアップおよびリカバリ基礎

87 Recovery Manager の増分バックアップ ただし このスクリプトで使用する構文では 計画の動作が明確に理解できません スクリプトと計画を理解するには データ ファイルのコピーまたは増分バックアップが存在しない場合の次の 2 つのコマンドの影響を理解する必要があります BACKUP INCREMENTAL LEVEL 1... FOR RECOVER OF COPY WITH TAG... コマンドでは レベル 1 の増分バックアップが実際には作成されない場合があります 特定のデータ ファイルのレベル 0 のイメージ コピーのバックアップが存在しない場合 このコマンドを実行すると レベル 1 のバックアップが作成されるかわりに 指定したタグを使用して ディスク上にデータ ファイルのイメージ コピーのバックアップが作成されます 注意 : DEVICE TYPE SBT を指定して BACKUP INCREMENTAL LEVEL 1... FOR RECOVER OF COPY コマンドを使用し テープ上にバックアップを作成する場合でも このコマンドをはじめて使用する場合は ディスク上にイメージ コピーが作成されますが テープ上にバックアップは書き込まれません イメージ コピーがディスク上に存在するようになると 次回のレベル 1 の増分バックアップはテープ上に作成することができます したがって スクリプトをはじめて実行すると 増分更新のサイクル開始に必要なデータ ファイルのイメージ コピーが作成されます 2 回目以降の実行では データ ファイルのレベル 1 の増分バックアップが作成されます RECOVER COPY OF DATABASE WITH TAG... コマンドを使用すると Recovery Manager は 指定したタグを持つデータ ファイルのコピーのセットにレベル 1 の使用可能なすべての増分バックアップを適用します 増分バックアップまたはデータ ファイルのコピーが存在しない場合 このコマンドでメッセージは表示されますが エラーは生成されません データ ファイルのコピーやレベル 1 の増分バックアップが存在しないため スクリプトをはじめて実行したときは 何も処理が行われません 2 回目に実行したときは データ ファイルのコピーが存在 ( 最初の BACKUP コマンドで作成されている ) しますが レベル 1 の増分バックアップが存在しないため 何も処理が行われません 3 回目以降の実行では それまでの実行でデータ ファイルのコピーとレベル 1 の増分バックアップが作成されているため レベル 1 の増分バックアップはデータ ファイルのコピーに適用され データ ファイルのコピーは レベル 1 の増分バックアップのチェックポイント SCN の状態までリカバリされます この例について 次のことにも注意してください データベースにデータ ファイルを追加するたびに 次にスクリプトを実行したときに 新しいデータ ファイルのイメージ コピーが作成されます その後の実行では そのデータ ファイルのレベル 1 の最初の増分バックアップが作成され さらにその後の実行では 他のデータ ファイルと同様に 新しいデータ ファイルが処理されます この計画で使用するために作成されたレベル 0 の増分データ ファイルのコピーを識別するには タグを使用する必要があります そのため この計画は実装する他のバックアップ計画とは連動しません 複数の増分バックアップ計画を採用している場合 Recovery Manager はレベル 0 のバックアップにタグが付けられるまでは レベル 1 の増分バックアップを作成できません イメージ コピーに適用するレベル 1 の増分バックアップは そのイメージ コピーのデータ ファイルのチェックポイント SCN とレベル 1 の使用可能な増分バックアップに基づいて選択されます ( リカバリされるイメージ コピーで使用されるタグは そのレベルの増分バックアップの選択基準にはなりません ) Recovery Manager を使用したデータベースのバックアップ 4-17

88 Recovery Manager の増分バックアップ 実際に サンプル スクリプトを 1 日に 1 回 ( 可能であれば深夜 ) に実行するようにスケジュールするとします 通常 夜 ( つまり 最初の 2 日後の夜 ) スクリプトの完了後に次のファイルの Point-in-Time リカバリが可能になります 24 時間前にスクリプトを実行したときのチェックポイント SCN 時点でのデータベースのイメージ コピー 前回実行したチェックポイント SCN 後に行われた変更の増分バックアップ イメージ コピーのチェックポイント SCN と現在の時刻の間に行われたすべての変更を含むアーカイブ REDO ログ その後の 24 時間以内に このバックアップからデータベースをリストアおよびリカバリ ( 完全リカバリまたは Point-in-Time リカバリのいずれか ) する必要がある場合は 増分バックアップしたデータ ファイルのコピーからデータ ファイルをリストアした後 必要な SCN に到達するまで レベル 1 の最新の増分バックアップおよび REDO ログから変更を適用できます REDO を適用するには 最大 24 時間かかります これによって Point-in-Time リカバリにかかる時間が制限されます 参照 : Enterprise Manager での Oracle 推奨バックアップ計画の使用方法については Oracle Database 2 日でデータベース管理者 を参照してください 増分更新バックアップ : 1 週間の例 24 時間を超える期間に高速リカバリの提供するために 基本的な例を拡張できます RECOVER COPY... WITH TAG を変更して リカバリ可能期間を開始する過去のある時間に データ ファイルのコピーを不完全リカバリします 次に 7 日間の保持方法の例を示します RUN { RECOVER COPY OF DATABASE WITH TAG 'incr_update' UNTIL TIME 'SYSDATE - 7'; BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE; } スクリプトは 次の処理を実行します 1 日目の夜 RECOVER COPY... UNTIL TIME 文は何も処理を実行しません BACKUP INCREMENTAL... FOR RECOVER OF COPY 文は レベル 0 の増分コピーを作成します 2 日目 ~ 7 日目の夜 TIME 'SYSDATE - 7' がまだ未来であるため RECOVER COPY... UNTIL TIME 文は何も処理を実行しません BACKUP INCREMENTAL... FOR RECOVER OF COPY 文は 前日のブロック変更を含むレベル 1 の差分増分バックアップを作成します 8 日目以降の夜 RECOVER COPY... UNTIL TIME 文は 7 日目以前のレベル 1 の増分をデータベースのコピーに適用します BACKUP INCREMENTAL... FOR RECOVER OF COPY 文は 前日の変更を含む増分バックアップを作成します 基本的な例と同様に 増分バックアップからのブロック変更および REDO ログからの個々の変更を使用して データ ファイルのコピーの SCN と現在の間の任意の時点に高速リカバリが可能です レベル 1 の増分が毎日あるため 1 日を超える REDO を適用する必要はありません 増分バックアップのパフォーマンスの改善 : チェンジ トラッキング Recovery Manager の増分バックアップ用のチェンジ トラッキング機能を使用すると チェンジ トラッキング ファイル内の各データ ファイルで変更されたブロックを記録することにより 増分バックアップのパフォーマンスが改善されます チェンジ トラッキングが有効な場合 Recovery Manager は チェンジ トラッキング ファイルを使用して 増分バックアップで変更されたブロックを識別します これによって データ ファイル内のすべてのブロックをスキャンする必要がなくなります チェンジ トラッキングを有効にした直後は チェンジ トラッキング ファイルにブロックの状態が反映されていないため レベル 0 の最初の増分バックアップでは データ ファイル 4-18 Oracle Database バックアップおよびリカバリ基礎

89 Recovery Manager の増分バックアップ 全体をスキャンする必要があります このレベル 0 の増分バックアップを親として使用するその後の増分バックアップでは チェンジ トラッキング ファイルを使用します 変更のないチェンジ トラッキングを使用する場合は 通常 増分バックアップの実行に使用したコマンドおよびそのチェンジ トラッキング ファイル自体 初期構成をわずかにメンテナンスする必要があります チェンジ トラッキングは 通常の動作時に データベースに対するパフォーマンスのオーバーヘッドをわずかに発生させるため デフォルトでは無効になっています ただし バックアップとバックアップの間で行われた変更がごく少量の場合などは バックアップ時にデータベース全体のスキャンを実行しないことは大きな利点です バックアップ計画に増分バックアップが含まれている場合は チェンジ トラッキングを有効にしてください データベース全体に対して 1 つのチェンジ トラッキング ファイルが作成されます デフォルトでは チェンジ トラッキング ファイルは Oracle が管理するファイルとして DB_CREATE_FILE_DEST に作成されます ブロック チェンジ トラッキング ファイルの名前を指定して 任意の場所に格納することもできます 注意 : Real Application Clusters(RAC) 環境で チェンジ トラッキング ファイルはクラスタ中の全ノードからアクセス可能な共有ストレージに置く必要があります 最新の増分バックアップ 8 つのうちのいずれかを親として使用して増分バックアップを取ることができるように Oracle には十分なチェンジ トラッキング情報が保存されています Recovery Manager では チェンジ トラッキング ファイル自体のバックアップおよびリカバリはサポートされていませんが データベースの全体または一部をリストアまたはリカバリする必要がある場合 リカバリによって 自動的にチェンジ トラッキングに対する処理が実行されます リストアおよびリカバリ後 チェンジ トラッキング ファイルは内容が消去され 再度 ブロック変更の記録を開始します リカバリの直後に実行される増分バックアップでは チェンジ トラッキング データを使用できます チェンジ トラッキングの有効化および無効化 データベースがオープンまたはマウントされている場合は チェンジ トラッキングを有効または無効にできます チェンジ トラッキングの設定を変更するには SQL*Plus を使用して 管理者権限でターゲット データベースに接続する必要があります データベース領域にチェンジ トラッキング ファイルを格納するには ターゲット データベースで DB_CREATE_FILE_DEST を設定する必要があります その後 次の SQL 文を発行して チェンジ トラッキングを有効にします SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING; また 次の SQL 文を使用して 任意の場所にチェンジ トラッキング ファイルを作成することもできます SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/mydir/rman_change_track.f' REUSE; REUSE オプションは 指定した名前で既存のファイルを上書きすることを示します チェンジ トラッキングを無効にするには 次の SQL 文を使用します SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING; チェンジ トラッキング ファイルがデータベース領域に格納されていた場合は チェンジ トラッキングを無効にするときに削除されます Recovery Manager を使用したデータベースのバックアップ 4-19

90 Recovery Manager の増分バックアップ チェンジ トラッキングが有効かどうかの確認 SQL*Plus から V$BLOCK_CHANGE_TRACKING.STATUS を問い合せて チェンジ トラッキングが有効かどうかを判断できます 有効な場合は V$BLOCK_CHANGE_TRACKING.FILENAME を問い合せて ファイル名を表示できます チェンジ トラッキング ファイルの移動 チェンジ トラッキング ファイルを移動する場合は ALTER DATABASE RENAME FILE コマンドを実行して 新しい場所を参照するように制御ファイルを更新します この項では チェンジ トラッキング ファイルの内容を保持したまま 場所を移動する方法について説明します チェンジ トラッキング ファイルを移動する方法 1. 必要に応じて チェンジ トラッキング ファイルの現在の名前を特定します SELECT filename FROM V$BLOCK_CHANGE_TRACKING; 2. データベースを停止します 次に例を示します SHUTDOWN IMMEDIATE 3. ホスト オペレーティング システムのコマンドを使用して チェンジ トラッキング ファイルを新しい場所に移動します 4. データベースをマウントし 領域がさらに大きい場所にチェンジ トラッキング ファイルを移動します 次に例を示します ALTER DATABASE RENAME FILE 'ora_home/dbs/change_trk.f' TO '/new_disk/change_trk.f'; 5. データベースをオープンします ALTER DATABASE OPEN; データベースを停止できない場合は チェンジ トラッキングを無効にした後 新しい場所で再度有効にする必要があります 次に例を示します ALTER DATABASE DISABLE BLOCK CHANGE TRACKING; ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE 'new_location'; この方法で移動すると チェンジ トラッキング ファイルの内容が失われます 次回 レベル 0 の増分バックアップを完了するまで Recovery Manager はファイル全体をスキャンする必要があります ディスク上のチェンジ トラッキング ファイルのサイズの見積り チェンジ トラッキング ファイルのサイズは データベースのサイズおよび有効な REDO スレッドの数に比例します データベースの更新頻度には関連しません 通常 ブロック チェンジ トラッキングに必要な領域は 追跡対象のデータ ブロックのサイズの約 1/30,000 です ただし 次の 2 つの要因によって ファイルがこの見積りで示すサイズより大きくなる可能性があるため注意が必要です データベースの拡張に伴う領域割当てのオーバーヘッドを回避するために チェンジ トラッキング ファイルの初期サイズは 10MB で 10MB ずつ新しい領域が割り当てられます つまり このファイルのサイズは 約 300GB までのデータベースに対しては 10MB 以上 約 600GB までのデータベースに対しては 20MB 以上になります 各データ ファイルに対しては ファイル サイズに関係なく 320K の最小限の領域がチェンジ トラッキング ファイルに割り当てられます このため 比較的小さいデータ ファイルが多数ある場合 このチェンジ トラッキング ファイルは 同じデータを格納していても 大きいデータ ファイルを少数で構成しているデータベースの場合より大きくなります 4-20 Oracle Database バックアップおよびリカバリ基礎

91 バックアップおよび Recovery Manager リポジトリのレポートの概要 Recovery Manager を使用したデータベース ファイルの検証 BACKUP コマンドの VALIDATE オプションを使用すると データ ファイルが適切な場所に存在するか および Recovery Manager でのデータ ファイルのバックアップの作成を妨げる物理的または論理的な破損がないかを確認できます BACKUP... VALIDATE を実行すると Recovery Manager は 実際のバックアップの場合と同じように バックアップされるファイル全体を読み取ります ただし 実際にはバックアップ セットやイメージ コピーを生成しません バックアップの検査によって破損ブロックが検出された後 Recovery Manager は 破損を示している行を反映して V$DATABASE_BLOCK_CORRUPTION ビューを更新します ブロック メディア リカバリを使用すると 破損を修復できます 詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください 破損ブロックを修復した後 このブロックを示している行はビューから削除されます たとえば 次のコマンドで すべてのデータベース ファイルおよびアーカイブ ログがバックアップ可能かどうかを検査できます BACKUP VALIDATE DATABASE ARCHIVELOG ALL; Recvery Manager クライアントは 実際にファイルをバックアップしたときと同じ出力を表示します Recovery Manager で検査できないファイルがあると エラー メッセージが表示されます たとえば 次のように表示されます RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of backup command at 08/29/ :33:47 ORA-19625: error identifying file /oracle/oradata/trgt/arch/archive1_6.dbf ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Additional information: 3 MAXCORRUPT または PROXY パラメータに VALIDATE オプションを使用することはできません 参照 : BACKUP 構文については Oracle Database バックアップおよびリカバリ リファレンス を参照してください BACKUP... VALIDATE コマンドで検出される破損ブロックの修復については Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください バックアップおよび Recovery Manager リポジトリのレポートの概要 様々な方法で Recovery Manager リポジトリから情報を取得できます Recovery Manager の LIST および REPORT コマンドでは 使用可能なバックアップと データベースをリストアおよびリカバリするためにそれをどのように使用できるかという詳細な情報が提供されます LIST については 4-22 ページの Recovery Manager バックアップ アーカイブ ログおよびデータベース インカネーションの表示 を REPORT については 4-27 ページの バックアップおよびデータベース スキーマのレポート を参照してください データベースがオープンしている場合は 多くの V$ ビューによって 制御ファイル内の Recovery Manager リポジトリ レコードに直接アクセスできます データベースがリカバリ カタログに登録されている場合は V$ ビューにほとんど類似している RC_ ビューによって リカバリ カタログに格納されている Recovery Manager リポジトリ データに直接アクセスできます ビューの問合せは SQL*Plus のいずれのグループからも行うことができます V$DATAFILE_HEADER V$PROCESS V$SESSION など 一部の V$ ビューにはリカバリ カタログ ビューにはない情報が含まれています V$ ビューについては Recovery Manager を使用したデータベースのバックアップ 4-21

92 Recovery Manager バックアップ アーカイブ ログおよびデータベース インカネーションの表示 Oracle Database リファレンス を RC_ ビューについては Oracle Database バックアップおよびリカバリ リファレンス を参照してください RESTORE コマンドでは PREVIEW 句がサポートされ 使用可能なバックアップ セットを前提として Recovery Manager がどのようにデータベースの全体または一部をリストアおよびリカバリできるかという詳細情報が提供されます RESTORE... PREVIEW については 6-9 ページの リストア操作で使用するバックアップの確認 : RESTORE PREVIEW を参照してください 注意 : Recovery Manager による制御の外部でバックアップが操作されている場合 ( たとえば いくつかのディスクベースのバックアップが削除されている場合や テープ バックアップが一時的に使用不可になっていたり 完全に消失している場合 ) CHANGE CROSSCHECK DELETE などのコマンドを使用して 使用可能な実際のバックアップ セットを反映するように バックアップの Recovery Manager リポジトリ レコードを更新します ( 第 8 章 Recovery Manager のメンテナンス作業 を参照 ) これを行わないと 前述のコマンドおよびビューの出力には誤りが表示され Recovery Manager は リポジトリが更新されるまで データベースをリストアおよびリカバリするためのバックアップを検出できない可能性があります 参照 : Recovery Manager リポジトリを最新の状態に保つ方法については Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください LIST 構文については Oracle Database バックアップおよびリカバリ リファレンス を参照してください REPORT 構文については Oracle Database バックアップおよびリカバリ リファレンス を参照してください RESTORE PREVIEW 構文については Oracle Database バックアップおよびリカバリ リファレンス を参照してください Recovery Manager バックアップ アーカイブ ログおよびデータベース インカネーションの表示 LIST コマンドは Recovery Manager リポジトリ内の情報を使用して バックアップ アーカイブ ログおよびデータベース インカネーションのリストを表示します LIST の出力を使用して 他の Recovery Manager コマンドとともに使用する特定のバックアップを識別できます この項では次の項目を取り上げます LIST コマンドによって生成された Recovery Manager レポート バックアップの表示 ファイルごとの表示 サマリー モードでのバックアップの表示 選択したバックアップの表示 データベース インカネーションの表示 4-22 Oracle Database バックアップおよびリカバリ基礎

93 Recovery Manager バックアップ アーカイブ ログおよびデータベース インカネーションの表示 LIST コマンドによって生成された Recovery Manager レポート バックアップの表示 LIST コマンドの BY BACKUP および BY FILE オプションを使用し SUMMARY および VERBOSE オプションのいずれかを選択して 出力方法を制御できます LIST コマンドは 主に使用可能なバックアップを判断することを目的としています たとえば 次のものを表示できます データベース 表領域 データ ファイル アーカイブ REDO ログまたは制御ファイルのバックアップおよびプロキシ コピー 期限切れになったバックアップ 時間 パス名 デバイス タイプ タグまたはリカバリ可能性で制限されているバックアップ データベース インカネーション V$BACKUP_FILES にも バックアップの表示情報が含まれます デフォルトでは Recovery Manager は バックアップごとにバックアップを表示します つまり 各バックアップまたはプロキシ コピーを連続して表示した後 そのバックアップが含まれるファイルを識別します ファイルごとにバックアップを表示することもできます デフォルトでは Recovery Manager は冗長モードでバックアップを表示します 冗長モードで出力されるバックアップが多すぎる場合は サマリー モードで表示することもできます バックアップごとの表示 バックアップごとにバックアップを表示するには ターゲット データベースとリカバリ カタログ ( 使用している場合 ) に接続してから LIST BACKUP コマンドを実行します listobjlist 句を使用して 必要なオブジェクトを指定します たとえば 次のように入力できます LIST BACKUP; LIST BACKUPSET; LIST COPY; # lists backup sets, image copies, and proxy copies # lists only backup sets and proxy copies # lists only disk copies オプションで EXPIRED を指定して クロスチェックでは検索されなかったバックアップを識別します LIST EXPIRED BACKUP; 出力を調べます (LIST 出力の様々な列ヘッダーについては Oracle Database バックアップおよびリカバリ リファレンス を参照 ) LIST BACKUP の出力例を 次に示します List ofchange, CROSSCHECK, and DELETE Backup Sets =================== BS Key Size Device Type Elapsed Time Completion Time M DISK 00:00:20 04-NOV-03 BP Key: 7 Status: AVAILABLE Compressed: NO Tag: TAG T Piece Name: /oracle/work/rdbms/backupset/2003_11_04/o1_mf_annnn_tag t200759_ztjxx3k8_.bkp List of Archived Logs in backup set 7 Thrd Seq Low SCN Low Time Next SCN Next Time OCT OCT OCT OCT OCT OCT NOV NOV NOV NOV NOV NOV-03 Recovery Manager を使用したデータベースのバックアップ 4-23

94 Recovery Manager バックアップ アーカイブ ログおよびデータベース インカネーションの表示 BS Key Type LV Size Device Type Elapsed Time Completion Time Full 2M DISK 00:00:01 04-NOV-03 BP Key: 8 Status: AVAILABLE Compressed: NO Tag: TAG T Piece Name: /ade/lashdown_rdbms/oracle/dbs/c Controlfile Included: Ckp SCN: Ckp time: 04-NOV-03 SPFILE Included: Modification time: 21-OCT-03 LIST COPY の出力例を 次に示します List of Archived Log Copies Key Thrd Seq S Low Time Name A 01-NOV-03 /oracle/work/rdbms/archivelog/2003_11_03/o1_mf_1_37_ztd4hl5d_.arc A 03-NOV-03 /oracle/work/rdbms/archivelog/2003_11_04/o1_mf_1_38_zthvg168_.arc A 04-NOV-03 /oracle/work/rdbms/archivelog/2003_11_04/o1_mf_1_39_ztjxwxwy_.arc ファイルごとの表示 listobjlist または recordspec 句 ( Oracle Database バックアップおよびリカバリ リファレンス を参照 ) を使用して 必要なオブジェクトを指定します オブジェクトを指定しないと Recovery Manager は すべてのデータベース ファイルとアーカイブ ログのコピーを表示します デフォルトでは Recovery Manager は冗長モードでオブジェクトを表示します 複数行で多数の情報を表示します ファイルごとにバックアップを表示するには Recovery Manager クライアントからターゲット データベースとリカバリ カタログ ( 使用している場合 ) に接続してから BY FILE オプションで表示するオブジェクトとオプションを指定して LIST を実行します たとえば 次のように入力します LIST BACKUP BY FILE; # shows backup sets, proxy copies, and image copies LIST COPY BY FILE; # shows only disk copies EXPIRED オプションを指定して クロスチェックでは検索されなかったバックアップを識別することもできます LIST EXPIRED BACKUP BY FILE; 出力を調べます (LIST 出力の様々な列ヘッダーについては Oracle Database バックアップおよびリカバリ リファレンス を参照 ) 出力例は次のとおりです List of Datafile Backups ======================== File Key TY LV S Ckp SCN Ckp Time #Pieces #Copies Compressed Tag B F A NOV YES TAG T B F A OCT NO TAG T B F A NOV YES TAG T B F A OCT NO TAG T some rows omitted List of Archived Log Backups ============================ Thrd Seq Low SCN Low Time BS Key S #Pieces #Copies Compressed Tag OCT-03 7 A 1 1 NO TAG T A 1 1 NO TAG T OCT-03 7 A 1 1 NO TAG T A 1 1 NO TAG T some rows omitted NOV-03 7 A 1 1 NO TAG T Oracle Database バックアップおよびリカバリ基礎

95 Recovery Manager バックアップ アーカイブ ログおよびデータベース インカネーションの表示 NOV-03 7 A 1 1 NO TAG T List of Controlfile Backups =========================== CF Ckp SCN Ckp Time BS Key S #Pieces #Copies Compressed Tag NOV-03 8 A 1 1 NO TAG T NOV-03 6 A 1 1 NO TAG T OCT-03 4 A 1 1 NO TAG T List of SPFILE Backups ====================== Modification Time BS Key S #Pieces #Copies Compressed Tag OCT-03 8 A 1 1 NO TAG T OCT-03 6 A 1 1 NO TAG T サマリー モードでのバックアップの表示 デフォルトでは LIST 出力で詳細な情報が表示されますが 要約された形式で表示されるように指定することもできます listobjectlist または recordspec 句を使用して 必要なオブジェクトを指定します オブジェクトを指定しないと LIST BACKUP は すべてのバックアップを表示します ターゲット データベースとリカバリ カタログ ( 使用している場合 ) に接続してから 必要なオブジェクトとオプションを指定して LIST BACKUP を実行します 次に例を示します LIST BACKUP SUMMARY; # lists backup sets, proxy copies, and disk copies EXPIRED キーワードを指定して クロスチェックでは検索されなかったバックアップを識別することもできます LIST EXPIRED BACKUP SUMMARY; 出力例は次のとおりです List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag B A A SBT_TAPE 21-OCT NO TAG T B F A SBT_TAPE 21-OCT NO TAG T B A A SBT_TAPE 21-OCT NO TAG T B F A SBT_TAPE 21-OCT NO TAG T B F A DISK 04-NOV YES TAG T B F A DISK 04-NOV NO TAG T B A A DISK 04-NOV NO TAG T B F A DISK 04-NOV NO TAG T LIST 出力の様々な列ヘッダーについては Oracle Database バックアップおよびリカバリ リファレンス を参照してください 選択したバックアップの表示 様々な条件を指定して LIST 出力を制限できます ターゲット データベースとリカバリ カタログ ( 使用している場合 ) に接続してから listobjlist または recordspec 句を指定して LIST COPY または LIST BACKUP を実行します たとえば 次のいずれかのコマンドを実行します # lists backups of all files in database LIST BACKUP OF DATABASE; # lists copy of specified datafile LIST COPY OF DATAFILE 'ora_home/oradata/trgt/system01.dbf'; # lists specified backup set Recovery Manager を使用したデータベースのバックアップ 4-25

96 Recovery Manager バックアップ アーカイブ ログおよびデータベース インカネーションの表示 LIST BACKUPSET 213; # lists datafile copy LIST DATAFILECOPY '/tmp/tools01.dbf'; maintqualifier または RECOVERABLE 句を指定して 検索を制限することもできます 次に例を示します # specify a backup set by tag LIST BACKUPSET TAG 'weekly_full_db_backup'; # specify a backup or copy by device type LIST COPY OF DATAFILE 'ora_home/oradata/trgt/system01.dbf' DEVICE TYPE sbt; # specify a backup by directory or path LIST BACKUP LIKE '/tmp/%'; # specify a backup or copy by a range of completion dates LIST COPY OF DATAFILE 2 COMPLETED BETWEEN '10-DEC-2002' AND '17-DEC-2002'; # specify logs backed up at least twice to tape LIST ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE sbt; 出力は LIST コマンドに指定してオプションによって異なります たとえば 次のコマンドでは データ ファイル 1 のコピーが表示されます RMAN> list backup of datafile 1; List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time Full 230M SBT_TAPE 00:00:49 21-OCT-03 BP Key: 2 Status: AVAILABLE Compressed: NO Tag: TAG T Handle: 02f4eatc_1_1 Media: /smrdir List of Datafiles in backup set 2 File LV Type Ckp SCN Ckp Time Name Full OCT-03 /oracle/dbs/tbs_01.f BS Key Type LV Size Device Type Elapsed Time Completion Time Full 233M DISK 00:04:30 04-NOV-03 BP Key: 5 Status: AVAILABLE Compressed: NO Tag: TAG T Piece Name: /oracle/work/rdbms/backupset/2003_11_04/o1_mf_nnndf_tag t195949_ ztjxfvgz_.bkp List of Datafiles in backup set 5 File LV Type Ckp SCN Ckp Time Name Full NOV-03 /ade/lashdown_rdbms/oracle/dbs/tbs_01.f 参照 : listobjlist および recordspec 構文については Oracle Database バックアップおよびリカバリ リファレンス を参照してください LIST 出力の様々な列については Oracle Database バックアップおよびリカバリ リファレンス を参照してください データベース インカネーションの表示 データベースに対して OPEN RESETLOGS 操作を実行するたびに 新しいデータベース インカネーションが作成されます データベース インカネーションと それによって Recovery Manager でのデータベース リカバリが受ける影響については Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください 4-26 Oracle Database バックアップおよびリカバリ基礎

97 バックアップおよびデータベース スキーマのレポート 増分バックアップの実行時 Recovery Manager は 前回のインカネーションまたは現行のインカネーションからのバックアップを 後続の増分バックアップの基礎として使用できます リストアおよびリカバリの実行時 すべてのアーカイブ ログが使用可能なかぎり Recovery Manager は 現行のインカネーションからのバックアップを使用するのと同様に リストアまたはリカバリ操作で前回のインカネーションからのバックアップを使用できます LIST INCARNATION コマンドを使用して データベース インカネーションを表示します データベース インカネーションを表示する方法ターゲット データベースとリカバリ カタログ ( 使用している場合 ) に接続してから LIST INCARNATION を実行します RMAN> LIST INCARNATION; リカバリ カタログを使用している場合 および同じカタログに複数のターゲット データベースを登録している場合は OF DATABASE オプションを使用して それらを区別することができます RMAN> LIST INCARNATION OF DATABASE prod3; LIST 出力の様々な列ヘッダーについては Oracle Database バックアップおよびリカバリ リファレンス を参照してください 出力例は次のとおりです RMAN> LIST INCARNATION OF DATABASE; List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time RDBMS PARENT 1 21-OCT RDBMS CURRENT OCT-03 この出力例では RESETLOGS が SCN でデータベース trgt に対して実行され 新しいインカネーションが作成されたことが示されています インカネーションは インカネーション キー (Inc Key 列 ) で区別されます バックアップおよびデータベース スキーマのレポート Recovery Manager の REPORT コマンドを使用すると 使用可能なバックアップおよびデータベースを分析して 次のような重要な質問に回答できます バックアップが必要なファイルは リカバリ不能な操作を実行したファイルは 不要なために削除できるファイルは 過去のある時点でのデータベースの物理スキーマは 最近バックアップされたファイルは Recovery Manager を使用したデータベースのバックアップ 4-27

98 バックアップおよびデータベース スキーマのレポート 注意 : Recovery Manager リポジトリに使用可能なバックアップおよびデータベースの状態の正確なレコードが保持されている場合にのみ REPORT で正しい結果が出力されます たとえば Recovery Manager の外部でディスクまたはテープからバックアップが削除されている場合 Recovery Manager によって生成されるレポートにはこれらの変更が自動的に反映されません Recovery Manager リポジトリに記録されているいくつかのバックアップが削除されているか またはストレージ デバイスがオフラインになっているかメディアが使用できないためにバックアップが一時的に使用不可になっている場合 CROSSCHECK コマンドを使用してすべてのバックアップの状態を更新するか または CHANGE CATALOG UNCATALOG および DELETE コマンドを使用して個々のバックアップの状態を直接設定できます 実際に使用可能なバックアップを反映するように Recovery Manager リポジトリを更新する方法については 第 8 章 Recovery Manager のメンテナンス作業 を参照してください この項では次の項目を取り上げます Recovery Manager バックアップのレポート 保存方針に基づくバックアップが必要なファイルのレポート リカバリ不能な操作の影響を受けるデータ ファイルのレポート 不要なバックアップのレポート データベース スキーマのレポート Recovery Manager バックアップのレポート レポートを使用すると バックアップおよびリカバリ計画が実際にデータベースのリカバリ可能性の要件を満たしていることを確認できます データベースがリカバリ可能であるかどうかを判断するために使用する REPORT には 主に次の 2 つの形式があります REPORT NEED BACKUP 構成済の保存方針または指定した保存方針を満たすためにバックアップする必要があるデータベース ファイルがレポートされます REPORT UNRECOVERABLE ダイレクト パス インサートなどの NOLOGGING 操作の影響を受けているためにバックアップを必要とするデータベース ファイルがレポートされます 注意 : REPORT コマンドでは Recovery Manager リポジトリ内の情報を基に出力が行われます Recovery Manager による制御の外部でバックアップが操作されている場合 ( たとえば いくつかのディスクベースのバックアップが削除されている場合や テープ バックアップが一時的に使用不可になっていたり 完全に消失している場合 ) CROSSCHECK CHANGE CATALOG UNCATALOG および DELETE コマンドを使用して 使用可能な実際のバックアップ セットを含むように Recovery Manager リポジトリ レコードを更新します ( 第 8 章 Recovery Manager のメンテナンス作業 を参照 ) そうしないと REPORT の出力が実際と異なる場合があります 4-28 Oracle Database バックアップおよびリカバリ基礎

99 バックアップおよびデータベース スキーマのレポート 保存方針に基づくバックアップが必要なファイルのレポート REPORT NEED BACKUP コマンドを使用して 特定の保存方針に基づくバックアップが必要なデータベース ファイルを判断します 引数を指定せずに REPORT NEED BACKUP を実行すると 現行の保存方針でバックアップが必要なオブジェクトがレポートされます REDUNDANCY が 1 に設定されている構成済の保存方針の出力は 次の例のようになります REPORT NEED BACKUP; RMAN retention policy will be applied to the command RMAN retention policy is set to redundancy 1 Report of files with less than 1 redundant backups File #bkps Name /oracle/oradata/trgt/undotbs01.dbf 注意 : CONFIGURE RETENTION POLICY TO NONE を使用して保存方針を無効にしている場合 REPORT NEED BACKUP はエラー メッセージを戻します これは 保存方針がないと Recovery Manager はバックアップする必要のあるファイルを決定できないためです 様々な保存方針での Recovery Manager の REPORT NEED BACKUP の使用 次のいずれかの形式のコマンドを使用して REPORT NEED BACKUP に様々な条件を指定できます REPORT NEED BACKUP RECOVERY WINDOW OFn DAYS バックアップがリカバリ期間ベースの保存方針を満たす必要があるオブジェクトが表示されます REPORT NEED BACKUP REDUNDANCYn バックアップが冗長性ベースの保存方針を満たす必要があるオブジェクトが表示されます REPORT NEED BACKUP DAYS = n リカバリ用に n 日分より多いアーカイブ REDO ログを必要とするファイルが表示されます REPORT NEED BACKUP INCREMENTAL n リカバリ用に n 個より多い増分バックアップの適用を必要とするファイルが表示されます 表領域およびデータ ファイルでの Recovery Manager の REPORT NEED BACKUP の使用 REPORT NEED BACKUP を使用して データベース全体の確認 指定された表領域のスキップ または様々な保存方針に対する特定の表領域またはデータ ファイルのみの確認を行うことができます 次に例を示します RMAN> REPORT NEED BACKUP RECOVERY WINDOW OF 2 DAYS DATABASE SKIP TABLESPACE TBS_2; RMAN> REPORT NEED BACKUP REDUNDANCY 2 DATAFILE 1; RMAN> REPORT NEED BACKUP TABLESPACE TBS_3; # uses configured retention policy RMAN> REPORT NEED BACKUP INCREMENTAL 2; # checks entire database 参照 : REPORT NEED BACKUP の使用可能なすべてのオプションおよび出力の様々な列ヘッダーについては Oracle Database バックアップおよびリカバリ リファレンス を参照してください Recovery Manager を使用したデータベースのバックアップ 4-29

100 バックアップおよびデータベース スキーマのレポート テープまたはディスク上のバックアップのみでの REPORT NEED BACKUP の使用 REPORT NEED BACKUP でテストするバックアップをディスクベースまたはテープベースのバックアップのみに制限できます 次に例を示します RMAN> REPORT NEED BACKUP RECOVERY WINDOW OF 2 DAYS DATABASE DEVICE TYPE SBT; RMAN> REPORT NEED BACKUP DEVICE TYPE DISK; RMAN> REPORT NEED BACKUP TABLESPACE TBS_3 DEVICE TYPE SBT; リカバリ不能な操作の影響を受けるデータ ファイルのレポート ダイレクト ロード インサートなどのリカバリ不能な操作によってデータ ファイルが変更されている場合 リカバリ不能な操作では REDO が生成されないため 通常のメディア リカバリを使用してファイルをリカバリすることはできません このような操作の後に影響を受けるデータ ファイルの全体バックアップまたは増分バックアップのいずれかを実行して リカバリ不能な操作の影響を受けるデータ ブロックを Recovery Manager を使用してリカバリできるようにする必要があります リカバリ不能な操作の影響を受けるデータ ファイル およびバックアップからデータ ファイルをリストア可能にするために必要なバックアップのタイプを識別するには REPORT UNRECOVERABLE コマンドを使用します 次に例を示します RMAN> REPORT UNRECOVERABLE; Report of files that need backup due to unrecoverable operations File Type of Backup Required Name full /oracle/oradata/trgt/system01.dbf 不要なバックアップのレポート OBSOLETE キーワードを指定すると 不要な ( 指定した保存方針を満たす必要がない ) バックアップ セット バックアップ ピースおよびデータ ファイルのコピーをレポートできます 他のオプションを指定せずに REPORT OBSOLETE を実行すると 現行の保存方針で不要とみなされるバックアップが表示されます 次に例を示します RMAN> REPORT OBSOLETE; Datafile Copy FEB-05 /backup/ora_df _s70_s1 Datafile Copy FEB-05 /backup/ora_df _s71_s1 Datafile Copy FEB-05 /backup/ora_df _s72_s1 Backup Set FEB-05 Backup Piece FEB-05 /backup/ora_df _s76_s1... RECOVERY WINDOW および REDUNDANCY オプションを指定して REPORT OBSOLETE を使用することによって 様々なリカバリ期間ベースまたは冗長性ベースの保存方針に基づいて不要とみなされるバックアップを確認できます 次に例を示します REPORT OBSOLETE RECOVERY WINDOW OF 3 DAYS; REPORT OBSOLETE REDUNDANCY 1; REPORT コマンドにデバイス タイプを指定することによって 不要なファイルを確認する際にディスクまたはテープ上のバックアップのみが検索されるように指定できます 次に例を示します REPORT OBSOLETE RECOVERY WINDOW OF 3 DAYS DEVICE TYPE DISK; REPORT OBSOLETE REDUNDANCY 1; 4-30 Oracle Database バックアップおよびリカバリ基礎

101 バックアップおよびデータベース スキーマのレポート 不要なバックアップをレポートする方法 1. ターゲット データベースとリカバリ カタログ ( 使用している場合 ) に接続します 2. Recovery Manager リポジトリに様々なバックアップに関する現行情報が含まれるようにするため CROSSCHECK コマンドを発行してディスク上のバックアップの状態と比較してリポジトリのバックアップの状態を更新するか または CHANGE CATALOG UNCATALOG および DELETE コマンドを使用して個々のバックアップの状態を直接指定する場合があります 最も簡単な例として 次のいずれかのコマンドを使用して ディスクまたはテープ ( あるいはその両方 ) 上のすべてのバックアップをクロスチェックできます RMAN> CROSSCHECK BACKUP DEVICE TYPE DISK; RMAN> CROSSCHECK BACKUP DEVICE TYPE SBT; RMAN> CROSSCHECK BACKUP; # crosshecks all backups on all devices 実際に使用可能なバックアップ セットが含まれるように Recovery Manager リポジトリを更新する方法の詳細は 第 8 章 Recovery Manager のメンテナンス作業 を参照してください 3. REPORT OBSOLETE を実行して リカバリの必要がなくなったために不要となったバックアップを識別します 次に例を示します # lists backups that not needed to recover the database to within last week REPORT OBSOLETE RECOVERY WINDOW OF 7 DAYS; # lists backups not needed for redundancy-based retention policy, considering only backups stored on tape REPORT OBSOLETE REDUNDANCY = 2 DEVICE TYPE sbt; 参照 : データベース スキーマのレポート Recovery Manager のバックアップ保存方針の概要については 3-18 ページの バックアップ保存方針の構成 を参照してください Recovery Manager バックアップを削除する方法および Recovery Manager リポジトリから Recovery Manager バックアップのレコードを削除する方法の詳細は 8-8 ページの CROSSCHECK 後の期限切れの Recovery Manager のバックップの削除 を参照してください REPORT SCHEMA コマンドを実行すると データベース ファイルに関する情報が表示されます ターゲット データベースとリカバリ カタログ ( 使用している場合 ) に接続してから REPORT SCHEMA を実行します 次に例を示します RMAN> REPORT SCHEMA; List of Permanent Datafiles =========================== File Size(MB) Tablespace RB segs Datafile Name SYSTEM *** /oracle/oradata/tbs_01.f 2 50 SYSAUX *** /oracle/oradata/tbs_ax1.f 3 2 SYSTEM *** /oracle/oradata/tbs_02.f 4 2 TBS_1 *** /oracle/oradata/tbs_11.f TBS_4 *** /oracle/oradata/tbs_43.f 22 2 TBS_5 *** /oracle/oradata/tbs_53.f List of Temporary Files Recovery Manager を使用したデータベースのバックアップ 4-31

102 バックアップおよびデータベース スキーマのレポート ======================= File Size(MB) Tablespace Maxsize(MB) Tempfile Name TEMP /oracle/oradata/tbs_tmp1.f 注意 : リカバリ カタログを使用すると atclause を使用して 過去の時刻 SCN またはログ順序番号を指定できます 次に例を示します REPORT SCHEMA AT TIME 'SYSDATE-14'; # schema 14 days ago REPORT SCHEMA AT SCN 1000; # schema at scn 1000 REPORT SCHEMA AT SEQUENCE 100 THREAD 1; # schema at sequence Oracle Database バックアップおよびリカバリ基礎

103 5 リストア ポイントおよび Oracle Flashback Database を使用したデータ保護 この章では Oracle Flashback Database およびリストア ポイントの概要と これらをデータ保護計画に組み込んだ場合の 設定 継続的な監視 およびこれらの機能に関連したメンテナンスについて説明します この章では 次の項目について説明します リストア ポイントおよび Oracle Flashback Database の概要 通常のリストア ポイントと保証付きリストア ポイントの使用 Oracle Flashback Database の設定とメンテナンス 注意 : Oracle Flashback Database 通常のリストア ポイントおよび保証付きリストア ポイントを使用したリカバリの使用例の詳細は 第 7 章 フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 を参照してください リストア ポイントおよび Oracle Flashback Database を使用したデータ保護 5-1

104 リストア ポイントおよび Oracle Flashback Database の概要 リストア ポイントおよび Oracle Flashback Database の概要 Oracle Flashback Database およびリストア ポイントは互いに関連する Oracle のデータ保護機能で 不要なデータベースの変更を元に戻す場合に Point-in-Time リカバリより効率的な代替機能を提供します この章では 最初に Oracle Flashback Database の概要を説明し 次にリストア ポイントの概要を説明します Oracle Flashback Database を使用すると 特定の時間枠内での不要なデータベースの変更による影響を無効にして データベース全体を過去のある時点に戻すことができます 結果は データベースの Point-in-Time リカバリと同じです リストア ポイントは Oracle Flashback Database および他のリカバリ操作に関連する機能を提供します 特に 保証付きリストア ポイントでは Oracle Flashback Database に対する補完機能が提供されるため ユーザーが SCN を選択し Oracle Flashback Database をその SCN に対して使用できるという要件が満たされます ただし 保証付きリストア ポイントと現在の SCN の間に存在する SCN に対しては必ずしも使用できるわけではありません リストア ポイントおよび Oracle Flashback Database は それぞれ独立して使用することも 一緒に使用することもできます いずれの場合でも Recovery Manager の FLASHBACK DATABASE コマンド または SQL*Plus の FLASHBACK DATABASE 文を使用して データベースを指定した SCN まで実際に戻します 次に例を示します FLASHBACK DATABASE TO RESTORE POINT 'before_upgrade'; FLASHBACK DATABASE TO SCN ; Oracle Flashback Database のその他の一般機能の概要を説明した後で 保証付きリストア ポイントの機能 2 つの機能の相互作用 およびいずれかの機能または両方の機能を使用するように選択した場合のトレードオフについて説明します この項では次の項目を取り上げます Oracle Flashback Database 通常のリストア ポイント 保証付きリストア ポイント Oracle Flashback Database および保証付きリストア ポイントのロギング Oracle Flashback Database Oracle Flashback Database には Recovery Manager(FLASHBACK DATABASE コマンドを使用 ) と SQL*Plus(FLASHBACK DATABASE 文を使用 ) の両方からアクセスできます Oracle Flashback Database を使用すると 論理的なデータ破損またはユーザー エラーからデータベース全体を迅速にリカバリできます 機能は従来の Point-in-Time リカバリと同様で データベースを過去の状態に戻すことができます ただし Oracle Flashback Database は データ ファイルをバックアップからリストアする必要がなく アーカイブ REDO ログから適用する必要がある変更が少ないため Point-in-Time リカバリより非常に高速です Oracle Flashback Database を使用すると データ ファイルが正常であるかぎり データベースに対する多くの不要な変更を元に戻すことができます これには データベースを以前のインカネーションの状態に戻すこと つまり OPEN RESETLOGS の影響を取り消すことが含まれます 注意 : 不要なデータベースの変更を元に戻す際の FLASHBACK DATABASE コマンドの使用方法については 7-13 ページの Oracle Flashback Database を使用したデータベースの変更の取消し を参照してください Oracle Flashback Database は独自のロギング メカニズムを使用して フラッシュ リカバリ領域に格納されるフラッシュバック ログフラッシュバック ログを作成します Oracle Flashback Database は フラッシュバック ログが使用可能な場合にのみ使用できます そのため この機能を使用する 5-2 Oracle Database バックアップおよびリカバリ基礎

105 リストア ポイントおよび Oracle Flashback Database の概要 には フラッシュバック ログを作成するように事前にデータベースを設定しておく必要があります Oracle Flashback Database を有効にするには フラッシュ リカバリ領域を設定し フラッシュバックの保存ターゲットを設定して Oracle Flashback Database で過去のどの時点のデータベースをリストアするかを指定します この時点以降 定期的に すべてのデータ ファイルで変更された各ブロックのイメージがフラッシュバック ログにコピーされます これらのブロック イメージを後で再利用して ログが記録された時点のデータ ファイルの内容を再構築できます Oracle Flashback Database を使用してデータベースを過去の目標時点の状態にリストアする場合 その時点以降に変更された各ブロックは 目標時点の直前のフラッシュバック ログにあるブロックのコピーからリストアされます その後で REDO ログが使用され ブロックがフラッシュバック ログにコピーされた時点以降の変更が再適用されます 注意 : REDO ログは テープまたはディスク上に保存され フラッシュバック ログに記録されている期間中常に使用可能である必要があります ( ただし 実際は Point-in-Time リカバリをサポートするために 通常 REDO ログはフラッシュバックの保存ターゲットより大幅に長い期間保存される必要があります ) データベースのフラッシュバックの期間 FLASHBACK DATABASE コマンドをサポートするための十分なフラッシュバック ログ データが現在存在する SCN の範囲をデータベースのフラッシュバックの期間データベースのフラッシュバックの期間と呼びます フラッシュ リカバリ領域で空き領域が少なくなると 構成済の保存方針に必要なファイルのための領域を確保するために フラッシュバック ログが削除される場合があります その結果として データベースのフラッシュバックの期間がフラッシュバックの保存ターゲットより短くなる可能性があります これは フラッシュ リカバリ領域のサイズ 保持する必要がある他のバックアップ および必要とされるフラッシュバック ロギングのデータ量によって決まります リストア ポイントおよび Oracle Flashback Database を使用したデータ保護 5-3

106 リストア ポイントおよび Oracle Flashback Database の概要 注意 : フラッシュバックの保存ターゲットは Oracle Flashback Database を使用できるという絶対の保証ではありません フラッシュ リカバリ領域に 保存方針を満たすために保持する必要があるフラッシュバック ログとファイル ( アーカイブ REDO ログやその他のバックアップなど ) の両方を格納できる十分な領域がない場合 その他のファイル用にフラッシュ リカバリ領域に空き領域を確保するため 最も古い SCN からフラッシュバック ログが削除される場合があります データベースのフラッシュバックの期間は 使用可能なフラッシュバック ログにある最も古い SCN より前には拡張できません フラッシュバック ログは フラッシュ リカバリ領域以外にはバックアップできません このため データベースのフラッシュバックの期間を満たすために十分なログをより確実に保持するには フラッシュ リカバリ領域で使用できる空き領域を最大化します 詳細は 5-11 ページの フラッシュバック ログを格納するためのフラッシュ リカバリ領域のサイズ設定 を参照してください また 表領域の削除やデータ ファイルの縮小など データベースに対して実行できる操作の多くは Oracle Flashback Database を使用して無効にすることができません このような操作の後では データベースのフラッシュバックの期間は その操作の直後の時点から開始されます データベースのフラッシュバックの期間が十分に長くないために FLASHBACK DATABASE が失敗した場合は データベースの Point-in-Time リカバリ (DBPITR) を使用すると 同様の結果を取得できることが多くあります DBPITR の詳細は 7-18 ページの データベースの Point-In-Time リカバリの実行 を参照してください Oracle Flashback Database を使用して特定の時点に戻すことが可能であることを保証したり フラッシュバックの期間のサイズを保証する唯一の方法は 保証付きリストア ポイントを使用することです 保証付きリストア ポイントおよび Oracle Flashback Database の詳細は 5-5 ページの 保証付きリストア ポイント を参照してください 通常のリストア ポイント 通常のリストア ポイントを作成すると リストア ポイント名が特定の時点または SCN に割り当てられます これは ブックマークまたは別名のようなもので SCN を指定する場合の省略表現として RESTORE POINT 句を認識するコマンドで使用できます 取り消す必要が可能性としてあるような操作を実行する前に 通常のリストア ポイントを作成できます リストア ポイントの名前と SCN は 制御ファイルに記録されます このため 後で Oracle Flashback Database Oracle Flashback Table または Point-in-Time リカバリを使用する必要がある場合は 時刻書式や SCN のかわりにリストア ポイントの名前を使用して目標時点を参照できます 後で取り消すような操作を実行する前に通常のリストア ポイントを定義すると 事前に SCN を手書きで記録したり 問題が発生した後で Oracle Flashback Query などの機能を使用して正しい SCN を調査する必要がなくなります 通常のリストア ポイントは 非常に軽量なものです 制御ファイルには データベースのパフォーマンスに影響を与えることなく 数千もの通常のリストア ポイントの記録を保持できます 通常のリストア ポイントは手動で削除しない場合 最終的には制御ファイルで期限切れになるため 継続的なメンテナンスは必要ありません リストア ポイントを使用できるコマンド 次のコマンドでは リストア ポイントを使用してターゲット SCN を指定できます Recovery Manager の RECOVER DATABASE および FLASHBACK DATABASE コマンド SQL*Plus の FLASHBACK TABLE 文 5-4 Oracle Database バックアップおよびリカバリ基礎

107 リストア ポイントおよび Oracle Flashback Database の概要 注意 : 一般的には 保証付きリストア ポイントは 通常のリストア ポイントで動作するすべてのコマンドで SCN の別名として使用できます 特に明記されていない場合 通常のリストア ポイントの使用箇所および使用方法に関する情報は保証付きリストア ポイントにも適用されます 保証付きリストア ポイント 通常のリストア ポイントと同様に 保証付きリストア ポイントはリカバリ操作時に SCN の別名として使用できます ただし これは Oracle Flashback Database 機能の使用に関連する個別の機能も提供します 特定の SCN で保証付きリストア ポイントを作成すると フラッシュバック ロギングがデータベースで無効な場合でも Oracle Flashback Database 操作を実行して データベースをその SCN の時点の状態に戻すことができるという要件が満たされます フラッシュバック ロギングが有効な場合 保証付きリストア ポイントを作成することで 最も古い保証付きリストア ポイントが作成された時点以降の任意の時点までデータベースをフラッシュバックするのに必要なフラッシュバック ログが保持されます 保証付きリストア ポイントを使用すると フラッシュ リカバリ領域に必要なログを格納するための十分なディスク領域があるかぎり データベース全体を数日前または数週間前の正常な状態に戻すことができます Oracle Flashback Database の場合と同様に 保証付きリストア ポイントを使用して ダイレクト ロード インサートなどの NOLOGGING 操作の影響を無効にすることもできます 注意 : Oracle Flashback Database に適用される制限は 保証付きリストア ポイントにも適用されます たとえば データ ファイルを縮小したり 表領域を削除すると その影響を受けるデータ ファイルは保証付きリストア ポイントまでフラッシュバックされなくなります ストレージ スナップショットの代替方法としての保証付きリストア ポイントの使用 実際には 保証付きリストア ポイントは 大規模なデータベースの更新 アプリケーションのパッチ インストールや更新など 危険を伴う操作の前にデータベースを保護するために使用されるストレージ スナップショットの有効な代替方法として提供されます スナップショットや複製データベースを作成し これに対して操作をテストするのではなく 必要なフラッシュバック ログが保持されていることを確認し プライマリ データベースまたはスタンバイ データベースで保証付きリストア ポイントを作成してから 危険を伴う操作を実行できます Oracle Flashback Database および保証付きリストア ポイントのロギング Oracle Flashback Database および保証付きリストア ポイントのロギングは 変更が適用される前のデータ ファイル ブロックのイメージを取得して行われます このため このイメージを使用すると FLASHBACK DATABASE コマンドを実行することで データベースを以前の状態に戻すことができます 通常のフラッシュバックのロギングと 保証付きリストア ポイントのロギングとの主な違いは ブロックが記録されるタイミングと フラッシュ リカバリ領域の領域圧迫に応じてログが削除できるかどうかに関係します これらの違いは ログに使用する領域およびデータベース パフォーマンスに影響します データベースのフラッシュバック ロギングを有効にするかどうか または保証付きリストア ポイントを使用するかどうか あるいはこの両方を行うかどうかは リカバリ可能性の目的と これらの機能を個別に使用した場合および同時に使用した場合のパフォーマンスと領域の使用量の予測によって異なります リストア ポイントおよび Oracle Flashback Database を使用したデータ保護 5-5

108 リストア ポイントおよび Oracle Flashback Database の概要 保証付きリストア ポイントおよびフラッシュ リカバリ領域の領域使用状況 保証付きリストア ポイントを作成した場合は データベース全体のフラッシュバック ロギングを有効にしているかどうかに関係なく フラッシュ リカバリ領域で使用可能な領域を監視する必要があります フラッシュ リカバリ領域内のファイルが保証を満たすために必要である場合 そのファイルは削除対象にはなりません このため 保証を満たすために必要なフラッシュバック ログとその他のファイル およびバックアップの保存方針を満たすために必要なファイルの保持によって フラッシュ リカバリ領域が完全に一杯になってしまう可能性があります 注意 : 保存方針によって義務付けられている要件や保証付きリストア ポイントのために フラッシュ リカバリ領域に削除対象となるファイルがない場合 データベースはディスクの領域不足が発生した場合と同じように動作します 多くの場合 これによってデータベースが停止します フラッシュ リカバリ領域が一杯になった場合の影響については 3-20 ページの フラッシュ リカバリ領域で領域が使用不可の場合 を参照してください 参照 : フラッシュ リカバリ領域のディスク領域の使用状況を監視する方法については 5-12 ページの フラッシュ リカバリ領域におけるフラッシュバック ログ用の領域管理 を参照してください フラッシュバック ロギングが無効な場合の保証付きリストア ポイントのロギング Oracle Flashback Database のロギングが無効な場合に保証付きリストア ポイントを作成すると 保証付きリストア ポイントの時点以降にデータ ファイル ブロックが最初に変更される際 変更前のブロックのイメージがフラッシュバック ログに格納されます このため フラッシュバック ログには 保証付きリストア ポイントが作成された時点で変更されているすべてのデータ ブロックの内容が格納されます ただし その後では 同じブロックに対する変更があっても そのブロックの最終変更以降に別の保証付きリストア ポイントが作成されないかぎり ブロックの内容が再び記録されることはありません この方法のロギングでは 次のような重要な因果関係があります 使用可能なブロック イメージは FLASHBACK DATABASE を使用して 保証付きリストア ポイントの時点でのデータ ファイルの内容を再作成するために使用できますが FLASHBACK DATABASE は Oracle Flashback Database のロギングが有効であるかぎり 保証付きリストア ポイントと現時点の間の時点に戻すためには使用できません データベースを中間の時点に戻す必要がある場合 それが可能なのはデータベースの Point-in-Time リカバリのみです 変更された各ブロックが記録されるのは 1 回のみであるため フラッシュバック ロギングが無効な場合 保証付きリストア ポイントのロギングのディスク領域使用量は 一般的に通常のフラッシュバック ロギングよりも非常に少なくなります Oracle Flashback Database が有効な場合は フラッシュバック ログが継続的に大きくなりますが 保証付きリストア ポイントは これを監視しなくても数日間または数週間でも保持することができます また データベースのフラッシュバック ロギングを使用しない場合 保証付きリストア ポイントのロギングにおけるパフォーマンスのオーバーヘッドも通常は低くなります 保証付きリストア ポイントを作成した時点にデータベースを戻す必要がある場合 一般的には Oracle Flashback Database のロギングを無効にして 保証付きリストア ポイントのみを使用する方がより効率的です たとえば 本番データベース サーバーで週末にアプリケーションのアップグレードを実行する予定がある場合は アップグレード プロセスの開始時に保証付きリストア ポイントを作成することで このプロセスが失敗に終わっても バックアップからデータベースをリストアするかわりに FLASHBACK DATABASE を使用して変更を取り消すことができます 5-6 Oracle Database バックアップおよびリカバリ基礎

109 通常のリストア ポイントと保証付きリストア ポイントの使用 保証付きリストア ポイントを定義している場合の Oracle Flashback Database のロギング Oracle Flashback Database が有効で 1 つ以上の保証付きリストア ポイントが定義されている場合 データベースでは通常のフラッシュバック ロギングが実行されます これによって パフォーマンスのオーバーヘッドが発生したり データベースの動作パターンによっては フラッシュ リカバリ領域で重大な領域圧迫が発生する可能性があります このような場合でも Oracle Flashback Database の通常のロギングとは異なり フラッシュ リカバリ領域には フラッシュバック ログが常に保持されます このログは FLASHBACK DATABASE を使用して 現在定義されている最も古い保証付きリストア ポイントまでの任意の時点に戻すために必要です フラッシュバック ログは 保証を満たすために必要な場合 領域圧迫に応じて削除されることはありません この使用例では FLASHBACK DATABASE をフラッシュバックの期間内の任意の時点に対して柔軟に使用でき 保証付きリストア ポイントによる確実性がありますが 保証をサポートするためには フラッシュ リカバリ領域で使用される領域を監視する必要があります 詳細は 5-9 ページの 保証付きリストア ポイントの領域使用状況の監視 および 5-12 ページの フラッシュ リカバリ領域におけるフラッシュバック ログ用の領域管理 を参照してください 通常のリストア ポイントと保証付きリストア ポイントの使用 この項では 通常のリストア ポイントと保証付きリストア ポイントの管理に使用するコマンドについて説明します この項では次の項目を取り上げます 通常のリストア ポイントと保証付きリストア ポイントの作成 リストア ポイントのリスト リストア ポイントの削除 保証付きリストア ポイントの使用の要件 保証付きリストア ポイントの使用をサポートするには データベースは次の要件を満たす必要があります COMPATIBLE 初期化パラメータを 10.2 以上に設定する必要があります データベースを ARCHIVELOG モードで実行している必要があります FLASHBACK DATABASE 操作を使用してデータベースを保証付きリストア ポイントに戻すには リストア ポイントの前後のアーカイブ REDO ログを使用する必要があります フラッシュ リカバリ領域を構成する必要があります (3-13 ページの Recovery Manager 用のフラッシュ リカバリ領域の設定 を参照 ) 保証付きリストア ポイントでは フラッシュバック ロギングに似たメカニズムが使用されます フラッシュバック ロギングの場合と同様に フラッシュ リカバリ領域に必要なログが格納される必要があります Oracle Flashback Database が有効になっていない場合 保証付きリストア ポイントをはじめて作成する ( または 以前に作成されたすべての保証付きリストア ポイントが削除されている ) 際には データベースがマウントされている必要があります ただし オープンされていないことが必要です 注意 : 通常のリストア ポイントの使用には特別な要件はありません 通常のリストア ポイントと保証付きリストア ポイントの作成 通常のリストア ポイントまたは保証付きリストア ポイントを作成するには SQL*Plus で リストア ポイントの名前を指定し 保証付きリストア ポイントであるか通常のリストア ポイント ( デフォルト ) であるかを指定して CREATE RESTORE POINT 文を使用します リストア ポイントの作成時に データベースがオープンまたはマウントされている可能性があります データベースがマウントされている場合 ( フィジカル スタンバイ データベースでないかぎり ) 正しく停止されている必要があります リストア ポイントおよび Oracle Flashback Database を使用したデータ保護 5-7

110 通常のリストア ポイントと保証付きリストア ポイントの使用 通常のリストア ポイントの作成方法の例を次に示します SQL> CREATE RESTORE POINT before_upgrade; Restore point created. 保証付きリストア ポイントの作成方法の例を次に示します SQL> CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE; Restore point created. リストア ポイントのリスト 現在定義されているリストア ポイントのリストを表示するには V$RESTORE_POINT 制御ファイル ビューに次の問合せを発行します SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE,STORAGE_SIZE FROM V$RESTORE_POINT; 各リストア ポイントの名前 リストア ポイントが作成された SCN 壁時計時刻およびデータベースのインカネーション番号 各リストア ポイントが保証付きリストア ポイントであるかどうか およびそのリストア ポイントへの Oracle Flashback Database 操作に必要な情報を保存するために使用されるフラッシュ リカバリ領域の量を表示できます また 次の問合せを使用して 保証付きリストア ポイントのみを表示することもできます SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE='YES'; 通常のリストア ポイントの場合 STORAGE_SIZE が 0( ゼロ ) になります 保証付きリストア ポイントの場合 STORAGE_SIZE は フラッシュ リカバリ領域のディスク領域の容量を示します この領域は そのリストア ポイントに対する FLASHBACK DATABASE を保証するために必要なログの保持に使用されます V$RESTORE_POINT の列の詳細は Oracle Database リファレンス を参照してください リストア ポイントの削除 参照 : SQL の CREATE RESTORE POINT 文の詳細は Oracle Database SQL リファレンス を参照してください 既存のリストア ポイントが不要であることを確認した場合 または既存のリストア ポイントの名前を使用して新しいリストア ポイントを作成する場合は SQL*Plus 文 DROP RESTORE POINT を使用して リストア ポイントを削除できます 次に例を示します SQL> DROP RESTORE POINT before_app_upgrade; Restore point dropped. 同じ文を使用して 通常のリストア ポイントおよび保証付きリストア ポイントの両方を削除できます 5-8 Oracle Database バックアップおよびリカバリ基礎

111 Oracle Flashback Database の設定とメンテナンス 注意 : 通常のリストア ポイントは 明示的に削除しなくても 最終的には制御ファイルで期限切れになります 制御ファイル内のリストア ポイントの保持を管理している規則は 次のとおりです 最新の 2048 個のリストア ポイントは その期限に関係なく 常に制御ファイルに保持されます CONTROL_FILE_RECORD_KEEP_TIME の値よりも新しいリストア ポイントは 定義されているリストア ポイント数に関係なく いずれも保持されます これらの条件を満たさない通常のリストア ポイントは 制御ファイルで期限切れになる場合があります 保証付きリストア ポイントは 制御ファイルで期限切れになることはありません これらは 明示的に削除されるまで保持されます 参照 : SQL の DROP RESTORE POINT 文の詳細は Oracle Database SQL リファレンス を参照してください 保証付きリストア ポイントの領域使用状況の監視 保証付きリストア ポイントがデータベースに定義されている場合は 保証を満たすために必要なファイルのために フラッシュ リカバリ領域で使用されている領域の容量を監視する必要があります 保証付きリストア ポイントを表示する問合せ (5-8 ページの リストア ポイントのリスト を参照 ) を使用し STORAGE_SIZE 列を参照して 各保証付きリストア ポイントに関連するファイルに必要な領域を決定します フラッシュ リカバリ領域の合計の使用量を確認するには 3-17 ページの V$RECOVERY_FILE_DEST および V$FLASH_ RECOVERY_AREA_USAGE の使用 で説明した問合せを使用します Oracle Flashback Database の設定とメンテナンス この項では Oracle Flashback Database の計画 これを使用するためのデータベースの構成 および有効なメンテナンス 監視 チューニング手順について説明します この項の内容は 次のとおりです Oracle Flashback Database の制限事項 Oracle Flashback Database の有効化の要件 Oracle Flashback Database のロギングの有効化 フラッシュバック ログを格納するためのフラッシュ リカバリ領域のサイズ設定 フラッシュ リカバリ領域におけるフラッシュバック ログ用の領域管理 現行のデータベースのフラッシュバックの期間の確認 Oracle Flashback Database のパフォーマンス チューニング Oracle Flashback Database のパフォーマンスの影響の監視 Oracle Flashback Database の制限事項 Oracle Flashback Database では コマンドの実行時に存在するデータ ファイルに対する変更が取り消されるため 次の制限事項があります Oracle Flashback Database で実行できるのは Oracle データベースで行われたデータ ファイルへの変更の取消しのみです これは メディア障害を修復したり 誤って削除したデータ ファイルをリカバリする場合には使用できません Oracle Flashback Database を使用して データ ファイルの縮小操作を取り消すことはできません リストア ポイントおよび Oracle Flashback Database を使用したデータ保護 5-9

112 Oracle Flashback Database の設定とメンテナンス データベースの制御ファイルがバックアップからリストアされるか または再作成された場合 フラッシュバック ログのすべての累積情報は削除されます FLASHBACK DATABASE は 制御ファイルのリストアまたは再作成の前の時点に戻すために使用することはできません Oracle Flashback Database の目標時点で NOLOGGING 操作が実行されていた場合 NOLOGGING 操作の影響を受けているデータベース オブジェクトおよびデータ ファイルにブロック破損が残る可能性があります たとえば NOLOGGING モードでダイレクト パス インサート操作を実行し この操作が 2005 年 4 月 1 日の 9 時から 9 時 15 分まで実行され 後で Oracle Flashback Database を使用して同じ日の 9 時 7 分の目標時点に戻すことが必要になった場合 Oracle Flashback Database 操作の完了後 ダイレクト パス インサートによって更新されたオブジェクトおよびデータ ファイルにブロック破損が残っている場合があります 可能であれば Oracle Flashback Database では NOLOGGING 操作と重なる目標時点または SCN を使用しないでください また 影響を受けるデータ ファイルに対して NOLOGGING 操作の直後の全体バックアップまたは増分バックアップを実行して 操作後の時点にリカバリできるようにします Oracle Flashback Database を使用して ダイレクト パス インサートなどの操作を実行中の時点にデータベースを戻す予定がある場合 操作を LOGGING モードで実行することを検討してください NOLOGGING モードをサポートしている操作の詳細は Oracle Database SQL リファレンス の logging_clause の説明を参照してください Oracle Flashback Database の有効化の要件 Oracle Flashback Database を有効にするための要件は 次のとおりです Oracle Flashback Database の操作ではアーカイブ ログが使用されるため データベースを ARCHIVELOG モードで実行している必要があります フラッシュバック ログはフラッシュ リカバリ領域にのみ格納できるため フラッシュ リカバリ領域を有効にしておく必要があります Real Application Clusters データベースの場合 フラッシュ リカバリ領域は クラスタ ファイル システムまたは ASM に格納する必要があります Oracle Flashback Database のロギングの有効化 Oracle Flashback Database のロギングを有効にするには DB_FLASHBACK_RETENTION_ TARGET 初期化パラメータを設定し ALTER DATABASE FLASHBACK ON 文を発行します 次の手順を実行します 1. SQL*Plus を起動し データベースがマウントされているが オープンされていないことを確認します 次に例を示します SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; 2. オプションで DB_FLASHBACK_RETENTION_TARGET に フラッシュバックの期間の長さを分単位で設定します SQL> ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320; # 3 days デフォルトでは DB_FLASHBACK_RETENTION_TARGET は 1 日 (1440 分 ) に設定されます 3. データベース全体に対して Oracle Flashback Database 機能を有効にします SQL> ALTER DATABASE FLASHBACK ON; 5-10 Oracle Database バックアップおよびリカバリ基礎

113 Oracle Flashback Database の設定とメンテナンス デフォルトでは すべての永続表領域用のフラッシュバック ログが生成されます 必要に応じて 特定の表領域のフラッシュバック ロギングを無効にして オーバーヘッドを軽減できます SQL> ALTER TABLESPACE tbs_3 FLASHBACK OFF; 表領域のフラッシュバック ロギングは 次のコマンドを使用して 後で再度有効にできます SQL> ALTER TABLESPACE tbs_3 FLASHBACK ON; 表領域に対して Oracle Flashback Database を無効にする場合は FLASHBACK DATABASE を実行する前に データ ファイルをオフラインにする必要があります 次のコマンドを使用して データベース全体のフラッシュバック ロギングを無効にできます SQL> ALTER DATABASE FLASHBACK OFF; フラッシュバック ロギングは スタンバイ データベースでも有効にできます スタンバイ データベースで Oracle Flashback Database を有効にすると そのスタンバイ データベースで Oracle Flashback Database を実行できます Data Guard 環境では スタンバイ データベースで Oracle Flashback Database を有効にすると様々な用途に使用できます 詳細は Oracle Data Guard 概要および管理 を参照してください フラッシュバック ログを格納するためのフラッシュ リカバリ領域のサイズ設定 Oracle Flashback Database を使用する場合 フラッシュバック ログと フラッシュ リカバリ領域に格納される他のファイルを保持するために フラッシュ リカバリ領域にさらに領域を追加する必要があります DB_FLASHBACK_RETENTION_TARGET 初期化パラメータの設定は 間接的にデータベースが保持するフラッシュバック ログ データの量を決定します 一定期間にデータベースによって生成されるフラッシュバック ログのサイズは 大幅に変化する可能性がありますが それは特定のデータベース ワークロードによって異なります 一定期間におけるデータベースの更新によって影響されるブロック数が多いほど その期間に生成されるフラッシュバック ログ データによって使用されるディスク領域は大きくなります データベースのフラッシュバック ログのディスク領域要件の見積り V$FLASHBACK_DATABASE_LOG ビューは フラッシュ リカバリ領域に追加するフラッシュバック ログ用の領域の量を見積もる場合に有効です Oracle Flashback Database のロギングを有効にし フラッシュバックの保存ターゲットを設定すると 一定期間データベースを通常のワークロードで実行して フラッシュバック ログの典型的なサンプルを作成することができます その後 次の問合せを実行します SQL> SELECT ESTIMATED_FLASHBACK_SIZE FROM V$FLASHBACK_DATABASE_LOG; Oracle Flashback Database を有効にした後のデータベース ワークロードに基づいて 現行のフラッシュバックの保存ターゲットに対応するために必要なディスク領域の見積りが計算されて戻されます 予測されるデータベースのフラッシュバック ログを保持するには $FLASHBACK_DATABASE_LOG.ESTIMATED_FLASHBACK_SIZE に指定されたディスク領域のサイズをフラッシュ リカバリ領域のサイズに追加します フラッシュ リカバリ領域内の使用領域は 保存方針に従って保持する必要があるバックアップとアーカイブ ログ および削除の対象となるその他のファイル ( フラッシュバック ログ すでにテープにバックアップしたがディスクにキャッシュされているバックアップなど ) の間で 常に調整されます 他のバックアップの保存要件は満たしていても フラッシュ リカバリ領域にフラッシュバック ログを格納するための十分な領域が割り当てられていない場合は 領域を確保するために リカバリ領域からフラッシュバック ログが削除される場合があります リストア ポイントおよび Oracle Flashback Database を使用したデータ保護 5-11

114 Oracle Flashback Database の設定とメンテナンス フラッシュ リカバリ領域におけるフラッシュバック ログ用の領域管理 フラッシュ リカバリ領域のフラッシュバック ログは直接管理することはできませんが フラッシュバックの保存ターゲットを設定するか 保証付きリストア ポイントを使用すると管理できます ただし データベースのフラッシュバック ログの保持に使用可能な領域を最大化するために フラッシュ リカバリ領域を全体として領域管理できます このようにして フラッシュバックの保存ターゲットが確保される可能性を高くします フラッシュバック ログ用に領域を確保するには BACKUP RECOVERY AREA BACKUP BACKUPSET などを使用して フラッシュ リカバリ領域のその他の内容をテープにバックアップします ファイルのテープへのバックアップを完了した後で DELETE コマンドを使用し フラッシュ リカバリ領域からそのファイルを明示的に削除します この方法でも バックアップの保存方針およびフラッシュバックの保存ターゲットを満たす十分な領域が作成されない場合は フラッシュ リカバリ領域にさらに領域を割り当てます 注意 : フラッシュ リカバリ領域の内容をテープにバックアップする場合 BACKUP RECOVERY AREA を使用すると フラッシュバック ログは含まれません フラッシュバック ログの保持と削除の規則 次の規則によって フラッシュ リカバリ領域におけるフラッシュバック ログの作成 保持 上書きおよび削除が管理されます フラッシュバック ログは フラッシュ リカバリ領域に十分な領域があるかぎり フラッシュバックの保存ターゲットを満たす必要がある場合に必ず作成されます フラッシュバック ログは 古くなり フラッシュバックの保存ターゲットを満たすために必要とされなくなると再利用できます データベースで新しいフラッシュバック ログを作成する必要がある場合に フラッシュ リカバリ領域が一杯になっていたり ディスク領域がない場合は 最も古いフラッシュバック ログがかわりに再利用されます 注意 : 最も古いフラッシュバック ログを再利用すると データベースのフラッシュバックの期間が短くなります ディスク領域が不足しているために 多くのフラッシュバック ログが再利用されると フラッシュバックの保存ターゲットが満たされなくなる場合があります フラッシュ リカバリ領域が一杯になると フラッシュ リカバリ領域によってアーカイブ REDO ログが自動的に削除され その他のファイル用の領域が確保されます この場合 FLASHBACK DATABASE を使用するために その REDO ログ ファイルを使用する必要があるフラッシュバック ログも削除されます 現行のデータベースのフラッシュバックの期間の確認 フラッシュバック ロギングが有効な場合は V$FLASHBACK_DATABASE_LOG.OLDEST_ FLASHBACK_SCN および V$FLASHBACK_DATABASE_LOG.OLDEST_FLASHBACK_TIME を問い合せて データベースのフラッシュバックの期間で最も古い SCN を確認できます 次に例を示します SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME FROM V$FLASHBACK_DATABASE_LOG; この問合せの結果で このデータベースのフラッシュバックの期間ではフラッシュバックの保存ターゲットが満たされないことが恒常的に示される場合は より多くのフラッシュバック ログを格納するために フラッシュ リカバリ領域を増やす必要がある可能性があります 5-12 Oracle Database バックアップおよびリカバリ基礎

115 Oracle Flashback Database の設定とメンテナンス 注意 : このビューは データベースで使用可能なフラッシュバック ログ データがどれくらいあるかを示します ただし フラッシュバック ログ データが使用可能であっても Oracle Flashback Database がデータベース全体に対して正常に終了できなくなる操作 ( データ ファイルの縮小 削除など ) があります この問合せの結果には このような制限は反映されません Oracle Flashback Database を使用してフラッシュバック可能な最新の SCN は データベースの現在の SCN です 次の問合せを実行すると 現在の SCN が戻されます SQL> SELECT CURRENT_SCN FROM V$DATABASE; Oracle Flashback Database のパフォーマンス チューニング フラッシュバック ログをメンテナンスすると Oracle データベース インスタンスで発生するオーバーヘッドが比較的制限されます プロセスおよび I/O のオーバーヘッドを制限するために 変更されたブロックが メモリーからフラッシュバック ログに比較的低い頻度で定期的に書き込まれます Oracle Flashback Database を有効にした大規模な本番データベースのパフォーマンスを向上させるには 次のガイドラインに従うことをお薦めします フラッシュ リカバリ領域には 可能な場合 オペレーティング システムのファイル キャッシュを使用せずに 高速のファイル システムを使用します 通常 フラッシュ リカバリ領域で作成されるフラッシュバック ログなどのファイルは サイズが大きくなります オペレーティング システムのファイル キャッシュは 通常 これらのファイルには効果的でなく 実際には これらのファイルに対する読取りおよび書込みを行うことによって CPU オーバーヘッドが増加する場合があります そのため オペレーティング システムのファイル キャッシュが行われない ASM などのファイル システムを使用することをお薦めします フラッシュ リカバリ領域を保持するファイル システムに 十分なディスク スピンドルを構成します 大規模な本番データベースでは フラッシュバック ログに効果的に書込みを行うために必要なディスク スループットをサポートするために 複数のディスク スピンドルが必要な場合があります フラッシュ リカバリ領域の保持に使用するストレージ システムに不揮発性 RAM が搭載されていない場合は ストライプ化した記憶ボリューム上に 比較的小さいストライプ サイズ (128K など ) でファイル システムを構成します これによって フラッシュバック ログへの 1 回の書込みが複数のスピンドルに分散され パフォーマンスが向上します 大規模な本番データベースでは init.ora パラメータの LOG_BUFFER を 8MB 以上に設定します これによって データベースのフラッシュバック ログの書込み用に 最大のメモリー ( 通常 16MB) が割り当てられます Oracle Flashback Database のロギングを有効にした場合のオーバーヘッドは データベース ワークロードの読取りと書込みの割合によって異なります ワークロードが書込み集中型の場合 Oracle Flashback Database のロギングを有効にするとオーバーヘッドが増加します ( 問合せを実行してもデータは変更されないため Oracle Flashback Database のロギング アクティビティには影響しません ) Oracle Flashback Database のパフォーマンスの影響の監視 フラッシュバック ロギングによるシステムの使用状況を監視する最も有効な方法は Oracle Statspack を使用してパフォーマンス統計情報を収集する方法です たとえば 最初の待機イベントとして flashback buf free by RVWR が表示された場合は フラッシュバック ログを高速で書き込むことができないことを示しています このような場合は 5-13 ページの Oracle Flashback Database のパフォーマンス チューニング で説明したいずれかの方法で フラッシュ リカバリ領域に使用されているファイル システムおよび記憶域をチューニングすることをお薦めします リストア ポイントおよび Oracle Flashback Database を使用したデータ保護 5-13

116 Oracle Flashback Database の設定とメンテナンス V$FLASHBACK_DATABASE_STAT ビュー ( Oracle Database リファレンス を参照 ) には データベースで記録されたフラッシュバック データのバイト数が表示されます ビューの各行は 累積の統計情報 ( 通常 1 時間の累計 ) を示します FLASHBACK_DATA および REDO_ DATA 列には 一定期間中に書き込まれたフラッシュバック データおよび REDO データのバイト数がそれぞれ示されます DB_DATA 列には 読取りおよび書込みが行われたデータ ブロックのバイト数が示されます FLASHBACK_DATA および REDO_DATA は順次書込みに対応し DB_DATA はランダム読取りおよび書込みに対応することに注意してください 順次 I/O とランダム I/O には違いがあるため I/O オーバーヘッドは フラッシュバック ログに対して発行された I/O 操作の回数によって明確に示されます 次の V$SYSSTAT の統計情報には 様々な目的のためにインスタンスから発行された I/O 操作の回数が示されます 列名 列の意味 Physical write I/O request データ ブロックを書き込むために発行された書込み操作の回数 physical read I/O request redo writes flashback log writes データ ブロックを読み取るために発行された読取り操作の回数 REDO ログに書き込むために発行された書込み操作の回数 フラッシュバック ログに書き込むために発行された書込み操作の回数 V$SYSSTAT ビューの列の詳細は Oracle Database リファレンス を参照してください I/O エラーの場合の Flashback Writer(RVWR) ) の動作 フラッシュバックが有効である場合 または保証付きリストア ポイントが存在する場合は バックグランド プロセス RVWR によって フラッシュバック データがフラッシュ リカバリ領域にあるデータベースのフラッシュバック ログに書き込まれます RVWR に I/O エラーが発生した場合 次の動作が予測されます 保証付きリストア ポイントが定義されている場合 RVWR に I/O エラーが発生すると インスタンスがクラッシュします 保証付きリストア ポイントが定義されていない場合 RVWR に I/O エラーが発生しても インスタンスはクラッシュしません これには 2 つの場合があります プライマリ データベースでは データベースのオープン中はデータベースのフラッシュバックが自動的に無効になります すべての既存のトランザクションと問合せは 影響を受けることなく続行されます これは シングル インスタンスおよび RAC の両方で予測される動作です フィジカル スタンバイまたはロジカル スタンバイでは RVWR がハングしたように見え I/O が定期的に再試行されます 最終的に これによってロジカル スタンバイがハングしたり フィジカル スタンバイの管理リカバリがハングする場合があります (Oracle では スタンバイ インスタンスはクラッシュしません これは 最大の保護モードの場合にプライマリ データベースがかわりにクラッシュしなようにするためです ) このハングを解決するには DBA は SHUTDOWN ABORT を実行するか または ALTER DATABASE FLASHBACK OFF を発行します 5-14 Oracle Database バックアップおよびリカバリ基礎

117 6 データベースの完全リストアおよび完全リカバリの実行 この章では データベースをバックアップからリカバリするために Recovery Manager で使用可能なツールについて説明します この章では 次の項目について説明します Recovery Manager を使用したデータベースのリストアおよびリカバリの概要 データベースのリストアおよびリカバリの基本使用例 データベースのリストアおよびリカバリの準備および計画 Recovery Manager の RESTORE: 消失したデータベース ファイルのバックアップからのリストア データベースの完全リストアおよび完全リカバリの実行 6-1

118 Recovery Manager を使用したデータベースのリストアおよびリカバリの概要 Recovery Manager を使用したデータベースのリストアおよびリカバリの概要 この章の内容 この章では データベースが正常に稼働するために必要な 1 つ以上のデータベース ファイルが消失した場合に Recovery Manager および Recovery Manager で作成したバックアップを使用して データベースを正常な稼働状態に戻す方法について説明します Recovery Manager でバックアップし リカバリできるデータベース ファイルには 制御ファイル サーバー パラメータ ファイル データ ファイルおよびアーカイブ REDO ログ ファイルがあります この章の内容は次のとおりです 6-3 ページの データベースのリストアおよびリカバリの基本使用例 では データベースのリストアおよびリカバリの一般的な使用例について包括的に説明します これらの使用例のいずれかが ユーザーの状況と一致する場合は ここで説明する作業を実行することができます 状況がこれらのいずれかとまったく一致しない場合でも 使用例を参考にして独自のリカバリ処理計画を作成できます 6-6 ページの データベースのリストアおよびリカバリの準備および計画 では リストアおよびリカバリ操作を計画する際に使用できる一般的な概要について説明します この説明には リストアおよびリカバリを行う必要があるファイルを決定する方法 リカバリ時に実行する必要がある手順などが含まれます また リストア操作時に Recovery Manager で使用するバックアップを確認する方法 およびリストア操作で使用するバックアップが有効かどうかを検証する方法についても説明します 6-13 ページの Recovery Manager の RESTORE: 消失したデータベース ファイルのバックアップからのリストア では 特定のタイプのファイルをリストアする場合の要件 ( バックアップ制御ファイルからリストアする場合に行う必要がある手順など ) および様々なリカバリ作業 ( 制御ファイル SPFILE 個々のデータ ファイルと REDO ログをリストアする方法など ) について個別に説明します リストアおよびリカバリを行う状況が この章で説明する基本的な使用例のいずれとも一致しない場合でも この章の説明に従って 独自のリカバリ計画で個々の作業を実行することができます データベースのリカバリで使用する Recovery Manager コマンドで重要なものは次の 2 つです RESTORE Recovery Manager リポジトリの内容に基づいて Recovery Manager バックアップからファイルを取得します RECOVER 使用可能なデータ ファイルおよび REDO ログを使用して 完全または Point-in-Time メディア リカバリを実行します 通常 データのリカバリ操作の実行に適するようにデータベースの状態を設定し ディスクおよびメディア マネージャとの通信に必要なチャネルの割当てまたは構成を行った後 一連の RESTORE および RECOVER コマンドを実行します Recovery Manager は すべての必要なファイルをバックアップから取得し リストアしたすべてのデータ ファイルに対してメディア リカバリを実行してデータベースを正常な状態に戻します この章では リストアおよびリカバリの最も一般的な使用例で共通して使用される方法について説明します リストアおよびリカバリを実行する場合は この章で説明されていない複雑な状況の場合でも この章で説明する方法について理解しておく必要があります ただし この章での説明は次の内容に制限されています この章の大部分では リストアおよびリカバリの使用例について説明します これらの例では メディア障害によってデータベース ファイルの一部またはすべてが破損した場合に 破損したファイルをバックアップからリストアし REDO ログに記録されたすべてのデータベースに対する変更をリカバリして データベース全体を正常な稼働状態に戻す方法を示します より高度なリカバリ ( ユーザー エラーからリカバリするための データベース全体または個々の表領域の Point-in-Time リカバリなど ) についても説明しますが これらの方法の詳細は 第 7 章 フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 で説明します 6-2 Oracle Database バックアップおよびリカバリ基礎

119 データベースのリストアおよびリカバリの基本使用例 参照 : データベースの Point-in-Time リカバリ (DataBase Point-In-Time Recovery: DBPITR) および Oracle Flashback Database の詳細は 第 7 章 フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 を参照してください 表領域の Point-in-Time リカバリ (Tablespace Point-In-Time Recovery: TSPITR) の詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください リカバリ カタログが含まれている Recovery Manager の使用方法についても説明していますが それらの使用方法の詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください この章の説明は シングル インスタンス構成で実行されている Oracle データベースに対してのみ適用されます Recovery Manager を使用して Real Application Clusters および Data Guard 構成のデータベースのリストアおよびリカバリを実行することもできますが このマニュアルでは それらの使用例については説明しません バックアップおよびリカバリの基本概念をこの章で確認した後 その基本概念に従って Recovery Manager を使用する方法の詳細は Oracle Database Oracle Clusterware および Oracle Real Application Clusters 管理およびデプロイメント ガイド および Oracle Data Guard 概要および管理 を参照してください Enterprise Manager を使用したリストアおよびリカバリ Enterprise Manager を使用すると Recovery Manager で提供されるデータベースのリストアおよびリカバリ機能の大部分を 一連のリカバリ ウィザードによって実行できます このウィザードによって DBA は データベースの分析 使用可能なバックアップおよびデータ リカバリの目的に基づいて様々なリカバリ作業を実行できます Enterprise Manager を介して Recovery Manager を使用すると この章で説明する より簡単なリストアおよびリカバリの使用例を実行できます また メディア障害およびユーザー エラーの両方を効率的に修復できる より高度なリストアおよびリカバリ方法 (Point-in-Time リカバリ Oracle データベースのフラッシュバック機能の使用など ) を実行できます 基礎となる機能は同じですが コマンドライン クライアントは 多くの一般的な状況でより柔軟に使用でき Recovery Manager のリストアおよびリカバリ機能に対して使用する Enterprise Manager インタフェースは Recovery Manager コマンドライン クライアントを直接使用するより簡単に使用できます Enterprise Manager のリストアおよびリカバリ機能の詳細は Oracle Database 2 日でデータベース管理者 を参照してください データベースのリストアおよびリカバリの基本使用例 6-6 ページの データベースのリストアおよびリカバリの準備および計画 および 6-13 ページの Recovery Manager の RESTORE: 消失したデータベース ファイルのバックアップからのリストア で説明する手順を使用して ほぼすべてのデータ消失のリカバリ方法を計画できます ただし ここで詳細に説明するのは データベースのリストアおよびリカバリの最も一般的な使用例の一部です データベース全体のリストアおよびリカバリ : 使用例 個々の表領域またはデータ ファイルのリストアおよび完全リカバリ : 使用例 ここで説明する手順によって データベース全体または個々の表領域が元の場所にリストアされます データベースの完全リストアおよび完全リカバリの実行 6-3

120 データベースのリストアおよびリカバリの基本使用例 この項のすべての手順を実行するには 次の要件が満たされている必要があります 現行の制御ファイルが破損していない 使用可能なデータ ファイルのバックアップのメディア リカバリに必要なアーカイブ ログおよび増分バックアップの完全なセットが存在する バックアップが存在しないデータ ファイルの場合 そのデータ ファイル作成時のオンライン REDO ログまたはアーカイブ REDO ログの完全なセットが存在する (REDO ログの完全なセットが存在する場合は Recovery Manager で 空のデータ ファイルを作成した後 ファイルがリカバリ処理の一部として作成された後のすべての変更を再適用して バックアップが存在しないデータ ファイルを再作成できる ) 自動チャネルが構成されている場合は Recovery Manager によって 使用可能なデバイス タイプ用に構成されているすべてのチャネルが並列化の設定に応じて割り当てられます 自動チャネルが構成されていない場合は RESTORE および RECOVER コマンドを RUN ブロックで囲み 適切な DISK または sbt チャネルを手動で割り当てて開始する必要があります この手動操作を行わない場合は RESTORE コマンドを実行しても デバイスからバックアップを取得することはできません データベース全体のリストアおよびリカバリ : 使用例 ここでは 現行の制御ファイルおよび SPFILE は存在しているが すべてのデータ ファイルが破損または消失している場合の使用例を示します データベース全体をリストアおよびリカバリする必要があります この例で使用するデータベースには 1 つの読取り専用表領域 history が含まれています この表領域は バックアップからリストアする必要がありますが メディア リカバリは必要ありません 現行の制御ファイルが使用可能な場合にデータベースをリストアおよびリカバリする方法 1. ターゲット データベースに接続してから データベースがマウントされていることを確認します RMAN> STARTUP MOUNT 2. SHOW ALL コマンドを使用して バックアップ デバイスにアクセスするために構成されるチャネルを表示します 自動チャネルが構成されていない場合は 手動で 1 つ以上のチャネルを割り当てます 3. RESTORE DATABASE コマンドを使用してデータベースをリストアし RECOVER DATABASE コマンドを使用してそのデータベースをリカバリします 4. 出力を検証して 正常にリカバリされたかどうかを確認します 正常にリカバリされた場合は データベースをオープンします 次の例では 自動チャネルを使用して データベースのリストアおよびリカバリを実行します RMAN> RESTORE DATABASE; RMAN> RECOVER DATABASE DELETE ARCHIVELOG MAXSIZE 25M; ここで使用している RECOVER DATABASE コマンドには 次の 2 つの有効なオプションがあります DELETE ARCHIVELOG を指定すると Recovery Manager によって リストアしたログ ファイルがデータ ファイルに適用された後に削除され ディスク領域を節約できます MAXSIZE 25M を指定すると 常に リストアしたログに使用される領域が 25MB に制限されます これによって リストアしたログに使用されるディスク領域の量を制御できます 単一のアーカイブ REDO ログが指定した MAXSIZE の値を超えると エラーが発生します MAXSIZE の値を増やして コマンドを再実行する必要があります 6-4 Oracle Database バックアップおよびリカバリ基礎

121 データベースのリストアおよびリカバリの基本使用例 読取り専用表領域を含むデータベースのリカバリ 読取り専用表領域では リストアおよびリカバリ処理で特別な処理が必要となる場合があります デフォルトのリストア処理では 読取り専用表領域はスキップされます 読取り専用表領域が バックアップからリストアされた後に読取り専用となった SCN に存在する場合 データベースの残りがリカバリされる際 この表領域に REDO は適用されません CHECK READONLY オプションを指定して RESTORE コマンドを実行すると 読取り専用表領域に属するデータ ファイルで欠落しているものを Recovery Manager でリストアできます RMAN> RESTORE DATABASE CHECK READONLY; RMAN> RECOVER DATABASE DELETE ARCHIVELOG; Recovery Manager によるリカバリがエラーを戻さずに終了した場合は データベースをオープンできます RMAN> ALTER DATABASE OPEN; データベース全体のリストアおよびリカバリでの一時表領域の再作成 データベース全体のリストアおよびリカバリが実行された後 データベースをオープンすると Recovery Manager リポジトリの制御ファイルのバージョンに記録され 欠落している一時表領域は 以前の作成時のサイズ (AUTOEXTEND および MAXSIZE 属性 ) で再作成されます 注意 : 欠落している一時表領域のみが再作成されます 一時ファイルに無効なヘッダーが含まれていても Recovery Manager リポジトリ内の記録された場所にまだ存在する場合 Recovery Manager はそのファイルを再作成しません 一時ファイルが最初に Oracle 管理ファイルとして作成された場合 現行の DB_CREATE_FILE_ DEST に再作成されます その他の場合は その以前の場所に再作成されます Recovery Manager が I/O エラーまたは他の原因でファイルを再作成できない場合 エラーがアラート ログにレポートされ データベースのオープン操作が続行されます 注意 : リカバリ カタログの使用時に制御ファイルがバックアップからリストアされている場合 リストアされた制御ファイルに格納された Recovery Manager リポジトリは リカバリ カタログ バージョンの Recovery Manager リポジトリに記録された一時表領域の情報で更新されます これによって 最新の構成の一時表領域が再作成されます 個々の表領域またはデータ ファイルのリストアおよび完全リカバリ : 使用例 ここでは データベースがオープンしていて いくつかのデータ ファイル ( すべてではない ) が破損している場合の使用例を示します 破損している表領域のリストアおよびリカバリは 残りのデータベースを使用可能な状態にしておくために データベースをオープンしたまま行います 6-7 ページの リストアまたはリカバリするデータベース ファイルの決定 で説明した手順でリカバリに必要なデータ ファイルを特定するとします 破損しているファイルが表領域 users からのものであることが示されます 次の例では 構成済のチャネルを使用し また 表領域 必要とされる増分バックアップおよびログをディスクまたはテープからリストアする際に使用するバックアップを Recovery Manager で選択して 表領域をリストアおよびリカバリします 1. ターゲット データベースおよびリカバリ カタログ データベース ( 該当する場合 ) に接続し データベースがマウントされているか またはオープン状態であるかを確認します 次に例を示します データベースの完全リストアおよび完全リカバリの実行 6-5

122 データベースのリストアおよびリカバリの準備および計画 2. 影響を受けた表領域がオフラインになっていない場合は ALTER TABLESPACE... OFFLINE IMMEDIATE を実行してオフラインにします RMAN> SQL 'ALTER TABLESPACE users OFFLINE IMMEDIATE'; 3. RESTORE コマンドで表領域またはデータベースをリストアし RECOVER コマンドでリカバリします ( 構成済のチャネルを使用したり 必要に応じて RUN ブロックを使用してチャネルを割り当て RESTORE および RECOVER コマンドのパフォーマンスを向上させます ) RMAN> RESTORE TABLESPACE users; RMAN> RECOVER TABLESPACE users; 4. リカバリ時に Recovery Manager によってエラーがレポートされなかった場合は 表領域をオンラインに戻します RMAN> SQL 'ALTER TABLESPACE users ONLINE'; この時点で このプロセスは完了します データベースのリストアおよびリカバリの準備および計画 Recovery Manager を使用すると データベースのリストアおよびリカバリ作業が簡単になりますが 消失しているデータベース ファイルおよびリカバリの目的に基づいて データベースのリストアおよびリカバリ操作を計画する必要があります Recovery Manager を使用して リストア処理に関する重要な決定の大部分を行うことができますが その決定を確認し 変更する必要がある場合もあります たとえば テープがサイト外に格納されているか またはデバイスがアクセス不可能なため 指定したバックアップが使用できない場合は リストア処理中にそのバックアップを使用しないように指定できます Recovery Manager では リストアで使用するバックアップを確認できるツール およびバックアップの内容を検証してそれらが将来のリストア操作で使用可能であることを確認できるツールが提供されています データベースのリストアおよびリカバリ手順の概要 Recovery Manager を使用したリストアおよびリカバリの基本的な実行手順は次のとおりです 1. バックアップからリストアする必要があるデータベース ファイル およびリストア操作に使用するバックアップ ( 特定のテープ あるいはディスク上のバックアップ セットまたはイメージ コピー ) を決定します リストアするファイルには 制御ファイル SPFILE アーカイブ REDO ログ ファイルおよびデータ ファイルがあります 2. データベースを 実行するリカバリのタイプに適した状態にします たとえば 1 つの表領域またはデータ ファイルをリカバリする場合は データベースをオープンにした状態で表領域またはデータ ファイルをオフラインにします すべてのデータ ファイルをリストアする場合は データベースを停止し マウントしてから リストアを実行する必要があります 3. RESTORE コマンドを使用して 消失したデータベース ファイルをバックアップからリストアします ファイルは 元の場所にリストアできます また ディスクで障害が発生した場合などは他の場所にリストアする必要があります 制御ファイルの場所を変更した場合は SPFILE を データ ファイルまたは REDO ログの場所を変更した場合は制御ファイルを更新する必要もあります 4. RECOVER コマンドを使用して リストアしたデータ ファイルにリカバリを実行します 5. ユーザーがデータベースを使用できるようにするために行う必要がある最後の手順を再度実行します たとえば 消失した制御ファイルをリストアした場合など 必要に応じて データベースを再びオープンしたり 個々の表領域をリストアおよびリカバリした場合に オフラインの表領域をオンラインにしたりします 6-6 Oracle Database バックアップおよびリカバリ基礎

123 データベースのリストアおよびリカバリの準備および計画 ここでは 様々な使用例を広範囲にわたって説明しています 状況によっては 説明した手順の一部が適用されない場合があります ( たとえば バックアップからリストアしたファイルが SPFILE のみの場合は メディア リカバリを実行する必要はありません ) ユーザーは 状況に応じて最終的なリカバリ計画を検討する必要があります リストアまたはリカバリするデータベース ファイルの決定 リストアまたはリカバリする必要があるファイルを決定する方法は 消失したファイルのタイプによって異なります この項では次の項目を取り上げます 消失した制御ファイルの確認 一般的に データベースの制御ファイルをリストアする必要があるタイミングは明確です 制御ファイルのコピーのいずれかにアクセスできなくなると すぐにデータベースが停止します 初期化パラメータ CONTROL_FILES に指定されているそれぞれの場所に有効な制御ファイルがないままデータベースを起動すると エラーが報告されます 制御ファイルの一部またはすべてのコピーが消失しても バックアップから制御ファイルをリカバリする必要はありません 制御ファイルの 1 つのコピーが消失した場合 データベースは自動的に停止します 破損または欠落している制御ファイルに破損していない制御ファイルのコピーを上書きコピーするか あるいは破損または欠落している制御ファイルが参照されないようにパラメータ ファイルを更新できます 破損せずに存在している制御ファイルのコピーのみが CONTROL_FILES パラメータによって参照された後 データベースを再起動できます 制御ファイルをバックアップからリストアした場合は データベース全体のメディア リカバリを実行した後 データ ファイルをリストアする必要がない場合でも OPEN RESETLOGS を実行します メディア リカバリが必要なデータ ファイルの識別方法 リカバリを実行するタイミングと方法は データベースの状態とデータ ファイルの場所によって異なります メディア リカバリが必要なファイル ( 存在する場合 ) を判別するには 次の手順を実行します 1. SQL*Plus を起動してターゲット データベースに接続します たとえば 次のコマンドを発行して trgt に接続します % sqlplus 'SYS/oracle@trgt AS SYSDBA' 2. 次の SQL 問合せを実行して データベースの状態を確認します SELECT STATUS FROM V$INSTANCE; 状態が OPEN の場合 データベースはオープン状態です ただし 一部のデータ ファイルにはメディア リカバリが必要です 3. V$DATAFILE_HEADER ビューを問い合せて データ ファイルの状態を確認します 次の SQL 文を実行して データ ファイルのヘッダーを確認します COL FILE# FORMAT 999 COL STATUS FORMAT A7 COL ERROR FORMAT A10 COL TABLESPACE_NAME FORMAT A10 COL NAME FORMAT A30 SELECT FILE#, STATUS, ERROR, RECOVER, TABLESPACE_NAME, NAME FROM V$DATAFILE_HEADER WHERE RECOVER = 'YES' OR (RECOVER IS NULL AND ERROR IS NOT NULL); 戻される各行には メディア リカバリが必要なデータ ファイルか またはリストアの必要のあるエラーが発生したデータ ファイルが示されます RECOVER および ERROR 列を確認します RECOVER には ファイルにメディア リカバリが必要かどうかが示され ERROR には データ ファイルのヘッダーの読取り時および検証時にエラーが発生したかどうかが示されます データベースの完全リストアおよび完全リカバリの実行 6-7

124 データベースのリストアおよびリカバリの準備および計画 ERROR が NULL でない場合は データ ファイルのヘッダーの読取りおよび検証は実行できません エラーの原因となるハードウェアまたはオペレーティング システムの一時的な問題を確認します 問題がない場合は ファイルをリストアしてコピーに切り替える必要があります ERROR 列が NULL で RECOVER 列が YES の場合 ファイルにはメディア リカバリが必要です ( バックアップからリストアする必要がある場合もあります ) 注意 : V$DATAFILE_HEADER は各データ ファイルのヘッダー ブロックのみを読み取るため データ ファイルのリストアが必要となるすべての問題を検出するわけではありません たとえば V$DATAFILE_HEADER を使用して 破損しているデータ ブロックがデータ ファイルに含まれているかどうかは識別できません また V$RECOVER_FILE を問い合せて リカバリが必要なデータ ファイルをそれらの状態とエラー情報とともにデータ ファイル番号ごとに表示することもできます SELECT FILE#, ERROR, ONLINE_STATUS, CHANGE#, TIME FROM V$RECOVER_FILE; 注意 : バックアップからリストアされた制御ファイル またはデータ ファイルに影響を与えたメディア障害の発生後に再作成された制御ファイルを含む V$RECOVER_FILE は使用できません リストアされた制御ファイルまたは再作成された制御ファイルには V$RECOVER_FILE を正確に更新するために必要な情報が含まれていません データ ファイルおよび表領域の名前を検出するために データ ファイル番号 V$DATAFILE および V$TABLESPACE ビューを使用して 有効な結合を実行することもできます 次に例を示します COL DF# FORMAT 999 COL DF_NAME FORMAT A35 COL TBSP_NAME FORMAT A7 COL STATUS FORMAT A7 COL ERROR FORMAT A10 COL CHANGE# FORMAT SELECT r.file# AS df#, d.name AS df_name, t.name AS tbsp_name, d.status, r.error, r.change#, r.time FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t WHERE t.ts# = d.ts# AND d.file# = r.file# ; ERROR 列で リカバリが必要な各ファイルに関する問題を識別します 参照 : V$ ビューの詳細は Oracle Database リファレンス を参照してください 読取り専用表領域のリカバリ クラッシュ リカバリまたはインスタンス リカバリの際 読取り専用表領域読取り専用表領域ではリカバリを行う必要はありません リカバリでは 起動時に読取り専用の各オンライン データ ファイルにメディア リカバリの必要がないことが検証されます これは ファイルが 読取り専用に設定される前に作成されたバックアップからリストアされていないかどうかをチェックして行われます 6-8 Oracle Database バックアップおよびリカバリ基礎

125 データベースのリストアおよびリカバリの準備および計画 注意 : 読取り専用表領域をリストアする場合 読取り専用にされる前に作成したバックアップを使用すると メディア リカバリを実行しないかぎりその表領域にはアクセスできません DBID の決定 自動バックアップから SPFILE または制御ファイルをリカバリする必要がある場合 ( すべてのデータベース ファイルが消失して障害時リカバリを実行する場合など ) は DBID を使用する必要があります 2-7 ページの ARCHIVELOG および NOARCHIVELOG モードの決定 で説明したように DBID は データベースの基本情報とともに記録する必要があります データベースの DBID のレコードがない場合は 次の 2 つの場面でデータベースをオープンせずに DBID を確認できます DBID は 制御ファイルの自動バックアップ用のファイル名の書式化に使用します 制御ファイルを検索した後 3-12 ページの 制御ファイルの自動バックアップ書式の構成 を参照して ファイル名のどこに DBID が表示されるかを確認します Recovery Manager セッションからの出力を保持するテキスト ファイルが存在する場合 Recovery Manager クライアントを起動し データベースに接続したときに DBID が表示されます 典型的な出力の例を次に示します % rman TARGET / Recovery Manager: Release Production on Sun Jun 12 02:41: Copyright (c) 1982, 2005, Oracle. All rights reserved. connected to target database: RDBMS (DBID= ) RMAN> リストア操作で使用するバックアップの確認 : RESTORE PREVIEW RESTORE コマンドは PREVIEW オプションをサポートします PREVIEW オプションを使用すると Recovery Manager リポジトリの情報に基づいて 特定のリストア操作を実行するのに必要なバックアップ ( ディスク テープなどのシーケンシャル メディア上にある バックアップ セットまたはイメージ コピー ) を特定できます リストアおよびリカバリ操作を計画する場合は RESTORE...PREVIEW を使用して すべての必要なバックアップが使用可能であることを確認し Recovery Manager で特定のバックアップを使用する状況または避ける状況を識別します たとえば RESTORE... PREVIEW の出力には RESTORE 操作時に 一時的に使用できないテープからのバックアップがリストア処理中に Recovery Manager によって要求されることが示されます その後 CHANGE... UNAVAILABLE コマンド (8-13 ページの バックアップ状態のマーク付け を参照 ) を実行して バックアップの状態を UNAVAILABLE に設定できます 次に RESTORE... PREVIEW を再度実行すると 使用不可能なバックアップを使用しないでリストア操作を実行するために Recovery Manager で使用するバックアップが表示されます バックアップが AVAILABLE と表示されても 実際は他の場所に格納されていている場合があります つまり 他の場所に格納されているため リストアに使用するには 取得する必要がある場合があります Recovery Manager がこのようなバックアップをリストア操作で使用するために選択した場合 この操作は失敗し エラーが表示されます RESTORE... PREVIEW を使用すると 他の場所に格納されているバックアップを識別することができ RESTORE...PREVIEW RECALL を使用すると RESTORE 操作で必要ではあるが他の場所に格納されているバックアップを リモートの記憶域から再呼出しするように要求できます データベースの完全リストアおよび完全リカバリの実行 6-9

126 データベースのリストアおよびリカバリの準備および計画 RESTORE... PREVIEW の使用 RESTORE...PREVIEW は すべての RESTORE 処理に適用できます RESTORE を使用すると 要求された RESTORE 処理で使用される各バックアップの詳細なレポート および RESTORE 処理の完了後のリカバリに必要なターゲット SCN を作成できます 次に PREVIEW オプションを使用した RESTORE コマンドの例を示します RESTORE DATABASE PREVIEW; RESTORE TABLESPACE users PREVIEW; RESTORE DATAFILE 3 PREVIEW; RESTORE ARCHIVELOG FROM LOGSEQ 200 PREVIEW; RESTORE ARCHIVELOG FROM TIME 'SYSDATE-7' PREVIEW; RESTORE ARCHIVELOG FROM SCN PREVIEW; RESTORE...PREVIEW の出力方式は LIST コマンドによる出力と同じです RESTORE...PREVIEW の出力の解釈は Oracle Database バックアップおよびリカバリ リファレンス を参照してください RESTORE... PREVIEW SUMMARY の使用 RESTORE... PREVIEW によって生成される詳細なレポートが必要以上の情報を表示する場合は RESTORE... PREVIEW SUMMARY オプションを使用して リストア処理で使用されるファイルおよび影響を受けるファイルに関する多くの詳細を非表示にできます 次に PREVIEW SUMMARY オプションを使用した RESTORE の例を示します RESTORE DATABASE PREVIEW SUMMARY; RESTORE TABLESPACE users PREVIEW SUMMARY; RESTORE DATAFILE 3 PREVIEW SUMMARY; RESTORE ARCHIVELOG FROM SCN PREVIEW SUMMARY; RESTORE... PREVIEW SUMMARY のレポート形式は LIST SUMMARY コマンドによる出力と同じです RESTORE...PREVIEW SUMMARY の出力の解釈は Oracle Database バックアップおよびリカバリ リファレンス を参照してください RESTORE... PREVIEW RECALL の使用 必要なバックアップが他の場所に格納されているために リストアが失敗するような場合 RESTORE... PREVIEW RECALL は いずれの RESTORE 操作でも使用できます RESTORE... PREVIEW によって 必要なバックアップが他の場所に格納されていることが示されている場合の出力を次に示します RMAN> restore archivelog all preview; Starting restore at 10-JUN-05 using channel ORA_DISK_1 using channel ORA_SBT_TAPE_1 List of Backup Sets =================== BS Key Size Device Type Elapsed Time Completion Time M SBT_TAPE 00:00:02 10-JUN-05 BP Key: 33 Status: AVAILABLE Compressed: NO Tag: TAG T Handle: 15gmknbs Media: /v1,15gmknbs List of Archived Logs in backup set 31 Thrd Seq Low SCN Low Time Next SCN Next Time JUN JUN JUN JUN JUN JUN JUN JUN JUN JUN Oracle Database バックアップおよびリカバリ基礎

127 データベースのリストアおよびリカバリの準備および計画 BS Key Size Device Type Elapsed Time Completion Time K SBT_TAPE 00:00:01 10-JUN-05 BP Key: 34 Status: AVAILABLE Compressed: NO Tag: TAG T Handle: 17gmknhp_1_1 Media: /v1,17gmknhp_1_1 List of Archived Logs in backup set 32 Thrd Seq Low SCN Low Time Next SCN Next Time JUN JUN JUN JUN-05 List of remote backup files ============================ Handle: 15gmknbs Media: /v1,15gmknbs この出力の最後の List of remote backup files には 他の場所に格納されているバックアップが示されます このような場合は RESTOREARCHIVELOG ALL PREVIEW RECALL を使用すると リモートのバックアップに対する再呼出しが行われ 次のような出力が生成されます RMAN> restore archivelog all preview recall; Starting restore at 10-JUN-05 using channel ORA_DISK_1 using channel ORA_SBT_TAPE_1 List of Backup Sets =================== BS Key Size Device Type Elapsed Time Completion Time M SBT_TAPE 00:00:02 10-JUN-05 BP Key: 33 Status: AVAILABLE Compressed: NO Tag: TAG T Handle: 15gmknbs Media: /v1,15gmknbs List of Archived Logs in backup set 31 Thrd Seq Low SCN Low Time Next SCN Next Time JUN JUN JUN JUN JUN JUN JUN JUN JUN JUN-05 BS Key Size Device Type Elapsed Time Completion Time K SBT_TAPE 00:00:01 10-JUN-05 BP Key: 34 Status: AVAILABLE Compressed: NO Tag: TAG T Handle: 17gmknhp_1_1 Media: /v1,17gmknhp_1_1 List of Archived Logs in backup set 32 Thrd Seq Low SCN Low Time Next SCN Next Time JUN JUN JUN JUN-05 Initiated recall for the following list of remote backup files ========================================================== Handle: 15gmknbs Media: /v1,15gmknbs Finished restore at 10-JUN-05 データベースの完全リストアおよび完全リカバリの実行 6-11

128 データベースのリストアおよびリカバリの準備および計画 RESTORE... PREVIEW コマンドは リストアに必要なバックアップがリモートとして報告されなくなるまで繰り返すことができます RECALL は いずれの RESTORE... PREVIEW コマンドにも追加できます 次に例を示します RESTORE TABLESPACE users PREVIEW RECALL; RESTORE DATAFILE 3 PREVIEW RECALL; バックアップのリストアの検査 : RESTORE VALIDATE および VALIDATE BACKUPSET RESTORE...VALIDATE および VALIDATE BACKUPSET コマンドを使用すると バックアップからリストアできるかどうかをテストできます 目的の RESTORE 操作に使用可能なバックアップの可用性 または RESTORE 操作に使用する特定のバックアップの内容をテストできます バックアップの内容の実際の読取りと 破損の検証が行われ リストアするオブジェクトがそのバックアップからリストアできることが確認されます 次のオプションがあります RESTORE... VALIDATE は Recovery Manager がバックアップから特定のオブジェクトをリストアできるかをテストします Recovery Manager によって 使用するバックアップが選択されます VALIDATE BACKUPSET は 指定するバックアップ セットの妥当性をテストします 参照 : RESTORE 構文の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください CONFIGURE 構文の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください RESTORE... VALIDATE を使用したバックアップからのリストアの検査 VALIDATE 句を指定して任意の有効な RESTORE コマンドを入力すると その RESTORE 操作に使用可能なバックアップが使用可能かどうかをテストできます データベースをマウントまたはオープンした状態でも RESTORE... VALIDATE を実行してバックアップを検査できます 次の例では バックアップ制御ファイル SYSTEM 表領域およびすべてのアーカイブ ログのリストアを検査します RESTORE CONTROLFILE VALIDATE; RESTORE TABLESPACE SYSTEM VALIDATE; RESTORE ARCHIVELOG ALL VALIDATE; RESTORE DATAFILE 4,5,6 VALIDATE; 注意 : データ ファイルのリストアを検査する場合に データ ファイルをオフラインにする必要はありません これは データ ファイルのバックアップの検査ではバックアップのみが読み取られ 本番データ ファイルは影響を受けないためです エラー メッセージおよび次のメッセージが表示された場合は Recovery Manager を使用して 1 つ以上の指定したファイルを 使用可能なバックアップからリストアすることはできません RMAN-06026: some targets not found - aborting restore 6-12 Oracle Database バックアップおよびリカバリ基礎

129 Recovery Manager の RESTORE: 消失したデータベース ファイルのバックアップからのリストア 次のようなエラー メッセージのスタックおよび出力が表示された場合は 指定したバックアップの読取り中に Recovery Manager で問題が発生しています RMAN-03009: failure of restore command on c1 channel at 12-DEC-01 23:22:30 ORA-19505: failed to identify file "oracle/dbs/1fafv9gl_1_1" ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Additional information: 3 エラー スタックが表示されない場合は 使用可能なバックアップからの指定したオブジェクトのリストアが Recovery Manager で正常に検査され Recovery Manager は 実際のリストアおよびリカバリ操作の実行中にこれらのオブジェクトを正常にリストアできます VALIDATE BACKUPSET を使用したバックアップ セットの検査 BACKUP VALIDATE コマンドには 検査するバックアップ セットの主キーが必要です 検査するバックアップ セットを指定する方法 LIST コマンドを実行し 主キーに注意しながら 確認する必要のあるバックアップ セットを検索します 次に例を示します LIST BACKUP; バックアップ セットを主キーごとに参照して バックアップ セットのリストアを検査します 次の例では バックアップ セット 56 および 57 を検査します VALIDATE BACKUPSET 56,57; 出力に validation complete メッセージが含まれている場合 Recovery Manager は指定したバックアップ セットのリストアを正常に検査しました 次に例を示します using channel ORA_DISK_1 channel ORA_DISK_1: starting validation of archive log backupset channel ORA_DISK_1: restored backup piece 1 piece handle=/oracle/dbs/0mdg9v8l_1_1 tag=tag t params=null channel ORA_DISK_1: validation complete Recovery Manager の RESTORE: 消失したデータベース ファイルのバックアップからのリストア この項では Recovery Manager によってバックアップされた様々なタイプのデータベース ファイルをリストアする方法について説明します データベースの消失した部分をリストアする計画全体を作成した後に その計画の個々の作業を実行する方法については この項を参照してください この項では次の項目を取り上げます バックアップからの制御ファイルのリストア バックアップからのサーバー パラメータ ファイル (SPFILE) のリストア データ ファイルおよび表領域のリストアとリカバリ バックアップからのアーカイブ REDO ログのリストア データベースの完全リストアおよび完全リカバリの実行 6-13

130 Recovery Manager の RESTORE: 消失したデータベース ファイルのバックアップからのリストア バックアップからの制御ファイルのリストア 制御ファイルのすべてのコピーが消失または破損した場合は 制御ファイルをバックアップからリストアする必要があります 制御ファイルをリストアするには RESTORE CONTROLFILE コマンドを使用します 注意 : データベースの制御ファイルをバックアップからリストアした後 データベースの完全メディア リカバリ (6-19 ページの リストア済データベース 表領域またはデータ ファイルのメディア リカバリの実行 を参照 ) を実行し RESETLOGS オプションを指定してデータベースをオープンします ただし 6-15 ページの 新しい場所への制御ファイルのリストア で説明する場合は例外です この場合は CONTROL_FILES 初期化パラメータに定義されていない場所に制御ファイルをリストアします また 実行しているデータベースを変更せずに 指定した場所に制御ファイルのコピーを作成します Recovery Manager では RESTORE CONTROLFILE... TO destination オプションを指定して デフォルトの場所 ( 次の項で説明する規則に従って決定 ) または 1 つ以上の任意の場所に制御ファイルをリストアできます 制御ファイルのデフォルトのリストア先 制御ファイルをリストアする場合 デフォルトのリストア先は CONTROL_FILES 初期化パラメータに定義されているすべての場所です CONTROL_FILES 初期化パラメータを設定しないと データベースは CONTROL_FILES パラメータが設定されていない場合に制御ファイルを作成するときと同じ規則を使用して リストアされた制御ファイルの格納先を決定します これらの規則については Oracle Database SQL リファレンス の CREATE CONTROLFILE 文の説明を参照してください 制御ファイルの自動バックアップからの制御ファイルのリストア リカバリ カタログを使用していない場合 制御ファイルは 自動バックアップからリストアする必要があります 制御ファイルを自動バックアップからリストアする場合は データベースを NOMOUNT 状態にする必要があります データベースの DBID を設定した後で RESTORE CONTROLFILE FROM AUTOBACKUP コマンドを実行します RMAN> SET DBID ; RMAN> RUN { SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'autobackup_format'; RESTORE CONTROLFILE FROM AUTOBACKUP; } Recovery Manager では 制御ファイルの自動バックアップを検出するために自動バックアップ書式および DBID が使用されます 自動バックアップが検出されると Recovery Manager によって 制御ファイルがそのバックアップから CONTROL_FILES 初期化パラメータに記録されているすべての制御ファイルの場所にリストアされます autobackup_format の適切な値を判断する方法については Oracle Database バックアップおよびリカバリ リファレンス の CONFIGURE 用のエントリ内の CONFIGURE CONTROLFILE AUTOBACKUP FORMAT についての説明を参照してください DBID を決定する方法については 6-9 ページの DBID の決定 を参照してください 6-14 Oracle Database バックアップおよびリカバリ基礎

131 Recovery Manager の RESTORE: 消失したデータベース ファイルのバックアップからのリストア フラッシュ リカバリ領域を使用した場合の制御ファイルのリストア 制御ファイルのリストアに使用するコマンドは フラッシュ リカバリ領域を使用しているかどうかに関係なく同じです ただし フラッシュ リカバリ領域を使用している場合は Recovery Manager によって バックアップからリストアされた制御ファイルが更新されます これは 制御ファイルに記録されているすべてのディスクベースのバックアップおよびイメージ コピーが暗黙的にクロスチェックされ リストアされた制御ファイルに記録されていないフラッシュ リカバリ領域内のすべてのバックアップがカタログに追加されることで行われます その結果 リストアされた制御ファイルには フラッシュ リカバリ領域内のすべてのバックアップの完全かつ正確なレコードと バックアップ時に制御ファイルに認知されていた他のバックアップが含まれます これによって リストアされた制御ファイルを有効に使用して データベースの残りをリストアできます テープ バックアップは 制御ファイルをリストアした後 自動的にクロスチェックされません テープ バックアップを使用している場合は 制御ファイルをリストアしてデータベースをマウントした後 テープ上でバックアップのクロスチェックを行う必要があります 次に例を示します RMAN> CROSSCHECK BACKUP DEVICE TYPE SBT; リカバリ カタログを使用した場合の制御ファイルのリストア 消失した制御ファイルを自動バックアップからリストアする場合は Recovery Manager リポジトリを格納するために制御ファイルのみを使用するよりも リカバリ カタログを使用した方が簡単になります リカバリ カタログには 制御ファイルのバックアップなど バックアップの完全なレコードが含まれています したがって DBID や制御ファイルの自動バックアップ書式を指定する必要はありません 制御ファイルをリストアするには Recovery Manager をターゲット データベースとリカバリ カタログに接続して データベースを NOMOUNT 状態にします その後で パラメータを指定しないで RESTORE CONTROLFILE コマンドを発行します 次に例を示します % rman TARGET rman/rman CATALOG catdb/catdb RMAN> RESTORE CONTROLFILE; リストアされた制御ファイルは CONTROL_FILES 初期化パラメータに定義されているすべての場所に書き込まれます 様々な状況での RESTORE CONTROLFILE の使用制限の詳細は Oracle Database バックアップおよびリカバリ リファレンス の RESTORE CONTROLFILE の説明を参照してください 既知の場所からの制御ファイルのリストア 次の書式のコマンドを使用して 制御ファイルの既知のコピーから制御ファイルをリストアできます RMAN> RESTORE CONTROLFILE from 'filename'; filename に指定された場所で検出された制御ファイルのコピーは CONTROL_FILES 初期化パラメータに定義されているすべての場所に書き込まれます 新しい場所への制御ファイルのリストア 1 つ以上の新しい場所に制御ファイルをリストアするには CONTROL_FILES 初期化パラメータを変更した後 引数を指定せずに RESTORE CONTROLFILE を実行して制御ファイルをデフォルトの場所にリストアする方法があります たとえば CONTROL_FILES に定義されている場所の一部がディスク障害によって使用できなくなった後に制御ファイルをリストアする場合は CONTROL_FILES で障害ディスクへの参照を別のディスクへのパス名に置き換えた後 引数を指定せずに RESTORE CONTROLFILE を実行します データベースの完全リストアおよび完全リカバリの実行 6-15

132 Recovery Manager の RESTORE: 消失したデータベース ファイルのバックアップからのリストア RESTORE CONTROLFILE TO 'filename' [FROM AUTOBACKUP] という書式を使用して CONTROL_FILES に定義されている以外の任意の場所に制御ファイルをリストアすることもできます RESTORE CONTROLFILE TO '/tmp/my_controlfile'; この操作は 現在使用中の制御ファイルを上書きしないため NOMOUNT MOUNT または OPEN 状態のデータベースで実行できます 'filename' という名前のすべての既存ファイルが上書きされます 制御ファイルを新しい場所にリストアした後 CONTROL_FILES 初期化パラメータを更新して新しい場所を追加定義できます 参照 : RESTORE CONTROLFILE 構文については Oracle Database バックアップおよびリカバリ リファレンス を参照してください バックアップ制御ファイルを使用した場合の制限 バックアップ制御ファイルを使用してデータベースをリストアした後 データベースに対して RECOVER DATABASE および OPEN RESETLOGS を実行する必要があります 様々な状況 ( リカバリ カタログを使用する場合 特定のバックアップからリストアする場合など ) で RESTORE CONTROLFILE を使用する場合の制限の詳細は Oracle Database バックアップおよびリカバリ リファレンス の RESTORE CONTROLFILE の説明を参照してください バックアップからのサーバー パラメータ ファイル (SPFILE) のリストア サーバー パラメータ ファイル (SPFILE) が消失した場合は Recovery Manager を使用してデフォルトの場所または任意の場所にリストアできます 制御ファイルが消失した場合とは異なり SPFILE が消失してもインスタンスはすぐに停止はしません SPFILE をリストアした後にインスタンスを停止して再起動する必要がありますが インスタンスは継続して稼働します SPFILE をリストアする際は 次の事項に注意してください インスタンスがサーバー パラメータ ファイルを使用して起動されている場合 既存のサーバー パラメータ ファイルは上書きできません インスタンスがクライアント側の初期化パラメータ ファイルを使用して起動されている場合 TO 句が使用されていなければ Recovery Manager は SPFILE をデフォルトの場所にリストアします デフォルトの場所はプラットフォーム固有です (Linux の場合は?/dbs/spfile.ora) SPFILE のリストアは リカバリ カタログを使用してリカバリ処理を簡略化できる手段の 1 つです これは DBID を記録しておく必要がないためですが 次の手順では リカバリ カタログを使用していないことを想定しています Recovery Manager では SPFILE のバックアップに基づいてクライアント側の初期化パラメータ ファイルも作成できます サーバー パラメータ ファイル (SPFILE) ( をリストアする方法 1. SPFILE が消失したときにデータベースが起動されている場合は ターゲット データベースに接続します たとえば 次のコマンドを実行します % rman TARGET / SPFILE が消失したときにデータベースが起動されておらず リカバリ カタログが使用されていない場合は ターゲット データベースの DBID を設定する必要があります DBID を決定する方法については 6-9 ページの DBID の決定 を参照してください 2. インスタンスを停止して マウントせずに再起動します SPFILE を使用できない場合 Recovery Manager は仮のパラメータ ファイルを使用してインスタンスを起動します 次に例を示します RMAN> STARTUP FORCE NOMOUNT; 6-16 Oracle Database バックアップおよびリカバリ基礎

133 Recovery Manager の RESTORE: 消失したデータベース ファイルのバックアップからのリストア 3. サーバー パラメータ ファイル (SPFILE) をリストアします デフォルトの場所にリストアする場合は 次のコマンドを実行します RMAN> RESTORE SPFILE FROM AUTOBACKUP; デフォルト以外の場所にリストアする場合は 次の例のようなコマンドを実行します RMAN> RESTORE SPFILE TO '/tmp/spfiletemp.ora' FROM AUTOBACKUP; 4. リストアしたファイルを使用してインスタンスを再起動します デフォルト以外の場所にあるサーバー パラメータ ファイルを使用して再起動する場合は 単一行の SPFILE=new_location を使用して 新しいクライアント側の初期化パラメータ ファイルを作成します new_location には リストアしたサーバー パラメータ ファイルのパス名を指定します 次に クライアント側の初期化パラメータ ファイルを使用してインスタンスを再起動します たとえば 単一行を含む /tmp/init.ora ファイルを作成します SPFILE=/tmp/spfileTEMP.ora 次に 次の Recovery Manager コマンドを使用して 格納された SPFILE に基づいてインスタンスを再起動します RMAN> STARTUP FORCE PFILE=/tmp/init.ora; # startup with /tmp/spfiletemp.ora 制御ファイルの自動バックアップからの SPFILE のリストア 制御ファイルの自動バックアップが構成済の場合 SPFILE は 自動バックアップが行われるたびに制御ファイルを使用してバックアップされます 自動バックアップから SPFILE をリストアする場合は データベースの DBID を設定した後で RESTORE SPFILE FROM AUTOBACKUP コマンドを実行します この手順は 自動バックアップから制御ファイルをリストアする場合と同様です データベースの DBID を設定した後で RESTORE CONTROLFILE FROM AUTOBACKUP コマンドを実行します RMAN> SET DBID ; RMAN> RUN { SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'autobackup_format'; RESTORE SPFILE FROM AUTOBACKUP; } Recovery Manager では 自動バックアップ書式および DBID を使用して制御ファイルの自動バックアップを検索し 制御ファイルの自動バックアップが検出されると そのバックアップからデフォルトの場所に SPFILE をリストアします autobackup_format の適切な値を判断する方法については Oracle Database バックアップおよびリカバリ リファレンス の CONFIGURE 用のエントリ内の CONFIGURE CONTROLFILE AUTOBACKUP FORMAT についての説明を参照してください DBID を決定する方法については 6-9 ページの DBID の決定 を参照してください Recovery Manager によるクライアント側初期化パラメータ ファイル (PFILE) の作成 サーバー パラメータ ファイルは TO PFILE 'filename' 句を使用してクライアント側の初期化パラメータ ファイルとしてリストアすることもできます 指定するファイル名は Recovery Manager クライアントが実行されているホストからアクセス可能なファイル システム上に存在している必要があります このファイルは インスタンスを実行しているホストから直接アクセス可能である必要はありません このコマンドを実行すると Recovery Manager クライアントを実行しているシステム上に /tmp/inittemp.ora という PFILE が作成されます RMAN> RESTORE SPFILE TO PFILE '/tmp/inittemp.ora'; データベースの完全リストアおよび完全リカバリの実行 6-17

134 Recovery Manager の RESTORE: 消失したデータベース ファイルのバックアップからのリストア クライアント側の PFILE を使用してインスタンスを再起動するには 次のコマンドを実行して同じクライアント マシン上で再度 Recovery Manager を実行します RMAN> STARTUP FORCE PFILE='/tmp/initTEMP.ora'; データ ファイルおよび表領域のリストアとリカバリ 元の場所への表領域のリストアと その場所でのメディア リカバリの実行については 6-5 ページの 個々の表領域またはデータ ファイルのリストアおよび完全リカバリ : 使用例 を参照してください ただし データ ファイルの元の場所を含むディスクで障害が発生した場合などは 元の場所以外にデータ ファイルをリストアする必要があります バックアップから新しい場所へのデータ ファイルのリストア バックアップから新しい場所にデータ ファイルをリストアする場合 制御ファイルにデータ ファイルの新しい場所を反映することが重要です 次の例では Recovery Manager の SET NEWNAME コマンドを使用して新しい名前を指定し SWITCH コマンドを使用して制御ファイルを更新し それらの新しい名前でデータベースの参照を開始します バックアップから元の場所にデータ ファイルをリストアする場合と同様に バックアップから新しい場所にデータ ファイルをリストアする場合もリストア開始時に影響を受けた表領域をオフラインにする必要があります その後 RUN ブロックを作成して RESTORE および RECOVER コマンドを囲みます 新しい場所に移動する各ファイルに対して SET NEWNAME コマンドを使用してそのファイルの新しい場所を指定します 次に RUN ブロック内で 通常どおり RESTORE TABLESPACE または RESTORE DATAFILE を実行します Recovery Manager を使用して 元の場所ではなく SET NEWNAME で指定した場所に各データ ファイルをリストアします RUN ブロックの RESTORE コマンドと RECOVER コマンドの間で SWITCH コマンドを使用して データ ファイルの新しいファイル名で制御ファイルを更新します SWITCH コマンドは SQL 文 ALTER DATABASE RENAME FILE と同じ処理を実行します SWITCH DATAFILE ALL を実行すると 制御ファイルに RUN ブロックで SET NEWNAME が発行されているすべてのデータ ファイルの新しい名前が反映されます 次の例では 表領域 users および tools にあるデータ ファイルを新しい場所にリストアして リカバリを実行します 古いデータ ファイルはディレクトリ /olddisk に格納され 新しいデータ ファイルは /newdisk に格納されているとします RUN { SQL 'ALTER TABLESPACE users OFFLINE IMMEDIATE'; SQL 'ALTER TABLESPACE tools OFFLINE IMMEDIATE'; # specify the new location for each datafile SET NEWNAME FOR DATAFILE '/olddisk/users01.dbf' TO '/newdisk/users01.dbf'; SET NEWNAME FOR DATAFILE '/olddisk/tools01.dbf' TO '/newdisk/tools01.dbf'; # to restore to an ASM disk group named dgroup, use: # SET NEWNAME FOR DATAFILE '/olddisk/trgt/tools01.dbf' # TO '+dgroup'; RESTORE TABLESPACE users, tools; SWITCH DATAFILE ALL; # update control file with new filenames RECOVER TABLESPACE users, tools; } 正常にリカバリされたら 表領域をオンラインにします SQL 'ALTER TABLESPACE users ONLINE'; SQL 'ALTER TABLESPACE tools ONLINE'; 参照 : SWITCH 構文の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください 6-18 Oracle Database バックアップおよびリカバリ基礎

135 Recovery Manager の RESTORE: 消失したデータベース ファイルのバックアップからのリストア リストア済データベース 表領域またはデータ ファイルのメディア リカバリの実行 メディア リカバリは アーカイブ REDO ログ オンライン REDO ログ およびバックアップからリストアされたデータ ファイルからのすべての変更に再適用されます メディア リカバリを簡単な方法で実行するには 引数を指定せずに RECOVER DATABASE コマンドを使用します RMAN> RECOVER DATABASE; 次の例に示すとおり 個々の表領域またはデータ ファイルのメディア リカバリを実行したり データベースの残りのリカバリ中に特定の表領域をスキップすることもできます RMAN> RECOVER DATABASE SKIP TABLESPACE users; RMAN> RECOVER TABLESPACE users, tools; RMAN> RECOVER DATAFILE '/newdisk/users01.dbf','/newdisk/tools01.dbf'; RMAN> RECOVER DATAFILE 4; Recovery Manager では リカバリ処理中に必要なアーカイブ REDO ログがバックアップからリストアされます バックアップがメディア マネージャに格納されている場合は 前もってチャネルを構成する必要があること ALLOCATE CHANNEL コマンドで RUN ブロックを使用して そこに格納されているバックアップへのアクセスを有効にする必要があることに注意してください リストアされたこれらのファイルに関連付けられたディスク領域を管理する場合に有効なオプションの 1 つとして DELETE ARCHIVELOG オプションがあります リストアしたアーカイブ REDO ログは RECOVER 処理で不要になると このオプションによってディスクから削除されます RMAN> RECOVER TABLESPACE users, tools DELETE ARCHIVELOG; Recovery Manager を使用して RECOVER 処理を実行するためにフラッシュ リカバリ領域にアーカイブ REDO ログ ファイルをリストアすると DELETE ARCHIVELOG オプションを使用しない場合でも リストアしたログは データ ファイルに適用された後自動的に削除されます RECOVER コマンドのオプションの詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください 新しい場所への単一のデータ ファイルのリストアおよびリカバリ : 例 この手順では 単一のデータ ファイルを新しい場所にリストアして その場所でメディア リカバリを実行します この手順を使用すると メディア障害などの問題のために 以前の場所にアクセスできない場合でも リストアおよびリカバリを実行できます RUN { SET NEWNAME FOR DATAFILE 3 to 'new_location'; RESTORE DATAFILE 3; SWITCH DATAFILE 3; RECOVER DATAFILE 3; } データ ファイルを新しい Oracle Managed Files の場所に格納する場合は 次のような書式のコマンドを使用できます RUN { SET NEWNAME FOR DATAFILE 3 to NEW; RESTORE DATAFILE 3; SWITCH DATAFILE 3; RECOVER DATAFILE 3; } データベースの完全リストアおよび完全リカバリの実行 6-19

136 Recovery Manager の RESTORE: 消失したデータベース ファイルのバックアップからのリストア リストアしたファイルは Oracle によって OMF の場所に格納され ファイル名が付けられます バックアップからのアーカイブ REDO ログのリストア アーカイブ REDO ログ ファイルは リカバリを実行する必要がある場合に Recovery Manager によってバックアップから自動的にリストアされます ただし RECOVER コマンド実行時にアーカイブ REDO ログ ファイルのリストアにかかる時間を短縮する必要がある場合 またはアーカイブ REDO ログ ファイルを新しい場所に格納する場合 これらのアーカイブ REDO ログ ファイルは手動でリストアすることもできます デフォルトでは Recovery Manager は ターゲット データベースの LOG_ARCHIVE_FORMAT および LOG_ARCHIVE_DEST_1 パラメータを使用して構成された名前でアーカイブ REDO ログをリストアします これらのパラメータはプラットフォーム固有の方式で組み合され リストアしたアーカイブ ログの名前を構成します 新しい場所へのアーカイブ REDO ログのリストア SET ARCHIVELOG DESTINATION コマンドを使用すると リストアしたアーカイブ REDO ログのデフォルトの名前を上書きできます このコマンドは データベースのリストア中 様々な場所に手動でアーカイブ ログをリストアします リカバリ中 Recovery Manager は新しくリストアされたアーカイブ ログの検出場所を認識します このため アーカイブ ログは 初期化パラメータ ファイルで指定されている場所にある必要はありません アーカイブ REDO ログを新しい場所へリストアする方法 1. ターゲット データベースに接続してから データベースがマウントまたはオープンされていることを確認します 2. 次のサンプル スクリプトに示すとおり RUN ブロック内で次の操作を実行します a. SET ARCHIVELOG DESTINATION を使用して リストアするアーカイブ REDO ログの新しい場所を指定します b. アーカイブ REDO ログをリストアします 次の例では すべてのバックアップ アーカイブ ログを新しい場所へリストアします RUN { SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore'; RESTORE ARCHIVELOG ALL; # restore and recover datafiles as needed... } 複数の場所へのアーカイブ REDO ログのリストア アーカイブ ログのリストア先を 1 つの RUN ブロックに複数回指定して リストアしたログを複数のリストア先に分散できます ( ただし 同時に複数のリストア先を指定して リストア操作時に同じログの複数のコピーを生成することはできません ) この機能を使用して リストアしたログを格納するために使用するディスク領域を管理できます 次の例では バックアップから 300 のアーカイブ REDO ログをリストアし ディレクトリ /fs1/tmp /fs2/tmp および /fs3/tmp に分散します RUN { # Set a new location for logs 1 through 100. SET ARCHIVELOG DESTINATION TO '/fs1/tmp'; RESTORE ARCHIVELOG FROM SEQUENCE 1 UNTIL SEQUENCE 100; # Set a new location for logs 101 through 200. SET ARCHIVELOG DESTINATION TO '/fs2/tmp'; 6-20 Oracle Database バックアップおよびリカバリ基礎

137 Recovery Manager の RESTORE: 消失したデータベース ファイルのバックアップからのリストア RESTORE ARCHIVELOG FROM SEQUENCE 101 UNTIL SEQUENCE 200; # Set a new location for logs 201 through 300. SET ARCHIVELOG DESTINATION TO '/fs3/tmp'; RESTORE ARCHIVELOG FROM SEQUENCE 201 UNTIL SEQUENCE 300; # restore and recover datafiles as needed... } RECOVER コマンドを発行すると リストアした必要なアーカイブ ログがリストア先で自動的に検出され データ ファイルに適用されます データベースの完全リストアおよび完全リカバリの実行 6-21

138 Recovery Manager の RESTORE: 消失したデータベース ファイルのバックアップからのリストア 6-22 Oracle Database バックアップおよびリカバリ基礎

139 7 フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 誤ったデータベースの更新による影響が発生した後に データベース内のオブジェクトやデータベース全体を以前の状態に戻す必要がある場合があります たとえば ユーザーまたは DBA が 1 つ以上の表の内容を誤って削除または更新したり 必要なデータベース オブジェクトを削除したり またはアプリケーションの更新や大規模なバッチ更新などの危険を伴う操作が失敗する場合があります データベース全体の Point-in-Time リストアおよびリカバリに加えて Oracle では Oracle Flashback Technology と呼ばれる機能グループが提供されます これらの機能は Point-in-Time リカバリより高速である場合があり また データベースの可用性を損なう可能性が低くなります この章では 不要なデータベースの変更を調査し Oracle Flashback Technology とデータベースのバックアップに基づいて適切なリカバリ計画を選択および実施するためのガイドラインを示します この章では 次の項目について説明します Point-in-Time リカバリとフラッシュバックの機能 Oracle Flashback Query: 行レベルでのリカバリ Oracle Flashback Table: 個々の表の過去の状態へのリカバリ Oracle Flashback Drop: DROP TABLE 操作の取消し Oracle Flashback Database を使用したデータベースの変更の取消し データベースの Point-In-Time リカバリの実行 フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 7-1

140 Point-in-Time リカバリとフラッシュバックの機能 Point-in-Time リカバリとフラッシュバックの機能 不要なデータベースの変更に対する最も一般的な解決策は データベースの Point-in-Time リカバリです これは バックアップからデータベースをリストアした後で REDO ログを適用し 不要な変更を行う前の時点までのすべての変更を再作成するものです Oracle Flashback Technology では データベースをバックアップからリストアしなくても データの過去の状態を表示したり データを過去の任意の時点に戻すことができる一連の機能の様々な代替機能が提供されます データベースの変更内容によっては Oracle Flashback Technology を使用した方が 不要な変更をより短時間で元に戻したり データベースの残りの部分の可用性に与える影響をより少なくできる場合があります データベースの Point-in-Time リカバリ データベースの Point-in-Time リカバリ (DBPITR) は 物理レベルで動作して データ ファイルを過去の目標時点の状態に戻す処理です Recovery Manager の DBPITR 操作では ユーザーが目標時点を指定すると Recovery Manager は その時点より前のバックアップからデータベースをリストアし その後で増分バックアップの適用とメディア リカバリを実行して データ ファイルのバックアップの時刻と目標時点の間に行われたすべての変更を再作成します バックアップ計画が適切に設計されていて データベースが ARCHIVELOG モードで実行されている場合 ほとんどすべての環境で DBPITR が選択肢の 1 つになります Recovery Manager を使用すると DBPITR はユーザー管理の DBPITR に比べて大幅に簡単になります ターゲット SCN を指定すると ユーザーが介入することなく データ ファイルがバックアップからリストアされ ディスクまたはテープで使用可能な増分バックアップとアーカイブ REDO ログを使用して効率的にリカバリされます ただし Point-in-Time リカバリにはいくつかのデメリットがあります 選択したオブジェクトのみを以前の状態に戻すことはできません データベース全体を戻す必要があります データベースの Point-in-Time リカバリ プロセスの実行中はデータベース全体が使用できなくなります Point-in-Time リカバリでは すべてのデータ ファイルをリストアし REDO ログと増分バックアップをバックアップからリストアしてデータ ファイルのリカバリで使用する必要があるため リカバリに時間がかかる可能性があります 必要なバックアップがテープに格納されている場合 このプロセスはさらに時間がかかる可能性があります 注意 : 不要なデータベースの変更が大量にあっても データベースの特定の表領域に限定される場合 表領域の表領域の Point-in-Time リカバリ (TSPITR) を使用すると データベースで影響のない表領域は使用可能なまま 表領域のサブセットを以前の SCN に戻すことができます TSPITR は高度な手法です 詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください Oracle Flashback Technology: Point-in-Time リカバリの代替方法 Oracle のフラッシュバック機能が使用可能なほとんどの環境では これらの機能はメディア リカバリよりも効率的です また これらの機能は過去の状態の調査にも使用できます Oracle Flashback Technology のほとんどの機能は論理レベルで動作して データベース オブジェクトの表示および操作を行います 次に例を示します Oracle Flashback Query を使用すると 目標時点を指定してデータベースに対する問合せを実行し その時点での状態を示す結果を表示できます 表に対する誤った更新などの不要な変更からリカバリするには その変更が発生する前の目標時点を選択し 問合せを実行して消失した行の内容を取得します Oracle Flashback Version Query を使用すると 指定した期間に 1 度でも表に存在したすべての行のすべてのバージョンを表示できます また 異なるバージョンの行のメタデータ ( そのバージョンを作成したトランザクションの開始時刻 終了時刻 操作 トランザク 7-2 Oracle Database バックアップおよびリカバリ基礎

141 Point-in-Time リカバリとフラッシュバックの機能 ション ID など ) を取得できます この機能は 消失したデータの値のリカバリおよび問い合せた表への変更の監査の両方に使用できます Oracle Flashback Transaction Query を使用すると 1 つのトランザクションまたは一定期間内のすべてのトランザクションによる変更を表示できます Oracle Flashback Table を使用すると 表を過去の時点の状態に戻すことができます データベースがオンラインである間に表データをリストアし 指定した表に対する変更のみを取り消すことができます Oracle Flashback Drop を使用すると DROP TABLE 文の影響を無効にできます Oracle Flashback Table Oracle Flashback Query Oracle Flashback Transaction Query および Oracle Flashback Version Query は いずれも UNDO データ (Oracle データベースに対する各更新の影響および更新時に上書きされた値の記録 ) に依存します これらの UNDO レコードは 主に SQL 問合せに対する読取り一貫性の提供やトランザクションのロールバックなどのために使用され 過去の状態のデータを再構築したり 過去の時点からの変更の記録を確認するために必要な情報を含みます Oracle Flashback Drop は ごみ箱ごみ箱というメカニズムを使用して構築されます Oracle は ごみ箱を使用して 削除されたデータベース オブジェクトによって使用されていた領域に新しいデータを格納することが必要になるまで これらのデータベース オブジェクトを管理します Oracle Flashback Database を使用すると データベースの Point-in-Time リカバリより効率的で直接的なリカバリを実行できます この機能は 物理レベルで動作する点で他のフラッシュバック機能と異なります Oracle Flashback Database を使用すると 現行のデータ ファイルが過去の時点の内容に戻ります 結果はデータベースの Point-in-Time リカバリの結果とほぼ同じになりますが バックアップからデータ ファイルをリストアする必要がなく メディア リカバリと比較して 適用が必要な REDO の数が限られているため より短時間でリカバリが行われます Oracle Flashback Database では フラッシュバック ログフラッシュバック ログを使用して データ ブロックの過去のバージョン およびアーカイブ REDO ログに含まれる情報の一部にアクセスします データベースの修復に Oracle Flashback Database を使用するには フラッシュバック ログを生成するようにデータベースを構成するか または保証付きリストア ポイントの関連機能を使用して 特定の時点 ( 危険を伴うデータベースの変更の直前など ) でのデータベースの内容を保護する必要があります 参照 : UNDO データおよび自動 UNDO 管理の詳細は Oracle Database 概要 および Oracle Database 管理者ガイド を参照してください Oracle Flashback Query Oracle Flashback Transaction Query および Oracle Flashback Version Query の詳細は Oracle Database アプリケーション管理者ガイド - 基礎編 を参照してください Oracle Flashback Database を使用するたのデータベースの設定および関連するリストア ポイント機能の詳細は リストア ポイントおよび Oracle Flashback Database を使用したデータ保護 を参照してください フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 7-3

142 Oracle Flashback Query: 行レベルでのリカバリ Oracle Flashback Query: 行レベルでのリカバリ データをリカバリする場合 過去の時点での表の状態を問合せできると有効です たとえば 午後 12 時 30 分に従業員 JOHN が EMP 表から削除されたことが判明し 午前 9 時 30 分には JOHN のデータがデータベースに正しく格納されていたことがわかっている場合は 削除前の時点の表の内容を問い合せてどのデータが消失したかを確認し 必要に応じて その消失したデータをデータベースに再挿入できます 表の過去の状態を問い合せるには SELECT 文の AS OF 句を使用します たとえば 2005 年 4 月 4 日午前 9 時 30 分の JOHN の従業員レコードの状態を取得するには 次の問合せを実行します SELECT * FROM EMP AS OF TIMESTAMP TO_TIMESTAMP(' :30:00', 'YYYY-MM-DD HH:MI:SS') WHERE name = 'JOHN'; JOHN の情報を EMP 表にリストアするには 次の更新が必要です INSERT INTO EMP (SELECT * FROM EMP AS OF TIMESTAMP TO_TIMESTAMP(' :30:00', 'YYYY-MM-DD HH:MI:SS') WHERE name = 'JOHN'); 欠落した行が過去の内容で再作成され 実行されているデータベースへの影響が最小限に抑えられます 参照 : SQL 文 SELECT... AS OF の使用方法および使用例の詳細は Oracle Database アプリケーション管理者ガイド - 基礎編 を参照してください SELECT... AS OF 形式の SELECT 文の構文の詳細は Oracle Database SQL リファレンス を参照してください Oracle Flashback Table: 個々の表の過去の状態へのリカバリ Oracle Flashback Table を使用すると DBA は データベースをオフラインにせずに 1 つまたは複数の表を 指定した過去の時点まで迅速かつ簡単にリカバリできます 多くの場合 Oracle Flashback Table を使用すると 複雑な Point-in-Time リカバリ操作を実行する必要がなくなります Oracle Flashback Table によって 現行の索引 トリガー 制約などの関連する属性が自動的に保持され 表がリストアされます DBA がアプリケーション固有のプロパティを検索およびリストアする必要はありません Oracle Flashback Table を使用すると 個々の表の内容が 任意の過去の SCN または時刻の状態に戻ります Oracle Flashback Table では UNDO 表領域の情報を使用して表がリストアされます バックアップからデータをリストアする必要はありません また Oracle Flashback Table 操作の実行中 データベースの残りの部分は使用可能のままになります 自動 UNDO 管理の詳細は Oracle Database 管理者ガイド を参照してください 1 つ以上の表で Oracle Flashback Table 機能を使用するには 目標時点または SCN で FLASHBACK TABLE SQL 文を使用します Oracle Flashback Table を使用する場合の前提条件 表に対して Oracle Flashback Table 機能を使用する場合の前提条件は次のとおりです 表で行の移動が有効である必要があります 行の移動を有効にするには 次の SQL 文を使用します ALTER TABLE table ENABLE ROW MOVEMENT; 7-4 Oracle Database バックアップおよびリカバリ基礎

143 Oracle Flashback Table: 個々の表の過去の状態へのリカバリ FLASHBACK ANY TABLE システム権限または表に対する FLASHBACK オブジェクト権限を持っている必要があります 表に対する SELECT INSERT DELETE および ALTER 権限を持っている必要があります 指定した目標時点または SCN までの FLASHBACK TABLE 操作に必要な過去の時点までの UNDO 情報が UNDO 表領域に保持されている必要があります 注意 : FLASHBACK TABLE... TO BEFORE DROP 文は Oracle Flashback Table ではなく Oracle Flashback Drop の機能を使用するので これらの前提条件に従いません 詳細は Oracle Flashback Drop: DROP TABLE 操作の取消し を参照してください Oracle Flashback Table の実行 次の SQL*Plus 文を使用すると EMP 表に対する FLASHBACK TABLE 操作を実行できます EMP 表が SCN で指定した時点の状態にリストアされます FLASHBACK TABLE EMP TO SCN ; また TO_TIMESTAMP を使用して FLASHBACK TABLE 操作の目標時点を指定することもできます 次に例を示します FLASHBACK TABLE EMP TO TIMESTAMP TO_TIMESTAMP(' :30:00', 'YYYY-MM-DD HH:MI:SS') 注意 : SCN へのタイムスタンプのマッピングは 必ずしも正確ではありません FLASHBACK TABLE 文でタイムスタンプを使用する場合 表がフラッシュバックされる実際の時間は TO_TIMESTAMP で指定した時間と比較すると 最大で約 3 秒異なる可能性があります 正確な時間が必要な場合は 時刻書式ではなく SCN を使用します デフォルトでは データベースは FLASHBACK TABLE 操作を実行する前に 影響を受ける表のトリガーを無効にし その操作の後で トリガーを操作前の状態 ( 有効または無効 ) に戻します 表のトリガーを FLASHBACK TABLE 操作中に適用させる場合は ENABLE TRIGGERS 句を FLASHBACK TABLE 文に追加します FLASHBACK TABLE table_name TO TIMESTAMP timestamp ENABLE TRIGGERS; 次の例は Oracle Flashback Table を使用できる論理的な破損の典型的な例です 午後 5 時に人事管理者によって 従業員 JOHN が EMP 表から欠落していることが判明しました この従業員は レポートが最後に実行された午後 2 時には表に存在していました したがって 午後 2 時から現在までの間に 誰かが誤って JOHN のレコードを削除したのです 人事管理者は Oracle Flashback Table を使用して EMP 表に設定されているトリガーを有効にして 表を午後 2 時の状態に戻します この場合は 次のように入力します FLASHBACK TABLE EMP TO TIMESTAMP TO_TIMESTAMP(' :00:00') ENABLE TRIGGERS; 参照 : Oracle Flashback Table の簡単な使用例は Oracle Database SQL リファレンス を参照してください フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 7-5

144 Oracle Flashback Drop: DROP TABLE 操作の取消し Oracle Flashback Drop: DROP TABLE 操作の取消し Oracle Flashback Drop を使用すると DROP TABLE 操作の影響を無効にできます この機能を使用すると 誤って削除した表をリカバリできます Oracle Flashback Drop は このような状況で使用可能な他のリカバリ方法 (Point-in-Time リカバリなど ) より大幅に高速に実行でき 最新のトランザクションも保持し 停止時間も発生しません 表を削除した場合 その表に関連付けられた領域はすぐには削除されません かわりに 表の名前が変更され 関連付けられたオブジェクトとともにデータベースのごみ箱ごみ箱に移動されます 削除のフラッシュバック操作を実行すると その表がごみ箱からリカバリされます Oracle Flashback Drop の使用方法を理解するには ごみ箱の仕組み その内容へのアクセス方法およびその管理方法も理解する必要があります この項の内容は 次のとおりです ごみ箱の概要 ごみ箱への表およびその他のオブジェクトの移動 ごみ箱内のオブジェクトのネーミング規則 ごみ箱内のオブジェクトの表示および問合せ ごみ箱の容量と領域圧迫 ごみ箱からのオブジェクトの消去 ごみ箱の概要 ごみ箱は 削除されたすべての表およびそれらの依存オブジェクトを格納する論理的なコンテナです 表が削除されると 後でリカバリできるように表とその依存オブジェクトがごみ箱に格納されます ごみ箱に格納される依存オブジェクトには 索引 制約 トリガー ネストした表 LOB セグメント LOB 索引セグメントが含まれます ごみ箱への表およびその他のオブジェクトの移動 DROP TABLE 文を実行するたびに 表とその依存オブジェクトがごみ箱に移動されます たとえば 次の文を実行すると EMPLOYEE_DEMO 表が 前述した索引 制約などの依存オブジェクトとともにごみ箱に移動されます SQL> DROP TABLE EMPLOYEE_DEMO; Table Dropped 表およびその依存オブジェクトは ごみ箱から消去消去されるまでごみ箱の中に残ります SQL*Plus の PURGE 文を使用すると 表またはその他のオブジェクトをごみ箱から明示的に消去できます (7-10 ページの ごみ箱からのオブジェクトの消去 を参照 ) 後で表をリカバリする必要がないことが確実な場合は DROP TABLE 文に PURGE オプションを使用して その表をごみ箱に移動せず 即時永続的に削除できます たとえば 次のように入力します DROP TABLE employee_demo PURGE; ごみ箱からオブジェクトを明示的に消去しない場合でも 表領域の制約を満たすために データベースによってごみ箱からオブジェクトが削除される場合があります 詳細は 7-8 ページの ごみ箱の容量と領域圧迫 を参照してください ごみ箱内のオブジェクトは 使用領域とはみなされません 領域のビューを問い合せてデータベース内の空き領域を取得すると ごみ箱内のオブジェクトは空き領域とみなされます オブジェクトは 削除された後もビュー USER_TABLES ALL_TABLES DBA_TABLES USER_INDEX ALL_INDEX および DBA_INDEX に表示されます 新しい列 DROPPED が これらのオブジェクトに対して YES に設定されます これらのビューに対する問合せに DROPPED 列を使用すると 削除されていないオブジェクトのみを表示できます ごみ箱内のオブジェクトのみを表示するには この章で後述する USER_RECYCLEBIN および DBA_RECYCLEBIN ビューを使用します 7-6 Oracle Database バックアップおよびリカバリ基礎

145 Oracle Flashback Drop: DROP TABLE 操作の取消し ごみ箱内のオブジェクトのネーミング規則 表およびその依存オブジェクトは ごみ箱に移動されると一意の名前が割り当てられ 名前の競合が回避されます 名前の競合は 次の状況で発生する場合があります 1 人のユーザーが表を削除し 同じ名前の別の表を作成して その表も削除した場合 2 人のユーザーが表に同じ名前を付け 2 人とも表を削除した場合 割り当てられる名前はグローバルに一意で ごみ箱に格納されている間のオブジェクトを識別するために使用されます オブジェクト名の形式を次に示します BIN$$globalUID$version 次に ここで示されている文字列について説明します globaluid は オブジェクト用に生成されるグローバルに一意な 24 文字の識別子です version は データベースによって割り当てられるバージョン番号です ごみ箱内のオブジェクトの名前は 常に 30 文字です ごみ箱での名前に使用される globaluid は オブジェクトまたはデータベースの情報が一目でわかるような 直接内容に関連する文字列ではありません ごみ箱の有効化および無効化 デフォルトでは ごみ箱は有効に設定されています 初期化パラメータ RECYCLEBIN を使用して ごみ箱を明示的に有効または無効にすることができます ごみ箱を有効にするには RECYCLEBIN の値を ON に設定します ごみ箱を無効にするには RECYCLEBIN の値を OFF に設定します データベースでパラメータ ファイル (PFILE) を使用している場合は パラメータ ファイルの RECYCLEBIN の値を指定できます 次に例を示します # turn off recycle bin RECYCLEBIN=OFF この値は すべてのデータベース セッションに適用されます ユーザー独自のデータベース セッションにごみ箱の動作を指定するには SQL*Plus で ALTER SESSION 文を使用して そのセッション用の RECYCLEBIN パラメータの値を変更できます たとえば 次のコマンドでは データベース セッションのごみ箱が無効になります ALTER SESSION SET RECYCLEBIN=OFF; このセッション中に削除するオブジェクトは ALTER SESSION SET RECYCLEBIN=ON を使用してごみ箱を有効にするまで ごみ箱に格納されなくなります ただし 他のユーザーはごみ箱によって保護されたままです また 将来のセッションでは データベース全体に対し この値が現行のデフォルトに戻されます また SQL*Plus で ALTER SYSTEM 文を使用して データベース全体に対し RECYCLEBIN パラメータの値を変更することもできます 次に例を示します ALTER SYSTEM SET RECYCLEBIN=OFF; これによって ユーザーが ALTER SESSION SET RECYCLEBIN=ON を使用して自分のセッションのごみ箱を個別に有効にするまでは すべてのセッションでのごみ箱が無効になります 注意 : ALTER SYSTEM または ALTER SESSION を使用して ごみ箱を有効または無効にしても すでにごみ箱にあるオブジェクトには影響しません フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 7-7

146 Oracle Flashback Drop: DROP TABLE 操作の取消し ごみ箱内のオブジェクトの表示および問合せ ごみ箱の内容を表示するには SQL*Plus の SHOW RECYCLEBIN コマンドを使用します SQL> show recyclebin; ORIGINAL NAME RECYCLEBIN NAME TYPE DROP TIME EMPLOYEE_DEMO BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0 TABLE :17:08:54 ORIGINAL NAME 列にオブジェクトの元の名前が表示され RECYCLEBIN NAME 列にごみ箱内でのオブジェクト名が表示されます ごみ箱内の表を問い合せる場合は RECYCLEBIN NAME を使用します また 次の 2 つのビューで ごみ箱内のオブジェクトの情報を取得できます ビュー USER_RECYCLEBIN DBA_RECYCLEBIN 説明 ユーザーが 自分でごみ箱に移動したオブジェクトを参照できます 簡単に使用するためのシノニム RECYCLEBIN があります 管理者が ごみ箱に移動されたすべてのオブジェクトを参照できます 次の例では ビューを使用して 削除したオブジェクトの元の名前を確認します SQL> SELECT object_name as recycle_name, original_name, type FROM recyclebin; RECYCLE_NAME ORIGINAL_NAME TYPE BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0 EMPLOYEE_DEMO TABLE BIN$JKS983293M1dsab4gsz/I249==$0 I_EMP_DEMO INDEX BIN$NR72JJN38KM1dsaM4gI348as==$0 LOB_EMP_DEMO LOB BIN$JKJ399SLKnaslkJSLK330SIK==$0 LOB_I_EMP_DEMO LOB INDEX 次の 3 つの条件を満たしている場合は 他のオブジェクトを問い合せるときと同様に ごみ箱内のオブジェクトを問い合せることができます FLASHBACK 権限を持っている ごみ箱に移動される前のオブジェクトに対する問合せの実行に必要な権限を持っている オブジェクトの元の名前ではなく ごみ箱でのオブジェクトの名前を問合せに使用する 次に ごみ箱内のオブジェクトを問い合せる構文の例を示します SQL> SELECT * FROM "BIN$KSD8DB9L345KLA==$0"; ( ごみ箱での名前に特殊文字を使用しているため 引用符を使用しています ) ごみ箱の容量と領域圧迫 また ごみ箱の表に対して Oracle Flashback Query を使用することもできます ( 前述の権限が必要です ) ごみ箱には 事前に一定量の領域が割り当てられているわけではありません そのため 削除されたオブジェクトがごみ箱に保持される最短期間も保証されていません この項では オブジェクトがごみ箱に保持される期間および領域の再生方法および再生時期を決定する規則について説明します 領域圧迫の理解 削除されたオブジェクトは 属している表領域に その表領域を拡張せずに新しいエクステントを割り当てられなくなるまでごみ箱内に保持されます この状態を 領域圧迫領域圧迫といいます 領域圧迫は 特定の表領域に定義されたユーザー割当て制限によって発生する場合もあります 7-8 Oracle Database バックアップおよびリカバリ基礎

147 Oracle Flashback Drop: DROP TABLE 操作の取消し 表領域に空き領域が存在しても ユーザーが表領域に対する割当て制限をすべて使用している場合があります 領域圧迫に対する処理が必要となった場合を除いて ごみ箱内の領域の再生またはオブジェクトの上書きは自動的には行われません データベースによる領域圧迫の処理 領域圧迫が発生すると データベースによって ごみ箱から自動的に消去するオブジェクトが選択されます オブジェクトは 先入れ先出しの順序で消去されます つまり 最初に削除されたオブジェクトが最初に消去されます 実際のオブジェクトの消去は 発生した領域圧迫の解消に必要な場合にのみ行われます つまり すぐに必要な領域を確保するために消去する必要がある最小限の数のオブジェクトが選択され 消去されます この方針によって 次の 2 つの目的が実現されます 必要以上に消去操作を実行しないことで 領域圧迫を発生させたトランザクションのパフォーマンスの低下を最小限に抑えます 領域が必要になるまでオブジェクトをごみ箱に残しておくことで オブジェクトの保持期間を最大限に伸ばします 表の索引などの依存オブジェクトは 関連付けられた表 ( またはその他の必要なセグメント ) より先に消去されます 個々のユーザーが表領域の割当て制限をすべて使用したために領域圧迫が発生した場合は 表領域に属するオブジェクトのうち ユーザーの領域の割当て制限の負担になるオブジェクトが ごみ箱から消去されます AUTO EXTEND を実行可能な表領域の場合 データ ファイルが拡張される前にオブジェクトはごみ箱から消去され 領域が再生されます ごみ箱のオブジェクトとセグメント ごみ箱は 表や索引などのオブジェクト レベルで機能します オブジェクトには パーティション表 パーティション索引 LOB セグメント ネストした表などの複数のセグメントが関連付けられている場合があります データベースでは 領域圧迫をすぐに解消するために必要なセグメントのみが再生されるため オブジェクトの一部のセグメントのみが再生される場合があります この場合 すぐに再生されなかったオブジェクトのセグメントに 一時セグメントのマークが付けられます これらの一時セグメントは 次に領域圧迫が発生した場合に 最初に再生されます このような場合は Oracle Flashback Drop を使用して 部分的に再生されたオブジェクトをごみ箱から出すことはできません ( たとえば パーティション表の 1 つのパーティションが再生された場合 その表は削除のフラッシュバックの対象にはなりません ) ごみ箱内の表に対する削除のフラッシュバックの実行 FLASHBACK TABLE... TO BEFORE DROP 文を使用すると オブジェクトをごみ箱からリカバリできます ごみ箱内の表の名前または元の表の名前のいずれかを指定できます この名前は DBA_RECYCLEBIN または USER_RECYCLEBIN ビューから取得できます (7-8 ページの ごみ箱内のオブジェクトの表示および問合せ を参照 ) FLASHBACK TABLE... TO BEFORE DROP 文を使用するには 表を削除する場合と同様の権限が必要です 次の例では BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0 表をリストアし その名前を hr.int_admin_emp に戻して そのエントリをごみ箱から消去します FLASHBACK TABLE "BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0" TO BEFORE DROP; 引用符の使用には注意が必要です これは 特殊文字がごみ箱のオブジェクト名に表示されている可能性があるためです Oracle Flashback Drop 操作では 表の元の名前を使用することもできます FLASHBACK TABLE HR.INT_ADMIN_EMP TO BEFORE DROP; フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 7-9

148 Oracle Flashback Drop: DROP TABLE 操作の取消し RENAME TO 句を指定して リストアした表に新しい名前を割り当てることができます 次に例を示します FLASHBACK TABLE "BIN$KSD8DB9L345KLA==$0" TO BEFORE DROP RENAME TO hr.int2_admin_emp; 元の名前が同じ複数のオブジェクトに対する削除のフラッシュバック 元の名前が同じ複数のオブジェクトを作成して 削除できます これらのすべてのオブジェクトは ともにごみ箱に格納されます たとえば 次の SQL 文を実行するとします CREATE TABLE EMP (...columns ); # EMP version 1 DROP TABLE EMP; CREATE TABLE EMP (...columns ); # EMP version 2 DROP TABLE EMP; CREATE TABLE EMP (...columns ); # EMP version 3 DROP TABLE EMP; この場合 各 EMP 表には 削除時にごみ箱での一意の名前が割り当てられます 表の元の名前を指定して FLASHBACK TABLE... TO BEFORE DROP 文を実行できます たとえば 次のように入力します FLASHBACK TABLE EMP TO BEFORE DROP; その元の名前を持つ最後に削除された表が 元の名前でごみ箱から取り出されます その表を取り出し RENAME TO 句を使用してその表に新しい名前を割り当てることができます 次の例では 前述の例で削除した 3 つすべての EMP 表をごみ箱から取り出し それぞれに新しい名前を付けます FLASHBACK TABLE EMP TO BEFORE DROP RENAME TO EMP_VERSION_3; FLASHBACK TABLE EMP TO BEFORE DROP RENAME TO EMP_VERSION_2; FLASHBACK TABLE EMP TO BEFORE DROP RENAME TO EMP_VERSION_1; FLASHBACK TABLE... TO BEFORE DROP で元の名前を使用すると その名前を持つ 最後に削除された表が参照されるため 最初に取り出される表は 最後に削除された表になります また ごみ箱での表の一意の名前を使用すると 元の名前が競合している場合でも ごみ箱から目的の表を取り出すことができます ごみ箱からのオブジェクトの消去 PURGE コマンドを使用すると オブジェクトをごみ箱から永続的に消去できます 一度消去したオブジェクトは Oracle Flashback Drop を使用してごみ箱から取り出すことができなくなります PURGE 文の形式は ごみ箱から消去するオブジェクトによって異なります 参照 : PURGE 文の詳細は Oracle Database SQL リファレンス を参照してください PURGE TABLE: 表および依存オブジェクトの消去 PURGE TABLE コマンドを使用すると 個々の表およびそのすべての依存オブジェクトをごみ箱から消去できます 次に 表の元の名前を使用した構文の例を示します PURGE TABLE EMP; また PURGE TABLE にはごみ箱でのオブジェクトの名前も使用できます PURGE TABLE "BIN$KSD8DB9L345KLA==$0"; 元の名前が同じ複数の表を作成して削除した場合 PURGE TABLE 文を実行すると 最初に削除した表が消去されます 7-10 Oracle Database バックアップおよびリカバリ基礎

149 Oracle Flashback Drop: DROP TABLE 操作の取消し 注意 : この場合の動作は FLASHBACK TABLE... TO BEFORE DROP の動作 ( 表の元の名前を使用すると 最後に削除した表がごみ箱から取り出される ) と反対になります たとえば 次の一連の CREATE TABLE および DROP TABLE 文を実行するとします CREATE TABLE EMP; DROP TABLE EMP; CREATE TABLE EMP; DROP TABLE EMP; CREATE TABLE EMP; DROP TABLE EMP; # version 1 of the table # version 1 dropped # version 2 of the table # version 2 dropped # version 3 of the table # version 3 dropped この時点で 3 つの EMP 表がごみ箱に格納されています PURGE TABLE EMP を複数回実行した結果は 次のとおりです PURGE TABLE EMP; PURGE TABLE EMP; PURGE TABLE EMP; # version 1 of the table is purged # version 2 of the table is purged # version 3 of the table is purged PURGE INDEX: ごみ箱内の領域の解放 PURGE INDEX を使用すると ごみ箱内の実表を保持したまま表の索引のみを消去できます 索引を消去するための構文は 次のとおりです PURGE INDEX "BIN$GTE72KJ22H9==$0"; ごみ箱から索引を消去することで 領域圧迫が発生する可能性を低減できるため 削除した表をより長くごみ箱に残しておくことができます Oracle Flashback Drop を使用して表をごみ箱から取り出す場合は 表を取り出した後に索引を再作成できます PURGE TABLESPACE: 表領域内の削除したすべてのオブジェクトの消去 PURGE TABLESPACE コマンドを使用すると 特定の表領域内の 削除したすべての表および他の依存オブジェクトを消去できます 構文は次のとおりです PURGE TABLESPACE hr; また 次の書式のコマンドを使用して 特定のユーザーに属する表領域のオブジェクトのみを消去することもできます PURGE TABLESPACE hr USER scott; PURGE RECYCLEBIN: ユーザーのごみ箱内のすべてのオブジェクトの消去 PURGE RECYCLEBIN コマンドを使用すると 現在ログインしているユーザーのごみ箱の内容を消去できます PURGE RECYCLEBIN; このユーザーのすべての表とその依存オブジェクトが このユーザーが所有する表の索引を除くすべての索引とともに消去されます PURGE DBA_RECYCLEBIN: ごみ箱内のすべてのオブジェクトの消去 SYSDBA 権限を持っている場合は どのユーザーがオブジェクトを所有しているかに関係なく 次のコマンドを使用して すべてのオブジェクトをごみ箱から消去できます PURGE DBA_RECYCLEBIN; フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 7-11

150 Oracle Flashback Drop: DROP TABLE 操作の取消し 表領域 クラスタ ユーザーまたは型の削除とごみ箱 表領域をその内容とともに削除すると 表領域内のオブジェクトは即時削除され ごみ箱には移動されません 削除した表領域内のオブジェクトがごみ箱に格納されている場合は ごみ箱から消去されます 表領域のすべてのオブジェクトがごみ箱に格納されている場合 DROP TABLESPACE で INCLUDING CONTENTS 句を指定していない場合でも 表領域を削除するとオブジェクトが消去されます ユーザーを削除すると そのユーザーに属するオブジェクトでごみ箱に格納されていないものは即時削除され ごみ箱には移動されません ユーザーに属するオブジェクトがごみ箱に格納されている場合は ごみ箱から消去されます クラスタを削除すると クラスタ内のすべての表が消去されます ユーザー定義のデータ型を削除すると その型に直接または間接的に依存するすべてのオブジェクトが消去されます Oracle Flashback Drop のための権限およびセキュリティ この項では Oracle Flashback Drop とごみ箱に関連する操作に必要なシステム権限について説明します DROP オブジェクトを削除する権限を持つユーザーは オブジェクトを削除してごみ箱に移動できます FLASHBACK TABLE... TO BEFORE DROP この権限は DROP 権限に関連付けられています つまり オブジェクトを削除できるユーザーは Oracle Flashback Drop を実行して 削除したオブジェクトをごみ箱から取り出すことができます PURGE この権限は DROP 権限に関連付けられています DROP TABLE または DROP ANY TABLE 権限を持つユーザーは オブジェクトをごみ箱から消去できます ごみ箱内のオブジェクトに対する SELECT ごみ箱内のオブジェクトを問い合せるには ごみ箱内のオブジェクトに対する SELECT および FLASHBACK 権限が必要です オブジェクトが削除される前にそのオブジェクトに対する SELECT 権限を持っていたユーザーは 継続してごみ箱内のオブジェクトに対する SELECT 権限を持ちます ごみ箱内のオブジェクトは 過去の状態のデータベースのオブジェクトであるため これらのオブジェクトを問い合せるには FLASHBACK 権限が必要です Oracle Flashback Drop の制限事項 ごみ箱の機能は システム表領域を除く ローカル管理表領域に対してのみ使用可能です 表がシステム表領域ではないローカル管理表領域に含まれていて その依存セグメント ( オブジェクト ) がディクショナリ管理表領域に含まれている場合 これらのオブジェクトはごみ箱によって保護されます ごみ箱には 一定量の領域が割り当てられていません また 削除されたオブジェクトがごみ箱に保持される期間も保証されていません 削除されたオブジェクトがごみ箱内に保持される期間は システムのアクティビティによって数秒から数か月まで異なります ごみ箱に格納されているオブジェクトに対して問合せは実行できますが DML または DDL 文は使用できません ごみ箱内の表に対してフラッシュバック問合せは実行できますが ごみ箱での名前を使用する必要があります 表の元の名前は使用できません 表を削除すると その表とすべての依存オブジェクト ( 索引 LOB セグメント ネストした表 トリガー 制約など ) も一緒にごみ箱に移動されます 同様に Oracle Flashback Drop を実行すると 通常 すべてのオブジェクトが同時に取り出されます 7-12 Oracle Database バックアップおよびリカバリ基礎

151 Oracle Flashback Database を使用したデータベースの変更の取消し ただし 索引などの一部の依存オブジェクトが 領域圧迫を解消するために再生される場合があります このような場合 再生された依存オブジェクトはごみ箱から取り出されません セキュリティ上の理由から 表に対してファイングレイン監査 (FGA) および Virtual Private Database(VPD) の方針が定義されている場合 その表はごみ箱によって保護されません パーティション索引構成表は ごみ箱によって保護されません 表の参照制約は ごみ箱に保持されません ( ただし 他の制約は 可能であれば保持されます ) 表を削除する ( ごみ箱に移動する ) 前にその表に参照制約が定義されていた場合は Oracle Flashback Drop を実行してごみ箱から表を取り出した後で参照制約を再作成します Oracle Flashback Database を使用したデータベースの変更の取消し 5-9 ページの Oracle Flashback Database の設定とメンテナンス に示すように データベースがフラッシュバック ロギング用に構成されている場合は FLASHBACK DATABASE コマンドを使用して データベースの内容をフラッシュバックの期間内の時点に戻すことができます また FLASHBACK DATABASE を使用すると 5-7 ページの 通常のリストア ポイントと保証付きリストア ポイントの作成 に示すコマンドを使用して以前に定義した保証付きリストア ポイントまで戻すこともできます この項では Oracle Flashback Database を使用して データベースに対する不要な変更を取り消す 一般的な使用例を説明します この項では次の項目を取り上げます Oracle Flashback Database の実行例 保証付きリストア ポイントまでのデータベースのフラッシュバックの実行 Oracle Flashback Database の実行による OPEN RESETLOGS の取消し 注意 : 保証付きリストア ポイントを定義していない場合は そのターゲット SCN がフラッシュバックの期間 (FLASHBACK DATABASE を使用できる SCN の範囲 ) 内であることを確認します フラッシュバックの期間の確認方法については 5-12 ページの 現行のデータベースのフラッシュバックの期間の確認 を リカバリで使用できる保証付きリストア ポイントの有無の確認方法については 5-8 ページの リストア ポイントのリスト を参照してください フラッシュバックの期間が目的の目標時点に達する過去の時点まで提供されておらず その目的の時点での保証付きリストア ポイントが存在しない場合は 同じ結果を得るために データベースの Point-in-Time リカバリを使用できます 詳細は 7-18 ページの データベースの Point-In-Time リカバリの実行 を参照してください Oracle Flashback Database の実行例 この項では Oracle Flashback Database を実行するためのプロセスについて ほとんどすべての場合での基本的な概要を説明します このプロセスでは 目的の目標時点の指定に 時刻書式 通常のリストア ポイントか保証付きリストア ポイントの名前 または SCN を使用します Oracle Flashback Database の操作を Recovery Manager で実行するには 次の手順を使用します 1. FLASHBACK DATABASE コマンドで使用する 目的の SCN リストア ポイントまたは時点を決定します フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 7-13

152 Oracle Flashback Database を使用したデータベースの変更の取消し 注意 : SCN を使用して目標を指定し データベースを 以前の Point-in-Time リカバリまたは Oracle Flashback Database の操作を使用して取り消された変更が反映されている状態に戻す場合には 特に注意が必要なため 7-16 ページの Oracle Flashback Database およびインカネーションをまたがった不明確な SCN を参照してください 目的が保証付きリストア ポイントまでのフラッシュバックである場合は 7-16 ページの 保証付きリストア ポイントまでのデータベースのフラッシュバックの実行 に示す方法を使用できます 目的が最後の OPEN RESETLOGS 操作の直前の時点に データベースを戻すことである場合は 7-17 ページの Oracle Flashback Database の実行による OPEN RESETLOGS の取消し に示す手順を使用します 2. Recovery Manager を起動し ターゲット データベースに接続します 次に例を示します rman TARGET / 3. データベースを正常に停止して データベースをオープンしているインスタンスがないことを確認します その後で これをマウントします RMAN> SHUTDOWN IMMEDIATE; RMAN> STARTUP MOUNT; ページの 現行のデータベースのフラッシュバックの期間の確認 に示す問合せを再実行します データベースを停止すると いくつかのフラッシュバック ロギング データが生成されます そのロギングに対応するフラッシュ リカバリ領域の領域圧迫のためにデータベースのフラッシュバック ログが削除されている場合 ターゲット SCN にフラッシュバックできない可能性があります 注意 : FLASHBACK DATABASE を試行したときにターゲット SCN がすでにフラッシュバック期間の範囲外になっている場合 ORA エラーが発生して FLASHBACK DATABASE が失敗します この場合 データベースは変更されません 5. Oracle Flashback Database の実行中 Recovery Manager で バックアップからいくつかのアーカイブ REDO ログをリストアする必要がある場合があります バックアップがテープに格納されているが SBT デバイスへのアクセスに必要なチャネルを構成していない場合は RUN ブロック内に FLASHBACK DATABASE コマンドを指定し 必要に応じて ALLOCATE CHANNEL コマンドを発行して Recovery Manager でディスクまたはテープからこれらのログを取得できるようにします 6. 次の例に示すいずれかの形式のコマンドを使用して目標時点を指定し Recovery Manager の FLASHBACK DATABASE コマンドを実行します RMAN> FLASHBACK DATABASE TO SCN 46963; RMAN> FLASHBACK DATABASE TO RESTORE POINT BEFORE_CHANGES; RMAN> FLASHBACK DATABASE TO TIME "TO_DATE('09/20/00','MM/DD/YY')"; FLASHBACKDATABASE コマンドが完了したとき データベースはマウントされたままで 指定した時点にリカバリされています 7-14 Oracle Database バックアップおよびリカバリ基礎

153 Oracle Flashback Database を使用したデータベースの変更の取消し データベースを読取り専用でオープンし いくつかの問合せを実行してデータベースの内容を検査することによって データベースが目的の状態に戻っていることを確認できます RMAN> SQL 'ALTER DATABASE OPEN READ ONLY'; Oracle Flashback Database 操作が正常に終了した後に実行可能な操作 Oracle Flashback Database 操作後のデータベースの状態が適切である場合 次のいずれかの操作を実行できます OPEN RESETLOGS 操作を実行してデータベースを更新可能にする RMAN> ALTER DATABASE OPEN RESETLOGS; 注意 : この OPEN RESETLOGS 操作を実行すると FLASHBACK DATABASE のターゲット SCN より後に実行されたデータベースに対するすべての変更が取り消されます ただし 7-17 ページの OPEN RESETLOGS の右側へのデータベースのフラッシュバックの例 に示す方法を使用すると 複数の SCN がフラッシュバックの期間内にあるかぎり データベースをそれぞれの SCN の範囲まで戻すことができます Oracle エクスポート ユーティリティ ( 従来のエクスポートまたは Data Pump Export) を使用して 破損しているオブジェクトをエクスポートします その後 データベースを現在の状態に戻します RMAN> RECOVER DATABASE; この手順を実行すると REDO ログに記録されているすべての変更をデータベースに再適用し 最新の SCN に戻すことによって Oracle Flashback Database の影響が取り消されます データベースを読取り / 書込みで再度オープンすると 以前使用したエクスポート ユーティリティに対応するインポート ユーティリティ ( 従来のインポートまたは Data Pump Import) を使用して エクスポートしたオブジェクトをインポートできます 誤った時刻へのデータベースのフラッシュバック後に実行可能な操作 データベースの状態を調査した結果 Oracle Flashback Database に使用したリストア ポイント 時刻または SCN が誤っていることがわかった場合は 次のいずれかの操作を実行できます 選択した目標時点が新しすぎた場合 FLASHBACK DATABASE コマンドを再度実行してデータベースを必要な時点まで戻すことができます RMAN> FLASHBACK DATABASE TO SCN 42963; #earlier than current SCN 選択したターゲット SCN が古すぎた場合 データベースをマウントし RECOVER DATABASE UNTIL を使用してデータベースを目的の SCN までの時点に進めることができます RMAN> RECOVER DATABASE UNTIL SCN 56963; #later than current SCN FLASBACK DATABASE コマンドの影響を完全に取り消す必要がある場合 UNTIL 句を指定せずに RECOVER DATABASE コマンドを使用するか または SET UNTIL コマンドを使用して データベースの完全リカバリを実行できます RMAN> RECOVER DATABASE; これによって データベースに対するすべての変更が再適用され 最新の SCN の状態に戻されます フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 7-15

154 Oracle Flashback Database を使用したデータベースの変更の取消し Oracle Flashback Database およびインカネーションをまたがった不明確な SCN Point-in-Time リカバリまたは Oracle Flashback Database が実施されたデータベースでは 時点を指定する方法として SCN を使用するのは不明確な方法になる可能性があります OPEN RESETLOGS の後の Oracle Flashback Database または DBPITR の影響は データベースが以前の SCN に戻され その時点以降の変更が取り消されることです したがって その時点以降の一部の SCN は 取り消された変更を参照したり データベースの現行の履歴での変更を参照する可能性があります デフォルトでは FLASHBACK DATABASE コマンドで引数として使用される SCN は 現行のインカネーション パス ( 以前の DBPITR や Oracle Flashback Database の後で取り消されていないインカネーション ) での時点を参照するとみなされます これが目的である場合は Oracle Flashback Database に目標を指定するために SCN を使用して この項の手順を使用できます Oracle Flashback Database を使用して 以前の Oracle Flashback Database または DBPITR の後に取り消された変更に対応する時点までリカバリする場合は 7-17 ページの OPEN RESETLOGS の右側へのデータベースのフラッシュバックの例 に示す方法を使用できます 参照 : データベースのインカネーション 取り消された変更 および OPEN RESETLOGS の影響については 7-19 ページの Point-in-Time リカバリおよびデータベース インカネーションの概要 を参照してください SCN とは異なり 時刻書式およびリストア ポイントは不明確にはなりません 時刻書式は その時点で現行であったインカネーションに常に関連付けられます リストア ポイントは それが作成されたときに現行であったインカネーションに常に関連付けられます これは 取り消されたデータベースのインカネーションに対応する時刻およびリストア ポイントが複数ある場合でも該当します データベースのインカネーションは 指定した時刻またはリストア ポイントが作成された時点で現行であったインカネーションに自動的にリセットされます 保証付きリストア ポイントまでのデータベースのフラッシュバックの実行 V$RESTORE_POINT ビューを使用して 使用可能な保証付きリストア ポイントをリストできます 次に例を示します SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE='YES'; NAME SCN TIME DATABASE_INCARNATION# GUA BEFORE_CHANGES MAR AM 2 YES 使用するリストア ポイントがわかっている場合は データベースをマウントし そのリストア ポイントを使用して FLASHBACK DATABASE コマンドを実行します 次に例を示します RMAN> SHUTDOWN IMMEDIATE; RMAN> STARTUP MOUNT; RMAN> FLASHBACK DATABASE TO RESTORE POINT 'BEFORE_CHANGES'; コマンドが完了したら データベースを読取り専用でオープンし この操作の影響を調査します 結果が予定どおりである場合は RESETLOGS オプションを指定してデータベースをオープンします 7-16 Oracle Database バックアップおよびリカバリ基礎

155 Oracle Flashback Database を使用したデータベースの変更の取消し Oracle Flashback Database の実行による OPEN RESETLOGS の取消し Oracle Flashback Database を使用して不要な OPEN RESETLOGS の前の状態に戻すための基本手順は 7-13 ページの Oracle Flashback Database の実行例 で説明する通常の場合と非常に似ています ただし FLASHBACK DATABASE コマンドで特定の SCN または時点を指定するのではなく FLASHBACK DATABASE TO BEFORE RESETLOGS を使用します 次に例を示します フラッシュバックを実行する前に フラッシュバックの期間の開始時点が 最後の OPEN RESETLOGS の時刻よりも前であることを確認します sql> select resetlogs_change# from v$database; sql> select oldest_flashback_scn from v$flashback_database_log; V$DATABASE.RESETLOGS_CHANGE# が V$FLASHBACK_DATABASE_LOG.OLDEST_ FLASHBACK_SCN より大きい場合は Oracle Flashback Database を使用して OPEN RESETLOGS を前の状態に戻すことができます データベースを停止し それをマウントして フラッシュバックの期間を再度確認します RESETLOGS SCN がまだフラッシュバックの期間内である場合は FLASHBACK DATABASE コマンドを次の形式で使用します RMAN> FLASHBACK DATABASE TO BEFORE RESETLOGS; FLASHBACK DATABASE の他の使用例と同様に ターゲット SCN がデータベースのフラッシュバックの期間の開始時点より前である場合は エラーが戻され データベースは変更されません コマンドが正常に終了すると データベースはマウントされたままで 以前のインカネーションで OPEN RESETLOGS が実行される前の最後の SCN までリカバリされます データベースを読取り専用でオープンし 問合せを実行して データが目的の状態になっていることを確認できます データベースを更新可能な状態に戻すには ALTER DATABASE OPEN RESETLOGS コマンドを使用します スタンバイ データベースにおける OPEN RESETLOGS に対する Oracle Flashback Database OPEN RESETLOGS に対して Oracle Flashback Database がサポートされる場合 スタンバイ データベースでの Oracle Flashback Database の適用がいくつか可能になります 次に例を示します フラッシュバックによるロジカル スタンバイ スイッチオーバーの取消し : データベースのロールが Oracle Flashback Database 操作の目標時点でのロール ( プライマリまたはスタンバイ ) に戻ります フィジカル スタンバイのアクティブ化の取消し : フィジカル スタンバイ データベースを一時的にアクティブ化し テストまたはレポートに使用した後で Oracle Flashback Database を使用してロールをフィジカル スタンバイに戻すことができます クローン データベースまたはスタンバイ データベースのテストへの継続的な使用 : ストレージ スナップショットの使用を必要としません Data Guard での Oracle Flashback Database のこれらの高度な適用の詳細は Oracle Data Guard 概要および管理 を参照してください OPEN RESETLOGS の右側へのデータベースのフラッシュバックの例 現行のインカネーション パスが古いインカネーションから分岐した時点の OPEN RESETLOGS の SCN よりも新しい 親インカネーションの時点にデータベースを戻す必要がある場合があります 親インカネーションで取り消された変更に対応するこれらの時点は 7-20 ページの図 7-1 複数の RESETLOGS が存在するデータベースのインカネーション履歴 などのインカネーションを示す図で 最後の OPEN RESETLOGS の 右側 として表現することができます たとえば この図で データベースがインカネーション 3 である場合に インカネーション 1 で取り消した SCN 1500 まで戻る必要があるとします フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 7-17

156 データベースの Point-In-Time リカバリの実行 Recovery Manager の RESET DATABASE TO INCARNATION コマンドを使用して Oracle Flashback Database で使用する SCN が現行のインカネーションを参照するように指定できます このプロセスは次のとおりです フラッシュバック ログに 該当する SCN までフラッシュバックするのに十分な情報があることを確認します sql> select oldest_flashback_scn from v$flashback_database_log; フラッシュバックのターゲットのインカネーション番号 ( 親インカネーションのインカネーション キー ) を決定します SQL> select prior_incarnation# from v$database_incarnation where status = 'CURRENT'; Recovery Manager で データベースを停止してからマウントします RMAN> SHUTDOWN IMMEDIATE; RMAN> STARTUP MOUNT; データベースのインカネーションに親インカネーションを設定します RMAN> RESET DATABASE TO INCARNATION 1; FLASHBACK DATABASE コマンドを実行します RMAN> FLASHBACK DATABASE TO SCN 1500; フラッシュバックが完了すると 結果を確認できます 成功した場合は RESETLOGS を指定してデータベースをオープンします データベースの Point-In-Time リカバリの実行 データベースの Point-in-Time リカバリ (DBPITR) ( を実行すると リカバリの目標時点より前のバックアップからデータベースがリストアされ 増分バックアップおよび REDO を使用してデータベースが目標時点にロールフォワードされます 使用可能なすべての REDO が使用されたり データベースに対するすべての変更が完全にリカバリされないため DBPITR は不完全リカバリ不完全リカバリとも呼ばれます ターゲット SCN は日時で指定できます この場合の操作は 時間ベースのリカバリ時間ベースのリカバリとも呼ばれます データベースの Point-in-Time リカバリの要件 データベースの Point-in-Time リカバリの要件を次に示します データベースが ARCHIVELOG モードで実行している必要があります DBPITR のターゲット SCN より前のすべてのデータ ファイルのバックアップ およびバックアップの SCN とターゲット SCN の間の期間のアーカイブ REDO ログが存在する必要があります 7-18 Oracle Database バックアップおよびリカバリ基礎

157 データベースの Point-In-Time リカバリの実行 Point-in-Time リカバリおよびデータベース インカネーションの概要 DBPITR を理解するには データベース インカネーションの背景情報と Recovery Manager がどのように現行のインカネーション パスではなく過去の時点のバックアップを処理するかという背景情報が必要です 特に データベースを最後の OPEN RESETLOGS より前の時点に戻す場合には 特別な考慮事項があります この項では次の項目を取り上げます 親 祖先および兄弟のデータベース インカネーションの理解 データベースのインカネーション履歴の例 データベース インカネーションと孤立したバックアップ 親 祖先および兄弟のデータベース インカネーションの理解 RESETLOGS オプションを指定してデータベースをオープンするたびに データベースの新しいインカネーションが作成されます OPEN RESETLOGS を実行すると 現行のオンライン REDO ログがアーカイブされ インカネーションによってログ順序番号が 1 にリセットされて オンライン REDO ログに新しいタイムスタンプおよび SCN が設定されます また インカネーション番号が 1 つ増加します インカネーション番号は REDO のストリームを一意にタグ付けおよび識別するために使用されます インカネーションは相互に複数の相関関係を持つことができます OPEN RESETLOGS 操作によって あるインカネーションから現行のインカネーションが分岐している場合 そのインカネーションを 現行のインカネーションの親インカネーションといいます 親インカネーションとそのすべての親インカネーションは 現行のインカネーションの祖先インカネーションです 共通の祖先を持つ 2 つのインカネーションは 一方のインカネーションが他方のインカネーションの祖先でない場合 兄弟インカネーション兄弟インカネーションです データベースのインカネーション履歴の例 図 7-1 複数の RESETLOGS が存在するデータベースのインカネーション履歴 に 複数のインカネーションを持つデータベースを示します フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 7-19

158 データベースの Point-In-Time リカバリの実行 図 7-1 複数の RESETLOGS が存在するデータベースのインカネーション履歴 SCN SCN 2000 SCN SCN 1 SCN 1000 SCN データベースのインカネーション 1 は SCN 1 で始まり SCN 1000 から SCN 2000 まで続いています インカネーション 1 の SCN 2000 で Point-in-Time リカバリを実行して SCN 1000 まで戻し RESETLOGS 操作でデータベースをオープンします これによって SCN 1000 で始まり SCN 3000 まで続く インカネーション 2 が作成されます インカネーション 2 の SCN 3000 で 別の Point-in-Time リカバリを実行し RESETLOGS 操作を行います これによって SCN 2000 で始まるインカネーション 3 が作成されます LIST INCARNATION コマンドを使用して データベースのインカネーション履歴を表示できます この図のインカネーション履歴を表す出力を 次に示します LIST INCARNATION; List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time TRGT PARENT 1 23-APR TRGT PARENT APR TRGT CURRENT APR-05 Reset SCN 列の値は RESETLOGS が実行されたときの SCN です Inc Key 列には インカネーション キーが示されます Recovery Manager では 一部のコマンドで インカネーション キーを使用してデータベース インカネーションを指定します たとえば RESET DATABASE TO INCARNATION を使用して 一部の複雑なリカバリの例で現行のインカネーションを変更します 参照 : RESET DATABASE コマンドの詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください 兄弟インカネーション 不明確な SCN および RESET DATABASE INCARNATION フラッシュバックまたは Point-in-Time リカバリ操作によって兄弟インカネーションが生成されているデータベースを使用する場合 現行のインカネーションとして設定されているインカネーションによって 特定の SCN 値が複数の時点を示す場合があることに注意してください たとえば この図では SCN 1500 はインカネーション 1 または 2 での時点を示すことが可能です SCN は FLASHBACK DATABASE RECOVER... UNTIL などの Recovery Manager コマンドで使用する場合 デフォルトで 兄弟インカネーションではなく現行のインカネーション パスを 7-20 Oracle Database バックアップおよびリカバリ基礎

159 データベースの Point-In-Time リカバリの実行 示すとみなされます ただし RESET DATABASE TO INCARNATION コマンドを使用すると SCN が別のインカネーションの範囲にあると解釈されます たとえば Point-in-Time リカバリで 次のコマンドを使用するとします RMAN> RECOVER DATABASE TO SCN 1500; 図 7-1 に示すデータベースで使用すると デフォルトで SCN 1500 はインカネーション 2 を示します 次の一連のコマンドを実行するとします RMAN> RESET DATABASE INCARNATION TO 1; RMAN> RECOVER DATABASE TO SCN 1500; SCN 1500 は SCN が 1500 であったときのインカネーション 1 での時点を示します データベース インカネーションと孤立したバックアップ データベースが複数のインカネーションを持つ場合 一部のバックアップは孤立孤立する可能性があります 孤立したバックアップとは 現行のインカネーションの祖先ではないデータベースのインカネーションで作成されたバックアップです 7-19 ページの Point-in-Time リカバリおよびデータベース インカネーションの概要 に示す例のデータベースを使用して 次の表に 孤立したバックアップを示します 孤立したバックアップは どのインカネーションが現行のインカネーションかによって異なります 現行のインカネーション インカネーション 1 インカネーション 2 インカネーション 3 使用可能な ( 孤立していない ) バックアップ インカネーション 1 のすべてのバックアップ SCN 1000 以前のインカネーション 1 のすべてのバックアップ インカネーション 2 のすべてのバックアップ SCN 1000 以前のインカネーション 1 のすべてのバックアップ SCN 2000 以前のインカネーション 2 のすべてのバックアップ インカネーション 3 のすべてのバックアップ 孤立したバックアップ インカネーション 2 および 3 のすべてのバックアップ SCN 1000 より後のインカネーション 1 のバックアップ インカネーション 3 のすべてのバックアップ SCN 1000 より後のインカネーション 1 のすべてのバックアップ SCN 2000 より後のインカネーション 2 のすべてのバックアップ 孤立したバックアップの使用現行のインカネーション パス以外の時点にデータベースをリストアする場合 Recovery Manager で孤立したバックアップを使用できます Recovery Manager は OPEN RESETLOGS 操作が実行された場合でも 最も古いバックアップからリカバリする時点までのアーカイブ ログが連続して存在していれば 直接の祖先であるインカネーションからバックアップをリストアして 現在の時点までリカバリできます また Recovery Manager では バックアップに示されている変更が取り消されたことがないインカネーションから制御ファイルをリストアする場合 孤立したバックアップを使用してリストアおよびリカバリを実行できます データベースの Point-in-Time リカバリの準備 DBPITR の準備として 次の手順を実行します リカバリを終了する必要がある目標時点 SCN リストア ポイントまたはログ順序番号を決定します Oracle Flashback Query Oracle Flashback Version Query および Oracle Flashback Transaction Query 機能は いつ論理的な破損が発生したかを識別するのに役立ちます また alert.log で リカバリが必要なイベントの時間を決定するのに役立つ情報を確認できます フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 7-21

160 データベースの Point-In-Time リカバリの実行 または ターゲット SCN を含むログ順序番号を設定し このログまでリカバリすることもできます たとえば アーカイブ済のログを表示するには V$LOG_HISTORY を問い合せます RECID STAMP THREAD# SEQUENCE# FIRST_CHAN FIRST_TIM NEXT_CHANG SEP SEP SEP たとえば あるユーザーによって午前 9 時 2 分に表領域が誤って削除されたことが判明した場合 削除が発生する直前の午前 9 時までリカバリすることができます この時刻より後にデータベースに加えられたすべての変更は失われます ターゲット SCN のかわりに目標時点を指定する場合 Recovery Manager を起動する前に時刻書式の環境変数が適切に設定されていることを確認します グローバリゼーション サポート設定の例を次に示します NLS_LANG = american_america.us7ascii NLS_DATE_FORMAT="Mon DD YYYY HH24:MI:SS" 現行のインカネーション内での Point-in-Time リカバリ 現行のインカネーション内での DBPITR は 現行の制御ファイルを使用して実行します DBPITR を実行する場合 RESTORE および RECOVER コマンドに個別に UNTIL 句を指定するのではなく プロセスの開始時に SET UNTIL コマンドを使用して目標時点を設定することによってエラーを回避できます これによって バックアップからリストアされたデータ ファイルに十分に古いタイムスタンプが設定され 後続の RECOVER 操作に使用できます DBPITR に必要な手順を次に示します 1. Recovery Manager をターゲット データベースおよび ( 必要に応じて ) リカバリ カタログ データベースに接続します データベースを MOUNT モードにします SHUTDOWN IMMEDIATE; STARTUP MOUNT; 2. RUN ブロック内で 次の操作を実行します a. SET UNTIL を使用して DBPITR の目標時点 リストア ポイント SCN またはログ順序番号を指定します 時刻を指定する場合は 環境変数 NLS_LANG および NLS_DATE_FORMAT で指定した日付書式を使用します b. 自動チャネルが構成されていない場合は 必要に応じてディスク チャネルおよびテープ チャネルを手動で割り当てます c. データベースをリストアおよびリカバリします 次の例では ターゲット データベースに対して SCN 1000 までの DBPITR を実行しています RUN { SET UNTIL SCN 1000; # Alternatives: # SET UNTIL TIME 'Nov :00:00'; # SET UNTIL SEQUENCE 9923; RESTORE DATABASE; RECOVER DATABASE; } 7-22 Oracle Database バックアップおよびリカバリ基礎

161 データベースの Point-In-Time リカバリの実行 注意 : SET UNTIL 時刻の指定には 時刻書式 リストア ポイントまたはログの順序番号を使用することもできます SET UNTIL TIME 'Nov :00:00'; SET UNTIL SEQUENCE 9923; SET UNTIL RESTORE POINT before_update; エラーが発生せずに操作が完了した場合 DBPITR は正常に終了しています データベースを読取り専用でオープンし 必要に応じて問合せを実行して 論理的な破損の影響が無効になっていることを確認できます 論理的な破損の影響が無効になっていない場合は 選択したターゲット SCN が誤っている可能性があります このような場合 不要な変更をさらに調査し 新しいターゲット SCN を決定して DBPITR の処理を繰り返します データベースの Point-in-Time リカバリでの目標時点の指定 前述の例に示したように SET UNTIL 文では SCN のかわりに時刻書式を使用できます ただし SET UNTIL TIME を使用して Point-in-Time リカバリの目標時点を指定する場合は 指定できる時点が現行のインカネーションに含まれていない場合があることに注意してください 目標時点では データベースが祖先インカネーションまたは兄弟インカネーションに存在する場合があります 目標時点が現行のインカネーションにない場合 祖先インカネーションに対する DBPITR の詳細は 7-23 ページの 祖先インカネーションまでの Point-in-Time リカバリ を 現行のインカネーションの祖先ではないインカネーションに対する DBPITR の詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください データベースの Point-in-Time リカバリ後に実行可能な操作 DBPITR が正常に終了した後 次のいずれかの操作を実行できます Data Pump Export などの Oracle エクスポート ユーティリティを使用して 1 つ以上のオブジェクトをデータベースからエクスポートします その後 データベースを現在の時点にリカバリし エクスポートしたオブジェクトを再インポートすることによって 他のすべての変更を取り消すことなく これらのオブジェクトを不要な変更が実行される前の状態に戻すことができます データベースを読取り / 書込みでオープンして ターゲット SCN より後に実行されたすべての変更を取り消します この場合 次に示すとおり RESETLOGS オプションを指定してデータベースをオープンする必要があります RMAN> ALTER DATABASE OPEN RESETLOGS; 現行のオンライン REDO ログがアーカイブされ ログ順序番号が 1 にリセットされ オンライン REDO ログに新しいタイムスタンプおよび SCN が設定されます 新しいログ順序番号およびインカネーションが設定された REDO ログ ファイルを識別することによって 不要なアーカイブ REDO ログが適用されることによるデータ ファイルの破損を回避します データ ファイルが NORMAL モードでオフラインにされているか または読取り専用になっていないかぎり オフラインのデータ ファイルに対する OPEN RESETLOGS 操作は失敗します RESETLOGS の実行後は REDO が不要になるため 読取り専用または NORMAL モードでオフラインにされた表領域のファイルをオンラインにすることができます 祖先インカネーションまでの Point-in-Time リカバリ 現行のインカネーション内の DBPITR と祖先インカネーションの SCN までの DBPITR の主な違いは データベースのインカネーションをターゲット SCN での現行のインカネーションに再設定する必要があり またターゲット SCN が含まれるインカネーションの制御ファイルをリストアする必要があることです フラッシュバックおよびデータベースの Point-in-Time リカバリの実行 7-23

162 データベースの Point-In-Time リカバリの実行 次の状況を想定しています リカバリ カタログで Recovery Manager を実行しています 2004 年 10 月 2 日にターゲット データベース trgt のバックアップを実行しています 2004 年 10 月 10 日にこのデータベースに対して DBPITR を実行し 以前のエラーを修正しています DBPITR の最後に OPEN RESETLOGS 操作を実行して 新しいインカネーションを開始しています 10 月 25 日 2004 年 10 月 8 日午前 8 時にデータベースから削除された重要なデータが必要であることが判明したとします これは 現行のインカネーションの開始点より前の時刻です 古いインカネーションまでの Point-in-Time リカバリを実行するには 次の手順を実行します 月 2 日のバックアップの時点での現行のインカネーションを確認します LISTINCARNATION を使用して 目標時点での現行のインカネーションの主キーを取得します LIST INCARNATION OF DATABASE trgt; List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time TRGT PARENT 1 02-OCT TRGT CURRENT OCT-04 Reset SCN および Reset Time 列で現行のインカネーションを識別し Inc Key 列でインカネーション キーを確認します この例では インカネーション キーの値は 2 です 2. データベースは起動されているが マウントされていないことを確認します STARTUP FORCE NOMOUNT 3. trgt を 10 月 2 日のバックアップの時点での現行のインカネーションに再設定します Inc Key 列の値を使用して インカネーションを識別します # reset database to old incarnation RESET DATABASE TO INCARNATION 2; 4. RUN コマンドで次の操作を実行して データベースをリストアおよびカバリします リカバリの終了時刻をデータが消失する直前の時刻に設定します 必要なチャネルが構成されていない場合は割り当てます 10 月 2 日のバックアップから制御ファイルをリストアし マウントします データ ファイルをリストアし データベースをリカバリします RECOVER DATABASE... UNTIL コマンドを使用して Point-in-Time リカバリを実行し データが消失する直前の 10 月 8 日午前 7 時 55 分の目標時点にデータベースを戻します この場合に必要なすべての手順の例を次に示します RUN { # set target time for all operations in the RUN block SET UNTIL TIME 'Oct :55:00'; RESTORE CONTROLFILE ; # without recovery catalog, use RESTORE CONTROLFILE FROM AUTOBACKUP ALTER DATABASE MOUNT; RESTORE DATABASE; RECOVER DATABASE; } ALTER DATABASE OPEN RESETLOGS; 7-24 Oracle Database バックアップおよびリカバリ基礎

163 8 Recovery Manager のメンテナンス作業 この章では Recovery Manager リポジトリの管理方法およびフラッシュ リカバリ領域に関連する管理作業について説明します この章では 次の項目について説明します 制御ファイルのみを使用した Recovery Manager リポジトリのメンテナンス CROSSCHECK を使用した Recovery Manager リポジトリの更新 メンテナンス操作に対する複数の Recovery Manager チャネルの使用 バックアップ レコードの状態の変更 アーカイブ ログおよびユーザー管理コピーのカタログへの追加 Recovery Manager レコードのカタログからの削除 フラッシュ リカバリ領域のメンテナンス 参照 : リカバリ カタログの使用時における Recovery Manager リポジトリの管理の詳細は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください Recovery Manager のメンテナンス作業 8-1

164 制御ファイルのみを使用した Recovery Manager リポジトリのメンテナンス 制御ファイルのみを使用した Recovery Manager リポジトリのメンテナンス 正式な Recovery Manager リポジトリは 常にデータベースの制御ファイルに格納されます Recovery Manager リポジトリのデータは 制御ファイルに格納される情報の補助として またより長期間のバックアップ履歴を提供するために 1 つ以上のリカバリ カタログ データベースに格納することもできます Recovery Manager はリカバリ カタログを使用しなくても動作するように設計されていますが リカバリ カタログを使用しない場合は いくつかの追加の管理作業を実行する必要があります 参照 : 制御ファイルの概要および管理については Oracle Database 管理者ガイド を参照してください 制御ファイルのバックアップおよびリストア リカバリ カタログを使用しない場合は 制御ファイルが Recovery Manager リポジトリに対する唯一のストレージとなるため 制御ファイルを保護することは非常に重要です 多重化機能またはオペレーティング システムのミラー化機能を使用して代替の制御ファイルを保存し 制御ファイルを頻繁にバックアップします 制御ファイルが確実に保護されるように CONTROLFILE AUTOBACKUP を ON に設定します 制御ファイルの自動バックアップを使用できる場合 Recovery Manager は SPFILE とバックアップ制御ファイルをリストアし データベースをマウントできます 制御ファイルをマウントした後 残りのデータベースをリストアできます 自動バックアップから制御ファイルをリストアした場合 CONFIGURE コマンドで行った永続的な設定は 制御ファイルの自動バックアップ時の値に戻ります 制御ファイルをリストアした後で SHOW ALL コマンドを使用して設定を再確認する必要があります 参照 : 制御ファイルの手動バックアップおよび自動バックアップについては Recovery Manager を使用した制御ファイルのバックアップ を参照してください 現行の制御ファイルおよびリカバリ カタログが使用できない場合のデータベースのリストア方法は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください 制御ファイル レコードの上書きの監視 リカバリ カタログを使用しない場合 制御ファイルは Recovery Manager バックアップの唯一の情報源となります バックアップを行うとき Oracle はこれらのバックアップを制御ファイルに記録します Recovery Manager リポジトリのデータを保持する際に制御ファイルが無制限に大きくならないように 指定したしきい値よりも古いレコードは再利用可能になります CONTROL_FILE_RECORD_KEEP_TIME 初期化パラメータは レコードが上書き可能になるまでの最小日数を決定します CONTROL_FILE_RECORD_KEEP_TIME = integer たとえば パラメータ値が 14 の場合 14 日以上経過したレコードは再利用の候補となります 上書きされたレコードの情報は失われます 再利用可能な最も古いレコードが 最初に使用されます 新しい Recovery Manager リポジトリ レコードを制御ファイルに追加する必要があるにもかかわらず しきい値よりも古いレコードが存在しない場合 Oracle は制御ファイルのサイズを拡大します 根本的なオペレーティング システムの問題によって ( ディスクの領域不足など ) 8-2 Oracle Database バックアップおよびリカバリ基礎

165 制御ファイルのみを使用した Recovery Manager リポジトリのメンテナンス 制御ファイルを拡大できない場合 Oracle は制御ファイル内の最も古いレコードを上書きし この処理をアラート ログに記録します CONTROL_FILE_RECORD_KEEP_TIME のデフォルト値は 7 日間です リカバリ カタログを使用しない場合は CONTROL_FILE_RECORD_KEEP_TIME 値を 保持する必要のある最も古いファイルよりも少し長く設定します たとえば データベース全体を 1 週間に 1 回バックアップする場合は すべてのバックアップを 7 日間以上保持する必要があります CONTROL_ FILE_RECORD_KEEP_TIME の値を 10 や 14 などに設定します 注意 : リカバリ カタログの使用にかかわらず CONTROL_FILE_ RECORD_KEEP_TIME が 0 に設定されている場合は Recovery Manager を使用しないでください Recovery Manager を使用すると バックアップ レコードが失われる場合があります 制御ファイル レコードの上書きの管理 次の場合について考えてみます リカバリ カタログは使用しません CONTROL_FILE_RECORD_KEEP_TIME の設定は 14 です 制御ファイルに存在するレコードの経過日数は すべて 1 ~ 13 日です 制御ファイルは オペレーティング システムによって許可される最大サイズです データ ファイルのバックアップを作成します 制御ファイルはオペレーティング システムの制限を超えるファイル サイズには拡大できないため 制御ファイル内のレコードの上書きが開始されます 最も古いレコードから上書きされます alert.log に 上書きされる各レコードのエントリが次のように記録されます kccwnc: following control file record written over: RECID #72 Recno 72 Record timestamp 07/28/00 22:15:21 Thread=1 Seq#=3460 Backup set key: stamp= , count=17 Low scn: 0x0000.3af33f36 07/27/00 21:00:08 Next scn: 0x0000.3af3871b 07/27/00 23:23:54 Resetlogs scn and time scn: 0x /05/99 10:46:44 Block count= Blocksize=512 このような状況を回避するための最も確実な方法は リカバリ カタログを使用することです リカバリ カタログを使用できない場合は 次の方法を使用して 制御ファイル レコードの上書きに関する問題を回避できます RAW ディスクではなくファイル システムに制御ファイルを格納します これによって 必要に応じて制御ファイルを拡大できます alert.log を監視して Oracle が制御ファイル レコードを上書きしていないことを確認します 参照 : 制御ファイル レコードの概要および再利用方法は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください Recovery Manager のメンテナンス作業 8-3

166 CROSSCHECK を使用した Recovery Manager リポジトリの更新 フラッシュ リカバリ領域と CONTROL_FILE_RECORD_KEEP_TIME の相互作用 フラッシュ リカバリ領域で作成されたファイルに関する情報を含む制御ファイル レコードを再利用する際 ( レコードが CONTROL_FILE_RECORD_KEEP_TIME より古いため ) ファイルが削除対象の場合は データベースでフラッシュ リカバリ領域からファイルの削除が試行されます そうでない場合 このファイルのレコードを含む制御ファイル セクションのサイズがデータベースによって拡張され アラート ログに次のようなメッセージで拡張したことが記録されます kccwnc: trying to expand control file section nnnn for Oracle Managed Files nnnn は制御ファイル レコード タイプの番号です 制御ファイルがホストのオペレーティング システムでサポートされている最大サイズである場合 制御ファイルは拡張することができません このような場合 この警告がアラート ログに表示されます WARNING: Oracle Managed File filename is unknown to control file. This is the result of limitation in control file size that could not keep all recovery area files. これは 制御ファイルで 構成済の保存方針を満たすために必要なすべてのフラッシュ リカバリ領域ファイルのレコードを保持できないことを意味します 次の方法で この問題を解決または軽減できます より大きなブロック サイズ ( できれば 32K) の制御ファイルを使用します これには SYSTEM 表領域のブロック サイズを制御ファイルのブロック サイズ以上に設定し DB_BLOCK_SIZE を変更した後 制御ファイルを再作成する必要があります テープなどの 3 次ストレージ デバイスにファイルをバックアップして フラッシュ リカバリ領域内のファイルを削除対象にします たとえば Recovery Manager の BACKUP RECOVERY AREA コマンドを使用すると フラッシュ リカバリ領域内のファイルをメディア マネージャに明示的にバックアップできます フラッシュ リカバリ領域内のファイルをさらに削除対象にするには 保存方針のリカバリ期間をを短縮するか 冗長性を低くします CROSSCHECK を使用した Recovery Manager リポジトリの更新 リカバリ カタログまたは制御ファイルのバックアップに関するデータがディスクまたはメディア管理カタログの該当するデータと同期されていることを確認するには クロスチェックを実行します CROSSCHECK コマンドは リカバリ カタログまたは制御ファイルに記録されているファイルでのみ動作します この項では次の項目を取り上げます Recovery Manager のクロスチェック バックアップ セットおよびイメージ コピーでの CROSSCHECK の基本的な使用 特定のバックアップ セットおよびコピーのクロスチェック 特定のデータベース ファイルのバックアップのクロスチェック Recovery Manager のクロスチェック クロスチェックは リポジトリ レコードが物理的な状態と一致しないバックアップに関する Recovery Manager リポジトリの期限切れの情報を更新します たとえば ユーザーがオペレーティング システムのコマンドを使用してディスク上からアーカイブ ログを削除すると リポジトリは 実際には削除されている場合でもログがディスク上に存在することを示します バックアップがディスク上に存在する場合 CROSSCHECK コマンドはファイルのヘッダーが有効であるかどうかを確認します バックアップがテープ上に存在する場合 コマンドは単にバックアップが存在することを確認します バックアップの状態の可能な値は AVAILABLE UNAVAILABLE および EXPIRED です 8-4 Oracle Database バックアップおよびリカバリ基礎

167 CROSSCHECK を使用した Recovery Manager リポジトリの更新 Recovery Manager の LIST コマンドを使用するか V$BACKUP_FILES やリカバリ カタログの様々なビュー (RC_DATAFILE_COPY RC_ARCHIVED_LOG など ) を問い合せると バックアップの状態を表示できます クロスチェックを実行すると Recovery Manager リポジトリが更新されるため これらのすべての方法では正確な情報が提供されます Recovery Manager リポジトリ内の各バックアップは バックアップとして使用できなくなると Recovery Manager によって EXPIRED としてマーク付けされます EXPIRED のマークが付いていたバックアップが使用可能になった場合 Recovery Manager によって AVAILABLE のマークが付けられます 注意 : CROSSCHECK コマンドは オペレーティング システムのファイルを削除しません また クロスチェック時に使用できないバックアップの Recovery Manager リポジトリ レコードも削除しません バックアップの状態とともにリポジトリ レコードを更新するだけです DELETE コマンドを使用して Recovery Manager リポジトリから期限切れのバックアップのレコードを削除します 参照 : 不要なバックアップの削除およびリポジトリ レコードの更新方法は 8-6 ページの バックアップの削除 を参照してください CROSSCHECK コマンドの構文およびリポジトリの状態値の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください バックアップ セットおよびイメージ コピーでの CROSSCHECK の基本的な使用 ターゲット データベースとリカバリ カタログ ( 使用している場合 ) に接続してから 必要に応じて CROSSCHECK コマンドを実行し Recovery Manager が認識するバックアップの状態と可用性を検査します テープまたはその他のメディア マネージャ用にチャネルを構成している場合は CROSSCHECK BACKUP を使用して すべてのメディアに格納されているすべてのバックアップをクロスチェックできます 次に例を示します CROSSCHECK BACKUP; テープ バックアップ用にチャネルを構成していない場合は CROSSCHECK を実行する前に RUN ブロックにメンテナンス チャネルを割り当てることができます 次に例を示します RUN { ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt; CROSSCHECK BACKUP; } 次に ディスクのイメージ コピーのみをクロスチェックする方法の例を示します CROSSCHECK COPY; # crosschecks only disk copies of # database files 次に バックアップ セットのみをクロスチェックする方法の例を示します CROSSCHECK BACKUPSET; # crosschecks backupsets on disk and SBT 特定のバックアップ セットおよびコピーのクロスチェック LIST コマンドを使用してバックアップをレポートしてから CROSSCHECK コマンドを使用して LIST 出力に示された特定のバックアップが存在することを確認できます DELETE EXPIRED コマンドは クロスチェックの失敗の原因となるバックアップのリポジトリ レコードを削除します Recovery Manager のメンテナンス作業 8-5

168 バックアップの削除 指定したバックアップをクロスチェックする方法 1. LIST コマンドを発行して 確認する必要のあるバックアップを特定します 次に例を示します LIST BACKUP; # lists all backup sets, proxy copies, and image copies 2. 指定したバックアップか存在するかどうかを確認します 次に例を示します CROSSCHECK BACKUP; # checks backup sets, proxy copies, and image copies CROSSCHECK COPY OF DATABASE; CROSSCHECK BACKUPSET 1338, 1339, 1340; CROSSCHECK BACKUPPIECE TAG = 'nightly_backup'; CROSSCHECK CONTROLFILECOPY '/tmp/control01.ctl'; CROSSCHECK DATAFILECOPY 113, 114, 115; CROSSCHECK PROXY 789; 特定のデータベース ファイルのバックアップのクロスチェック CROSSCHECK コマンドのオプションを使用すると 特定のデータベース 表領域 データ ファイル 制御フィルまたはアーカイブ REDO ログのバックアップのみを確認できます 次に例を示します CROSSCHECK BACKUP OF DATAFILE "?/oradata/trgt/system01.dbf" COMPLETED AFTER 'SYSDATE-14'; CROSSCHECK BACKUP OF ARCHIVELOG ALL SPFILE; 次のコマンドを使用すると アーカイブ REDO ログおよび SPFILE のバックアップを確認できます CROSSCHECK BACKUP OF ARCHIVELOG ALL SPFILE; 参照 : 特定のデータベース ファイルのバックアップを確認するための CROSSCHECK の使用方法の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください Recovery Manager の CROSSCHECK における特定の時点以降のバックアップへの制限 COMPLETED AFTER 句を CROSSCHECK コマンドに追加すると 確認対象のバックアップを 指定した時点以降に作成されたものに制限できます たとえば 次のコマンドでは 先週作成されたデータ ファイルのバックアップが確認されます CROSSCHECK BACKUP OF DATAFILE 4 COMPLETED AFTER 'SYSDATE-14'; バックアップの削除 Recovery Manager を使用して Recovery Manager で作成したバックアップを削除できます Recovery Manager を使用してバックアップを削除すると 指定したバックアップが削除されるとともに その削除を反映するために Recovery Manager リポジトリが更新されます この項では次の項目を取り上げます 指定したバックアップの削除 CROSSCHECK 後の期限切れの Recovery Manager のバックップの削除 Recovery Manager のバックアップでの DELETE FORCE の使用 保存方針に基づいて不要になった Recovery Manager のバックアップの削除 8-6 Oracle Database バックアップおよびリカバリ基礎

169 バックアップの削除 注意 : DELETED 状態のバックアップは LIST コマンドの出力には表示されません ただし V$ 制御ファイル ビューを問い合せると 削除されたバックアップに関する情報を取得できます 参照 : 指定したバックアップの削除 DELETE 構文の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください リカバリ カタログ ビューの詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください 一般的には 保持する必要のないバックアップを削除するには DELETE コマンドを使用します DELETE は バックアップ メディアから物理的なファイルを削除し (Recovery Manager がリカバリ カタログに接続されている場合は ) リカバリ カタログからバックアップのレコードを削除して 制御ファイル内のこれらのバックアップのレコードを DELETED 状態に更新します DELETE コマンドでは 次のような様々なタイプのバックアップの削除がサポートされています DELETE BACKUP( バックアップ セット プロキシ コピーおよびイメージ コピーを削除 ) DELETE COPY( イメージ コピーのみを削除 ) DELETE ARCHIVELOG などで 次の例に示されています DELETE コマンドでは 削除するバックアップを指定するための様々なオプションがサポートされています これらのオプションの詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください 次の例には DELETE コマンドを使用して削除するバックアップおよびアーカイブ REDO ログを指定する様々な一般的な方法を示します LIST 出力の主キーを使用してバックアップを削除します DELETE BACKUPPIECE 101; ディスク上のファイル名を使用してバックアップを削除します DELETE CONTROLFILECOPY '/tmp/control01.ctl'; ディスクからアーカイブ REDO ログを削除します DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE = 300; タグに基づいてバックアップを削除します DELETE BACKUP TAG='before_upgrade'; バックアップされているオブジェクトおよびバックアップが格納されているメディアまたはディスクの場所に基づいてバックアップを削除します DELETE BACKUP OF TABLESPACE users DEVICE TYPE sbt; # delete only from tape DELETE COPY OF CONTROLFILE LIKE '/tmp/%'; # Recovery Manager リポジトリに記録されているこのデータベースのすべてのバックアップを削除します DELETE BACKUP; テープにバックアップされているかどうかに基づいて ディスクからバックアップとアーカイブ REDO ログを削除します DELETE ARCHIVELOG ALL BACKED UP 3 TIMES TO sbt; Recovery Manager のメンテナンス作業 8-7

170 バックアップの削除 対話形式で Recovery Manager を実行すると ファイルを削除する前に確認が求められます DELETE コマンドのいずれの形式でも NOPROMPT キーワードを使用することによって これらの確認をしないようにできます DELETE NOPROMPT ARCHIVELOG ALL; CROSSCHECK 後の期限切れの Recovery Manager のバックップの削除 CROSSCHECK を使用してリポジトリに記録されたバックアップがディスクまたはテープにまだ存在するかどうかを確認したときに Recovery Manager がそのバックアップの場所を確認できない場合 Recovery Manager は Recovery Manager リポジトリ内のそのバックアップのレコードを EXPIRED 状態に更新します その後 DELETE EXPIRED コマンドを使用して Recovery Manager リポジトリから期限切れのバックアップのレコードを削除できます 期限切れのファイルがまだ存在する場合 DELETE EXPIRED コマンドはエラーを戻して終了します 期限切れのリポジトリ レコードを削除する方法 1. 最近クロスチェックを実行していない場合は CROSSCHECK コマンドを発行します 次に例を示します CROSSCHECK BACKUP; # checks backup sets and copies on configured channels 2. 期限切れのバックアップを削除します 次に例を示します DELETE EXPIRED BACKUP; 注意 : EXPIRED とマークされたオブジェクトが実際に存在する場合 DELETE EXPIRED コマンドは警告を発行します まれに オブジェクトが存在する場合でも リポジトリはオブジェクトに EXPIRED のマークを付ける場合があります たとえば オブジェクトを含むディレクトリがクロスチェック時に破損し 後で修復されたり メディア マネージャが適切に構成されなかったために実際には存在するバックアップが存在しないとレポートされたりします Recovery Manager のバックアップでの DELETE FORCE の使用 Recovery Manager リポジトリが示すオブジェクトの状態が メディアのオブジェクトの実際の状態と異なる場合があります たとえば 実際にはバックアップ セットがディスクまたはテープに存在しない ( または メディア マネージャにおけるテープやその他のバックアップ メディアの内容のカタログから消失している ) 場合でも Recovery Manager リポジトリはそのバックアップ セットが AVAILABLE であると示します オブジェクトを削除しようとすると 次のような警告が表示されます RMAN-06207: WARNING: 1 objects could not be deleted for DISK channel(s) due RMAN-06208: to mismatched status. Use CROSSCHECK command to fix status List of Mismatched objects ========================== Object Type Filename/Handle Backup Piece 0id270ud_1_1 オプションの FORCE キーワードを指定して DELETE コマンドを使用すると Recovery Manager は指定されたバックアップを削除しますが バックアップがディスクまたはテープから消失している場合に発生するエラーなど すべての I/O エラーを無視します この後で Recovery Manager がファイルを削除できたかどうか またはファイルがすでに消失していたかどうかに関係なく Recovery Manager リポジトリを更新して バックアップが削除された事実を反映します 次に例を示します DELETE FORCE NOPROMPT BACKUPSET TAG 'weekly_bkup'; 8-8 Oracle Database バックアップおよびリカバリ基礎

171 メンテナンス操作に対する複数の Recovery Manager チャネルの使用 参照 : 保存方針に基づいて不要になった Recovery Manager のバックアップの削除 Recovery Manager の DELETE コマンドでは OBSOLETE オプションがサポートされ これによって 不要になったバックアップ つまり指定したリカバリ可能性の要件を満たす必要がなくなったバックアップが削除されます 構成済のデフォルトの保存方針 または DELETE OBSOLETE コマンドにオプションとして指定した他の保存方針に従って 不要とされるファイルを削除できます DELETE コマンドの他の形式と同様に 削除されたファイルはバックアップ メディアおよびリカバリ カタログから削除され 制御ファイル内で DELETED としてマーク付けされます 引数を付けずに DELETE OBSOLETE コマンドを指定した場合 Recovery Manager は現在構成されている保存方針によって不要と定義されるすべてのバックアップを削除します 次に例を示します DELETE OBSOLETE; バックアップ メディアとリポジトリが同期されていない場合の DELETE の動作は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください DELETE コマンドの構文の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください また REDUNDANCY 句または RECOVERY WINDOW 句を DELETE で使用すると 構成済のデフォルトのかわりに特定の保存方針で不要となるバックアップを削除できます DELETE OBSOLETE REDUNDANCY = 3; DELETE OBSOLETE RECOVERY WINDOW OF 7 DAYS; KEEP UNTIL に指定した期限が切れたときの DELETE OBSOLETE の動作 DELETE OBSOLETE を実行する際 一部のバックアップに設定された KEEP UNTIL 期間を超えた場合でも 指定された保存方針を満たすために必要なバックアップは削除されません バックアップが保存方針を満たす必要がある場合 KEEP UNTIL 句の設定にかかわらず Recovery Manager はそのバックアップを不要とみなしません KEEP UNTIL の設定によって バックアップが保存方針で要求される期間より長く保持されることはありますが それより早く不要になることはありません KEEP UNTIL の期間にかかわらず バックアップが保存方針を満たす必要がある場合は そのバックアップは不要にはなりません リカバリ期間ベースの保存方針では KEEP UNTIL に指定した期間を超えても バックアップがリカバリ期間を満たす必要がある場合はそのバックアップは保持されます 冗長性ベースの保存方針では KEEP UNTIL に指定した期間を超えても バックアップが冗長性要件を満たす必要がある場合はそのバックアップは保持されます メンテナンス操作に対する複数の Recovery Manager チャネルの使用 この項では次の項目を取り上げます 複数の Recovery Manager チャネルのメンテナンス コマンドへの割当て 複数のチャネルでの Recovery Manager のクロスチェックおよび削除方法 1 回のコマンドによるディスク チャネルおよびテープ チャネルのクロスチェック : 例 複数の Oracle Real Application Clusters ノードのクロスチェック : 例 1 回の DELETE コマンドによるディスク チャネルおよびテープ チャネルでの削除 : 例 複数のチャネルの解放 : 例 Recovery Manager のメンテナンス作業 8-9

172 メンテナンス操作に対する複数の Recovery Manager チャネルの使用 複数の Recovery Manager チャネルのメンテナンス コマンドへの割当て CROSSCHECK または DELETE コマンドを発行する前に 複数のチャネルを構成するか 手動で割り当てます Recovery Manager は バックアップの作成に使用されたチャネルと同じデバイス タイプのすべてのチャネルのバックアップを検索します マルチチャネル機能の用途は主に 単一のコマンドで ディスク上とテープ上の両方のバックアップをクロスチェックおよび削除することです 複数のチャネルでの Recovery Manager のクロスチェックおよび削除方法 複数のチャネルを構成するか手動で割り当てて CROSSCHECK または DELETE コマンドを実行すると Recovery Manager によって 適切なデバイス タイプを持つすべてのチャネルでクロスチェックまたは削除が実行されます たとえば チャネルを構成するのではなく 手動でチャネルを割り当てることを想定します メディア マネージャは構成されていますが テープへはバックアップされていません 次のように ディスクにデータベースのバックアップを 1 つだけ作成しました RUN { ALLOCATE CHANNEL ch1 DEVICE TYPE DISK CONNECT 'SYS/sys_pwd@node2'; BACKUP DATABASE; } Recovery Manager プロンプトで 次の一連のコマンドを発行したとします ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK CONNECT 'SYS/oracle@node1'; AlLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK CONNECT 'SYS/oracle@node2'; ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt; CROSSCHECK BACKUP OF DATABASE; Recovery Manager リポジトリには ディスクへのデータベースのバックアップのレコードがあるため 2 つのディスク チャネルでアクセス可能なバックアップをクロスチェックします ( また 2 つ目のチャネルでバックアップを検出します ) Recovery Manager リポジトリには sbt バックアップのレコードがないため CROSSCHECK コマンドは 割り当てられた SBT チャネルにアクセスしません 1 回のコマンドによるディスク チャネルおよびテープ チャネルのクロスチェック : 例 ディスクおよびテープ用に複数のチャネルを構成している場合 Recovery Manager はすべての構成済チャネルを使用し 両方のバックアップ先で同時にクロスチェックを行います たとえば sbt チャネルが次のように構成されているとします CONFIGURE DEVICE TYPE sbt PARALLELISM 1; CONFIGURE DEFAULT DEVICE TYPE sbt; この場合 次のコマンドを実行して DISK および sbt の両方でクロスチェックを実行できます CROSSCHECK BACKUP OF DATABASE; Recovery Manager は sbt チャネルおよび事前構成された DISK チャネルの両方を使用してクロスチェックを実行します 出力例は次のとおりです allocated channel: ORA_SBT_TAPE_1 channel ORA_SBT_TAPE_1: sid=12 devtype=sbt_tape channel ORA_SBT_TAPE_1: WARNING: Oracle Test Disk API using channel ORA_DISK_1 crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=/oracle/dbs/16c5esv4_1_1 recid=36 stamp= crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=/oracle/dbs/c recid=37 stamp= Oracle Database バックアップおよびリカバリ基礎

173 メンテナンス操作に対する複数の Recovery Manager チャネルの使用 crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=12c5erb2_1_1 recid=32 stamp= crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=13c5erba_1_1 recid=33 stamp= crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=14c5erce_1_1 recid=34 stamp= crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=c recid=35 stamp= 自動 sbt チャネルが構成されていない場合 次の例のように ディスクおよびテープのメンテナンス チャネルを手動で割り当てることもできます RUN { ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt; CROSSCHECK BACKUP OF DATABASE; } Recovery Manager は事前構成されたディスク チャネルを使用するため ディスク チャネルを手動で割り当てる必要はありません 複数の Oracle Real Application Clusters ノードのクロスチェック : 例 複数ノードでクロスチェックを実行する場合 ( また一般的に Recovery Manager を操作する場合 ) バックアップがどのノードで作成されたかにかかわらず すべてのバックアップがすべてのノードからアクセス可能になるようにクラスタを構成します このようにクラスタを構成すると リストアおよびクロスチェック操作中に クラスタ内の任意のノードでチャネルを割り当てることができます すべてのバックアップが各ノードからアクセス可能になるようにクラスタを構成できない場合は リストアおよびクロスチェック操作中に CONNECT オプションを指定して CONFIGURE CHANNEL コマンドを実行することによって複数のノードにチャネルを割り当て すべてのバックアップが最低でも 1 つのノードからアクセス可能になるようにする必要があります クロスチェック中にいくつかのバックアップにアクセスできない場合 ( それらのバックアップにアクセス可能なノードにチャネルがまったく構成されていないため ) それらのバックアップは クロスチェック後に Recovery Manager リポジトリ内で EXPIRED とマークされます たとえば Oracle Real Application Cluster(RAC) 構成で CONFIGURE CHANNEL...CONNECT... を使用できます この構成では テープ バックアップがクラスタ内の様々なノードで作成され 各バックアップがそれが作成されたノードでのみそれらのバックアップにアクセスできます 次の例では RAC クラスタに 2 つのノードが含まれ 各クラスタには クロスチェックのためにいくつかのバックアップにアクセスするためのチャネルが 1 つ必要であると想定しています 次のようにチャネルを構成します CONFIGURE DEVICE TYPE DISK PARALLELISM 2; CONFIGURE CHANNEL 1 DEVICE TYPE DISK CONNECT 'SYS/oracle@node_1'; CONFIGURE CHANNEL 2 DEVICE TYPE DISK CONNECT 'SYS/oracle@node_2'; 次に 次のコマンドを実行してクラスタ ノードをクロスチェックします CROSSCHECK BACKUP; 1 回の DELETE コマンドによるディスク チャネルおよびテープ チャネルでの削除 : 例 割り当てられたすべてのチャネルで削除を実行することもできます 次の例では sbt チャネルを構成します CONFIGURE DEVICE TYPE sbt PARALLELISM 1; CONFIGURE DEFAULT DEVICE TYPE TO sbt; Recovery Manager のメンテナンス作業 8-11

174 メンテナンス操作に対する複数の Recovery Manager チャネルの使用 次に コマンドを実行して ディスクおよびテープのすべてのバックアップ セットを削除します DELETE BACKUPSET; Recovery Manager は 構成された sbt チャネルおよび事前構成された DISK チャネルの両方を使用して削除を実行します 次の出力例では Recovery Manager は ファイルを削除する前に確認を求めるプロンプトを表示します using channel ORA_SBT_TAPE_1 using channel ORA_DISK_1 List of Backup Pieces BP Key BS Key Pc# Cp# Status Device Type Piece Name AVAILABLE SBT_TAPE 12c5erb2_1_ UNAVAILABLE SBT_TAPE 13c5erba_1_ AVAILABLE SBT_TAPE 14c5erce_1_ AVAILABLE SBT_TAPE c AVAILABLE DISK /oracle/dbs/16c5esv4_1_ AVAILABLE DISK /oracle/dbs/c Do you really want to delete the above objects (enter YES or NO)? y deleted backup piece backup piece handle=/oracle/dbs/16c5esv4_1_1 recid=36 stamp= deleted backup piece backup piece handle=/oracle/dbs/c recid=37 stamp= deleted backup piece backup piece handle=12c5erb2_1_1 recid=32 stamp= deleted backup piece backup piece handle=13c5erba_1_1 recid=33 stamp= deleted backup piece backup piece handle=14c5erce_1_1 recid=34 stamp= deleted backup piece backup piece handle=c recid=35 stamp= 次の例では DISK および sbt のメンテナンス チャネルを手動で割り当てて ディスクおよびテープの両方から特定のバックアップ セットを削除します RUN { ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK; ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt; DELETE BACKUPSET 1,2,3,4,5; } Recovery Manager はチャネル上の特定のバックアップ セットを検索して 検出されたバックアップ セットを削除します チャネル上でバックアップが検出されない場合 Recovery Manager は制御ファイルにあるそのオブジェクトに削除されたことを示すマークを付けて リカバリ カタログ レコードを削除します ( リカバリ カタログを使用している場合 ) 複数のチャネルの解放 : 例 次のコマンドを実行すると 割り当てられたすべてのメンテナンス チャネルを解放できます RELEASE CHANNEL; 8-12 Oracle Database バックアップおよびリカバリ基礎

175 バックアップ レコードの状態の変更 Recovery Manager を使用したデータベースの削除 オペレーティング システムからデータベースを削除する必要がある場合があります たとえば テスト データベースを作成した後 そのテスト データベースは必要なくなります このような場合 Recovery Manager で DROP DATABASE コマンドを使用するか または SQL*Plus で DROP DATABASE 文を使用します DROP DATABASE では マウントされたターゲット データベースに Recovery Manager が接続されている必要があります リカバリ カタログへの接続は必要ありません Recovery Manager をリカバリ カタログに接続した状態でオプション INCLUDE COPIES AND BACKUPS を指定すると Recovery Manager はデータベースも登録解除します 参照 : SQL*PlusDROP DATABASE コマンドの使用方法は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください データベースを削除する方法 1. Recovery Manager をターゲット データベースおよびリカバリ カタログ ( 任意 ) に接続します 次に例を示します rman TARGET / CATALOG rman/rman@catdb 2. データベースに関連するすべてのバックアップをカタログに追加します たとえば 次のコマンドを実行すると フラッシュ リカバリ領域のファイルがカタログに追加され 次に 2 次的なアーカイブ先のファイルがカタログに追加されます RMAN> CATALOG START WITH '+disk1'; # all files from flash recovery area # (stored on ASM disk) RMAN> CATALOG START WITH '/arch_dest2'; # all files from second arch dest 3. データベースに関連するすべてのバックアップおよびコピーを削除します 次に例を示します RMAN> DELETE BACKUPSET; # deletes all backups RMAN> DELETE COPY; # delete all image copies (including archived logs) 4. オペレーティング システムからデータベースを削除します ( カタログに接続している場合 そのデータベースはリカバリ カタログから自動的に登録解除されます ) 次に例を示します DROP DATABASE; # delete all database files and unregister the database バックアップ レコードの状態の変更 この項では次の項目を取り上げます バックアップ状態のマーク付け 保存方針からの長期バックアップの除外 バックアップ状態のマーク付け バックアップが検出されない場合 またはサイト外に移された場合は CHANGE... UNAVAILABLE コマンドを実行します Recovery Manager は RESTORE または RECOVER コマンドでは UNAVAILABLE のマークの付いたファイルを使用しません ファイルが後で検出された場合 またはメイン サイトに戻された場合は CHANGE... AVAILABLE を発行して再度使用可能であることを示すマークを付けます フラッシュ リカバリ領域内のファイルを UNAVAILABLE にマークすることはできません Recovery Manager のメンテナンス作業 8-13

176 バックアップ レコードの状態の変更 リポジトリのファイルの状態に UNAVAILABLE または AVAILABLE のマークを付ける方法 1. LIST コマンドを発行して Recovery Manager バックアップの可用性の状態を確認します 次に例を示します LIST BACKUP; 2. UNAVAILABLE または AVAILABLE キーワードを指定して CHANGE を実行し Recovery Manager リポジトリの状態を更新します 次に例を示します CHANGE DATAFILECOPY '/tmp/control01.ctl' UNAVAILABLE; CHANGE COPY OF ARCHIVELOG SEQUENCE BETWEEN 1000 AND 1012 UNAVAILABLE; CHANGE BACKUPSET 12 UNAVAILABLE; CHANGE BACKUP OF SPFILE TAG "TAG T154556" UNAVAILABLE; CHANGE DATAFILECOPY '/tmp/system01.dbf' AVAILABLE; CHANGE BACKUPSET 12 AVAILABLE; CHANGE BACKUP OF SPFILE TAG "TAG T154556" AVAILABLE; 参照 : CHANGE コマンドの構文の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください 保存方針からの長期バックアップの除外 BACKUP... KEEP コマンドを使用すると 構成済みの保存方針とは異なる期間 バックアップを保持できます ただし バックアップは完全に有効で 他の Recovery Manager バックアップと同様にリストアできます このタイプのバックアップは長期バックアップ長期バックアップと呼ばれます 注意 : 制御ファイルには Recovery Manager リポジトリの大規模なデータ セットを無限に含めることはできないため KEEP FOREVER 句を使用する場合は リカバリ カタログを使用する必要があります 不完全リカバリ用にアーカイブ ログを保存する場合は KEEP... LOGS を指定し 保存しない場合は KEEP... NOLOGS を指定します NOLOGS は 非一貫性バックアップでは無効です 既存のバックアップの KEEP 状態を変更するには CHANGE コマンドを使用します たとえば 長期バックアップを保持する必要のない場合にこのコマンドを使用します BACKUP... KEEP で使用できるオプションを CHANGE... KEEP でも使用できます フラッシュ リカバリ領域に格納されているファイルには KEEP 属性を設定できないことに注意してください バックアップの KEEP 状態を変更する方法 CHANGE... KEEP を発行して保存方針とは異なる保存期間を定義するか CHANGE... NOKEEP を発行して保存方針をこのファイルに適用します 次の例では 保存方針に基づいてバックアップ セットに不要のマークが付けられます CHANGE BACKUPSET 231 NOKEEP; 次の例では データ ファイルのコピーを保存方針から 180 日 (6 か月 ) の間除外します CHANGE DATAFILECOPY '/tmp/system01.dbf' KEEP UNTIL 'SYSDATE+180'; 注意 : KEEP UNTIL を使用してバックアップが保持される期間の最小値を指定した場合 保存方針を満たすためにそのバックアップが必要であれば 指定した期間より長くそのバックアップが保持される可能性があります Recovery Manager の DELETE OBSOLETE コマンドを実行する際 KEEP UNTIL を使用してバックアップが保持される期間の最小値を設定した場合でも 保存方針を満たすためにそのバックアップが必要な場合は削除されません 8-14 Oracle Database バックアップおよびリカバリ基礎

177 アーカイブ ログおよびユーザー管理コピーのカタログへの追加 アーカイブ ログおよびユーザー管理コピーのカタログへの追加 Recovery Manager 以外の方法を使用して作成されたファイルおよびバックアップ ピースのコピーと同様に リポジトリに記録されていないアーカイブ ログが存在することを Recovery Manager に認識させることができます この項では次の項目を取り上げます アーカイブ ログおよびユーザー管理コピーのカタログへの追加 ユーザー管理データ ファイルのコピーのカタログへの追加 バックアップ ピースのカタログへの追加 ディスクの場所にあるすべてのファイルのカタログへの追加 アーカイブ ログおよびユーザー管理コピーのカタログへの追加 ターゲット データベースの制御ファイルは ターゲット データベースによって生成されたすべてのアーカイブ ログのレコードと すべての Recovery Manager バックアップを保持します CATALOG コマンドを実行すると Recovery Manager に認識させたいファイルのレコードが存在しない場合に メタデータをリポジトリに追加できます 次の場合に Recovery Manager の CATALOG コマンドを実行します データ ファイル アーカイブ ログまたはバックアップ ピースのコピーを作成するために オペレーティング システムのユーティリティを使用する場合 この場合 リポジトリにはこれらのレコードは存在しません バックアップ制御ファイルを使用してリカバリを実行し リカバリ中のアーカイブ先または形式を変更する場合 この状況では リカバリに必要なアーカイブ ログに関する情報はリポジトリには含まれません したがって これらのログをカタログに追加する必要があります データ ファイルのコピーをレベル 0 のバックアップとしてカタログに追加する場合 これによって 後で増分バックアップ方法の基礎となるデータ ファイルのコピーを使用して増分バックアップを実行できるようになります 新しいリリースに移行する前に作成された Oracle7 のデータベース ファイルのユーザー管理コピー または Recovery Manager を使用する前に作成された Oracle8 以上のデータベース ファイルのユーザー管理コピーをカタログに追加する場合 これらのデータ ファイルのコピーによって 移行したデータベースのバックアップを取る前にデータベースがクラッシュしたときにデータベースをリカバリできます UNIX の cp コマンドを使用したデータ ファイルのコピーなど ユーザー管理コピーを作成するときには必ずカタログに追加してください ユーザー管理コピーを作成する場合 ALTER TABLESPACE... BEGIN/END BACKUP 文を使用してオンライン表領域のデータ ファイルのコピーを作成できます Recovery Manager はこのようなデータ ファイルのコピーを作成しませんが CATALOG コマンドを使用してデータ ファイルのコピーをリカバリ カタログに追加し Recovery Manager に認識させることができます ユーザー管理コピーをカタログに追加する場合は 次のものが必要です ディスクのアクセス性 1 つのファイルの完全なイメージ コピー データ ファイル 制御ファイル アーカイブ REDO ログまたはバックアップ ピースのいずれかのコピー たとえば ミラー化されたディスク ドライブ上にデータ ファイルを格納する場合 ミラー化を解除することによって ユーザー管理コピーを作成できます この場合 ミラー化を解除した後に CATALOG コマンドを使用してユーザー管理コピーが存在することを Recovery Manager に通知します 再度ミラー化する前に CHANGE... UNCATALOG コマンドを実行してファイルのコピーが存在しないことを Recovery Manager に通知します Recovery Manager のメンテナンス作業 8-15

178 アーカイブ ログおよびユーザー管理コピーのカタログへの追加 ユーザー管理データ ファイルのコピーのカタログへの追加 CATALOG コマンドを使用して ユーザー管理コピーに関する情報を Recovery Manager リポジトリに伝播します ファイルがカタログに追加されたら LIST を実行するか V$BACKUP_ FILES を問い合せて確認します データ ファイルのユーザー管理コピーを作成してカタログに追加する方法 1. データ ファイルのコピーをオペレーティング システムのユーティリティで作成します バックアップの処理中に データベースがオープンになっており データ ファイルがオンラインになっている場合 ALTER TABLESPACE BEGIN/END BACKUP を実行する必要があります この例では オンライン データ ファイルをバックアップします SQL> ALTER TABLESPACE users BEGIN BACKUP; % cp $ORACLE_HOME/oradata/trgt/users01.dbf /tmp/users01.dbf; SQL> ALTER TABLESPACE users END BACKUP; 2. ターゲット データベースおよびリカバリ カタログ ( 必要な場合 ) に接続して CATALOG コマンドを実行します 次に例を示します CATALOG DATAFILECOPY '/tmp/users01.dbf'; 接続したターゲット データベース以外のデータベースからのデータ ファイルのコピーをカタログに追加しようとすると 次のようなエラーが表示されます RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of catalog command on default channel at 08/29/ :44:34 ORA-19563: datafile copy header validation failed for file /tmp/tools01.dbf 参照 : CATALOG コマンドの構文の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください バックアップ ピースのカタログへの追加 ディスク上のバックアップ ピースをカタログに追加できます この方式は オペレーティング システムのユーティリティを使用して ある場所から同じホストの別の場所へ またはあるホストから別のホストへバックアップ ピースをコピーする場合に有効です 以前のインカネーションのデータベースからバックアップ ピースのカタログを追加することもできます Recovery Manager は 後続のリストアおよびリカバリ操作時にバックアップ ピースを使用できるかどうかを決定できます バックアップ ピースをカタログに追加する方法 1. Recovery Manager をターゲット データベースに接続してから バックアップ ピースのファイル名をカタログに追加します 次に例を示します CATALOG BACKUPPIECE '/disk2/09dtq55d_1_2', '/disk2/0bdtqdou_1_1'; バックアップ ピースをカタログに追加した後 V$BACKUP_PIECE V$BACKUP_SET V$BACKUP_DATAFILE V$BACKUP_REDOLOG および V$BACKUP_SPFILE を問い合せることによってメタデータを表示できます 8-16 Oracle Database バックアップおよびリカバリ基礎

179 アーカイブ ログおよびユーザー管理コピーのカタログへの追加 注意 : Oracle9i より前のリリースからバックアップ ピースをカタログに追加する場合は 最も大きい番号のコピーを最初にカタログに追加することによって 大幅なパフォーマンスの向上を実現できます そうでない場合は Recovery Manager はすべてのピースを検証して正しい順序を決定します たとえば コピー 2 の前にコピー 3 のピースをカタログに追加します CATALOG BACKUPPIECE '/disk2/09dtq55d_1_3', '/disk2/09dtq55d_1_2'; Oracle Database 10g からのバックアップ ピースはこの問題の影響を受けることはなく 任意の順序でカタログに追加することができます 2. V$ ビューを問い合せて 変更を確認できます 次に例を示します SELECT HANDLE FROM V$BACKUP_PIECE; 参照 : CATALOG BACKUPPIECE の制限の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照してください ディスクの場所にあるすべてのファイルのカタログへの追加 自動ストレージ管理 (ASM) Oracle Managed Files のフレームワークまたはフラッシュ リカバリ領域を使用する場合は ディスクの管理システムには認識されているが Recovery Manager リポジトリには表示されていないファイルを再度カタログに追加する必要があります この状況は メディア障害 ソフトウェアの不具合またはユーザー エラーのためにファイル名を追跡するメカニズムが失敗したときに発生する場合があります CATALOG START WITH コマンドを使用すると ASM ディスク グループ Oracle Managed Files または従来のファイル システム ディレクトリにあるすべてのファイルを検索して Recovery Manager リポジトリに記録されていないファイルを調べることができます このコマンドでファイルをカタログに追加できる場合 ファイルはカタログに追加されます このコマンドでファイルをカタログに追加できない場合は スキップしたファイルに最も近い内容が推測されます ディスクの場所にあるすべてのファイルをカタログへ追加する手順 Recovery Manager をターゲット データベースに接続してから カタログに追加するファイルのディスクの場所を指定します 次に例を示します RMAN> CATALOG START WITH '+disk'; # catalog all files from an ASM disk group RMAN> CATALOG START WITH '/fs1/datafiles/'; # catalog all files in directory 注意 : START WITH 句では ワイルド カードは正しく使用できません フラッシュ リカバリ領域の内容のカタログへの追加 CATALOG RECOVERY AREA コマンドを実行すると フラッシュ リカバリ領域のすべてのファイルがカタログに追加されます この操作中 Recovery Manager リポジトリにリストされないリカバリ領域内のすべてのファイルは Recovery Manager リポジトリに追加されます 次に例を示します CATALOG RECOVERY AREA; Recovery Manager のメンテナンス作業 8-17

180 Recovery Manager レコードのカタログからの削除 Recovery Manager レコードのカタログからの削除 この項では次の項目を取り上げます Recovery Manager レコードのカタログからの削除 オペレーティング システムのユーティリティを使用して削除したファイルのレコードの削除 Recovery Manager レコードのカタログからの削除 CHANGE... UNCATALOG コマンドを実行すると Recovery Manager リポジトリのレコードに次の処理を実行します 制御ファイル リポジトリのバックアップ レコードを DELETED 状態に更新します リカバリ カタログ ( 使用している場合 ) から指定したバックアップ レコードを削除します Recovery Manager は 指定した物理ファイルは変更しません ファイルのリポジトリ レコードのみを変更します このコマンドは Recovery Manager 以外の方法でバックアップを削除した場合に使用できます たとえば オペレーティング システムのユーティリティを使用してアーカイブ REDO ログを削除した場合 CHANGE ARCHIVELOG... UNCATALOG を発行することによってリポジトリからこのログのレコードを削除します オペレーティング システムのユーティリティを使用して削除したファイルのレコードの削除 オペレーティング システムのユーティリティを使用して削除したファイルのカタログ レコードを削除するには CHANGE... UNCATALOG コマンドを実行します オペレーティング システムのユーティリティを使用して削除したバックアップのカタログ レコードを削除する方法 1. オペレーティング システムのコマンドを使用してオペレーティング システムから削除したバックアップに対して CHANGE... UNCATALOG を実行します 次の例では 制御ファイルおよびデータ ファイル 1 のディスク コピーへのリポジトリの参照を削除します CHANGE CONTROLFILECOPY '/tmp/control01.ctl' UNCATALOG; CHANGE DATAFILECOPY '/tmp/system01.dbf' UNCATALOG; 2. 任意で 関連するリカバリ カタログ ビュー (RC_DATAFILE_COPY RC_ CONTROLFILE_COPY など ) を参照して 指定したレコードが削除されたことを確認します たとえば 次の問合せによって コピー 4833 のレコードが削除されたことを確認します SELECT CDF_KEY, STATUS FROM RC_DATAFILE_COPY WHERE CDF_KEY = 4833; CDF_KEY STATUS rows selected Oracle Database バックアップおよびリカバリ基礎

181 フラッシュ リカバリ領域のメンテナンス フラッシュ リカバリ領域のメンテナンス フラッシュ リカバリ領域は自己管理されていますが DBA の介入が必要な場合があります フラッシュ リカバリ領域が一杯になった場合の解決方法 削除対象のファイルがない場合にフラッシュ リカバリ領域が一杯になるという状態を解決するいくつかの方法があります ディスク領域を追加し DB_RECOVERY_FILE_DEST_SIZE を増加して 新しい領域に反映します バックアップをフラッシュ リカバリ領域からテープなどの 3 次デバイスに移動します フラッシュ リカバリ領域のすべてのファイルをテープに 1 回でバックアップする簡単な方法の 1 つに BACKUP RECOVERY AREA コマンドがあります バックアップをフラッシュ リカバリ領域からテープに転送した後 Recovery Manager の DELETE コマンドの形式を使用し フラッシュ リカバリ領域からファイルを削除することで フラッシュ リカバリ領域全体の状態を解決できます 注意 : 設計上 フラッシュバック ログはフラッシュ リカバリ領域以外にバックアップできません したがって BACKUP RECOVERY AREA 操作では フラッシュバック ログはテープにバックアップされません フラッシュバック ログは フラッシュ リカバリ領域内の他のファイルの領域を確保するために自動的に消去されます ただし 保証付きリストア ポイントを使用すると データベースをリストア ポイント SCN までフラッシュバックするために必要なフラッシュバック ログを強制的に保持できます Recovery Manager の DELETE コマンドを使用して フラッシュ リカバリ領域から不要なファイルを削除します ( ホスト オペレーティング システムのコマンドを使用してファイルを削除しても データベースでは 削除した結果できる空き領域が認識されないことに注意してください Recovery Manager の CROSSCHECK コマンドを使用して フラッシュ リカバリ領域の内容を再確認し 期限切れのファイルを特定した後 DELETE EXPIRED コマンドを使用して Recovery Manager リポジトリから欠落しているファイルを削除できます ) また バックアップ保存方針の変更について考慮する必要があります Data Guard を使用している場合は アーカイブ ログの削除方針の変更についても考慮する必要があります 参照 : 保存方針の決定方法については第 4 章 Recovery Manager を使用したデータベースのバックアップ Data Guard 使用時のアーカイブ ログの削除方針については Oracle Data Guard 概要および管理 を参照してください フラッシュ リカバリ領域の位置の変更 データベースのフラッシュ リカバリ領域を新しい位置に移動する必要がある場合は 次の手順に従います 1. SQL*Plus を起動して DB_RECOVERY_FILE_DEST 初期化パラメータを変更します 次に例を示します ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+disk1' SCOPE=BOTH SID='*'; このパラメータを変更すると 新しいフラッシュ リカバリ領域のすべてのファイルは新しい位置に作成されます Recovery Manager のメンテナンス作業 8-19

182 フラッシュ リカバリ領域のメンテナンス 2. 永続ファイル ( 制御ファイルおよびオンライン REDO ログ ファイル ) フラッシュバック ログおよび一時ファイルは フラッシュ リカバリ領域の以前の位置に残る場合があります フラッシュ リカバリ領域の以前の場所に残っている一時ファイルは 削除対象であるとみなされて削除されます 実際に現行の永続ファイル 一時ファイルまたはフラッシュバック ログを新しいフラッシュ リカバリ領域に移動する必要がある場合は Oracle Database バックアップおよびリカバリ アドバンスト ユーザーズ ガイド を参照してください そのマニュアルでは Recovery Manager を使用して ASM ディスク グループとの間でデータ ファイルを移動する処理について説明しています この処理は フラッシュ リカバリ領域との間でファイルを移動する際にも有効です 参照 : A-8 ページの フラッシュ リカバリ領域およびテープへのバックアップ : 基本的な例 フラッシュ リカバリ領域の以前の場所に残っている永続ファイルは 削除対象とみなされて削除されます ファイル作成時にインスタンスがクラッシュした場合のフラッシュ リカバリ領域の動作 通常 フラッシュ リカバリ領域は自己管理されていますが フラッシュ リカバリ領域でファイルを作成中にインスタンスがクラッシュすると フラッシュ リカバリ領域にファイルが残される場合があります このような場合 アラート ログに次のようなメッセージが表示されます ORA-19816: WARNING: Files may exist in location that are not known to database. location はフラッシュ リカバリ領域の位置です この場合 Recovery Manager コマンド CATALOG RECOVERY AREA を使用して 該当するファイルを Recovery Manager リポジトリに存在するように再度カタログに追加する必要があります 問題のファイルのファイル ヘッダーが破損している場合は オペレーティング システム レベルのユーティリティを使用して 手動でファイルを削除する必要があります 8-20 Oracle Database バックアップおよびリカバリ基礎

183 A Recovery Manager ベースのディスクおよびテープのバックアップ計画の例 この付録では Recovery Manager 増分更新バックアップおよびフラッシュ リカバリ領域を効果的に使用する ディスクのみのバックアップ計画およびディスクとテープベースのバックアップ計画のいくつかについて説明します この付録では 次の項目について説明します フラッシュ リカバリ領域へのバックアップ : 基本的な例 フラッシュ リカバリ領域およびテープへのバックアップ : 基本的な例 Recovery Manager ベースのディスクおよびテープのバックアップ計画の例 A-1

184 フラッシュ リカバリ領域へのバックアップ : 基本的な例 フラッシュ リカバリ領域へのバックアップ : 基本的な例 次に示すすべての例では Recovery Manager 環境およびフラッシュ リカバリ領域が 3-20 ページの ディスク ベースのバックアップ用のフラッシュ リカバリ領域の構成 : 例 のように構成されていることを前提としています ディスク専用バックアップのスクリプト作成 バックアップ スクリプトの動作の詳細は データベースの負荷および割り当てられているディスク領域の量に依存します 次のスクリプトは データベースの更新パターン およびディスク上のリカバリ期間のアーカイブに必要なフラッシュ リカバリ領域に割り当てられた最小限のディスク領域に基づいて分類できます 少数のデータベース ブロックが変更される場合 増分バックアップのサイズは データベースのサイズより大幅に小さくなります この場合 ディスク領域と他のリソースを有効に利用するために 増分バックアップが最適なバックアップ方法です ほとんどまたはすべてのデータベース ブロックが頻繁に変更される場合 増分バックアップのサイズは データベースのサイズと同等に大きくなります この場合 データベースの完全なイメージ コピーを定期的に作成することが最適なバックアップ方法です 次の例では アーカイブ ログのバックアップは必要ありません これらのログは Oracle がフラッシュ リカバリ領域にアーカイブするためです アーカイブ ログは 保存方針で必要とされる間は フラッシュ リカバリ領域に残ります また すべてのデータベース バックアップもフラッシュ リカバリ領域に保存されます この項では次の項目を取り上げます 少数のデータ ブロックが変更される場合のバックアップ スクリプト ブロックが頻繁に変更される場合のバックアップ スクリプト 半数のブロックが毎週変更される場合のバックアップ スクリプト 少数のデータ ブロックが変更される場合のバックアップ スクリプト 毎日変更されるデータ ブロックが少数の場合 増分バックアップのサイズは小さくなるので 毎日の増分バックアップを実行する計画を変更できます 初期設定ディスク上のフラッシュ リカバリ領域の推奨最小サイズは バックアップの頻度と使用される保存方針によって異なります 構成済の保存方針が REDUNDANCY X で Y 日ごとにバックアップを取る場合は フラッシュ リカバリ領域の推奨ディスク割当て制限を求める式は 次のようになります Disk Quota = Size of X copies of database + Size of one copy of incremental backups + Size of (Y+1) days of archived logs 保存方針を X 日のリカバリ期間に設定し バックアップ スクリプトを Y 日ごとに実行する場合 次のいずれかの式で必要なディスク割当て制限を計算できます X>=Y の場合 フラッシュ リカバリ領域の推奨ディスク割当て制限を求める式は 次のとおりです Disk Quota = Size of one copy of database + Size of (floor(x/y) + 1) copies of incremental backups + Size of (X * ceil(x/y) +1) days of archived logs この場合 ceil(x/y) は X/Y 以上の最小整数で floor(x/y) は X/Y 以下の最大整数です A-2 Oracle Database バックアップおよびリカバリ基礎

185 フラッシュ リカバリ領域へのバックアップ : 基本的な例 X <Y の場合 推奨値を求める式は次のとおりです Disk Quota = Size of one copy of database + Size of 2 copies of incremental backups + Size of (Y +1) days of archived logs 適切な方の式に従って フラッシュ リカバリ領域のサイズを求めます 次の例では 保存方針が REDUNDANCY 1 であると想定しています RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 1; また バックアップを毎日実行することを想定しています 毎日実行するスクリプト毎日バックアップを実行するためのスクリプトは 次のようになります RMAN> RECOVER COPY OF DATABASE WITH TAG "whole_db_copy"; # Make an incremental backup of the database to the flash recovery area. RMAN> BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG "whole_db_copy" DATABASE; このバックアップ方法の 1 日目の時点で "whole_db_copy" というタグが付けられたバックアップが存在しないとします このスクリプトの実行結果は次のとおりです 1 日目 RECOVER 文は 処理を実行しません BACKUP... FOR RECOVER OF COPY は レベル 0 の初期データベースのコピーを作成します 2 日目も レベル 0 の増分データベースのコピーに適用するレベル 1 の増分バックアップが存在しないため RECOVER 文は 何も処理を実行しません BACKUP コマンドは レベル 1 の最初の増分バックアップを作成します 3 日目以降は 前日からのレベル 1 の増分がレベル 0 のデータベースのコピーに適用され 前日のレベル 1 の増分の時刻までロールフォワードされます また レベル 1 の新しい増分が作成され 前日のレベル 1 の増分バックアップの後 行われたすべての変更が含められます このバックアップ計画は 2 月 1 日に有効になります 次の表に この計画の結果 フラッシュ リカバリ領域の内容がどのように変化するかを示します ( フラッシュ リカバリ領域には 他のバックアップ操作に基づく他のファイルも含まれます 次の表では このバックアップ計画に関連するファイルについてのみ示します ) 表 A-1 少数のデータ ブロックが変更される場合のバックアップ : バージョン 1 日付 スクリプトの処理 スクリプト実行後のフラッシュ リカバリ領域の内容 2 月 1 日 ( 日 ) 2 月 2 日 ( 月 ) 1. 増分更新を試行しますが レベル 0 のバックアップが存在しないため 処理は実行されません 2. レベル 0 のバックアップを作成します 1. 増分更新を試行しますが レベル 1 の増分が存在しないため 処理は実行されません 2. レベル 1 の増分をバックアップします 2 月 1 日日曜日の時点での SCN を持つレベル 0 のイメージ コピーの増分バックアップ 2 月 1 日日曜日の時点での SCN を持つレベル 0 のイメージ コピーの増分バックアップ 2 月 1 日 ~ 2 日の変更を含むレベル 1 の増分バックアップ 2 月 1 日から今日までのアーカイブ ログ Recovery Manager ベースのディスクおよびテープのバックアップ計画の例 A-3

186 フラッシュ リカバリ領域へのバックアップ : 基本的な例 表 A-1 少数のデータ ブロックが変更される場合のバックアップ : バージョン 1( ( 続き ) スクリプト実行後のフラッシュ リカバリ領域日付スクリプトの処理の内容 2 月 3 日以降 1. レベル 0 の増分更新を実行し 前日までロールフォワードします 2. レベル 1 の増分をバックアップします 前日のレベル 1 の SCN までロールフォワードされたレベル 0 のイメージ コピーの増分バックアップ 過去 24 時間の変更を含むレベル 1 の増分バックアップ 2 月 1 日から今日までのアーカイブ ログロールフォワードされたレベル 0 のバックアップのリカバリには有効でない古い増分バックアップおよびアーカイブ ログは フラッシュ リカバリ領域が不足した時点で自動的に削除されます 例を変更する場合 (n 日分 (n > 1) のアーカイブ ログと増分バックアップを保持できるように フラッシュ リカバリ領域のサイズを変更する場合 ) は RECOVER 行を RECOVER COPY UNTIL TIME 'SYSDATE-n' に変更します たとえば フラッシュ リカバリ領域が 3 日分の増分バックアップを保持できる大きさの場合 スクリプトを次のように変更できます RECOVER COPY OF DATABASE TAG "whole_db_copy" UNTIL TIME 'SYSDATE-3'; # Make an incremental backup of the database to the flash recovery area. BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG "whole_db_copy" DATABASE; 毎日スクリプトを実行すると Recovery Manager は 現在から 3 日前の SCN までデータベース全体のコピーをロールフォワードします つまり ディスク割当て制限規則によって SYSDATE-3 日後に作成されたアーカイブ ログと増分バックアップは保持されます ( これは 過去 3 日の SCN までデータベースをリカバリするために必要なためです ) 次の表に この計画で毎日スクリプトを実行した後 フラッシュ リカバリ領域に格納されるファイルを示します 表 A-2 少数のデータ ブロックが変更される場合のバックアップ : 3 日間のバックアップ 日付 スクリプトの処理 フラッシュ リカバリ領域の内容 2 月 1 日 ( 日 ) 2 月 2 日 ( 月 ) 1. レベル 0 のバックアップの増分更新を試行しますが SYSDATE-3 までロールフォワードする必要がある古いレベル 0 のバックアップが存在しないため 何の影響も及ぼされません 2. レベル 0 のバックアップを作成します 1. レベル 0 のバックアップの増分更新を試行しますが SYSDATE-3 までロールフォワードする必要がある古いレベル 0 のバックアップが存在しないため 何の影響も及ぼされません 2. 2 月 2 日の変更に対するレベル 1 の増分バックアップを作成します 2 月 1 日からのレベル 0 のバックアップ 2 月 1 日からのレベル 0 のバックアップ 2 月 2 日からの変更を含むレベル 1 のバックアップおよび 2 月 1 日から今日までのアーカイブ ログ A-4 Oracle Database バックアップおよびリカバリ基礎

187 フラッシュ リカバリ領域へのバックアップ : 基本的な例 表 A-2 少数のデータ ブロックが変更される場合のバックアップ : 3 日間のバックアップ ( 続き ) 日付 2 月 3 日 ( 火 ) 2 月 4 日 ( 水 ) 2 月 5 日 ( 木 ) スクリプトの処理 1. レベル 0 のバックアップの増分更新を試行しますが SYSDATE-3 までロールフォワードする必要がある古いレベル 0 のバックアップが存在しないため 何の影響も及ぼされません 2. 2 月 3 日の変更に対するレベル 1 の増分バックアップを作成します 1. レベル 0 のバックアップの増分更新を試行しますが SYSDATE-3 までロールフォワードする必要がある古いレベル 0 のバックアップが存在しないため 何の影響も及ぼされません 2. 2 月 4 日の変更に対するレベル 1 の増分バックアップを作成します 1. レベル 0 のバックアップを 2 月 2 日までロールフォワードする レベル 0 のバックアップの増分更新を試行します 2. 2 月 5 日の変更に対するレベル 1 の増分バックアップを作成します フラッシュ リカバリ領域の内容 レベル 0 のバックアップ 2 月 2 日 ~ 3 日のレベル 1 の増分バックアップおよび 2 月 1 日 ~ 3 日のアーカイブ ログ レベル 0 のバックアップ 2 月 2 日から今日までのレベル 1 のバックアップおよび 2 月 1 日から今日までのアーカイブ ログ 2 月 2 日までロールフォワードされたレベル 0 のバックアップ 2 月 3 日から今日までのレベル 1 のバックアップおよび 2 月 2 日から今日までのアーカイブ ログ 2 月 6 日以降 1. レベル 0 のバックアップを 2 月 3 日までロールフォワードする レベル 0 のバックアップの増分更新を試行します 2. その日に行われた変更に対するレベル 1 の増分バックアップを作成します 過去 3 日間のレベル 1 のバックアップまでロールフォワードされたレベル 0 のバックアップ 2 月 1 日から今日までのアーカイブ ログロールフォワードされたレベル 0 のバックアップのリカバリには有効でない古い増分バックアップおよびアーカイブ ログは フラッシュ リカバリ領域が不足した時点で自動的に削除されます ブロックが頻繁に変更される場合のバックアップ スクリプト 一般的な CRM 環境の例では 1 週間で多数またはほとんどのデータ ブロックが更新されます 冗長性 X という保存方針と Y 日ごとに実行されるバックアップ スクリプトを使用する場合 ディスク割当て制限の最小値は 次の式で判断できます Disk Quota = Size of X copies of the database + size of Y days of archived redo logs リカバリ期間 X 日という保存方針と Y 日ごとに実行されるバックアップ スクリプトを使用する場合 X>=Y であれば 次の式でディスク割当て制限を判断できます Disk Quota = Size of 1 copy of the database + size of ((X * ceil(x/y)) +1) days of archived redo logs この場合 ceil(x/y) は X/Y 以上の最小整数です Recovery Manager ベースのディスクおよびテープのバックアップ計画の例 A-5

188 フラッシュ リカバリ領域へのバックアップ : 基本的な例 X<Y の場合のディスク割当て制限は X=Y の場合と同じです つまり 次のようになります Disk Quota = Size of 1 copy of the database + size of (Y +1) days of archived redo logs 次の例では 保存方針が REDUNDANCY 1 で バックアップ スクリプトを毎週実行すると想定しています この例のディスク割当て制限の最小値は次のようになります Disk Quota = Size of 1 copy of the database + size of 8 days of archived logs この例では 初期設定スクリプトは必要ありません 次に 毎週実行するバックアップ スクリプトの例を示します # Execute once a week # Make a full backup of the database to the flash recovery area. BACKUP DATABASE TAG "weekly_full_bkup"; 次の表に示すとおり データベースのレベル 0 のコピーと 1 週間分のアーカイブ ログを保持するディスク割当て制限が必要です 表 A-3 ほとんどのブロックが変更される場合のバックアップ 日付 2 月 1 日 ( 日 ) 処理 レベル 0 をバックアップします フラッシュ リカバリ領域の内容全体バックアップ 2 月 8 日 ( 日 ) 以降の各日曜日 レベル 0 をバックアップします レベル 0 をバックアップします 今日からの全体バックアップ 2 月 1 日 ~ 8 日のアーカイブ ログ この日曜日からの全体バックアップ 前回の日曜日からこの日曜日までのアーカイブ ログ 半数のブロックが毎週変更される場合のバックアップ スクリプト 約半数のデータ ブロックが毎週変更される場合 または変更されるデータ ブロックの数が週ごとに大きく異なる場合に この計画を使用します この計画で実行するスクリプトは 増分更新バックアップを使用する汎用スクリプトです 最初に データベースのイメージ コピーを作成し 定期的にレベル 1 の増分バックアップを取り レベル 0 の既存のコピーをロールフォワードします フラッシュ リカバリ領域に必要な領域を求める式は 保存方針によって異なります 保存方針が REDUNDANCY X で Y 日ごとに実行するバックアップ スクリプトの場合 必要なディスク領域は次のとおりです Disk Quota = Size of X copies of the database + Size of 1 incremental backup + Size of Y+1 days of archived redo logs リカバリ期間が X 日で Y 日ごとに実行するバックアップ スクリプトの場合 X>=Y であれば 必要な領域は次のとおりです Disk Quota = Size of 1 copy of the database + Size of floor(x/y)+1 incremental backups + Size of (X * ceil(x/y)) + 1 days of archived logs この場合 ceil(x/y) は X/Y 以上の最小整数で floor(x/y) は X/Y 以下の最大整数です X<Y の場合に必要な領域は X=Y の場合と同じです Disk Quota = Size of 1 copy of the database + Size of 2 incremental backups + Size of Y+1 days of archived logs 次の例では 保存方針が REDUNDANCY 1 で バックアップ スクリプトを毎週実行すると想定しています A-6 Oracle Database バックアップおよびリカバリ基礎

189 フラッシュ リカバリ領域へのバックアップ : 基本的な例 初期設定この例のディスク割当て制限の最小値は次のようになります Disk Quota = Size of 1 copy of the database + Size of 1 incremental backup + Size of 8 days of archived logs 1 週目 BACKUP... FOR RECOVER OF COPY コマンドは データベースのレベル 0 の増分バックアップをフラッシュ リカバリ領域に作成します このバックアップは 毎週の計画の基本になります 2 週目以降 このコピーが 最後の増分バックアップのチェックポイント時間までロールフォワードされます このようにして ディスク上で行う 1 週間のリカバリ期間を作成します 毎週実行するスクリプト初期設定の後 毎週実行するバックアップ スクリプト ( 毎週 日曜日の夜に実行するなど ) は 次のようになります # Execute once a week # Roll forward the whole copy of the database to last incremental backup SCN RECOVER COPY OF DATABASE TAG "whole_db_copy"; # Make an incremental backup of the database to the flash recovery area. BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG "whole_db_copy" DATABASE; 次の表に バックアップ スクリプトを実行するたびに フラッシュ リカバリ領域の内容がどのように変化するかを示します ここでは 常に 十分なアーカイブ ログとバックアップを保存して 7 日間のリカバリ期間を保持します 表 A-4 半数のブロックが変更される場合のバックアップ 日付 処理 スクリプト実行後のフラッシュ リカバリ領域の内容 2 月 1 日 ( 日 ) 2 月 8 日 ( 日 ) 1. "whole_db_copy" というタグが付けられたデータベースのレベル 0 の増分コピーをロールフォワードしますが レベル 0 のコピーが存在しないため 失敗します 2. レベル 0 の増分バックアップを作成します 1. 前の週のレベル 1 の増分バックアップを使用して "whole_db_copy" というタグが付けられたデータベースのレベル 0 の増分コピーをロールフォワードしますが 前の週からのレベル 1 のバックアップが存在しないため 失敗します 2. レベル 1 の増分バックアップを作成します レベル 0 のバックアップ 2 月 1 日日曜日からのレベル 0 のバックアップ ( レベル 1 が存在しないため ロールフォワードされない ) 2 月 1 日 ~ 8 日のアーカイブ ログ Recovery Manager ベースのディスクおよびテープのバックアップ計画の例 A-7

190 フラッシュ リカバリ領域およびテープへのバックアップ : 基本的な例 表 A-4 半数のブロックが変更される場合のバックアップ ( 続き ) スクリプト実行後のフラッシュ リカバリ領域の日付処理内容 以降の日曜日 1. データベースのレベル 0 のコピーをレベル 1 の最新の増分バックアップの SCN までロールフォワードします 2. レベル 1 の最後の増分バックアップの SCN からの変更を含むレベル 1 の増分バックアップを作成します 前回の日曜日のレベル 1 の増分の SCN までロールフォワードされたレベル 0 のバックアップ 前回の日曜日から今日までのアーカイブ ログ前回の日曜日より前のアーカイブ ログおよび前の週のレベル 1 の増分バックアップは レベル 0 のバックアップのロールフォワード後 廃棄されます これは それらを適用できるバックアップが存在しないためです 不要なファイルは ディスク領域が不足したときにデータベースによって削除されるまで または DELETE OBSOLETE コマンドが使用されるまで フラッシュ リカバリ領域に残ります フラッシュ リカバリ領域およびテープへのバックアップ : 基本的な例 ここでは Recovery Manager を使用して フラッシュ リカバリ領域にバックアップを作成した後 それらをテープに移動する方法について説明します この項で実行するスクリプトは フラッシュ リカバリ領域をログのアーカイブ先およびすべてのディスク バックアップ先として使用します つまり フラッシュ リカバリ領域にアーカイブ ログまたはバックアップを作成するための領域がない場合は Oracle が 不要またはテープに移動されたアーカイブ ログおよびバックアップを自動的に削除します バックアップ ファイルおよびアーカイブ REDO ログをテープに移動すると フラッシュ リカバリ領域で新しいファイル用に使用できる領域が増加します フラッシュ リカバリ領域のディスク割当て制限を求める式では 最小値が計算されます このディスク割当て制限は 保存方針を満たすためのテープ領域の可用性によって異なります ただし 式で計算されるより多くのフラッシュ リカバリ領域のディスク割当て制限を行うことによって ディスク上のリカバリ期間を増やし データベースのリストアおよびリカバリ時にテープからアーカイブ REDO ログおよびバックアップをリストアする必要性を削減できます ディスクまたはテープにバックアップするための Recovery Manager 環境の構成 Recovery Manager を使用して 保存方針 バックアップの最適化および制御ファイルの自動バックアップを構成します 次に例を示します CONNECT TARGET SYS/orace@trgt; # Recovery window of 15 days ensures that the database is recoverable within 7 # days using backups on disk and tape CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS; CONFIGURE BACKUP OPTIMIZATION ON; # Because you do not use a recovery catalog, enable the autobackup feature CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE DEVICE TYPE sbt PARMS='...' PARALLELISM 1; # PARMS are vendor-specific A-8 Oracle Database バックアップおよびリカバリ基礎

191 フラッシュ リカバリ領域およびテープへのバックアップ : 基本的な例 ディスクおよびテープへのバックアップ スクリプトの作成例 ディスク専用の場合と同様に この項で実行するバックアップ スクリプトは データベースの負荷に基づいて分類されます 少数のデータ ブロックが変更される場合のバックアップ スクリプト この例では 比較的少数のデータ ブロックが頻繁に変更されるため レベル 1 の毎日の増分バックアップのサイズは小さくなります この例の目的は ディスク上にあるレベル 0 の 1 つの増分バックアップを レベル 1 の増分バックアップを使用して毎日増分更新した後 他のすべてのファイルをテープに移動することです これによって フラッシュ リカバリ領域の使用量を最小限に抑えることができます 初期設定フラッシュ リカバリ領域を必要なディスク割当て制限で作成し そのフラッシュ リカバリ領域を REDO ログのアーカイブ先として設定します ディスク割当て制限を求める式は バックアップの保存方針によって異なります ただし 保存方針が冗長性に基づくか リカバリ期間に基づくかは同じです 次の式を使用します Disk Quota = Size of 1 copy of the database + size of 1 day's level 1 incremental backup + size of (Y+1) days of archived logs この場合 Y は 各バックアップ スクリプトで BACKUP RECOVERY AREA を実行する間隔 ( 日数 ) です この例の場合 1 つのバックアップ スクリプトが毎日実行され レベル 1 の新しい増分バックアップが その日の変更を反映して作成されます その後 前日からのレベル 1 のバックアップを使用して レベル 0 のバックアップをロールフォワードし フラッシュ リカバリ領域のすべてのファイルをテープにバックアップします スクリプトは フラッシュ リカバリ領域を毎日テープにバックアップするため フラッシュ リカバリ領域は データベースのコピー レベル 1 の毎日の増分バックアップおよび 2 日分のアーカイブ REDO ログを保持できる大きさである必要があります ディスク上のリカバリ期間は 1 日です 1 日以上前の時点にリカバリするには Recovery Manager は バックアップをテープからリストアする必要があります 毎日実行するスクリプト初期設定の後 Recovery Manager によって通常毎日実行するバックアップ スクリプトは 次のようになります # Execute each day of the week # Roll forward the copy to most recent incremental backup SCN, which will # be yesterday's incremental level 1 backup RECOVER COPY OF DATABASE WITH TAG "daily_backup"; # Take incremental backups to flash recovery area (using default disk channel) BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG "daily_backup" DATABASE; # Back up flash recovery area to tape BACKUP RECOVERY AREA; # delete obsolete backups on tape DELETE OBSOLETE DEVICE TYPE sbt; Recovery Manager ベースのディスクおよびテープのバックアップ計画の例 A-9

192 フラッシュ リカバリ領域およびテープへのバックアップ : 基本的な例 次の表に このスクリプトを毎日実行すると フラッシュ リカバリ領域とテープの内容がどのように変化するかを示します スクリプトは daily_backup というタグが付けられたレベル 0 のデータベースのコピーを 前日のレベル 1 の増分バックアップの SCN までロールフォワードした後 レベル 1 の新しい増分バックアップを 前日の変更を反映して作成します たとえば 木曜日にスクリプトを実行すると Recovery Manager は レベル 0 のバックアップを 水曜日の増分バックアップの SCN までロールフォワードします 表 A-5 少数のブロックが変更される場合のバックアップ 日付 2 月 1 日 ( 日 ) 2 月 2 日 ( 月 ) 処理 1. レベル 0 のバックアップをロールフォワードしますが レベル 0 のバックアップが存在しないため 失敗します 2. 後日ロールフォワードされるレベル 0 の増分バックアップを作成します 1. レベル 0 のバックアップをロールフォワードしますが レベル 1 のバックアップが存在しないため 失敗します 2. 2 月 2 日の変更を含むレベル 1 の増分バックアップを作成します 3. フラッシュ リカバリ領域を sbt にバックアップします フラッシュ リカバリ領域および sbt の内容 レベル 0 の増分バックアップアーカイブ REDO ログなど フラッシュ リカバリ領域にある他のファイルはテープにコピーされ 領域が不足したときにフラッシュ リカバリ領域から削除されます 2 月 1 日からのレベル 0 のバックアップ 2 月 2 日からの変更を含むレベル 1 の増分バックアップアーカイブ REDO ログなど フラッシュ リカバリ領域にある他のファイルはテープにコピーされ 領域が不足したときにフラッシュ リカバリ領域から削除されます テープに格納されている不要なファイルは削除されます 以降 1. レベル 0 の増分バックアップをレベル 1 の以前の増分バックアップの SCN までロールフォワードします 2. 前日からの変更を含むレベル 1 の増分バックアップを作成します 3. フラッシュ リカバリ領域を sbt にバックアップします 前日までロールフォワードされたレベル 0 のバックアップ この日からの変更を含むレベル 1 の増分バックアップアーカイブ REDO ログなど フラッシュ リカバリ領域にある他のファイルはテープにコピーされ 領域が不足したときにフラッシュ リカバリ領域から削除されます テープに格納されている不要なファイルは削除されます 多くブロックが変更される場合のバックアップ スクリプト この例では CRM 環境の例と同様に 1 週間で多数またはほとんどのデータ ブロックが更新されます 毎日の増分バックアップを実行する計画は 増分バックアップのサイズが非常に大きくなり 予測が困難なためお薦めしません この場合は データベースを毎週テープにバックアップし アーカイブ ログを毎日テープにバックアップし リカバリ期間ベースの保存方針を使用する計画が適しています この計画では 次の処理が実行されます REDO ログ ファイルは フラッシュ リカバリ領域にアーカイブされます データベースの全体バックアップが 毎週フラッシュ リカバリ領域に取られます テープに格納されていない フラッシュ リカバリ領域のバックアップ ファイル ( アーカイブ REDO ログを含む ) は BACKUP RECOVERY AREA コマンドを使用して 毎日テープにバックアップされ テープに格納されている不要なファイルは削除されます A-10 Oracle Database バックアップおよびリカバリ基礎

193 フラッシュ リカバリ領域およびテープへのバックアップ : 基本的な例 リカバリ期間ベースの保存方針を使用すると その期間に Point-in-Time リカバリの実行に必要なすべてのバックアップは 必要な間は保持されます これによって ディスク領域の使用に制限がある場合でも データは保護されます 初期設定フラッシュ リカバリ領域を必要なディスク割当て制限で作成し そのフラッシュ リカバリ領域を REDO ログのアーカイブ先として設定します ディスク割当て制限を求めるための式は テープへのフラッシュ リカバリ領域のバックアップ頻度によって異なります Disk Quota = Size of 1 copies of the database + size of (Y+1) days of archived logs この場合 Y は 各バックアップ スクリプトで BACKUP RECOVERY AREA を実行する間隔 ( 日数 ) です この例では データベースの全体バックアップを毎週実行し テープへのフラッシュ リカバリ領域のバックアップを毎日実行すると想定しています この計画では 2 つのスクリプトを実行します 1 つ目のスクリプトは 各週の 1 日目 ( 日曜日 ) に実行し データベースの全体バックアップを作成します 2 つ目のスクリプトは 各週の他の日 ( 月曜日 ~ 土曜日 ) に実行し フラッシュ リカバリ領域の内容 ( その日のアーカイブ REDO ログ ) をテープにバックアップします この計画では どちらのスクリプトにも BACKUP RECOVERY AREA コマンドが含まれるため コマンドは毎日実行されます この例では Y=1 であるため ディスク割当て制限は データベースの 1 つのコピーに 2 日分のアーカイブ REDO ログを足したサイズになります 毎週実行するスクリプト次の Recovery Manager バックアップ スクリプトは 毎週日曜日に実行されます # Execute only once a week # Take copy of database to flash recovery area BACKUP AS COPY DATABASE; # Take backup of flash recovery area to tape BACKUP RECOVERY AREA; # Delete obsolete backups on tape DELETE OBSOLETE DEVICE TYPE sbt; EXIT; 毎日実行するスクリプト毎日 ( 月曜日 ~ 土曜日 ) 実行される Recovery Manager スクリプトは 次のようになります # Execute 6 days/wk # Take backup of flash recovery area to tape BACKUP RECOVERY AREA; # delete obsolete backups on tape DELETE OBSOLETE DEVICE TPE sbt; フラッシュ リカバリ領域全体が毎日テープにバックアップされるため 新しいファイル用に領域が必要になると データベースは バックアップおよびアーカイブ REDO ログ ファイルをフラッシュ リカバリ領域から削除します 領域が不足すると 必ずファイルが削除されるため バックアップとバックアップの間で どのファイルがフラッシュ リカバリ領域に残るかを予測することは困難です 半数のブロックが変更される場合のバックアップ スクリプト 次の計画は 定期的に取られたデータベースの全体バックアップに基づいています データベースの全体バックアップ間で約半数のデータ ブロック変更される場合 または変更されるデータ ブロックの数がデータベースの全体バックアップ間で大きく異なる場合に有効です 計画は データベースの増分更新バックアップベースの全体バックアップに基づいており 毎週ロールフォワードされます この計画には データベースのレベル 0 のディスク コピー増分バックアップと 過去 7 日分のデータ ファイルの変更で毎週日曜日に作成されるレベル 1 の増分が必要です ロールフォワードの後 フラッシュ リカバリ領域の内容はテープにバッ Recovery Manager ベースのディスクおよびテープのバックアップ計画の例 A-11

194 フラッシュ リカバリ領域およびテープへのバックアップ : 基本的な例 クアップされるため データベースのレベル 0 の増分コピーおよびレベル 1 の毎週の増分バックアップは ディスクおよびテープの両方で使用可能になります アーカイブ REDO ログ ファイルは 毎日フラッシュ リカバリ領域に蓄積されます 毎日スクリプトを実行するたびに これらの REDO ログ ファイルはテープにバックアップされます その後 フラッシュ リカバリ領域が不足すると これらのファイルはディスクから削除されます 初期設定この例でのフラッシュ リカバリ領域の最小ディスク割当て制限は 次の式で計算されます Disk Quota = Size of 1 copy of the database + Size of 1 level 1 incremental backup with Y days of changes + Size of (Y+1) days of archived redo logs この場合 Y は フラッシュ リカバリ領域をテープにバックアップする間隔 ( 日数 ) です この例では Y=7 であるため ディスク割当て制限は データベースの 1 つのコピー レベル 1 の 7 日間の増分バックアップ 8 日分のアーカイブ REDO ログを足したサイズになります 毎週実行するスクリプトこの計画で 毎週日曜日にバックアップを実行するスクリプトは 次のようになります # Execute once a week # Roll forward the whole copy of the database to last incremental backup SCN RECOVER COPY OF DATABASE WITH TAG "whole_db_copy"; # Make an incremental backup of the database to the flash recovery area. BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG "whole_db_copy" DATABASE; # Back up flash recovery area to tape BACKUP RECOVERY AREA; # delete obsolete backups on tape DELETE OBSOLETE DEVICE TYPE sbt; 毎日実行するスクリプトこの計画で 毎日実行するスクリプトは 次のようになります # Execute 6 days/wk # Back up flash recovery area to tape BACKUP RECOVERY AREA; # delete obsolete backups on tape DELETE OBSOLETE DEVICE TYPE sbt; A-12 Oracle Database バックアップおよびリカバリ基礎

195 フラッシュ リカバリ領域およびテープへのバックアップ : 基本的な例 次の表に スクリプトによるリカバリ期間の保持方法を示します この例では 週は日曜日に始まると想定しています 表 A-6 半数のブロックが変更される場合のバックアップスクリ日付プト処理 スクリプト実行後のフラッシュ リカバリ領域およびテープの内容 第 1 週 日曜日 第 1 週 月曜日 ~ 土曜日 第 2 週 日曜日 第 2 週 月曜日 ~ 土曜日 毎週 1. RECOVER COPY OF DATABASE コマンドを実行しますが データベースのレベル 0 のバックアップが存在しないため 処理は実行されません 2. BACKUP... FOR RECOVER OF COPY コマンドの実行結果として レベル 0 のバックアップを作成します 3. フラッシュ リカバリ領域のすべてのファイルをテープにバックアップします 4. 不要なバックアップをテープから削除します 毎日 1. フラッシュ リカバリ領域を テープにバックアップします 2. 不要なバックアップをテープから削除します 毎週 1. レベル 0 を最新の増分 SCN までリカバリする RECOVER COPY OF DATABASE コマンドを実行しますが ロールフォワードで使用するレベル 1 の増分バックアップが存在しないため 処理は実行されません 2. レベル 1 の増分バックアップを実行します 第 1 週からの変更を含むレベル 1 の増分バックアップが作成されます 3. フラッシュ リカバリ領域をテープにバックアップします 4. 不要なバックアップをテープから削除します 毎日 1. フラッシュ リカバリ領域を テープにバックアップします 2. 不要なバックアップをテープから削除します フラッシュ リカバリ領域には データベースのレベル 0 の増分バックアップが含まれ 毎週ロールフォワードされます テープには データベースのレベル 0 の増分バックアップが含まれます フラッシュ リカバリ領域には 前日のアーカイブ REDO ログ およびデータベースのレベル 0 の増分バックアップが含まれます テープには レベル 0 の増分バックアップ および第 1 週の日曜日以降のすべての日の REDO ログが含まれます 不要なバックアップはありません フラッシュ リカバリ領域には 第 1 週の日曜日の SCN でのデータベースのレベル 0 の増分バックアップ 第 1 週からの変更を含むレベル 1 の増分バックアップが含まれます テープには 第 1 週の日曜日からのレベル 0 の増分バックアップ 第 1 週からのすべての変更を含むレベル 1 の増分バックアップ 第 1 週からのアーカイブ REDO ログが含まれます 不要なバックアップはありません フラッシュ リカバリ領域には 前日のアーカイブ REDO ログ およびデータベースのレベル 0 の増分バックアップが含まれます その他のアーカイブ REDO ログも含まれます テープには レベル 0 の増分バックアップ および第 1 週の日曜日以降のすべての日の REDO ログが含まれます Recovery Manager ベースのディスクおよびテープのバックアップ計画の例 A-13

196 フラッシュ リカバリ領域およびテープへのバックアップ : 基本的な例 表 A-6 半数のブロックが変更される場合のバックアップ ( 続き ) スクリプト実行後のフラッ 日付 スクリプト 処理 シュ リカバリ領域およびテープの内容 第 3 週 日曜日 毎週 1. レベル 0 を最新の増分 SCN までリカバリする RECOVER COPY OF DATABASE コマンドを実行します レベル 0 の増分バックアップは 第 2 週の 1 日目までロールフォワードされます 2. レベル 1 の増分バックアップを実行します 第 2 週からの変更を含むレベル 1 の増分バックアップが作成されます 3. フラッシュ リカバリ領域をテープにバックアップします 4. 不要なバックアップをテープから削除します フラッシュ リカバリ領域には 第 2 週の日曜日の SCN でのデータベースのレベル 0 の増分バックアップ 第 2 週からの変更を含むレベル 1 の増分バックアップが含まれます テープには 第 2 週の日曜日の SCN までロールフォワードされたレベル 0 の増分バックアップ 第 2 週からのすべての変更を含むレベル 1 の増分バックアップ 第 2 週からのアーカイブ REDO ログが含まれます テープから削除された不要なバックアップには 第 1 週からのアーカイブ REDO ログ 第 1 週からのデータベースのレベル 0 の増分バックアップのテープ バックアップが含まれます データベースのバックアップ用に十分なディスク領域がない場合のバックアップ スクリプト データベースのコピーを保持するためのディスク割当て制限が十分でない場合 フラッシュ リカバリ領域をアーカイブ ログの格納先としてのみ使用する必要があります ディスク割当て制限規則によって これらのログは ( すでにテープにバックアップ済などの理由で ) 不要になるとフラッシュ リカバリ領域から削除されます 他のファイルを格納するための領域がフラッシュ リカバリ領域に不足した場合に アーカイブ ログをフラッシュ リカバリ領域から削除するには アーカイブ ログを毎日テープにバックアップします この計画では フラッシュ リカバリ領域のサイズは 2 日分以上のアーカイブ REDO ログと 1 日分の増分バックアップを保持できる大きさにする必要があります この計画では 増分更新バックアップは使用しませんが レベル 0 とレベル 1 の増分バックアップに基づいています この計画では 2 つのスクリプトを使用します 1 つは毎週 ( 日曜日など ) 実行し もう 1 つは 1 つ目のスクリプトを実行した日以外 ( 月曜日 ~ 土曜日 ) に実行します 毎週実行するスクリプトは テープにレベル 0 の増分バックアップを作成します このバックアップには データベースの内容すべてが含まれます 1 つ目のスクリプトを実行する日以外に実行するスクリプトは レベル 1 の増分バックアップを作成します このバックアップには データベースへの毎日の変更が含まれます 毎週実行するスクリプト次に 各週の 1 日目に 1 回実行するスクリプトを示します # Execute only once a week # backup database to tape BACKUP DEVICE TYPE sbt INCREMENTAL LEVEL 0 DATABASE; # delete obsolete backups on tape DELETE OBSOLETE DEVICE TYPE sbt; # backup recovery file destination to tape BACKUP RECOVERY AREA; A-14 Oracle Database バックアップおよびリカバリ基礎

197 フラッシュ リカバリ領域およびテープへのバックアップ : 基本的な例 毎日実行するスクリプト次のスクリプトは 2 日目以降の毎日 ( 月曜日 ~ 土曜日 ) 実行します # backup recovery file destination to tape BACKUP RECOVERY AREA; # Take incremental backups to flash recovery area BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 DATABASE; 次の表に Recovery Manager の保存方針のリカバリ期間の保持方法と ディスク割当て制限の保持方法を示します 毎日スクリプトを実行した後も存在するリカバリ ファイルがテープに存在するため Oracle では 必要に応じて フラッシュ リカバリ領域からファイルを削除します 表 A-7 日付 ディスク領域に制限がある場合のバックアップスクリプト処理 スクリプト実行後のテープの内容 2 月 1 日 ( 日 ) 2 月 2 日 ( 月 )~ 2 月 7 日 ( 土 ) 2 月 8 日 ( 日 ) 毎週 1. レベル 0 をテープにバックアップします 2. 不要なバックアップをテープから削除します 3. フラッシュ リカバリ領域をテープにバックアップします 毎日 1. フラッシュ リカバリ領域をテープにバックアップします 2. レベル 1 をディスクにバックアップします 毎週 1. レベル 0 をテープにバックアップします 2. 不要なバックアップをテープから削除します 3. フラッシュ リカバリ領域をテープにバックアップします テープには 2 月 1 日以降のデータベース全体のレベル 0 のバックアップと アーカイブ REDO ログが含まれます テープには 2 月 1 日以降のデータベース全体のレベル 0 のバックアップ 月曜日から今日までの毎日のレベル 1 の増分バックアップ 1 週間分のアーカイブ REDO ログが含まれます テープには 2 月 1 日以降のデータベース全体のレベル 0 のバックアップ 月曜日から今日までの毎日のレベル 1 の増分バックアップ 1 週間分のアーカイブ REDO ログが含まれます Recovery Manager ベースのディスクおよびテープのバックアップ計画の例 A-15

198 フラッシュ リカバリ領域およびテープへのバックアップ : 基本的な例 A-16 Oracle Database バックアップおよびリカバリ基礎

199 用語集 ARCHIVELOG モード (ARCHIVELOG mode) データベース モードで このモードの場合 Oracle は一杯になったオンライン REDO ログをディスクにコピーする このモードは データベース作成時に指定するか あるいは ALTER DATABASE ARCHIVELOG 文を使用して指定する アーカイブ REDO ログ NOARCHIVELOG モード を参照 DBID 一意となるように生成された内部番号で データベースの識別に使用される データベースを作成すると Oracle が自動的にこの番号を作成する LogMiner SQL 文でログ ファイルの読取り 分析および解析を行うためのユーティリティ アーカイブ REDO ログ を参照 NOARCHIVELOG モード (NOARCHIVELOG mode) データベース モードで このモードの場合 Oracle は一杯になったオンライン REDO ログを上書きする前にディスクにアーカイブすることを要求しない このモードはデータベース作成時に指定するかまたは ALTER DATABASE NOARCHIVELOG コマンドを使用して モードを変更する NOARCHIVELOG モードで実行すると 失われたまたは破損したデータがリカバリされる可能性が限られる アーカイブ REDO ログ ARCHIVELOG モード を参照 NORMAL モードでオフラインされた (offline normal) 表領域を NORMAL モードでオフライン化するには ALTER TABLESPACE... OFFLINE NORMAL 文を使用する 表領域内のデータ ファイルにはチェックポイントが付けられるため オンライン状態にする前にリカバリする必要はない 表領域が NORMAL モードでオフライン化されなかった場合は そのデータ ファイルをオンラインにする前にリカバリする必要がある Oracle Flashback Database Recovery Manager の FLASHBACK コマンドまたは SQL*Plus の FLASHBACK 文によって データベース全体を以前の一貫性のある SCN に戻す機能 データベースのフラッシュバックは 物理ファイルをリストアせずに 変更されたデータ ブロックの保存イメージを使用して現行のデータ ファイルを過去の状態にリストアするという点で 従来のメディア リカバリとは異なる フラッシュバック データベース プロセスでは フラッシュバック ログフラッシュバック ログとアーカイブ REDO ログが使用される Oracle Managed Files (OMF) Oracle データベースの機能の 1 つ ディスクの専用領域内での Oracle データベース ファイルの作成 命名および削除を管理し DBA がその指定に関与する必要性を最小限にする 用語集 -1

200 Oracle 管理ファイル (Oracle-managed file) Oracle Managed Files 機能で管理されるデータベース ファイル Point-in-Time リカバリ (point-in-time recovery) データベース ファイルを現行以外の時刻まで不完全リカバリする Point-in-Time リカバリは 不完全リカバリ不完全リカバリまたは時間ベースのリカバリ時間ベースのリカバリとも呼ばれる 完全リカバリ完全リカバリ 不完全リカバリ不完全リカバリ メディア リカバリメディア リカバリ リカバリするリカバリする を参照 Recovery Manager (RMAN) Oracle データベースの物理バックアップおよびリカバリのプライマリ ユーティリティ Recovery Manager は Oracle データベースのレコードを Recovery Manager リポジトリと呼ばれる独自の構造で保持し バックアップの記憶域を管理し バックアップを検証する これは リカバリ カタログと呼ばれる中央情報リポジトリとあわせて使用することも またリカバリ カタログなしで使用することもできる リカバリ カタログを使用しない場合 Recovery Manager はデータベースの制御ファイルを使用し バックアップおよびリカバリ処理に必要な情報を格納する Recovery Manager とサード パーティのメディア マネージャ ソフトウェアをあわせて使用すると テープなどの 3 次ストレージ デバイスにファイルのバックアップを作成できる バックアップ ピースバックアップ ピース バックアップ セットバックアップ セット コピーコピー メディア マネージャメディア マネージャ リカバリ カタログ を参照 Recovery Manager リポジトリ (Recovery Manager repository) ターゲット データベースでのバックアップ処理とリカバリ処理に関する Recovery Manager メタデータのレコード Recovery Manager リポジトリの正式なコピーは 常にターゲット データベースの制御ファイルに格納される リカバリ カタログリカバリ カタログを使用して Recovery Manager リポジトリを長期間保存することもできる また リカバリ カタログリカバリ カタログは データベースの制御ファイルが消失した場合に Recovery Manager リポジトリ データの代替ソースとして使用できる リカバリ カタログ リカバリ カタログ データベースリカバリ カタログ データベース 再同期化再同期化 を参照 REDO スレッド (redo thread) インスタンスによって生成される REDO データベースがシングル インスタンス構成で実行される場合 そのデータベースには REDO スレッドが 1 つのみ存在する REDO ログ (redo log) オンライン REDO ログまたはアーカイブ REDO ログのいずれかを指す オンライン REDO ログは 2 つ以上の REDO ログ グループのセットで Oracle データ ファイルと制御ファイルに対するすべての変更が記録される アーカイブ REDO ログは オフラインの宛先に書き込まれるオンライン REDO ログのコピーである アーカイブ REDO ログ オンライン REDO ログ を参照 REDO ログ グループ (redo log group) ( オンライン REDO ログ ファイルに対応する ) 各オンライン REDO ログ メンバーは 1 つの REDO ログ グループに属する REDO ログ グループには 1 つ以上のメンバーが含まれる 複数のメンバーが含まれている REDO ログ グループを 多重 REDO ログ グループという REDO ログ グループのすべてのメンバーの内容は同じである 用語集 -2

201 RESETLOGS データベースをオープンする方法の 1 つ この方法を使用すると 現行のオンライン REDO ログがすべてアーカイブされ (ARCHIVELOG モードの場合 ) ログ順序番号が 1 にリセットされ オンライン REDO ログが消去される OPEN RESETLOGS 操作を実行すると 新しいデータベース インカネーションが開始される 新しいインカネーションの開始 SCN (RESETLOGS SCN とも呼ばれる ) は OPEN RESETLOGS を実行する前のメディア リカバリの不完全リカバリ SCN に 1 を足したものである OPEN RESETLOGS 操作は 不完全リカバリやバックアップ制御ファイルを使用したリカバリの後に実行する必要がある OPEN RESETLOGS 操作を実行しても データベースのリカバリ可能性に影響はない OPEN RESETLOGS 操作を実行する前のバックアップは有効のままになり OPEN RESETLOGS 操作の後に作成されたバックアップとともに使用して データベースのすべての破損を修復できる RMAN Recovery Manager を参照 SBT System Backup to Tape インタフェース テープへのバックアップに使用される Recovery Manager コマンドでバックアップ先を指定するために最も一般的に使用される ("BACKUP DEVICE TYPE sbt DATABASE" など ) SYSTEM 表領域 (SYSTEM tablespace) データベースの Oracle データ ディクショナリ ( データベースのすべての内容を記述するメタデータ ) を含む表領域 他の表領域とは異なり SYSTEM 表領域で Oracle が機能するには 表領域に含まれているすべてのデータ ファイルがオンラインであることが必要である メディア障害によって SYSTEM 内のデータ ファイルの 1 つが影響を受けた場合 データベースをマウントしてリカバリする必要がある UNDO 表領域 (undo tablespace) データベースが自動 UNDO 管理モードで実行されているときに ロールバック情報のみが格納される専用表領域 アーカイブ (archiving) 一杯になったオンライン REDO ログをオフライン ログのアーカイブ先にコピーする操作 オンライン REDO ログのオフライン コピーは アーカイブ REDO ログと呼ばれる REDO ログをアーカイブするには データベースを ARCHIVELOG モードで実行する必要がある アーカイブ REDO ログ (archived redo log) 一杯になったオンライン REDO ログ グループのメンバーのコピーで データベースが ARCHIVELOG モードのときに作成される LGWR プロセスにより各オンライン REDO ログが REDO レコードで一杯になると アーカイバ プロセスはこれらのログを 1 つ以上の REDO ログのアーカイブ先にコピーする このコピーが アーカイブ REDO ログである Recovery Manager では 元のアーカイブ REDO ログとアーカイブ REDO ログのイメージ コピーは区別されず どちらもイメージ コピーとみなされる 一時ファイル (tempfile) 一時表領域にあり TEMPFILE オプションで作成されるファイル 一時表領域に表などの永続データベース オブジェクトは格納できない 通常はソートに使用される 一時ファイルには永続オブジェクトが含まれないため Recovery Manager によるバックアップは行われない ただし Recovery Manager は 一時ファイルの場所を制御ファイル内で追跡し 一時ファイルは リカバリ時にそれらの場所に必要に応じて再作成される 一貫性のある停止 (consistent shutdown) IMMEDIATE TRANSACTIONAL または NORMAL オプションを指定して停止したデータベース 正しく停止されたデータベースは すでに一貫性のある状態であるため リカバリする必要はない 用語集 -3

202 一貫性バックアップ (consistent backup) メディア リカバリを実行することなく RESETLOGS オプションを指定してオープンできるデータベース全体のバックアップ つまり このバックアップに REDO を適用しなくても一貫性が保たれる ( ただし 一貫性バックアップの作成後に生成された REDO を適用しないかぎり その一貫性バックアップの作成以降のすべてのトランザクションが消失することに注意する ) 一貫性バックアップは データベースの一貫性のある停止一貫性のある停止を実行した後でのみ作成できる バックアップが完了するまで データベースを再度オープンしないように注意する必要がある ファジー ファイルファジー ファイル 非一貫性バックアップ非一貫性バックアップ を参照 イメージ コピー (image copy) 単一のデータ ファイル アーカイブ REDO ログ ファイルまたは制御ファイルのビット単位のコピーコピーで 次のようなものを指す そのまま使用して リカバリを実行できるもの ( 未使用ブロックの圧縮を使用する Recovery Manager 固有の形式のバックアップ セットとは異なる ) Recovery Manager の BACKUP AS COPY コマンド UNIX の cp などのオペレーティング システムのコマンド または Oracle アーカイバ プロセスによって生成されたもの インカネーション (incarnation) データベースの別バージョン RESETLOGS オプションを指定してデータベースをオープンすると データベースのインカネーションが変更されるが 必要な REDO が使用できるかぎり 以前のインカネーションからバックアップをリカバリできる インスタンス障害 (instance failure) Oracle インスタンスが ハードウェア障害 Oracle 内部エラーまたは SHUTDOWN ABORT 文によって終了すること インスタンス障害が発生した場合は クラッシュ リカバリまたはインスタンス リカバリを必ず実行する必要がある インスタンス リカバリ (instance recovery) RAC 構成で インスタンスを使用して REDO データをオープン状態のデータベースに適用する このインスタンスが 別のインスタンスのクラッシュを検出したときに実行される リカバリするリカバリする を参照 エクスポート (export) いずれかの Oracle エクスポート ユーティリティ (Data Pump Export など ) を使用して データベースから ( 物理ファイルではなく ) バイナリ ファイルに論理データを抽出すること データをデータベースにインポートするには 対応する Oracle インポート ユーティリティを使用する 論理バックアップ論理バックアップ を参照 オペレーティング システムのバックアップ (operating system backups) ユーザー管理のバックアップユーザー管理のバックアップ を参照 オペレーティング システムのバックアップおよびリカバリ (operating system backup and recovery) ユーザー管理のバックアップとリカバリユーザー管理のバックアップとリカバリ を参照 用語集 -4

203 オンライン REDO ログ (online redo log) オンライン REDO ログとは データベースへのすべての変更が記録される 2 つ以上のファイルのセットである データベースが変更されるたびに Oracle は REDO レコードを REDO バッファに生成する REDO バッファの内容は LGWR プロセスによってオンライン REDO ログにフラッシュされる 現行のオンライン REDO ログとは LGWR によって現在書込みが行われているオンライン REDO ログを指す LGWR はファイルの最後に到達すると ログ スイッチログ スイッチを実行し 新しいログ ファイルへの書込みを開始する データベースを ARCHIVELOG モードで実行している場合 一杯になった各オンライン REDO ログ ファイルを 1 つ以上のアーカイブ先にコピーしないと LGWR で上書きできない アーカイブ REDO ログ を参照 オンライン REDO ログ グループ (online redo log group) Oracle のオンライン REDO ログは 複数のオンライン REDO ログ グループで構成されている 各グループには 1 つ以上の同一のオンライン REDO ログ メンバーが含まれている オンライン REDO ログ メンバーは REDO レコードを含む物理ファイルである オンライン REDO ログ メンバー (online redo log member) オンライン REDO ログ グループ内の物理的なオンライン REDO ログ ファイル 各ログ グループには 1 つ以上のメンバーが必要である グループの各メンバーの内容は同じである オンライン バックアップ (online backup) データベースがオープンしており かつデータ ファイルがオンラインのときに作成される 1 つ以上のデータ ファイルのバックアップ データベースをオープンした状態でユーザー管理のバックアップを作成する場合は ALTER TABLESPACE BEGIN BACKUP コマンドを発行して 表領域をバックアップ モードバックアップ モードにする必要がある (ALTER DATABASE BEGIN BACKUP を使用して 1 つの手順でデータベースのすべての表領域をバックアップ モードにすることもできる ) Recovery Manager を使用してバックアップを実行する際は 表領域をバックアップ モードにしてはいけないことに注意する 完全再同期化 (full resynchronization) Recovery Manager の処理の 1 つ データベースの制御ファイル内にある変更されたメタデータを使用して リカバリ カタログリカバリ カタログを更新する Recovery Manager コマンドの RESYNC CATALOG を発行すると 完全なカタログ再同期化再同期化を開始できる (Recovery Manager は再同期化を必要に応じて自動的に実行するため RESYNC CATALOG を使用する必要はほとんどない ) 完全リカバリ (complete recovery) リストアしたバックアップ以降に生成されたすべての REDO を適用して 1 つ以上のデータ ファイルをリカバリする 通常 完全リカバリは 1 つ以上のデータ ファイルまたは制御ファイルがメディア障害によって破損した場合に実行される 破損したファイルを完全にリカバリするには リストアしたバックアップ以降に生成された REDO をすべて使用する 不完全リカバリ不完全リカバリ メディア リカバリメディア リカバリ を参照 クラッシュ リカバリ (crash recovery) シングル インスタンス データベースのクラッシュ あるいは Oracle Real Applications Clusters 構成の全インスタンスのクラッシュのどちらかが発生した場合に オンライン REDO レコードをデータベースに自動的に適用すること クラッシュ リカバリに必須なのはオンライン ログの REDO のみ アーカイブ REDO ログは必須ではない リカバリするリカバリする を参照 用語集 -5

204 クローズ状態のバックアップ (closed backup) データベースがクローズしている間に作成される 1 つ以上のデータベース ファイルのバックアップ 通常 クローズ状態のバックアップは 全体データベース バックアップである データベースが正常にクローズされた場合 バックアップに含まれているファイルはすべて一貫性が保たれた状態になっている データベースが正常にクローズされなかった場合 バックアップの一貫性は保たれない 一貫性のある停止一貫性のある停止 一貫性バックアップ一貫性バックアップ を参照 クロスチェック (crosscheck) ディスクまたはメディア管理カタログのファイルが リポジトリおよび制御ファイルのデータに対応しているかどうかをチェックする テープにはメディア マネージャメディア マネージャによって期限切れまたは使用不可のマークが付けられることがあり ファイルはディスクから削除されたり破損することがあるため Recovery Manager リポジトリにはバックアップに関する古い情報が含まれる場合がある クロスチェックを実行するには CROSSCHECK コマンドを実行する ファイルをリストアできるかどうかを判断するには VALIDATE BACKUPSET または RESTORE... VALIDATE を実行する 妥当性チェック妥当性チェック を参照 現行のオンライン REDO ログ (current online redo log) 現時点において LGWR バックグラウンド プロセスで REDO レコードが記録されているオンライン REDO ログ ファイル REDO ログ REDO ログ グループ を参照 コールド バックアップ (cold backup) クローズ状態のバックアップクローズ状態のバックアップ を参照 コピー (copy) Oracle ファイル (Oracle データ ファイル 制御ファイルおよびアーカイブ REDO ログ ) をビット単位で正確にディスクにバックアップすること 次の 2 つの方法でコピーできる オペレーティング システムのユーティリティを使用する (UNIX の cp や dd など ) Recovery Manager の BACKUP AS COPY コマンドを使用する バックアップバックアップ を参照 孤立したバックアップ (orphaned backups) データベースのインカネーションのバックアップであるが そのインカネーションが現行のインカネーションの直接の祖先ではないか または祖先のインカネーションが現行のインカネーションに向かって分岐した SCN の後に作成されたバックアップ このようなバックアップは 現行のインカネーションで使用できない 再同期化 (resynchronization) ターゲット データベースの制御ファイルの現行情報を使用して リカバリ カタログを更新する処理 RESYNC CATALOG コマンドを発行すると カタログの完全再同期化完全再同期化を開始できる 部分再同期化では アーカイブ REDO ログ バックアップ セットおよびデータ ファイルのコピーに関する情報をリカバリ カタログに転送する Recovery Manager は 必要に応じて再同期化を自動的に実行する 差分増分バックアップ (differential incremental backup) レベル 1 またはレベル 0 の最新のバックアップ以降に変更されたすべてのブロックをバックアップするタイプの増分バックアップ増分バックアップ たとえば レベル 1 の差分バックアップでは Recovery Manager は レベル 1 またはレベル 0 の最新のバックアップを判断し そのバックアップ後に変更されたすべてのブロックをバックアップする 差分バックアップは増分バックアップのデフォルトのタイプとなっている 差分増分バックアップを使用してリカバリするときは Recovery Manager では リストアされたデータ ファイルがバックアップされた後のすべてのレベル 1 の差分増分バックアップを適用する必要がある 累積増分バックアップ累積増分バックアップ 増分バックアップ増分バックアップ を参照 用語集 -6

205 システム変更番号 (system change number: SCN) コミットされたバージョンのデータベースを ある時点で定義するスタンプ Oracle は コミットされたすべてのトランザクションに一意の SCN を割り当てる 自動 UNDO 管理モード (automatic undo management mode) UNDO データが専用の UNDO 表領域に格納されるデータベース モード UNDO 管理に関して実行する必要があるのは UNDO 表領域の作成のみである その他の UNDO 管理はすべて自動的に実行される 自動チャネル割当て (automatic channel allocation) ALLOCATE CHANNNEL コマンドを使用せずにバックアップおよびリストア作業を実行する Recovery Manager の機能 CONFIGURE コマンドを使用すると ディスクとテープのチャネルを指定できる その後は チャネルを手動で割り当てることなく Recovery Manager コマンド プロンプトで BACKUP や RESTORE などのコマンドを発行できる Recovery Manager は コマンドの実行に必要な構成済のチャネルをすべて使用する 循環再利用レコード (circular reuse records) 情報が含まれている制御ファイル レコード バックアップとリカバリ操作時に Recovery Manager が使用する これらのレコードは 論理的なリングに配置されている 使用可能なレコード スロットが一杯の場合 制御ファイルを拡大して新規レコード用の領域を確保するか あるいは最も古いレコードを上書きする CONTROL_FILE_RECORD_KEEP_TIME 初期化パラメータは レコードが上書き可能になるまで保持される日数を制御する CONTROL_FILE_ RECORD_KEEP_TIME のデフォルトは 7 日間 非循環再利用レコード非循環再利用レコード を参照 冗長性セット (redundancy set) Oracle データベース ファイルの障害や消失からのリカバリを可能にするバックアップのセット スタンバイ データベース (standby database) 本番データベースのコピー 障害時の保護に使用できる ストアド スクリプト (stored script) リカバリ カタログに格納された一連の Recovery Manager コマンド スナップショット制御ファイル (snapshot control file) Recovery Manager がオペレーティング システムの特定の位置に作成したデータベースの制御ファイルのコピー Recovery Manager は リカバリ カタログの再同期化または制御ファイルのバックアップを実行する場合 スナップショット制御ファイルを作成して制御ファイルの一貫性のあるバージョンを取得する 制御ファイルの自動バックアップ (control file autobackup) 現行の制御ファイルの自動バックアップは Recovery Manager が次の状況で実行する Recovery Manager プロンプトで BACKUP コマンドが実行された後 RUN ブロック内に BACKUP コマンドがあり その後に別の BACKUP コマンドが続かない場合 制御ファイルの自動バックアップではデフォルトのファイル名が使用されるため 制御ファイルやリカバリ カタログが消失した場合でも Recovery Manager はそのファイル名を使用して制御ファイルをリストアできる デフォルトのファイル名は必要に応じて変更できる 全体バックアップ (full backup) Recovery Manager による非増分バックアップ この場合の 全体 とは データベースのバックアップの割合を示しているのではなく バックアップが増分バックアップではないことを示している したがって 1 つのデータ ファイルの全体バックアップを作成することは可能である 用語集 -7

206 増分バックアップ (incremental backup) 修正されたブロックのみのバックアップが作成される Recovery Manager バックアップ 増分バックアップはレベルレベルによって分類される レベル 0 の増分バックアップと全体バックアップは 使用済のブロックすべてのバックアップを作成するという点で 同じ機能である ただし 全体バックアップでは それ以降に実行される増分バックアップで バックアップされるブロックに影響はないが 増分バックアップでは それ以降に実行される増分バックアップでバックアップされるブロックに影響が及ぶという相違がある レベル 1 の増分バックアップの場合 前回の増分バックアップ以降に変更されたブロックのみのバックアップが作成される 前回の増分バックアップ以降変更されていないブロックのバックアップは作成されない 増分バックアップは 差分増分バックアップ差分増分バックアップまたは累積増分バックアップのいずれかである 累積増分バックアップでは レベル 1 の最新のバックアップが行われた後 変更されたすべてのブロックをバックアップする 差分増分バックアップでは レベル 1 または 0 の最新の増分バックアップが行われた後 変更されたすべてのブロックをバックアップする ターゲット データベース (target database) Recovery Manager でバックアップまたはリストアするデータベース 多重化 (multiplexing) オンライン REDO ログ同じ内容の複数のオンライン REDO ログのコピーを 自動的にメンテナンスすること 制御ファイル同じ内容の複数のデータベース制御ファイルのコピーを 自動的にメンテナンスすること バックアップ セットデータベース ファイルをディスクから同時に読み取り そのブロックを同一のバックアップ ピースに書き込む Recovery Manager の機能 アーカイブ REDO ログ Oracle アーカイバ プロセスは REDO ログのコピーを複数アーカイブできる ミラー化ミラー化 を参照 妥当性チェック (validation) バックアップがリストア可能かどうかをチェックするテスト Recovery Manager はバックアップをスキャンし チェックサムを参照してこれらの内容が正しくリストアできるかどうかを検証する クロスチェッククロスチェック メディア マネージャメディア マネージャ リカバリ カタログリカバリ カタログ を参照 チェックポイント (checkpoint) データベースの REDO スレッドに SCN を定義するデータ構造 チェックポイントは制御ファイルと各データ ファイル ヘッダーに記録されており リカバリの重要な要素である チャネル (channel) Recovery Manager とターゲット データベースとの間の接続 割り当てられた各チャネルは 新しい Oracle サーバー セッションを開始する このセッションは バックアップ リストアおよびリカバリ操作を実行する チャネルは DISK チャネル ( ディスク I/O の実行に使用される ) または sbt チャネル ( サード パーティのメディア マネージャメディア マネージャを介した I/O の実行に使用される ) のいずれかになる メディア マネージャメディア マネージャ ターゲット データベースターゲット データベース を参照 長期バックアップ (long-term backup) バックアップの保存方針からは逸脱するが リカバリ カタログには記録するバックアップ 通常 長期バックアップは レポート生成に将来使用する可能性があるデータベースのスナップショットである 用語集 -8

207 データ ファイルのメディア リカバリ (datafile media recovery) より現在時刻に近い時点にロールフォワードするために リストアされたデータ ファイルに REDO レコードを適用する ブロック メディア リカバリブロック メディア リカバリを実行している場合を除いて リカバリ中はデータ ファイルをオフラインにする必要がある データベース識別子 (database identifier) DBID を参照 データベース全体のバックアップ (whole database backup) 制御ファイルおよびデータベースに属するすべてのデータ ファイルのバックアップを作成する バックアップバックアップ を参照 データベース チェックポイント (database checkpoint) 最も低い SCN のスレッド チェックポイント データベース チェックポイントより前のすべての有効なスレッドにおけるすべての変更がディスクに書き込まれていることが保証される チェックポイントチェックポイント を参照 データベースの Point-in-Time リカバリ (DBPITR) データベース全体を 指定した過去の目標時点 SCN またはログ順序番号の状態にリカバリする 不完全リカバリ不完全リカバリ 表領域の Point-in-Time リカバリ を参照 ディスク コントローラ (disk controller) 1 つ以上のディスク ドライブを制御するハードウェア コンポーネント ディスク割当て制限 (disk quota) ユーザーが指定するフラッシュ リカバリ領域フラッシュ リカバリ領域のサイズの制限 ディスク割当て制限に達すると 不要になったファイルが自動的に削除される 登録 (registration) Recovery Manager で REGISTER DATABASE コマンドを実行し ターゲット データベースの存在をリカバリ カタログに記録する ターゲット データベースは その DBID によってカタログ内で一意に識別される 同じカタログに複数のデータベースを登録することも 複数のカタログに同じデータベースを登録することもできる DBID を参照 トランスポータブル表領域 (transportable tablespace) 表領域のセットを あるデータベースから別のデータベースに または再度そのデータベースにトランスポートする機能 表領域をデータベースにトランスポートすることと あらかじめロードされたデータを使用して表領域を作成することは類似している バイナリ圧縮 (binary compression) 圧縮技術で Recovery Manager がバックアップ セットにバックアップされるデータに適用している圧縮アルゴリズム パスワード ファイル (password file) ORAPWD コマンドで作成され ネットワークを介して SYSDBA または SYSOPER ロールを使用して接続する場合に必要なファイル パスワード ファイルの詳細は Oracle Database 管理者ガイド を参照 用語集 -9

208 破損ブロック (corrupt block) Oracle 形式で認識されない または内容に一貫性がない Oracle ブロック 通常 破損の原因はハードウェアの故障またはオペレーティング システムの問題である 破損ブロックは 論理的破損 (Oracle 内部エラー ) またはメディア破損 ( 形式が正しくないブロック ) のいずれかとして識別される メディア破損ブロックは ブロックをリカバリするか または破損ブロックを含むデータベース オブジェクトを削除して他のオブジェクトで再利用できるようにすることで修復できる メディア破損の原因がハードウェア故障の場合 前述のどちらの解決策も そのハードウェアの故障を直さなければ効果がない ブロック メディア リカバリブロック メディア リカバリ を参照 バックアップ (backup) (1) データベース 表領域 表 データ ファイル 制御ファイル アーカイブ REDO ログなどのデータのバックアップ コピー バックアップは物理バックアップ ( データベース ファイル レベル ) または論理バックアップ ( データベース オブジェクト レベル ) として作成できる 物理バックアップは Recovery Manager を使用して 1 つ以上のデータ ファイル 制御ファイルまたはアーカイブ ログをバックアップすることによって作成できる 論理バックアップは Oracle エクスポート ユーティリティ (Data Pump Export または従来のエクスポート ) の 1 つを使用して作成できる (2) バックアップ セット プロキシ コピーまたはディスク ベースのイメージ コピーを作成する Recovery Manager コマンド コピーコピー バックアップ セットバックアップ セット 多重化多重化 RMAN を参照 バックアップ データベース全体 (backup, whole database) データベース全体のバックアップデータベース全体のバックアップ を参照 バックアップおよびリカバリ (backup and recovery) データベースをメディア障害やユーザー エラーによるデータ消失から保護する作業に関係する概念 手順および方針 バックアップ制御ファイル (backup control file) 制御ファイルのバックアップ 制御ファイルは Recovery Manager の backup コマンドや SQL の ALTER DATABASE BACKUP CONTROLFILE TO 'filename' 文を使用してバックアップできる バックアップ セット (backup set) 1 つ以上のデータ ファイル 制御ファイル SPFILE およびアーカイブ REDO ログ ファイルのバックアップ 各バックアップ セットは バックアップ ピースバックアップ ピースと呼ばれる 1 つ以上のバイナリ ファイルで構成される バックアップ ピースは専用の形式で記述され Recovery Manager によってのみ作成およびリストアされる バックアップ セットは Recovery Manager の BACKUP コマンドで生成される 通常 バックアップ セットは 1 つのバックアップ ピースのみで構成される Recovery Manager でバックアップ セットの内容が複数のバックアップ ピースに分割されるのは ALLOCATE CHANNEL コマンドまたは CONFIGURE CHANNEL コマンドの MAXPIECESIZE オプションを使用してバックアップ ピース サイズを制限している場合のみである バックアップ ピースバックアップ ピース 未使用ブロックの圧縮未使用ブロックの圧縮 多重化多重化 RMAN を参照 バックアップ ピース (backup piece) Recovery Manager のバックアップ セットの格納に使用される物理ファイルの形式 バックアップ バックアップ セットバックアップ セット RMAN を参照 バックアップ保存方針 (backup retention policy) 保存方針保存方針 を参照 用語集 -10

209 バックアップ モード (backup mode) オンライン バックアップを作成する前に ALTER TABLESPACE... BEGIN BACKUP コマンド または ALTER DATABASE BEGIN BACKUP コマンドを発行するときに開始するデータベース モード ( ホット バックアップ モードとも呼ばれる ) 表領域のバックアップ モードを解除するには ALTER TABLESPACE... END BACKUP または ALTER DATABASE END BACKUP コマンドを発行する オンライン表領域のデータ ファイルのユーザー管理バックアップを作成する場合は このコマンドを使用する必要がある Recovery Manager を使用している場合は データベースをバックアップ モードにする必要はない バックアップ モードでは データベースを更新すると通常より多くの REDO が作成される Oracle では バッファ キャッシュ内のブロックが使用済になるたびに データに対する変更の記録に加えて 変更されたブロックのイメージを REDO ログに書き込む必要がある 破損ブロック破損ブロック オンライン バックアップオンライン バックアップ を参照 パラレル化 (parallelization) 複数のチャネルを Recovery Manager のバックアップ処理およびリカバリ処理に割り当てる パラレル リカバリ (parallel recovery) リカバリ方式の 1 つで 複数のプロセスが REDO ログ ファイルからの変更を同時に適用する RECOVERY_PARALLELISM 初期化パラメータまたは SQL*Plus の RECOVER コマンドにオプションを指定すると インスタンスおよびメディア リカバリのパラレル化を自動的に実行できる 非一貫性バックアップ (inconsistent backup) バックアップの一部のファイルに それらのファイルのチェックポイント以降の変更が含まれるバックアップ このタイプのバックアップに一貫性を持たせるには リカバリ処理が必要である 非一貫性バックアップは 通常 オンライン データベースのバックアップ時に作成される 非一貫性バックアップは データベースがクローズ状態であっても 次のような場合に作成される Oracle インスタンス (RAC 構成内のすべてのインスタンス ) がクラッシュした直後 SHUTDOWN ABORT によってデータベースを停止した後 非一貫性バックアップが有効なのは データベースが ARCHIVELOG モードであり バックアップ以降に作成されたすべてのアーカイブ REDO ログが使用可能である場合のみである 一貫性バックアップ一貫性バックアップ オンライン バックアップオンライン バックアップ システム変更番号システム変更番号 データベース全体のバックアップ を参照 非循環再利用レコード (noncircular reuse records) Oracle データベースに必要な 重要な情報が含まれる制御ファイル レコード これらのレコードは 自動的に上書きされない 非循環再利用レコードに含まれる情報には データ ファイルやオンライン REDO ログの場所などがある 循環再利用レコード循環再利用レコード を参照 表領域の Point-in-Time リカバリ (tablespace point-in-time recovery: TSPITR) 1 つ以上の非 SYSTEM 表領域を現行以外の時刻までリカバリする Recovery Manager またはユーザー管理の方式を使用して TSPITR を実行できる ファジー ファイル (fuzzy file) チェックポイント SCN と同じか より新しい SCN が割り当てられたブロックを ブロック ヘッダーに少なくとも 1 つ含んでいるデータ ファイル たとえば バックアップ モードバックアップ モードのデータ ファイルが Oracle によって更新されると このような状況が発生する リストアされたファジー ファイルは 必ずリカバリを実行する必要がある 用語集 -11

210 不完全リカバリ (incomplete recovery) データベースの Point-in-Time リカバリの同義語 完全リカバリ完全リカバリ メディア リカバリメディア リカバリ リカバリするリカバリする を参照 複製データベース (duplicate database) Recovery Manager の duplicate コマンドを使用して ターゲット データベースのバックアップから作成したデータベース 補助データベース補助データベース を参照 物理スキーマ (physical schema) ある時点でのデータベース内のデータ ファイル 制御ファイルおよび REDO ログ 表領域とデータ ファイルのリストを取得するには Recovery Manager の REPORT SCHEMA コマンドを発行する 部分再同期化 (partial resynchronization) 再同期化のタイプ この同期化では Recovery Manager はアーカイブ ログ バックアップ セットおよびデータ ファイルのコピーに関するデータを ターゲット制御ファイルからリカバリ カタログに転送する フラッシュバック ログ (flashback logs) データベースのフラッシュバック操作の実行に使用される Oracle によって生成されるログ フラッシュバック ログは フラッシュ リカバリ領域にのみ書き込むことができる フラッシュバック ログは ディスクにバックアップすることはできない フラッシュ リカバリ領域 (flash recovery area) リカバリに関連するファイル ( 制御ファイル オンライン REDO ログのコピー アーカイブ ログ フラッシュバック ログ Recovery Manager バックアップなど ) の格納に使用できる任意のディスクの位置 フラッシュ リカバリ領域にあるファイルは Oracle や Recovery Manager によって自動的に管理される フラッシュ リカバリ領域の最大サイズは ディスク割当て制限で指定できる プロキシ コピー (proxy copy) Recovery Manager のバックアップ処理とリストア処理時に メディア マネージャメディア マネージャがメディア ストレージ デバイスとディスク間のデータ転送を管理するバックアップ ブロック チェンジ トラッキング (block change tracking) データベースの各更新に影響を受けたデータ ファイル ブロックを Oracle に追跡させるデータベース オプション 追跡情報は チェンジ トラッキング ファイルと呼ばれる新しい形式のファイルで格納される ブロック チェンジ トラッキングが有効になっている場合 Recovery Manager は チェンジ トラッキング ファイル内の変更されたブロックの記録を使用して データ ファイル全体を読み取るのではなく 変更されたことがわかっているブロックのみを読み取ることによって 増分バックアップのパフォーマンスを向上させる ブロック メディア リカバリ (block media recovery) Recovery Manager の BLOCKRECOVER コマンドを使用してデータ ファイル内の指定ブロックをリカバリする ブロック メディア リカバリでは 対象となるデータ ファイルはオンラインのままで 破損ブロックのみがリストアおよびリカバリされる 平均リカバリ時間 (Mean Time To Recover: MTTR) データベースに関するクラッシュ リカバリやメディア リカバリの実行に必要とされる時間 メディア リカバリの MTTR には 検出速度 メディア リカバリの実行に使用する方法 データベース サイズなどの様々な要因が影響を与える 用語集 -12

211 補助セット (auxiliary set) TSPITR において リカバリ セットにはないファイルの集合 ただし TSPITR 操作を正しく実行するには これらのファイルを補助データベースでリストアする必要がある 補助データベース補助データベース リカバリ セットリカバリ セット を参照 補助データベース (auxiliary database) (1)Recovery Manager の DUPLICATE コマンドを使用して ターゲット データベースのバックアップから作成したデータベース (2) 新しい場所にリストアされ 表領域の Point-in-Time リカバリ (TSPITR) 時に新しいインスタンス名で起動される一時データベース TSPITR 補助データベースは リカバリ セットと補助セットで構成される リカバリ セットリカバリ セット 補助セット補助セット 表領域の Point-in-Time リカバリ を参照 保存方針 (retention policy) メディア リカバリ用のバックアップとアーカイブ ログの保存期間を決定するユーザー定義の方針 保存方針は バックアップ冗長性またはリカバリ期間リカバリ期間で定義できる Recovery Manager は 現行の保存方針を満たすために必要なデータ ファイル バックアップ およびそれらのデータ ファイル バックアップの完全リカバリに必要なすべてのアーカイブ REDO ログを保持する ホット バックアップ (hot backup) オンライン バックアップオンライン バックアップ を参照 ホット バックアップ モード (hot backup mode) バックアップ モードバックアップ モード を参照 未使用ブロックの圧縮 (unused block compression) Recovery Manager がデータ ファイルのバックアップを含むバックアップ セットのサイズを縮小する方法 使用されていないデータ ファイルのブロックをスキップすることで行われる ブロックをスキップできる場合の詳細は Oracle Database バックアップおよびリカバリ リファレンス を参照 ミラー化 (mirroring) データと同じ内容のコピーを 1 つ以上のディスクでメンテナンスすること ミラー化は通常 二重化されたハードディスクにおいてオペレーティング システム レベルで実行する したがって いずれかのディスクが使用不可能になっても 中断することなくもう一方のディスクで要求の処理を継続できる ファイルをミラー化すると Oracle が 1 回書き込む間にオペレーティング システムは複数のディスクに書込みを行う ファイルを多重化多重化すると Oracle は複数のファイルに同じデータを書き込む メディア障害 (media failure) Oracle で使用される任意のファイル ( データ ファイル ログ ファイル 制御ファイルなど ) を含むディスクの破損 Oracle がメディア障害を検出すると 影響を受けたファイルがオフラインになる メディア リカバリメディア リカバリ を参照 メディア マネージャ (media manager) Recovery Manager と統合可能なサード パーティのネットワーク対応バックアップ システム これによって データベース バックアップを 3 次ストレージに直接書き込むことができるようになる 用語集 -13

212 メディア リカバリ (media recovery) リストアされたバックアップ データ ファイルまたは個々のデータ ブロックに REDO または増分バックアップを適用すること メディア リカバリでは データベース 表領域 データ ファイルまたはデータ ファイル内のブロックのセットをリカバリできる メディア リカバリは 完全リカバリ (REDO ログ内のすべての変更が適用される ) または不完全リカバリ ( 指定した時点までの変更のみが適用される ) のいずれかで実行できる メディア リカバリは データベースが ARCHIVELOG モードの場合にのみ実行できる ブロック メディア リカバリブロック メディア リカバリ リカバリするリカバリする を参照 ユーザー管理のバックアップ (user-managed backup) Recovery Manager 以外の方法 ( オペレーティング システムのユーティリティなど ) を使用して実行されるバックアップ たとえば UNIX の cp コマンドや Windows の copy コマンドを実行して ユーザー管理のバックアップを作成できる ユーザー管理のバックアップは オペレーティング システムのバックアップとも呼ばれる ユーザー管理のバックアップとリカバリ (user-managed backup and recovery) Recovery Manager を使用しない Oracle データベースのバックアップおよびリカバリ計画 オペレーティング システムのバックアップおよびリカバリとも呼ばれる オペレーティング システムのユーティリティ (UNIX の cp コマンドなど ) を使用してデータベース ファイルをバックアップおよびリストアし SQL*Plus の RECOVER コマンドを使用してリカバリできる リカバリ (recovery) データベース ファイルまたはデータベースに関して使用される場合は REDO データまたは増分バックアップをデータベース ファイルに適用して 消失した変更を再構築すること リカバリには インスタンス リカバリインスタンス リカバリ クラッシュ リカバリクラッシュ リカバリおよびメディア リカバリメディア リカバリの 3 つのタイプがある Oracle では オンライン REDO レコードを使用して 最初の 2 つのタイプのリカバリを自動的に実行する メディア リカバリを実行する場合のみ バックアップをリストアしてコマンドを発行する必要がある 完全リカバリ完全リカバリ 不完全リカバリ不完全リカバリ を参照 リカバリ カタログ (recovery catalog) Recovery Manager が 1 つ以上の Oracle データベースの Recovery Manager リポジトリ情報を格納する Oracle の表とビューのセット Recovery Manager はこのデータを使用して Oracle データベースのバックアップ リストアおよびリカバリを管理する リカバリ カタログの使用はオプションである データベースの Recovery Manager リポジトリ情報の主な格納場所は 常にターゲット データベースの制御ファイルである リカバリ カタログは 制御ファイル内の Recovery Manager リポジトリ データで定期的に更新される 制御ファイルが消失した場合 消失した情報のうち データベースのリストアおよびリカバリに必要な情報のほとんどまたはすべてはリカバリ カタログから取得できる リカバリ カタログには 長期バックアップおよびターゲット データベースで使用する Recovery Manager ストアド スクリプトのレコードも記録できる リカバリ カタログ データベースリカバリ カタログ データベース を参照 リカバリ カタログ データベース (recovery catalog database) リカバリ カタログのスキーマが設定されている Oracle データベース リカバリ カタログをターゲット データベースに格納しないよう注意する 用語集 -14

213 リカバリ期間 (recovery window) Recovery Manager バックアップ保存方針のタイプの 1 つ DBA が期間を指定し Recovery Manager が リカバリ期間内の任意の時点までの Point-in-Time リカバリに必要なバックアップおよびアーカイブ REDO ログが保存されることを保証する この期間は常に 現在の時刻で終了し ユーザーが指定した日数さかのぼる たとえば 保存方針が 7 日間のリカバリ期間で設定されている場合 現在の時刻が火曜日の午前 11 時であれば Recovery Manager は前の週の火曜日の午前 11 時までの Point-in-Time リカバリに必要なバックアップを保持する 保存方針保存方針 を参照 リカバリする (recover) データベース ファイルまたはデータベースのリカバリとは 通常 メディア リカバリ クラッシュ リカバリまたはインスタンス リカバリを実行することを指す データのリカバリ のように 一般的に 失われたデータを再構築または再作成することを示す場合にも使用される 完全リカバリ完全リカバリ 不完全リカバリ不完全リカバリ インスタンス リカバリインスタンス リカバリ クラッシュ リカバリクラッシュ リカバリ メディア リカバリメディア リカバリ を参照 リカバリ セット (recovery set) 表領域の Point-in-Time リカバリの実行時 以前の時点までのリカバリが行われる 1 つ以上の表領域 TSPITR を実行すると リカバリ セットのデータベース オブジェクトがすべて同じ時点の状態にリカバリされる 補助セット補助セット を参照 リストア (restore) 消失したファイルまたは破損したファイルを バックアップと置き換えること ファイルをリストアするには たとえば UNIX の cp コマンドまたは Recovery Manager の RESTORE コマンドを使用する 累積増分バックアップ (cumulative incremental backup) レベル 0 の最新のバックアップ以降に変更されたすべてのブロックをバックアップする増分バックアップ 累積増分バックアップを使用してリカバリするときは 最新の累積増分バックアップを 1 つのみ適用する必要がある 差分増分バックアップ差分増分バックアップ 増分バックアップ増分バックアップ を参照 ロールバック (rolling back) リカバリするのロールフォワードロールフォワード段階でデータベースに適用される コミットされていない変更を ロールバック セグメントを使用して取り消すこと ロールバック セグメント (rollback segments) データベースの変更前のイメージを記録するデータベース セグメント ロールフォワード (rolling forward) REDO レコードまたは増分バックアップをデータ ファイルおよび制御ファイルに適用して これらのファイルに加えた変更をリカバリすること リカバリするリカバリする ロールバックロールバック を参照 ログ順序番号 (log sequence number) REDO ログ ファイルの REDO レコードのセットを一意的に識別するための番号 あるオンライン REDO ログ ファイルが一杯になって別のオンライン REDO ログ ファイルに切り替わると Oracle は新しいファイルにログ順序番号を自動的に割り当てる ログ スイッチログ スイッチ REDO ログ を参照 用語集 -15

214 ログ スイッチ (log switch) LGWR がアクティブな REDO ログ ファイルへの書込みを停止し 使用可能な次の REDO ログ ファイルに切り替える時点 アクティブなログ ファイルが REDO レコードで一杯になった場合 あるいは手動で切替えを強制的に実行した場合に LGWR によって切り替えられる REDO ログ を参照 論理バックアップ (logical backups) 表などの データベース スキーマ オブジェクトのバックアップ 論理バックアップは Oracle Data Pump Export Utility または Oracle エクスポート ユーティリティを使用して作成およびリストアされる バックアップの作成に使用されたユーティリティに対応する Oracle インポート ユーティリティを使用して 論理バックアップからオブジェクトをリストアできる 用語集 -16

215 索引 A ALTER DATABASE 文 RENAME FILE 句,6-18 AVAILABLE オプション CHANGE,8-13 B BACKUP ARCHIVELOG,4-10 DELETE ALL,4-11 DELETE INPUT,4-11 FOR RECOVER OF COPY WITH TAG,4-16 PLUS ARCHIVELOG,4-11 BACKUP コマンド,4-2 CURRENT CONTROLFILE オプション,4-10 DELETE ALL INPUT オプション,4-11 DELETE INPUT オプション,4-11 C CATALOG コマンド,8-15 CHANGE... KEEP DELETE OBSOLETE,8-9,8-14 CHANGE コマンド,8-4 AVAILABLE オプション,8-13 UNAVAILABLE オプション,8-13 UNCATALOG オプション,8-18 CONTROL_FILE_RECORD_KEEP_TIME 初期化パラメータ,8-2 Recovery Manager レコードの上書きの防止,8-2 CONTROL_FILES 初期化パラメータ,6-15 CROSSCHECK コマンド,8-4 D Data Pump Export Utility バックアップ,2-12 DBPITR,7-18 DELETE OBSOLETE CHANGE... KEEP,8-9,8-14 DELETE コマンド,8-7,8-15 EXPIRED オプション,8-8 EXPIRED オプション DELETE,8-8 F Flashback Database 概要,1-12 フラッシュバック ログ,1-12 Flashback Drop,7-6 概要,1-12 ごみ箱,1-12,7-6 有効化と無効化,7-7 Flashback Query 概要,1-11 Flashback Table 概要,1-12 FLASHBACK TABLE 文,7-4,7-5 Flashback Transaction Query 概要,1-12 Flashback Version Query 概要,1-11 FORCE オプション DELETE コマンド,8-8 I INCLUDE CURRENT CONTROLFILE オプション BACKUP コマンド,4-9 I/O エラー削除中に無視する,8-8 K KEEP オプション BACKUP,8-14 L LIST コマンド,4-21,4-22 N NLS_DATE_FORMAT 環境変数,3-2 NLS_LANG 環境変数,3-2 E EXIT コマンド,3-2 索引 -1

216 O Oracle Flashback Database 概要,1-12 Oracle Flashback Drop 概要,1-12 Oracle Flashback Query 概要,1-11 Oracle Flashback Table 概要,1-12 Oracle Flashback Transaction Query 概要,1-12 Oracle Flashback Version Query 概要,1-11 P Point-in-Time リカバリ実行現行の制御ファイルの使用,7-22 Q QUIT コマンド,3-2 R Recovery Manager アーカイブ REDO ログバックアップ,4-10 コマンド CATALOG,8-15 CHANGE,8-4 DELETE,8-15 REPORT,4-29 RESTORE,6-7 時間パラメータの設定,3-2 切断,3-2 増分バックアップ差分,4-13 累積,4-14 レベル 0,4-13 データ ファイルのコピーバックアップ,4-9 データベース キャラクタ セット,3-2 データベース接続,3-6 カタログの指定なし,3-6 ターゲットに必要な SYSDBA,3-6 バックアップ,4-2 アーカイブ REDO ログ,4-10,4-12 検査,4-21 制御ファイル,4-9,4-10 制御ファイルのコピー,4-10 増分,4-12 データ ファイル,4-8,4-9 データベース全体,4-8 テスト,4-21 表領域,4-8,4-9 保存方針構成,3-18 メタデータ,8-1 リスト,4-22 リストアアーカイブ REDO ログ,6-20 レポート,4-28 データベース スキーマ,4-31 バックアップが必要なオブジェクト,4-29 不要なバックアップ,4-30 Recovery Manager の終了,3-2 Recovery Manager のテストバックアップ,4-21 Recovery Manager メタデータの管理,8-1 RECOVERY WINDOW パラメータ CONFIGURE コマンド,3-18 REDO ログアーカイブ モード,2-7 RENAME DATABASE 句 ALTER DATABASE 文,6-18 REPORT コマンド,4-21,4-28 NEED BACKUP オプション,4-29 RESTORE コマンド,6-7 S SYSDBA オプション Recovery Manager のターゲットへの接続時に暗黙的に使用,3-6 U UNAVAILABLE オプション CHANGE,8-13 UNCATALOG オプション CHANGE,8-18 リポジトリ レコードの削除,8-18 UNDO 表領域,1-5 UNDO ブロック,1-5 V V$DATABASE_BLOCK_CORRUPTION ビュー,4-21 V$FLASH_RECOVERY_AREA_USAGE,3-17 V$RECOVERY_FILE_DEST,3-17 あ アーカイブ REDO ログ Recovery Manager を使用したリストア,6-20 カタログに追加,8-15 バックアップ Recovery Manager を使用,4-10,4-12 バックアップ時の生成,4-11 アーカイブ モード,2-7 アーカイブ ログ ファイルバックアップ,4-10 他のバックアップ,4-11 バックアップ後の削除,4-11 圧縮バックアップ セット,4-6 アラート ログ制御ファイル レコードの上書きの監視,8-3 制御ファイル レコードのメッセージ,8-2 索引 -2

217 い 一貫性バックアップ Recovery Manager を使用,4-7 イメージ コピーリストアのテスト,6-12 インスタンスリカバリ,1-8 インスタンス リカバリ,1-8 インスタンス障害,1-8 概要,1-8 定義,1-8 読取り専用表領域,6-8 お オフライン バックアップ,2-10 オンライン REDO ログ多重,1-13 バックアップ,2-12 メディア障害,1-13 オンライン バックアップ,2-10 か ガイドラインバックアップ Data Pump Export Utility,2-12 構造変更,2-11 使用回数の多い表領域,2-11 頻度,2-10 古いバックアップの保管,2-10 リカバリ不能操作,2-11 可用性 Recovery Manager バックアップ,8-13 環境変数 NLS_DATE_FORMAT,3-2 NLS_LANG,3-2 き 期限切れのバックアップ削除,8-8 危険なバックアップ手段の回避,2-12 キャラクタ セット Recovery Manager で使用される設定,3-2 く クラッシュ リカバリ,1-8 インスタンス障害,1-8 インスタンス障害後,1-8 概要,1-8 読取り専用表領域,6-8 クロスチェック,8-4 バックアップおよびコピー,8-4 複数のチャネル,8-9 け 検査バックアップ,4-21 こ 構成 Recovery Manager 自動バックアップ,3-11 バックアップ保存方針,3-18 コピークロスチェック,8-4 コマンド Recovery Manager BACKUP CURRENT CONTROLFILE,4-10 CATALOG,8-15 CHANGE,8-4 CROSSCHECK,8-4 DELETE,8-15 LIST,4-22 REPORT,4-28 NEED BACKUP オプション,4-29 RESTORE,6-7 ごみ箱 Flashback Drop,1-12,7-6 オブジェクトのリストア,7-9 名前を変更されたオブジェクト,7-7 表示,7-8 有効化と無効化,7-7 さ サーバー パラメータ ファイル自動バックアップの構成,3-11 バックアップ,4-10 リストア,6-16 削除コピー,8-6 バックアップ,8-6,8-7 複数のチャネル,8-9 差分増分バックアップ,4-13 し 時間パラメータ Recovery Manager で使用される設定,3-2 時間ベースのリカバリ,7-18 自動バックアップ生成,4-9 障害インスタンスリカバリ,1-8 準備されている保護対策,1-3 説明,1-2,1-13 メディア,1-2,1-13 リカバリ も参照初期化パラメータ CONTROL_FILE_RECORD_KEEP_TIME,8-2 CONTROL_FILES,6-15 せ 制御ファイル概要,1-5 コピーバックアップ,4-10 自動バックアップ構成,3-11 索引 -3

218 バックアップ Recovery Manager を使用,4-9,4-10 データベース バックアップに含める,4-9 リストア,6-15 レコードの上書き,8-2 制御ファイルのコピーバックアップ,4-10 制御ファイルの自動バックアップ構成,3-11 データベースの構造変更時,3-11 制御ファイル レコード上書き,8-2 制御ファイル レコードの上書き,8-2 切断 Recovery Manager,3-2 そ 増分更新バックアップ,4-16 増分バックアップ,4-12 差分,4-13 増分更新,4-16 ブロック チェンジ トラッキング,4-18 ソフトウェア構成記録の保持,2-12 た 多重化リカバリ,1-13 ち チェンジ トラッキング,4-18 使用されるディスク領域,4-20 チェンジ トラッキング ファイルの移動,4-20 有効化と無効化,4-19 チャネル複数クロスチェックおよび削除,8-9 て ディスク障害,1-2,1-13 ディスク使用量監視,3-17 データ構造リカバリに必要,1-3 データ ファイルバックアップ Recovery Manager を使用,4-8,4-9 読取り専用リカバリ,6-8 データ ファイルのコピー Recovery Manager を使用したバックアップ,4-9 データベースアーカイブのモード,2-7 データベース スキーマレポートの生成,4-31 データベース接続 Recovery Manager カタログの指定なし,3-6 Recovery Manager でのタイプ,3-6 Recovery Manager に必要な SYSDBA,3-6 データベース全体のバックアップ Recovery Manager を使用,4-8 データベースの Point-in-Time リカバリ,7-18 時間ベースのリカバリ,7-18 データベースの Point-in-Time リカバリ (DBPITR) 定義,7-2 データベースのフラッシュバックデータベースのフラッシュバックの期間の確認,5-12 パフォーマンス チューニング,5-13 有効化,5-10 要件,5-10 領域管理,5-12 ディスク領域要件の見積り,5-11 ログ保持および削除の規則,5-12 データベース ライター プロセス (DBWn) メディア障害,1-14 は ハードウェア構成記録の保持,2-12 バックアップ Data Pump Export Utility,2-12 Recovery Manager,4-2 Recovery Manager のテスト,4-21 RESETLOGS の実行前のリカバリ,7-24 アーカイブ REDO ログ Recovery Manager を使用,4-10,4-12 一貫性 Recovery Manager を使用した作成,4-7 オフライン,2-10 オンライン,2-10 オンライン REDO ログ,2-12 ガイドライン,2-6 ~ 2-13 Data Pump Export Utility,2-12 構造変更,2-11 使用回数の多い表領域,2-11 頻度,2-10 古いバックアップの保管,2-10 リカバリ不能オブジェクト,2-11 可用性,8-13 期限切れ削除,8-8 クロスチェック,8-4 検査,4-21 サーバー パラメータ ファイル,4-10 避けるべき手段,2-12 制御ファイル Recovery Manager を使用,4-10 制御ファイルの自動バックアップ,4-9 増分,4-12 差分,4-13 定義,1-2 データ ファイル Recovery Manager を使用,4-8,4-9 データベース作成前の計画,2-6 データベース全体 Recovery Manager を使用,4-8 データベースの構造変更時,2-11 バックアップが必要なオブジェクトのレポート,4-29 索引 -4

219 非一貫性 Recovery Manager を使用した作成,4-7 表領域,2-11 Recovery Manager を使用,4-8,4-9 非累積増分,4-13 頻度,2-10 物理的な定義,1-2 方法機能の比較,1-15 保管,2-10 保存方針からの除外,8-14 累積増分,4-14 レコード,2-12 レポートの生成,4-21,4-28 ログの自動切替え,4-11 論理定義,1-2 バックアップおよびリカバリ定義,1-2 バックアップ セット圧縮,4-6 未使用領域の圧縮,4-3 リストアのテスト,6-12 バックアップ ピース定義,4-3 バックアップ方式,1-15 機能の比較,1-15 比較,1-15 バックアップ例ディスクとテープ,A-8 ディスクのみ,A-2 ひ 非一貫性バックアップ Recovery Manager を使用,4-7 表 FLASHBACK TABLE 文,7-5 フラッシュバック トランザクション問合せ,7-4 表領域 Recovery Manager を使用したバックアップ,4-8 バックアップ,2-11 頻度,2-11 リカバリのアクセス性データベースがオープン状態の場合,6-5 表領域のバックアップ Recovery Manager を使用,4-8,4-9 非累積増分バックアップ,4-13 ふ 不完全リカバリ定義,7-18 物理バックアップ,1-2 フラッシュバック削除オブジェクトのリストア,7-9 ごみ箱でのオブジェクト名,7-7 ごみ箱の問合せ,7-8 フラッシュバック トランザクション問合せ,7-4 フラッシュバック表使用,7-4,7-5 フラッシュ リカバリ領域 V$RECOVERY_FILE_DEST および V$FLASH_ RECOVERY_AREA_USAGE を使用したディスク使用量の監視,3-17 テープを使用したバックアップ例,A-8 バックアップ例,A-2 ブロック チェンジ トラッキング,4-18 有効化と無効化,4-19 ブロックの破損 V$DATABASE_BLOCK_CORRUPTION に格納,4-21 ほ 保証付きリストア ポイント,5-5 ストレージ スナップショットとの比較,5-5 フラッシュ リカバリ領域の領域使用状況,5-8 要件,5-7 保存方針構成,3-18 冗長性の構成,3-18 バックアップの除外,8-14 無効化,3-19 リカバリ期間,3-18 み 未使用ブロックの圧縮,4-3 未使用領域の圧縮,4-3 め メタデータ Recovery Manager の管理,8-1 メディア障害概要,1-2,1-13 メディア リカバリ概要,1-7 も モードアーカイブ ログ,2-7 ゆ ユーザー エラー,1-14 り リカバリ Point-in-Time 時間ベース,7-18 一般的な手順,6-6 インスタンス,1-8 インスタンス リカバリ,1-8 インスタンス障害,1-8 読取り専用表領域,6-8 クラッシュ,1-8 クラッシュ リカバリ,1-8 読取り専用表領域,6-8 準備,6-7 使用されるデータ構造,1-3 データベースの Point-in-Time,7-18 索引 -5

220 必要な障害,1-2,1-13 表領域,6-5 メディア,1-7 メディア リカバリ使用可能または使用禁止,2-7 リカバリ カタログカタログに追加 O/S バックアップ,8-15 更新オペレーティング システムの削除後,8-18 バックアップの削除,8-6 レコードの削除,8-7 ログ スイッチ レコード,8-15 リカバリ期間保存方針の構成,3-18 リカバリ不能操作バックアップ実行,2-11 リカバリ不能操作後のバックアップ実行,2-11 リストバックアップおよびコピー,4-27 リストアサーバー パラメータ ファイル,6-16 制御ファイル,6-15 テスト,6-12 リストアの妥当性検査,6-12 リストア ポイント使用,5-7 通常,5-4 保証付き,5-5 ストレージ スナップショットとの比較,5-5 要件,5-7 る 累積増分バックアップ,4-14 れ 例 Recovery Manager RESETLOG の実行前のバックアップのリカバリ, 7-24 レベル 0 の増分バックアップ,4-13 レポート,4-21,4-28 データベース スキーマ,4-31 バックアップが必要なオブジェクト,4-29 不要なバックアップ,4-30 リカバリ不能なバックアップ,4-30 ろ ロールバック セグメント,1-5 ログ スイッチリカバリ カタログ レコード,8-15 論理バックアップ,1-2 索引 -6