REDO転送サービス(Redo Transport Services)

1 REDOデータ送信先(Where to send redo data)

1.1 宛先タイプ(Distination Types)

  • Oracle Data Guard スタンバイ・データベース
  • アーカイブREDO ログ・リポジトリ
  • Oracle Streams リアルタイム・ダウンストリーム取得データベース
  • Oracle Change Data Capture ステージング・データベース

1.2 宛先の構成(Configuring Distinations with the LOG_ARCHIVE_DEST_n)

LOG_ARCHIVE_DEST_n 初期化パラメータ

  • LOG_ARCHIVE_DEST_n 初期化パラメータでは、最大10の宛先を定義する。
  • いずれもLOCATION(ローカル・ディスク) またはSERVICE(REDO転送サービス) 属性を使用してREDO データのアーカイブ先を指定する必要がある。

ARCHIVE_DEST_STATE_n パラメータ

  • 定義する各LOG_ARCHIVE_DEST_n 初期化パラメータに対し、それぞれ対応するLOG_ARCHIVE_DEST_STATE_n パラメータを指定する。
  • LOG_ARCHIVE_DEST_STATE_n(n は1から10 の整数)初期化パラメータは、対応する宛先が現在オン(有効)とオフ(無効)のどちらになっているかを指定する。

LOG_ARCHIVE_DEST_STATE_n 初期化パラメータの属性

属性 説明
ENABLE REDO ログ転送サービスはこの宛先にREDO データを転送できる。これはデフォルトです。
DEFER REDO 転送サービスはこの宛先にREDO データを転送しない。これは有効ですが、使用されない宛先です。
ALTERNATE この宛先は使用可能ではないが、関連付けられている宛先への通信に障害が起きると使用可能になる。
RESET 機能はDEFER と同じだが、前に失敗している場合は宛先に関するエラー・メッセージを消去する。

1.3 フラッシュ・リカバリ領域の設定(Setting Up Flash Recovery Areas)

フラッシュ・リカバリ領域を構成するには、DB_RECOVERY_FILE_DEST 初期化パラメータを使用する。リカバリ領域を作成し、他のローカルのアーカイブ先を設定しない場合、LOG_ARCHIVE_DEST_10 は暗黙的にUSE_DB_RECOVERY_FILE_DEST に設定される(アーカイブREDO ログ・ファイルがフラッシュ・リカバリ領域に送信されることを意味する)。フラッシュ・リカバリ領域の構成については、フラッシュ・リカバリ領域の設定・管理を参照して下さい。

1.3.1 LOG_ARCHIVE_DEST_10 の宛先の使用

フラッシュ・リカバリ領域が構成されていて、ローカルの宛先が定義されていない場合、DataGuard により暗黙的に、LOG_ARCHIVE_DEST_10 の宛先がフラッシュ・リカバリ領域として使用される。LOG_ARCHIVE_DEST_10 の宛先が使用される場合、Data Guard は、自動的にすべてのLOG_ARCHIVE_DEST_10 パラメータ属性のデフォルト値を使用する。

1.3.2 他のLOG_ARCHIVE_DEST_n の宛先の使用

  • LOG_ARCHIVE_DEST_10 以外の宛先を構成する場合
alter system set log_archive_dest_1='location=use_db_recovery_file_dest valid_for=(online_logfiles,primary_role)';
  • ロールの推移後に使用するためにLOG_ARCHIVE_DEST_10 の宛先に加えて宛先を構成する場合
LOG_ARCHIVE_DEST_9='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH MANDATORY REOPEN=5 VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)'
LOG_ARCHIVE_DEST_10='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH MANDATORY REOPEN=5 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)'

1.3.3 STANDBY_ARCHIVE_DEST の宛先の使用

フィジカル・スタンバイ・データベースの場合は、フラッシュ・リカバリ領域を指すようにSTANDBY_ARCHIVE_DEST パラメータを定義できる。

STANDBY_ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST'

