10g リリース2（10.2）
B19197-03
 目次 |
 索引 |
| Oracle Database 2日でデータベース管理者 10g リリース2（10.2） B19197-03 |
|
この章では、Oracle Enterprise Managerを使用したOracleデータベースのバックアップおよびリカバリについて説明します。Oracleのバックアップおよびリカバリの基本的な概念を説明し、推奨ディスクベース・バックアップ計画を使用したバックアップおよびリカバリ用にデータベースを構成する方法、その他の基本バックアップを行う方法およびバックアップのメンテナンスを実行する方法を示します。また、完全なデータベース・バックアップのリカバリ手順を簡単に示します。
|
注意: 推奨バックアップ計画を利用できるようにご使用のデータベースを設定する方法は、「基本的なバックアップおよびリカバリのためのデータベース構成」を参照してください。データベース・コンフィギュレーション・アシスタントを使用してデータベースを作成する場合に自動バックアップを構成するときは、この項の手順を実行する必要はありません。推奨バックアップ計画を使用して、自動日次バックアップ用に構成済のデータベースを作成する方法の詳細は、「DBCAを使用したデータベースの作成および構成」を参照してください。 |
この章の内容は次のとおりです。
通常、Oracleのバックアップおよびリカバリの中心は、ご使用のデータベースを完全に再構成できる、データベース・ファイルの物理バックアップにあります。Enterprise Managerに組み込まれているバックアップおよびリカバリ機能で保護されるファイルには、データファイル、制御ファイル、サーバー・パラメータ・ファイル（SPFILE）およびアーカイブREDOログ・ファイルが含まれます。ご使用のデータベースは、これらのファイルを使用して再構成できます。物理レベルで動作するバックアップ・メカニズムによって、データファイルの誤削除またはディスク・ドライブの障害などのファイル・レベルでの破損が防止されます。
論理レベルのバックアップ（表、表領域などのデータベース・オブジェクトのエクスポートなど）は、いくつかの用途で物理バックアップを補足する場合に有効です。ただし、データベース全体を保護することはできません。効果的なバックアップ計画は、物理レベルのバックアップに基づいている必要があります。
Oracleデータベースのフラッシュバック機能では、物理バックアップおよび論理バックアップにかわる効率的で簡単な方法として、物理データおよび論理データの様々なリカバリ・ツールが提供されます。このフラッシュバック機能によって、バックアップからのデータファイルのリストアしたり、メディア・リカバリを実行することなく、データベースに対して行った不要な変更を元に戻すことができます。
この章では、次の論理レベルのフラッシュバック機能の概要を示します。
いずれの機能にも、詳細な準備（消失したデータを元に戻すことができる論理レベルのエクスポートなど）は必要ありません。両方ともデータベースが使用可能な場合に使用できます。Oracleデータベースのフラッシュバック機能の詳細は、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。
Oracle Enterprise Managerの物理バックアップ機能および物理リカバリ機能は、Recovery Manager（RMAN）コマンドライン・クライアントに基づいて構築されています。Enterprise Managerでは、Recovery Managerの様々な機能を利用でき、ウィザードおよび自動計画を使用してRecovery Managerベースのバックアップおよびリカバリを簡素化したり、さらには自動化します。
ご使用のデータベースをバックアップすることは、データファイル、制御ファイルおよびアーカイブREDOログ（データベースがARCHIVELOGモードで実行されている場合）のバックアップ・コピーを作成することです。バックアップからのデータベースのリストアは、通常のデータベース操作時に、データベースを構成する物理ファイルをバックアップ・メディア（ディスクまたはテープ）からそれぞれの位置にコピーすることを意味します。データベースのリカバリは、通常、REDOログ・ファイルを使用して、バックアップ以降にデータベースに対して行われた変更を反映し、バックアップからリストアされたデータベース・ファイルを更新するプロセスです。
バックアップには一貫性と非一貫性があります。バックアップ時に、データファイルに適用されていない変更がREDOログにない場合は、バックアップに一貫性があります。
一貫性バックアップを作成するには、データベースを正常に停止しておく必要があります。バックアップ中は、再びオープンすることはできません。データベースの停止時に、REDOログ内のすべてのコミット済の変更がデータファイルに書き込まれるため、トランザクションの一貫性がデータファイルで確保されます。このプロセスは、バックアップ中にデータベース全体がオフラインになるため、オフライン・バックアップと呼ばれます。
一貫性バックアップとは対照的に、非一貫性バックアップは、データベースがオープンしている間に作成されます。非一貫性バックアップでは、データファイルに適用されていない変更がオンラインREDOログに含まれます。トランザクションの一貫性はデータファイルで確保されません。データベースをARCHIVELOGモードで実行してREDOログを保存する必要があります。これらの変更を保存するには、バックアップ時のオンラインREDOログをデータファイルとともにアーカイブおよびバックアップする必要があります。
その名前にもかかわらず、非一貫性バックアップは、一貫性バックアップと同様にバックアップの確実な方法です。非一貫性バックアップを作成する最大のメリットは、データベースがオープン状態で更新可能な場合にデータベースをバックアップできることです。
一貫性バックアップからデータファイルをリストアすると、データベースをすぐにオープンできます。非一貫性バックアップからデータファイルをリストアすると、REDOログに記録されたコミット済の変更がデータファイルに適用され、トランザクションの一貫性が確保されるまで、データベースをオープンできません。非一貫性バックアップからリストアされたデータファイルにREDOログからの変更を適用するプロセスは、メディア・リカバリと呼ばれます。
バックアップからアーカイブREDOログおよびデータファイルをリストアする場合は、データベースをオープンする前に、メディア・リカバリを実行する必要があります。データファイルに反映されていないアーカイブREDOログ内のデータベース・トランザクションがデータファイルに適用され、データベースをオープンする前にトランザクションの一貫性が確保されます。
メディア・リカバリには、制御ファイル、（通常はバックアップからリストアされる）データファイル、およびデータファイルがバックアップされた時点以降に行われた変更を含むオンラインREDOログおよびアーカイブREDOログが必要です。多くの場合、メディア・リカバリは、メディア障害（ファイルやディスクの損失など）またはユーザー・エラー（表の内容の削除など）からのリカバリに使用されます。
メディア・リカバリには、完全リカバリおよびPoint-in-Timeリカバリの2つの形式があります。完全リカバリでは、バックアップからデータファイルがリストアされ、アーカイブREDOログおよびオンラインREDOログからすべての変更がデータファイルに適用されます。データベースは障害発生直前の状態に戻り、コミットされた変更を失うことなくオープンできます。
Point-in-Timeリカバリでは、データベースは、過去に選択したターゲット時刻の内容に戻されます。ターゲット時刻より前に作成したデータファイルのバックアップ、およびそのバックアップを行った時刻からターゲット時刻までのすべてのアーカイブREDOログ・ファイルから開始します。リカバリ中、バックアップ時刻からターゲット時刻までのすべての変更がデータファイルに適用されます。
Point-in-Timeリカバリでは、データベース全体を、バックアップを行った時点とアーカイブREDOログ内の最新の変更が行われた時点の間の任意の時点の状態に戻すことができます。ターゲット時刻後のすべての変更が破棄されます。Point-in-Timeリカバリは、データベースに対して行った一部の変更をリカバリしないことから、不完全リカバリとも呼ばれます。
Enterprise Managerでは、完全リカバリとPoint-in-Timeリカバリの両方に対して有効なインタフェースがリカバリ・ウィザードの形式で提供されています。ただし、このマニュアルでは主に完全リカバリについて説明します。Point-in-Timeリカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。
バックアップおよびリカバリに関連するファイルの管理を簡単にするために、Oracleでは、データベースのフラッシュ・リカバリ領域を作成できます。次の情報を指定する必要があります。
その後、バックアップ関連アクティビティ（REDOログのアーカイブなど）で、生成されたファイルをフラッシュ・リカバリ領域に格納できます。Oracleデータベースでは、この記憶域が自動的に管理され、他のファイルで領域が必要な場合にリカバリ目標を満たすために、ディスク上で不要になったファイルが削除されます。テープに移動したバックアップは、フラッシュ・リカバリ領域から自動削除できます。バックアップを定期的にテープにコピーすることによって、他のファイル用にフラッシュ・リカバリ領域が解放されます。
フラッシュ・リカバリ領域を使用すると、バックアップ記憶域の管理タスクが簡単になります。そのため、これは推奨される方法です。特に指定していないかぎり、この章の例は、フラッシュ・リカバリ領域の使用を前提としています。
Recovery Managerによって、データベースのすべてのデータファイル、バックアップ・ファイル、リカバリ・ファイルおよびバックアップ履歴のレコードが保持されます。このレコードは、Recovery Managerリポジトリと呼ばれます。
Recovery ManagerまたはEnterprise Managerを使用して実行するすべてのバックアップ操作は、Recovery Managerによってディスクまたはテープ上に作成されたすべてのバックアップの位置およびその他のメタデータとともに、リポジトリに記録されます。Recovery Managerを使用せずにファイルをバックアップした場合（ホスト・オペレーティング・システム・レベルでディスク上にファイルをコピーしてバックアップした場合など）は、そのコピーに関する情報をRecovery Managerリポジトリにも追加できます。リカバリ時に、RESTORE DATABASEなどのコマンドを発行できます。Oracleでは、リカバリの実行に必要なディスクおよびテープ上のバックアップの選択に、リポジトリのレコードが使用されます。
Recovery Managerリポジトリの主要位置は、データベース制御ファイルです。これは、制御ファイルの保護がバックアップ計画において重要であることのもう1つの理由です。一部のインストールでは、1つ以上のOracleデータベース用にRecovery Managerリポジトリの2つ目のコピーが、リカバリ・カタログと呼ばれる一連の表に格納されます。リカバリ・カタログは、個別のOracleデータベースに格納されます。リカバリ・カタログの使用はオプションのため、詳細は、このマニュアルでは説明しません。
バックアップおよびリカバリのファイルおよびプロセスを自動管理するOracleデータベースの機能を最大限に活用するには、データベースを次のように構成します。
ARCHIVELOGモードで実行。
また、バックアップするファイル、バックアップをディスクに格納する形式、フラッシュ・リカバリ領域からファイルを削除できる時期などを管理する多数のポリシーを設定する必要があります。
フラッシュ・リカバリ領域は、データベース・ファイルの作業セットとは別のディスクに格納する必要があります。そうしないと、ディスクがデータベースのシングル・ポイント障害になります。
フラッシュ・リカバリ領域に割り当てるディスク領域の量は、データベースのサイズとアクティビティ・レベル（データファイルおよびREDOログ・ファイルのサイズを決定）およびリカバリ目標によって異なります。目標では、バックアップの種類、時期、保存期間を指定します。
フラッシュ・リカバリ領域における領域管理は、バックアップ保存方針によって管理されます。保存方針によって、ファイルが不要になる時期（ファイルがデータのリカバリ目標を満たす必要がなくなる時期）を決定します。保存方針は、バックアップの冗長性またはリカバリ期間に基づきます。
冗長性ベースの方針では、指定した数の最新バックアップのレコードがRecovery Managerリポジトリに存在する場合にのみ、そのファイルのバックアップがフラッシュ・リカバリ領域によって不要であるとみなされます。たとえば、保存方針で、各ファイルに対して2つのバックアップを保存する必要があるとします。月曜日の夜に夜間バックアップを開始します。水曜日の夜間バックアップが正常に実行された後は、火曜日と水曜日のバックアップが使用可能なため、月曜日の夜間バックアップが冗長となります。
リカバリ期間ベースの方針では、1日単位で時間間隔を指定します。ファイルは、現在からその日数前までの間のある時点への完全リカバリまたはPoint-in-Timeリカバリを実行する必要がなくなった場合にのみ不要になります。たとえば、3日間のリカバリ期間を指定するとします。3日以上前からのすべてのデータファイルのバックアップが、そのバックアップ以降に生成されたアーカイブREDOログの完全なセットとともに保存されている必要があります。
冗長性ベースの保存方針によって、より簡単にフラッシュ・リカバリ領域内の領域使用率を予測できますが、過去のどの時点までデータベースをリカバリできるかは予測できません。リカバリ期間ベースの方針では、データ保護が強化されますが、バックアップの記憶域要件の予測が難しくなる場合があります。前述したとおり、設計が不完全なバックアップ計画では、短いリカバリ期間を指定した場合でも、予想以上に領域要件が高くなる場合があります。リカバリ期間ベースの保存方針は、設計が完全なバックアップ計画の中で使用することをお薦めします。
通常、フラッシュ・リカバリ領域内のファイルは、不要になった後でも、新しいファイルを格納するために領域が必要になるまでフラッシュ・リカバリ領域から削除されません。領域に余裕があるかぎり、最近テープに移動したファイルをディスクにも残すことによって、リカバリ時にテープからファイルを取得する必要がなくなります。
フラッシュ・リカバリ領域から不要ファイルおよびテープに移動したファイルを自動削除することで、REDOログのアーカイブ先の利便性が高まります。他のアーカイブ先では、リカバリが不要になったディスクのアーカイブREDOログを手動でクリーンアップする必要があります。
フラッシュ・リカバリ領域のサイズ変更方法の詳細は、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。ただし、原則として、フラッシュ・リカバリ領域を大きくすることをお薦めします。フラッシュ・リカバリ領域は、すべてのデータファイルおよび制御ファイルのコピー、オンラインREDOログ、および保存方針に従って保存されたデータファイル・バックアップを使用してデータベースをリカバリするために必要なアーカイブREDOログ・ファイルを保持できる大きさが理想的です。
バックアップ計画に増分バックアップ（「データファイルの増分バックアップ」を参照）が含まれている場合は、これらのファイルも十分に保持できる領域をフラッシュ・リカバリ領域に追加します。一部のバックアップをテープに移動できる場合は、フラッシュ・リカバリ領域のサイズを小さくできます。これらのファイルをテープから取得すると、データベースのリストアおよびリカバリの時間が長くなることに注意してください。
バックアップおよびリカバリの一部の構成タスクの実行、バックアップ・ジョブのスケジュールおよびリカバリの実行には、適切な資格証明が必要です。次の資格証明が必要な場合があります。
Recovery Managerのタスクを実行およびスケジュールするには、SYSDBA権限を持つユーザーとしてEnterprise Managerにログインするか、またはDBAグループのメンバーであるユーザーのホスト・オペレーティング・システムの資格証明を指定する必要があります。また、ホスト・オペレーティング・システム・ユーザーには、Recovery Managerコマンドライン・クライアントの実行権限も必要です。
ホスト・オペレーティング・システムの資格証明が必要なタスクの場合は、「ホスト資格証明」フォームが、タスクの実行に使用するページの下部に表示されます（図9-1を参照）。Enterprise Managerでは、Recovery Managaerを起動して要求またはスケジュールしたジョブを実行する際に資格証明が使用されます。
「ホスト資格証明」フォームには、常に、「優先資格証明として保存」とラベル付けされたチェックボックスが含まれています。操作を実行する前にこのチェックボックスを選択すると、指定した資格証明が現在ログインしているOracleユーザー用に永続的に格納されます。そのユーザーとしてログインし、ホスト資格証明が必要な操作を実行するたびに、デフォルトで優先資格証明が再利用されます。
フラッシュ・リカバリ領域は、データベースを初めて作成する際に構成できます。ただし、データベースの作成時にこのタスクを実行しなかった場合でも、この時点でデータベースのフラッシュ・リカバリ領域を作成できます。
フラッシュ・リカバリ領域を構成するには、次の手順を実行します。
「メンテナンス」プロパティ・ページが表示されます。
「リカバリ設定」ページが表示されます。
フラッシュ・リカバリ領域内の領域使用量を監視して、フラッシュ・リカバリ領域がバックアップ・ファイルおよびその他のリカバリ関連ファイルの格納に十分な大きさであることを確認する必要があります。ホームページの「高可用性」セクションには、フラッシュ・リカバリ領域の使用可能な領域の割合が表示されます。「使用可能なフラッシュ・リカバリ領域」をクリックして、「リカバリ設定」ページに移動します。このページには、各タイプに割り当てられている領域の量および空き領域の量を示す「フラッシュ・リカバリ領域の使用量」グラフが含まれています。
データベースを初めて作成する際にARCHIVELOGモードを構成しなかった場合は、この時点で次の手順に従って構成できます。この手順で、アーカイブ・ログがフラッシュ・リカバリ領域のみに格納されるように指定します。これは、アーカイブREDOログをメンテナンスする場合に最適な方法です。
データベースをARCHIVELOGモードにするには、次の手順を実行します。
「リカバリ設定」プロパティ・ページが表示されます。
USE_DB_RECOVERY_FILE_DESTに設定されています。ディスク上の他の位置も指定できます。データベースの管理を簡単にするには、フラッシュ・リカバリ領域のみをREDOログのアーカイブ先として使用することをお薦めします。フラッシュ・リカバリ領域にのみアーカイブ・ログを格納するには、他の位置を空白のままにします。
ご使用のデータベースがARCHIVELOGモードで実行されていなかった場合は、データベースを再起動してARCHIVELOGモードへの切替えを有効にすることが求められます。
「データベースの再起動: ホストとターゲット・データベースの資格証明の指定」ページが表示されます。
「データベースの再起動: 確認」ページが表示されます。
ARCHIVELOGモードに切り替えた直後に、データベース全体の一貫性（オフライン・）バックアップを実行します。
オフライン・データベース・バックアップの詳細は、「Enterprise Managerによるバックアップの実行およびスケジュール」を参照してください。
注意:
ARCHIVELOGモードに切り替える前のバックアップは、切替え後のある時点へのデータベースのリストアおよびリカバリには使用できません。したがって、切替え直後にバックアップを実行しなかった場合は、バックアップなしでデータベースを実行していることになります。
構成済フラッシュ・リカバリ領域があり、ARCHIVELOGモードで実行中の場合、バックアップの格納方法、バックアップされるデータ、バックアップがフラッシュ・リカバリ領域から削除されるまでの保持時間を決定する多数の設定およびポリシーを構成できます。ご使用の環境に対してバックアップのパフォーマンスが最適化されるように構成することもできます。この項では、使用可能な設定の基礎となる概念およびEnterprise Managerを使用してそれらの設定を変更する方法について説明します。
ディスクおよびテープにバックアップを書き込む方法は、「バックアップ設定」ページの「デバイス」プロパティ・ページの設定によって影響されます。ディスク・ベース・バックアップの場合は、バックアップを格納するためのデフォルトの形式、ディスク上のバックアップを格納する位置、およびパフォーマンスを向上させるためにバックアップ・タスクをパラレルで実行するかどうかを構成できます。
Recovery Managerによって作成されたデータベースのバックアップは、イメージ・コピーまたはバックアップ・セットの2つの形式のいずれかで格納できます。
イメージ・コピーは、バックアップするファイルのバイト単位の正確なコピーです。ホスト・オペレーティング・システム・レベルでファイルをコピーして作成できます。ただし、オペレーティング・システム・レベルでのファイルのコピーとは異なり、Recovery ManagerまたはEnterprise Managerを使用してイメージ・コピーのバックアップを作成すると、Recovery Managerリポジトリにそれらのコピーが記録されます。この方法によって、Recovery Managerで、データベースのリストアおよびリカバリ中にこれらのコピーを使用できます。Recovery Managerでは、Recovery Managerリポジトリに記録されている場合のみファイルを使用できます。Recovery Managerでは、ディスクにのみイメージ・コピーを作成できます。
バックアップ・セットは、Recovery Managerのバックアップ・コマンドによって作成されるバックアップを含む論理的な要素です。Recovery Managerの個々のBACKUPコマンドによって、1つ以上のバックアップ・セットを作成できます。各バックアップ・セットは、バックアップ・ピースと呼ばれる複数の物理ファイルで構成されます。バックアップ・ピースには、1つ以上のデータベース・ファイルのバックアップが、Recovery Managerでのみ操作可能な圧縮形式で格納されています。バックアップ・ピースは、単体では有効に操作することはできません。単にバックアップ・セットの一部としてアクセスされるだけです。バックアップ・セットは、ディスクまたはメディア管理デバイス（テープなど）に作成できます。バックアップ・セットは、バックアップをメディア・マネージャに書き込むことができる唯一の形式です。
Recovery Managerは、バックアップおよびリストア・タスクを実行する場合、サーバー・セッション（データベース・サーバーで実行されるプロセス）に依存します。各サーバー・セッションは、Recovery Managerチャネルに対応して、バックアップ・デバイス間のデータの流れを示します。Recovery Managerでは、並列処理（複数のチャネルおよびサーバー・セッションを使用した、1つのバックアップまたはリカバリのタスクの実行）がサポートされています。
並列処理を適切に使用すると、バックアップおよびリカバリのタスクでのパフォーマンスを大幅に向上できます。Recovery Managerバックアップでのチャネルおよび並列性の概念の詳細は、『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。
「データベース」の「ホーム」ページで、「メンテナンス」をクリックします。「バックアップ/リカバリ」セクションで、「バックアップ設定」を選択します。
「バックアップ設定」ページには、「デバイス」、「バックアップ・セット」および「ポリシー」の3つのプロパティ・ページがあります。ここで選択する設定は、すべてのバックアップ・ジョブに適用できるデフォルト値になります。個々のバックアップ・タスクを実行する場合は、これらのデフォルト値を上書きできます。
デフォルトでは、「デバイス」プロパティ・ページが最初に表示されます。「ディスク設定」セクションの下にある次のフィールドを確認します。
この時点では、この値を1に設定します。この値は、後で変更できます。Recovery Managerの並列性およびパフォーマンスについては、『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。
フラッシュ・リカバリ領域へ直接バックアップするには、空白のままにします。
「バックアップ・セット」が選択されていることを確認します。Oracleデータファイルをバックアップ・セットにバックアップする利点の1つは、データファイルのバックアップにおいて、領域を節約するために、Recovery Managerで未使用ブロックの圧縮を使用できることです。データファイルのうち、データの格納に使用されたブロックのみがバックアップ・セットに含まれます。
また、バックアップのためにホスト資格証明も指定できます。「Oracle Enterprise Managerのバックアップおよびリカバリを実行するための資格証明」の説明に従って資格証明を入力します。
これらを設定した後、「ディスク・バックアップのテスト」をクリックして、資格証明およびバックアップ位置が正しいことを確認できます。
「バックアップ・セット」プロパティ・ページの設定についてのアラートは、この時点では表示されません。
「バックアップ設定」ページで、「ポリシー」をクリックします。「ポリシー」プロパティ・ページで、制御ファイルおよびSPFILEのバックアップを管理するバックアップ・ポリシー、データベース全体のバックアップから除外する表領域およびバックアップ保存方針を設定できます。
「バックアップ・ポリシー」ページの次のオプションを確認します。
SPFILEおよび制御ファイルは、データベースおよびRecovery Managerの操作に重要です。また、通常のデータファイルと比べると比較的小さいファイルです。これらのファイルを頻繁にバックアップすると、比較的少ないオーバーヘッドが記憶域に対して発生します。「自動バックアップ・ディスクの場所」を空白のままにしておくと、自動バックアップはフラッシュ・リカバリ領域に作成されます。
このオプションによって、フラッシュ・リカバリ領域の領域を節約できます。
このオプションでは、Oracleのブロック変更追跡機能を利用できます。この機能によって、通常の操作中に、少ないオーバーヘッドで増分バックアップのパフォーマンスが大幅に向上します。
バックアップから除外する表領域の名前のリストを指定できます。たとえば、すべてのバックアップに読取り専用表領域を含める必要はありません。ここでは、除外される表領域のリストが空で、すべての表領域がバックアップされることを確認します。
保存方針は、次の形式から選択できます。
このオプションによって、バックアップは、明示的に削除されるまでフラッシュ・リカバリ領域に保存されます。このオプションに保存方針はありません。
このオプションによって、リカバリ期間ベースの保存方針が有効になります。
このオプションによって、冗長性ベースの保存方針が有効になります。
この時点では、31日間のリカバリ期間を指定して、リカバリ期間ベースの保存方針を選択します。
ページの下部の「ホスト資格証明」セクションに、適切な資格証明が含まれていることを確認します。「OK」をクリックし、新しい設定を保存します。
この項では、Enterprise Managerを使用してデータベースをバックアップする方法について説明します。Oracleデータベース・バックアップのタイプの概要を示した後、異なるバックアップ・タイプを実行する方法、Enterprise Managerの推奨バックアップ計画を利用して高速リカバリを実行できる有効な基本バックアップ計画を実装する方法、およびユーザー独自のバックアップをスケジュールする方法について説明します。
推奨バックアップ計画、およびEnterprise Managerを使用して実行する他のバックアップ・タイプを理解するには、Oracleでサポートされているデータベース・バックアップの概念を理解する必要があります。
データファイルの全体バックアップは、データファイルのすべての使用済ブロックを含むバックアップです。このバックアップは、イメージ・コピー・バックアップ（ホスト・オペレーティング・システムのファイル・コピー・コマンドでコピーした場合と同様にデータファイルの正確なコピー）、またはRecovery Managerで作成されたバックアップ・セットのいずれかにできます。バックアップが格納される形式に関係なく、少数のブロックのみが変更された場合でも、データファイル全体がバックアップされます。
増分バックアップでは、各データファイルのバックアップ間で変更があったブロックのみが取得されます。通常の増分バックアップ計画では、レベル0の増分バックアップが開始ポイントとして使用されます。レベル0のバックアップでは、データファイルのすべてのブロックが取得されます。
次のレベル1の増分バックアップでは、通常、定期的（1日に1回など）に、変更されたデータファイルにある各ブロックのイメージをコピーします。レベル1のバックアップには、累積（最後にレベル0のバックアップが取られた後に変更されたすべてのブロック）または差分（最後にレベル0またはレベル1の増分バックアップが取られた後に変更されたブロックのみ）があります。
増分バックアップから変更されたブロックのリカバリは、メディア・リカバリのパフォーマンスを向上させるために使用されます。増分レベルが1のバックアップは、増分バックアップの期間に変更されたすべてのデータファイル・ブロックの最終的な内容をコピーするため、リカバリ・プロセスでは、その期間のREDOログから個々の更新を再適用する必要はなく、単に最終的な内容で各ブロックを更新します。REDOログは、レベル1の増分バックアップではバックアップされない期間に行われた変更に対してのみ使用されます。
Oracleの増分更新バックアップ機能によって、データファイルの古いイメージ・コピー・バックアップとともにレベル1の1つ以上の増分バックアップを使用できます。最後のレベル1の増分バックアップを行った時点まで古いコピーをロールフォワードできます。イメージ・コピーが作成された後に変更されたすべてのブロックは、最後のレベル1の増分バックアップ時点の新しい内容で上書きされます。その結果、ファイルは、データベース・リカバリを行うために、適切な時点にロールフォワードされ、その内容が、最後のレベル1のバックアップ時点で行われたイメージ・コピーのデータファイルの全体バックアップと同じになります。
増分更新バックアップをバックアップ計画に組み込むと、必要なリカバリ時間が短縮されます。これは、現在または過去のある時点までのメディア・リカバリを、最後に完全なデータベース・バックアップを行った時間ではなく、最後のレベル1のバックアップが適用された時点から開始できるためです。推奨のバックアップ計画は、増分更新バックアップに基づいています。
増分バックアップを含むすべてのRecovery Managerバックアップは、タグを使用してラベル付けできます。タグは、バックアップを一意にまたはバックアップ・グループの一部として識別するテキスト文字列です。たとえば、毎週土曜日の夜にデータベースの完全バックアップを実行する場合、すべての同様のバックアップと区別するために、タグFULL_SATURDAYを使用できます。これらのタグは、Recovery Managerコマンドで特定のバックアップを指定するために使用できます。たとえば、最新のFULL_SATURDAYバックアップをテープに移動するコマンドを発行できます。
タグを使用してバックアップの様々なグループを指定できるため、バックアップ計画全体で、相互に干渉しない様々なルーチンを作成できます。バックアップ・ジョブをスケジュールし、そのジョブに名前を付けると、バックアップにタグを付ける場合にそのジョブ名が使用されます。
Enterprise Managerを使用すると、Recovery Managerでサポートされているすべての異なるバックアップ・タイプを実行し、バックアップ計画で必要な様々なバックアップ・ジョブをスケジュールできます。
データベースの全体バックアップは、バックアップ時点のデータベース全体の内容をバックアップすることが基本です。すべてのデータファイルの全体バックアップが作成されます。バックアップの結果は、イメージ・コピーまたはバックアップ・セットとして格納されますが、いずれの場合も、データベースのすべてのデータファイルの内容、制御ファイル、アーカイブREDOログおよびサーバー・パラメータ・ファイルがバックアップされます。これらのファイルを使用して、データベースの完全リカバリを実行できます。
データベース全体のバックアップは、バックアップ計画全体で重要な要素であると同時に、必須の手順（ARCHIVELOGモードをオンまたはオフに切り替える場合など）となる場合もあります（「データベースのARCHIVELOGモードの構成」を参照）。
データベース全体のバックアップを実行するには、次の手順を実行します。
図9-1に示す、「バックアップのスケジュール」ページが表示されます。
このページの重要なセクションは次のとおりです。
「カスタマイズ・バックアップのスケジュール: オプション」ページが表示されます。このページで、このデータベース全体のバックアップのオプションを指定します。
「基本的なバックアップおよびリカバリのためのデータベース構成」で説明したとおり、データベースが
注意:
ARCHIVELOGモードで実行されるように設定されている場合にのみ、オンライン・バックアップを使用できます。NOARCHIVELOGモードでは、オフライン・バックアップのみ実行できます。
「拡張」セクションでは、次の選択を行います。
選択後、「次へ」をクリックします。
「カスタマイズ・バックアップのスケジュール: 設定」ページが表示されます。
「カスタマイズ・バックアップのスケジュール: スケジュール」ページが表示されます。
「ジョブの説明」には、参照する場合に有効な説明文を設定できます。
終了後、「次へ」をクリックします。
「カスタマイズ・バックアップのスケジュール: 確認」ページが表示されます。このページには、前述のページで指定したバックアップ・ジョブの詳細が表示されます。
この例では、「ジョブの発行」をクリックします。
「ステータス」ページが表示されます。このページには、ジョブが正常に発行されたことを示すメッセージが表示されます。
「実行」ページが表示されます。このページには、ジョブを説明する「サマリー」セクションが含まれています。「ログ」セクションには、バックアップ・ジョブの様々な手順の進捗を示す表が表示されます。ブラウザでこのページを再ロードして、ジョブの進捗を監視できます。「ログ」セクションの表の「名前」列で、Recovery Managerジョブのフェーズを確認できます。バックアップのフェーズ名をクリックすると、その部分のRecovery Managerジョブの出力が含まれているページが表示されます。このページで、ブラウザの「戻る」ボタンをクリックすると、「実行」ページに戻ります。
オフライン・バックアップを実行すると、データベース・インスタンスは、停止後、再起動し、オフライン・バックアップの実行中はMOUNTED状態になります。オフライン・バックアップはバックグラウンドで実行され、出力はブラウザに表示されません。データベースがオープン状態でないため、オフライン・バックアップの実行中Enterprise Managerに表示されるページに影響があります。
バックアップ・ジョブを発行すると、ジョブが正常に発行されたことを示す「ステータス」ページが表示されます。また、その出力には、オフライン・バックアップの一環としてデータベースが停止およびマウントされること、およびバックアップが完了するまで待機する必要があることを示す通知も含まれます。
データベースが停止および再起動される場合は、Enterprise Managerアプリケーションも短時間停止します。Enterprise Managerは、停止中のページの更新には対応できません。
Enterprise Managerが再起動された後も、データベースがオープンされない場合は、インスタンスに接続できないことがEnterprise Managerによってレポートされます。データベースでオフライン・バックアップが実行されると、このページの「データベース・インスタンス」セクションにデータベース・リスナーおよびインスタンスの現在の状態（「アンマウント」または「マウント」）がレポートされます。また、「起動」または「リカバリの実行」というオプションも表示されます。
オフライン・バックアップ中は、「起動」または「リカバリの実行」をクリックしないでください。オフライン・バックアップの障害となることがあります。かわりに、オフライン・バックアップが完了してデータベースが再起動されるまで、ページを繰り返し更新します。Enterprise Managerによってログイン資格証明の入力を求められると終了です。ログイン後、「データベース」の「ホーム」ページに戻ることができます。
Enterprise Managerによって、ディスクへの推奨バックアップ計画を簡単に設定できます。推奨バックアップ計画では、データを保護し、選択したリカバリ期間のいずれの時点にも効率的にリカバリできます。（最も簡単な例（この項で使用）では、この期間は24時間です。）推奨の計画で、Oracleの増分バックアップおよび増分更新バックアップ機能を利用することによって、データベース全体のバックアップより高速なバックアップ、およびアーカイブ・ログからデータファイルにデータベースの変更を適用して行うより高速なリカバリが可能になります。
推奨バックアップ計画は、データベースのイメージ・コピーの作成に基づいています。このコピーは、増分更新バックアップを使用してロールフォワードされます。Oracle Enterprise Managerによって、Recovery Managerバックアップ・ジョブが夜間に実行されるようにスケジュールされます。
計画では、各データファイルに対して次のとおりバックアップが実行されます。
リストアおよびリカバリで使用する場合は、1日目のREDOログを使用して、1日目のどの時点へもリカバリできます。
リストアおよびリカバリで使用する場合は、レベル0のバックアップを2日目の始めまで迅速にロールフォワードするために、この増分レベル1を適用できます。REDOログを使用すると、2日目のいずれの時点にもリカバリできます。
リストアおよびリカバリで使用する場合は、この増分レベル1をn-1日目からn日目の始めまでロールフォワードされたデータファイルに適用できます。REDOログを使用すると、n日目のいずれの時点にもデータベースをリカバリできます。
推奨バックアップ計画で使用されるデータファイルのコピーは、タグORA$OEM_LEVEL_0でタグ付けされます。この計画で使用するレベル1の増分バックアップは、同様にラベル付けされたデータファイルのコピーを使用するために作成されます。推奨の計画に使用するバックアップからの干渉を考慮しなくても、他のバックアップ計画を確実に実装できます。
ディスク・バックアップとともにテープ・バックアップを使用する推奨の計画もありますが、これらの詳細は、この章では説明しません。
推奨計画を使用してディスクにバックアップするには、次の手順を実行します。
図9-1に示す、「バックアップのスケジュール」ページが表示されます。
「推奨バックアップのスケジュール: バックアップ先」ページが表示されます。このページで、バックアップ先メディア（ディスクまたはテープ、あるいはその両方）を選択します。
「推奨バックアップのスケジュール: 設定」ページが表示されます。このページには、ディスク・ベースの計画の一環として毎日実行するバックアップの説明が表示されます。
「推奨バックアップのスケジュール: スケジュール」ページが表示されます。
「推奨バックアップのスケジュール: 確認」ページが表示されます。
ORA$OEM_LEVEL_0を確認できます。スケジュールを変更する必要がない場合は、「ジョブの発行」をクリックして、推奨の計画のジョブをスケジュールに追加します。この設定により、ご使用のデータベースは、増分バックアップおよび増分適用バックアップを使用して毎日1回バックアップされ、過去24時間のどの時点にも迅速にリカバリできます。
『Oracle Databaseバックアップおよびリカバリ基礎』で説明されている様々な使用可能なバックアップ・オプションについて理解を深めた後、推奨バックアップ計画の実装に使用するタスク以外のバックアップ・タスクのスケジュールを決定できます。
実行するジョブを指定する項目はバックアップの各タイプで異なりますが、すべてのバックアップは「バックアップのスケジュール」ページ（図9-1を参照）から始まります。ここでは、バックアップするオブジェクト・タイプのいくつかを選択できます。また、ディスクからテープにバックアップを移動するなど、ある場所から別の場所に既存のバックアップを移動することもできます。
バックアップするオブジェクト、必須オプション、設定などの詳細を指定するページに進むには、「カスタマイズ・バックアップのスケジュール」をクリックします。これらのページに示される選択肢は、バックアップ対象のオブジェクトのタイプによって決まります。各ページで、選択を行った後、「次へ」をクリックして次のページに進みます。
オプションを指定した後、「カスタマイズ・バックアップのスケジュール: スケジュール」ページで、「ジョブ名」、「ジョブの説明」およびジョブの実行時期を指定します。
ジョブの名前、説明およびスケジュールの指定を終了したら、「次へ」をクリックし、「カスタマイズ・バックアップのスケジュール: 確認」ページに移動します。オプションを確認した後、「戻る」をクリックして変更を行うか、「RMANスクリプトの編集」をクリックしてスクリプトに変更を行うか、または「ジョブの発行」をクリックしてジョブをスケジュールに追加します。
バックアップ計画の一環として、バックアップが完全な状態で、リカバリ目標を満たすために使用できるかどうかを定期的に確認する必要があります。
Enterprise Managerでは、バックアップを検証する場合に2つの異なる方法があります。
使用可能なバックアップを使用して特定のリストア操作を実行できることの検証は、「リカバリの実行」ページで実行します。詳細は、「Recovery Managerバックアップからのデータファイルのリストアの検証」を参照してください。ディスクまたはテープ上の特定のバックアップ・セットおよびイメージ・コピーの検証は、「現行バックアップの管理」ページで実行します。詳細は、「バックアップ・セットまたはイメージ・コピーの内容の検証」を参照してください。両方の形式の検証は、Enterprise Managerでスケジュールされたタスクとして設定できます。両方の形式の検証をバックアップ計画に組み込んで、使用可能なバックアップでリカバリ目標が常に満たされるようにする必要があります。
Enterprise Managerのガイド付きリカバリ機能によって、次に示すリストアおよびリカバリの様々な使用例に必要なロジックがカプセル化されたリカバリ・ウィザードを使用できます。
Enterprise Managerでは、破損したデータベース・ファイルの検出などを含め、リストアおよびリカバリする必要があるデータベースの部分を判別できます。Enterprise Managerを使用すると、必要な情報の入力を求められたり、必要なリカバリ操作が実行されるため、リカバリ・プロセスを簡単に行うことができます。
この項の例では、一般的なリストア・タスクおよびリカバリ・タスクを部分的に示します。ただし、同じ「リカバリの実行」ページを使用して、Enterprise Managerの他のデータベース全体またはオブジェクト・レベルのリカバリ機能にアクセスすることもできます。
リストア・タスクおよびリカバリ・タスクにアクセスするには、次の手順を実行します。
「メンテナンス」プロパティ・ページが表示されます。
「リカバリの実行」ページが表示されます。図9-2に、このページのセクションを示します。
「リカバリの実行」ページでは、データベース全体、または選択した表領域、データファイル、アーカイブ・ログ、表のみをリカバリできます。
この例では、バックアップからのデータベース全体のリカバリを示します。この例では、1つ以上のデータファイルが消失した後、使用可能なSPFILEおよび制御ファイルが残っている場合に、データベースをリストアおよびリカバリしているとします。Enterprise Managerも、消失したSPFILEまたは制御ファイルのリストアに使用できます。詳細は、「消失したSPFILEまたは制御ファイルのリカバリ」を参照してください。
「リカバリの実行」ページが表示されます。
「確認」ページが表示されます。
「リカバリ・ウィザード」ページが表示されます。この時点で、データベースが停止されます。
SYSDBAロールで接続するか、またはDBAグループ内のユーザーのホスト資格証明を入力します。「リカバリの実行」ページが再度表示され、データベースが（この操作で必要な）MOUNTED状態であることが示されます。
「データベース全体のリカバリの実行: Point-in-Time」ページが表示されます。
この例では、「現在の時間へのリカバリ」を選択し、「次へ」をクリックします。
「データベース全体のリカバリの実行: 名前の変更」ページが表示されます。
「データベース全体のリカバリの実行: 確認」ページが表示されます。
消失した制御ファイルまたはSPFILEのリカバリは、データベースを停止してから開始する必要があります。制御ファイルが消失している場合、インスタンスは実行できないことに注意してください。
通常、消失した制御ファイルの診断は、データベースを起動しようとして失敗した場合に実行されます。基本手順は次のとおりです。
バックアップから制御ファイルがリストアされると、データベースがマウントされます。バックアップからリストアされた制御ファイルを使用してデータベースを起動する場合は、バックアップからリストアされたデータファイルがなくても、データファイルの完全リカバリを実行する必要があります。データベースは、データファイルがリカバリされた後、RESETLOGSオプションを指定してオープンする必要があります。
データファイルの完全リカバリを実行するには、次の手順を実行します。
リカバリが完了したら、RESETLOGSオプションを指定してデータベースをオープンすることを求められます。
バックアップからのデータファイルのリストアの検証では、指定したファイルのリストアに使用可能なバックアップが十分に存在するかどうかがテストされます。リストアする表領域およびそれらをリストアする時点を指定すると、Recovery Managerによって、必要なデータが含まれている一連のバックアップが選択されます。次に、選択されたバックアップ全体が読み取られ、破損されていないことが確認されます。
|
注意:
この操作は、Recovery Managerの ファイルのリストアの検証では、使用可能なバックアップ・ファイルが存在する場合にファイルをリストアできるかどうかはテストされますが、指定したオブジェクトのすべてのバックアップが有効かどうかはテストされません。 特定のバックアップの検証および特定のリストア・タスクの検証は、両方ともバックアップ計画の検証に有効です。詳細は、「バックアップの検証およびバックアップ計画のテスト」を参照してください。 |
「リカバリの実行」ページが表示されます。
「オブジェクト・レベルのリカバリの実行」ページが表示されます。
「オブジェクト・レベルのリカバリの実行: リストア」ページが表示されます。
「オブジェクト・レベルのリカバリの実行: スケジュール」ページが表示されます。
「オブジェクト・レベルのリカバリの実行: 確認」ページが表示されます。
「リカバリの実行: 結果」ページが表示されます。
Oracle Flashback Tableを使用すると、データベース内の他のオブジェクトに影響を与えずに、1つ以上の表を以前の時点の内容に戻すことができます。このリカバリ方法によって、論理データの破損（表への行の誤挿入、表からのデータの誤削除など）をリカバリできます。表のフラッシュバックを使用すると、データベース内の他のオブジェクトに行われた必要な変更を元に戻さずに、選択した表を過去のある時点の状態に戻すことができます。また、Point-in-Timeリカバリとは異なり、操作中にデータベースを使用できます。
この例では、hrスキーマ内のemployees表で表のフラッシュバックを実行します。2005年10月23日15時30分少し過ぎに誤って更新を行ったため、すべての従業員のlastname列が空の文字列に変更され、元のlastnameの値を表に戻す必要があるとします。
表のフラッシュバックを実行する前に、行移動が、フラッシュバックする表で有効になっていることを確認する必要があります。
行移動を表で有効にする場合または行移動が表で有効かどうかがわからない場合は、次の手順に従います。
「表」ページが表示されます。
hrスキーマ内の表を検索します。表を検出するために、検索結果を最初のページから最後のページまで参照する必要がある場合があります。
employeesを選択します。「編集」をクリックします。「表の編集: table_name」ページが表示されます。
ページが更新されると、ページの最上部にあるロケータ・リンクの「表」をクリックして検索結果に戻ることができます。また、各表でこれらの手順を繰り返して、より多くの表に対して行移動を有効にできます。
表のフラッシュバック操作を実行するには、次の手順を実行します。
「リカバリの実行」ページが表示されます。
「オブジェクト・レベルのリカバリの実行: Point-in-Time」ページが表示されます。
この例では、破損が発生した時刻が2005年10月3日15時36分であるとわかっているとします。指定された形式で、「タイムスタンプにフラッシュバック」を選択してターゲット時刻を入力します。「次へ」をクリックして表のフラッシュバックのプロセスを続行します。
「オブジェクト・レベルのリカバリの実行: 表のフラッシュバック」ページが表示されます。
hr.employees表を手動で入力します。「次へ」をクリックして表のフラッシュバックのプロセスを続行します。ご使用の表にその他の依存表が存在する場合は、「依存状態オプション」ページが表示されます。このページでは、依存状態の処理方法の選択を求められます。
hr.employeesには、依存表hr.jobsおよびhr.departmentsが含まれています。この例では、すべての変更をカスケードし、hr.employees表のみでなく、これらの2つの表もフラッシュバックするとします。
「次へ」をクリックして続行します。
「オブジェクト・レベルのリカバリの実行: 確認」ページが表示されます。
操作が完了すると、「確認」ページに結果が表示されます。「OK」をクリックして、データベースのホームページに戻ります。
Oracle Flashback Dropを使用すると、表の削除結果を無効にし、索引、トリガーなどの依存オブジェクトとともに削除した表をデータベースに戻すことができます。この操作は、削除したオブジェクトをごみ箱に格納することによって実現されます。削除したオブジェクトは、明示的にまたは新しいデータベース・オブジェクトに領域が必要なためにごみ箱が消去されるまで、ごみ箱から取得できます。
表のフラッシュバックと同様に、削除のフラッシュバックでは、残りのデータベースはオープン状態のまま、削除のフラッシュバック操作に影響されないオブジェクト内の必要な変更を元に戻さずに使用できます。データベースをオフラインにし、バックアップからファイルをリストアする必要があるリカバリ方法より有効です。
削除のフラッシュバック操作を実行するには、次の手順を実行します。
「リカバリの実行」ページが表示されます。
「オブジェクト・レベルのリカバリの実行: 削除したオブジェクト選択項目」ページが表示されます。
ページが更新されると、検索項目と一致したオブジェクトが「結果」セクションに表示されます。ごみ箱のみが表示された場合は、ごみ箱の横にある矢印をクリックしてその内容を1レベル開きます。削除した表で検索項目と一致したものが表示されますが、依存オブジェクトは表示されません。また、個々の表を開くか、または「すべてを開く」をクリックして、ごみ箱内のすべてのオブジェクト（削除した表と、索引、トリガーなどの依存オブジェクトの両方を含む）を表示できます。表示された各表に対して、「操作」列の「内容の表示」をクリックすると内容を表示できます。削除のフラッシュバックに対して1つ以上の表を選択するには、各表の横にあるチェックボックスを選択します。
リストアするすべてのオブジェクトの選択が終了すると、「次へ」をクリックします。
「オブジェクト・レベルのリカバリの実行: 名前の変更」ページが表示されます。
「オブジェクト・レベルのリカバリの実行: 確認」ページが表示されます。このページには、削除のフラッシュバック操作が完了するとオブジェクトに付けられる名前のみでなく、フラッシュバックするオブジェクト（依存オブジェクトを含む）の完全なセットを示す影響分析が表示されます。
確認ページに、操作が正常に実行されたことが示されます。
Recovery Managerのバックアップの管理（Enterprise Managerを使用する場合または使用しない場合がある）には、ディスクまたはテープに格納されているデータベースのバックアップを管理する場合と、これらのバックアップのレコードをRecovery Managerリポジトリで管理する場合があります。Enterprise Managerを使用すると、両方のバックアップ管理タスクが簡単になります。
Recovery Managerリポジトリ内のバックアップ・レコードは、次の状態のいずれかになります。
また、バックアップは不要になることもあります。不要バックアップは、現在構成されている保存方針に基づいて、データ・リカバリの目標達成に必要ではなくなったバックアップです。
Enterprise Managerで実行可能なバックアップ・メンテナンス・タスクには、次のものがあります。
バックアップ記憶域のフラッシュ・リカバリ領域を使用すると、多くのメンテナンス・アクティビティが削減されるか、または不要になります。実行中のデータベース操作に必要な領域を確保する必要がある場合は、保存方針を損なわずに、フラッシュ・リカバリ領域の自動ディスク領域管理メカニズムによってバックアップ・ファイルおよびその他のファイルが削除されます。
バックアップ管理機能にアクセスするには、データベースのホームページに移動して、「メンテナンス」をクリックし、「メンテナンス」プロパティ・ページを開きます。「バックアップ/リカバリ」セクションで、「現行バックアップの管理」を選択します。
「現行バックアップの管理」ページには、「バックアップ・セット」と「イメージ・コピー」という選択可能な2つのプロパティ・ページがあります。いずれのページも同様の用途で使用できます。Recovery Managerリポジトリ内のレコードに基づいて、バックアップ・セットまたはイメージ・コピーとして格納されたバックアップが表示され、表示されたバックアップを管理することができます。図9-3「「現行バックアップの管理」ページ」に、通常の「バックアップ・セット」プロパティ・ページを示します。
「イメージ・コピー」プロパティ・ページも似ていて、同じ操作がサポートされています。「現行バックアップの管理」ページの要素は次のとおり分類できます。
各プロパティ・シートの「検索」セクションを使用すると、表示されるバックアップを次の項目に基づいて制限できます。
デフォルトでは、過去1か月のすべての使用可能なバックアップが示されます。必要に応じて条件を指定して、バックアップ・リストをフィルタ処理し、「実行」をクリックして、バックアップを検索します。
このページの「結果」セクションには、「検索」セクションで指定した条件に一致するバックアップが示されます。バックアップ・セット（「バックアップ・セット」プロパティ・ページ上）およびイメージ・コピー（「イメージ・コピー」プロパティ・ページ上）には、異なる詳細が示されます。
「バックアップ・セット」プロパティ・ページでは、バックアップ・セットは、「キー」列の一意の値（Recovery Managerコマンドでバックアップ・セットを識別するために使用される内部生成番号）および「タグ」列の値によって識別されます。各バックアップでは、ページにはバックアップされたファイルのタイプ、バックアップ先のデバイス・タイプ、バックアップの完了時間、現在のステータスなどの情報が示されます。
「タグ」列の指定したバックアップ・セットの値をクリックすると、そのバックアップ・セットの詳細を表示できます。表示される内容は次のとおりです。
「イメージ・コピー」プロパティ・ページでは、イメージ・コピーは、「キー」列の一意の値（Recovery Managerコマンドでバックアップ・セットを識別するために使用される内部生成番号）および「名前」列のファイル名によって識別されます。各バックアップでは、ファイル・タイプ、タグ、完了時間およびステータスも示されます。また、このページには各イメージ・コピーのステータス（使用可能、使用不可または期限切れ）および「保存」列（バックアップの保存方針への特別な例外がこのファイルに適用されるかどうかを示す）が示されます。
「名前」列の値をクリックすると、そのファイルの詳細（データファイル番号、ファイル・サイズ、表領域名、作成時のSCN、およびファイルがバックアップされた時点の最後のチェックポイントのSCNと時刻など）を表示することもできます。
個々のバックアップをクロスチェックまたは削除したり、個々のバックアップが一時的にRecovery Managerでアクセスできないことがわかっている場合にそれらに「使用不可」とマークすることもできます。たとえば、一部のバックアップが長期間保存するためにサイト外に移動されたテープに格納されることがわかっている場合は、Recovery Managerによってリストア操作で使用可能とみなされないように、それらのバックアップを「使用不可」とマークできます。ファイルの横にある「選択」チェックボックスを使用して、「結果」リストの最上部にある該当する操作ボタンをクリックします。
「イメージ・コピー」ページには、「バックアップ・セット」プロパティ・ページと同様の機能があります。この項では、主に、イメージ・コピーのコマンドと実質的に同じ「バックアップ・セット」プロパティ・ページのコマンドについて説明します。
Enterprise Managerでバックアップおよびリストア・コマンドを実行する場合と同様に、バックアップのステータスをクロスチェック、削除および変更するコマンドは、最終的にはRecovery Managerコマンドに変換されます。コマンドはRecovery Managerジョブとして発行されます。このジョブは、すぐに実行するか、スケジュールすることができます。一部のタスク（バックアップの定期クロスチェックなど）は、バックアップ計画で定期的にスケジュールされる要素に含める必要があります。
バックアップを検証する場合は、バックアップ用のファイルが存在すること、破損していないこと、およびリカバリ操作で使用可能であることを確認します。選択されたバックアップ・ファイル全体が読み取られ、エラーが確認されます。
|
注意: 特定のバックアップを検証すると、それらのバックアップが読取り可能かどうかのみが確認されます。使用可能な一連のバックアップがリカバリ可能性の目的に合うかどうかはテストされません。 たとえば、データベースのいくつかの表領域のデータファイルのイメージ・コピーを所有でき、各ファイルを検証できます。ただし、有効なバックアップが存在しない表領域が存在する場合は、データベースをリストアおよびリカバリすることはできません。 リストア操作を検証すると、使用可能な一連のバックアップを実際に使用して、特定のリストア操作（特定の表領域またはデータベース全体のリストアなど）を実行できることが確認されます。リストア操作の検証については、「バックアップの検証およびバックアップ計画のテスト」を参照してください。 |
特定のバックアップがリストアおよびリカバリ操作で使用可能かどうかを検証するには、次の手順を実行します。
「現行バックアップの管理」ページが表示されます。
「検証: ジョブ・パラメータの指定」ページが表示されます。
ジョブの発行を確認するメッセージが表示されます。
このプロセスは、Recovery ManagerのVALIDATEコマンドに対応します。Recovery ManagerのVALIDATEコマンドの使用に関する詳細は、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。
バックアップをクロスチェックすると、Recovery Managerによって、バックアップの実際の物理ステータスがRecovery Managerリポジトリ内のバックアップのレコードと一致していることが確認されます。たとえば、ディスク上のバックアップがオペレーティング・システム・コマンドで削除されているためリストア操作で使用できない場合、そのファイルをクロスチェックすると、その状況が検出されます。クロスチェック操作後は、ディスクまたはテープ上のバックアップの状態がRecovery Managerリポジトリに適切に反映されます。
ディスクへのバックアップは、Recovery Managerリポジトリに示された位置のディスクに存在する場合およびファイル・ヘッダーに破損がない場合、「使用可能」とマークされます。テープ上のバックアップは、テープ上に存在する（ファイル・ヘッダーの破損はチェックされていない）場合、「使用可能」と表示されます。欠落または破損しているバックアップは、「期限切れ」とマークされます。
各ファイルをクロスチェックするには、次の手順を実行します。
また、ページの上部にある「すべてをクロスチェック」をクリックして、Recovery Managerリポジトリに記録されているすべてのバックアップを一度にクロスチェックすることもできます。「すべてをクロスチェック: ジョブ・パラメータの指定」ページで、クロスチェックをすぐに実行するか、または後で実行するようにスケジュールできます。または、定期的にスケジュールされるクロスチェックを指定することもできます。
このプロセスは、Recovery ManagerのCROSSCHECKコマンドに対応します。詳細は、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。
期限切れバックアップの削除では、「期限切れ」とマークされたバックアップ（クロスチェック操作中にRecovery Managerによってアクセス不可とみなされたバックアップ）がRecovery Managerリポジトリから削除されます。（ディスクまたはテープからのバックアップを含むファイルの削除は試行されません。この操作は、Recovery Managerリポジトリのみを更新します。）
期限切れバックアップを削除するには、次の手順を実行します。
「期限切れのものをすべて削除: ジョブ・パラメータの指定」ページが表示されます。
ジョブが正常に発行されたことを示すメッセージが表示されます。
1つ以上の特定のバックアップが、一時的な状況（一時的にオフラインになっているディスク・ドライブ、オフサイトに格納されているテープなど）のため使用不可であるとわかっている場合は、それらのバックアップに「使用不可」とマークできます。Recovery Managerでは、リストアおよびリカバリ操作で使用不可のバックアップの使用は試行されません。ただし、使用不可のバックアップのレコードはRecovery Managerリポジトリに保持され、期限切れバックアップを削除した場合も、「使用不可」とマークされたバックアップの削除は試行されません。バックアップが再度アクセス可能になると、それらのバックアップを「使用可能」とマークできます。
「現行バックアップの管理」ページの「結果」セクションの上部に、バックアップを「使用可能」または「使用不可」とマークするためのボタンがあります。
バックアップを「使用可能」とマークするには、バックアップの「結果」リスト内の各バックアップの横にある「選択」チェックボックスを選択し、「使用可能に変更」を選択します。
バックアップを「使用不可」とマークするには、バックアップの「結果」リスト内の各バックアップの横にある「選択」チェックボックスを選択し、「使用不可に変更」を選択します。
不要バックアップ（保存方針を満たすために必要ではなくなったバックアップ）を削除するには、「現行バックアップの管理」ページの最上部にある「不要なものをすべて削除」をクリックします。
「不要なものをすべて削除」をクリックすると、「不要なものをすべて削除: ジョブ・パラメータの指定」ページが表示されます。削除ジョブは、バックアップ・ジョブと同様に、すぐに実行するか、またはスケジュールすることができます。
フラッシュ・リカバリ領域をディスク・ベースのバックアップ先として使用する場合は、不要バックアップをディスクから削除する必要はありません。フラッシュ・リカバリ領域の自動領域管理によって、ファイルは、バックアップ保存方針で指定したとおりに保存され、領域が必要な場合にのみ削除されます。
バックアップ・レポートには、Recovery Managerで実行した過去のバックアップ・ジョブについての概要および詳細な情報が表示されます。これには、Enterprise Managerで実行したバックアップおよびRecovery Managerコマンドライン・クライアントで実行したバックアップの両方が含まれています。
バックアップ・レポートを表示するには、「メンテナンス」プロパティ・ページの「バックアップとリカバリ」セクションで「バックアップ・レポート」をクリックします。
このページには、最近のバックアップ・ジョブのリストが表示されます。このページの「フィルタ基準」セクションを使用して、バックアップ時刻、バックアップしたデータのタイプ、表示されているジョブのステータス（成功か失敗か、およびジョブで警告が生成されたか）ごとに、表示されるバックアップを制限できます。任意のフィルタ条件を指定して「実行」をクリックし、表示されるリストを関係があるバックアップに制限できます。
リストには、各バックアップの基本的な情報が表示されます。
バックアップについての詳細を表示するには、「バックアップ名」列の値をクリックします。選択したバックアップについての「バックアップ・レポートの表示」ページが表示されます。このページには、次のようなバックアップ・ジョブの入力および出力についての詳細、およびこのバックアップについての概要情報（タイプごとにバックアップされたファイル数、データの合計、作成された出力ファイルの数、サイズおよびタイプ）が表示されます。
最近のジョブの場合は、「ステータス」列の値をクリックすることによって、そのジョブのRecovery Manager出力ログを表示することもできます。
「バックアップ・レポートの表示」ページにも「フィルタ基準」セクションがあり、これを使用して、別のバックアップや特定の日付範囲のバックアップに対する簡単な検索を実行できます。結果レポートには、検索基準に一致するバックアップの集計情報が表示されます。
Oracle by Example（OBE）には、このマニュアルに関するシリーズが含まれています。このOBEでは、この章のタスクを段階的に説明し、注釈付きのスクリーン・ショットを使用します。
バックアップおよびリカバリのOBEを参照するには、ご使用のブラウザで次の場所を指定します。
http://www.oracle.com/technology/obe/10gr2_2day_dba/backup/backup.htm
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|