| Oracle Internet Directory Administrator's Guide 10g (10.1.4.0.1) Part Number B15991-01 |
|
|
View PDF |
| Oracle Internet Directory Administrator's Guide 10g (10.1.4.0.1) Part Number B15991-01 |
|
|
View PDF |
This chapter tells you how to monitor and manage replication in Oracle Internet Directory.
Once you have installed and configured replication, you can view or modify the default values for replication-related objects. This section contains these topics:
Viewing and Modifying Directory Replication Server Configuration Parameters
Viewing and Modifying Parameters for Particular Replica Nodes
The Compare and Reconcile Tool
|
Note: No change to any configuration parameter or replication agreement takes effect until the replication server is restarted. |
The section "Directory Server Configuration Parameters" under "Replication Schema Elements" in Oracle Identity Management User Reference lists and describes the directory replication server configuration parameters. These parameters are stored in the replication server "configuration set entry", which has the following DN: cn=configset0,cn=osdrepld,cn=subconfigsubentry. This entry contains replication attributes that control replication processing. You can modify some of these attributes.
To view configuration parameters of the directory replication server:
In the navigator pane, expand in succession Oracle Internet Directory Servers, directory server instance, Server Management.
Select Replication Server. The following tab pages appear in the right pane.
Active Replication Servers, which tells you which directory replication servers are now running
Replication Status, which tells you the number of the last change applied from each supplier to each consumer in the DRG
Changelog Subscriber Status, which lists subscribers to the change log, and gives the number of the last change applied from this node
To modify configuration parameters of the directory replication server:
In the navigator pane, expand Oracle Internet Directory Servers, directory server instance, Server Management, Replication Server.
Select the replication configuration set whose parameters you want to modify. The corresponding tab pages appear in the right pane.
In the General tab page, modify the fields as appropriate.
For a description of these fields, see Table A-20, "Fields in the Replication Server Configuration Set: General Tab Page".
For Advanced Replication-based agreements, in the ASR Agreement tab page, modify the fields as appropriate.
For a description of these fields, see Table A-21, "Fields in the ASR Agreement Tab Page".
Restart the directory replication server to effect your changes.
|
Note: Be sure to add all host names for all nodes in the DRG into the Replication Group Nodes field. Do this for all nodes in the DRG. |
To modify replication configuration parameters by using command-line tools, use the syntax documented in the ldapmodify command-line tool reference in Oracle Identity Management User Reference.
"Replication Schema Elements" in Oracle Identity Management User Reference describes the replication server configuration parameters. As noted in that table, the modifiable replication configuration parameters are:
orclChangeRetryCount
orclThreadsPerSupplier
The orclThreadsPerSupplier configuration parameter has two subtypes:
apply: The number of worker threads for applying change logs
transport: The number of worker threads for transporting change logs
Example 31-1 Modifying the Number of Retries Before a Change Is Moved into the Purge Queue
This example uses an input file named mod.ldif to change the number of retry attempts from the default of ten times to five times. Specifically, after attempting to apply an update five times, the update is dropped and logged in the replication log.
Edit the example file mod.ldif as follows:
dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry changetype: modify replace: orclChangeRetryCount orclChangeRetryCount: 5
Use ldapmodify to update the replication server configset0 parameter value as follows:
ldapmodify –D "cn=orcladmin" –w administrator_password -h my_host \ -p port -f mod.ldif
Restart the directory replication server.
Example 31-2 Modifying the Number of Worker Threads Used for Applying Change Logs
This example uses an input file named mod.ldif to change the number of worker threads used for applying change logs to 5.
Edit the example file mod.ldif as follows:
dn: cn=configset0, cn=osdrepld, cn=subconfigsubentry changetype:modify replace: orclthreadspersupplier;apply orclthreadspersupplier;apply: 5
Use ldapmodify to update the replication server configset0 parameter value as follows:
ldapmodify -h consumer_host_name -p consumer_port -D cn=orcladmin \ –w administrator_password -v -f mod.ldif
Restart the directory replication server:
oidctl connect=connect_string server=oidrepld instance=instance_number restart
|
See Also: Theoidctl command-line tool reference in Oracle Identity Management User Reference for instructions on restarting the directory replication server |
Example 31-3 Modifying the Number of Worker Threads Used for Transporting and Applying Change Logs
This example uses an input file named mod.ldif to make the following changes:
Change the number of worker threads used for applying change logs to 1
Change the number of worker threads used for transporting change logs to 1
All steps are the same as in Example 31-2. Only the LDIF file differs.
Edit the example file mod.ldif as follows:
dn: cn=configset0, cn=osdrepld, cn=subconfigsubentry changetype:modify replace: orclthreadspersupplier;transport orclthreadspersupplier;transport: 1 replace: orclthreadspersupplier;apply orclthreadspersupplier;apply: 1
Once you make this change, only one worker thread and one reader thread will be spawned for each replication direction between two replicas of a replication agreement.
To modify a particular replica node, you modify the replica subentry. "Replication Schema Elements" in Oracle Identity Management User Reference describes the parameters you can modify in the replica subentry.
|
Note: Because the directory replication server reads replication node objects from the consumer, you must apply all changes to the consumer and, optionally, to the supplier. |
To view and modify a particular replica node by using Oracle Directory Manager:
In the navigator pane, expand Oracle Internet Directory Servers, directory server instance, Replication Management.
Select the replica node you want to view or modify. The corresponding tab pages appear in the right pane.
In the General tab page, you can modify the fields as appropriate. Table A-22, "Fields in the Replica Node: General Tab Page" describes the fields in this tab page.
The Replica Agreements tab page enables you to view the details of the replication agreement in which the specified node participates. The columns in this tab page are described in Table A-23, "Columns in the Replica Agreements Tab Page".
After you have viewed and modified the replica node, restart the directory replication server.
To modify replication configuration parameters by using command-line tools, use the syntax documented in the ldapmodify command-line tool reference in Oracle Identity Management User Reference.
Example 31-4 Modifying the orclReplicaURI Attribute for a Particular Replica Node
The directory replication server uses the orclReplicaURI attribute value of the replica subentry to locate the directory server for that replica. If the port or host where the directory server is running is changed, then this attribute must be modified accordingly.
Edit the example file mod.ldif as follows:
Dn: orclreplicaid=unique_replica_identifier, cn=replication configuration Changetype:modify Replace:orclReplicaURI OrclReplicaURI: ldap://host_name:port_number/
Use ldapmodify to update the replica subentry orclreplicauri attribute.
ldapmodify –D "cn=orcladmin" –w administrator_password -h my_host \ -p port -f mod.ldif
Restart the directory replication server.
Example 31-5 Modifying the orclReplicaSecondaryURI Attribute for a Particular Replica
The directory replication server uses the orclReplicaSecondaryURI attribute value as an alternate location to contact the directory server for a particular replica. A user can add an alternate ldapURI attribute at which the directory server can be contacted for that particular replica. To add additional ldapURI attribute:
Edit the example file mod.ldif as follows:
Dn: orclreplicaid=unique_replica_identifier, cn=replication configuration Changetype:modify add:orclReplicaSecondaryURI OrclReplicaSecondaryURI: ldap://host_name:port_number/
Use ldapmodify to update the replica subentry OrclReplicaSecondaryURI attribute.
ldapmodify –D "cn=orcladmin" –w administrator_password -h my_host \ -p port -f mod.ldif
Restart the directory replication server.
Example 31-6 Modifying the orclReplicaState Attribute for a Particular Replica
OrclReplicaState represents the state of a particular replica. To bootstrap (re-initialize) a replica, update this attribute in the following manner:
Edit the example file mod.ldif as follows:
Dn: orclreplicaid=unique_replicaID, cn=replication configuration
Changetype:modify
replace:orclReplicaState
OrclReplicaState: 0
On the host where the consumer replica is running, use ldapmodify to update the replica subentry orclreplicastate attribute.
ldapmodify –D "cn=orcladmin" –w administrator_password -h consumer_host \ -p port -f mod.ldif
Restart the directory replication server.
This section contains instruction for modifying replication agreements that are based on both Advanced Replication and LDAP.
Replication agreement parameters based on Advanced Replication are stored in replication agreement entries, which have the following DN:
orclAgreementID=000001,cn=replication configuration
To view and modify replication agreement parameters by using Oracle Directory Manager:
In the navigator pane, expand Oracle Internet Directory Servers, then directory server instance, then Replication Management. The following tab pages appear in the right pane:
Replication Status, which tells you the number of the last change applied from each supplier to each consumer in the DRG
Replica Status, which tells you the state of the replica—that is, whether it is online, offline, or in the bootstrapping process.
Changelog Subscriber, which lists subscribers to the change log, and gives the number of the last change applied from this node
ASR Agreement, in which you can view and modify the information for an Advanced Replication-based replication agreement. The fields in this tab page are described in Table A-21, "Fields in the ASR Agreement Tab Page".
|
Note: Be sure to add all host names for all nodes in the DRG into the Replication Group Nodes field. Do this for all nodes in the DRG. |
If you are modifying the values, and want to return to the values that appeared when you first opened this pane, then click Revert. If you are satisfied with your changes, then click Apply.
"Replication Schema Elements" in Oracle Identity Management User Reference lists and describes the replication agreement parameters and indicates those that you can modify.
To add more nodes to the values in a replication agreement entry, run ldapmodify at the command line, referencing an LDIF-formatted file.
Example 31-7 Adding Nodes to a Replication Agreement
This example uses an input file named mod.ldif to add two nodes to a replication agreement:
Edit mod.ldif as follows:
dn: orclagreementid=000001,cn=replication configuration changetype: modify add: orcldirreplgroupdsas orcldirreplgroupdsas: hollis orcldirreplgroupdsas: eastsun-11
Use ldapmodify to update the replication server configset0 parameter value as follows:
ldapmodify –D "cn=orcladmin" –w administrator_password -h host \ -p port -f mod.ldif
Restart the directory replication server.
This procedure modifies the entry containing the replication agreement whose DN is orclagreementid=000001,cn=replication configuration. The input file adds the two nodes, hollis and eastsun-11, into the replication group governed by oraclagreementid=000001.
|
Note: You must include the new nodes—for example,hollis and eastsun-11 in the previous sample LDIF file—in the orclDirReplGroupDSAs parameter on each node in the replicated environment before you start the replication process.
"Adding a Node for Multimaster Replication (Oracle Database Advanced Replication Types Only)" explains the process of adding a new node to a replication environment. |
Because Oracle Internet Directory 10g (10.1.4.0.1) supports only one configuration set for the directory replication server, you do not need to specify a configuration set.
Example 31-8 Modifying the orclExcludedNamingContexts Attribute for an Oracle Database Advanced Replication Replica Agreement
In a replication agreement based on Advanced Replication, the directory replication server uses the value of the orclExcludedNamingcontexts attribute of the replica agreement entry to specify the top level subtrees to be excluded from replication.
In this example, two top level naming contexts—c=us and c=uk—are excluded from Advanced Replication.
Edit the example file mod.ldif as follows:
dn: orclAgreementID=000001, cn=replication configuration Changetype:modify Replace: orclExcludedNamingcontexts orclExcludedNamingcontexts: c=us orclExcludedNamingcontexts: c=uk
Use ldapmodify to update the replication agreement orclupdateschedule attribute.
ldapmodify -D "cn=orcladmin" -w administrator_password -h consumer_host \ -p port -f mod.ldif
Restart the directory replication server.
LDAP-based replication agreement parameters are stored in replication agreement entries, which have the following DN:
orclAgreementID=unique_identifier_of_the_replication_agreement, orclReplicaId=unique_identifier_of_the_supplier, cn=replication configuration
|
Note: Ensure that the agreement is identical at both the supplier and the consumer. The replication server reads the last applied change number and the naming context from the agreement at the supplier node. It reads the other agreement attributes from the consumer. |
To view and modify replication agreement parameters by using Oracle Directory Manager:
In the navigator pane, expand in succession Oracle Internet Directory Servers, directory server instance, Replication Management, Replica Node: replica identifier.
Select the replica agreement you want to view or modify. The following tab pages appear in the right pane:
General, in which you can view and modify LDAP based replication agreement information. The fields in this tab page are described in Table A-23, "Columns in the Replica Agreements Tab Page".
Replica Naming Context, in which you can view, add, delete, and modify LDAP naming context objects. The fields in this tab page are described in Table A-24, "Fields in the Replica Agreement: Replica Naming Context Tab Page".
"Replication Schema Elements" in Oracle Identity Management User Reference describes the replication agreement parameters and indicates those that you can modify.
Example 31-9 Modifying the orclUpdateSchedule Attribute for a Particular Replica Agreement
The directory replication server uses the orclupdateschedule attribute value of the replica agreement entry as time interval in minutes to determine how often the replication server process the new change logs from the supplier.
This example shows that replication server will process new change logs from the supplier for every minute.
Edit the example file mod.ldif as follows:
dn: orclAgreementID=id_number,orclReplicaId=replica_identifier, cn=replication configuration Changetype:modify Replace: orclupdateschedule orclupdateschedule: 1
Use ldapmodify to update the replication agreement orclupdateschedule attribute.
ldapmodify -D "cn=orcladmin" -w administrator_password -h consumer_host \ -p port -f mod.ldif
Restart the directory replication server.
Example 31-10 Modifying the orclLastAppliedChangeNumber Attribute for a Particular Replica Agreement
The directory replication server uses the value orclLastAppliedChangeNumber attribute to determine the number of last applied change log processed by the consumer.
The modification of the orclLastAppliedChangeNumber attribute must be applied against the supplier node since replication server reads orclLastAppliedChangeNumber from the same duplicate agreement at the supplier.
In this example, orclLastAppliedChangeNumber attribute of the duplication agreement at the supplier is set to 700, which indicates all change logs with changelog number prior to 700 has been processed by the replication server.
|
Note: Do not modify theorclLastAppliedChangeNumber attribute except as instructed during the partial replication add node procedure. |
Edit the example file mod.ldif as follows:
dn: orclAgreementID=unique_identifier_of_the_replication_agreement, orclReplicaId=unique_identifier_of_the_supplier,cn=replication configuration Changetype:modify Replace: orclLastAppliedChangeNumber orclLastAppliedChangeNumber: 700
Use ldapmodify to update the replication agreement orclupdateschedule attribute at the supplier.
ldapmodify -D "cn=orcladmin" -w administrator_password \ -h supplier_host -p port -f mod.ldif
Restart the directory replication server.
You can change the password for the replication administrator database account on all nodes of a DRG using Oracle Database Advanced Replication by using the -chgpwd argument to the Replication Environment Management Tool, remtool. To use this argument, enter:
remtool -chgpwd
The remtool utility then prompts you for the MDS Global Name—that is, the name of the Master Definition Site—the current password, and the new password. It then asks you to confirm the new password. If you enter an incorrect current password, then you must run the Replication Environment Management Tool again.
You can also use the -pchgpwd argument to remtool to change the password of the replication DN of a replica.
To change the password only in the replication wallet, $ORACLE_HOME/dap/admin, use the -pchgwalpwd argument to remtool. To use this argument, enter:
remtool -pchgwalpwd
|
See Also: Theremtool command-line tool reference in Oracle Identity Management User Reference for more information about using this tool |
Oracle Directory Manager enables you to view the last 25 changes you performed, listing them by change log number, the type of operation—namely, add, modify, or delete—in which each occurred, and the entry on which each was made. It allows you select a particular change to see more specific details about it.
To manage the change log, in the navigator pane expand in succession Oracle Internet Directory Servers, directory server instance, then select Change Log Management. The right pane lists the last 25 changes, beginning with the most recent. It tells you the change number, the type of operation in which each change occurred, and the entry on which the change was made.
To see the details of a particular change, in the right pane, select the change, then choose View Properties. The Change Log window appears. The fields for the Change Log window are listed and described in Table A-27, "Fields in the Change Log Window".
In the default configuration for replication, the orclupdateschedule attribute is set to a value of 1, representing 1 minute. You can shorten the replication processing time by changing the value of the orclupdateschedule attribute to 0, representing 1 second.
In directory replication based on Advanced Replication, the default configuration achieves a processing time that is approximately 2.5 minutes:
1 minute for the supplier to prepare the change for sending to the consumer
30 seconds for Advanced Replication to push the change to the consumer
1 minute for the consumer to apply the change
In the case of Advanced Replication, changing the default value for the orclupdateschedule attribute to 0 results in a replication time of 32 seconds. To do this:
Edit mod.ldif as follows:
dn: orclagreementid=000001, cn=replication configuration, cn=replication configuration changetype:modify replace: orclupdateschedule orclupdateschedule: 0
Upload mod.ldif as follows:
ldapmodify -D "cn=orcladmin" -w administrator_password -h host_name -p port \ -v -f mod.ldif
Restart the directory replication server:
oidctl connect=connect_string server=oidrepld instance=instance_number restart
In LDAP-based directory replication, the default configuration achieves a processing time that is approximately 1 minute during which the change is retrieved from the supplier and applied to the consumer. Changing the default value for the orclupdateschedule attribute to 0 results in a replication time of 1 second. To do this:
Edit mod.ldif as follows:
dn: orclAgreementID=unique_identifier_of_the_replication_agreement, orclReplicaId=unique_identifier_of_the_supplier, cn=replication configuration changetype:modify replace: orclupdateschedule orclupdateschedule: 0
On the consumer host, upload mod.ldif as follows:
ldapmodify -h consumer_host_name -p consumer_port -D cn=orcladmin \ –w administrator_password -v -f mod.ldif
Restart the directory replication server
oidctl connect=connect_string server=oidrepld instance=instance_number restart
The Replication Environment Management Tool, remtool, enables you to monitor the health of the replication process. You can run remtool periodically to ensure that your replication processes are performing properly.
The remtool options for monitoring the health of the replication process are -pdipqstat and -pverify options to remtool. These are also known as the Display Queue Statistics Tool and the Replication Verification Tool. Their syntax is as follows:
remtool -pdispqstat [-v] [-bind hostname:port_number/replication_dn_password]
remtool -pverify [-v] [-bind hostname:port_number/replication_dn_password] [-hiqmax hiqmax] [-tbtmax tbtmax]
First run the Display Queue Statistics Tool. It will show the queue statistics of the DRG. Check to see if the number of Human Intervention Queue (HIQ) entries and change logs to be transported (Logs TBP) are higher than usual. If so, that means replication is running more slowly than it should. Run the Replication Verification Tool to verify your replication configurations.
If the Replication Verification Tool reports test failure, check the report that it generates and follow the suggestion in the report to fix the specific failures.
The compare and reconcile tool oidcmprec enables you to compare two directories. It detects and resolves conflicts. Of the two directories, one directory is considered to be the source directory or "source of truth." The other directory is the destination directory that needs to be synchronized with the source directory. The directories to be compared can be standalone directories, part of the same replication group, or part of different replication groups.
This section provides an introduction to the oidcmprec tool and some examples of oidcmprec usage. It includes the following topics:
Known Limitations of the oidcmprec Tool
|
See Also: The "oidcmprec" command reference inOracle Identity Management User Reference for the complete syntax foroidcmprec, including operations, conflict scenarios, and conflict resolution rules. |
The oidcmprec tool can detect and resolve the following conflict scenarios:
Entry only in source directory (entos)
Entry only in destination directory (entod)
Attribute only in source directory (atros)
Attribute only in destination directory (atrod)
Single-valued attribute differs (svatrdif)
Multi-valued attribute differs (mvatrdif)
Entry DN differs (dndif)
The dndif scenario can occur in a replication environment when a modrdn or moddn operation performed in one node is not replicated to another node. As a result, the entry has the same orclguid but different DNs on the two nodes. The tool uses the orclguid attribute to detect this conflict.
The oidcmprec tool can also detect and resolve the following schema conflict scenarios:
Object class definition exists only in source directory (odefos)
Object class definition exists only in destination directory (odefod)
Object class definition different in source and destination directory (odefdif)
Attribute definition exists only in source directory (adefos)
Attribute definition exists only in destination directory (adefod)
Attribute definition different in source and destination directory (adefdif)
The tool supports five operation. Each operation compares entries, detects conflicts, and optionally resolves them. The operations differ as to how they resolve conflicts. The operations are as follows:
Compare operation: compares two directories and stores the changes as LDIF records in a file. The LDIF file can be applied to the destination directory to make it identical to the source directory. Only the data in the source directory is considered valid.
Reconcile operation: compares two directories and applies necessary changes at the destination directory to make it identical to the source directory. All the changes made to the directory are stored as LDIF records in a file. Only the data in the source directory is considered valid.
Merge or two-way reconcile operation: compares two directories and applies necessary changes at the source or destination directory to make them identical. The data in both directories is considered valid. For example, when the tool detects that an entry exists only in the destination directory, the tool adds it to the source. This operation also records all the changes applied to the directory as LDIF records in a file.
Merge dry run operation: compares two directories, similar to the merge operation, but does not apply the changes in the directory. Instead, it stores the changes as LDIF records in a file. The changes to be applied to the source directory and to destination directory are stored in two different files.
User defined compare and reconcile operation: uses conflict resolution rules that you choose for each conflict scenario. See Oracle Identity Management User Reference for a list of conflict resolution rules you can use for each conflict scenario.
The oidcmprec tool generates the following files for every operation:
filename.rpt: contains the DNs of all entries compared and the compare result.
filename.s2d.ldif: contains all changes applied to the destination directory or stored for later application to the destination directory. The name is an abbreviation for source directory to destination directory.
filename.d2s.ldif: contains all changes applied to the source directory or stored for later application to the source directory. The name is an abbreviation for destination directory to source directory.
filename.eos.rpt: lists DNs of entries that exist only in the source directory. It also lists name of attributes and object classes that are defined only in the source directory, if the schema is included for the operation.The name is an abbreviation for entries available only in source directory.
filename.eod.rpt: lists DNs of entries that exist only in the destination directory. It also lists name of attributes and object classes that are defined only in the destination directory, if the schema is included for the operation. The name is an abbreviation for entries available only in destination directory.
filename.dif.rpt: lists DNs of all entire that differ along with names of attribute that differ. It also lists name of attributes and object classes whose definitions differ, if the schema is included for the operation. This file is known as dif file.
filename.err: contains all error messages. This file is known as err file.
Using the replication DN and replication DN password as credentials, the tool performs three tasks. First it loads schema information into memory. Next, it collects the entries to be compared and it compares them, attribute by attribute. The tool uses schema information to determine the compare rule to be used for each attribute. Then, based on the compare result, the tool takes the necessary actions. These operations are performed by different threads:
The DN thread is responsible for collecting entries to be compared. While collecting entries, it does not fetch the entire tree at once. It first fetches the base entry and processes it. Then it fetches the immediate children of the base entry and processes them, and then their immediate children, and so on. The collected entries are passed on to worker threads. You can control the number of DN threads using the dnthreads argument.
The worker thread is responsible for comparing entries attribute by attribute and applying conflict resolution rules. The worker thread then passes on the entry to the log writer thread. You can control the number of worker threads by using the threads argument. The total number of worker threads and DN threads cannot exceed a maximum value equal to 6 * (Number of CPUs) - 2. If you specify more than that, the tool adjusts the number of worker and DN threads so as not to exceed the maximum.
The log writer thread is responsible for writing the contents to all seven output files listed in"Output from oidcmprec". There is only one log writer thread. You cannot increase the number.
These threads are spawned, monitored and terminated by the main thread. The main thread processes command line arguments and parameter files and spawns the other threads. As soon as the main thread detects that all operations are complete, it terminates all threads and cleans up all connections.
Each thread establishes an LDAP connection to the source directory and to the destination directory. These connections remain open until all operations are completed by the thread. If a connection is closed for any reason, the tool will try to reestablish connection if the contonerr argument is set to TRUE. If the tool can reestablish the connection, it continues operation.
|
Note: Use thecontonerr argument to specify whether the tool should continue processing on error. This argument can be set to TRUE or FALSE. By default it is set to TRUE. |
You use the source and destination options to set the source and destination directories.
oidcmprec source=staqj13:3060 destination=staqj:3070 base="''" \
scope=subtree file=temp operation=compare
The tool prompts for passwords if they are not provided on the command line:
Enter replication DN password of the source directory : Enter replication DN password of the destination directory :
Use the base, dns2exclude, and scope options to choose the area to be compared and reconciled.
This example compares the entire directory except c=us,dc=mycom,dc=com and c=uk,dc=mycom,dc=com:
oidcmprec base="''" \
dns2exclude="'c=us,dc=mycom,dc=com' 'c=uk,dc=mycom,dc=com'" \
operation=compare scope=subtree \
source=myhost1.mycom.com:389/replication_dn_pwd \
destination=myhost2.mycom.com:389/replication_dn_pwd \
threads=5 dnthreads=2 file=cmpres
This example compares the naming contexts dc=com and dc=org except for the trees c=us,dc=mycom,dc=com and c=uk,dc=myorg,dc=org.
oidcmprec base="'dc=com' 'dc=org'" \
dns2exclude="'c=us,dc=mycom,dc=com' 'c=uk,dc=myorg,dc=org'" \
operation=compare scope=subtree \
source=myhost1.mycom.com:389/replication_dn_pwd \
destination=myhost2.mycom.com:389/replication_dn_pwd \
threads=5 dnthreads=2 file=cmpres
By default, oidcmprec compares all attributes except for the operational attributes creatorsname, createtimestamp, modifiersname, modifytimestamp, orclentrydn, and orclnormdn. You can control the attributes to be included or excluded for the chosen operation using exclattr or inclattr, respectively. The exclattr and inclattr arguments allow limited pattern matching. You can use attributename* to match all attributes starting with attributename. You can also use attributename;* to match all subtypes of attributename.
This example excludes the authpassword attribute with and without subtype, plus the attributes userpassword and category, in addition to the standard excluded attributes.
oidcmprec operation=compare scope=subtree base="'dc=com' 'dc=org'" \
source=myhost1.mycom.com:389/replication_dn_pwd \
destination=myhost2.mycom.com:389/replication_dn_pwd \
exclattr="authpassword authpassword;* userpassword category" \
threads=5 dnthreads=2 file=compare
This example includes only the attributes uid, cn, sn, givenname, and mail in the compare operation.
oidcmprec operation=compare scope=subtree base="'dc=com'" \
source=myhost1.mycom.com:389/replication_dn_pwd \
destination=myhost2.mycom.com:389/replication_dn_pwd \
inclattr="uid cn sn givenname mail" \
file=compare
This example includes all attributes for the compare operation except orclguid, creatorsname, and modifiersname. This example also asks the tool to stop when it encounters any error by setting contonerr=false.
oidcmprec operation=compare scope=subtree base="'dc=com'" \
source=myhost1.mycom.com:389/replication_dn_pwd \
destination=myhost2.mycom.com:389/replication_dn_pwd \
inclattr="*" exclattr="orclguid creatorsname modifiersname" \
file=compare contonerr=false
Change log generation for the changes made by oidcmprec depends on the value of the orcldiprepository attribute of the root DSE. Change log generation behavior, however, can be controlled by using the genchglog argument. The genchglog argument can have the following values:
default: The directory server settings determine whether a change log is generated or not. Change logs are generated if the root entry's orcldiprepository attribute is set to true. They are not generated if orcldiprepository is set to false. The same rule applies for both the source and destination directories. default is the default value for gechglog.
true: Change logs are always generated, irrespective of the settings on the source and destination directories.
false: Change logs are never generated, irrespective of the settings on the source and destination directories.
In the following example, genchglog=false to turns off change log generation:
oidcmprec operation=merge scope=subtree base="'dc=com'" \
source=myhost1.mycom.com:389/replication_dn_pwd \
destination=myhost2.mycom.com:389/replication_dn_pwd \
inclattr="*" exclattr="orclguid creatorsname modifiersname" \
file=merge genchglog=false
All the arguments that can be given on the oidcmprec command line can also be stored in a parameter file. You can input the parameter file using the paramfile option. If you specify an argument both on the command line and in the parameter file, the argument specified on the command line takes precedence over the one specified in the parameter file. For example:
oidcmprec paramfile=comp_param threads=4
This example uses the following sample parameter file:
############################################# #Parameter file for compare and reconcile tool #Creator : John #Date : 21-Mar-2006 #File Name : comp_param ############################################# operation=compare source=staqj13:3060/ods destination=staqj13:3070/ods base="cn=oraclecontext" base="c=uk,dc=mycom,dc=com" base="c=us,dc=mycom,dc=com" verbose=false force=true threads=6 dnthreads=2 exclattr="orclguid userpassword authpassword authpassword;*" filename=cmp2006Feb01
In this example, the tool spawns four worker threads. It gives precedence to command line arguments.
You can include the schema in an oidcmprec operation by including cn=subschemasubentry in the base argument. For example:
oidcmprec operation=merge scope=subtree \
base="'dc=com' 'cn=subschemasubentry'" \
source=myhost1.mycom.com:389/replication_dn_pwd \
destination=myhost2.mycom.com:389/replication_dn_pwd \
inclattr="*" exclattr="orclguid creatorsname modifiersname" \
file=merge genchglog=false
If you include other DNs in addition to the schema, oidcmprec performs the operation on the schema first.
Conflict scenarios and conflict resolution rules for each operation are described in the "oidcmprec" command reference in Oracle Identity Management User Reference.
You can override the predefined conflict resolution rules by specifying the conflict name and the rule to use in the command line or parameter file. The following example changes the conflict resolution rule used for the conflicts dndif and mvatrdif to ignore for the compare operation:
oidcmprec operation=compare source=host1:3060 destination=host2:3070 \
base="''" scope=subtree file=temp operation=compare \
dndif=ignore mvatrdif=ignore
In addition to the predefined operations compare, reconcile, merge, and merge dry run, oidcmprec has a user-defined compare and reconcile operation, userdefinedcr, that enables you to specifying conflict resolution rule arguments. Any conflict resolution rule you do not specify with userdefinedcr defaults to ignore. The following command line uses the userdefinedcr operation:
oidcmprec operation=userdefinedcr scope=subtree \
base="'dc=com' 'dc=org'" \
source=myhost1.mycom.com:389/replication_dn_pwd \
destination=myhost2.mycom.com:389/replication_dn_pwd \
entos=add entod=ignore atros=add atrod=ignore \
svatrdif=usesrc mvatrdif=usesrc dndif=ignore \
threads=5 dnthreads=2 file=myreconcile
Conflict scenarios and conflict resolution rules are described in the "oidcmprec" command reference in Oracle Identity Management User Reference.
The oidcmprec tool has the following limitations:
When the tool logs changes to LDIF records in the filename.s2d.ldif or filename.d2s.ldif file for deletion of a tree, it logs the parent record first, followed by its children. If you attempt to apply this change using the ldapmodify command-line tool, it will fail, as the directory server will not allow deletion of non-leaf entry. To prevent ldapmodify from failing, edit the file to reorder the records before running ldapmodify.
When the tool performs a delete operation on a entry, it deletes that entry and its children. The tool records that the entry was deleted, but does not log that its children were also deleted.
The tool has limitations with respect to compound RDNs. These are RDNs that contain two or more attribute=attrvalue pairs, separated by a +, for example:
uid=jpaul + cn=john paul + mail=john.paul@oracle.com,dc=oracle,dc=com
If one of the directories you are comparing contains a compound RDN, when the tool suggests modrdn/moddn changes in the filename.s2d.ldif or filename.d2s.ldif file, the deleteoldrdn value might be incorrect.