1.3.4 プライマリ・データベースとスタンバイ・データベースでフラッシュ・リカバリ領域を共有する

フラッシュ・リカバリ領域を共有する各データベースに、DB_UNIQUE_NAME 初期化パラメータで一意のデータベース名が指定されている場合は、データベース間でフラッシュ・リカバリ領域を共有できる。
プライマリDBのパラメータ設定例(DB_UNIQUE_NAMEはデフォルトでPAYROLLに設定される)

DB_NAME=PAYROLL
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'
DB_RECOVERY_FILE_DEST='/arch/oradata'
DB_RECOVERY_FILE_DEST_SIZE=20G

スタンバイDBのパラメータ設定例
DB_NAME=PAYROLL
DB_UNIQUE_NAME=boston
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'
STANDBY_ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST'
DB_RECOVERY_FILE_DEST='/arch/oradata'
DB_RECOVERY_FILE_DEST_SIZE=5G

2 REDOデータ送信方法(How to send redo data)

  • プライマリDBでは、アーカイバ・プロセス(ARCn)またはログ・ライター・プロセス(LGWR)を使用し、トランザクションREDO データを収集してスタンバイ宛先に転送する。
  • 同じ宛先へのREDO送信にARCnとLGWRの両方を使用できない。ある宛先にLGWRを使用し、他の宛先にARCnを使用してREDO送信ができる。
  • DataGuardでは、ギャップの自動解消及び再同期化のため、フェッチ・アーカイブ・ログ(FAL)クライアントおよびサーバーを使用して、ネットワーク停止後にアーカイブREDO ログ・ファイルがスタンバイ宛先に送信される。

2.1 ARCnでREDOログのアーカイブ(Using ARCn to Archive Redo Data)

  • ARCnアーカイブ・プロセスはData Guard 構成で最大パフォーマンス・レベルのデータ保護のみをサポートする。
  • LOG_ARCHIVE_DEST_nの属性を指定して、プライマリDBから他の宛先へのREDO自動転送を制御する。(ARCnはデフォルト動作なので、ARCH属性の指定はオプション)。
  • LOG_ARCHIVE_MAX_PROCESSESはARCnプロセス最大数を指定する。デフォルトは4つ、最大30まで、ワークロードを調整するため、Oracle DBにより、ARCnプロセス数が動的に調整される。
  • ARCnによりアーカイブ処理の場合、ローカルアーカイブをリモートアーカイブから分離するため、2つ以上のARCnプロセスが必要だ。ローカルアーカイブとリモートアーカイブの分離で、LGWRによるオンラインREDOログファイルの再利用が非常に早くなる。

2.2 LGWRでREDOログのアーカイブ(Using the LGWR to Archive Redo Data)

2.2.1 LGWRプロセスとARCnプロセスの違い

Using the LGWR process differs from ARCn processing ,because instead of waiting for the online redo log to switch at the primary database and then writing the entire archived redo log at the remote destination all at once,the LGWR process selects a standby redo log file at the standby site that reflects the log sequence number (and size) of the current online redo log file of the primary database.

2.2.2 LGWRプロセス使用

LOG_ARCHIVE_DEST_n:LGWR およびSERVICE 属性を指定する必要がある。

同期、非同期ネットワーク転送設定
  • SYNC 属性を指定すると、すべてのネットワークI/O がオンラインREDO ログ・ファイルへの各書込み操作と同期して実行され、ネットワークI/O の完了を待機する(デフォルトのネットワーク転送設定)。データ保護の最大保護および最大可用性モードには、同期LGWR 処理が必須です
  • ASYNC 属性を指定すると、すべてのネットワークI/O は非同期的に実行され、ネットワークI/O の完了を待たずに、実行中のアプリケーションまたはユーザーへ制御が即時に戻される。
