11gリリース1（11.1）
E05755-03
 目次 |
 索引 |
| Oracle Data Guard 概要および管理 11gリリース1（11.1） E05755-03 |
|
この章では、Oracle REDO転送サービスを構成および監視する方法について説明します。次の項目で構成されています。
REDO転送サービスは、Oracleデータベース間でREDOデータの自動転送を実行します。次のREDO転送先がサポートされています。
このマニュアルでは、スタンバイ・データベースを作成および管理する方法について説明します。
この宛先タイプは、アーカイブREDOログ・ファイルの一時オフサイト記憶域に使用されます。アーカイブ・ログ・リポジトリは、Oracleデータベース・インスタンスとフィジカル・スタンバイ制御ファイルで構成されます。アーカイブ・ログ・リポジトリにはデータファイルが含まれないため、ロールの推移はサポートできません。
アーカイブ・ログ・リポジトリの作成に使用される手順は、データファイルのコピーを除いて、フィジカル・スタンバイ・データベースの作成に使用される手順と同じです。
Oracle Streamsダウンストリーム取得データベースの詳細は、『Oracle Streams概要および管理』を参照してください。
Oracle Change Data Captureステージング・データベースの詳細は、『Oracle Warehouse Builderユーザーズ・ガイド』を参照してください。
Oracleデータベースでは、REDOデータを最大9個のREDO転送先に送信できます。各REDO転送先は、次の2つのREDO転送モードのいずれかによりREDOデータを受信するように、個別に構成されます。
同期REDO転送モードは、REDOデータをトランザクション・コミットに対して同期させて転送します。トランザクションによって生成されたすべてのREDOが、同期REDO転送モードを使用する使用可能なREDO転送先すべてに正常に送信されるまで、そのトランザクションはコミットできません。
この転送モードは、最大保護および最大可用性の各データ保護モード（第5章「Data Guardの保護モード」を参照）で使用されます。
非同期REDO転送モードは、REDOデータをトランザクション・コミットに対して非同期で転送します。トランザクションによって生成されたすべてのREDOが、非同期REDO転送モードを使用するREDO転送先すべてに正常に送信されるまで待機しなくても、そのトランザクションはコミットできます。
この転送モードは、最大パフォーマンス・データ保護モード（第5章「Data Guardの保護モード」を参照）で使用されます。
この項では、REDO転送サービスの構成方法について説明します。次の項目で構成されています。
この項では、読者が次の項目（『Oracle Database管理者ガイド』および『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照）を十分に理解していることを前提にしたレベルで説明します。
REDO転送では、Oracle Netセッションを使用してREDOデータを転送します。これらのREDO転送セッションは、Secure Sockets Layer（SSL）プロトコルまたはリモート・ログイン・パスワード・ファイルのいずれかを使用して認証されます。
Secure Sockets Layer（SSL）は、ネットワーク接続を保護するための業界標準プロトコルです。SSLでは、RSA公開鍵暗号化および対称鍵暗号化を使用して、認証、暗号化およびデータ整合性を提供します。SSLは、次の場合に2つのOracleデータベース間のREDO転送の認証に自動的に使用されます。
LOG_ARCHIVE_DEST_n、FAL_SERVERおよびFAL_CLIENTの各データベース初期化パラメータで、SSL用に構成されたOracle Net接続記述子を使用する場合
SSL認証の要件が満たされない場合、各データベースはリモート・ログイン・パスワード・ファイルを使用する必要があります。Data Guard構成では、すべてのフィジカル・スタンバイ・データベースおよびスナップショット・スタンバイ・データベースは、プライマリ・データベースのパスワード・ファイルのコピーを使用する必要があります。このコピーは、SYSOPER権限またはSYSDBA権限が付与または取り消されるたびに、あるいはこれらの権限を持つユーザーのパスワードが変更された後に、リフレッシュする必要があります。
REDO転送の認証にパスワード・ファイルを使用する場合、REDO転送の認証に使用されるユーザー・アカウントのパスワードは、REDO転送セッションを開始したデータベースとターゲット・データベース間で比較されます。REDO転送セッションを確立するには、パスワードが両方のデータベースで一致する必要があります。
デフォルトでは、パスワード・ファイルを使用する場合、SYSユーザーのパスワードがREDO転送セッションの認証に使用されます。REDO_TRANSPORT_USERデータベース初期化パラメータを使用して、SYSOPER権限が付与されたユーザー名を設定すると、REDO転送の認証用に別のユーザー・パスワードを選択できます。管理しやすくするために、REDO_TRANSPORT_USERパラメータをREDOソース・データベースおよび各REDO転送宛先で同じ値に設定することをお薦めします。
この項では、REDOデータをREDO転送先に送信するようにOracleデータベースを構成する方法について説明します。
LOG_ARCHIVE_DEST_nデータベース初期化パラメータ（nは1〜10の整数）を使用して、ローカルのアーカイブREDOログの位置を指定するか、REDO転送先を指定します。この項では、このパラメータの後者の使用について説明します。
各LOG_ARCHIVE_DEST_nパラメータに対応するLOG_ARCHIVE_DEST_STATE_nデータベース初期化パラメータ（nは1〜10の整数）があります。このパラメータを使用すると、対応するREDO転送先を有効または無効にできます。表6-1に、このパラメータに割り当てることができる有効な値を示します。
| 値 | 説明 |
|---|---|
|
|
REDO転送サービスはこの宛先にREDOデータを転送できる。これはデフォルトです。 |
|
|
REDO転送サービスはこの宛先にREDOデータを転送しない。 |
|
|
この宛先は、関連付けられている宛先への通信に障害が発生すると使用可能になる。 |
REDO転送先は、LOG_ARCHIVE_DEST_nパラメータを、1つ以上の属性を含む文字列に設定して構成します。この項では、最も一般的に使用される属性について簡単に説明します。すべてのLOG_ARCHIVE_DEST_nパラメータの属性の詳細は、第15章を参照してください。
SERVICE属性は、REDO転送先の必須属性で、属性リストの最初に指定する必要があります。SERVICE属性は、REDO転送先への接続に使用されるOracle Netサービス名の指定に使用されます。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.3.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値の1つと一致する必要があります。また、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転送に使用している場合、REDOギャップの解決時間が大幅に短縮されます。REDOギャップの解決の詳細は、6.3.3項を参照してください。
次の例では、この項で説明したLOG_ARCHIVE_DEST_nの属性をすべて使用しています。2つのREDO転送先が定義され、使用可能になっています。最初の宛先は、非同期REDO転送モードを使用します。2番目の宛先は、30秒のタイムアウトを指定した同期REDO転送モードを使用します。DB_UNIQUE_NAMEは、REDOギャップの解決時に圧縮を使用するので、両方の宛先に指定されています。REDO転送障害がいずれかの宛先で発生した場合、REDO転送はその宛先への再接続を試行しますが、60秒に1回より長い間隔で行います。
DB_UNIQUE_NAME=BOSTON LOG_ARCHIVE_CONFIG='DG_CONFIG=(BOSTON,CHICAGO,DENVER)' 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=DENVER SYNC AFFIRM NET_TIMEOUT=30 VALID_FOR=
(ONLINE_LOGFILE,PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE DB_UNIQUE_NAME=DENVER' LOG_ARCHIVE_DEST_STATE_3='ENABLE'
V$ARCHIVE_DESTビューを問い合せると、REDO転送先ごとに現行の設定およびステータスを確認できます。
この項では、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ログ・グループが少なくとも1つ多く必要です。
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ログを作成できます。
ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog1.rdo') SIZE 500M; ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog2.rdo') SIZE 500M; ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog3.rdo') SIZE 500M;
この項では、スタンバイREDOログ・アーカイブの構成方法について説明します。
次の手順を実行して、スタンバイ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ソース・データベースで次の問合せを実行し、各スレッドの最新のアーカイブ順序番号を判定します。
SQL> SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG GROUP BY THREAD#;
REDOソース・データベースで次の問合せを実行し、各REDO転送先の最新のアーカイブREDOログ・ファイルを判定します。
SQL> SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ# 2> FROM V$ARCHIVE_DEST_STATUS 3> 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 2> (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) 3> LOCAL WHERE 4> LOCAL.SEQUENCE# NOT IN 5> (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND 6> THREAD# = LOCAL.THREAD#); THREAD# SEQUENCE# --------- --------- 1 12 1 13 1 14
REDOソース・データベースおよび各REDO転送先でLOG_ARCHIVE_TRACEデータベース初期化パラメータを設定し、REDO転送の進捗状況をトレースします。詳細と例は、付録Gを参照してください。
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 2> V$REDO_DEST_RESP_HISTOGRAM WHERE DEST_ID=2 AND FREQUENCY>1;
REDOソース・データベースで次の問合せを実行すると、宛先2について最も遅いレスポンス時間を表示できます。
SQL> SELECT max(DURATION) FROM V$REDO_DEST_RESP_HISTOGRAM 2> WHERE DEST_ID=2 AND FREQUENCY>1;
REDOソース・データベースで次の問合せを実行すると、宛先2について最も速いレスポンス時間を表示できます。
SQL> SELECT min( DURATION) FROM V$REDO_DEST_RESP_HISTOGRAM 2> WHERE DEST_ID=2 AND FREQUENCY>1;
REDOギャップは、REDO転送が割り込まれるたびに発生します。REDO転送が再開されると、REDO転送サービスはREDOギャップを自動的に検出し、欠落したREDOを宛先に送信して解決します。
REDOギャップの解決に必要な時間は、ギャップのサイズに正比例し、REDOソース・データベースとREDO転送先との間のネットワーク・リンクの実効スループットに反比例します。REDO転送サービスには、パフォーマンスが低いネットワーク・リンクを使用している場合にREDOギャップの解決時間を短縮するオプションが2つあります。
LOG_ARCHIVE_DEST_nパラメータのCOMPRESSION属性を使用すると、REDO転送の圧縮を使用して、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 2> 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
これらのログ・ファイルをフィジカル・スタンバイ・データベースにコピーし、コピーしたログを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';
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 2> WHERE NEXT_CHANGE# NOT IN 3> (SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#) 4> 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';
表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』ホワイト・ペーパーを参照してください。
http://otn.oracle.com/deploy/availability/htdocs/maa.htm
最高のパフォーマンスを得るためにREDO転送を最適化する方法は、『Oracle Data Guard Redo Transport and Network Configuration Best Practices』ホワイト・ペーパーを参照してください。このホワイト・ペーパーは、次のURLからOracle Maximum Availability Architecture（MAA）のホームページにアクセスして入手することができます。
http://otn.oracle.com/deploy/availability/htdocs/maa.htm
|
 Copyright © 1999, 2008 Oracle Corporation. All Rights Reserved. |
|