| Oracle® Data Guard概要および管理 11gリリース2 (11.2) B56302-06 |
|
 前 |
 次 |
この章ではフィジカル・スタンバイ・データベースの作成手順を説明します。この章の内容は次のとおりです。
この章に記載の手順に従うと、デフォルト・データ保護モードである最大パフォーマンス・モード用のスタンバイ・データベースを構成できます。各種データ保護モードの構成の詳細は、第5章を参照してください。
|
関連項目:
|
スタンバイ・データベースを作成する前に、プライマリ・データベースが正しく構成されていることを確認する必要があります。
表3-1は、フィジカル・スタンバイ・データベースを作成するための準備としてプライマリ・データベースで実行するタスクのチェックリストです。各タスクを詳細に説明している参照先の項も記載されています。
|
注意: これらの準備のためのタスクは、1回のみ実行してください。これらの手順を完了すると、データベースは、1つ以上のスタンバイ・データベースに対するプライマリ・データベースとして機能する準備が整います。 |
プライマリ・データベースをFORCE LOGGINGモードにします。これは、データベース作成後に、次のSQL文を使用して実行できます。
SQL> ALTER DATABASE FORCE LOGGING;
この文を発行する場合、プライマリ・データベースを少なくともマウントしておく(また、オープンもできるようにしておく)必要があります。この文は、完了までに非常に時間がかかる場合があります。これは、ログに記録されないダイレクト書込みI/Oがすべて完了するまで待機するためです。
|
関連項目:
|
Data Guardでは、Oracle Netセッションを使用してData Guard構成のメンバー間でREDOデータを転送し、メッセージを制御します。これらのREDO転送セッションは、Secure Sockets Layer(SSL)プロトコルまたはリモート・ログイン・パスワード・ファイルのいずれかを使用して認証されます。
SSLは、次の場合に2つのデータベース間のREDO転送セッションの認証に使用されます。
データベースが同じOracle Internet Directory(OID)エンタープライズ・ドメインのメンバーであり、現行ユーザーのデータベース・リンクの使用を許可する場合
データベースに対応するLOG_ARCHIVE_DEST_nおよびFAL_SERVERの各データベース初期化パラメータで、SSL用に構成されたOracle Net接続記述子を使用する場合
各データベースに、データベースのOIDエントリの識別名(DN)と一致するDNが付けられたユーザー証明書を格納するOracleウォレットまたはサポートされるハードウェア・セキュリティ・モジュールがある場合
SSL認証の要件が満たされない場合は、リモート・ログイン・パスワード・ファイルを使用するようにData Guard構成の各メンバーを構成する必要があります。また、構成内のすべてのフィジカル・スタンバイ・データベースには、プライマリ・データベースのパスワード・ファイルの最新コピーが必要です。
|
注意: SYSDBA権限またはSYSOPER権限を付与または取り消すか、これらの権限を持つユーザーのログイン・パスワードを変更するたびに、構成内の各フィジカル・スタンバイ・データベースまたはスナップショット・スタンバイ・データベースで、パスワード・ファイルをプライマリ・データベースのパスワード・ファイルの最新コピーで置き換える必要があります。 |
|
関連項目:
|
このタスクはオプションですが、Data Guard構成の作成時に、REDOデータを受信するようにプライマリ・データベースを構成することをお薦めします。このベスト・プラクティスに従うことで、プライマリ・データベースは、スタンバイ・ロールに速やかに推移してREDOデータの受信を開始できるようになります。
REDOデータを受信するようにデータベースを構成する方法の詳細は、6.2.3項を参照してください。
プライマリ・データベースでは、データベースがプライマリ・ロールで動作している間のREDO転送サービスを制御する初期化パラメータを定義します。また、プライマリ・データベースがスタンバイ・ロールに推移したときにREDOデータの受信と適用サービスを制御するパラメータを追加する必要があります。
例3-1に、プライマリ・データベースでメンテナンスする、プライマリ・ロールの初期化パラメータを示します。この例は、シカゴにプライマリ・データベースがあり、ボストンにフィジカル・スタンバイ・データベースが1つあるData Guard構成を示しています。例3-1に示すパラメータは、シカゴのデータベースがプライマリ・データベース・ロールまたはスタンバイ・データベース・ロールで稼働している場合に有効です。この構成例では、次の表に示す名前を使用しています。
例3-1 プライマリ・データベース: プライマリ・ロールの初期化パラメータ
DB_NAME=chicago DB_UNIQUE_NAME=chicago LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)' CONTROL_FILES='/arch1/chicago/control1.ctl', '/arch2/chicago/control2.ctl' LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/chicago/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_2= 'SERVICE=boston ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
これらのパラメータは、REDO転送サービスがREDOデータをスタンバイ・システムに転送する方法と、ローカル・ファイル・システムでのREDOデータのアーカイブ処理を制御します。例では、LOG_ARCHIVE_DEST_2初期化パラメータにREDOデータを転送する非同期(ASYNC)ネットワーク転送を指定します。これらは推奨設定であり、スタンバイREDOログ・ファイルが必要です(3.1.3項「REDOデータを受信するためのプライマリ・データベースの構成」を参照)。
例3-2に、プライマリ・データベースで定義するスタンバイ・ロールの追加の初期化パラメータを示します。これらのパラメータは、プライマリ・データベースがスタンバイ・ロールに推移すると有効になります。
例3-2 プライマリ・データベース: スタンバイ・ロールの初期化パラメータ
FAL_SERVER=boston DB_FILE_NAME_CONVERT='boston','chicago' LOG_FILE_NAME_CONVERT= '/arch1/boston/','/arch1/chicago/','/arch2/boston/','/arch2/chicago/' STANDBY_FILE_MANAGEMENT=AUTO
例3-2に示す初期化パラメータを指定すると、プライマリ・データベースがギャップを解決するよう設定され、新しいプライマリ・データベースからの新規データファイルとログ・ファイルのパス名を変換して、このデータベースがスタンバイ・ロールで動作しているときの着信REDOデータがアーカイブされます。説明に従ってプライマリおよびスタンバイ・ロールについて初期化パラメータを設定した場合、ロールの推移後に変更が必要なパラメータはありません。
次の表に、例3-1および例3-2に示した各パラメータ設定に関する簡単な説明を示します。
| パラメータ | 推奨する設定 |
|---|---|
DB_NAME |
プライマリ・データベースで、データベースが作成されたときに使用された名前を指定します。フィジカル・スタンバイ・データベースで、プライマリ・データベースのDB_NAMEを使用します。 |
DB_UNIQUE_NAME |
各データベースの一意の名前を指定します。この名前はデータベースと固定され、プライマリ・データベースとスタンバイ・データベースのロールが逆になっても変更されません。 |
LOG_ARCHIVE_CONFIG |
Data Guard機能をすべて有効化するには、このパラメータのDG_CONFIG属性をData Guard構成で明示的に設定する必要があります。構成内の各データベース名のDB_UNIQUE_NAMEを含み、各名前がカンマで区切られたテキスト文字列にDG_CONFIGを設定します。 |
CONTROL_FILES |
プライマリ・データベースの制御ファイルのパス名を指定します。例3-1は2つの制御ファイルに対してこれを行う方法を示しています。制御ファイルの別のコピーを用意しておき、問題のない制御ファイルを問題のある制御ファイルの場所にコピーした後、容易にインスタンスを再開できるようにしておくことをお薦めします。 |
LOG_ARCHIVE_DEST_n |
REDOデータがアーカイブされるプライマリ・システムおよびスタンバイ・システムの位置を指定します。例3-1では、次のようになっています。
注意: 高速リカバリ領域を( |
LOG_ARCHIVE_DEST_STATE_n |
REDO転送サービスがREDOデータを指定した宛先に転送するのを許可するには、ENABLEを指定します。 |
REMOTE_LOGIN_PASSWORDFILE |
リモート・ログイン・パスワード・ファイルを使用して管理ユーザーまたはREDO転送セッションを認証する場合は、このパラメータをEXCLUSIVEまたはSHAREDに設定する必要があります。 |
LOG_ARCHIVE_FORMAT |
スレッド(%t)、順序番号(%s)およびリセットログID(%r)を使用して、アーカイブREDOログ・ファイルのフォーマットを指定します。 |
FAL_SERVER |
FALサーバー(通常はプライマリ・ロールで実行中のデータベース)のOracle Netサービス名を指定します。シカゴのデータベースがスタンバイ・ロールで実行されている場合、ボストンのデータベースが欠落しているログ・ファイルを自動的に送信できなければ、ボストンのデータベースがFALサーバーとして使用され、そこから欠落しているアーカイブREDOログ・ファイルがフェッチ(要求)されます。 |
DB_FILE_NAME_CONVERT |
スタンバイ・データベースのデータファイルのパス名とファイル名の位置を指定し、その後にプライマリの位置を指定します。このパラメータにより、プライマリ・データベースのデータファイルのパス名がスタンバイ・データファイルのパス名に変換されます。スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、またはデータファイルが格納されているスタンバイ・サイトのディレクトリ構造がプライマリ・サイトと異なる場合は、このパラメータが必要です。このパラメータは、フィジカル・スタンバイ・データベースのパス名の変換にのみ使用されることに注意してください。このパラメータにより、複数のペアのパスを指定できます。 |
LOG_FILE_NAME_CONVERT |
スタンバイ・データベースのオンラインREDOログ・ファイルの位置を指定し、その後にプライマリの位置を指定します。このパラメータにより、プライマリ・データベースのログ・ファイルのパス名がスタンバイ・データベースのパス名に変換されます。スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、またはログ・ファイルが格納されているスタンバイ・システムのディレクトリ構造がプライマリ・システムと異なる場合は、このパラメータが必要です。このパラメータにより、複数のペアのパスを指定できます。 |
STANDBY_FILE_MANAGEMENT |
データファイルがプライマリ・データベースに追加または削除された場合に、それに対応してスタンバイ・データベースも自動的に変更されるように、AUTOに設定します。 |
|
注意: 変更が必要なその他のパラメータがないか、初期化パラメータ・ファイルを確認してください。たとえばスタンバイ・データベース上のディレクトリ場所がプライマリ・データベースでの指定と異なる場合は、ダンプ先パラメータを変更する必要があります。 |
アーカイブが有効になっていない場合は、次の文を発行して、プライマリ・データベースをARCHIVELOGモードにし、自動アーカイブを有効にします。
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> ALTER DATABASE ARCHIVELOG; SQL> ALTER DATABASE OPEN;
アーカイブの詳細は、『Oracle Database管理者ガイド』を参照してください。
この項では、フィジカル・スタンバイ・データベースの作成で実行するタスクについて説明します。この章での詳細な説明内容は、『Oracle Database管理者ガイド』、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』、およびOracle Database Net Services管理者ガイド』で説明している次の内容を十分理解していることが前提になっています。
データベース管理者の認証
データベース初期化パラメータ
REDOログ、データファイルおよび制御ファイルの管理
アーカイブREDOログの管理
高速リカバリ領域
Oracle Net構成
表3-2は、フィジカル・スタンバイ・データベースの作成で実行するタスク、および各タスクを実行するデータベースのチェックリストです。各タスクを詳細に説明している参照先の項も記載されています。
表3-2 フィジカル・スタンバイ・データベースの作成
| 参照先 | タスク | データベース |
|---|---|---|
|
|
プライマリ・データベース・データファイルのバックアップ・コピーの作成 |
プライマリ |
|
|
|
プライマリ |
|
|
|
プライマリ |
|
|
プライマリ・システムからスタンバイ・システムへのファイルのコピー |
プライマリ |
|
|
|
スタンバイ |
|
|
|
スタンバイ |
|
|
フィジカル・スタンバイ・データベースが正しく実行されているかどうかの確認 |
スタンバイ |
データベースを完全にリカバリするのに必要なアーカイブREDOログ・ファイルがあるかぎり、プライマリ・データベースのバックアップ・コピーを使用して、フィジカル・スタンバイ・データベースを作成できます。Recovery Manager(RMAN)ユーティリティを使用することをお薦めします。
データベースのバックアップ方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
バックアップ処理のために、プライマリ・データベースを停止する必要がある場合は、次のSQL*Plus文を発行して、プライマリ・データベースを起動します。
SQL> STARTUP MOUNT;
スタンバイ・データベース用の制御ファイルを作成してから、ユーザー・アクセス用にプライマリ・データベースをオープンします。次に例を示します。
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/boston.ctl'; SQL> ALTER DATABASE OPEN;
|
注意: プライマリ・データベースとスタンバイ・データベースの両方に単一の制御ファイルを使用することはできません。 |
次の手順を実行して、スタンバイ・データベースのパラメータ・ファイルを作成します。
次に例を示します。
SQL> CREATE PFILE='/tmp/initboston.ora' FROM SPFILE;
3.2.5項では、このパラメータ・ファイルをフィジカル・スタンバイ・データベースでの使用に適したパラメータ値が含まれるように変更した後で、このファイルからサーバー・パラメータ・ファイルを作成します。
パラメータ・ファイル内の初期化パラメータ設定の大部分はフィジカル・スタンバイ・データベースにも適していますが、一部変更が必要なものがあります。
例3-3 フィジカル・スタンバイ・データベース用の初期化パラメータの変更
. . . DB_NAME=chicago DB_UNIQUE_NAME=boston LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)' CONTROL_FILES='/arch1/boston/control1.ctl', '/arch2/boston/control2.ctl' DB_FILE_NAME_CONVERT='chicago','boston' LOG_FILE_NAME_CONVERT= '/arch1/chicago/','/arch1/boston/','/arch2/chicago/','/arch2/boston/' LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/boston/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2= 'SERVICE=chicago ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE STANDBY_FILE_MANAGEMENT=AUTO FAL_SERVER=chicago . . .
プライマリ・データベースとスタンバイ・データベースでは、COMPATIBLE初期化パラメータを同じ値に設定する必要があります。値が異なる場合は、REDO転送サービスがREDOデータをプライマリ・データベースからスタンバイ・データベースに転送できない可能性があります。
SHOW PARAMETERSコマンドを使用して、他に変更を必要とするパラメータがないかどうかを確認することをお薦めします。
次の表に、例3-3に示したパラメータ設定のうち、プライマリ・データベースとは異なる設定に関する簡単な説明を示します。
| パラメータ | 推奨する設定 |
|---|---|
DB_UNIQUE_NAME |
このデータベースの一意の名前を指定します。この名前はデータベースと固定され、プライマリ・データベースとスタンバイ・データベースのロールが逆になっても変更されません。 |
CONTROL_FILES |
スタンバイ・データベースの制御ファイルのパス名を指定します。例3-3は2つの制御ファイルに対してこれを行う方法を示しています。制御ファイルの別のコピーを用意しておき、問題のない制御ファイルを問題のある制御ファイルの場所にコピーした後、容易にインスタンスを再開できるようにしておくことをお薦めします。 |
DB_FILE_NAME_CONVERT |
プライマリ・データベースのデータファイルのパス名とファイル名の位置を指定し、その後にスタンバイの位置を指定します。このパラメータにより、プライマリ・データベースのデータファイルのパス名がスタンバイ・データファイルのパス名に変換されます。スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、またはデータファイルが格納されているスタンバイ・サイトのディレクトリ構造がプライマリ・サイトと異なる場合は、このパラメータが必要です。 |
LOG_FILE_NAME_CONVERT |
プライマリ・データベースのオンラインREDOログ・ファイルの位置を指定し、その後にスタンバイの位置を指定します。このパラメータにより、プライマリ・データベースのログ・ファイルのパス名がスタンバイ・データベースのパス名に変換されます。スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、またはログ・ファイルが格納されているスタンバイ・システムのディレクトリ構造がプライマリ・システムと異なる場合は、このパラメータが必要です。 |
LOG_ARCHIVE_DEST_n |
REDOデータのアーカイブ先を指定します。例3-3では、次のようになっています。
注意: 高速リカバリ領域を( |
FAL_SERVER |
FALサーバー(通常はプライマリ・ロールで実行中のデータベース)のOracle Netサービス名を指定します。ボストンのデータベースがスタンバイ・ロールで実行されている場合、シカゴのデータベースが欠落しているログ・ファイルを自動的に送信できなければ、シカゴのデータベースがFALサーバーとして使用され、そこから欠落しているアーカイブREDOログ・ファイルがフェッチ(要求)されます。 |
|
注意: 変更が必要なその他のパラメータがないか、初期化パラメータ・ファイルを確認してください。たとえばスタンバイ・データベース上のディレクトリ場所がプライマリ・データベースでの指定と異なる場合は、ダンプ先パラメータを変更する必要があります。 |
オペレーティング・システムのコピー・ユーティリティを使用して、次のバイナリ・ファイルをプライマリ・システムからスタンバイ・システムにコピーします。
次の手順を実行して、Windowsベース・サービスの作成、パスワード・ファイルの作成、Oracle Net環境の設定およびSPFILEの作成を行います。
スタンバイ・データベースのホストがWindowsシステムである場合、ORADIMユーティリティを使用してWindowsサービスを作成します。次に例を示します。
WINNT> oradim –NEW –SID boston –STARTMODE manual
ORADIMユーティリティの使用の詳細は、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください。
プライマリ・データベースにリモート・ログイン・パスワード・ファイルがある場合は、そのファイルをフィジカル・スタンバイ・データベース・システムの適切なディレクトリにコピーします。パスワード・ファイルは、SYSDBA権限またはSYSOPER権限が付与または取り消されるか、これらの権限を持つユーザーのログイン・パスワードが変更されるたびに再コピーする必要があります。
この手順は、オペレーティング・システムの認証を管理ユーザーに使用する場合およびSSLをREDO転送の認証に使用する場合はオプションです。
プライマリ・サイトとスタンバイ・サイトの両方で、Oracle Net Managerを使用して、各データベースに対するリスナーを構成します。
リスナーを再起動して新しい定義を読み込むには、プライマリ・システムとスタンバイ・システムの両方で次のLSNRCTLユーティリティ・コマンドを入力します。
% lsnrctl stop % lsnrctl start
『Oracle Database Net Services管理者ガイド』を参照してください。
プライマリ・システムとスタンバイ・システムの両方で、Oracle Net Managerを使用して、プライマリ・データベースとスタンバイ・データベースのネットワーク・サービス名を作成します。ネットワーク・サービス名はREDO転送サービスで使用されます。
Oracle Netネット・サービス名は、プライマリ・データベースとスタンバイ・データベースに対するリスナーの構成時に指定したものと同じプロトコル、ホスト・アドレス、ポートおよびサービスを使用する接続記述子に解決される必要があります。この接続記述子は、専用サーバーが使用されるように指定する必要もあります。
『Oracle Database Net Services管理者ガイド』および『Oracle Database管理者ガイド』を参照してください。
アイドル状態のスタンバイ・データベースで、SQL CREATE文を使用して、手順2で編集したテキストの初期化パラメータ・ファイルから、スタンバイ・データベース用のサーバー・パラメータ・ファイルを作成します。次に例を示します。
SQL> CREATE SPFILE FROM PFILE='initboston.ora';
プライマリ・データベースにデータベース暗号化ウォレットがある場合は、スタンバイ・データベース・システムにコピーし、そのウォレットを使用するようにスタンバイ・データベースを構成します。
|
注意: データベース暗号化ウォレットは、マスター暗号化キーが更新されるたびに、プライマリ・データベース・システムから各スタンバイ・データベース・システムにコピーする必要があります。スタンバイ・データベースの暗号化されたデータには、プライマリ・データベースの現行のマスター暗号化キーを格納するデータベース暗号化ウォレットまたはハードウェア・セキュリティ・モジュールを指すように、スタンバイ・データベースが構成されるまでアクセスできません。 |
|
関連項目: データベース暗号化の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。 |
フィジカル・スタンバイ・データベースおよびREDO Applyを起動するには、次の手順を実行します。
スタンバイ・データベースで、次のSQL文を発行してデータベースを起動およびマウントします。
SQL> STARTUP MOUNT;
REDOデータをプライマリ・データベースから受信してアーカイブするように、6.2.3項で説明する手順を実行して、スタンバイ・データベースを準備します。
この手順はオプションですが、スタンバイ・データベースの作成時に、オンラインREDOログを作成することをお薦めします。このベスト・プラクティスに従うことで、スタンバイ・データベースは、プライマリ・データベース・ロールに速やかに推移できるようになります。
スタンバイ・データベースのオンラインREDOログにおけるREDOログ・グループのサイズおよび数は、スタンバイ・データベースがプライマリ・ロールに推移した場合に十分に機能するように選択する必要があります。
スタンバイ・データベースで、次のコマンドを発行してREDO Applyを開始します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE - > DISCONNECT FROM SESSION;
この文にはDISCONNECT FROM SESSIONオプションが指定されているため、REDO Applyはバックグラウンド・セッションで実行されます。詳細は、7.3項「REDOデータのフィジカル・スタンバイ・データベースへの適用」を参照してください。
また、この文にはUSING CURRENT LOGFILE句が指定されているため、REDOを受信後すぐに適用できます。詳細は、7.3.1項「REDO Applyの開始」を参照してください。
フィジカル・スタンバイ・データベースを作成してREDO転送サービスを設定した後、データベースの変更がプライマリ・データベースからスタンバイ・データベースに正常に転送されているかどうかの確認が必要な場合があります。
スタンバイ・データベースでREDOデータが受信されていることを確認するには、最初に、スタンバイ・データベースの既存のアーカイブREDOログ・ファイルを識別し、ログ・スイッチを強制実行して、プライマリ・データベースのオンラインREDOログ・ファイルをいくつかアーカイブし、スタンバイ・データベースを再度チェックする必要があります。このタスクの実行手順を次に示します。
スタンバイ・データベースでV$ARCHIVED_LOGビューを問い合せて、アーカイブREDOログの既存のファイルを識別します。次に例を示します。
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME -
> FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
SEQUENCE# FIRST_TIME NEXT_TIME
---------- ------------------ ------------------
8 11-JUL-07 17:50:45 11-JUL-07 17:50:53
9 11-JUL-07 17:50:53 11-JUL-07 17:50:58
10 11-JUL-07 17:50:58 11-JUL-07 17:51:03
3 rows selected.
プライマリ・データベースで、ALTER SYSTEM SWITCH LOGFILE文を発行して、ログ・スイッチを強制実行し、現行のオンラインREDOログ・ファイル・グループをアーカイブします。
SQL> ALTER SYSTEM SWITCH LOGFILE;
スタンバイ・データベースでV$ARCHIVED_LOGビューを問い合せて、スタンバイ・データベースでREDOデータが受信およびアーカイブされたことを確認します。
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME -
> FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
SEQUENCE# FIRST_TIME NEXT_TIME
---------- ------------------ ------------------
8 11-JUL-07 17:50:45 11-JUL-07 17:50:53
9 11-JUL-07 17:50:53 11-JUL-07 17:50:58
10 11-JUL-07 17:50:58 11-JUL-07 17:51:03
11 11-JUL-07 17:51:03 11-JUL-07 18:34:11
4 rows selected.
アーカイブREDOログ・ファイルは、フィジカル・スタンバイ・データベースに適用できます。
スタンバイ・データベースでV$ARCHIVED_LOGビューを問い合せて、受信したREDOが適用されたことを確認します。
SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG -
> ORDER BY SEQUENCE#;
SEQUENCE# APP
--------- ---
8 YES
9 YES
10 YES
11 IN-MEMORY
4行を選択しました。
|
注意: 最後に受信したログ・ファイルのAPPLIED列の値は、そのログ・ファイルが適用されている場合、IN-MEMORYまたはYESのいずれかです。 |
この時点で、フィジカル・スタンバイ・データベースが実行中であり、最大パフォーマンス・レベルのデータ保護を提供できます。次に、フィジカル・スタンバイ・データベースに対して実行できるその他の操作について説明します。
データ保護モードのアップグレード
Data Guard構成は、最初は最大パフォーマンス・モード(デフォルト)で設定されます。
フラッシュバック・データベースの有効化
フラッシュバック・データベースにより、フェイルオーバー後のプライマリ・データベースの再作成の必要がなくなります。フラッシュバック・データベースでは、データファイルをバックアップからリストアしたりREDOデータを広範囲に適用する必要がないため、従来のPoint-in-Timeリカバリよりもはるかに高速でデータベースを過去の最新時点の状態に戻すことができます。フラッシュバック・データベースは、プライマリ・データベースまたはスタンバイ・データベース、あるいはその両方で有効化できます。Data Guard環境でのフラッシュバック・データベースの使用例は、13.2項および13.3項を参照してください。データベースのフラッシュバックの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』も参照してください。
