17 LOG_ARCHIVE_DEST_nパラメータの属性
これは、LOG_ARCHIVE_DEST_n初期化パラメータの属性のリストです(nは1から31の間の整数)。
               
- 
                     LOCATIONおよびSERVICE( LOCATIONはLOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31ではサポートされない)
- 
                     MANDATORY( LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31ではサポートされない)
- 
                     SYNCおよびASYNC( SYNCはLOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31ではサポートされない)
使用上のノート
- 
                     Oracle Data Guard構成の各データベースは、通常、オンラインおよびスタンバイREDOログのアーカイブ用の LOCATION属性を持つ宛先を1つと、構成にあるその他のデータベース用のREMOTE属性を持つ宛先を1つ持ちます。
- 
                     構成されている場合、 LOG_ARCHIVE_DEST_1からLOG_ARCHIVE_DEST_10の各宛先には、ローカル・ディスクのディレクトリまたはリモートからアクセスするデータベースを指定する、LOCATIONまたはSERVICE属性が含まれている必要があります。LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31の各宛先にはSERVICE属性が含まれている必要があります。その他のすべての属性は省略可能です。 
- 
                     LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31は、COMPATIBLE初期化パラメータが11.2.0.0以上に設定されている場合のみ使用できます。
ノート:
LOG_ARCHIVE_DEST_n初期化パラメータの複数の属性が非推奨になりました。これらの属性は下位互換用にサポートされており、『Oracle Databaseリファレンス』で説明しています。
                  
関連項目:
LOG_ARCHIVE_DEST_n宛先を定義してREDO転送サービスを設定する方法の詳細は、REDO転送サービスを参照してください
                  
AFFIRMおよびNOAFFIRM
AFFIRMおよびNOAFFIRM属性は、REDO転送先が、受信済REDOデータをスタンバイREDOログに書き込む前または書き込んだ後に、受信済REDOデータを確認するかどうかを制御します。
                  
各オプションの定義は次のとおりです。
- 
                        AFFIRM—REDO転送先で受信したREDOデータをスタンバイREDOログに書き込んだ後に確認するように指定します。
- 
                        NOAFFIRM—REDO転送先で受信したREDOデータをスタンバイREDOログに書き込む前に確認するように指定します。
| カテゴリ | AFFIRM | NOAFFIRM | 
|---|---|---|
| データ型 | キーワード | キーワード | 
| 有効な値 | 該当なし | 該当なし | 
| デフォルト値 | 該当なし | 該当なし | 
| 必須属性 | 
 | 
 | 
| 属性との競合 | 
 | 
 | 
| 対応先 | 
 | 
 | 
使用上のノート
- 
                           AFFIRM属性およびNOAFFIRM属性が指定されていない場合、デフォルトは、SYNC属性が指定されているときはAFFIRM、ASYNC属性が指定されているときはNOAFFIRMです。
- 
                           SYNC属性を使用しないAFFIRM属性の指定は非推奨であり、今後のリリースではサポートされません。
関連項目:
例
次の例は、リモート宛先のAFFIRM属性を示しています。
                     
LOG_ARCHIVE_DEST_3='SERVICE=stby1 SYNC AFFIRM' LOG_ARCHIVE_DEST_STATE_3=ENABLE
ALTERNATE
ALTERNATE属性は、元のアーカイブ先で障害が発生したときに使用する代替アーカイブ先を指定します。
                  
ノート:
Oracle Database 12cリリース2 (12.2.0.1)以降、代替アーカイブ先の数と機能を、リモート・ログ・アーカイブ先のALTERNATE属性のかわりにGROUPおよびPRIORITY属性を使用することで拡張できます。この新しい方法はALTERNATE属性の方法とともには使用できません。詳細は、代替宛先を参照してください。
                     ALTERNATE属性は、代替ローカル・アーカイブ先を構成するために予約されています。下位互換性のために、ALTERNATEをリモート・ログ・アーカイブに使用する例がALTERNATE属性を使用したリモート代替宛先の構成に提供されています。
                     
| カテゴリ | ALTERNATE=LOG_ARCHIVE_DEST_n | 
|---|---|
| データ型 | 文字列 | 
| 有効な値 | 
 | 
| デフォルト値 | なし。代替宛先が指定されていない場合、REDO転送サービスでは自動的に別のアーカイブ先に変更されません。 | 
| 必須属性 | なし脚注1 | 
| 属性との競合 | 
 | 
| 対応先 | 
 | 
脚注1
MAX_FAILUREがALTERNATEで使用されることは必須ではありませんが、代替宛先がアクティブになるには、ゼロ以外のMAX_FAILURE値が必要です。ALTERNATEをMAX_FAILUREのデフォルト値(ゼロ)とともに使用すると、動作は変わりません。
                     
脚注2
REOPEN属性にゼロ以外の値を指定すると、試行間の最小時間がREOPENの値(秒)と等しくなり、エラーの回数がMAX_FAILUREの値と等しいか超えるまで代替宛先はアクティブになりません。
                     
使用上のノート
- 
                           ALTERNATE属性はオプションです。代替宛先が指定されていない場合、元のアーカイブ先に障害が発生しても、アーカイブ・サービスでは自動的に別のアーカイブ先に変更されません。
- 
                           ローカルの LOG_ARCHIVE_DEST_nパラメータごとに指定できる代替宛先は、1つのみです(LOCATION=…)。
- 
                           代替宛先には、次の例に示されているように同じローカル・プライマリ・データベース・システムまたはローカル・スタンバイ・データベース・システム上の異なるディスクの場所を指定する必要があります。 
- 
                           代替宛先を構成するには、 LOG_ARCHIVE_DEST_STATE_nパラメータをALTERNATEに設定します。
- 
                           代替宛先を手動で有効化するには、 LOG_ARCHIVE_DEST_STATE_nパラメータをENABLEに設定します。
- 
                           有効化された宛先が代替宛先を参照していない場合は、代替宛先を自動的に有効化する方法はないため、代替宛先は保留になることを意味しています。ただし、 ALTER SYSTEM文を使用して実行時に代替宛先を有効化できます。
