43 Managing Replication Configuration Attributes
See Managing and Monitoring Replication for specific replication management tasks.
43.1 Understanding Replication Configuration Attributes
The following topics provide a contextual description of the configuration attributes that reside in specific containers in the DIT:
43.1.1 Replication Configuration Container
All replication information for a node resides in the container cn=replication configuration
located at the root DSE. This entry resides on each node in a DRG.
The following is a sample replication configuration container entry:
dn: cn=replication configuration orclaci: access to entry by * (browse) orclaci: access to attr=(*) by * (search,read) orclnormdn: cn=replication configuration cn: replication configuration description: Replication agreement Container object objectclass: top objectclass: orclcontainerOC
43.1.2 Understanding Replica Subentry
The following topics provide a contextual description of replica subentry and its attributes:
43.1.2.1 About Replica Subentry
The Replica subentry has the DN
orclreplicaid=Replica_ID,cn=replication configuration
This subentry is created at installation under the replication configuration container. It contains attributes that identify and define the characteristics of the node it represents.
43.1.2.2 Replica Subentry Attributes
Table 43-1 describes the attributes of the replica subentry. LDAP indicates that you can manage this attribute by using LDAP tools.
Table 43-1 Attributes of the Replica Subentry
Attribute | Description | Update Mechanism | Default | Possible Values |
---|---|---|---|---|
|
Unique identifier for directory database. Initialized at installation. Matches orclreplicaid at the root DSE. |
Read-only |
hostname_ORACLESID |
Integer |
|
Address used to open a connection to this replica. |
LDAP |
Valid ldapURI format |
|
|
Addresses used if |
LDAP |
Valid ldapURI format |
|
|
Defines the type of replica such as read-only or read/write. |
LDAP |
0 (Read/Write) |
0: Read/Write 1: Read-Only 2: Pilot |
|
Defines whether replica is in pilot (testing) mode. |
|
0 |
0: False 1: True |
|
Defines state of the replica. |
LDAP |
You can set 0, 1, 2, 6, or 8. Server sets other values. See Table A-2. |
|
|
Time when replica entered pilot (testing) mode. |
Read-only |
Time |
Note:
On Windows systems, ensure that the replication server is not running before you enable bootstrapping by changing the value of orclReplicaState
to 0
.
43.1.2.3 Example of Replica Subentry
In Figure 43-3 , a replica subentry is represented by orclReplicaID=
UID_of_node_D
,cn=replication configuration
.
The following is a sample replica subentry:
dn: orclreplicaid=myhost1_repl1,cn=replication configuration objectclass: top objectclass: orclreplicasubentry orclreplicaid: myhost1_repl1 orclreplicauri: ldap://myhost1:3060/ orclreplicasecondaryuri: ldap://myhost1.mycompany.com:3060/ orclreplicastate: 1
See Also:
Oracle Directory Replication Schema Elements in Reference for Oracle Identity Management for descriptions of the attributes of the replica subentry.
43.1.3 Understanding Replication Agreement Entry
The following topics provide a conceptual description of replication agreement entry and its attributes and also describe the different LDAP replication agreements:
43.1.3.1 About Replication Agreement Entry
The DN of the Replication Agreement Entry is:
orclagreementid=Agreement_ID,orclreplicaid=Replica_ID,cn=replication configuration
This entry contains attributes that define the replication agreement between the two or more nodes and is associated with the orclReplAgreementEntry
objectclass. LDAP-based replication agreement for LDAP nodes reside under the supplier's replica subentry. For example, in Figure 43-3, an LDAP-based replication agreement entry is represented by orclagreementID=000003, orclReplicaID=UID_of_node_D,cn=replication configuration
.
43.1.3.2 Replication Agreement Entry Attributes
Table 43-2 shows the attributes in the replication agreement. LDAP indicates that you can manage this attribute by using LDAP tools.
Table 43-2 Attributes of the Replication Agreement Entry
Attribute | Description | Update Mechanism | Default | Possible Values |
---|---|---|---|---|
|
Name of replication agreement entry. |
Read-only |
||
|
LDAP-based replication only. DN of the replica to identify a consumer in the replication agreement. |
Read-only |
DN |
|
|
LDAP-based one-way replication only. LDAP filter string that specifies entries that should not be replicated. See Configuring Replication Filtering Using the orclEntryExclusionFilter Attribute. |
LDAP |
LDAP filter string enclosed in parentheses. Supported maximum length is For example: |
|
|
Replication protocol for change propagation to replica. Values: |
Read-only |
ODS_LDAP_1.0: LDAP-based |
|
|
Update interval for new changes and those being retried. |
LDAP |
60 (seconds) |
Greater than or = 0 |
|
Interval at which the directory replication server repeats the change application process. |
LDAP |
600 (seconds) |
Greater than or = 60 (seconds) |
|
Whether the connections from replication server to the directory server are kept active or established every time the changelog processing is done. |
LDAP |
1 |
0: false 1: true |
|
Last change number transported or applied at the consumer replica. For LDAP-based agreements, this attribute contains subtypes. The format is: orcllastappliedchangenumber; status_type$supplier_replicaID$consumer_replicaID: Number where status_type is: It indicates that changelogs from supplier_replicaID to consumer_replicaID with change number less than |
Read-only |
||
|
Subtrees to be excluded from replication. |
Read-only |
||
|
Unique identifier of a one-way, two-way, or peer-to-peer replication group |
Read-only |
||
|
Replication agreement type. |
Read-only |
0: one-way/read-only fan-out replication agreement 1: two-way/updatable fan-out replication agreement 2: LDAP-based multimaster replication agreement |
43.1.3.3 About LDAP-Based Replication Agreements
For LDAP-based replication, there are separate replication agreements for each supplier-consumer relationship. For one-way replication, there is a single, one-way replication agreement.
The entry for an LDAP-based replication agreement resides immediately below the replica subentry of the node that serves as the supplier. Thus, the DN of the replication agreement as found on a supplier node is:
orclagreementID=
unique_identifier_of_the_replication_agreement
, orclReplicaID=
unique_identifier_of_supplier_node
, cn=replication configuration
Similarly, the DN of the replication agreement as found on a consumer node is:
orclagreementID=
unique_identifier_of_the_replication_agreeement
, orclReplicaID=
unique_identifier_of_supplier_node
, cn=replication configuration
In a fan-out replication agreement, you can tell which node the agreement entry is associated with by looking at its parent. For example, look at the following replication agreement entry.
orclagreementID=
000002,orclReplicaID=
node_A,cn=replication configuration
In this example, you can determine that the replication agreement represented by orclagreementID=000002
is associated with node A. This is because the parent of orclagreementID=000002
is orclReplicaID=node_A
.
Note:
-
The container entry
cn=replication configuration
is replicated on all nodes, but may not be identical on all nodes. -
The
orclreplicadn
attribute of an LDAP-based replication agreement specifies the associated consumer node. -
The
agreementtype
indicates the replication agreement type. See Table 43-2 for values oforclagreementtype
.
43.1.3.4 Example of Two-Way LDAP-Based Replication Agreements
For two-way replication, there can be either a single, two-way replication agreement or two one-way agreements for each supplier-consumer relationship. The following is a sample two-way replication agreement entry:
dn: orclagreementid=000002, orclreplicaid=stadd58_repl, cn=replication configuration orclagreementid: 000002 orclreplicationprotocol: ODS_LDAP_1.0 orclreplicadn: orclreplicaid=stadd57_repl,cn=replication configuration orclldapconnkeepalive: 1 orclagreementtype: 1 orclreplicationid: 000002 orcllastappliedchangenumber;transport$stadd57$stadd58: 106 orcllastappliedchangenumber;transport$stadd58$stadd57: 2421 orcllastappliedchangenumber;apply$stadd57$stadd58: 106 orcllastappliedchangenumber;apply$stadd58$stadd57: 2421 orclupdateschedule: 0 orclhiqschedule: 60 objectclass: orclReplAgreementEntry objectclass: top
Note:
The value of orclagreementtype
is 1 because this is a two-way replication agreement. See Table 43-2 for values of orclagreementtype
for other replication agreement types.
See Also:
Oracle Directory Replication Schema Elementsin Reference for Oracle Identity Management for descriptions of the attributes of the replication agreement entry
43.1.4 Replication Naming Context Container Entry
This entry contains all the LDAP naming context objects. This entry has the RDN cn=replication namecontext
, and it is created below the orclagreementID
entry during replication configuration.
The following is a sample replication naming context container entry:
dn: cn=replication namecontext,orclagreementid=000002, orclreplicaid=myhost1_repl1,cn=replication configuration objectclass: top objectclass: orclcontainerOC cn: replication namecontext
43.1.5 Understanding Replication Naming Context Object Entry
The following topics provide a contextual description of replication naming context object entry and its attributes:
43.1.5.1 About Replication Naming Context Object Entry
This entry contains all the LDAP naming context objects. These objects specify the replication filtering policy, that is, what to include in or exclude from replication to an LDAP-based partial replica.
This entry is created below the naming context container entry during replication configuration. It is configurable. For example, in Figure 43-3, the replication naming context object is: cn=includednamingcontext000001,cn=replication namecontext,orclagreementID=000003,orclReplicaID=
UID_of_node_D
,cn=replication configuration
.
43.1.5.2 Replication Naming Context Entry Attributes
Table 43-3 describes the attributes of the replication naming context entry.
Table 43-3 Attributes of the Replication Naming Context Entry
Attribute | Description |
---|---|
|
The root of the naming context to be replicated. If orclincludednamingcontexts is set to " orclincludednamingcontexts ; supplier_replicaID$consumer_replicaiD: DN
This is a single valued attribute. For each naming context object, you can specify only one unique subtree in each direction. In partial replication, except for subtrees listed in the orclexcluednamingcontexts attribute, all subtrees in the specified included naming context are replicated. You can modify this attribute. |
|
The root of a subtree, located within the included naming context, to be excluded from replication.This attribute has subtypes that specify the replication direction in which the naming context should be excluded. The format is: orclexcludednamingcontexts; supplier_replicaID$consumer_replicaiD : DN This is a multivalued attribute. From within the naming context specified in the orclincludednamingcontexts attribute, you can specify one or more subtrees to be excluded from the partial replication in each direction. You can modify this attribute. |
|
An attribute, located within the included naming context, to be excluded from replication. orclexcludedattributes; supplier_replicaID$consumer_replicaiD: attribute_name This is a multivalued attribute. You can modify this attribute |
43.1.5.3 Example of Replication Naming Context Entry
The following is a sample replication naming context object entry:
dn:cn=namectx001, cn=replication namecontext, orclagreementid=unique_identifier_of_the_replication_agreement, orclreplicaid=replica_id_of_node_A, cn=replication configuration orclincludednamingcontexts: cn=mycompany orclexcludednamingcontexts; replica_id_of_node_A$ replica_id_of_node_B : c=us,cn=mycompany orclexcludedattributes; replica_id_of_node_B$ replica_id_of_node_A : userPassword
The example specifies the following replication filtering:
-
The naming context
cn=mycompany
is included for replication in both directions for node A and node B. -
The naming context
c=us,cn=mycompany
is excluded for replication from node A to node B only. -
The
userPassword
attribute is excluded for replication from node B to node A
See Also:
-
Oracle Directory Replication Schema Elementsin Reference for Oracle Identity Management
43.1.6 Understanding Replication Configuration Set
The following topics provide a a contextual description of replication configuration set and its attributes:
43.1.6.1 About Replication Configuration Set
The replication configuration set has the DN:
cn=configset0,cn=osdrepld,cn=subconfigsubentry
Table 43-4 lists and describes the attributes of the replication configuration set, which has the following DN:
cn=configset0,cn=osdrepld,cn=subconfigsubentry
You must restart the replication server in order for any attribute changes under this DN to take effect, except for the attribute orcldebuglevel
. LDAP indicates that you can manage this attribute by using LDAP tools.
43.1.6.2 Replication Configuration Set Attributes
The following table lists and describes the attributes of the replication configuration set:
Table 43-4 Replication Configuration Set Attributes
Attribute | Description | Update Mechanism | Default | Possible Values |
---|---|---|---|---|
|
Time of entry creation or modification. |
Read-only |
||
|
Name of person creating or modifying the entry |
Read-only |
||
|
Number of processing retry attempts for a change-entry before being moved to the human intervention queue. |
LDAP |
10 |
Greater than or equal to 1. |
|
Number of worker threads spawned at each supplier for transporting change logs. |
LDAP |
1 |
1-100 |
|
Number of worker threads spawned at each supplier for applying change logs. |
LDAP |
5 |
1-100 |
|
Dynamically vary the number of threads assigned to transport and apply tasks based on load. If you set the server to auto tune, you must specify the number of maximum number of threads to be shared between these tasks. Restart server after changing. |
LDAP |
1 |
0: Off 1: On |
|
Maximum number of worker threads. Required if |
LDAP |
20 |
1-100 |
|
Generate stack dump. (Restart after changing.) |
LDAP |
0 |
0: False 1: True |
|
Maximum log file size (MB) |
LDAP |
1 MB |
> or = 1 |
|
Maximum number of log files to keep in rotation |
LDAP |
100 |
> or = 1 |
|
Maximum number of entries to process per replication cycle |
LDAP |
1000 |
1-10000 |
|
Automatically resolve replication conflicts |
LDAP |
1 |
0: False 1: True |
|
Use SASL for replication binds. |
LDAP |
Attribute does not exist by default. |
auth, auth-int, auth-conf |
|
Specifies that replication be activated on the replication server designated by |
LDAP |
0 |
0: False 1: True |
|
Activation state of the replication server |
Read-only, LDAP |
0 |
0 or nonexistant: Not running False 1: Running |
|
Debug level of replication server |
LDAP |
0 |
Values are additive: 0: No Debug Log 2097152: Replication Performance Log 4194304: Replication Debug Log 8388608: Function Call Trace 16777216: Heavy Trace Log |
|
Name of OID component where replication is or will be activated |
Read-only |
Set during replication setup |
String |
|
Instance number of instance where replication is or will be activated |
Read-only |
Set during replication setup |
Integer |
|
Specifies whether timestamp or attribute version should be honored first during attribute level conflict resolution. |
LDAP |
0 |
0: Timestamp first. 1: Version number first |
43.1.7 Examples of Replication Configuration Objects in a Directory
This section explains the replication configuration objects in a directory.
The examples of replication objects in this section rely on the replication environment shown in Figure 43-1.
Figure 43-1 Example: Multimaster Replication and Fan-Out Replication

