D How Replication Works

This appendix contains advanced information about replication. It contains the following topics:

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.

D.1 Features of Oracle Database Advanced Replication-Based Replication

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.

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:

D.2 Architecture for Oracle Database Advanced Replication-Based 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.

Figure D-1 Advanced Replication Process

Described in text.

The events are as follows:

  1. A change request is made on the Oracle Internet Directory server of Replica A.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. The new change log is pushed From Replica A to Replica B through Oracle Database Advanced Replication.

  7. 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.

  8. The replication server applies the new change at Replica B.

  9. 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.

  10. 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 42, "Managing and Monitoring Replication" for information on configuring replication

D.3 Architecture of LDAP-Based Replication

This section gives a more detailed look at LDAP replication. Data flow in LDAP replication consists of two phases, transport and apply.

Figure D-2 and its accompanying text explain the fan-out replication process.

Figure D-2 LDAP Replication Process

Described in text

  1. An LDAP change request is made on the Oracle Internet Directory server of Replica A.

  2. The change is accepted and committed to Oracle Internet Directory database storage.

    2'. 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)

  3. The replication server on Replica B queries for new inbound change logs from the supplier replica, Replica A's ods_chg_log table]. The filter used for the query is:

    (& (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=….)
…)

    A control is also passed along with this search operation with the value of orclreplicationid specified in the processing agreement.

  4. The replication Server at B requests that the Oracle Internet Directory at Replica B store the new change log as a shadow change log.

    4'. The Oracle Internet Directory server at Replica B stores the shadow change log in the asr_chg_log table at Replica B.

    Steps 3, 3', and 4 correspond with the transport part of LDAP-based change log processing

  5. The replication server at Replica B checks whether the last transported number is greater than the last applied change number on Replica B. If so, it indicates that there are new changes in the local change log store asr_chg_log. In that case, the replication server at Replica B queries the local store asr_chg_log for new change logs from A. The filter for the query is:

    (& (objectclass=changeLogEntry) (servername=ReplicaID_of_A)
  (changeNumber>= Last_Applied_ChgNum_From_A_TO_B))

  6. The replication server at Replica B request that the Oracle Internet Directory server at Replica B apply the retrieved change to storage.

  7. Oracle Internet Directory server at Replica B accepts and commits the change to Oracle Internet Directory database storage.

    7' If the local replica is the source of 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, ReplicaB
orclreplicationid/chg_rid = N
Modifiersname = Replbind_DN_of_A

    orclreplicatid/chg_rid is set to the orclreplicationid value of the processing agreement.

  8. The replication server requests that the server update the shadow change log retry_cnt status properly.

D.4 LDAP Replica States

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.

Table D-1 LDAP Replica States

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.

  • Sets the replica state to 3 (Bootstrap in progress) immediately when it starts to bootstrap.

  • Sets the replica state to 4 (Bootstrap in progress, cn=oraclecontext bootstrap has completed) after it completes bootstrapping of "cn=oraclecontext" successfully

  • Sets the replica state to 5 (Bootstrap Error occurred) after bootstrap is completed but failure(s) detected during the bootstrap. Then it waits until the replica state is re-set.

    Note: Human intervention is required; See Section S.1.12, "Troubleshooting Oracle Internet Directory Replication" for details.

  • Sets the replica state to 1 (On-line) after bootstrap has completed successfully. Then replication automatically starts to perform normal replication processing.

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, cn=oraclecontext bootstrap has completed.

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).

D.5 The Replication Process

This section describes how the multimaster replication process adds, deletes, and modifies entries, and how it modifies DNs and RDNs. It contains these topics:

D.5.1 How the Multimaster Replication Process Adds a New Entry to a Consumer

When the directory replication server adds a new entry to a consumer, it follows this change application process:

  1. 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.

  2. 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.

D.5.2 How the Multimaster Replication Process Deletes an Entry

When the directory replication server deletes an entry from a consumer, it follows this change application process:

  1. The directory replication server looks in the consumer for an entry with a GUID matching the one in the change entry.

  2. 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.

D.5.3 How the Multimaster Replication Process Modifies an Entry

When the directory replication server modifies an entry in a consumer, it follows this change application process:

  1. The directory replication server looks in the consumer for an entry with a GUID matching the one in the change entry.

  2. 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.

  3. The directory replication server then applies the following conflict resolution rules:

    1. The attribute with the most recent modify time is used.

    2. The attribute with the most recent version of the attribute is used—for example, version 1, 2, or 3.

    3. The modified attribute on the host whose name is closest to the beginning of the alphabet is used.

  4. 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.

D.5.4 How the Multimaster Replication Process Modifies a Relative Distinguished Name

When the directory replication server modifies the RDN of an entry in a consumer, it follows this change application process:

  1. The directory replication server looks in the consumer for the DN with a GUID that matches the GUID in the change entry.

  2. 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.

D.5.5 How the Multimaster Replication Process Modifies a Distinguished Name

When the directory replication server modifies the DN of an entry in a consumer, it follows this change application process:

  1. 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.

  2. 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.