- 
                           代替宛先に指定できる宛先には、次の制限事項があります。 - 
                                 ローカル宛先を少なくとも1つは有効にする。 
- 
                                 有効な宛先数は、 LOG_ARCHIVE_MIN_SUCCEED_DESTパラメータでの定義と一致させる必要がある。
- 
                                 宛先をそれ自身の代替先にすることはできない。 
 
- 
                                 
- 
                           宛先に障害がある場合、次のアーカイブ操作で代替宛先が有効化されます。アーカイブ操作中に代替宛先を有効化するには処理済のブロックを再度読み取る必要があるので、これはサポートされていません。 
- 
                           代替宛先が指定されていない場合、または MAX_FAILUREがゼロ(デフォルト)に設定されている場合、元の宛先に障害が発生しても、アーカイブ・サービスでは自動的に別の宛先に変更されません。
例
これらの例は、基本的な概念を示しており、示しているように使用することを意図しているわけではありません。ローカルのアーカイブ設定によって構成は異なります。
次の例に、サンプル初期化パラメータ・ファイルを示します。このサンプル・ファイルでは、書込み失敗や割当て失敗などのエラーが発生したり、デバイスがいっぱいになった場合、次回のアーカイブ操作で、ローカル・アーカイブ先LOG_ARCHIVE_DEST_1は代替宛先LOG_ARCHIVE_DEST_2に自動的にフェイルオーバーします。
                     
例17-1 代替ローカル宛先への自動フェイルオーバー
LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY MAX_FAILURE=1 
ALTERNATE=LOG_ARCHIVE_DEST_2'
 
LOG_ARCHIVE_DEST_STATE_1=ENABLE
 
LOG_ARCHIVE_DEST_STATE_2=ALTERNATE
LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY'元の宛先LOG_ARCHIVE_DEST_1へのアーカイブを再開するには、手動で再度有効にする必要があります。次に、LOG_ARCHIVE_DEST_2を前の代替状態にリセットしてアクティブなローカル・アーカイブ先が2つにならないようにする必要があります。そのためには、次のようにしてLOG_ARCHIVE_DEST_STATE_nパラメータを元の値に設定します。
                     
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_1=ENABLE ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ALTERNATE
このフォールバック・メカニズムは自動化できます。例17-2のサンプル初期化パラメータ・ファイルで示すように、優先宛先を指すALTERNATE属性を指定して、元の宛先と代替宛先のペアを作成します。
                     
例17-2 自動ローカル代替フォールバック
LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY MAX_FAILURE=1 
ALTERNATE=LOG_ARCHIVE_DEST_2'
 
LOG_ARCHIVE_DEST_STATE_1=ENABLE
 
LOG_ARCHIVE_DEST_STATE_2=ALTERNATE
LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY 
ALTERNATE=LOG_ARCHIVE_DEST_1'
LOG_ARCHIVE_DEST_1が再度使用できるようになると、Oracle Data Guardはアクティブなローカル・アーカイブ宛先になるように自動的に設定し、LOG_ARCHIVE_DEST_2をその代替としてリセットします。
                     
COMPRESSION
COMPRESSION属性は、REDOデータをREDO転送先に転送する前に圧縮するかどうかを指定するために使用します。
                  
ノート:
REDO転送の圧縮は、Oracle Advanced Compressionオプションの機能です。REDO転送の圧縮機能を使用する前に、このオプションのライセンスを購入する必要があります。
| カテゴリ | COMPRESSION=[ENABLE | DISABLE | ZLIB | LZO] | 
|---|---|
| データ型 | ブール | 
| 有効な値 | 
 | 
| デフォルト値 | 
 | 
| 必須属性 | なし | 
| 属性との競合 | なし | 
| 対応先 | 
 | 
使用上のノート
- 
                           ENABLEオプションを指定すると圧縮が可能になり、デフォルトでZLIB圧縮アルゴリズムが使用されます。
- 
                           COMPRESSION属性はオプションです。指定されていない場合、デフォルトの圧縮動作はDISABLEです。
- 
                           Oracle Data Guardの COMPRESSION属性も使用するSYNC接続文字列の場合、sqlnet.oraファイルでSQLNET.COMPRESSION構成パラメータを無効に設定します(オフにします)。SQLNET.COMPRESSIONパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。
例
次の例は、COMPRESSION属性が指定されているLOG_ARCHIVE_DEST_nパラメータを示しています。ENABLEオプションが指定されているため、ZLIB圧縮アルゴリズムが使用されます。
                     
LOG_ARCHIVE_DEST_3='SERVICE=denver SYNC COMPRESSION=ENABLE' LOG_ARCHIVE_DEST_STATE_3=ENABLE
DB_UNIQUE_NAME
DB_UNIQUE_NAME属性は、この宛先にあるデータベースの一意の名前を指定します。
                  
| カテゴリ | DB_UNIQUE_NAME=name | 
|---|---|
| データ型 | String | 
| 有効な値 | nameは、 | 
| デフォルト値 | なし | 
| 必須属性 | なし | 
| 属性との競合 | なし | 
| 対応先 | 
 | 
使用上のノート
- 
                           この属性は、次の場合にはオプションです。 - 
                                 LOG_ARCHIVE_CONFIG=DG_CONFIG初期化パラメータが指定されていない場合。
- 
                                 これがローカル宛先( LOCATION属性で指定)の場合。
 
- 
                                 
- 
                           この属性が必須となるのは、 LOG_ARCHIVE_CONFIG=DG_CONFIG初期化パラメータが指定されており、かつ、これがリモート宛先(SERVICE属性で指定)の場合です。
- 
                           プライマリ・データベースとスタンバイ・データベースの関係を明確に識別するには、 DB_UNIQUE_NAME属性を使用します。この属性は、Oracle Data Guard構成に複数のスタンバイ・データベースが存在する場合に特に有用です。