In Figure 43-1, nodes A, B, and C form a multimaster replication group. Node C replicates to a fourth node, D, which, in turn, fans out to Node E.
The replication agreements in this environment are as follows:
-
Node A has one replication agreement representing its multimaster relationship with nodes B and C.
-
Node B has two replication agreements, the first representing its multimaster relationship with nodes A and C, the second representing its relationship to node F. The replication agreement between B and F is two-way.
-
Node C has two replication agreements, the first representing its multimaster relationship with nodes A and B, the second representing its relationship to node D. This is a one-way replication agreement in which C serves as the supplier and node D is the consumer.
-
Node D has two replication agreements. Both of its replication agreements are one-way. One represents its relationship to the supplier node C, from which it consumes changes, the other represents its relationship to consumer node E for which it is the supplier.
-
Node E has a one-way replication agreement with Node D. Node E is the consumer.
-
Node F has two replication agreements, one representing its relationship to the node B, the other representing its relationship to node G.Both are two-way replication agreements.
-
Node G has a one-way replication agreement with Node F. Node G is the consumer.
Figure 43-2 shows the replication objects in the DIT that pertain to node C in Figure 43-1 .
Figure 43-2 Example: Replication Configuration Entries for Node C

For node C, the entry cn=replication configuration
at the root DSE contains these RDNs:
-
orclagreementID=000001
: The multimaster replication agreement in which node C participates with nodes A and B. -
orclReplicaID=
UID_of_node_C
: Unique identifier of node C that contains information about it. -
orclagreementID=000002
: Unique identifier of the relationship between supplier node C and consumer node D. You know that, in this case,orclagreementID=000002
is the replication agreement of the supplier node C because node C is its parent.This entry contains the attribute
orclreplicaDN
. Its value is the replica entry DN of consumer node D, with which node C has the replication agreement. -
cn=replication DN
: The bind DN that the directory replication server on node C uses to bind to the directory server. -
cn=replication namecontext
: Container of information about naming contexts that are included in replication. -
cn=includednamingcontext000001
andcn=namingcontext002
: The actual objects that are included in or excluded from replication. In the naming context included for replication, you can specify one or more subtrees to be excluded from replication. In that same included naming context, you can specify particular attributes to be excluded from replication.
Figure 43-3 shows the replication agreement entry in the DIT that pertains to node D in Figure 43-1.
Figure 43-3 Example: Replication Configuration Entries for Node D

For node D, the entry cn=replication configuration
at the root DSE contains these RDNs:
-
orclReplicaID=
UID_of_node_D
: Unique identifier of node D and contains information about it. -
orclagreementID=000003
: Unique identifier of the relationship between supplier node D and consumer node E. You know that, in this case,orclagreementID=000003
is the replication agreement of the supplier node D because node D is its parent.This entry contains the attribute
orclreplicaDN
, the value of which is the DN of consumer node E with which node D has the replication agreement. -
cn=replication DN
: Bind DN that the directory replication server on node D uses to bind to the directory server. -
cn=replication namecontext
: Container of information about naming contexts that are included in replication. -
cn=
namingcontext001
andcn=namingcontext002
: Objects specifying naming contexts to be included in replication. In the naming context included in replication, you can specify one or more subtrees or particular attributes to be excluded from replication.
43.2 Managing Replication Configuration Attributes Using the Command Line
You can modify most attributes from the command line by using ldapmodify
.
The command line syntax is:
ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile
The contents of the LDIF file depends on the DN and the operation being performed.
For examples of LDIF files for changing replication configuration attributes, see Overview of Managing and Monitoring Replication Using the Command Line.