Release 2.1.1
Part Number A86101-01
 Library |
 Product |
 Contents |
 Index |
| Oracle Internet Directory Administrator's Guide Release 2.1.1 Part Number A86101-01 |
|
Replication is the mechanism that maintains exact duplicates of specified naming contexts on multiple nodes.
This chapter contains these topics:
This section describes how to install and initialize Oracle directory replication server software on a node.
Each node in a group of DSAs holds an updatable copy, also called an updatable replica, of the same set of naming contexts. These naming contexts are synchronized with each other by replication processing. This group of nodes is called a directory replication group (DRG).
|
Note: The instructions in this section apply to setting up replication in a group of empty nodes. For instructions on adding a node to an existing DRG, see "Adding a Replication Node". |
To install and configure a replication group, perform these general tasks:
Task 1: Install Oracle Internet Directory on All Nodes in the DRG
Task 2: Decide Which Node Will Serve as the ASR Master Definition Site (MDS)
Task 3: At the MDS, Set Up ASR for a Directory Replication Group
Task 4: Start Oracle Directory Server Instances on All the Nodes
Task 6: Start the Replication Servers on All the Nodes
Note that the typical installation of the Oracle8i Enterprise Edition, which is required for the Oracle Internet Directory, includes Oracle Advanced Symmetric Replication (ASR). By contrast, a typical installation of Oracle8i Standard Edition does not include ASR.
A master definition site (MDS) is any of the Oracle Internet Directory databases in which the administrator is going to run the configuration scripts. A remote master site is any site other than the Master Definition Site that participates in ASR replication.
You must be able to use Net8 to connect to the MDS database and all other nodes that constitute the DRG.
The following sections lead you through installing and configuring ASR through Oracle Internet Directory installation scripts. More advanced ASR users may prefer to configure ASR through the Oracle8i Replication Manager Tool.
Setting up the Oracle Advanced Symmetric Replication (ASR) environment to establish a Directory Replication Group (DRG) requires you to:
Follow these steps, described more fully below, on all nodes in the Directory Replication Group to prepare the Net8 environment:
To prepare the Net8 environment for replication:
sqlnet.ora.
The sqlnet.ora file should contain the following parameters at minimum:
names.directory_path = (TNSNAMES) names.default_domain = domain
On UNIX, this file is in $ORACLE_HOME/network/admin
On Windows NT, this file is in ORACLE_HOME\network\admin
tnsnames.ora.
The tnsnames.ora file must contain connect
descriptor information in the
following format for all Oracle Internet Directory databases:
net_service_name = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = HOST_NAME_OR_IP_ADDRESS) (PORT = 1521)) (CONNECT_DATA = (service_name = service_name))
On UNIX, this file is in $ORACLE_HOME/network/admin
On Windows NT, this file is in ORACLE_HOME\network\admin
You may want to create multiple rollback segments. You can increase the size of the table spaces and segments to meet your system requirements.
a. Create a tablespace for rollback segments.
Execute SQL*Plus by typing the following command:
sqlplus system/system_password@net_service_name
At the SQL*Plus prompt, type:
CREATE TABLESPACE table_space_name
datafile file_name_with_full_path SIZE 50M REUSE AUTOEXTEND ON NEXT
10M MAXSIZE max_bulk_update transaction_size ex:500M;
b. Create rollback segments.
At the SQL*Plus prompt, type the following lines for each rollback segment:
CREATE ROLLBACK SEGMENT rollback_segment_name tablespace table_space_name storage (INITIAL 1M NEXT 1M OPTIMAL 2M MAXEXTENTS UNLIMITED);
Repeat the CREATE ROLLBACK SEGMENT command
for each rollback segment entered in the initialization parameter
file.
init.ora.
Type the following lines in the initialization parameter file:
rollback_segments = (rollback_segment_name_1, rollback_segment_name_2 ...) JOB_QUEUE_PROCESSES = a_minimum_of_total_number_of_LDAP_nodes_minus_one SHARED_POOL_SIZE = 20000000 OPEN_LINKS = a_minimum_of_total_number_of_LDAP_nodes_minus_one
Ensure that the total System Global Area (SGA) does not exceed 50% of your system's physical memory.
To stop the listener for the Oracle Internet Directory database, use the listener control utility (lsnrctl). Type the following command at the LSNRCTL command prompt:
SET PASSWORD password STOP [listener_name]
SET PASSWORD is required only if the password
is set in the listener.ora file. The password defaults to
ORACLE. The default listener name is LISTENER.
To restart the listener for the Oracle Internet Directory database, type the following command at the LSNRCTL command prompt:
START [listener_name]6. Stop and restart the Oracle Internet Directory database.
To stop and restart the Oracle Internet Directory
database, you can use SQL*Plus.
See
Also:
To configure ASR for the replication group, complete the following steps from the MDS:
$ORACLE_HOME/ldap/bin
\ldap\bin
ldaprepl.sh -asrsetup
This script executes a number of operations.
As the script runs, it asks for the information in the following table, first for the MDS, then for the master sites.
| Information | Definition |
|---|---|
|
Host name |
Name of the computer |
|
Global name |
Net service name of the MDS database, as listed
in the file |
|
System password |
system password |
After you have provided the necessary information for the first master site, the script asks if there is another master site.
Y
or N. If you enter N, to indicate that you
have identified all sites, then it shows a table of the information
you have provided, and asks for confirmation. If it is not correct,
then press N. The script will start again at the beginning,
asking about the MDS again.
After you have provided all the information, the script
asks you to verify the correctness of the information. If the information
is correct and you press Y, then the script begins configuring
the sites.
This process may take a long time, depending on your system resources and the number of nodes in your DRG. The script keeps you informed of its progress.
|
Troubleshooting Tip: If the process fails, then do the following:
Run this command for each node in the DRG. Issuing this command should result in no rows being selected. If rows are selected containing the failed status and error messages, then this means that ASR set up failed. In this case, you may:
|
| See
Also:
|
To start Oracle directory server instances on all nodes, run the following command:
oidctl connect=net_service_name server=oidldapd instance=instance_number_of_ ldap_server flags="-p port" start
| See
Also:
Chapter 5, "Managing an Oracle Directory Server" for more information on starting an Oracle directory server instance |
You need to configure parameters for:
|
Important: When you install and configure replication for the
first time, you must inform the Oracle directory replication server
about the existence of the member nodes in the replication agreement.
To do this, modify the |
The Oracle directory replication server configuration 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. Note that the orclDirReplGroupAgreement
attribute contains a replication agreement identifier. In this release,
only one replication agreement is possible.
The next table lists and describes the Oracle directory replication server configuration parameters.
| Parameter name | Description | Default Values | Modifiable? |
|---|---|---|---|
|
modifyTimestamp |
Time of entry creation or modification |
|
No |
|
modifiersName |
Name of person creating or modifying the entry |
|
No |
|
orclChangeRetryCount |
Single-valued attribute. The number of processing retry attempts for a change-entry before being dropped. The value for this parameter must be equal to or greater than 1 (one). |
10 |
Yes |
|
orclPurgeSchedule |
Single-valued attribute. Specifies purge (garbage collection) interval in minutes. Removes entries that are already applied or have been dropped as candidate changes. This thread is initiated periodically based on the frequency that you set. The value for this parameter must be equal to or greater than 1 (one). |
10 minutes |
Yes |
|
orclThreadsPerSupplier |
Number of worker threads Oracle directory replication server provides for each supplier for change log processing. The value for this parameter must be equal to or greater than 1 (one). |
5 |
Yes |
|
orclDirReplGroupAgreement |
Multi-valued attribute. Identifies the symmetrical replication agreements for which this server is responsible. |
orclagreementid=000001, |
No |
|
orclChangeLogLife |
Single-valued attribute. Specifies in hours the time for the life of entries in the change log store. 0 (zero) indicates that this is a change number-based purge. See Also: "Change Log Purging" |
0 |
Yes |
To view and modify replication configuration parameters:
Configuration parameters appear in the General tab page. You can use this tab page to view replication configuration parameters, and modify many of them. The following table describes the fields in this tab page.
| Field | Description |
|---|---|
|
Modify Timestamp |
Time of entry creation or modification in UTC (Coordinated Universal Time). You cannot modify this parameter. |
|
Modifier's Name |
Name of person creating or modifying the entry. You cannot modify this parameter. |
|
Change Retry Count |
Type the number of attempts that the conflict resolution process tries to apply each update before giving up and logging the incident. The default is 10. |
|
Purge Schedule |
Type the number of minutes in between garbage collections. The replication garbage collection thread removes entries that are already applied or have been dropped as candidate changes. The default is 10. |
|
Number of Threads Per Supplier |
Type the number of worker threads the Oracle directory replication server provides for each supplier for change log processing. The default is 5. |
|
Set |
Type the configuration identifier. |
|
Change Log Life |
Type the number of hours for the life of the change log objects. See Also: "Change Log Purging" |
To modify replication configuration parameters by using command line tools, use the syntax documented in "ldapmodify Syntax".
This example uses an input file named mod.ldif
to change the garbage collection interval from the default of 10 minutes
to 30 minutes.
mod.ldif
as follows:
dn: cn=configset0,cn=osdrepld,cn=subconfigsubentrychangetype: modifyreplace:orclPurgeSchedule orclPurgeSchedule: 30
configset0 parameter value
as follows:
ldapmodify -h host -p port -f mod.ldif
This example uses an input file named mod.ldif
to change the change log life parameter to 10:
mod.ldif
as follows:
dn: cn=configset0,cn=oidrepld,cn=subconfigsubentry changetype: modify replace: orclChangeLogLife orclChangeLogLife: 10 hours
configset0 parameter value
as follows:
ldapmodify -h host -p port -f mod.ldif
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.
mod.ldif
as follows:
dn: cn=configset0,cn=osdrepld,cn=subconfigsubentrychangetype: modifyreplace: orclChangeRetryCountorclChangeRetryCount: 5
configset0 parameter value
as follows:
ldapmodify -h host -p port -f mod.ldif
This example uses an input file named mod.ldif
to change the number of worker threads used in change log processing:
mod.ldif
as follows:
dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry changetype: modify replace: orclthreadspersupplier orclthreadspersupplier: new_number_of_worker_threads
configset0 parameter value
as follows:
ldapmodify -h host -p port -f mod.ldif
"Restarting Directory
Server Instances" for
instructions on restarting the Oracle directory replication
server
See
Also:
In the parameter DirectoryReplicationGroupDSAs,
type all of the host names of the DSAs in the DRG. Be sure that this information
is identical on all the nodes.
Replication agreement parameters are stored in the replication agreement entries which have the following DN:
orclAgreementID=id number,cn=orclreplagreements
This entry contains attributes that pertain only to the nodes participating in this agreement. You can create multiple replication agreements to manage replication between reciprocating nodes, but you can reference only one of them in your start-server message by using Oracle Directory Manager. For Oracle Internet Directory release 2.1.1, only one replication agreement can be used.
The following table lists and describes the replication agreement parameters.
To view and modify replication agreement parameters by using Oracle Directory Manager:
The fields in this tab page are described in the following table. You can view the parameters and modify some of them by double-clicking the attributes.
.
The following table lists and describes the replication agreement parameters.
To add more nodes to the values in a replication agreement entry, run ldapmodify at the command line, referencing an LDIF-formatted file.
This example uses an input file named mod.ldif
to add two nodes to a replication agreement:
mod.ldif
as follows:
dn: orclagreementid=000001,cn=orclreplagreementschangetype: modifyadd: orcldirreplgroupdsasorcldirreplgroupdsas: hollisorcldirreplgroupdsas: eastsun-11
configset0 parameter value
as follows:
ldapmodify -h host -p port -f mod.ldif
This procedure modifies the entry containing the replication
agreement whose DN is orclagreementid=000001,cn=orclreplagreements.
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 above sample LDIF file--in the "Adding a Replication Node" explains the process of adding a new node to a replication environment. |
Because Oracle Internet Directory release 2.1.1 supports only one configuration set for Oracle directory replication server, you do not need to specify a configuration set.
To start replication servers on all nodes, type the following command:
oidctl connect=db_connection_string server=oidrepld instance=1
flags="-h host -p port" start
Note that the instance number does not need to be unique across the entire DRG.
| See
Also:
Chapter 5, "Managing an Oracle Directory Server" for information on starting the replication servers |
You can turn off change logging, which occurs in the Oracle
directory server, by using the default value of the -l flag
in the OID Control Utility command for Oracle directory server from true
to false. This is useful if you suspect that the
change log file might not be emptying. However, turning change logging
off on a given node means that updates on that node cannot be replicated
to other nodes in the DRG.
You can turn off the multimaster flag, which occurs in the
Oracle directory replication server, by using the default value of the
-m flag in the OID Control Utility command for Oracle directory
server from true to false.
This is useful for reducing performance overhead if you are deploying
a single master with read-only replica consumers. The multimaster option
controls conflict resolution, which serves no purpose if you are deploying
a single master.
This method, described in this section, is the easier of the two. The process can be fully automated, and the generated file can be used for partial replication. Use this procedure unless your directory is very large. Backup using this method can take up to seven hours for a directory with one million entries.
This method, described in Appendix B, "Adding a DSA Using the Database Copy Procedure", cannot be fully automated and cannot be reused for partial replication. However, cold backup takes much less time for a large directory server. If your directory has, say, more than a million entries, then use this method.
|
Note: Before you add a replication node, prepare the Net8 environment. For instructions, see "Prepare the Net8 Environment for Replication". |
To add a replication node to a functioning DRG of any significant size, follow these steps, each of which is more fully described later in this chapter.
Task 1: Stop the Oracle Directory Replication Server on All Nodes
Task 2: Configure the New Node into the LDAP Replication Group on All the Existing Nodes
Task 3: Identify a Sponsor Node and Switch the Sponsor Node to Read-Only Mode
Task 4: Backup the Sponsor Node by Using ldifwrite
Task 5: Perform ASR Add Node Setup
Task 6: Switch the Sponsor Node to Updatable Mode
Task 7: Start the Oracle Directory Replication Server on All Nodes Except the New Node
Task 8: Load Data into the New Node by Using bulkload
Task 9: Start LDAP Server on the New Node
Task 10: Configure the LDAP Replication Agreement on the New Node
Task 11: Start the Oracle Directory Replication Server on the New Node
To stop the Oracle directory replication server, run the following command on each node in the LDAP replication group:
oidctl connect=db_connect_string server=oidrepld instance=1 stop
The following example creates an LDIF file, add_node.ldif,
and configures it into the replication group on all the existing nodes.
dn: orclagreementid=000001,cn=orclreplagreements changetype: modify replace: orcldirreplgroupdsas orcldirreplgroupdsas: host_name_of_the_new_node orcldirreplgroupdsas: host_name_of_existing_node_1 orcldirreplgroupdsas: host_name_of_existing_node_2 . . . orcldirreplgroupdsas: host_name_of_existing_node_n
Run the following command against each node in the LDAP replication group:
ldapmodify -h host_name_of_the_node -p port -f add_node.ldif
A sponsor node is one that will supply the data to the new node. To identify a sponsor node and switch it to read-only mode:
change_mode.ldif, containing the following:
dn: changetype: modify replace: orclservermode orclservermode: r
ldapmodify -D "cn=orcladmin" -w welcome -h host_name_of_sponsor_node
-p port -f change_mode.ldif oidctl connect=net_service_name server=oidldapd restart
This restarts all running Oracle directory servers on the sponsor node in Read-Only mode. It takes approximately fifteen seconds for a directory server to restart.
Because this may take a long time, you may start "Task 5: Perform ASR Add Node Setup" while backup is in process.
Enter the following command:
ldifwrite -c db_connect_string -b "" -f output_ldif_file
You can perform this task at the same time as you are performing "Task 4: Backup the Sponsor Node by Using ldifwrite".
From the sponsor node, run the following script:
ldaprepl.sh -addnode
This script executes a number of operations.
As the script runs, it asks for the information in Table 10-1, first for the sponsor node then for the existing master sites.
| Information | Description |
|---|---|
|
Host Name of sponsor node |
Name of the computer |
|
Global name |
Net service name of the MDS or master site database, as listed in |
|
system password |
system password |
When you have identified all the existing master sites, enter N. The script then asks for information regarding the new node. Once you have provided that information, the script shows you a table of the information you have provided, and asks for confirmation.
If the information is not correct, then press N. The script then starts again at the beginning, asking the same information. If the information is correct and you enter Y, then the script begins configuring the sites.
This process can take a long time, depending on your system resources and the size of your DRG. The script keeps you informed of its progress.
|
Troubleshooting Tip: If the process fails, then do the following:
Run this command for each node in the DRG. Issuing this command should result in no rows being selected. If rows are selected containing the status [failed] and error messages, then this means that ASR set up failed. In this case, you may:
|
To switch the sponsor node to updatable mode:
change_mode.ldif to the following:
dn: changetype: modify replace: orclservermode orclservermode: rw
ldapmodify -D "cn=orcladmin" -w welcome -h host_name_of_sponsor_node
-p port -f change_mode.ldif oidctl connect=net_service_name server=oidldapd restart
To start the Oracle directory replication server, type the following command:
oidctl connect=db_connection_string server=oidrepld instance=1
flags="-h host -p port" start
Verify that no directory or replication processes are running on the new node.
To load data, type the following command:
bulkload.sh -connect db_connect_string_of_new_node -generate -load
-restore absolute_path_to_the_ldif_file_generated_by_ldifwrite
To start the LDAP server, type the following command:
oidctl connect=db_connect_string_of_new_node server=oidldapd
instance=1 flags="-p port" start
Run the following command against the new node:
ldapmodify -h host_name_of_the_new_node -p port -f add_node.ldif
To start the Oracle directory replication server, type the following command:
oidctl connect=db_connect_string_of_new_node server=oidrepld instance=1
flags="-h host_name_of_new_node -p port" start
You can delete a replication node from a DRG only if there are more than two nodes in the DRG.
To delete a replication node from a directory with fewer than a million entries, follow these steps, each of which is more fully described later.
Task 1: Stop the Oracle Directory Replication Server on All Nodes
Task 2: Stop All Processes in the Node to be Deleted
Task 3: Delete the Node from the Master Definition Site
Task 4: Start the Oracle Directory Replication Server on All Nodes
Task 5: Delete the Node from the Replication Group
Task 6: Restart the Oracle Directory Replication Server on the Remaining Nodes
To stop the Oracle directory replication server, run the following command on each node in the DRG:
oidctl connect=net_service_name server=oidrepld instance=1 stop
Stop the OID Control Utility and the OID Monitor.
|
See Also:
|
From the MDS, run the following script:
ldaprepl.sh -delnode
This script executes these operations:
orclDirReplGroupDSAs parameter.
As the script runs, it asks for the information in Table 10-2, first for the Master Definition Site then for the node to be deleted.
| Information | Description |
|---|---|
|
Host Name of MDS or master site |
Name of the computer |
|
Global name |
Net service name of the MDS or master site database, as listed in |
Once you have provided that information, the script shows you a table of the information you have provided, and asks for confirmation. If the information is not correct, then press N. The script then starts again at the beginning, asking the same information. If the information is correct and you enter Y, then the script begins configuring the sites.
This process can take a long time, depending on your system resources and the size of your DRG. The script keeps you informed of its progress.
|
Troubleshooting Tip: If the process fails, then do the following:
Run this command for each node in the DRG. Issuing this command should result in no rows being selected. If rows are selected containing the status [failed] and error messages, then this means that ASR set up failed. In this case, you may:
|
To start the Oracle directory replication server, type the following command:
oidctl connect=net_service_name server=oidrepld instance=1
flags="-h host -p port" start
Before deleting the node from the replication group, be sure that all of its changes have been applied to the other nodes.
The following example creates an LDIF file, delete_node.ldif, and configures it into the replication group on all the existing nodes. Notice that this LDIF file does not include the host name of the node to be deleted.
dn: orclagreementid=000001,cn=orclreplagreements changetype: modify replace: orcldirreplgroupdsas orcldirreplgroupdsas: host_name_of_existing_node1 orcldirreplgroupdsas: host_name_of_existing_node2 . . . orcldirreplgroupdsas: host_name_of_existing_node_n
Run the following command against each node in the LDAP replication group:
ldapmodify -h host_name_of_the_node -p port -f delete_node.ldif
After deleting the node, restart the Oracle directory replication server on the remaining nodes for greater efficiency. To do this, type the following command:
oidctl connect=db_connection_string server=oidrepld instance=1
flags="-h host -p port" restart
This section contains these topics:
If a conflict has been written into the log, then it means that the system is not able to resolve it by following its resolution procedure. To avoid further replication change conflicts arising from earlier unapplied changes, it is important to monitor the logs regularly.
To monitor replication change conflicts, examine the contents of the replication log. You can distinguish between messages by their respective timestamps.
Conflict resolution messages, examples of which are shown below, are logged in the file oidrepld00.log. The path for this file is ORACLE_HOME/ldap/log. The result of each attempt to resolve the replication conflict is displayed at the end of each conflict resolution message.
2000/08/03::10:59:05: ************ Conflict Resolution Message ************ 2000/08/03::10:59:05: Conflict reason: Attempted to modify a non-existent entry. 2000/08/03::10:59:05: Change number:1306. 2000/08/03::10:59:05: Supplier:eastlab-sun. 2000/08/03::10:59:05: Change type:Modify. 2000/08/03::10:59:05: Target DN:cn=ccc,ou=Recruiting,ou=HR,ou=Americas,o=IMC,c=US. 2000/08/03::10:59:05: Result: Change moved to low priority queue after failing on 10th retry.
2000/08/03::10:59:05: ************ Conflict Resolution Message ************ 2000/08/03::10:59:05: Conflict reason: Attempted to add an existing entry. 2000/08/03::10:59:05: Change number:1209. 2000/08/03::10:59:05: Supplier:eastlab-sun. 2000/08/03::10:59:05: Change type:Add. 2000/08/03::10:59:05: Target DN:cn=Lou Smith, ou=Recruiting, ou=HR, ou=Americas, o=IMC, c=US. 2000/08/03::10:59:05: Result: Deleted duplicated target entry which was created later than the change entry. Apply the change entry again.
2000/08/03::10:59:06: ************ Conflict Resolution Message ************ 2000/08/03::10:59:06: Conflict reason: Attempted to delete a non-existent entry. 2000/08/03::10:59:06: Change number:1365. 2000/08/03::10:59:06: Supplier:eastlab-sun. 2000/08/03::10:59:06: Change type:Delete. 2000/08/03::10:59:06: Target DN:cn=Lou Smith,ou=recruiting,ou=hr,ou=americas,o=imc,c=us. 2000/08/03::10:59:06: Result: Change moved to low priority queue after failing on 10th retry.
The human intervention queue manipulation tool enables you to move the changes from the human intervention queue to either the retry queue or the purge queue. Moving the change to the purge queue means that there are no further attempts to re-apply the changelog entry. Perform the following general steps to address changes in the human intervention queue:
To place a change back into the retry queue, use this syntax:
hiqretry.sh -connect net_service_name [-start change_number]
[-end change_number] [-equal change_number] -supplier supplier_node
The arguments are:
To place a change into the purge queue, use this syntax:
hiqpurge.sh -connect net_service_name [-start change_number] [-end change_ number] [-equal change_number] -supplier supplier_node
Arguments are:
The following examples illustrate how to use the human intervention queue manipulation tool.
Suppose that, after analyzing the replication log, you decide to do the following:
To do this, you issue these two commands:
hiqretry.sh -connect oiddb1 -start 10324 -end 10579 -supplier ldap_rep1 hiqpurge.sh -connect oiddb1 -start 10581 -end 10623 -supplier ldap_repl
The first command moves changes originating in ldap_rep1 with change numbers from 10324 to 10579 back to the retry queue. The second command deletes changes that originate in the supplier ldap_repl and that have change numbers from 10581 to 10623.
The following command moves the change with change number equal to 10519 back to the retry queue.
hiqretry.sh -connect oiddb1 -equal 10519 -supplier ldap_repl
The following command moves all the changes with change number greater or equal to 10324 back to the retry queue.
hiqretry.sh -connect oiddb1 -start 10324 -supplier ldap_repl
The following command moves all the changes with change numbers less than or equal to 10579 back to the retry queue.
hiqretry.sh -connect oiddb1 -end 10579 -supplier ldap_repl
The following command includes no options. It moves all changes that originate in the supplier ldap_repl from the Human Intervention Queue to the retry queue.
hiqretry.sh -connect oiddb1 -supplier ldap_repl
When the Oracle directory replication server encounters inconsistent data, you can use the OID reconciliation tool to synchronize the entries on the consumer with those on the supplier. When you do this, perform the following general steps:
The OID reconciliation tool uses this syntax:
oidreconcile -h supplier_host -c consumer_host [-P supplier_port] [-p consumer_ port] [-s scope] -b basedn -W supplier_password -w consumer_password [-T thread]
When the OID reconciliation tool receives the specified DN, it compares the orclGuid of the parent DN on both the supplier and the consumer.
If the global identification (orclGuid) of both parents match, and the option -s subtree is set, then the OID reconciliation tool does the following:
For example, the following command replaces the whole subtree starting from "ou=hr,o=acme,c=us" on the consumer with the equivalent subtree on the supplier:
oidreconcile -h supplier_host -P 389 -c consumer_host -p 389 -b "ou=hr,o=acme,c=us" -s subtree -W supplier_password -w consumer_password
If the global identification (orclGuid) of both parents ("o=acme,c=us") match, and -s subtree is not set, then the OID reconciliation tool replaces only the entry itself on the consumer node with the specified entry from the supplier node.
For example, the following command, in which the option "-s subtree" is not set, replaces only the specified entry, "ou=hr,o=acme,c=us".
oidreconcile -h supplier -P 389 -c consumer -p 389 -b "ou=hr, o=acme, c=us"
-W supplier_password -w consumer_password
Figure 10-1 helps to explain how this process works.
This figure shows two DITs, one on a supplier node and one on a consumer node. In the DIT on the supplier node, the orclGuid for c=us is 1 (one), the orclGuid for o=acme is 10, and the orclGuid for ou=st is 15. On the consumer node, the orclGuid for o=acme is 5, and the orclGuid for ou=st is 7.
The orclGuids for the parent of o=acme,c=us--namely, c=us--on both the supplier and the consumer match. Therefore, the following command replaces all entries under o=acme,c=us on the consumer with the corresponding ones on supplier:
oidreconcile -h supplier -c consumer -b "o=acme, c=us" -s subtree -W supplier_ password -w consumer_password
If the orclGuid of both parents does not match, then the OID reconciliation tool does not perform the reconciliation. Instead, it tells the user the first ancestor on the consumer in which the orclGuid matches that of the same ancestor on the supplier.
For example, in Figure 10-1, suppose you were to run the following command:
oidreconcile -h supplier -c consumer -b "ou=st, o=acme, c=us" -s subtree
-W supplier_password -w consumer_password
As a result of this command, you would receive a message that the first ancestor of ou=st in which the orclGuids match is o=acme,c=us. This message means that you should use o=acme,c=us as basedn argument to oidreconcile.
|
 Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|