- 
                           DB_UNIQUE_NAMEで指定する名前は、DG_CONFIGリストのDB_UNIQUE_NAME値の1つと一致している必要があります。REDO転送サービスにより、指定された宛先のデータベースのDB_UNIQUE_NAME属性がDB_UNIQUE_NAME属性と一致していること、またはその宛先への接続が拒否されていることが検証されます。
- 
                           DB_UNIQUE_NAME属性で指定する名前は、宛先で識別されるデータベースのDB_UNIQUE_NAME初期化パラメータで指定されている名前と一致している必要があります。
例
次の例では、DB_UNIQUE_NAMEパラメータではboston (DB_UNIQUE_NAME=boston)が指定されており、これはLOG_ARCHIVE_DEST_1パラメータのDB_UNIQUE_NAME属性にも指定されています。LOG_ARCHIVE_DEST_2パラメータのDB_UNIQUE_NAME属性は、宛先としてchicagoを指定しています。bostonとchicagoは、どちらもLOG_ARCHIVE_CONFIG=DG_CONFIGパラメータにリストされています。
                     
DB_UNIQUE_NAME=boston LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)' LOG_ARCHIVE_DEST_1='LOCATION=/arch1/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2='SERVICE=Sales_DR VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago'
DELAY
DELAY属性は、スタンバイ・サイトでプライマリ・サイトからのREDOデータがアーカイブされてから、スタンバイ・データベースまたはそこからカスケードされたスタンバイにアーカイブREDOログ・ファイルが適用されるまでの最小タイム・ラグを指定します。
                  
| カテゴリ | DELAY[=minutes] | 
|---|---|
| データ型 | 数値 | 
| 有効な値 | 0分以上 | 
| デフォルト値 | 30分 | 
| 必須属性 | 
 | 
| 属性との競合 | 
 | 
| 対応先 | 
 | 
使用上のノート
- 
                           DELAY属性はオプションです。デフォルトでは、遅延は発生しません。
- 
                           DELAY属性は、スタンバイ宛先のアーカイブREDOログ・ファイルが、指定した時間が経過するまでリカバリに利用されないことを示します。時間間隔は分で表され、転送されたREDOデータがスタンバイ・サイトに正常に到達した時点から計測されます。
- 
                           DELAY属性を使用すると、破損したプライマリ・データまたは誤ったプライマリ・データからスタンバイ・データベースを保護できます。ただし、フェイルオーバー中は、破損が発生した時点までのすべてのREDOを適用するための所要時間が長くなるため、トレードオフを伴います。
- 
                           DELAY属性は、REDOデータのスタンバイ宛先への転送に影響しません。
- 
                           リアルタイム適用が使用可能になっている場合、設定した遅延は無視されます。 
- 
                           DELAY属性の変更は、次にREDOデータをアーカイブすると(ログ・スイッチ後に)有効になります。進行中のアーカイブ操作には、影響しません。
- 
                           指定した遅延間隔は、スタンバイ・サイトで次のように上書きできます。 - 
                                 フィジカル・スタンバイ・データベース用 SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY; 
- 
                                 ロジカル・スタンバイ・データベース用 SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY; 
 
- 
                                 
- 
                           カスケードされたスタンバイが使用する DELAY値は、カスケードしているスタンバイにREDOを送信したプライマリのLOG_ARCHIVE_DEST_nパラメータに設定された値です。
関連項目:
これらのALTER DATABASE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
                        
例
DELAY属性を使用すれば、プライマリ・データベースと様々なレベルで同期させる複数のスタンバイ・データベースを維持する構成を設定できます。ただし、REDO Applyで破損時点までのすべてのREDOを適用するまでにかかる時間が長くなるため、フェイルオーバー中は、この保護はなんらかのオーバーヘッドを伴います。 
                     
たとえば、プライマリ・データベースAにスタンバイ・データベースBおよびCがあると仮定します。スタンバイ・データベースBは障害時リカバリ・データベースとして設定されているため、タイム・ラグはありません。スタンバイ・データベースCには2時間の遅延が設定されています。2時間あれば、スタンバイ・データベースに伝播する前に、ユーザー・エラーを検出できます。
次の例は、この構成用にDELAY属性を指定する方法を示しています。
                     
LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest MANDATORY' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_2='SERVICE=stbyB SYNC AFFIRM' LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_3='SERVICE=stbyC DELAY=120' LOG_ARCHIVE_DEST_STATE_3=ENABLE
ノート:
または、十分なフラッシュバック・ログ・データがあれば、フラッシュバック・データベースを使用して、データベースを障害発生時点または他のデータベース・インカネーションのSCNまで戻すこともできます。フラッシュバック・データベースの使用については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』で説明しています。
ENCRYPTION
ENCRYPTION属性は、Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)に転送する前にREDOデータを暗号化するかどうかを指定するために使用されます。 
                  
ノート:
REDO転送の暗号化はリカバリ・アプライアンスへの接続でのみ許可されます。リカバリ・アプライアンス以外のログ・アーカイブ先で暗号化を構成しようとするとエラーになります。
| カテゴリ | ENCRYPTION=ENABLEまたはDISABLE | 
|---|---|
| データ型 | ブール | 
| 有効な値 | 
 | 
| デフォルト値 | 
 | 
| 必須属性 | 
 | 
| 属性との競合 | 
 | 
| 対応先 | 
 | 
使用上のノート
- 
                           ENCRYPTION属性はオプションです。指定しない場合、デフォルトの暗号化動作はDISABLEです。
- 
                           ENCRYPTION属性を使用するには、保護されたデータベースでCOMPATIBLE初期化パラメータを11.2.0.4以上に設定する必要があります。
例
次の例に、LOG_ARCHIVE_DEST_nパラメータに指定したENCRYPTION属性を示します。
                     
LOG_ARCHIVE_DEST_3='SERVICE=denver ENCRYPTION=ENABLE' LOG_ARCHIVE_DEST_STATE_3=ENABLE
関連項目:
- 
                              Zero Data Loss Recovery Appliance管理者ガイド( LOG_ARCHIVE_DEST_nパラメータを使用したREDO暗号化の詳細)
