This appendix contains advanced information about replication. It contains the following topics:
Section D.1, "Features of Oracle Database Advanced Replication-Based Replication"
Section D.2, "Architecture for Oracle Database Advanced Replication-Based Replication"
Note:
All references to Oracle Single Sign-On in this appendix refer to Oracle Single Sign-On 10g (10.1.4.3.0) or later.
In Oracle Database Advanced Replication-based replication, the transport of update information between Oracle Internet Directory nodes in a replication agreement is managed by Oracle Database Advanced Replication, a store-and-forward transport feature. Advanced Replication enables you to synchronize database tables across two Oracle databases.
Note:
If it is appropriate for your deployment, Oracle recommends that you use LDAP-based replication instead of Oracle Database Advanced Replication-based replication for better performance.
Oracle Database Advanced Replication:
Stores local changes and periodically propagates them in batches to consumers. The consumer replication servers apply the remote changes to their own local directory servers, and then purge the applied remote changes from their local stores.
Enables read and update access to directory tables anywhere in the Oracle replication group. Typical Advanced Replication configurations use row-level replication.
Provides proven network tolerance. Data transfer can be controlled and monitored by. Such manageability allows a high degree of flexibility in how the data transfer is scheduled.
Note:
The Oracle Single Sign-On database schema that resides in the same database as Oracle Internet Directory is also replicated by Advanced Replication.
See Also:
The section "Configuring Oracle Single Sign-On for Replication" in the chapter on high availability in the Oracle Application Server Single Sign-On Administrator's Guide in the 10g (10.1.4.0.1) library.
Oracle Database Advanced Replication in the Oracle Database Documentation Library for information about Advanced Replication
Typical Oracle Database Advanced Replication configurations use asynchronous data propagation—that is, suppliers write their changes to change logs, and then regularly send batched changes to other consumers. Consumers receive the change log data, then reproduce the changes locally.
When you configure replication, you specify which nodes in a replication group share changes. Regardless of the number of nodes you introduce into the replication environment, the basic architecture for replication remains the same. Local changes are distributed to a remote master site where the replication server, acting as a client, sends commands to the Oracle Internet Directory server that implements them.
Figure D-1 and its accompanying text provides an overview of the Oracle Database Advanced Replication process.
The events are as follows:
A change request is made on the Oracle Internet Directory server of Replica A.
The change is accepted and committed to storage in the Oracle Internet Directory Database.
2' A new change log is generated for the operation, and stored in the ods_chg_log
table, where server = Replica A.
The replication server on Replica A queries for new outbound change logs from the local ods_chg_log
table. The filter used for the query is:
(& (objectclass=changeLogEntry) (servername=ReplicaID_of_A) (changeNumber>= Last_Applied_ChgNum_From_A_TO_A) )
A control is also passed along with this search operation with the value of orclreplicationid
specified in the processing agreement. The value 1 is reserved for Advanced Replication agreements.
Last_Applied_ChgNum_From_A_TO_A
is the outbound change log processing status.
3' The directory server internally queries ods_chg_log
for new change logs and returns fetched change logs.
The new change log retrieved from ods_chg_log
is copied to local asr_chg_log
.
4' The replication server copies retrieved change logs to the local asr_chg_log
.
The replication server requests Oracle Internet Directory server to update the Change log retry_cnt
status properly.
5' Oracle Internet Directory server updates the retry_cnt
of the change log in the ods_chg_log
table.
The new change log is pushed From Replica A to Replica B through Oracle Database Advanced Replication.
If the last transported number is greater than last applied change number on Replica B, it indicates that there are new changes in local change log store asr_chg_log
. In that case, the replication server on Replica B queries for new inbound change logs from its local asr_chg_log
table. The filter used is:
(& (objectclass=changeLogEntry) (servername=ReplicaID_of_A) (changeNumber>= Last_Applied_ChgNum_From_A_TO_B))
7' The directory server queries asr_chg_log
for new change logs.
The replication server applies the new change at Replica B.
Oracle Internet Directory server at Replica B accepts and commits the change to storage in the Oracle Database.
9' If the local replica has any LDAP-based consumer replicas, a change log is regenerated in the ods_chg_log
table at Replica B, with the following regenerating rules:
server = server of local replica,
ReplicaB orclreplicationid/chg_rid = 1
Modifiersname = Replbind_DN_of_A
orclreplicatid/chg_rid
is set to the value of orclreplicationid
of the processing agreement. In this case, because the change is replicated and processed through Advanced Replication, it is set to 1 because 1 is reserved for Advanced Replication.
The replication server request Oracle Internet Directory server to update the shadow change log retry_cnt
status properly.
10' Oracle Internet Directory server updates the retry_cnt
of the shadow change log in the database.
Purging occurs regularly, removing entries that are already applied and those that are dropped as candidate changes. Remote change records in the local change log table are purged by the garbage collection thread if they have been applied locally. Local change records in the local change log table are purged by the garbage collection thread if they have been distributed to all the consumers.
See Also:
Chapter 43, "Managing and Monitoring Replication" for information on configuring replication
This section gives a more detailed look at LDAP replication. Beginning with Oracle Internet Directory 11g Release 1 (11.1.1.7.0), the data flow in LDAP replication consists of the apply phase with the apply queue. The transport phase with the transport queue is no longer used.
Figure D-2 and its accompanying text explain the fan-out replication process.
An LDAP change request is made on the Oracle Internet Directory server of Replica A.
The change is accepted and committed to Oracle Internet Directory database storage.
A new change log is generated for the operation and stored in the ods_chg_log
table, where:
server = Replica A
orclreplicationid
/chg_rid
= 0 (The value 0 is for user operations.)
Modifiersname
= user DN of the Modifier (by default)
The Replication Server at Replica B fetches the change logs from the ods_chg_log
table at Replica A, performs some partial replication filtering in memory, and then puts the change logs directly into the apply queue. The orclupdateschedule
configuration attribute determines the replication frequency.
The Replication Server at Replica B requests that the Oracle Internet Directory server at Replica B commit the changes to storage.
The Oracle Internet Directory server at Replica B commits the changes to the Oracle Internet Directory database storage, copies the changes into the asr_chg_log
table, and updates the retry count to -2, all in a single LDAP call.
If a failure occurs on the commit, the Oracle Internet Directory server reports the error to the Replication Server, copies the changes to the asr_chg_log
table, and decrements the retry count by 1. The Oracle Internet Directory server can then re-apply the commit.
Regardless of success or failure, all change logs are be copied to the asr_chg_log
table at Replica B.
If Replica B is the source for any other replicas, a change log is regenerated in ods_chg_log
table at Replica B, which follows the following changelog
regeneration rules:
server = server of local replica, Replica B
orclreplicationid
/chg_rid
= N
Modifiersname
= Replbind_DN_of_A
orclreplicatid
/chg_rid
is set to the orclreplicationid
value of the processing agreement.
This section describes the replica states for LDAP-based replication.LDAP replica states have no effect upon Advanced Replication.
When LDAP based replication is configured, and the replication server is started, the server reads the replica state orclreplicastate
from the local replica, "orclreplicaid=
local_Replica_ID
, cn=replication configuration
". The replication server behaves differently, based upon the local replica state, as shown in Table D-1. The replication server reads the local replica state from the local (consumer) node.
Note:
On Windows systems, ensure that the replication server is not running before you enable bootstrapping by changing the value of orclReplicaState
to 0
.
Value | Meaning | Server Behavior |
---|---|---|
0 |
Bootstrap |
Starts replication bootstrap processing to synchronize the consumer directory from the supplier, based on the replication naming context configuration. Updates the replica state to correspond with bootstrap progress.
|
1 |
On line |
Starts normal replication processing to replicate changes from the supplier to the consumer. |
2 |
Off line |
Logs an error message in oidrepld.log similar to this: 2004/09/24:17:41:44 * Replica(dlsun1418_replica2) is in OFFLINE mode, Please update the replica state and restart OIDREPLD... The administrator must set the replica state properly and restart the replication server. |
3 |
Bootstrap in progress |
Sets the replica state back to 0 (Bootstrap), then starts to bootstrap again as if the replica state were 0. |
4 |
Bootstrap in progress, |
Sets the replica state back to 0 (Bootstrap), then starts to bootstrap again as if the replica state were 0. |
5 |
Bootstrap completed; failure detected for one or more naming contexts. |
Logs an error message in oidrepld.log similar to this: 2004/09/24:17:13:30 * Replication BOOTSTRAP_ERROR mode detected for replica(dlsun1418_replica2) Then it waits until the replica state is reset properly. |
6 |
Database copy-Based addnode; |
This mode indicates that the replica is a database copy-based addnode. |
7 |
Sync schema |
Sync schema, but not data, from supplier to consumer. |
8 |
Boot strap without schema sync |
If schema sync was previously performed, but bootstrapping failed at a subsequent step, bootstrapping is started again without performing another schema sync. |
Oracle Internet Directory replication server logs the bootstrapping process in the Oracle Internet Directory replication server log, $ORACLE_INSTANCE
/diagnostics/logs/OID/
componentName
/oidrepld00.log
.
If bootstrap completes successfully, the log looks similar to the following example, and the replication server automatically starts to perform normal replication processing.
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
If failures are detected, the log looks similar to the following example:
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
Tip:
You have two options for troubleshooting bootstrap failure.
Option 1: Identify the cause of the bootstrap failure and fix the cause, then restart bootstrapping by setting the consumer replica's orclreplicastate
to Bootstrap mode.
Option 2: Identify the naming contexts that failed to be bootstrapped and use oidcmprec
to reconcile them. Then resume replication by setting the consumer replica's orclreplicastate
to Online mode.
Note:
Oidrepld
is now in Bootstrap_error mode, so you do need to reset the consumer replica's replica state (orclreplicastate
).
This section describes how the multimaster replication process adds, deletes, and modifies entries, and how it modifies DNs and RDNs. It contains these topics:
How the Multimaster Replication Process Adds a New Entry to a Consumer
How the Multimaster Replication Process Modifies a Relative Distinguished Name
How the Multimaster Replication Process Modifies a Distinguished Name
When the directory replication server adds a new entry to a consumer, it follows this change application process:
The directory replication server looks in the consumer for the DN of the parent of the target entry. Specifically, it does this by looking for a global unique identifier (GUID) assigned to the DN of the parent.
If the parent entry exists, then the directory replication server composes a DN for the new entry and places the new entry under its parent in the consumer. It then places the change entry in the purge queue.
If the change entry is not successfully applied on the first try, then:
The directory replication server places the new change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.
If the change entry is not successfully applied on all but the last retry, then:
The directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.
If the change entry is not successfully applied on the last retry, then:
The directory replication server checks to see if the new entry is a duplicate of an existing entry.
If the change entry is a duplicate entry, then:
The directory replication server applies the following conflict resolution rules:
The entry with the older creation time stamp is used.
If both entries have the same creation time stamp, then the entry with the smaller GUID is used.
If the change entry is used, then the target entry is removed, the change is applied, and the change entry is placed in the purge queue.
If the target entry is used, then the change entry is placed in the purge queue.
If the change entry is not a duplicate entry, then:
The directory replication server places the change entry in the human intervention queue, and repeats the change application process at the interval you specified in the orclHIQSchedule
parameter.
If the change entry is not successfully applied after it has been placed in the human intervention queue:
The directory replication server keeps the change in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the Oracle Internet Directory Comparison and Reconciliation Tool and the human intervention queue manipulation tool to resolve the conflict.
When the directory replication server deletes an entry from a consumer, it follows this change application process:
The directory replication server looks in the consumer for an entry with a GUID matching the one in the change entry.
If the matching entry exists in the consumer, then the directory replication server deletes it. It then places the change entry in the purge queue.
If the change entry is not successfully applied on the first try, then:
The directory replication server places the change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.
If the change entry is not successfully applied on all but the last retry, then:
The directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.
If the change entry is not successfully applied on the last retry, then:
The directory replication server places the change entry in the human intervention queue and repeats the change application process at specified intervals.
If the change entry is not successfully applied after it has been placed in the human intervention queue:
The directory replication server keeps the change entry in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the Oracle Internet Directory Comparison and Reconciliation Tool and the human intervention queue manipulation tool to resolve the conflict.
When the directory replication server modifies an entry in a consumer, it follows this change application process:
The directory replication server looks in the consumer for an entry with a GUID matching the one in the change entry.
If the matching entry exists in the consumer, then the directory replication server compares each attribute in the change entry with each attribute in the target entry.
The directory replication server then applies the following conflict resolution rules:
The attribute with the most recent modify time is used.
The attribute with the most recent version of the attribute is used—for example, version 1, 2, or 3.
The modified attribute on the host whose name is closest to the beginning of the alphabet is used.
The directory replication server applies the filtered modification, and places the change entry in the purge queue.
If the change entry is not successfully applied on the first try, then:
The directory replication server places the change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.
If the change entry is not successfully applied on all but the last retry, then:
The directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.
If the change entry is not successfully applied by the last retry, then:
The directory replication server places the change entry in the human intervention queue and repeats the change application process at specified intervals.
If the change entry is not successfully applied after it has been placed in the human intervention queue:
The directory replication server keeps the change entry in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. You can use the Oracle Internet Directory Comparison and Reconciliation Tool and the Human Intervention Queue Manipulation Tool to resolve the conflict.
When the directory replication server modifies the RDN of an entry in a consumer, it follows this change application process:
The directory replication server looks in the consumer for the DN with a GUID that matches the GUID in the change entry.
If the matching entry exists in the consumer, then the directory replication server modifies the RDN of that entry and places the change entry in the purge queue.
If the change entry is not successfully applied on the first try, then:
The directory replication server places the change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.
If the change entry is not successfully applied on all but the last retry, then:
The directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.
If the change entry is not successfully applied on the last retry, then:
The directory replication server places the change entry in the human intervention queue and checks to see if it is a duplicate of the target entry.
If the change entry is a duplicate entry, then:
The directory replication server applies the following conflict resolution rules:
The entry with the older creation time stamp is used.
If both entries have the same creation time stamp, then the entry with the smaller GUID is used.
If the change entry is used, then the target entry is removed, the change entry is applied, and then placed in the purge queue.
If the target entry is used, then the change entry is placed in the purge queue.
If the change entry is not a duplicate entry, then:
The directory replication server places the change entry in the human intervention queue, and repeats the change application process at specified intervals.
If the change entry is not successfully applied after it has been placed in the human intervention queue:
The directory replication server keeps the change entry in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the Oracle Internet Directory Comparison and Reconciliation Tool and the Human Intervention Queue Manipulation Tool to resolve the conflict.
When the directory replication server modifies the DN of an entry in a consumer, it follows this change application process:
The directory replication server looks in the consumer for the DN with a GUID that matches the GUID in the change entry.
The directory replication server also looks in the consumer for the parent DN with a GUID that matches the GUID of the new parent specified in the change entry.
If both the DN and the parent DN of the target entry exist in the consumer, then the directory replication server modifies the DN of that entry and places the change entry in the purge queue.
If the change entry is not successfully applied on the first try, then:
The directory replication server places the change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.
If the change entry is not successfully applied on all but the last retry, then:
The directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.
If the change entry is not successfully applied by the last retry, then:
The directory replication server places the change entry in the human intervention queue and checks to see if it is a duplicate of the target entry.
If the change entry is a duplicate entry, then:
The directory replication server applies the following conflict resolution rules:
The entry with the older creation time stamp is used.
If both entries have the same creation time stamp, then the entry with the smaller GUID is used.
If the change entry is used, then the target entry is removed, the change entry is applied, and then placed in the purge queue.
If the target entry is used, then the change entry is placed in the purge queue.
If the change entry is not a duplicate entry, then:
The directory replication server places the change entry in the human intervention queue, and repeats the change application process at specified intervals.
If the change entry is not successfully applied after it has been placed in the human intervention queue:
The directory replication server keeps the change entry in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the Oracle Internet Directory Comparison and Reconciliation Tool and the Human Intervention Queue Manipulation Tool to resolve the conflict.