7 REDO転送サービス
Oracle Data Guard構成では、Oracle REDO転送サービスを構成および監視する必要があります。
7.1 REDO転送サービスの概要
REDO転送サービスは、Oracle Data Guard構成のメンバー間でREDOデータの自動転送を実行します。
次のREDO転送先がサポートされています。
-
Oracle Data Guardスタンバイ・データベース
このガイドでは、フィジカル・スタンバイ・データベース、ロジカル・スタンバイ・データベースおよびスナップショット・スタンバイ・データベースの作成および管理方法について説明します。
-
アーカイブ・ログ・リポジトリ
この宛先タイプは、アーカイブREDOログ・ファイルの一時オフサイト記憶域に使用されます。アーカイブ・ログ・リポジトリは、Oracleデータベース・インスタンスとフィジカル・スタンバイ制御ファイルで構成されます。アーカイブ・ログ・リポジトリにはデータファイルが含まれないため、ロールの推移はサポートできません。
アーカイブ・ログ・リポジトリの作成に使用される手順は、データファイルのコピーを除いて、フィジカル・スタンバイ・データベースの作成に使用される手順と同じです。
-
Oracle Streamsダウンストリーム取得データベース
Oracle Streamsダウンストリーム・キャプチャ・データベースの詳細は、『Oracle Streams概要および管理』を参照してください。
-
遠隔同期インスタンス
遠隔同期インスタンスの詳細は、「遠隔同期」を参照してください。
-
Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)
各REDO転送先は、次の2つのREDO転送モードのいずれかによりREDOデータを受信するように、個別に構成されます。
-
同期
同期REDO転送モードは、REDOデータをトランザクション・コミットに対して同期させて転送します。トランザクションによって生成されたすべてのREDOが、同期REDO転送モードを使用する使用可能なREDO転送先すべてに正常に送信されるまで、そのトランザクションはコミットできません。
プライマリ・データベースと
SYNC
REDO転送先の間の距離に制限はありませんが、プライマリ・データベースとSYNC
REDO転送先の間のネットワーク待機時間が長くなるに従って、トランザクションのコミットの待機時間も長くなります。この転送モードは、最大保護および最大可用性の各データ保護モード(「Oracle Data Guardの保護モード」を参照)で使用されます。
注意:
同期REDO転送はZero Data Loss Recovery Applianceでサポートされていません。
-
非同期
非同期REDO転送モードは、REDOデータをトランザクション・コミットに対して非同期で転送します。トランザクションによって生成されたすべてのREDOが、非同期REDO転送モードを使用するREDO転送先すべてに正常に送信されるまで待機しなくても、そのトランザクションはコミットできます。
この転送モードは、最大パフォーマンス・データ保護モード(「Oracle Data Guardの保護モード」を参照)で使用されます。
7.2 REDO転送サービスの構成
REDOデータの送受信を行う前に、Oracleデータベースを構成する必要があります。構成プロセスの一環として、REDO転送のセキュリティを設定します。
次のトピックを参照してください。
これのトピックでは、次のトピックを十分に理解していることが求められます。
-
データベース管理者の認証
-
データベース初期化パラメータ
-
REDOログの管理
-
アーカイブREDOログの管理
-
高速リカバリ領域
-
Oracle Net構成
7.2.1 REDO転送のセキュリティ
REDO転送では、Oracle Netセッションを使用してREDOデータを転送します。
これらのREDO転送セッションは、Secure Sockets Layer(SSL)プロトコルまたはリモート・ログイン・パスワード・ファイルのいずれかを使用して認証されます。
7.2.1.1 SSLを使用したREDO転送の認証
Secure Sockets Layer(SSL)は、ネットワーク接続を保護するための業界標準プロトコルです。
SSLでは、RSA公開鍵暗号化および対称鍵暗号化を使用して、認証、暗号化およびデータ整合性を提供します。SSLは、次の場合に2つのOracleデータベース間のREDO転送の認証に自動的に使用されます。
-
データベースが同じOracle Internet Directory(OID)エンタープライズ・ドメインのメンバーであり、そのドメインが現行ユーザーのデータベース・リンクの使用を許可する場合
-
データベースに対応する
LOG_ARCHIVE_DEST_
n
およびFAL_SERVER
の各データベース初期化パラメータで、SSL用に構成されたOracle Net接続記述子を使用する場合 -
各データベースに、データベースのOIDエントリの識別名(DN)と一致するDNが付けられたユーザー証明書を格納するOracleウォレットまたはサポートされるハードウェア・セキュリティ・モジュールがある場合
関連項目:
-
SSLの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
-
エンタープライズ・ドメイン管理の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
-
Oracle Internet Directoryの管理方法の詳細は、『Oracle Label Security管理者ガイド』を参照してください。
7.2.1.2 パスワード・ファイルを使用したREDO転送の認証
SSL認証要件を満たしていない場合、各データベースはリモート・ログイン・パスワード・ファイルを使用する必要があります。
Oracle Data Guard構成では、すべてのフィジカルおよびスナップショット・スタンバイ・データベースはプライマリ・データベースからのパスワード・ファイルのコピーを使用する必要があります。管理権限(SYSDG
、SYSOPER
、SYSDBA
など)が付与または解除された場合、および管理権限を持つユーザーのパスワードが変更された場合は、コピーは自動的にリフレッシュされます。唯一の例外は、遠隔同期インスタンスです。遠隔同期インスタンスはREDOを受け取りますが、適用しないため、更新したパスワード・ファイルを引き続き手動で遠隔同期インスタンスにコピーする必要があります。遠隔同期インスタンスでパスワード・ファイルが更新されると、プライマリでのパスワードの更新を含むREDOは、遠隔同期インスタンスからREDOログを受け取るように設定されているすべてのスタンバイ・データベースに自動的に伝播されます。REDOが適用されると、スタンバイでパスワード・ファイルが更新されます。
REDO転送の認証にパスワード・ファイルを使用する場合、REDO転送の認証に使用されるユーザー・アカウントのパスワードは、REDO転送セッションを開始したデータベースとターゲット・データベース間で比較されます。REDO転送セッションを確立するには、パスワードが両方のデータベースで一致する必要があります。
デフォルトでは、パスワード・ファイルを使用する場合、SYS
ユーザーのパスワードがREDO転送セッションの認証に使用されます。REDO_TRANSPORT_USER
データベース初期化パラメータを使用して、SYSOPER
権限が付与されたユーザー名を設定すると、REDO転送の認証用に別のユーザー・パスワードを選択できます。管理しやすくするために、REDO_TRANSPORT_USER
パラメータをREDOソース・データベースおよび各REDO転送宛先で同じ値に設定することをお薦めします。
関連項目:
リモート・ログイン・パスワード・ファイルの作成とメンテナンスの詳細は、『Oracle Database管理者ガイド』を参照してください。
7.2.2 REDOデータを送信するためのOracleデータベースの構成
REDO転送先を指定するには、LOG_ARCHIVE_DEST_
n
データベース初期化パラメータを使用します(n
は1から31の整数)。
各LOG_ARCHIVE_DEST_
n
パラメータに対応するLOG_ARCHIVE_DEST_STATE_
n
データベース初期化パラメータ(n
は1から31の整数)があります。このパラメータを使用すると、対応するREDO転送先を有効または無効にできます。表7-1に、このパラメータに割り当てることができる有効な値を示します。
表7-1 LOG_ARCHIVE_DEST_STATE_n初期化パラメータの値
値 | 説明 |
---|---|
|
|
|
|
|
この宛先は、関連付けられている宛先への通信に障害が発生すると使用可能になる。 |
REDO転送先は、LOG_ARCHIVE_DEST_
n
パラメータを、1つ以上の属性を含む文字列に設定して構成します。この項では、最も一般的に使用される属性について簡単に説明します。すべてのLOG_ARCHIVE_DEST_
n
パラメータの属性の詳細は、「LOG_ARCHIVE_DEST_nパラメータの属性」を参照してください。
SERVICE
属性は、REDO転送先の必須属性で、属性リストの最初に指定する必要があります。SERVICE
属性は、REDO転送先への接続に使用されるOracle Netサービス名の指定に使用されます。サービス名は、Oracle Netネーミング・メソッドによって、REDO転送先のOracle Netリスナーと一致するOracle Net接続記述子に解決できる必要があります。この接続記述子は、REDO転送先のデフォルト接続タイプでないかぎり、専用サーバー接続を使用するように指定する必要があります。
関連項目:
Oracle Netサービス名、接続記述子、リスナー、ネットワーク・セキュリティの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
SYNC
属性は、同期REDO転送モードを使用してREDOデータをREDO転送先に送信するように指定します。
ASYNC
属性は、非同期REDO転送モードを使用してREDOデータをREDO転送先に送信するように指定します。非同期REDO転送モードは、SYNC
属性とASYNC
属性のどちらも指定されない場合に使用されます。
NET_TIMEOUT
属性は、LGWR
プロセスが、同期REDO転送モードを使用する転送先でREDOデータが正常に受信されたことの確認を待機する時間を指定するために使用します。確認がNET_TIMEOUT
の秒数内に受信されない場合は、REDO転送接続は終了し、エラーがログに記録されます。
同期REDO転送モードを使用する場合は常にNET_TIMEOUT
属性を指定して、REDO転送障害によるREDOソース・データベースの最大停止期間を厳密に制御できるようにすることをお薦めします。同期REDO転送モードのレスポンス時間の監視の詳細は、「同期REDO転送のレスポンス時間の監視」を参照してください。
注意:
すべての同期スタンバイ宛先に対してグローバルな、データベース初期化パラメータDATA_GUARD_SYNC_LATENCY
を設定することもできます。少なくとも1つの同期スタンバイがREDOの受信を確認した後、後続の宛先を切断するまで、プライマリ・データベースが待機できる最大時間(秒単位)を定義します。
たとえば、3つの同期スタンバイ宛先があり、DATA_GUARD_SYNC_LATENCY
の値を2に設定するとします。最初のスタンバイがREDOの受信をただちに確認した場合、プライマリ・データベースは他の2つのスタンバイが応答するのを2秒間待ちます。1つまたは両方が2秒以内に応答した場合、これらはアクティブな宛先として保持されます。時間内に応答しない宛先は失敗したものとしてマークされます。どちらの場合も、1つの同期スタンバイがREDOの受信を確認したため、プライマリはゼロ・データ損失保護モードのままになります。失敗した同期スタンバイは、REOPEN
属性に指定された秒数が経過した後、通常どおりに再接続されます。
AFFIRM
属性は、REDOソース・データベースから受信されたREDOが、スタンバイREDOログに書き込まれるまで確認されないように指定するために使用します。NOAFFIRM
属性は、受信されたREDOが、スタンバイREDOログに書き込まれるのを待機せずに確認されるように指定するために使用します。
DB_UNIQUE_NAME
属性は、REDO転送先のDB_UNIQUE_NAME
を指定するために使用します。DB_UNIQUE_NAME
属性は、LOG_ARCHIVE_CONFIG
データベース初期化パラメータが定義されていて、その値にDG_CONFIG
リストが指定されている場合に指定する必要があります。
DB_UNIQUE_NAME
属性を指定する場合、その値はDG_CONFIG
リスト内のDB_UNIQUE_NAME
値のいずれかと一致している必要があります。また、REDO転送先のDB_UNIQUE_NAME
データベース初期化パラメータの値とも一致している必要があります。いずれかが一致していない場合、エラーがログに記録され、その宛先にREDO転送を行うことはできません。
VALID_FOR
属性は、REDO転送サービスがREDOデータをREDO転送先に転送する時期を指定するために使用します。Oracle Data Guard構成内のすべてのサイトでREDO転送先ごとにVALID_FOR
属性を指定して、どのスタンバイ・データベースがプライマリ・ロールを担うかに関係なく、ロールの推移後もREDO転送サービスがすべてのスタンバイ・データベースに引き続きREDOデータを送信するようにすることをお薦めします。
REOPEN
属性は、前回のエラーにより非アクティブなREDO転送先への自動再接続試行の最低間隔(秒数)を指定するために使用します。
COMPRESSION
属性は、REDOデータを圧縮した形式でREDO転送先に転送するよう指定するために使用します。REDO転送を圧縮することにより、帯域幅が小さく待機時間が長いネットワーク・リンクにおいてREDO転送のパフォーマンスを大幅に向上できます。
REDO転送の圧縮は、Oracle Advanced Compressionオプションの機能です。REDO転送の圧縮機能を使用する前に、このオプションのライセンスを購入する必要があります。
次の例では、この項で説明したLOG_ARCHIVE_DEST_
n
の属性をすべて使用しています。DB_UNIQUE_NAME
は、圧縮の使用と同じく、両方の宛先に指定されています。REDO転送障害がいずれかの宛先で発生した場合、REDO転送はその宛先への再接続を試行しますが、60秒に1回より長い間隔で試行します。
DB_UNIQUE_NAME=BOSTON LOG_ARCHIVE_CONFIG='DG_CONFIG=(BOSTON,CHICAGO,HARTFORD)' LOG_ARCHIVE_DEST_2='SERVICE=CHICAGO ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILE, PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE DB_UNIQUE_NAME=CHICAGO' LOG_ARCHIVE_DEST_STATE_2='ENABLE' LOG_ARCHIVE_DEST_3='SERVICE=HARTFORD SYNC AFFIRM NET_TIMEOUT=30 VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE DB_UNIQUE_NAME=HARTFORD' LOG_ARCHIVE_DEST_STATE_3='ENABLE'
注意:
Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)の構成は、スタンバイ・データベースの構成と同じになります。前述の例では、ChicagoはASYNC
転送先であるため、スタンバイ・データベースとリカバリ・アプライアンスのいずれの可能性もあります。(同期REDO転送はRecovery Applianceでサポートされていません)
7.2.3 REDOデータを受信するためのOracleデータベースの構成
REDO転送先は、REDOソース・データベースからREDOデータを受信およびアーカイブするように構成する必要があります。
次の各項を参照してください。
7.2.3.1 スタンバイREDOログの管理
同期および非同期のREDO転送モードでは、REDO転送先にスタンバイREDOログが必要です。スタンバイREDOログは、別のOracleデータベースから受信されたREDOを格納するために使用します。スタンバイREDOログは、構造的にはREDOログと同じで、REDOログの作成および管理に使用するのと同じSQL文を使用して作成および管理します。
別のOracleデータベースからREDO転送を介して受信されたREDOは、リモート・ファイル・サーバー(RFS)フォアグラウンド・プロセスにより、現行のスタンバイREDOログ・グループに書き込まれます。REDOソース・データベースでログ・スイッチが発生すると、着信REDOは次のスタンバイREDOログ・グループに書き込まれ、前に使用されたスタンバイREDOログ・グループはARC
n
バックグラウンド・プロセスによってアーカイブされます。
REDOソース・データベースでREDOログ・ファイル・グループを順次いっぱいにしてアーカイブするプロセスは、スタンバイREDOログ・グループを順次いっぱいにしてアーカイブすることで、各REDO転送先でミラーリングされます。
各スタンバイREDOログ・ファイルは、少なくともREDOソース・データベースのREDOログで最も大きなREDOログ・ファイルと同じ大きさである必要があります。管理しやすくするために、REDOソース・データベースのREDOログの全REDOログ・ファイルとREDO転送先のスタンバイREDOログは同じサイズにすることをお薦めします。
スタンバイREDOログには、REDOソース・データベースのREDOスレッドごとに、REDOソース・データベースのREDOログより少なくとも1つ多いREDOログ・グループが必要です。REDOソース・データベースで、REDOソース・データベースのREDOログにいくつREDOログ・グループがあるかを確認するためにV$LOG
ビューに問合せを行い、REDOソース・データベースにいくつREDOスレッドが存在するかを確認するためにV$THREAD
ビューに問合せを行います。
REDOソース・データベースで次の問合せを実行し、REDOログの各ログ・ファイルのサイズおよびログ・グループ数を確認します。
SQL> SELECT GROUP#, BYTES FROM V$LOG;
REDO転送先データベースで次の問合せを実行し、スタンバイREDOログの各ログ・ファイルのサイズおよびログ・グループ数を確認します。
SQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG;
REDOソース・データベースがOracle Real Applications Cluster(Oracle RAC)またはOracle Real Application Clusters One Node (Oracle RAC One Node)データベースの場合、REDOソース・データベースのV$LOG
ビューに問合せを行い、いくつREDOスレッドが存在するかを確認し、スタンバイREDOログにREDOログ・グループを追加する際に、対応するスレッド数を指定します。
2つのREDOスレッドを持つREDOソース・データベースからREDOを受信するためのスタンバイREDOログをデータベースに作成するには、次のサンプルSQL文が使用されます。
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 500M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 500M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 500M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 500M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 500M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 500M;
注意:
REDOログ・グループをプライマリ・データベースに1つ追加するたびに、構成内の各スタンバイ・データベースのスタンバイREDOログにもログ・グループを1つ追加する必要があります。そうしないと、プライマリ・ログ・スイッチ後にスタンバイ・データベースが非同期化する可能性があり、その結果、一時的にデータ消失のないフェイルオーバーが機能しなくなったり、最大保護モードで稼働しているプライマリ・データベースが停止したりしかねません。
7.2.3.2 REDOがアーカイブREDOログ・ファイルに直接書き込まれる場合
スタンバイ・データベースにより受信されたREDOは、スタンバイREDOログ・グループが使用できない場合、またはREDOギャップを解決するためにREDOが送信された場合に、アーカイブREDOログ・ファイルに直接書き込まれます。これが行われた場合、別のデータベースから受信したアーカイブREDOについて有効なREDOはLOG_ARCHIVE_DEST_
n
パラメータのLOCATION
属性で指定された場所に書き込まれます。この目的で使用されるLOG_ARCHIVE_DEST_
n
パラメータは、スタンバイ・データベースのマウント時に決定され、LOG_ARCHIVE_DEST_
n
パラメータが修正されるたびに、再評価されます。
7.3 カスケードされたREDO転送先
カスケードされたREDO転送先(ターミナル宛先とも呼ばれる)では、プライマリ・データベースREDOを、プライマリ・データベースから直接にではなく、スタンバイ・データベースから間接的に受信します。
プライマリ・データベースREDOを1つ以上のカスケードされたターミナル宛先に、変更をそのローカル・データベース・ファイルに適用するのと同時にカスケードするフィジカル・スタンバイ・データベースは、カスケード・スタンバイ・データベースとして知られています。
カスケードにより、プライマリ・データベースからカスケード・スタンバイ・データベースへのREDO転送の実行に関連したオーバーヘッドが軽減されます。
カスケード・スタンバイ・データベースは、プライマリ・データベースREDOを最大30のターミナル宛先にカスケードできます。
カスケード・スタンバイ・データベースは、リアルタイムまたは非リアルタイムでREDOをカスケードできます。リアルタイムではREDOがスタンバイREDOログ・ファイルに書き込まれ、非リアルタイムではすべてのスタンバイREDOログ・ファイルがカスケード・スタンバイでアーカイブされます。
-
フィジカル・スタンバイ・データベースのみがREDOをカスケードできます。
-
リアルタイム・カスケードにはOracle Active Data Guardオプションのライセンスが必要です。
-
非リアルタイム・カスケードは宛先1から10まででのみサポートされます。(リアルタイム・カスケードはすべての宛先でサポートされます。)
注意:
Oracle Databaseアップグレード時のカスケードされたREDO転送先の処理方法の詳細は、Oracle Databaseソフトウェアをパッチ適用またはアップグレードする前の注意事項を参照してください。
また、次のトピックも参照してください:
7.3.1 ターミナル宛先の構成
この手順では、ターミナル宛先を構成する方法について説明します。
例7-1 REDOのカスケード時に使用される初期化パラメータの一部
プライマリ・データベース
DB_UNIQUE_NAME=boston FAL_SERVER=boston2 LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,boston2,denver)' LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2='SERVICE=boston2 SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston2'
カスケードしているフィジカル・スタンバイ・データベース
DB_UNIQUE_NAME=boston2 FAL_SERVER=boston LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(boston,boston2,denver)' LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston2' LOG_ARCHIVE_DEST_2= 'SERVICE=denver VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'
カスケードされたフィジカル・スタンバイ・データベース
DB_UNIQUE_NAME=denver FAL_SERVER=boston2 LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,boston2,denver)' LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=denver'
カスケード環境の設定後の構成の検証の詳細は、「構成の検証」を参照してください。
7.3.2 カスケードのシナリオ
Data Guard構成は、1つまたは複数のフィジカル・スタンバイにカスケードするように設定できます。
次のトピックを参照してください。
7.3.2.1 フィジカル・スタンバイへのカスケード
この手順では、1つのフィジカル・スタンバイ・データベースにカスケードする例を示します。
このシナリオでは、きわめて重要なプライマリ・データベースがあります。このデータベースにはパフォーマンスやデータ保護に厳しい要件があるため、ローカルのフィジカル・スタンバイ・データベースをデプロイして、データ消失のない保護と、プライマリ・データベースとローカル・スタンバイ・データベースのサイトで地域災害に備えるための、カスケードされたリモート・フィジカル・スタンバイ・データベースを準備することに決定しました。
次の手順を実行することで、前述の目的を達成できます。
- ローカル・サイトにフィジカル・スタンバイ・データベースを作成します。
- プライマリ・データベースとローカル・スタンバイ・データベースのサイトでの地域災害に対する保護策として、十分に遠く離れたサイトでフィジカル・スタンバイ・データベースを作成します。
- ローカル・スタンバイ・データベースを、プライマリ・データベースの
SYNC
REDO転送先として構成します。 - リモート・フィジカル・スタンバイ・データベースを、ローカル・スタンバイ・データベースのターミナル宛先として構成します。
7.3.2.2 複数のフィジカル・スタンバイへのカスケード
この手順では、複数のフィジカル・スタンバイ・データベースにカスケードする例を示します。
このシナリオでは、北アメリカにプライマリ・データベースがあり、読取り専用のレポート生成アプリケーションをサポートするために、ヨーロッパにこのデータベースのレプリカを3つデプロイしようと考えています。コストおよびパフォーマンス上の理由から、北アメリカからヨーロッパの各サイトへのネットワーク・リンクを維持しないつもりです。
次の手順を実行することで、前述の目的を達成できます。
- 北アメリカのサイトとヨーロッパのサイトの1つとの間にネットワーク・リンクを作成します。
- ヨーロッパの各サイトにフィジカル・スタンバイ・データベースを作成します。
- 「フィジカル・スタンバイ・データベースのオープン」で説明しているように、フィジカル・スタンバイ・データベースをリアルタイム問合せモードでオープンします。
- 欧米間のネットワーク・リンクのヨーロッパ側の終点にあるフィジカル・スタンバイ・データベースを、他のヨーロッパのスタンバイ・データベースにREDOをカスケードするように構成します。
- その他の2つのフィジカル・スタンバイ・データベースを、手順4で構成したカスケード・スタンバイ・データベースのターミナル宛先として構成します。
7.4 カスケード・スタンバイでのデータ保護の考慮点
構成にカスケード・スタンバイが含まれる場合、各宛先には、フェイルオーバー中に使用するそのソースを指すように定義されたLOG_ARCHIVE_DEST_
n
パラメータが含まれる必要があります。
リアルタイム・カスケードでは、カスケード・スタンバイ・データベースが、非同期REDO転送を使用してプライマリ・データベースからREDOを直接受信するスタンバイ・データベースとほぼ同じレベルのデータ保護を提供できます。しかし、REDOはリアルタイムで転送されますが、停止によりすべてのREDOがターミナル宛先に到達できなくなると、2つ目のネットワーク・ホップが存在する事実により、さらなるデータ消失の可能性が生じます。
7.5 構成の検証
Oracle Data Guard構成を作成後に検証するには、構成内の任意のデータベースからV$DATAGUARD_CONFIG
ビューを問い合せます。
ビューには、DB_UNIQUE_NAME
およびLOG_ARCHIVE_CONFIG
初期化パラメータで定義された一意のデータベース名が表示されます。
関連項目:
-
V$DATAGUARD_CONFIG
ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
7.6 REDO転送サービスの監視
REDO転送ステータスとともに、REDO転送のレスポンス時間を監視できます。
次のトピックを参照してください。
7.6.1 REDO転送ステータスの監視
REDOソース・データベースでREDO転送ステータスを監視するためにビューを問い合せることができます。
次の手順を実行して、REDOソース・データベースでREDO転送ステータスを監視します。
7.6.2 同期REDO転送のレスポンス時間の監視
V$REDO_DEST_RESP_HISTOGRAM
ビューには、REDO転送先ごとのレスポンス時間データが格納されます。
レスポンス時間データは、同期REDO転送モードにより送信されたREDO転送メッセージに関して保持されます。
宛先ごとのデータは一連の行で構成されており、各レスポンス時間に1行ずつ割り当てられています。レコードの保存を簡素化するために、300秒未満の場合、レスポンス時間は最も近い整数の秒数に切り上げられます。300秒超のレスポンス時間は、600、1200、2400、4800または9600秒にそれぞれ切り上げられます。
各行は、4つ列FREQUENCY
、DURATION
、DEST_ID
およびTIME
で構成されます。
FREQUENCY
列には、特定のレスポンス時間が監視された回数が格納されます。DURATION
列は、レスポンス時間に相当します。DEST_ID
列は、宛先を特定します。TIME
列には、その行が最後に更新されたときに取得されたタイムスタンプが格納されます。
このビューのレスポンス時間データは、REDOソース・データベースでのトランザクション・スループットに影響を与える可能性がある同期REDO転送モードのパフォーマンスの問題を特定するのに役立ちます。NET_TIMEOUT
属性のチューニングにも有効です。
次の3つの例では、LOG_ARCHIVE_DEST_2
パラメータに対応する宛先2への問合せのサンプルを示します。別の宛先についてレスポンス時間データを表示するには、問合せのDEST_ID
を変更するだけです。
REDOソース・データベースで次の問合せを実行すると、宛先2についてレスポンス時間のヒストグラムを表示できます。
SQL> SELECT FREQUENCY, DURATION FROM - > V$REDO_DEST_RESP_HISTOGRAM WHERE DEST_ID=2 AND FREQUENCY>1;
REDOソース・データベースで次の問合せを実行すると、宛先2について最も遅いレスポンス時間を表示できます。
SQL> SELECT max(DURATION) FROM V$REDO_DEST_RESP_HISTOGRAM - > WHERE DEST_ID=2 AND FREQUENCY>1;
REDOソース・データベースで次の問合せを実行すると、宛先2について最も速いレスポンス時間を表示できます。
SQL> SELECT min( DURATION) FROM V$REDO_DEST_RESP_HISTOGRAM - > WHERE DEST_ID=2 AND FREQUENCY>1;
注意:
REDO転送先がNET_TIMEOUT
の秒数内にREDO転送メッセージに応答しない場合、同期REDO転送モードのセッションが終了するため、宛先について最も頻繁に監視されるレスポンス時間は、その宛先に指定されたNET_TIMEOUT
値の最高値を超えることはできません。
7.6.3 REDOギャップの検出および解決
REDOギャップは、REDO転送が中断されるたびに発生します。
REDO転送が再開されると、REDO転送サービスはREDOギャップを自動的に検出し、欠落したREDOを宛先に送信して解決します。
REDOギャップの解決に必要な時間は、ギャップのサイズに正比例し、REDOソース・データベースとREDO転送先との間のネットワーク・リンクの実効スループットに反比例します。REDO転送サービスには、パフォーマンスが低いネットワーク・リンクを使用している場合にREDOギャップの解決時間を短縮するオプションが2つあります。
-
REDO転送の圧縮
LOG_ARCHIVE_DEST_
n
パラメータのCOMPRESSION
属性を使用して、宛先に送信する前にREDOデータを圧縮するように指定します。 -
パラレルREDO転送ネットワーク・セッション
LOG_ARCHIVE_DEST_
n
パラメータのMAX_CONNECTIONS
属性を使用すると、複数のネットワーク・セッションを使用して、REDOギャップを解決するために必要なREDOを送信するように指定できます。
COMPRESSION
属性とMAX_CONNECTIONS
属性の詳細は、「LOG_ARCHIVE_DEST_nパラメータの属性」を参照してください。
7.6.3.1 手動によるギャップの解決
場合によっては、ギャップの解決を自動的に実行できず、手動による実行が必要になります。
たとえば、プライマリ・データベースが使用できない場合には、ロジカル・スタンバイ・データベースでREDOギャップの解決を手動で実行する必要があります。
フィジカル・スタンバイ・データベースで次の問合せを実行し、REDOギャップがフィジカル・スタンバイ・データベースに存在するかどうかを判断します。
SQL> SELECT * FROM V$ARCHIVE_GAP; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ----------- ------------- -------------- 1 7 10
この例の出力は、フィジカル・スタンバイ・データベースでスレッド1の順序番号7から10のログ・ファイルが現在欠落していることを示しています。
プライマリ・データベースで次の問合せを実行し、プライマリ・データベースでのアーカイブREDOログ・ファイルの位置を特定します(プライマリ・データベースのローカル・アーカイブ先はLOG_ARCHIVE_DEST_1
とします)。
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND - > DEST_ID=1 AND SEQUENCE# BETWEEN 7 AND 10; NAME -------------------------------------------------------------------------------- /primary/thread1_dest/arcr_1_7.arc /primary/thread1_dest/arcr_1_8.arc /primary/thread1_dest/arcr_1_9.arc
注意:
この問合せは、特定のスレッドについて連続する順序番号を戻します。その場合、実際のギャップはありませんが、関連するスレッドは、これらの2つのアーカイブ・ログの生成期間内に無効および有効に設定されました。また、この問合せは、特定のスレッドの最後に存在するギャップを識別しません。たとえば、プライマリ・データベースでスレッド1に対して順序番号100までアーカイブ・ログが生成され、ロジカル・スタンバイ・データベースがそのスレッドについて受信した最後のアーカイブ・ログが順序番号77である場合、この問合せは、順序番号78から100のアーカイブ・ログについてギャップがあるにもかかわらず、1行も返しません。
これらのログ・ファイルをフィジカル・スタンバイ・データベースにコピーし、コピーしたログをALTER DATABASE REGISTER LOGFILE
を使用して登録します。次に例を示します。
SQL> ALTER DATABASE REGISTER LOGFILE - > '/physical_standby1/thread1_dest/arcr_1_7.arc'; SQL> ALTER DATABASE REGISTER LOGFILE - > '/physical_standby1/thread1_dest/arcr_1_8.arc'; SQL> ALTER DATABASE REGISTER LOGFILE - > '/physical_standby1/thread1_dest/arcr_1_9.arc';
注意:
フィジカル・スタンバイ・データベースのV$ARCHIVE_GAP
ビューが戻すのは、REDO Applyの続行を現在ブロックしているギャップのみです。そのギャップを解決した後、フィジカル・スタンバイ・データベースでV$ARCHIVE_GAP
ビューを再度問い合せ、別のギャップ順序が存在するかどうかを判断します。この処理をギャップがなくなるまで繰り返します。
REDOギャップがロジカル・スタンバイ・データベースに存在するかどうかを判断するには、ロジカル・スタンバイ・データベースでDBA_LOGSTDBY_LOG
ビューを問い合せます。たとえば、次の問合せでは、ロジカル・スタンバイ・データベースのTHREAD 1
に2つのファイルが表示されているため、アーカイブREDOログ・ファイルの順序番号にギャップがあることを示しています。(ギャップがない場合、問合せで表示されるのは、スレッドごとに1つのファイルのみです。)この出力は、登録されたファイルの最大の順序番号は10ですが、順序番号6で示されるファイルにギャップがあることを示しています。
SQL> COLUMN FILE_NAME FORMAT a55 SQL> SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L - > WHERE NEXT_CHANGE# NOT IN - > (SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#) - > ORDER BY THREAD#, SEQUENCE#; THREAD# SEQUENCE# FILE_NAME ---------- ---------- ----------------------------------------------- 1 6 /disk1/oracle/dbs/log-1292880008_6.arc 1 10 /disk1/oracle/dbs/log-1292880008_10.arc
順序番号7、8および9の欠落しているログ・ファイルをロジカル・スタンバイ・システムにコピーし、コピーしたログをALTER DATABASE REGISTER LOGICAL LOGFILE
文を使用して登録します。次に例を示します。
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE - > '/disk1/oracle/dbs/log-1292880008_7.arc'; SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE - > '/disk1/oracle/dbs/log-1292880008_8.arc'; SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE - > '/disk1/oracle/dbs/log-1292880008_9.arc';
注意:
ここで指定した、ロジカル・スタンバイ・データベースのDBA_LOGSTDBY_LOG
ビューに基づいた問合せが戻すのは、SQL Applyの続行を現在ブロックしているギャップのみです。そのギャップを解決した後、ロジカル・スタンバイ・データベースでDBA_LOGSTDBY_LOG
ビューを再度問い合せ、別のギャップ順序が存在するかどうかを判断します。この処理をギャップがなくなるまで繰り返します。
7.6.4 REDO転送サービスの待機イベント
Oracle待機イベントを使用して、REDOソース・データベース上のREDO転送待機時間を追跡できます。
表7-2には、これらのOracle待機イベントをいくつかリストします。それらは、V$SYSTEM_EVENT
動的パフォーマンス・ビュー内にあります。
REDO転送で使用されるOracle待機イベントの詳細リストは、次の場所からOracle Maximum Availability Architecture(MAA)のホームページにアクセスし、『Oracle Data Guard Redo Transport and Network Best Practices』ホワイト・ペーパーを参照してください。
表7-2 REDO転送の待機イベント
待機イベント | 説明 |
---|---|
LNS wait on ATTACH |
すべての |
LNS wait on SENDREQ |
すべての |
LNS wait on DETACH |
すべての |