- 
                              Oracle Database Advanced Securityガイド(透過的データ暗号化の詳細) 
GROUP
GROUP属性を使用して、ログのアーカイブ先の特定のコレクションでメンバーシップを指定します。
                  
  グループは1から8まで番号付けされます。デフォルトのグループ(GROUP=0)は、割り当てることができないという点において特殊です。デフォルトのグループには、明示的にグループに割り当てられないすべての宛先が移入されます。
                  
| カテゴリ | GROUP=integer | 
|---|---|
| データ型 | 整数 | 
| 有効な値 | 1から8 | 
| デフォルト値 | 0 | 
| 必須属性 | SERVICE | 
| 属性との競合 | ALTERNATE | 
| 対応先 | 該当なし | 
使用上のノート
- 
                           なし 
例
DB_UNIQUE_NAMEなどの他の必須パラメータが存在する場合もあります。 LOG_ARCHIVE_DEST_1='SERVICE=FS1 GROUP=1'
LOG_ARCHIVE_DEST_2='SERVICE=FS2 GROUP=1'
LOG_ARCHIVE_DEST_3='SERVICE=FS3 GROUP=2'
LOG_ARCHIVE_DEST_4='SERVICE=FS4 GROUP=2'関連項目:
LOCATIONおよびSERVICE
各宛先にはLOCATION属性またはSERVICE属性を指定して、REDO転送サービスがローカル・ディスクのディレクトリまたはリモート・データベースの宛先のどちらにREDOデータを転送できるかを明示する必要があります。 
                  
LOG_ARCHIVE_DEST_1からLOG_ARCHIVE_DEST_10の宛先は、LOCATION属性またはSERVICE属性を含むことができます。
                  
LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31の宛先は、SERVICE属性しか含むことができません。
                  
| カテゴリ | LOCATION=local_disk_directoryまたはUSE_DB_RECOVERY_FILE_DEST | SERVICE=net_service_name | 
|---|---|---|
| データ型 | 文字列値 | 文字列値 | 
| 有効な値 | 該当なし | 該当なし | 
| デフォルト値 | なし | なし | 
| 必須属性 | 該当なし | 該当なし | 
| 属性との競合 | 
 | 
 | 
| 対応先 | 
 | 
 | 
使用上のノート
- 
                           LOCATIONまたはSERVICE属性を指定する必要があります。デフォルトはありません。
- 
                           LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31パラメータでは、LOCATION属性はサポートされません。
- 
                           複数の属性を指定している場合は、属性のリストの最初に LOCATION属性またはSERVICE属性を指定します。
- 
                           LOCATION属性で少なくとも1つのローカル・ディスクのディレクトリを指定する必要があります。これにより、データベースのメディア・リカバリが必要になる場合、ローカルのアーカイブREDOログ・ファイルに確実にアクセスできるようになります。ローカルまたはリモートの追加宛先は最大30個まで指定できます。
- 
                           LOCATION属性には、次のいずれかを指定できます。- 
                                 LOCATION=local_disk_directoryこれは、データベースを置くシステム上のディスク・ディレクトリの一意のディレクトリ・パス名を指定します。これは、アーカイブREDOログ・ファイルのローカル宛先です。 
- 
                                 LOCATION=USE_DB_RECOVERY_FILE_DEST高速リカバリ領域を構成するには、 DB_RECOVERY_FILE_DEST初期化パラメータを使用して、高速リカバリ領域として機能するディレクトリまたはOracle Storage Managerのディスク・グループを指定します。
 
- 
                                 
- 
                           SERVICE属性を指定する場合は、次のようにします。- 
                                 SERVICE属性と、REDOデータの送信先となるリモートOracleデータベース・インスタンスを識別する有効なOracle Netサービス名(SERVICE=net_service_name)を指定して、リモート宛先を識別します。SERVICE属性で指定するOracle Netサービス名は、リモート・データベースへの接続に必要な情報を含む接続記述子に変換されます。関連項目: Oracle Netサービス名の設定の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 
- 
                                 リモート宛先にREDOデータを転送するには、着信するアーカイブREDOデータを受け取るために、ネットワーク接続と、リモート宛先に対応付けられたOracleデータベース・インスタンスが必要です。 
 
- 
                                 
- 
                           LOCATIONおよびSERVICE属性の現行の設定を確認するには、V$ARCHIVE_DEST固定ビューを問い合せます。- 
                                 TARGET列は、宛先がプライマリ・データベースにとってローカルかリモートかを示します。
- 
                                 DESTINATION列は、宛先に指定されている値を示します。たとえば、宛先パラメータ値は、アーカイブREDOログ・ファイルが配置されているリモートのOracleインスタンスを示すOracle Netサービス名を指定します。
 
- 
                                 
例
次の例は、LOCATION属性の指定方法を示しています。
LOG_ARCHIVE_DEST_2='LOCATION=/disk1/oracle/oradata/payroll/arch/' LOG_ARCHIVE_DEST_STATE_2=ENABLE
次の例は、SERVICE属性の指定方法を示しています。
                     
LOG_ARCHIVE_DEST_3='SERVICE=stby1' LOG_ARCHIVE_DEST_STATE_3=ENABLE
MANDATORY
MANDATORY属性は、書き込まれたオンライン・ログ・ファイルが再使用できるためには、その前に宛先に正常にアーカイブされる必要があることを指定します。
                  
| カテゴリ | MANDATORY | 
|---|---|
| データ型 | キーワード | 
| 有効な値 | 該当なし | 
| デフォルト値 | 該当なし | 
| 必須属性 | 該当なし | 
| 属性との競合 | オプション | 
| 対応先 | 
 | 
使用上のノート
- 
                           LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31パラメータでは、MANDATORY属性はサポートされません。
- 
                           MANDATORYが指定されていない場合、デフォルトでは、宛先はオプションとみなされます。すべての宛先がオプションである場合にも、最低1つの宛先は成功する必要があります。オプションの宛先へのアーカイブが失敗した場合、オンラインREDOログ・ファイルは再利用可能なままで、最終的に上書きされる可能性があります。しかし、必須の宛先へのアーカイブ操作が失敗した場合、オンラインREDOログ・ファイルは上書きされません。 
