| Oracle® Data Guard概要および管理 11gリリース2 (11.2) B56302-06 |
|
 前 |
 次 |
この章では、Oracle REDO転送サービスを構成および監視する方法について説明します。次の項目で構成されています。
REDO転送サービスは、Oracleデータベース間でREDOデータの自動転送を実行します。次のREDO転送先がサポートされています。
Oracle Data Guardスタンバイ・データベース
このマニュアルでは、スタンバイ・データベースを作成および管理する方法について説明します。
アーカイブ・ログ・リポジトリ
この宛先タイプは、アーカイブREDOログ・ファイルの一時オフサイト記憶域に使用されます。アーカイブ・ログ・リポジトリは、Oracleデータベース・インスタンスとフィジカル・スタンバイ制御ファイルで構成されます。アーカイブ・ログ・リポジトリにはデータファイルが含まれないため、ロールの推移はサポートできません。
アーカイブ・ログ・リポジトリの作成に使用される手順は、データファイルのコピーを除いて、フィジカル・スタンバイ・データベースの作成に使用される手順と同じです。
Oracle Streamsダウンストリーム取得データベース
Oracle Streamsダウンストリーム・キャプチャ・データベースの詳細は、『Oracle Streams概要および管理』を参照してください。
Oracle Change Data Captureステージング・データベース
Oracle Change Data Captureステージング・データベースの詳細は、Oracle Warehouse Builderソースおよびターゲット・ガイドを参照してください。
Oracleデータベースでは、REDOデータを最大30個のREDO転送先に送信できます。各REDO転送先は、次の2つのREDO転送モードのいずれかによりREDOデータを受信するように、個別に構成されます。
同期
同期REDO転送モードは、REDOデータをトランザクション・コミットに対して同期させて転送します。トランザクションによって生成されたすべてのREDOが、同期REDO転送モードを使用する使用可能なREDO転送先すべてに正常に送信されるまで、そのトランザクションはコミットできません。
プライマリ・データベースとSYNC REDO転送先の間の距離に制限はありませんが、プライマリ・データベースとSYNC REDO転送先の間のネットワーク待機時間が長くなるに従って、トランザクションのコミットの待機時間も長くなります。
この転送モードは、最大保護および最大可用性の各データ保護モード(第5章「Data Guardの保護モード」を参照)で使用されます。
非同期
非同期REDO転送モードは、REDOデータをトランザクション・コミットに対して非同期で転送します。トランザクションによって生成されたすべてのREDOが、非同期REDO転送モードを使用するREDO転送先すべてに正常に送信されるまで待機しなくても、そのトランザクションはコミットできます。
この転送モードは、最大パフォーマンス・データ保護モード(第5章「Data Guardの保護モード」を参照)で使用されます。
この項では、REDO転送サービスの構成方法について説明します。次の項目で構成されています。
この項での詳細な説明内容は、読者が『Oracle Database管理者ガイド』、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』、およびOracle Database Net Services管理者ガイド』で説明している次の内容を十分理解していることが前提になっています。
データベース管理者の認証
データベース初期化パラメータ
REDOログの管理
アーカイブREDOログの管理
高速リカバリ領域
Oracle Net構成
REDO転送では、Oracle Netセッションを使用してREDOデータを転送します。これらのREDO転送セッションは、Secure Sockets Layer(SSL)プロトコルまたはリモート・ログイン・パスワード・ファイルのいずれかを使用して認証されます。
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認証要件を満たしていない場合、各データベースはリモート・ログイン・パスワード・ファイルを使用する必要があります。Data Guard構成では、すべてのフィジカルおよびスナップショット・スタンバイ・データベースはプライマリ・データベースからパスワード・ファイルのコピーを使用する必要があり、SYSOPERまたはSYSDBA権限を付与または解除されるたびに、あるいはこれらの権限を持つユーザーのパスワード変更後、このコピーのリフレッシュが必要です。
REDO転送の認証にパスワード・ファイルを使用する場合、REDO転送の認証に使用されるユーザー・アカウントのパスワードは、REDO転送セッションを開始したデータベースとターゲット・データベース間で比較されます。REDO転送セッションを確立するには、パスワードが両方のデータベースで一致する必要があります。
デフォルトでは、パスワード・ファイルを使用する場合、SYSユーザーのパスワードがREDO転送セッションの認証に使用されます。REDO_TRANSPORT_USERデータベース初期化パラメータを使用して、SYSOPER権限が付与されたユーザー名を設定すると、REDO転送の認証用に別のユーザー・パスワードを選択できます。管理しやすくするために、REDO_TRANSPORT_USERパラメータをREDOソース・データベースおよび各REDO転送宛先で同じ値に設定することをお薦めします。
|
関連項目: リモート・ログイン・パスワード・ファイルの作成とメンテナンスの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
この項では、REDOデータをREDO転送先に送信するようにOracleデータベースを構成する方法について説明します。
LOG_ARCHIVE_DEST_nデータベース初期化パラメータ(nは1から31の整数)を使用して、ローカルのアーカイブREDOログの位置を指定するか、REDO転送先を指定します。この項では、このパラメータの後者の使用について説明します。
各LOG_ARCHIVE_DEST_nパラメータに対応するLOG_ARCHIVE_DEST_STATE_nデータベース初期化パラメータ(nは1から31の整数)があります。このパラメータを使用すると、対応するREDO転送先を有効または無効にできます。表6-1に、このパラメータに割り当てることができる有効な値を示します。
REDO転送先は、LOG_ARCHIVE_DEST_nパラメータを、1つ以上の属性を含む文字列に設定して構成します。この項では、最も一般的に使用される属性について簡単に説明します。すべてのLOG_ARCHIVE_DEST_nパラメータの属性の詳細は、第15章を参照してください。
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転送モードのレスポンス時間の監視の詳細は、6.4.2項を参照してください。
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転送先に転送する時期を指定するために使用します。Data Gurad構成内のすべてのサイトで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'
この項では、REDOソース・データベースからREDOデータを受信およびアーカイブするように、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ログは、Data Guard構成のプライマリ・データベースに作成して、スタンバイ・ロールへのスイッチオーバー後すぐにREDOデータを受信できるようにすることをお薦めします。
ALTER DATABASE ADD STANDBY LOGFILE SQL文を使用して、スタンバイREDOログを作成し、スタンバイREDOログ・グループを既存のスタンバイREDOログに追加します。
たとえば、REDOソース・データベースのREDOログに2つのREDOログ・グループがあり、各グループには500MBのREDOログ・ファイルが1つずつ含まれているとします。この場合、REDOソース・データベースのREDOログよりREDOログ・グループが少なくとも1つ多く必要であるという要件を満たすため、スタンバイREDOログには、3つ以上のスタンバイREDOログ・グループが必要です。
次のSQL文を使用すると、この使用例に適したスタンバイREDOログを作成できます。
SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog1.rdo') SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog2.rdo') SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog3.rdo') SIZE 500M;
REDOソース・データベースがOracle Real Applications Cluster(Oracle RAC)またはOracle 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つ追加する必要があります。そうしないと、プライマリ・ログ・スイッチ後にスタンバイ・データベースが非同期化する可能性があり、その結果、一時的にデータ消失のないフェイルオーバーが機能しなくなったり、最大保護モードで稼働しているプライマリ・データベースが停止したりしかねません。 |
この項では、スタンバイREDOログ・アーカイブの構成方法について説明します。
|
関連項目:
|
アーカイブが有効になっていない場合は、次の文を発行してデータベースをARCHIVELOGモードにし、自動アーカイブを有効にします。
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> ALTER DATABASE ARCHIVELOG;
スタンバイREDOログ・アーカイブを実行するには、データベースはARCHIVELOGモードである必要があります。
次の手順を実行して、スタンバイREDOログ・アーカイブを高速リカバリ領域に設定します。
LOG_ARCHIVE_DEST_nパラメータのLOCATION属性をUSE_DB_RECOVERY_FILE_DESTに設定します。
同じLOG_ARCHIVE_DEST_nパラメータのVALID_FOR属性をスタンバイREDOログ・アーカイブを許可する値に設定します。
次に、スタンバイREDOログを高速リカバリ領域にアーカイブするようにフィジカル・スタンバイ・データベースを構成するために使用されるパラメータ値のサンプルをいくつか示します。
LOG_ARCHIVE_DEST_2 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE)' LOG_ARCHIVE_DEST_STATE_2=ENABLE
アーカイブREDOログ・ファイルの管理が簡素化されるため、高速リカバリ領域の使用をお薦めします。
次の手順を実行して、スタンバイREDOログ・アーカイブをローカル・ファイル・システムの場所に設定します。
LOG_ARCHIVE_DEST_nパラメータのLOCATION属性を有効なパス名に設定します。
同じLOG_ARCHIVE_DEST_nパラメータのVALID_FOR属性をスタンバイREDOログ・アーカイブを許可する値に設定します。
次に、スタンバイREDOログをローカル・ファイル・システムの場所にアーカイブするようにフィジカル・スタンバイ・データベースを構成するために使用されるパラメータ値のサンプルをいくつか示します。
LOG_ARCHIVE_DEST_2 = 'LOCATION = /disk2/archive VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE)' LOG_ARCHIVE_DEST_STATE_2=ENABLE
スタンバイ・データベースにより受信されたREDOは、スタンバイREDOログ・グループが使用できない場合、またはREDOギャップを解決するためにREDOが送信された場合に、アーカイブREDOログ・ファイルに直接書き込まれます。これが行われた場合、別のデータベースから受信したアーカイブREDOについて有効なREDOはLOG_ARCHIVE_DEST_nパラメータのLOCATION属性で指定された場所に書き込まれます。この目的で使用されるLOG_ARCHIVE_DEST_nパラメータは、スタンバイ・データベースのマウント時に決定され、LOG_ARCHIVE_DEST_nパラメータが修正されるたびに、再評価されます。
|
注意: この項で説明しているOracle Data GuardのカスケードREDO転送宛先機能を使用するには、Oracle Database 11gリリース2(11.2.0.2)以上を使用する必要があります。11.2.0.2以前のリリースではこの機能に対する制約がいくつかあります。11.2.0.2以上にはこの種の制約はありません。 |
カスケードされたREDO転送先では、プライマリ・データベースREDOを、プライマリ・データベースから直接にではなく、スタンバイ・データベースから間接的に受信します。
プライマリ・データベースREDOを1つ以上のカスケードされた転送先にカスケードするスタンバイ・データベースは、カスケード・スタンバイ・データベースとして知られています。
カスケードにより、プライマリ・データベースからカスケード・スタンバイ・データベースへのREDO転送の実行に関連したオーバーヘッドが軽減されます。
カスケード・スタンバイ・データベースは、最高30か所のカスケードされた宛先(フィジカル、ロジカル、またはスナップショット・スタンバイ・データベース)まで、プライマリ・データベースのREDOをカスケードできます。
プライマリ・データベースのREDOは、スタンバイ・データベースでの受信と同時にスタンバイREDOログに書込まれます。ただしREDOはすぐにカスケードされません。書込み先のスタンバイREDOログ・ファイルがローカルにアーカイブ保存された後でカスケードされます。したがってプライマリ・データベースについては、カスケード・スタンバイ・データベースよりもカスケード先のほうが常にREDO転送ラグが大きくなります。
フィジカル・スタンバイ・データベースは、REDOをカスケードできる唯一のスタンバイ・データベースのタイプ
Data Guard Brokerではカスケードされた宛先をサポートしない
この項の残りの部分には、次の情報が記載されています。
カスケードされた宛先を構成するには、次の手順を実行します。
カスケード・スタンバイ・データベースとして構成するフィジカル・スタンバイ・データベースを選択します。
カスケード・スタンバイ・データベースで、FAL_SERVER属性をプライマリ・データベース、またはプライマリ・データベースからREDOを直接受信するスタンバイ・データベースのOracle Net別名を指定して構成します。
カスケード・スタンバイ・データベースで、カスケードされた宛先のLOG_ARCHIVE_DEST_nデータベース初期化パラメータを構成します。この宛先のSERVICE属性にカスケードされた宛先のOracle Net別名を指定し、スタンバイ・ロールである間にスタンバイREDOログのアーカイブが有効になるようにVALID属性を構成します。
SYNCまたはASYNC REDO転送属性が指定されている場合、それらは無視されます。
カスケードされた宛先では、FAL_SERVERデータベース初期化パラメータに、カスケード・スタンバイ・データベース、またはプライマリ・データベースに直接接続されている別のスタンバイ・データベースのOracle Net別名を指定して構成します。プライマリ・データベースを指定することも可能ですが、そうするとプライマリ・データベースでのREDO転送オーバーヘッドを減らすというカスケードの目的が果たせなくなります。
例6-1は、bostonというプライマリ・データベースがREDOをboston2というローカル・フィジカル・スタンバイ・データベースに送信し、そこからプライマリ・データベースREDOがdenverというリモート・フィジカル・スタンバイ・データベースにカスケードされるというData Guard構成のメンバーによって使用されるいくつかのデータベース初期化パラメータを示しています。
LOG_ARCHIVE_DEST_nデータベース初期化パラメータは、データベースbostonがスタンバイ・ロールのときに、データベースdenverに対するスタンバイREDOログ・アーカイブとして有効なデータベースbostonでも構成できることに注意してください。これにより、データベースbostonとデータベースboston2の間でスイッチオーバーが実行された場合でも、データベースdenverへのREDOカスケードが続行可能になります。
例6-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'
障害時リカバリを主目的とするスタンバイ・データベースでは、REDOデータをプライマリ・データベースから直接受信することをお薦めします。これは、最高レベルのデータ保護となります。カスケードされたスタンバイ・データベースは、第2防御ラインとして利用できますが、本質的にREDOをプライマリから直接受信するスタンバイ・データベースより、受信するプライマリ・データベースREDOの数が常に少なくなります。
この項では、2つの典型的なカスケードのシナリオについて説明します。
このシナリオでは、きわめて重要なプライマリ・データベースがあります。このデータベースにはパフォーマンスやデータ保護に厳しい要件があるため、ローカルのフィジカル・スタンバイ・データベースをデプロイして、データ消失のない保護と、プライマリ・データベースとローカル・スタンバイ・データベースのサイトで地域災害に備えるための、カスケードされたリモート・フィジカル・スタンバイ・データベースを準備することに決定しました。
次の手順を実行することで、前述の目的を達成できます。
ローカル・サイトにフィジカル・スタンバイ・データベースを作成します。
プライマリ・データベースとローカル・スタンバイ・データベースのサイトでの地域災害に対する保護策として、十分に遠く離れたサイトでフィジカル・スタンバイ・データベースを作成します。
ローカル・スタンバイ・データベースを、プライマリ・データベースのSYNC REDO転送先として構成します。
リモート・フィジカル・スタンバイ・データベースを、ローカル・スタンバイ・データベースのカスケードされた宛先として構成します。
このシナリオでは、北アメリカにプライマリ・データベースがあり、読取り専用のレポート生成アプリケーションをサポートするために、ヨーロッパにこのデータベースのレプリカを3つデプロイしようと考えています。コストおよびパフォーマンス上の理由から、北アメリカからヨーロッパの各サイトへのネットワーク・リンクを維持しないつもりです。
次の手順を実行することで、前述の目的を達成できます。
北アメリカのサイトとヨーロッパのサイトの1つとの間にネットワーク・リンクを作成します。
ヨーロッパの各サイトにフィジカル・スタンバイ・データベースを作成します。
9.2項で説明しているように、フィジカル・スタンバイ・データベースをリアルタイム問合せモードでオープンします。
欧米間のネットワーク・リンクのヨーロッパ側の終点にあるフィジカル・スタンバイ・データベースを、他のヨーロッパのスタンバイ・データベースにREDOをカスケードするように構成します。
欧米間のネットワーク・リンクのヨーロッパ側の終点にあるフィジカル・スタンバイ・データベースを、プライマリ・データベースのカスケードされた宛先として構成します。
この項は、次の項目で構成されています。
この項では、REDOソース・データベースでREDO転送ステータスを監視するのに使用する手順について説明します。
REDOソース・データベースで次の問合せを実行し、各スレッドの最新のアーカイブ順序番号を判定します。
SQL> SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG - > WHERE RESETLOGS_CHANGE# = (SELECT MAX(RESETLOGS_CHANGE#) FROM V$ARCHIVED_LOG) - > GROUP BY THREAD#;
REDOソース・データベースで次の問合せを実行し、各REDO転送先の最新のアーカイブREDOログ・ファイルを判定します。
SQL> SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ# - > FROM V$ARCHIVE_DEST_STATUS - > WHERE STATUS <> 'DEFERRED' AND STATUS <> 'INACTIVE'; DESTINATION STATUS ARCHIVED_THREAD# ARCHIVED_SEQ# ------------------ ------ ---------------- ------------- /private1/prmy/lad VALID 1 947 standby1 VALID 1 947
最新のアーカイブREDOログ・ファイルは、各宛先で同じである必要があります。同じでない場合、その宛先へのアーカイブ操作の間に検出されたエラーはVALID以外のステータスで表示されます。
REDOソース・データベースで問合せを実行すると、アーカイブREDOログ・ファイルが特定のREDO転送先で受信されたかどうかを確認できます。各宛先には対応付けられたID番号があります。データベースのV$ARCHIVE_DESTビューのDEST_ID列に問合せを発行して、各宛先のID番号を特定できます。
宛先1がローカル・アーカイブREDOログを指し、宛先2がREDO転送先を指しているとします。REDOソース・データベースで次の問合せを実行し、ログ・ファイルがREDO転送先で欠落しているかどうかを確認します。
SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM - > (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) - > LOCAL WHERE - > LOCAL.SEQUENCE# NOT IN - > (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND - > THREAD# = LOCAL.THREAD#); THREAD# SEQUENCE# --------- --------- 1 12 1 13 1 14
REDOソース・データベースおよび各REDO転送先でLOG_ARCHIVE_TRACEデータベース初期化パラメータを設定し、REDO転送の進捗状況をトレースします。詳細と例は、付録Fを参照してください。
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;
|
注意: 宛先について最も頻繁に監視されるレスポンス時間は、その宛先に指定されたNET_TIMEOUT値の最高値を超えることはできません。これは、REDO転送先がNET_TIMEOUTの秒数内にREDO転送メッセージに応答しない場合、同期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属性の詳細は、第15章「LOG_ARCHIVE_DEST_nパラメータの属性」を参照してください。
場合によっては、ギャップの解決を自動的に実行できず、手動による実行が必要になります。たとえば、プライマリ・データベースが使用できない場合には、ロジカル・スタンバイ・データベースで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ビューを再度問い合せ、別のギャップ順序が存在するかどうかを判断します。この処理をギャップがなくなるまで繰り返します。 |
表6-2に、REDOソース・データベースでのREDO転送の待機時間を追跡管理するのに使用されるOracle待機イベントをいくつか示します。これらの待機イベントは、V$SYSTEM_EVENT動的パフォーマンス・ビューに表示されます。
REDO転送で使用されるOracle待機イベントの詳細リストは、次のURLからOracle Maximum Availability Architecture(MAA)のホームページにアクセスし、『Oracle Data Guard Redo Transport and Network Best Practices』ホワイト・ペーパーを参照してください。
最高のパフォーマンスを得るためにREDO転送を最適化する方法は、『Oracle Data Guard Redo Transport and Network Configuration Best Practices』ホワイト・ペーパーを参照してください。このホワイト・ペーパーは、次のURLからOracle Maximum Availability Architecture(MAA)のホームページにアクセスして入手することができます。