LGWR SYNC処理

  プライマリDB側、LGWRは1つ以上のネットワークサーバープロセス(LNSn)でREDOデータをパラレルに複数の宛先に送信する。トランザクションのREDOデータがすべてのLGWR SYNC宛先に受信されるまで、プライマリDBはトランザクションがコミットされない。スタンバイDB側では、リモートファイルサーバー(RFS)がネットワークを介してREDOデータを受信し、スタンバイREDOログファイルに書き込む。
  プライマリDBのログスイッチによって、スタンバイDBのログスイッチがトリガーされる。スタンバイDBのARCnはスタンバイREDOログファイルをスタンバイREDOアーカイブファイルにアーカイブする。

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago'
LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR SYNC NET_TIMEOUT=30'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE

LGWR ASYNC処理

  LGWR およびASYNC 属性を指定すると、ログ・ライター・プロセスがローカルのオンラインREDO ログ・ファイルに書き込む間に、ネットワーク・サーバー(LNSn)プロセス(宛先ごとに1 つずつ)がREDO をリモートの宛先に非同期的に転送します。LGWR プロセスは、LNSネットワークI/O の完了を待たずに次の要求の処理を続行します。

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago'
LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR ASYNC'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE

3 REDOデータ送信タイミング(When Redo Data Should Be Sent)

3.1 VALID_FOR 属性を使用したロール・ベースの宛先の指定

  • VALID_FORの設定によって、スイッチオーバー及びフェイルオーバーが単純化される。
  • VALID_FOR属性に従って、REDO転送サービスがREDOデータを宛先にいつ転送できるかを識別する。

VALID_FOR=(redo_log_type,database_role)
redo_log_type:ONLINE_LOGFILE,STANDBY_LOGFILE,ALL_LOGFILES
database_role:PRIMARY_ROLE,STANDBY_ROLE ,ALL_ROLES
例: LOG_ARCHIVE_DEST_1='LOCATION=/ARCH1/CHICAGO/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES)'

3.2 DB_UNIQUE_NAME 属性の設定

  • DB_UNIQUE_NAME 属性を使用することによって、RAC+DG構成に動的にスタンバイDBを追加できるようになる。
  • LOG_ARCHIVE_CONFIGが定義されている場合、DB_UNIQUE_NAMEが必須である。

DB_NAME=chicago
DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago, boston)'
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston'
REDO転送サービスがboston宛へREDOデータを送信する時、リモートでDB_UNIQUE_NAMEを検証し、一致しなければその宛先への送信が拒否される。

4 エラー対処(What to Do If Errors Occur)

4.1 アーカイブ操作再試行(REOPEN属性)

  • REOPEN属性を使って、ARCnまたはLGWRがエラーを発生した宛先へREDOデータ再送信をするかどうかと、その時期を指定する。
  • REOPEN=secondsでREDOデータ送信再試行の間隔を指定する。デフォルトで300秒、0を指定すると、再試行はしない。

4.2 代替アーカイブ先(ALTERNATE属性)

  • ALTERNATE属性では、アーカイブ障害時、使用できる代替アーカイブ先を定義する。
  • ALTERNATE属性より、REOPEN属性のほうが優先される。下記の何れかが満たされている場合、代替アーカイブ先は使用される。
    • REOPEN 属性に、値0(ゼロ)が指定されている。
    • 0(ゼロ)ではないREOPEN 属性で、0(ゼロ)ではないMAX_FAILURE の件数を超過している。
  • ALTERNATE属性はMANDATORY属性より優先される。

4.3 再試行回数(MAX_FAILURE属性)

  • REDO転送サービスが失敗した宛先へ再試行する最大回数を指定する。
  • 試行した回数を超えると、REOPEN属性が0に設定されていたものとして処理される。
  • MAX_FAILUREを使用すると、REOPEN属性が必須となる。

LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=60 MAX_FAILURE=3'

5 データ保護モード(Setting Up a Data Protection Mode)

5.1 データ保護モード要件