- 
                           LOG_ARCHIVE_MIN_SUCCEED_DEST=nパラメータ(nは1から10の整数)は、オンラインREDOログ・ファイルを上書きできるようになる前に、正常にアーカイブしておく必要がある宛先の数を指定します。LOG_ARCHIVE_MIN_SUCCEED_DEST=nの件数は、すべてのMANDATORYの宛先とオプションのローカル宛先によって満たされます。LOG_ARCHIVE_MIN_SUCCEED_DESTパラメータに設定した値が一致すると、オンラインREDOログ・ファイルは再利用可能になります。たとえば、次のようにパラメータを設定できます。# Database must archive to at least two locations before # overwriting the online redo log files. LOG_ARCHIVE_MIN_SUCCEED_DEST = 2 
- 
                           1つ以上のローカル宛先が必要であり、それらに MANDATORYを宣言するか、またはオプションのままにしておくことができます。LOG_ARCHIVE_MIN_SUCCEED_DESTパラメータの最小値は1のため、最低1つのローカル宛先が操作上必須です。
- 
                           必須の宛先のいずれかに障害が発生すると、 LOG_ARCHIVE_MIN_SUCCEED_DESTパラメータは不適切になります。
- 
                           LOG_ARCHIVE_MIN_SUCCEED_DESTパラメータ値を、必須の宛先数にオプションのローカル宛先数を加えた数よりも大きく設定することはできません。
- 
                           V$ARCHIVE_DEST固定ビューのBINDING列は、アーカイブ操作に障害がどのように影響するのかを指定します。
例
次の例は、MANDATORY属性を示しています。
                     
LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest MANDATORY' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_3='SERVICE=denver MANDATORY' LOG_ARCHIVE_DEST_STATE_3=ENABLE
MAX_FAILURE
MAX_FAILURE属性は、プライマリ・データベースが失敗した宛先を放棄する前に、REDO転送サービスが通信を再確立してその宛先へのREDOデータを転送するログ・スイッチ時の連続試行回数を制御します。
                  
| カテゴリ | MAX_FAILURE=count | 
|---|---|
| データ型 | 数値 | 
| 有効な値 | >=0 | 
| デフォルト値 | デフォルトのグループ宛先のデフォルト値は0です。デフォルト以外のログ・アーカイブ先のグループ宛先のデフォルト値は1です。 | 
| 必須属性 | 
 | 
| 属性との競合 | なし | 
| 対応先 | 
 | 
MAX_FAILUREの使用上のノート
一定の間隔でアーカイブ先がチェックされ、アーカイブ先をアクティブ化する必要があるかどうかが判断されます。アーカイブ先がチェックされるシナリオは次のとおりです。
- 
                           
                           代替の場所が設定されていないスタンドアロンのアーカイブ先 アーカイブ先が LOG_ARCHIVE_DEST_nを使用して構成され、ALTERNATE属性が設定されていない場合:- MAX_FAILUREが1に設定されている場合、このアーカイブ先で障害が発生しても再アクティブ化は試行されません。
- MAX_FAILURE> 1の場合、連続する失敗の回数が- MAX_FAILUREの値と等しくなるまで、再アクティブ化が試行されます。この数に達すると、アーカイブ先の再アクティブ化はこれ以上試行されません。
- MAX_FAILUREが0の場合、再アクティブ化の試行は連続して行われます。
 
- 
                           
                           それぞれが他方の代替場所であるアーカイブ先のペア LOG_ARCHIVE_DESTINATION_1およびLOG_ARCHIVE_DESTINATION_2パラメータを使用して構成されたアーカイブ先が2つあるとします。LOG_ARCHIVE_DESTINATION_1パラメータのALTERNATE属性はLOG_ARCHIVE_DESTINATION_2に設定され、LOG_ARCHIVE_DESTINATION_2の場合はLOG_ARCHIVE_DESTINATION_1に設定されます。優先宛先の状態はENABLEに設定され、他のアーカイブ先はALTERNATEに設定されます。- 
                                 
                                 優先宛先の MAX_FAILUREの値がゼロに設定されている場合、代替宛先はアクティブ化されません。代替宛先をアクティブ化する機能が無効になるため、優先宛先の MAX_FAILUEをゼロに設定することはお薦めしません。
- 優先宛先のMAX_FAILUREの値がゼロ以外の値に設定されている場合、優先宛先にMAX_FAILURE障害が発生した後にアーカイブ先がアクティブ化されます。この時点で、優先宛先が代替宛先として割り当てられます。優先宛先がALTERNATE状態の間は、REOPENの値に関係なく、優先宛先の再アクティブ化が試行されます。
 非優先の代替場所がアクティブ化された後の動作は、スタンドアロンのアーカイブ場所と同様ですが、次の点が異なります。 - 再アクティブ化の試行中に優先宛先がアクティブ化された場合、非優先宛先はALTERNATE状態に指定されます。
- 非優先宛先がMAX_FAILUREに達すると、両方のアーカイブ先が無効になり、それ以上の再アクティブ化は試行されません。
 
- 
                                 
                                 
- 
                           
                           アーカイブ先のチェーン LOG_ARCHIVE_DEST_1、LOG_ARCHIVE_DEST_2およびLOG_ARCHIVE_DEST_3パラメータを使用して構成された3つのアーカイブ先の例を考えてみます。LOG_ARCHIVE_DEST_2はLOG_ARCHIVE_DEST_1の代替宛先で、LOG_ARCHIVE_DEST_3はLOG_ARCHIVE_DEST_2の代替場所です。LOG_ARCHIVE_DEST_3には代替の場所はありません。LOG_ARCHIVE_DEST_1およびLOG_ARCHIVE_DEST_2のMAX_FAILURE属性の値は、ゼロ以外の値に設定する必要があります。そうしないと、LOG_ARCHIVE_DEST_1またはLOG_ARCHIVE_DEST_2が失敗した場合、MAX_FAILUREがゼロであるため、その代替宛先はアクティブ化されず、宛先の再アクティブ化は継続的にチェックされます。LOG_ARCHIVE_DEST_1のMAX_FAILURE値に達すると、LOG_ARCHIVE_DEST_2がアクティブ化されます。LOG_ARCHIVE_DEST_2がMAX_FAILUREに達すると、LOG_ARCHIVE_DEST_3がアクティブ化されます。LOG_ARCHIVE_DEST_3の動作は、スタンドアロンのアーカイブ先の動作と同じです。
