| Oracle Fusion Middleware Oracle Internet Directory管理者ガイド 11g リリース1(11.1.1) B55919-02 |
|
 前 |
 次 |
| Oracle Fusion Middleware Oracle Internet Directory管理者ガイド 11g リリース1(11.1.1) B55919-02 |
|
前 |
次 |
この付録では、レプリケーションに関する詳細情報について説明します。この付録には、次の項があります。
|
注意: この付録で言及するOracle Single Sign-Onはすべて、Oracle Single Sign-On 10g(10.1.4.3.0)以上のことです。 |
Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションでは、レプリケーション承諾がなされたOracle Internet Directoryノード間における更新情報の転送は、Oracle Databaseアドバンスト・レプリケーションのストア/フォワード転送機能によって管理されます。アドバンスト・レプリケーションを使用すると、2つのOracleデータベース間で、データベース表を同期化させることができます。
Oracle Databaseアドバンスト・レプリケーション:
ローカルの変更内容を格納し、コンシューマに定期的にまとめて伝播します。コンシューマ・レプリケーション・サーバーは、リモートの変更内容をサーバー固有のローカルのディレクトリ・サーバーに適用し、ローカル・ストアから適用済のリモートの変更内容をパージします。
Oracleレプリケーション・グループ内のどこにあるディレクトリ表に対しても読取りおよび更新アクセスできるようにします。一般的なアドバンスト・レプリケーション構成では、行レベル・レプリケーションが使用されます。
実証済のネットワーク・トレランスを提供します。データ転送を制御および監視できます。このような管理機能によって、データ移送のスケジュール方法に高度な柔軟性を与えることができます。
|
注意: Oracle Internet Directoryと同じデータベース内に常駐するOracle Single Sign-Onのデータベース・スキーマも、アドバンスト・レプリケーションを使用してレプリケートします。 |
|
関連項目:
|
一般的なOracle Databaseアドバンスト・レプリケーション構成では、サプライヤが変更内容を変更ログに書き込み、バッチ処理された変更を他のコンシューマに定期的に送信する非同期データ伝播を使用します。コンシューマは変更ログ・データを受信し、変更内容をローカルに適用します。
レプリケーションを構成する場合は、レプリケーション・グループ内で変更を共有するノードを指定します。レプリケーション環境に導入するノードの数にかかわらず、レプリケーションの基本アーキテクチャは同一です。ローカル変更がリモート・マスター・サイトに配布されると、クライアントとして機能するレプリケーション・サーバーによってOracle Internet Directoryサーバーにコマンドが送信され、ここでコマンドが実装されます。
図D-1とその後に続く説明では、Oracle Databaseアドバンスト・レプリケーション・プロセスの概要を示します。
プロセスは次のとおりです。
レプリカAのOracle Internet Directoryサーバーで変更リクエストが作成されます。
変更は、受け入れられ、Oracle Internet Directoryデータベースのストレージにコミットされます。
2' この操作に対して新規の変更ログが生成され、ods_chg_log表(server = レプリカA)に格納されます。
レプリカA上のレプリケーション・サーバーは、ローカルのods_chg_log表に新規のアウトバウンド変更ログを問い合せます。この問合せには次のフィルタが使用されます。
(& (objectclass=changeLogEntry) (servername=ReplicaID_of_A) (changeNumber>= Last_Applied_ChgNum_From_A_TO_A) )
この検索操作とともに、処理承諾で指定されたorclreplicationidの値で制御も渡されます。値1は、アドバンスト・レプリケーション承諾のために予約されています。
Last_Applied_ChgNum_From_A_TO_Aは、アウトバウンド変更ログ処理ステータスです。
3' ディレクトリ・サーバーは、ods_chg_logに新規の変更ログを内部的に問い合せて、フェッチした変更ログを返します。
ods_chg_logから取得した新規の変更ログは、ローカルのasr_chg_logにコピーされます。
4' レプリケーション・サーバーは、取得した変更ログをローカルのasr_chg_logにコピーします。
レプリケーション・サーバーは、Oracle Internet Directoryサーバーに対して、変更ログretry_cntのステータスを正しく更新するようにリクエストします。
5' Oracle Internet Directoryサーバーは、ods_chg_log表にある変更ログのretry_cntを更新します。
新規の変更ログは、Oracle Databaseアドバンスト・レプリケーションを介して、レプリカAからレプリカBに送信されます。
レプリカBにおいて、前回移送された数が前回適用された変更の数より大きい場合は、ローカル変更ログ・ストアasr_chg_logに新規の変更があることを示しています。この場合、レプリカB上のレプリケーション・サーバーは、ローカルのasr_chg_log表に新規のインバウンド変更ログを問い合せます。次のフィルタが使用されます。
(& (objectclass=changeLogEntry) (servername=ReplicaID_of_A) (changeNumber>= Last_Applied_ChgNum_From_A_TO_B))
7' ディレクトリ・サーバーは、asr_chg_logに新規の変更ログを問い合せます。
レプリケーション・サーバーは、レプリカBで新規の変更を適用します。
レプリカBのOracle Internet Directoryサーバーは、変更を受け入れ、Oracle Databaseのストレージにコミットします。
9' ローカル・レプリカにLDAPベースのコンシューマ・レプリカがある場合、変更ログがレプリカBにあるods_chg_log表で、次の規則に従って再生成されます。
server = server of local replica,
ReplicaB orclreplicationid/chg_rid = 1
Modifiersname = Replbind_DN_of_A
orclreplicatid/chg_ridは、処理承諾のorclreplicationidの値に設定されます。この場合、変更がアドバンスト・レプリケーションを介してレプリケートと処理が行われるため、値はアドバンスト・レプリケーション用に予約されている1に設定されます。
レプリケーション・サーバーは、Oracle Internet Directoryサーバーに対して、シャドウ変更ログretry_cntのステータスを正しく更新するようにリクエストします。
10' Oracle Internet Directoryサーバーは、データベースにあるシャドウ変更ログのretry_cntを更新します。
適用済のエントリや候補の変更に従って削除されたエントリのパージが定期的に発生します。ローカルの変更ログ表にあるリモート変更の記録は、その変更がローカルで適用されると、ガベージ・コレクション・スレッドによってパージされます。ローカルの変更ログ表にあるローカル変更の記録は、その変更がすべてのコンシューマに配布されると、ガベージ・コレクション・スレッドによってパージされます。
この項では、LDAPレプリケーションの詳細を説明します。LDAPレプリケーションでのデータ・フローは、転送と適用の2つのフェーズで構成されます。
図D-2およびその後に続く説明で、ファンアウト・レプリケーション・プロセスを示します。
LDAP変更リクエストが、レプリカAのOracle Internet Directoryサーバーで作成されます。
変更は、受け入れられ、Oracle Internet Directoryデータベースのストレージにコミットされます。
2'.この操作に対して新規の変更ログが生成され、ods_chg_log表に格納されます。
server = レプリカA
orclreplicationid/chg_rid = 0(値0はユーザー操作)
Modifiersname = 修飾子のユーザー識別名(デフォルト)
レプリカB上のレプリケーション・サーバーは、サプライヤのレプリカ、レプリカAのods_chg_log表に新規のインバウンド変更ログを問い合せます。この問合せには次のフィルタが使用されます。
(& (objectclass=changelogentry) (changeNumber>=Last_Transported_ChgNum_From_A_TO_B) (! (modifiersname=ReplicaID_of_B)) (! (orclreplicatonid = Orclreplicationid_Attribute_Value_of_Processing_Agreement)) (!(targetdn=*,excluded_naming_ctx_dn ) (….) (….) ….) (targetdn=cn=catalogs) (targetdn=cn=subschemasubentry) (targetdn=cn=oracleschemaversion) (targetdn=*,included_naming_ctx_dn) (targetdn=….) …)
この検索操作とともに、処理承諾で指定されたorclreplicationidの値で制御も渡されます。
レプリカBのレプリケーション・サーバーは、レプリカBのOracle Internet Directoryに新規の変更ログをシャドウ変更ログとして格納するようにリクエストします。
4'.レプリカBのOracle Internet Directoryサーバーは、レプリカBのasr_chg_log表にシャドウ変更ログを格納します。
手順3、3'および4は、LDAPベース変更ログ処理の転送部分と一致します。
レプリカBのレプリケーション・サーバーは、レプリカBにおいて、前回移送された数が前回適用された変更の数より大きいかどうかをチェックします。そうである場合は、ローカル変更ログ・ストアasr_chg_logに新規の変更があることを示しています。この場合、レプリカBのレプリケーション・サーバーは、ローカル・ストアasr_chg_logにAからの新規変更ログを問い合せます。この問合せには次のフィルタが使用されます。
(& (objectclass=changeLogEntry) (servername=ReplicaID_of_A) (changeNumber>= Last_Applied_ChgNum_From_A_TO_B))
レプリカBのレプリケーション・サーバーは、レプリカBのOracle Internet Directoryサーバーに取得した変更をストレージに適用するようにリクエストします。
レプリカBのOracle Internet Directoryサーバーは、変更を受け入れ、Oracle Internet Directoryデータベースのストレージにコミットします。
7' ローカルのレプリカがその他のレプリカのソースである場合、レプリカBのods_chg_log表に変更ログが、次の変更ログ再生成規則に従って再生成されます。
server = server of local replica, ReplicaB
orclreplicationid/chg_rid = N
Modifiersname = Replbind_DN_of_A
orclreplicatid/chg_ridは、処理承諾のorclreplicationid値に設定されます。
レプリケーション・サーバーは、サーバーに対して、シャドウ変更ログretry_cntのステータスを正しく更新するようにリクエストします。
この項では、LDAPベースのレプリケーションのレプリカ状態について説明します。LDAPのレプリカ状態は、アドバンスト・レプリケーションには影響しません。
LDAPベースのレプリケーションを構成し、レプリケーション・サーバーを起動すると、サーバーはローカルのレプリカ(orclreplicaid=local_Replica_ID, cn=replication configuration)からレプリカ状態orclreplicastateを読み取ります。表D-1に示すとおり、レプリケーション・サーバーの動作はローカルのレプリカ状態によって異なります。レプリケーション・サーバーは、ローカル(コンシューマ)・ノードからローカルのレプリカ状態を読み取ります。
|
注意: WindowsシステムではorclReplicaStateの値を0に変更してブートストラップを有効にする前に、レプリケーション・サーバーが稼働していないことを確認します。 |
表D-1 LDAPのレプリカ状態
| 値 | 意味 | サーバーの動作 |
|---|---|---|
|
0 |
ブートストラップ |
レプリケーションのネーミング・コンテキスト構成に基づき、サプライヤからコンシューマ・ディレクトリを同期化するためのレプリケーションのブートストラップ・プロセスを開始する。ブートストラップの進行に合せてレプリカ状態を更新する。
|
|
1 |
オンライン |
通常のレプリケーション・プロセスを開始し、サプライヤからコンシューマへ変更をレプリケートする。 |
|
2 |
オフライン |
エラー・メッセージを、次のようにoidrepld.logに記録する。 2004/09/24:17:41:44 * Replica(dlsun1418_replica2) is in OFFLINE mode, Please update the replica state and restart OIDREPLD... 管理者は、レプリカ状態を適切に設定し、レプリケーション・サーバーを再起動する必要がある。 |
|
3 |
ブートストラップ進行中 |
レプリカ状態を0(ブートストラップ)に戻し、状態が0である場合と同様に、ブートストラップを再度開始する。 |
|
4 |
ブートストラップ進行中、 |
レプリカ状態を0(ブートストラップ)に戻し、状態が0である場合と同様に、ブートストラップを再度開始する。 |
|
5 |
ブートストラップの完了。1つ以上のネーミング・コンテキストで障害を検出。 |
エラー・メッセージを、次のようにoidrepld.logに記録する。 2004/09/24:17:13:30 * Replication BOOTSTRAP_ERROR mode detected for replica(dlsun1418_replica2) 次に、レプリカ状態が適切にリセットされるまで待機する。 |
|
6 |
データベース・コピー・ベースのaddnode。 |
このモードは、レプリカがデータベース・コピー・ベースのaddnodeであることを示す。 |
|
7 |
スキーマの同期化 |
サプライヤからコンシューマへの、データではなくスキーマの同期化。 |
|
8 |
スキーマを同期化しないブートストラップ |
以前にスキーマの同期化が実行されているものの、後続の手順でブートストラップが失敗している場合には、スキーマの同期化を再実行せずに再度ブートストラップが開始される。 |
Oracle Internet Directoryレプリケーション・サーバーでは、Oracle Internet Directoryレプリケーション・サーバー・ログ($ORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidrepld00.log)にブートストラップ・プロセスが記録されます。
ブートストラップが正常に完了した場合、ログは次の例と同様になり、レプリケーション・サーバーが自動的に通常のレプリケーション・プロセスを開始します。
2004/10/06:17:13:25 * Starting OIDREPLD against isunnad03:5555... 2004/10/06:17:13:26 * Starting scheduler... 2004/10/06:17:13:27 * Start to BootStrap from supplier=isunnad03_purify to consumer=isunnad03_purify3 2004/10/06:17:13:28 * gslrbssSyncDIT:Replicating namingcontext=cn=oraclecontext ...... 2004/10/06:17:14:21 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oraclecontext, 222 entries matched 2004/10/06:17:14:21 * gslrbssSyncDIT:Replicating namingcontext=c=india ...... 2004/10/06:17:14:21 * gslrbssSyncDIT:Sync done successfully for namingctx: c=india, 0 entries matched 2004/10/06:17:14:21 * gslrbssSyncDIT:Replicating namingcontext=c=uk ...... 2004/10/06:17:19:57 * gslrbssSyncDIT:Sync done successfully for namingctx: c=uk, 1087 entries matched 2004/10/06:17:19:57 * gslrbssSyncDIT:Replicating namingcontext=cn=oracleschemaversion ...... 2004/10/06:17:19:59 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oracleschemaversion, 10 entries matched 2004/10/06:17:20:01 * gslrbsbBootStrap: BOOTSTRAP DONE SUCCESSFULL
障害が検出された場合、ログは次の例と同様になります。
2004/09/14:12:57:23 * Starting OIDREPLD against dlsun1418:4444... 2004/09/14:12:57:25 * Starting scheduler... 2004/09/14:12:57:26 * Start to BootStrap from supplier=dlsun1418_replica to consumer=dlsun1418_replica2 2004/09/14:12:57:27 * gslrbssSyncDIT:Replicating namingcontext=cn=oraclecontext ...... 2004/09/14:12:58:21 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oraclecontext, 222 entries matched 2004/09/14:12:58:21 * gslrbssSyncDIT:Replicating namingcontext=cn=quan zhou ...... 2004/09/14:12:58:23 * BootStrap failure when adding DN=cn=Quan Zhou,server=dlsun1418_replica2,err=Constraint violation. 2004/09/14:12:58:23 * gslrbssSyncDIT:Sync failed for namingctx: cn=quan zhou, only 1 entries retrieved 2004/09/14:12:58:23 * gslrbssSyncDIT:Replicating namingcontext=cn=oracleschemaversion ...... 2004/09/14:12:58:25 * gslrbssSyncDIT:Sync done successfully for namingctx: cn=oracleschemaversion, 10 entries matched 2004/09/14:12:58:51 * gslrbsbBootStrap: Failure occurred when bootstrapping 1 out of 3 namingcontext(s) from the supplier
|
ヒント: ブートストラップの障害のトラブルシューティングには2つのオプションがあります。
|
|
注意: このとき、OidrepldはBootstrap_errorモードになっているので、コンシューマ・レプリカのレプリカ状態(orclreplicastate)をリセットする必要があります。 |
この項では、マルチマスター・レプリケーション・プロセスによるエントリの追加、削除、変更方法、および識別名と相対識別名の変更方法について紹介します。この項の内容は、次のとおりです。
ディレクトリ・レプリケーション・サーバーは、コンシューマに新規エントリを追加すると、次の変更適用プロセスを実行します。
ディレクトリ・レプリケーション・サーバーは、コンシューマ内でターゲット・エントリの親の識別名を探します。具体的には、その親の識別名に割り当てられているGlobal Unique Identifier(GUID)を探します。
親エントリが存在している場合、ディレクトリ・レプリケーション・サーバーは新規エントリの識別名を作成し、コンシューマ内にあるその親の下に新規エントリを配置します。次に、変更エントリをパージ・キューに入れます。
1回目の試行で変更エントリが正常に適用されなかった場合:
ディレクトリ・レプリケーション・サーバーは新しい変更エントリをリトライ・キューに入れ、再試行回数を指定の最大値に設定して変更適用プロセスを繰り返します。
最終試行を除いて、変更エントリが正常に適用されなかった場合:
ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに保持したまま、再試行回数を減らして、変更適用プロセスを繰り返します。
最終試行で変更エントリが正常に適用されなかった場合:
ディレクトリ・レプリケーション・サーバーは、新規エントリが既存エントリと重複していないかどうかをチェックします。
変更エントリが重複エントリの場合:
ディレクトリ・レプリケーション・サーバーは、次の競合解消規則を適用します。
作成タイムスタンプが古い方のエントリを使用します。
両方のエントリの作成タイムスタンプが同じ場合は、GUIDの小さい方のエントリを使用します。
変更エントリを使用すると、ターゲット・エントリは削除されて変更が適用され、その変更エントリがパージ・キューに入ります。
ターゲット・エントリを使用すると、変更エントリがパージ・キューに入ります。
変更エントリが重複エントリではない場合:
ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、orclHIQScheduleパラメータで指定した間隔で変更適用プロセスを繰り返します。
変更エントリが管理者操作キューに入れられた後正常に適用されない場合:
ディレクトリ・レプリケーション・サーバーは、このキューに変更を保持したまま、管理者によるアクションを待ちながら、指定した間隔で変更適用プロセスを繰り返します。管理者は、Oracle Internet Directory比較調整ツールおよび管理者操作キュー操作ツールを使用して、競合を解消できます。
ディレクトリ・レプリケーション・サーバーは、コンシューマからエントリを削除すると、次の変更適用プロセスを実行します。
ディレクトリ・レプリケーション・サーバーは、コンシューマ内で変更エントリのGUIDと一致するGUIDを持つエントリを探します。
一致するエントリがコンシューマ内にある場合、ディレクトリ・レプリケーション・サーバーはそのエントリを削除します。次に、変更エントリをパージ・キューに入れます。
1回目の試行で変更エントリが正常に適用されなかった場合:
ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに入れ、再試行回数を指定の最大値に設定して、変更適用プロセスを繰り返します。
最終試行を除いて、変更エントリが正常に適用されなかった場合:
ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに保持したまま、再試行回数を減らして、変更適用プロセスを繰り返します。
最終試行で変更エントリが正常に適用されなかった場合:
ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、指定した間隔で変更適用プロセスを繰り返します。
変更エントリが管理者操作キューに入れられた後正常に適用されない場合:
ディレクトリ・レプリケーション・サーバーは、このキューに変更エントリを保持したまま、管理者によるアクションを待ちながら、指定した間隔で変更適用プロセスを繰り返します。管理者は、Oracle Internet Directory比較調整ツールおよび管理者操作キュー操作ツールを使用して、競合を解消できます。
ディレクトリ・レプリケーション・サーバーは、コンシューマのエントリを変更すると、次の変更適用プロセスを実行します。
ディレクトリ・レプリケーション・サーバーは、コンシューマ内で変更エントリのGUIDと一致するGUIDを持つエントリを探します。
一致するエントリがコンシューマ内にある場合、ディレクトリ・レプリケーション・サーバーは、変更エントリ内の各属性と、ターゲット・エントリ内の各属性を比較します。
その後、ディレクトリ・レプリケーション・サーバーは、次の競合解消規則を適用します。
変更時間が最新の属性を使用します。
最新バージョンの属性を使用します(バージョン1、2または3など)。
ホスト上の変更された属性のうち、アルファベットのAに最も近い名前のエントリを使用します。
ディレクトリ・レプリケーション・サーバーは、フィルタ処理済の変更を適用し、変更エントリをパージ・キューに入れます。
1回目の試行で変更エントリが正常に適用されなかった場合:
ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに入れ、再試行回数を指定の最大値に設定して、変更適用プロセスを繰り返します。
最終試行を除いて、変更エントリが正常に適用されなかった場合:
ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに保持したまま、再試行回数を減らして、変更適用プロセスを繰り返します。
最終試行で変更エントリが正常に適用されなかった場合:
ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、指定した間隔で変更適用プロセスを繰り返します。
変更エントリが管理者操作キューに入れられた後正常に適用されない場合:
ディレクトリ・レプリケーション・サーバーは、このキューに変更エントリを保持したまま、管理者によるアクションを待ちながら、指定した間隔で変更適用プロセスを繰り返します。管理者は、Oracle Internet Directory比較調整ツールおよび管理者操作キュー操作ツールを使用して、競合を解消できます。
ディレクトリ・レプリケーション・サーバーは、コンシューマのエントリの相対識別名を変更すると、次の変更適用プロセスを実行します。
ディレクトリ・レプリケーション・サーバーは、コンシューマ内で変更エントリのGUIDと一致するGUIDを持つ識別名を探します。
一致するエントリがコンシューマ内にある場合、ディレクトリ・レプリケーション・サーバーはそのエントリの相対識別名を変更し、変更エントリをパージ・キューに入れます。
1回目の試行で変更エントリが正常に適用されなかった場合:
ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに入れ、再試行回数を指定の最大値に設定して、変更適用プロセスを繰り返します。
最終試行を除いて、変更エントリが正常に適用されなかった場合:
ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに保持したまま、再試行回数を減らして、変更適用プロセスを繰り返します。
最終試行で変更エントリが正常に適用されなかった場合:
ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、変更がそのターゲット・エントリと重複していないかどうかをチェックします。
変更エントリが重複エントリの場合:
ディレクトリ・レプリケーション・サーバーは、次の競合解消規則を適用します。
作成タイムスタンプが古い方のエントリを使用します。
両方のエントリの作成タイムスタンプが同じ場合は、GUIDの小さい方のエントリを使用します。
変更エントリを使用すると、ターゲット・エントリは削除されて、変更エントリが適用されパージ・キューに入ります。
ターゲット・エントリを使用すると、変更エントリがパージ・キューに入ります。
変更エントリが重複エントリではない場合:
ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、指定した間隔で変更適用プロセスを繰り返します。
変更エントリが管理者操作キューに入れられた後正常に適用されない場合:
ディレクトリ・レプリケーション・サーバーは、このキューに変更エントリを保持したまま、管理者によるアクションを待ちながら、指定した間隔で変更適用プロセスを繰り返します。管理者は、Oracle Internet Directory比較調整ツールおよび管理者操作キュー操作ツールを使用して、競合を解消できます。
ディレクトリ・レプリケーション・サーバーは、コンシューマのエントリの識別名を変更すると、次の変更適用プロセスを実行します。
ディレクトリ・レプリケーション・サーバーは、コンシューマ内で変更エントリのGUIDと一致するGUIDを持つ識別名を探します。
また、ディレクトリ・レプリケーション・サーバーは、コンシューマ内で変更エントリに指定されている新しい親のGUIDと一致するGUIDを持つ親の識別名も探します。
ターゲット・エントリの識別名と親の識別名の両方がコンシューマ内にある場合、ディレクトリ・レプリケーション・サーバーはそのエントリの識別名を変更し、変更エントリをパージ・キューに入れます。
1回目の試行で変更エントリが正常に適用されなかった場合:
ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに入れ、再試行回数を指定の最大値に設定して、変更適用プロセスを繰り返します。
最終試行を除いて、変更エントリが正常に適用されなかった場合:
ディレクトリ・レプリケーション・サーバーは変更エントリをリトライ・キューに保持したまま、再試行回数を減らして、変更適用プロセスを繰り返します。
最終試行で変更エントリが正常に適用されなかった場合:
ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、変更がそのターゲット・エントリと重複していないかどうかをチェックします。
変更エントリが重複エントリの場合:
ディレクトリ・レプリケーション・サーバーは、次の競合解消規則を適用します。
作成タイムスタンプが古い方のエントリを使用します。
両方のエントリの作成タイムスタンプが同じ場合は、GUIDの小さい方のエントリを使用します。
変更エントリを使用すると、ターゲット・エントリは削除されて、変更エントリが適用されパージ・キューに入ります。
ターゲット・エントリを使用すると、変更エントリがパージ・キューに入ります。
変更エントリが重複エントリではない場合:
ディレクトリ・レプリケーション・サーバーは、変更エントリを管理者操作キューに入れ、指定した間隔で変更適用プロセスを繰り返します。
変更エントリが管理者操作キューに入れられた後正常に適用されない場合:
ディレクトリ・レプリケーション・サーバーは、このキューに変更エントリを保持したまま、管理者によるアクションを待ちながら、指定した間隔で変更適用プロセスを繰り返します。管理者は、Oracle Internet Directory比較調整ツールおよび管理者操作キュー操作ツールを使用して、競合を解消できます。