項目 最大保護(Maximum Protection) 最大可用性(Maximum Availability) 最大パフォーマンス(Maximum Performance)
REDO アーカイブ・プロセス LGWR LGWR LGWRまたはARCn
ネットワーク転送モード SYNC SYNC LGWR:SYNC またはASYNC。ARCH:SYNC。
ディスク書込みオプション AFFIRM AFFIRM AFFIRM またはNOAFFIRM
スタンバイREDOログ必要性 YES YES NO,ただし推奨される
データ消失 NO YES YES

5.2 データ保護モード指定

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE}

実機検証:DataGuard 保護モード設定(Upgrade Maximum Availability Mode)

6 手動によるアーカイブギャップ(GAP)の判断及び解決

6.1 フィジカル・スタンバDBのギャップ判断

ギャップ(GAP)が存在するかどうかを判断するには、V$ARCHIVE_GAP ビューを問い合わせる。

SQL> SELECT * FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
----------- ------------- --------------
1 7 10

プライマリDBでV$ARCHIVED_LOGを問い合わせて欠落したアーカイブログを調べる。
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND
2> 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

6.2 ロジカル・スタンバイDBのギャップ判断

ロジカルスタンバイDBの場合、DBA_LOGSTDBY_LOGを問い合わせてギャップが存在するかどうかを調べられる。

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

6.3 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';

ログ・ファイルをフィジカル・スタンバイ・データベースに登録した後は、REDO Apply を再開できる。

7 監視と確認

7.1 ログファイル・アーカイブ監視

V$LOG:REDOログ・ファイルのステータスを判定する
V$ARCHIVED_LOG:最新のアーカイブREDO ログ・ファイルを判定する
V$ARCHIVE_DEST_STATUS:各アーカイブ先で最新のアーカイブREDO ログ・ファイルを判定する
LOG_ARCHIVE_TRACEパラメーター:スタンバイ・サイトで転送されたREDO の進行状況をトレースする

7.2 待機イベント

待機イベント タイプ 待機時間の監視対象
ARCH wait on ATTACH ARCn すべてのARCn プロセスによるRFS 接続の生成。
ARCH wait on SENDREQ ARCn すべてのARCn プロセスによる、受信したREDO データのディスクへの書込み、およびリモートのアーカイブREDO ログ・ファイルのオープンおよびクローズ。
ARCH wait on DETACH ARCn すべてのARCn プロセスによるRFS 接続の削除。
LGWR wait on LNS LGWR SYNC LNSn プロセスからメッセージを受信するまでのLGWR プロセスの待機。
LNS wait on ATTACH LGWR SYNC すべてのネットワーク・サーバーによるRFS 接続の生成。
LNS wait on SENDREQ LGWR SYNC すべてのネットワーク・サーバーによる、受信したREDO データのディスクへの書込み、およびリモートのアーカイブREDO ログ・ファイルのオープンおよびクローズ。
LNS wait on DETACH LGWR SYNC すべてのネットワーク・サーバーによるRFS 接続の削除。
LNS wait on DETACH LGWR ASYNC すべてのネットワーク・サーバーによるRFS 接続の削除。
LNS wait on ATTACH LGWR ASYNC すべてのネットワーク・サーバーによるRFS 接続の生成。
LNS wait on SENDREQ LGWR ASYNC すべてのネットワーク・サーバーによる、受信したREDO データのディスクへの書込み、およびリモートのアーカイブREDO ログ・ファイルのオープンおよびクローズ。
True ASYNC Control FileTXN Wait LGWR ASYNC LNSn プロセスによるライフタイム中の制御ファイル・トランザクションの保留。
True ASYNC Wait for ARCH log LGWR ASYNC アーカイブREDO ログを参照するまでのLNSn プロセスの待機(LNSn プロセスが現行のログ・ファイルをアーカイブ中でログ・スイッチが発生する場合)。
Waiting for ASYNC dest activation LGWR ASYNC アクティブでない宛先がアクティブになるまでのLNSn プロセスの待機。
True ASYNC log-end-of-file wait LGWR ASYNC 論理的なファイルの終わりに達した後で次のREDO ビットに達するまでのLNSn プロセスの待機。
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License