Oracle Database 2日でデータベース管理者 11g リリース1(11.1) E05759-03 |
|
この章では、Oracle Enterprise Manager Database ControlでのOracle Databaseのバックアップおよびリカバリについて説明します。この章を読むと、Oracle Databaseのバックアップ操作およびリカバリ操作の基本概念に精通し、ディスクベースのバックアップ計画の実装方法を習得して、データベース・ファイルに対する簡単な修復を行うことができます。
この章は次の項で構成されています。
Oracle Databaseバックアップおよびリカバリでは、データベース・ファイルの物理バックアップを行い、データベースを再構築することを主な目的としています。Oracle Enterprise Manager Database Control(Database Control)に組み込まれているバックアップおよびリカバリ機構で保護されるファイルには、データファイル、制御ファイル、サーバー・パラメータ・ファイルおよびアーカイブREDOログがあります。これらのファイルを使用すると、データベースを再構築できます。バックアップ・メカニズムは、データファイルの間違った削除やディスク・ドライブの障害などによるファイルの損傷を回避するために、物理レベルで機能します。
Oracle Recovery Manager(RMAN)は、Enterprise Managerベースのコマンドライン・ツールです。Oracle Databaseのバックアップおよびリカバリを効率よく行うために、このツールの使用をお薦めします。Recovery Managerはサーバーとの連携に優れており、バックアップおよびリストアの実行時にブロックレベルで破損を検出します。Recovery Managerでは、ファイルの多重化および圧縮バックアップ・セットによって、バックアップ時のパフォーマンスおよび領域の消費量を最適化し、主要なテープおよびストレージ・メディア製品との統合を実現しています。
論理バックアップ(表や表領域のようなデータベース・オブジェクトのエクスポートなど)は、物理バックアップの補助手段としては有効ですが、データベース全体の保護はできません。効果的なバックアップ計画は物理バックアップに基づいたものであることが必要です。
Oracle Databaseフラッシュバック機能は物理および論理バックアップに対して効率的で簡単な代替として物理および論理データ・リカバリ・ツールの範囲を提供します。フラッシュバック機能はバックアップまたはメディア・リカバリの実行からデータファイルのリストアなしに不要なデータベースの変更の効果の取消しができます。
この項では、次のフラッシュバック機能について説明します。
最初の2つの機能は論理レベルで実行され、3つ目の機能は物理レベルで実行されます。これらの機能では、失われたデータを回復する場合に、論理エクスポートの作成などの詳細な準備を必要としません。ユーザーのデータベースが使用可能である場合は、すべての機能を使用できます。Oracle Databaseのフラッシュバック機能の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』で説明しています。
Oracle Enterprise Managerの物理バックアップおよびリカバリ機能は、Recovery Manager(RMAN)コマンドライン・クライアントに基づいて作成されています。Database Controlでは、Recovery Managerの多くの機能が使用でき、Recovery Managerベースのバックアップおよびリカバリを簡略化して自動化するウィザードおよび自動化の方法が用意されています。
データベースのバックアップとは、データファイル、制御ファイルおよびアーカイブREDOログのコピーを作成することです(データベースがARCHIVELOG
モードで実行されている場合)。データベースのリストアとは、通常はディスクまたはテープなどのバックアップ媒体から元の場所または新しい場所に、データベースを構成する物理ファイルをコピーすることです。データベースのリカバリとは、通常REDOログ・ファイルを使用して、バックアップ後に作成されたデータベースへの変更を加えて、バックアップからリストアされたデータベース・ファイルを更新するプロセスのことです。
バックアップには、一貫性バックアップと非一貫性バックアップがあります。一貫性バックアップを作成するには、データベースが正常に停止され、バックアップ中はクローズ状態である必要があります。REDOログにコミットされた変更のすべてがデータファイルに書き込まれるため、データファイルはトランザクションの一貫性が保たれた状態となります。一貫性バックアップからデータファイルをリストアするときは、データベースをすぐにオープンできます。
データベースがARCHIVELOG
モードの場合は、アーカイブREDOログ・ファイルを使用してリカバリが可能な非一貫性バックアップを作成できます。オープンしているデータベースのバックアップは、まだデータファイルに適用されていない変更がオンラインREDOログに含まれているために、一貫していません。確実にリカバリできるように、REDOログをアーカイブした後、データファイルとともにバックアップする必要があります。
名前によらず、非一貫性バックアップは一貫性バックアップと同程度の堅牢性を持っています。一貫性バックアップの作成と比較した場合、データベースがオープンしていて更新可能な状態でもデータベースのバックアップができるという利点があります。
参照:
|
アーカイブREDOログおよびデータファイルをリストアする場合、データベースをオープンする前にメディア・リカバリを実行する必要があります。データファイルにまだ反映されていないアーカイブREDOログのデータベース・トランザクションがすべてデータファイルに適用され、トランザクションの一貫性が保たれた状態になってから、データベースがオープンされます。
メディア・リカバリには、制御ファイル、データファイル(通常、バックアップからリストアされたもの)、およびデータファイルがバックアップされた時点以降の変更を含むオンラインREDOログとアーカイブREDOログが必要です。メディア・リカバリは、ファイルやディスクの消失などのメディア障害から、または表のコンテンツの削除などのユーザー・エラーからリカバリする場合によく使用されます。
メディア・リカバリには、完全リカバリとPoint-in-Timeリカバリがあります。完全リカバリでは、バックアップのデータファイルをリストアし、すべての変更をアーカイブREDOログおよびオンラインREDOログからデータファイルに適用します。データベースは障害発生時の状態に戻り、データを失うことなくオープンできます。
Point-in-Timeリカバリでは、ユーザーが選択した過去のある時点の内容にデータベースを戻します。ターゲットの時点より前に作成されたデータファイルのバックアップ、およびバックアップ作成時からターゲットの時点までのアーカイブREDOログ・ファイル一式をリストアします。バックアップ時からターゲットの時点までの変更がデータファイルに適用されます。ターゲットの時点より後の変更はすべて破棄されます。
Oracle Enterprise Manager Database Control(Database Control)には、完全リカバリとPoint-in-Timeリカバリの両方を実行できるインタフェースがリカバリ・ウィザードの形式で用意されています。ただし、このガイドでは完全リカバリを中心に説明します。
バックアップおよびリカバリ・ファイルの管理を簡略化するには、データベースのフラッシュ・リカバリ領域を作成します。フラッシュ・リカバリ領域とは、バックアップおよびリカバリ・ファイルのディスクの位置を集中化するOracle管理ディレクトリ、ファイル・システム、または自動ストレージ管理ディスク・グループのことです。アーカイブ・ログとフラッシュバック・ログはフラッシュ・リカバリ領域に作成されます。Recovery Managerでは、フラッシュ・リカバリ領域にバックアップ・セットとイメージ・コピーを格納し、メディアのリカバリ時にはこの領域を使用してファイルをリストアします。フラッシュ・リカバリ領域は、テープ用のディスク・キャッシュとしても機能します。
Oracle Databaseではこの記憶域を自動的に管理し、不要になったファイルを削除します。バックアップを定期的にテープにコピーすると、他のファイル用にフラッシュ・リカバリ領域を解放できます。リカバリ領域を有効にして、バックアップ管理を簡略化することをお薦めします。このマニュアルでは、特に注記がある場合以外は、フラッシュ・リカバリ領域を使用することが前提となります。
参照:
|
Recovery Managerでは、各データベースの操作の実行対象となるデータベース・ファイルおよびバックアップのレコードが保持されます。このメタデータをRecovery Managerリポジトリと呼びます。
ホストのオペレーティング・システム・レベルでファイルをコピーするなどの方法で、Recovery Managerを使用せずにファイルをバックアップした場合、コピーについてのメタデータをRecovery Managerリポジトリに追加できます。後でRESTORE DATABASE
などのコマンドを使用する場合、Recovery Managerではリポジトリ内のレコードを使用してリカバリに必要なバックアップが選択されます。
データベースのRecovery Managerリポジトリが第1に格納される場所はデータベースの制御ファイルです。Recovery Managerのこのメタデータの重要性は、制御ファイルの保護がバックアップ計画の重要な部分を占めるもう1つの理由となっています。インストールの形態によっては、Recovery Managerリポジトリの2番目のコピーがリカバリ・カタログと呼ばれるスキーマに格納されます。このカタログは別のデータベースにあり、複数のデータベースのメタデータを格納できます。リカバリ・カタログの使用はオプションであり、このガイドの範囲外です。
参照:
|
この項では、推奨バックアップ計画を利用するためのデータベースの設定方法について説明します。すでにOracle Database Configuration Assistant(DBCA)で自動バックアップ用にデータベースを構成している場合は、この項をスキップしてください。
バックアップおよびリカバリのファイルと操作を自動管理するOracle Databaseの機能を最大限に利用するには、データベースを次のように構成します。
ARCHIVELOG
モードでデータベースを実行します。これにより、オンライン・バックアップが実行でき、完全なメディア・リカバリやPoint-in-Timeメディア・リカバリなどのデータ・リカバリ・オプションを指定できます。
また、バックアップするファイル、バックアップをディスクに格納する形式、ファイルを削除できる時期などを管理する多数のポリシーを設定する必要があります。自動日次バックアップが事前構成されたデータベースを作成する方法については、「DBCAを使用したデータベースの作成および管理」を参照してください。
バックアップおよびリカバリ用の一部の構成タスクを実行したり、バックアップ・ジョブをスケジュールしてリカバリを実行したりするには、適切な資格証明を持っている必要があります。必要になる可能性がある資格証明は次のとおりです。
SYSDBA
権限を持つデータベース・ユーザーとしてDatabase Controlにログインします。または、dba
グループのユーザー(UNIXまたはLinuxの場合)か、ora_dba
グループのユーザー(Microsoft Windowsの場合)のホスト・オペレーティング・システム資格証明を指定します。ホスト・オペレーティング・システムのユーザーにはRecovery Managerコマンドライン・クライアントの実行権限も必要です。
ホスト・オペレーティング・システムの資格証明を必要とするタスクでは、タスクの実行に使用されるページの下部に「ホスト資格証明」フォームが表示されます。Enterprise Managerでは、ユーザーがリクエストまたはスケジュールしたRecovery Managerジョブを起動する際にこの資格証明を使用します。
アクションを実行する前にこのオプションを選択すると、指定した資格証明が現在ログインしているOracle Databaseユーザー用に永続的に格納されます。Oracle Databaseユーザーとしてログインするたびに優先資格証明がデフォルトで再利用され、ホスト資格証明を必要とする操作が実行されます。
作業中のデータファイル・セットとは別のディスクにフラッシュ・リカバリ領域を配置する必要があります。これを行わなかった場合、このディスクがデータベースのシングル・ポイント障害になる可能性があります。
フラッシュ・リカバリ領域に割り当てるディスク領域の範囲は、データファイルのサイズおよびREDOログ・ファイル、リカバリ目標を決定するデータベースのサイズおよびアクティビティ・レベルによって決まります。オブジェクトは使用するバックアップの種類、使用する時間および維持する期間を決定します。
フラッシュ・リカバリ領域での領域管理は、バックアップ保存ポリシーによって制御されます。保存ポリシーは、ファイルがいつ不要になるか、つまりデータ・リカバリ目標を達成するために必要ではなくなるかを決定します。
保存ポリシーは、バックアップの冗長性またはリカバリ期間がベースとなります。冗長性ベースのポリシーでは、Recovery Managerリポジトリに記録されたファイルの最新バックアップが指定した数を超えた場合にのみ、そのファイルのバックアップが不要であるとみなされます。期間ベースのリカバリ・ポリシーでは、期間を日数で指定します。ファイルは、指定した期間内のシステム変更番号(SCN)への完全リカバリまたはPoint-in-Timeリカバリに必要ではなくなった場合にのみ、不要になります。したがって、期間ベースのリカバリ保存ポリシーをお薦めします。
フラッシュ・リカバリ領域のファイルが不要になった後でも、通常は新規ファイルのために領域が必要になるまで削除されません。領域に空きがあるかぎり、最近テープに移動されたファイルはリカバリの際にテープからリカバリしなくてもよいようにディスクに残ります。不要なファイルおよびテープに移動されたファイルがフラッシュ・リカバリ領域から自動的に削除されるため、フラッシュ・リカバリ領域はアーカイブ先として便利です。その他の場所にアーカイブした場合、不要なアーカイブREDOログを手動でクリーンアップする必要があります。
『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』では、フラッシュ・リカバリ領域のサイズ設定方法について説明されています。一般に、フラッシュ・リカバリ領域は大きいほど有効に使用できます。理想的には、保存ポリシーに従って保持されたデータベースをリカバリするために必要なデータファイル、制御ファイル、オンラインREDOログおよびアーカイブ・ログのコピーと、これらのバックアップ・ファイルのコピーを十分に保持できる大きさのフラッシュ・リカバリ領域が必要です。
バックアップ計画に増分バックアップ(詳細は、「データファイルの増分バックアップ」を参照)が含まれる場合、ファイルの保存に十分なフラッシュ・リカバリ領域を追加します。バックアップの一部をテープに移動できる場合、フラッシュ・リカバリ領域のサイズを削減できます。テープからファイルを取得する場合はデータベースのリストア操作およびリカバリに必要な時間が長くなるので注意してください。
リカバリ設定ページでインスタンス・リカバリ、メディア・リカバリおよびフラッシュ・リカバリの設定を構成できます。このセクションでフラッシュ・リカバリ領域を構成し、データベースのアーカイブを有効にします。
最初にデータベースを作成するとき、フラッシュ・リカバリ領域を構成できます。データベース作成時にこのタスクを実行しなかった場合でも、ここでフラッシュ・リカバリ領域を作成できます。
ARCHIVELOG
モードに設定するには、次の手順を実行します。このディレクトリに対するオペレーティング・システム権限がデータベースによるファイルの作成を許可することを確認します。
SYS
としてEnterprise Manager Database Controlにログインします。
リカバリ設定ページが表示されます。
USE_DB_RECOVERY_FILE_DEST
が設定されていない場合は、これをアーカイブ先に設定します。この初期化パラメータでは、フラッシュ・リカバリ領域をアーカイブ先にすることを指定します。
データベース管理を容易にするためのベスト・プラクティスは、フラッシュ・リカバリ領域を唯一のアーカイブ先として使用することです。
このオプションでは、フラッシュ・リカバリ領域にフラッシュバック・ログを生成するように指定します。これにより、フラッシュバック・データベースを使用できるようになります。通常稼働時には、データ・ブロックのイメージが不定期にフラッシュバック・ログに記録されます。フラッシュバック・ログの作成、削除およびサイズ変更は自動的に行われます。
データベースを再起動するよう求めるメッセージが表示されます。
データベースの再起動: ホストとターゲット・データベースの資格証明の指定ページが表示されます。
状態チェックの詳細は、「Database Controlを使用したバックアップおよびリカバリのための資格証明の指定」を参照してください。
定期的に「リフレッシュ」をクリックすると、操作の進行を監視できます。
ARCHIVELOG
モードにデータベースを切り替えた直後に、データベース全体の一貫性(オフライン)バックアップを実行します。
注意:
ARCHIVELOG
モードに切り替える前のバックアップを使用して、切り替え後の状態にデータベースをリストアおよびリカバリすることはできません。したがって、切り替え直後にバックアップを作成しなかった場合は、バックアップなしでデータベースを稼働させることになります。データベース・バックアップの作成の詳細は、「Database Controlを使用したバックアップの実行およびスケジュール設定」を参照してください。
参照:
フラッシュ・リカバリ領域の領域使用量を監視して、バックアップおよびその他のリカバリ関連ファイルの格納に十分な大きさがあることを確認するのは重要です。
リカバリ設定ページが表示されます。
再生可能なフラッシュ・リカバリ領域(GB)および空きフラッシュ・リカバリ領域(GB)の設定は、使用可能な領域の大きさを示します。
多数のバックアップ関連の設定およびポリシーを構成できます。たとえば、バックアップをどのように保存するか、どのデータをバックアップするか、バックアップをどの程度の期間保持するかなどを決定できます。また、設定を構成してバックアップのパフォーマンスを最適化できます。
この項では、有効な設定の基礎となる概念およびDatabase Controlのバックアップ設定ページを使用してそれらを変更する方法について説明します。デバイス・サブページの設定はRecovery Managerのディスクおよびテープへの書込み方法に影響します。
Recovery Managerで作成したデータベース・バックアップは、イメージ・コピーまたはバックアップ・セットとして格納されます。
イメージ・コピーは、ファイルが正確にバイト単位でコピーされたものです。イメージ・コピーは、オペレーティング・システム・レベルでファイルをコピーして作成できます。ただし、オペレーティング・システム・レベルでのファイルのコピーとは異なり、Recovery ManagerまたはDatabase Controlによって作成されたイメージ・コピーは、データベースのリストア操作およびリカバリ時にRecovery Managerが使用できるようにRecovery Managerリポジトリに記録されます。Recovery Managerによるファイルのリストアが可能なのは、Recovery Managerリポジトリにファイルが記録されているときのみです。Recovery Managerは、ディスク上にのみイメージ・コピーを作成できます。
バックアップ・セットとは、Recovery ManagerのBACKUP
コマンドで生成される論理エンティティです。このコマンドにより、ディスクまたはメディア管理デバイス上に1つ以上のバックアップ・セットを生成できます。Recovery Managerは、メディア・マネージャにのみバックアップ・セットを書き込むことができます。
各バックアップ・セットにはバックアップ・ピースと呼ばれるいくつかの物理ファイルが含まれています。1つのバックアップ・ピースに、1つ以上のデータベース・ファイルのバックアップがRecovery Manager固有のコンパクトな形式で格納されます。バックアップ・セットの利点の1つとして、未使用ブロックの圧縮により、データファイルのバックアップに使用される領域を節約できることがあげられます。データファイルの中でデータの格納に使用されたブロックのみがバックアップ・セットに含められます。
Recovery Managerは、データベース・サーバー上で実行されるプロセスであるサーバー・セッションによって異なり、バックアップが作成され、リストアされます。各サーバー・セッションが、バックアップ・デバイスを行き来するデータの流れを表すRecovery Managerチャネルに順に対応しています。チャネルは、タイプ・ディスクまたはタイプSBT(テープ)のいずれかです。
Recovery Managerでは、1つのバックアップの作業またはリカバリ・タスクを実行する複数のチャネルおよびサーバー・セッションを使用する、並列化がサポートされています。並列化の正しい活用によりバックアップおよびリカバリ・タスクのパフォーマンスを大幅に向上できます。
ディスクベース・バックアップの場合、バックアップのデフォルトの形式、ディスク上のバックアップの保存先、およびバックアップ・タスクが並行して実行されるかどうかを構成できます。
テープへのバックアップの場合、テープ・ドライブの数やバックアップを圧縮するかどうかなどの設定を構成できます。ほとんどのプラットフォームでは、Oracle Databaseにメディア・マネージャを統合し、連続したメディアを格納に使用する必要があります。
データベースおよびファイル・システムのテープへのバックアップをサポートするOracle Secure Backupをメディア・マネージャとして使用できます。Oracle Secure Backupは、他のサード・パーティSBTインタフェースと同じサービスをRecovery Managerに提供しますが、他のインタフェースより密接にDatabase Controlに統合されています。この項では、ディスク・バックアップのみを作成すると想定しています。
バックアップ設定ページが表示されます。
バックアップ設定のデバイス・サブページが表示されます。
1
と入力します。この値は、後で変更できます。Recovery Managerの並列性およびパフォーマンスについては、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
バックアップ・セットの利点の1つとして、未使用ブロックの圧縮により、データファイルのバックアップに使用される領域を節約できることがあげられます。データファイルの中でデータの格納に使用されたブロックのみがバックアップ・セットに含められます。
「Database Controlを使用したバックアップおよびリカバリのための資格証明の指定」の説明に従ってホスト資格証明を入力します。
テストに成功したかどうかを示すメッセージが表示されます。
この例では、バックアップ・セット・サブページの設定を変更しません。
制御ファイルおよびサーバー・パラメータ・ファイルのバックアップ、データベース全体のバックアップから除外する表領域、およびバックアップ保存ポリシーを制御するバックアップ・ポリシーを設定できます。
バックアップ設定ページが表示されます。
バックアップ・ポリシー・サブページが表示されます。
サーバー・パラメータ・ファイルと制御ファイルはデータベースおよびRecovery Managerに不可欠であり、そのサイズは通常のデータファイルに比べて小規模です。頻繁にバックアップしても、格納のオーバーヘッドはそれほど大きくありません。
このオプションを選択すると、フラッシュ・リカバリ領域の領域を節約できます。
このオプションを選択すると、ブロック変更トラッキング機能を利用できます。これにより、オーバーヘッドをほとんどかけずに増分バックアップのパフォーマンスを大幅に高めることができます。
この機能を使用すると、バックアップから除外する表領域のリストを指定できます。たとえば、読取り専用の表領域をすべてのバックアップに含める必要はありません。
31
と入力します。この設定により、期間ベースで保存を行うリカバリ・ポリシーが有効になります。
このオプションにより、ログが自動削除の対象となるのはテープにバックアップされたとき、または保存ポリシーに基づいて不要になったときのみであることを指定します。
この項では、Oracle Enterprise Manager Database Control(Database Control)でデータベースのバックアップを作成する方法について説明します。オラクル社が推奨するディスクのみのバックアップ計画は、データベースの日常的なバックアップを効率化します。この計画により、現在から24時間前までの任意の時点の状態に、データベースを迅速に戻すことができます。より柔軟なバックアップ・オプションの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
この項では、オラクル社が推奨するバックアップ計画、およびDatabase Controlを通じて提供されているその他のバックアップ・タイプの理解に必要な概念を説明します。
データファイルの全体バックアップにはデータファイルのすべての使用済ブロックが含まれます。「Recovery Managerバックアップについて」で説明されているように、Recovery Managerバックアップはイメージ・コピーとバックアップ・セットのいずれかです。イメージ・コピーはデータファイルのビット単位のコピーであり、未使用ブロックを含みます。
Recovery Manager増分バックアップ・コピーでは、バックアップ間で変更されたデータファイルのブロックのみ取得されます。データファイルのすべてのブロックをコピーしたレベル0の増分バックアップは、増分バックアップ計画の開始点として使用されます。
レベル1の増分バックアップは、前回の増分バックアップの後で変更されたブロックのイメージのみをコピーします。レベル1のバックアップは、直新のレベル0のバックアップ以降に変更されたすべてのブロックが含まれます。または直近のレベル0またはレベル1の増分バックアップ以降に変更されたブロックのみが含まれる差分です。通常の増分バックアップ計画では、レベル1のバックアップを1日1回のように定期的に行います。
変更されたブロックを増分バックアップからリカバリすると、メディア・リカバリを高速化できます。増分レベル1のバックアップ・コピーには、増分バックアップ計画の対象となる期間内に変更されたすべてのデータファイル・ブロックの最終的な内容がコピーされるため、リカバリ・プロセスでは、その期間のREDOログにおける個々の更新の再適用は省略して、各ブロックを最終的な内容に更新できます。REDOログが使用されるのは、レベル1のバックアップの対象とならない期間に行われた変更に対してのみです。
Recovery Managerを使用すると、レベル1の増分バックアップをデータファイルの古いイメージ・コピーに適用できます。古いコピーを最新のレベル1増分バックアップの時点にロールフォワードすることが可能です。イメージ・コピー作成後に変更されたブロックはすべて、最新のレベル1増分バックアップの時点の新しい内容で上書きされます。その結果、ファイルがロールフォワードされ、ファイルの内容は最新のレベル1増分バックアップの時点に作成されたデータファイルのイメージ・コピーと等しくなり、データベースがリカバリされます。
増分的に更新されたバックアップをバックアップ計画に組み込むことで、予想リカバリ時間を短縮できます。これは現時点または最近の過去のある時点までのメディア・リカバリが、最新の全データベース・バックアップ時ではなく最新のレベル1のバックアップが適用された時点から開始できるためです。
すべてのRecovery Managerバックアップ(増分バックアップを含む)にタグが付いています。タグとは、そのバックアップを一意に、またはバックアップ・グループの一部として識別するテキスト文字列です。たとえば、毎週土曜日の夜にデータベースの週次全体バックアップを実行した場合、タグFULL_SAT
を使用してすべての週次全体バックアップを識別できます。
タグを使用すると、Recovery Managerコマンドで特定のバックアップを参照できます。たとえば、最新のFULL_SAT
バックアップをテープに移動するコマンドを発行できます。タグを指定しない場合は、一意のタグが自動的に作成されます。
タグを使用し、バックアップの異なるグループを参照できるため、異なるルーチンを互いに干渉しないバックアップ計画に作成できます。バックアップ・ジョブのスケジュールを設定しジョブ名を与えると、ジョブ名はタグとして使用されます。
Database ControlによりRecovery Managerバックアップを実行し、バックアップ計画に必要なバックアップ・ジョブのスケジュールを設定できます。
データベース全体のバックアップには、データベースのすべてのデータファイルの完全な内容の他、制御ファイル、アーカイブREDOログおよびサーバー・パラメータ・ファイルが含まれています。これらのファイルを使用すると、完全リカバリを実行できます。
データベース全体のバックアップは総合的なバックアップ計画の重要な要素ですが、ARCHIVELOG
モードを有効化または無効化するとき(「リカバリ設定の構成」を参照)のように、必須の手順となる場合もあります。この項では、データベース全体のバックアップをディスクに作成する方法について説明します。
バックアップのスケジュール・ページが表示されます。
カスタマイズ・バックアップのスケジュール: オプション・ページが表示されます。
通常は、データベースの可用性を最大化するためにオンライン・バックアップを実行します。
注意:
「基本バックアップおよびリカバリのためのデータベースの構成」で説明したとおり、データベースが |
オフライン・バックアップを実行する場合、アーカイブ・ログをバックアップする必要はありません。これは、データベースがバックアップ時に一貫性が保たれた状態にあり、このバックアップからデータベースをリストアする場合はメディア・リカバリを必要としないためです。しかし、必要に応じてアーカイブ・ログをバックアップに含めることもできます。
この場合、バックアップされたREDOログは、領域が不足すると自動的に削除されます。他のアーカイブ先を使用している場合は、バックアップ記憶域の管理の一環としてこのオプションを選択すると便利です。
この場合、不要になったバックアップは、領域が不足すると自動的に削除されます。バックアップ・ファイルに対して他のアーカイブ先を使用している場合は、このオプションを選択できます。
セキュリティを強化するために、ユーザーが選択したアルゴリズムでRecovery Managerバックアップ・セットを暗号化できます。権限のないユーザーは暗号化されたバックアップを読み取ることができません。
カスタマイズ・バックアップのスケジュール: 設定ページが表示されます。
可能なかぎりディスクにバックアップして、テープからのリストア操作に要する時間を最小限に抑え、リカバリ時間を最小化することをお薦めします。ディスク・バックアップは後でテープに移動できます。
カスタマイズ・バックアップのスケジュール: スケジュール・ページが表示されます。
ステータス・ページが表示されます。このページには、ジョブが正常に送信されたことを示すメッセージが含まれます。
実行: データベース・ページが表示されます。このページにはジョブについて説明している「サマリー」セクションが含まれています。ページの下の表にはバックアップ・ジョブの様々な手順の進行が表示されます。現在進行しているジョブを監視するためにブラウザでこのページを再ロードできます。
表の「名前」列でRecovery Managerジョブの現在のフェーズを確認できます。バックアップ・ジョブのフェーズ名をクリックするとジョブの一部分のRecovery Manager出力が含まれたページが表示されます。このページからブラウザにある「戻る」ボタンをクリックすると、実行: データベース・ページに戻ります。
Database Controlにより、ディスクへバックアップするというオラクル社が推奨するバックアップ計画の設定が容易になります。このバックアップではデータを保護し、ユーザー指定のリカバリ期間の任意の時点までの有効なリカバリ可能ポイントを提供します。オラクル社が推奨する計画では増分バックアップおよび増分的に更新されたバックアップ機能を使用し、データベース全体のバックアップよりも早いバックアップ、およびアーカイブ・ログからデータファイルへデータベースの変更を適用しリカバリするよりも早いリカバリ可能性を提供します。
オラクル社が推奨する計画はデータベースのイメージ・コピー作成に基づいています。データベースはバックアップの追加更新によりコピーをロールフォワードします。Oracle Enterprise ManagerはRecovery Managerバックアップ・ジョブを深夜にスケジューリングします。
各データファイルについて、バックアップに必要な計画は次のとおりです。
リカバリが必要な場合は、1日目からのREDOログを使用して、1日目の任意の時点にリカバリできます。
リカバリが必要な場合は、Recovery Managerはこの増分レベル1を適用して、レベル0のバックアップを2日目のはじめにロールフォワードできます。Recovery Managerでは、REDOログを使用して2日目の任意の時点にリカバリできます。
リカバリが必要な場合は、Recovery Managerはn-1日からn日のはじめにロールフォワードされたデータファイルに増分レベル1のバックアップを適用できます。Recovery Managerでは、REDOログを使用してデータベースをn日の任意の時点にリカバリできます。
推奨バックアップ計画で使用されるデータファイルのコピーにはORA$OEM_LEVEL_0
というタグが付いています。この計画で使用されるレベル1の増分バックアップは、このラベルの付いたデータファイルのコピーとともに使用できるよう作成されます。オラクル社が推奨するバックアップ計画を妨げることなく、他のバックアップ計画を安全に実装できます。
オラクル社が推奨するバックアップ計画では、ディスク・バックアップとともにテープ・バックアップを使用しますが、この項では扱いません。
次の手順では、データベースの日次バックアップをスケジュールします。この計画は増分バックアップと増分的に適用されたバックアップを使用しており、過去24時間以内の任意の時点にすばやくリカバリすることが可能です。
バックアップのスケジュール・ページが表示されます。
推奨バックアップのスケジュール: バックアップ先ページが表示されます。このページではディスクまたはテープ、あるいは両方などのバックアップのための接続メディアを選択します。
「推奨バックアップのスケジュール: 設定」ページが表示されます。
このページには、ディスク・ベースの計画の一環として毎日実行するバックアップの説明が表示されます。
推奨バックアップのスケジュール: スケジュール・ページが表示されます。
推奨バックアップのスケジュール: 確認ページが表示されます。
Database Controlに、Recovery Managerによって実行されるバックアップ・スクリプトが表示されます(ただし、スクリプトを直接編集することはできません)。スクリプトは次のようになります。
Daily Script: run { allocate channel oem_disk_backup device type disk; recover copy of database with tag 'ORA$OEM_LEVEL_0'; backup incremental level 1 cumulative copies=1 for recover of copy with tag 'ORA$OEM_LEVEL_0' database; }
『Oracle Databaseバックアップおよびリカバリ基礎』で説明されている様々な使用可能なバックアップ・オプションについて理解を深めた後、推奨バックアップ計画の実装に使用するタスク以外のバックアップ・タスクのスケジュールを決定できます。
バックアップのスケジュール・ページが表示されます。
各ページに表示される選択肢は、バックアップするオブジェクトのタイプによって決まります。ウィザードの使用方法の詳細は、各ページの「ヘルプ」をクリックしてください。
バックアップ計画の一部として、バックアップが正常でありリカバリ可能オブジェクトを満たしているかを定期的にチェックする必要があります。バックアップは次の方法で検証できます。
いずれの検証形式も、Database Controlでスケジュール済タスクとして設定できます。検証の形式をバックアップ計画に両方組み込み、使用可能なバックアップが常にリカバリ可能な目的を満たしていることを確認します。
特定のバックアップの検証では、バックアップが存在し、リストア可能であるかどうかがチェックされます。使用可能なバックアップ・セットでリカバリが可能かどうかのテストは行われません。たとえば、データベースの複数の表領域におけるデータファイルのイメージ・コピーが存在し、それぞれが検証可能であるとします。ただし、その中に有効なバックアップが存在しない表領域がある場合、データベースをリストアおよびリカバリすることはできません。
現行バックアップの管理ページが表示されます。
検証: ジョブ・パラメータの指定ページが表示されます。
メッセージによりジョブの送信が確認されます。
指定したデータベース・ファイルのリストアに使用できる十分なバックアップ・セットが存在するかどうかをテストできます。リストアする表領域、およびどの時点にリストアするか(指定可能な場合)を指定すると、必要なデータを含むバックアップ・セットが自動的に選択されます。Recovery Managerは、選択したバックアップ全体を読み取り、ファイルが壊れていないことを確認しますが、出力ファイルは生成しません。
ファイルのリストアの検証により、ファイルが使用可能なバックアップとしてリストアされるかどうかをテストできますが、指定したオブジェクトのすべてのバックアップが有効かどうかはテストできません。
リカバリの実行ページが表示されます。
オブジェクト・レベルのリカバリの実行ページが表示されます。
オブジェクト・レベルのリカバリの実行: リストア・ページが表示されます。
オブジェクト・レベルのリカバリの実行: 確認ページが表示されます。
リカバリの実行: 結果ページが表示されます。
バックアップ・レポートには、Recovery Managerによって実行された過去のバックアップ・ジョブに関するサマリーおよび詳細情報が記録されています。詳細情報には、Oracle Enterprise Manager Database Control(Database Control)とRecovery Managerコマンドライン・クライアントの両方で実行されたバックアップが含まれます。
バックアップ・レポート・ページには最近のバックアップ・ジョブのリストが含まれます。ジョブのステータス、バックアップの開始時間およびタイプによりリストされたバックアップを制限(フィルタ処理)するためのページの「検索」セクションを使用します。「検索」セクションで任意のフィルタ条件を指定し、「実行」をクリックします。
選択したバックアップのバックアップ・レポート・ページが表示されます。
バックアップ計画の一環として、データベースのバックアップを管理する必要があります。関連タスクの1つに、Recovery Managerリポジトリのバックアップ・レコードの管理があります。Oracle Enterprise Manager Database Control(Database Control)はこれらのタスクを簡略化します。
バックアップおよびリカバリ計画で重要なことは、作成後のバックアップの管理です。バックアップ管理には不要なバックアップの削除、およびバックアップが使用可能であるかを確認する定期的なチェックの実行が含まれます。
バックアップ管理タスクは現行バックアップの管理ページから実行できます。このページには、バックアップ・セットとイメージ・コピーの2つのサブページがあります。どちらのページも、Recovery Managerリポジトリのレコードに基づいてバックアップをリスト表示し、バックアップの管理を可能にするという目的を果します。
Recovery Managerリポジトリに記録されたバックアップには次のステータス値のいずれかがあります。
バックアップは不要になることもあります。不要なバックアップは、現在構成されている保存ポリシーに基づいて、データ・リカバリの目的を満たすために必要でなくなったバックアップです。
Database Controlで実行できるメンテナンス・タスクは次のとおりです。
Database Controlのバックアップおよびリストア・コマンドと同様に、バックアップ・ステータスのクロスチェック、削除および変更を行うコマンドは最終的にRecovery Managerコマンドに変換されます。Recovery Managerコマンドは、即時実行またはスケジュール設定が可能なRecovery Managerジョブとして発行されます。バックアップの定期的なクロスチェックなどのタスクは、バックアップ計画の一環として定期的にスケジュールしてください。
フラッシュ・リカバリ領域をバックアップ記憶域として使用すると、多くのメンテナンス・アクティビティが不要になるか、削減されます。バックアップおよびその他のファイルは、必要に応じて自動ディスク領域管理メカニズムにより削除されます。このため、保存ポリシーに違反することなく、進行中のデータベース操作での領域の需要を満たすことができます。
バックアップをクロスチェックすると、バックアップの物理的な状況をRecovery Managerリポジトリ内の論理レコードと同期させることができます。たとえば、ディスク上のバックアップをオペレーティング・システム・コマンドで削除した場合は、クロスチェックでこの状況が検出されます。クロスチェックの後、バックアップの状態がRecovery Managerリポジトリに正確に反映されます。
ディスクへのバックアップは、Recovery Managerリポジトリに表示された場所のディスクにある場合、およびファイル・ヘッダーに破損がない場合、使用可能としてリストされます。テープへのバックアップは、バックアップがテープ上にある場合に使用可能と表示されます(ただしファイル・ヘッダーは破損をチェックされません)。欠落していたり破損しているバックアップは期限切れとしてリストされます。
現行バックアップの管理ページが表示されます。
クロスチェックを行うイメージ・コピーとバックアップ・セットの両方を1回の操作では選択できません。
確認ページが表示された後、Database Controlによりクロスチェックが実行されます。
現行バックアップの管理ページが表示されます。
すべてをクロスチェック: ジョブ・パラメータの指定ページが表示されます。クロスチェックを即時実行または後で実行するようにスケジュールできます。クロスチェックを定期的にスケジュールすることも可能です。
参照:
CROSSCHECK
コマンドを使用したこの手順の実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
期限切れバックアップを削除すると、EXPIRED
としてリストされたバックアップがRecovery Managerリポジトリから削除されます。期限切れバックアップとは、クロスチェック中にアクセス不可能であることが判明したバックアップです。バックアップを含むファイルがディスクまたはテープから削除されることはありません。この操作ではRecovery Managerリポジトリのみの更新が実行されます。
現行バックアップの管理ページが表示されます。
この操作により、現在どのサブページがアクティブであるかには関係なく、期限切れのバックアップ・セットと期限切れのイメージ・コピーがRecovery Managerリポジトリから削除されます。
期限切れのものをすべて削除: ジョブ・パラメータの指定ページが表示されます。
期限切れのバックアップを削除する直前にクロスチェックを実行することで、Recovery Managerはどのバックアップが期限切れになっているかに関する最新の情報を取得できます。
ジョブが正常に発行されたことを示すメッセージが表示されます。
ディスク・ドライブが一時的にオフラインになっていたり、テープがオフサイトに保管されているなど、一時的な条件のために1つ以上の特定のバックアップを使用できない場合、これらのバックアップを使用不可とマークできます。使用不可のバックアップは、データのリストアおよびリカバリで使用されません。
Recovery Managerリポジトリには、使用不可のバックアップのレコードが保持されていて、期限切れバックアップを削除する場合、使用不可としてリストされたバックアップがRecovery Managerに削除されることはありません。使用不可のバックアップが再度アクセス可能になると、使用可能のマークを付けられます。
現行バックアップの管理ページが表示されます。
確認メッセージが表示されます。
この項では、構成済の保存ポリシーで必要とされていない不要なバックアップの削除方法について説明します。フラッシュ・リカバリ領域を唯一のディスクベースのバックアップ先として使用している場合、不要なバックアップをディスクから削除する必要はありません。フラッシュ・リカバリ領域では、ファイルは保存ポリシーで指定したとおりに保持され、領域が不足した場合にのみ削除されます。
現行バックアップの管理ページが表示されます。
「不要なものをすべて削除」をクリックしたときにバックアップ・セット・サブページとイメージ・コピー・サブページのどちらが表示されていたかに関係なく、不要なバックアップ(バックアップ・セットとイメージ・コピーの両方)がすべて削除されます。
不要なものをすべて削除: ジョブ・パラメータの指定ページが表示されます。
オラクル社推奨のリカバリ機能では、データ・リカバリ・アドバイザを利用します。これは、データ障害を自動的に診断して適切な修復オプションを決定、提示し、ユーザーの要求に応じて修正を実行するOracle Database機能です。データ・リカバリ・アドバイザは、データ修復を自動化する一元化ツールにより、Oracle Databaseの管理性および信頼性を改善します。
データ・リカバリ・アドバイザにおける状態チェックとは、データベースまたはデータベース・コンポーネントの状態を評価するために状態モニターが実行する診断手順です。状態チェックは、エラーの発生を受けて実行されます。手動で実行することもできます。
障害とは、状態チェックで検出された永続的なデータ破損です。通常、障害は発生後に検出されます。データベース操作によってデータが破損するとエラーになり、データベースで状態チェックが自動的に実行されます。このチェックでは、エラーに関連した障害がないかどうかデータベースが調査されます。障害が診断された場合は、自動診断リポジトリ(ADR)に記録されます。
データベースで障害が検出され、ADRに格納された後にかぎり、データ・リカバリ・アドバイザを使用して修復アドバイスを生成し、障害を修復できます。データ・リカバリ・アドバイザは、アクセス不可能なファイル、物理的および論理的なブロック破損、I/O障害などの障害をレポートし、修復します。すべての障害に、CRITICAL、HIGH、LOWのいずれかの障害優先度が設定されます。OPENまたはCLOSEDの障害ステータスも設定されます。
また、データ・リカバリ・アドバイザを使用して修復オプションを表示することもできます。修復とは、1つ以上の障害を修正する処理です。修復の例としては、ブロック・メディア・リカバリ、データファイル・メディア・リカバリ、Oracle Flashback Databaseなどがあげられます。通常、データ・リカバリ・アドバイザは自動と手動両方の修復オプションを提示します。必要に応じて、修復を実行するために、自動修復オプションを選択できます。その場合、データ・リカバリ・アドバイザは修復が正常に行われたことを確認し、該当する修復済の障害をクローズします。
リカバリ・プロセスは、障害が疑われるとき、または障害が検出されたときに起動します。障害は、エラー・メッセージ、アラート、トレース・ファイル、状態チェックなど、多くの方法で検出できます。その後、データ・リカバリ・アドバイザを使用して障害に関する情報およびアドバイスを取得し、障害を自動的に修復することができます。
この項では、データ・リカバリ・アドバイザを使用して破損ブロックを修復する例について説明します。データベースのホームページの診断メーターがインシデントの発生を示していると仮定してください。データベースのホームページの「アラート」セクションにブロックの破損の発生が示されます。
リカバリの実行ページが表示されます。リカバリの実行ページは、「Oracle推奨のリカバリ」とユーザー主導リカバリの2つのセクションに分かれています。「Oracle推奨のリカバリ」セクションでは、データ・リカバリ・アドバイザを使用してリカバリが自動化されます。
手順2のスクリーンショットでは、このセクションに優先度の高い障害が1つ存在することが示されます。障害の内容は、データファイル1に破損ブロックが含まれているというものです。
障害の表示および管理ページが表示されます。
この操作を行うと、データ・リカバリ・アドバイザで認識されている障害をすべて表示できます。データ障害は、ページ下部にナビゲーション・ツリー形式で表されます。
リカバリ・アドバイス・ページが表示されます。
このページには、障害の修復に使用されるRecovery Managerスクリプトが表示されます。たとえば、破損ブロックの場合、スクリプトは次のようになります。
# block media recovery recover datafile 1 block 63467;
確認ページが表示されます。このページには、リカバリ・ジョブの概要がまとめられています。
ジョブ・アクティビティ・ページが表示されます。
ジョブ名、ジョブ・ステータス、修復の実行がスケジュールされている時間、ジョブの所有者などの修復の詳細が表にまとめられています。
ジョブ実行ページが表示されます。
ナビゲーション・ツリーのジョブ・ステップをクリックすると、そのジョブの結果を表示できます。
Oracle Enterprise Manager Database Control(Database Control)のユーザー主導リカバリ機能には、フラッシュバック機能を使用してリストアの操作およびリカバリの手順を実行できるリカバリ・ウィザードが用意されています。たとえば、次の操作を実行できます。
Database Controlでは、データベース操作に影響を与える前に、破損したデータベース・ファイルなどを検出する状況を含め、データベースのどの部分をリストアおよびリカバリする必要があるかを決定できます。Database Controlは順を追ってリカバリし、必要な情報を要求し、指定されたリカバリ・アクションを実行します。
この項では、リカバリの実行ページについて理解を深めるため、いくつかの一般的なリカバリの例を扱います。リカバリの実行ページを使用すると、Database Controlによる他のデータベース全体の機能やオブジェクト・レベルのリカバリ機能にアクセスできます。
Oracle Flashback Tableを使用すると、他のデータベース・オブジェクトに影響を与えることなく、1つ以上の表を過去のある時点の内容に戻すことができます。したがって、表の行を誤って追加または削除した場合のような論理的なデータ破損からのリカバリが可能です。Point-in-Timeリカバリとは異なり、データベースはフラッシュバック操作中も使用可能なままです。
この例では、employees
スキーマのhr
表にあるフラッシュバック表を使用します。2005年10月23日15時30分00秒の直後の誤った更新により、すべての従業員のlastname
列を空の文字列に変更したと想定すると、元のlastname
値を表に戻す必要があります。
フラッシュバック表を使用する前に、フラッシュバックする(以前の状態に戻す)表で行の移動が有効になっていることを確認する必要があります。行の移動とは、フラッシュバック発生後にROWIDが変わることを意味します。このような制約が存在するのは、フラッシュバック前のROWIDをアプリケーションが保存していた場合に、フラッシュバック後もそのROWIDが同じ行に対応する保証はないためです。
表ページが表示されます。
この例では、employees
を選択します。
表の編集: table_nameページが表示されます。
更新メッセージが表示されます。
この例では、hr.jobs
およびhr.departments
の各表で行の移動を有効化する必要があります。
この例では、hr.employees
表およびその依存表を過去のある時点に巻き戻します。
リカバリの実行ページが表示されます。
このページでは表のオブジェクト・レベルのリカバリを使用して再ロードされます。
オブジェクト・レベルのリカバリの実行: Point-in-Timeページが表示されます。
この例では、5分前に行を誤って挿入したと想定しています。「タイムスタンプにフラッシュバック」を選択し、5分前の時刻を入力します。
オブジェクト・レベルのリカバリの実行: 表のフラッシュバック・ページが表示されます。
複数の表名を入力すると、複数の表を同じ時点にフラッシュバックできます。「表の追加」をクリックして、他の表を検索することもできます。この例では、「フラッシュバックする表」テキスト・ボックスにhr.employees
と入力します。
表に他の依存表が存在する場合、依存状態オプション・ページが表示されます。このページでは、依存性をどのように処理するかを決定します。
「依存状態の表示」をクリックすると、影響を受ける表を確認できます。
この例では、hr.employees
表に依存表hr.jobs
およびhr.departments
があります。そのため、「重ねて表示」を選択して「次へ」をクリックします。
オブジェクト・レベルのリカバリの実行: 確認ページが表示されます。
操作が完了すると、確認ページに結果が表示されます。「OK」をクリックしてデータベースのホームページに戻ります。
Oracle Flashback Dropを使用すると、削除した表を索引やトリガーなどの依存オブジェクトとともにデータベースに戻して、表の削除の影響を取り消すことができます。この機能では削除したオブジェクトがごみ箱に格納されますが、ごみ箱の中のオブジェクトは、ユーザーの明示的な指定または領域不足によりごみ箱がパージされるまで取得可能です。
フラッシュバック表と同様に、フラッシュバック・ドロップはデータベースがオープンしているときに使用できます。また、フラッシュバックを行っても、フラッシュバック・ドロップ操作の影響を受けないオブジェクトの変更が取り消されることはありません。フラッシュバック表は、データベースをオフラインにしてバックアップからファイルをリストアする必要のあるメディア・リカバリ形式より便利です。
フラッシュバック・ドロップについて学習するため、reg_hist
という表を新しく作成して、後で削除します。フラッシュバック・ドロップ機能で取得できるため、表はごみ箱に配置されます。
表ページが表示されます。
hr
、「オブジェクト名」フィールドにregions
と入力し、「実行」をクリックします。ページ下部の表にスキーマおよび表がリスト表示されます。
表の作成ページの一般サブページが表示されます。
reg_hist
と入力し「実行」をクリックします。表ページにこの表に関する情報が表示されます。
オプションを指定して削除ページが表示されます。
メッセージにより表が削除されたことが確認されます。
この項では、「表の削除」の説明に従ってreg_hist
表を作成して削除したと想定しています。次の手順でごみ箱からreg_hist
を取得します。
リカバリの実行ページが表示されます。
このページでは表のオブジェクト・レベルのリカバリを使用して再ロードされます。
オブジェクト・レベルのリカバリの実行: 削除したオブジェクト選択項目ページが表示されます。
この例では、「スキーマ名」フィールドにhr
、「表」フィールドにreg_hist
と入力し、「実行」をクリックします。
検索条件に一致するオブジェクトが「結果」セクションにリスト表示されます。必要に応じて、ごみ箱の横の矢印をクリックして内容を1レベル展開し、検索条件に一致する削除済の表(依存オブジェクトを除く)を表示します。
この例では、reg_hist
を選択して「次へ」をクリックします。
オブジェクト・レベルのリカバリの実行: 名前の変更ページが表示されます。
オブジェクトをごみ箱から取得するときにオブジェクト名を変更する第1の理由は、取得する表と同じ名前の新しい表がすでに作成されている可能性があるためです。オブジェクト名前の変更の必要がある場合は、必要に応じて「新しい名前」フィールドに新しい名前を入力します。
オブジェクト・レベルのリカバリの実行: 確認ページが表示されます。このページにはフラッシュバック・ドロップ操作完了時に持つ名前、依存オブジェクトを含むフラッシュバックされたオブジェクトの全設定が示されている影響分析が表示されます。
確認ページにより操作が正常であることが示されます。
他のフラッシュバック機能とは異なり、Oracle Flashback Databaseは物理レベルで動作します。フラッシュバック・データベースを使用すると、現在のデータファイルが前のある時点の内容に戻ります。結果はデータベースのPoint-in-Timeリカバリとほぼ同じですが、データファイルのリストアおよびリカバリの必要がないので、フラッシュバック・データベースの方が格段に高速です。また、メディア・リカバリに比べてREDOデータ適用の必要性はわずかです。
フラッシュバック・データベースでは、データ・ブロックの旧バージョンへのアクセスにフラッシュバック・ログが使用され、アーカイブREDOログのデータも一部使用されます。フラッシュバック・データベースを使用してデータベースを修復するには、「リカバリ設定の構成」の説明に従って、フラッシュバック・ログが生成されるようにデータベースを構成する必要があります。
リカバリの実行ページが表示されます。
確認ページが表示されます。
リカバリ・ウィザード・ページが表示されます。この時点で停止作業が開始されます。
データベースが停止し、マウントされた状態になると、Database Controlも一時的に停止して、再起動します。このプロセスの実行中、Database Controlがブラウザに応答できない時間があります。Database Controlが再度応答するまでページをリフレッシュしてください。
Database Controlが再起動し、データベースが起動されマウントされると、しばらくしてDatabase Controlにより、データベースがNOMOUNT
状態であることを報告するレポートが出力されます。「リフレッシュ」、「起動」および「リカバリの実行」の選択肢が提示されます。続行する前にデータベース・インスタンス・ページでデータベース・インスタンスがマウントされたと報告されるまで、ページを定期的にリフレッシュします。
SYSDBA
ロールで接続するか、DBA
グループのユーザーのホスト・コンピュータ資格証明を指定します。状態チェックの詳細は、「Database Controlを使用したバックアップおよびリカバリのための資格証明の指定」を参照してください。
リカバリの実行ページが再度表示され、データベース全体をリストアおよびリカバリする必要のあるデータベースがマウントされたことが表示されます。
確認ページが表示されます。
データベース全体のリカバリの実行: フラッシュバック・ページが表示されます。
データベース全体のリカバリの実行: 確認ページが表示されます。
フラッシュバック操作が完了すると、リカバリの実行: 結果ページが表示されます。
データベースが正常にオープンしたら「OK」をクリックします。
この項では、データベース全体をリストアおよびリカバリする方法を示します。この例では、1つ以上のデータファイルを損失した後、なお使用可能なサーバー・パラメータ・ファイルと制御ファイルがある場合にデータベースをリストアおよびリカバリすることを想定します。Database Controlを使用して損失したサーバー・パラメータ・ファイルまたは制御ファイルをリストアすることもできます。
この例では、「現在の時間へのリカバリ」を選択して、「次へ」をクリックします。
データベース全体のリカバリの実行: 修復ページが表示されます。
データベース全体のリカバリの実行: 確認ページが表示されます。
リカバリが完了すると、リカバリの実行: 結果ページが表示されます。
Oracle by Example(OBE)には、このマニュアルに関するシリーズが含まれています。このOBEでは、この項のタスクを段階的に説明し、注釈付きのスクリーンショットを使用します。バックアップおよびリカバリのOBEを表示するには、ブラウザに次のURLを指定します。
http://www.oracle.com/technology/obe/11gr1_2day_dba/backup/backup.htm
|
Copyright © 2004, 2008, Oracle Corporation. All Rights Reserved. |
|