- 
                           
                           グループ内のアーカイブ先 複数のログ・アーカイブ先を含むログ・アーカイブ・グループを考えてみます。各アーカイブ先には、1から8の優先度があります。グループ内のすべてのアーカイブ先では、 MAX_FAILURE属性をゼロ以外の値に設定する必要があります。優先度が最も高い代替宛先が最初にアクティブ化されます。使用可能な優先度が最も高い代替宛先が複数ある場合は、そのいずれかが選択されます。優先度8が最も優先度が高く機能するアーカイブ先になると、優先度8のすべてのアーカイブ先がアクティブ化されます。 現在アクティブな宛先に障害が発生した場合は、残りの宛先の中で最も優先度の高い宛先がアクティブ化されます。優先度8の宛先がアクティブ化された場合は、特殊なケースになります。 REOPEN属性に設定された値に関係なく、現在アクティブなアーカイブ先よりも優先度の高いすべての代替宛先で、定期的に再アクティブ化がチェックされます。優先度の高いアーカイブ先が機能するようになった場合、そのアーカイブ先はアクティブ化され、現在アクティブなアーカイブ先はALTERNATE状態になります。
Oracle Database 12cリリース2 (12.2)でのMAX_FAILUREの使用上のノート
- 
                           新しい GROUP属性とPRIORITY属性を使用するREDO宛先では、エラー件数がMAX_FAILURE属性に指定された値に達した場合、宛先はERROR状態になり、アクセス可能になるまでその状態を継続します。これは、REOPEN属性に指定された値に応じて定期的にチェックされます。
- 
                           ログ・アーカイブ・グループのデフォルト宛先(新しい GROUP属性とPRIORITY属性を使用しないそのREDO宛先)では、MAX_FAILURE属性の動作はOracle Database 12cリリース1 (12.1.0.1)の場合と同じです
例
次の例では、REDO転送サービスが障害の発生した宛先へのログ・スイッチ時に、各ログ・スイッチの間隔が5秒を超えているかぎり最大3回までの再接続を連続再試行できます。3回目の試行後アーカイブ操作に失敗すると、その宛先はREOPEN属性が指定されていないものとして扱われ、リセットされるまで永久障害としてマークされます。
                     
LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=5 MAX_FAILURE=3' LOG_ARCHIVE_DEST_STATE_1=ENABLE
NET_TIMEOUT
NET_TIMEOUT属性は、REDO転送先に送信されたREDOデータの確認待ちをLGWRバックグラウンド・プロセスがブロックする時間を秒数で指定します。 
                  
確認がNET_TIMEOUTの秒数内に受信されない場合は、エラーがログに記録され、その宛先へのREDO転送セッションは終了します。
                  
| カテゴリ | NET_TIMEOUT=seconds | 
|---|---|
| データ型 | 数値 | 
| 有効な値 | 1脚注3から1200 | 
| デフォルト値 | 30秒 | 
| 必須属性 | 
 | 
| 属性との競合 | 
 | 
| 対応先 | プライマリ・データベースの | 
脚注3
最小値は1秒に設定できますが、一時的なネットワーク・エラーによるスタンバイ・データベースからの切断を回避するために、最小値は8から10秒に設定することをお薦めします。
使用上のノート
- 
                           NET_TIMEOUT属性はオプションです。ただし、NET_TIMEOUT属性を指定しないと30秒に設定されますが、プライマリ・データベースが停止する可能性があります。この状況を回避するには、NET_TIMEOUT属性に0(ゼロ)以外の小さい値を指定することによって、ネットワーク・サーバーからのステータスを待機する際、ユーザーが指定したタイムアウト時間の期限が切れた後に、プライマリ・データベースが操作を続行できます。
- 
                           Oracle Database 12cリリース12.2 (12.2.0.1)より、すべての同期スタンバイ宛先に対してグローバルな、データベース初期化パラメータ DATA_GUARD_SYNC_LATENCYがあります。少なくとも1つの同期スタンバイがREDOの受信を確認した後、後続の宛先を切断するまで、プライマリ・データベースが待機できる最大時間(秒単位)を定義します。『Oracle Databaseリファレンス』を参照してください。
例
次の例は、NET_TIMEOUT属性を使用して、プライマリ・データベースのネットワーク・タイムアウト値を10秒に指定する方法を示しています。
                     
LOG_ARCHIVE_DEST_2='SERVICE=stby1 SYNC NET_TIMEOUT=10' LOG_ARCHIVE_DEST_STATE_2=ENABLE
NOREGISTER
NOREGISTER属性は、アーカイブREDOログ・ファイルの場所が対応する宛先に記録されないことを示します。
                  
| カテゴリ | NOREGISTER | 
|---|---|
| データ型 | キーワード | 
| 有効な値 | 該当なし | 
| デフォルト値 | 該当なし | 
| 必須属性 | 
 | 
| 属性との競合 | 
 | 
| 対応先 | 
 | 
使用上のノート
- 
                           NOREGISTER属性は、スタンバイ・データベースの宛先がOracle Data Guard構成の一部である場合はオプションです。
- 
                           NOREGISTER属性は、宛先がOracle Data Guard構成の一部でない場合は必須です。
- 
                           これは、リモートの宛先のみの属性です。各アーカイブREDOログ・ファイルの位置は、常にプライマリ・データベースの制御ファイルに記録されます。 
