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転送先すべてに正常に送信されるまで、そのトランザクションはコミットできません。
プライマリ・データベースと
SYNCREDO転送先の間の距離に制限はありませんが、プライマリ・データベースとSYNCREDO転送先の間のネットワーク待機時間が長くなるに従って、トランザクションのコミットの待機時間も長くなります。この転送モードは、最大保護および最大可用性の各データ保護モード(「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構成では、すべてのフィジカルおよびスナップショット・スタンバイ・データベースはプライマリ・データベースからのパスワード・ファイルのコピーを使用する必要があります。ソース・データベースとターゲット・データベースの両方でデータベースの互換性が12.2以降に設定されている場合は、管理権限(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ログ・グループはARCnバックグラウンド・プロセスによってアーカイブされます。
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.2.3.3 アーカイブREDOログ・ファイルの場所
特定の基準により、リモート・ファイル・サーバー(RFS)がアーカイブREDOログ・ファイルを作成する場所が定義されます。
-
ローカル・ログ・アーカイブ先が構成されていない場合は、次のようになります。:
-
Oracle Managed Files (OMF)を使用すると、アーカイブREDOログ・ファイルは高速リカバリ領域に保存されます。
-
OMFを使用しないと、アーカイブREDOログファイルは
/dbs/archディレクトリに保存されます。
-
-
ローカル・ログ・アーカイブ先が1つ以上定義されている場合、アーカイブREDOログ・ファイルは、SRLおよび現在のロールに対して有効な最初の(最下位の)有効なアクティブ・ログ・アーカイブ先に保存されます。
-
ローカル・ログ・アーカイブ先が1つ以上定義されていても、アーカイブ先が有効でもアクティブでもない場合、アーカイブREDOログ・ファイルは
/dbs/archディレクトリに保存されます。
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つのフィジカル・スタンバイ・データベースにカスケードする例を示します。
このシナリオでは、きわめて重要なプライマリ・データベースがあります。このデータベースにはパフォーマンスやデータ保護に厳しい要件があるため、ローカルのフィジカル・スタンバイ・データベースをデプロイして、データ消失のない保護と、プライマリ・データベースとローカル・スタンバイ・データベースのサイトで地域災害に備えるための、カスケードされたリモート・フィジカル・スタンバイ・データベースを準備することに決定しました。
次のステップを実行することで、前述の目的を達成できます。
- ローカル・サイトにフィジカル・スタンバイ・データベースを作成します。
- プライマリ・データベースとローカル・スタンバイ・データベースのサイトでの地域災害に対する保護策として、十分に遠く離れたサイトでフィジカル・スタンバイ・データベースを作成します。
- ローカル・スタンバイ・データベースを、プライマリ・データベースの
SYNCREDO転送先として構成します。 - リモート・フィジカル・スタンバイ・データベースを、ローカル・スタンバイ・データベースのターミナル宛先として構成します。
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を送信するように指定できます。(MAX_CONNECTIONSパラメータは、Oracle Databaseリリース18cから非推奨となっており、下位互換性のためにのみ残されています。)
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 |
すべての |