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