- 
                           
                           この属性は、ダウンストリームGoldenGateマイニング設定のないOracle Data Guard構成では使用しないでください。このシナリオで NOREGISTERを使用すると、スイッチオーバー操作中に問題が発生する可能性があります。
例
次の例は、NOREGISTER属性を示しています。
                     
LOG_ARCHIVE_DEST_5='NOREGISTER'
PRIORITY
PRIORITY属性は、ログ・アーカイブ先のコレクション内の優先順位を指定するために使用されます。 
                  
優先度は1から8まで番号付けされます。値が低いほど高い優先度を表します。最も低い優先順位(PRIORITY=8)は、その優先順位がアクティブな場合にその優先順位の宛先がすべてアクティブにされるという意味で特殊です。より高い優先順位の宛先がサービスに戻ると、その宛先がアクティブにされ、低い優先順位の宛先はすべて非アクティブにされます。
                  
| カテゴリ | Priority=integer | 
|---|---|
| データ型 | 整数 | 
| 有効な値 | 1から8 | 
| デフォルト値 | 1 | 
| 必須属性 | SERVICE | 
| 属性との競合 | ALTERNATE | 
| 対応先 | 該当なし | 
使用上のノート
- 
                           PRIORITY属性は常にGROUP属性とともに使用されて、グループのメンバー(REDO宛先)の規則正しい有効化とフォールバックを提供します。
例
次の例は、基本的な概念を説明するためのもので、示されたとおりに使用することを意図しているわけではありません。構成に応じて、DB_UNIQUE_NAMEなどの他の必須パラメータが存在する場合もあります。優先順位を定義するサンプル・ログ・アーカイブ先の設定は、次のとおりです:
                     
LOG_ARCHIVE_DEST_1='SERVICE=FS1 SYNC GROUP=1 PRIORITY=1'
LOG_ARCHIVE_DEST_2='SERVICE=FS2 SYNC GROUP=1 PRIORITY=1'
LOG_ARCHIVE_DEST_3='SERVICE=FS3 ASYNC GROUP=1 PRIORITY=2'
LOG_ARCHIVE_DEST_4='SERVICE=TS ASYNC GROUP=1 PRIORITY=3'この宣言結果の動作は、次のようになります。
- 
                           プライマリは、2つの優先遠隔同期インスタンス FS1またはFS2のいずれかに送信します。
- 
                           FS1とFS2の両方が使用不可になった場合、プライマリはFS3に送信します(この場合はASYNC経由)。
- 
                           プライマリが FS3に対して送信中にFS1またはFS2のいずれかが使用可能になった場合、プライマリはその使用可能な優先ログ・アーカイブ先にフェイルバックします。
- 
                           優先順位が高い3つのログ・アーカイブ先のすべてに障害が発生した場合、プライマリは TS(ターミナル・スタンバイ)への送信を開始します。TSへの送信中にFS1、FS2またはFS3が使用可能になった場合、プライマリは新しく使用可能になった優先順位の高いほうの宛先にスイッチされます。
REOPEN
REOPEN属性は、REDO転送サービスが失敗した宛先の再オープンを試行するまでの最小秒数を指定します。
                  
| カテゴリ | REOPEN [=seconds] | 
|---|---|
| データ型 | 数値 | 
| 有効な値 | 0秒以上 | 
| デフォルト値 | 300秒 | 
| 必須属性 | なし | 
| 属性との競合 | 
 | 
| 対応先 | 
 | 
使用上のノート
- 
                           REOPEN属性はオプションです。
- 
                           REDO転送サービスは、失敗した宛先の再オープンをログ・スイッチ時に試行します。 
- 
                           REDO転送サービスは、最後のエラーの時刻に REOPEN間隔を加算した時刻が現在の時刻より小さいかどうかをチェックします。その場合、REDO転送サービスは宛先の再オープンを試行します。
- 
                           REOPENは、接続障害のみでなく、すべてのエラーに適用されます。エラーには、ネットワーク障害、ディスク・エラー、クオータ例外などがありますが、これらに制限されません。
- 
                           オプションの宛先に REOPENを指定すると、エラーが発生した場合にOracleデータベースでオンラインREDOログ・ファイルを上書きできます。MANDATORY宛先にREOPENを指定すると、REDO転送サービスは、REDOデータを正常に転送できない場合にプライマリ・データベースを停止します。この場合には、次のオプションを考慮します。- 
                                 宛先を遅延させる、宛先をOPTIONALとして指定する、または SERVICE属性値を変更することで宛先を変更。
- 
                                 代替宛先の指定。 
- 
                                 宛先の無効化。 
 
- 
                                 
例
次の例は、REOPEN属性を示しています。
                     
LOG_ARCHIVE_DEST_3='SERVICE=stby1 MANDATORY REOPEN=60' LOG_ARCHIVE_DEST_STATE_3=ENABLE
SYNCおよびASYNC
SYNCおよびASYNC属性は、使用するREDO転送モードが同期(SYNC)なのか、非同期(ASYNC)なのかを指定します。
                  
| カテゴリ | SYNC | ASYNC | 
|---|---|---|
| データ型 | キーワード | キーワード | 
| 有効な値 | 該当なし | 該当なし | 
| デフォルト値 | 該当なし | なし | 
| 必須属性 | なし | なし | 
| 属性との競合 | 
 | 
 | 
| 対応先 | 
 | 
 | 
使用上のノート
- 
                           LOG_ARCHIVE_DEST_11からLOG_ARCHIVE_DEST_31パラメータでは、SYNC属性はサポートされません。
- 
                           トランザクションをコミットするには、 SYNC属性が指定されている使用可能な各宛先で、そのトランザクションによって生成されたREDOデータを受信しておく必要があります。
- 
                           プライマリ・データベースおよびロジカル・スタンバイの、宛先1から10のデフォルトは ASYNC(リアルタイム・カスケード)に設定されます。フィジカル・スタンバイ、スナップショット・スタンバイ、および遠隔同期インスタンスの、宛先1から10のデフォルトは ARCH転送モードに設定されます。(ARCH属性は非推奨です。この状況でARCHを使用することは、単にリアルタイムでないカスケードを示します。)宛先11から31のデフォルトは常に ASYNCに設定されます。
- LGWR属性を指定したがSYNC属性もASYNC属性も指定しなかった場合、デフォルトはSYNCです。
関連項目:
- 
                              LOG_ARCHIVE_DEST_n非推奨属性の詳細は、『Oracle Databaseリファレンス』を参照してください。
例
次の例は、SYNC属性が指定されているLOG_ARCHIVE_DEST_nパラメータを示しています。
                     
LOG_ARCHIVE_DEST_3='SERVICE=stby1 SYNC' LOG_ARCHIVE_DEST_STATE_3=ENABLE
TEMPLATE
TEMPLATE属性は、宛先でアーカイブされたREDOログの名前について、ディレクトリ仕様と書式テンプレートを定義します。 
                  
このテンプレートは、REDO宛先のLOG_ARCHIVE_FORMAT初期化パラメータにより定義されたデフォルトのファイル名書式とは異なるファイル名を生成するために使用されます。
                  
| カテゴリ | TEMPLATE=filename_template_%t_%s_%r | 
|---|---|
| データ型 | 文字列値 | 
| 有効な値 | 該当なし | 
| デフォルト値 | なし | 
| 必須属性... | 
 | 
| 属性との競合 ... | 
 | 
| 対応先 ... | 
 | 
使用上のノート
- 
                           TEMPLATE属性はオプションです。TEMPLATEが指定されていない場合、アーカイブされたREDOログには、LOG_ARCHIVE_FORMAT初期化パラメータの値を使用して名前が付けられます。
- 
                           TEMPLATE属性は、リモート・アーカイブ先でLOG_ARCHIVE_FORMAT初期化パラメータ設定をオーバーライドします。
- 
                           TEMPLATE属性は、リモート宛先(SERVICE属性で指定された宛先)でのみ有効です。
- 
                           表17-1で説明されているとおり、 filename_templateに指定した値には、%s、%t、および%rディレクティブが必要です。表17-1 TEMPLATE属性のディレクティブ ディレクティブ 説明 %t インスタンス・スレッド番号を置換します。 %T 0(ゼロ)を埋め込んだインスタンス・スレッド番号を置換します。 %s ログ・ファイル順序番号を置換します。 %S 0(ゼロ)を埋め込んだログ・ファイル順序番号を置換します。 %r リセットログIDを置換します。 %R 0(ゼロ)を埋め込んだリセットログIDを置換します。 
- 
                           filename_template値は宛先に送信され、そこでファイル名を作成する前に、変換および検証されます。 
VALID_FOR
VALID_FOR属性には、REDOデータを宛先に書き込むかどうかを指定します。
                  
次の要因について考えてみます。
- 
                        データベースがプライマリ・ロールとスタンバイ・ロールのどちらで現在実行されているか 
- 
                        オンラインREDOログ・ファイルまたはスタンバイREDOログ・ファイル(あるいはその両方)が、現在この宛先のデータベースでアーカイブされているかどうか 
| カテゴリ | VALID_FOR=(redo_log_type, database_role) | 
|---|---|
| データ型 | 文字列値 | 
| 有効な値 | 該当なし | 
| デフォルト値 | 
 | 
| 必須属性 | なし | 
| 属性との競合 | なし | 
| 対応先 | 
 | 
使用上のノート
- 
                           VALID_FOR属性はオプションです。ただし、Oracle Data Guard構成内の各データベースでREDO転送先ごとにVALID_FOR属性を指定し、構成内のスタンバイ・データベースへのロール推移後もREDO転送が続行されるようにすることをお薦めします。
- 
                           LOG_ARCHIVE_DEST_n宛先ごとにこれらの要因を構成するには、キーワードのペア(VALID_FOR=(redo_log_type,database_role))を使用してこの属性を指定します。- 
                                 redo_log_typeキーワードは、次のいずれかをアーカイブする場合に有効な宛先を識別します。 - 
                                       ONLINE_LOGFILE—この宛先は、オンラインREDOログ・ファイルをアーカイブする場合のみ有効です。
- 
                                       STANDBY_LOGFILE—この宛先は、スタンバイREDOログ・ファイルをアーカイブする場合のみ有効です。
- 
                                       ALL_LOGFILES— この宛先は、オンラインREDOログ・ファイルまたはスタンバイREDOログ・ファイルをアーカイブする場合に有効です。
 
- 
                                       
- 
                                 database_roleキーワードは、この宛先がアーカイブに有効なロールを識別します。 - 
                                       PRIMARY_ROLE—この宛先は、データベースがプライマリ・ロールで実行されている場合のみ有効です。
- 
                                       STANDBY_ROLE—この宛先は、データベースがスタンバイ・ロールで実行されている場合のみ有効です。
- 
                                       ALL_ROLES—この宛先は、データベースがプライマリ・ロールまたはスタンバイ・ロールで実行されている場合に有効です。
 
- 
                                       
 
- 
                                 
- 
                           宛先に VALID_FOR属性を指定しないと、データベースがプライマリ・ロールまたはスタンバイ・ロールで稼働しているかどうかに関係なく、デフォルトで、オンラインREDOログ・ファイルとスタンバイREDOログ・ファイルのアーカイブが宛先で有効になります。このデフォルトの動作は、VALID_FOR属性で(ALL_LOGFILES,ALL_ROLES)キーワード・ペアを設定した場合と同様です。
- 
                           VALID_FOR属性を使用すると、同じ初期化パラメータ・ファイルをプライマリ・ロールとスタンバイ・ロールの両方に使用できます。
例
次の例は、VALID_FORのデフォルトのキーワードのペアを示します。
                     
LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata VALID_FOR=(ALL_LOGFILES, ALL_ROLES)'
このデータベースがプライマリ・ロールまたはスタンバイ・ロールで稼働している場合、宛先1は、すべてのログ・ファイルをローカル・ディレクトリ/disk1/oracle/oradataにアーカイブします。