Release 9.0.2
Part Number A95192-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle Internet Directory Administrator's Guide Release 9.0.2 Part Number A95192-01 |
|
Replication is the mechanism that maintains exact duplicates of specified naming contexts on multiple nodes. This chapter tells you how to install, configure, and manage replication in Oracle Internet Directory.
This chapter contains these topics:
"Replication" for a conceptual discussion of replication
See Also:
This section describes how to install and initialize directory replication server software on a node.
Each node in a group of directory servers holds an updatable copy, also called an updatable replica, of the same naming context or 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).
If you are deploying more than one Oracle Internet Directory instance on the same machine, then you cannot uniquely identify each directory server instance by the name of its host. In this case, before installing and configuring replication, follow the instructions in "Identifying a Node as Independent of Its Host".
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 Oracle9i Replication Master Definition Site (MDS)
Task 3: Set Up Oracle9i Replication for a Directory Replication Group
Task 4: Load Data into the Directory
Task 5: Start Oracle Directory Server Instances on All the Nodes
Task 6: Start the Replication Servers on All Nodes in the DRG
Task 7: Test Directory Replication
|
Note:
|
Note that the typical installation of the Oracle9i Enterprise Edition, which is required for the Oracle Internet Directory, includes Oracle9i Replication. By contrast, a typical installation of Oracle9i Standard Edition does not include Oracle9i Replication.
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 (RMS) is any site other than the MDS that participates in Oracle9i Replication.
You must be able to use Oracle Net Services to connect to the MDS database and all other nodes that constitute the DRG.
The following sections lead you through installing and configuring Oracle9i Replication through Oracle Internet Directory installation scripts. More advanced Oracle9i Replication users may prefer to configure Oracle9i Replication through the Oracle9i Replication Manager Tool.
To configure the Oracle9i Replication environment to establish a directory replication group (DRG), perform the tasks discussed in these topics:
Follow these steps, described more fully below, on all nodes in the directory replication group to prepare the Oracle Net Services environment:
To prepare the Oracle Net Services 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.
Define all Oracle Internet Directory database instances in the DRG on all nodes in the DRG. 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.
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;
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.
Modify the parameters 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 ...) SHARED_POOL_SIZE = 20000000
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]
Stop and restart the Oracle Internet Directory database.
To stop and restart the Oracle Internet Directory database, you can use SQL*Plus.
Use SQL*Plus. Test both internal@net_service_name and internal@net_service_name.domain. If this does not work, then replication will not work.
To configure Oracle9i Replication for the replication group, complete the following steps from the MDS:
$ORACLE_HOME/ldap/bin
\ldap\bin
ldaprepl.sh -asrsetup
The ldaprepl.sh script executes a number of operations.
As the script runs, it asks for the information in the following table, first for the MDS.
| Requested Information | Definition |
|---|---|
|
MDS Global Name |
Net service name of the MDS database, as listed in the file |
|
System password for MDS |
System password for the Master Definition Site |
After you have provided this information for the MDS, the script asks you for the global names and system passwords of any other master sites.
After you have provided the necessary information for the other master sites, the script asks you for the replication administration password. This enables it to create the database account for the replication administrator on all the nodes. The replication administrator needs this password later when adding or deleting nodes.
Once you have identified all sites, the script shows a table of the information you have provided, and asks for confirmation. If it is not correct, then press N. The script then starts again at the beginning, asking about the MDS again.
After you have provided all the information, the script asks you to verify 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.
|
Note: If you interrupt the process before it is complete, then you must start at the beginning. Interrupting the process does not negatively affect your re-installation. If errors arise, see Troubleshooting Replication Setup. |
If you have a small number of entries to add to the DRG, you can wait until you have completely configured the DRG, then use ldapadd to load the data to one of the nodes. The entries will then be replicated to the other nodes at the specified time.
If you have a large amount of data to load into the DRG, then use the bulkload utility. To do this:
bulkload.sh -connect net_service_name -check -generate file_with_absolute_ path_name
bulkload.sh -connect net_service_name_1 -load
bulkload.sh -connect net_service_name_2 -load
then enter:
bulkload.sh -connect net_service_name_3 -load
and so on, until you have bulkloaded the data onto each node in the DRG.
|
Note: To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:
|
|
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
Be sure that the change logging option for the directory server is set to the default, namely, TRUE.
|
See Also:
Chapter 3, "Preliminary Tasks and Information" for more information on starting an Oracle directory server instance. |
To start replication servers on all nodes, type the following command:
oidctl connect=net_service_name server=oidrepld instance=1
flags='-h host_name_of_this_computer -p port' start
Note that the instance number does not need to be unique across the entire DRG.
|
See Also:
Chapter 5, "Oracle Directory Server Administration" for information on starting the replication servers |
You can turn off the multimaster flag, which occurs in the directory replication server, by changing the value of the -m flag in the OID Control Utility command for Oracle directory server from the default, namely, 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.
|
Note: As part of Task 3, the ldaprepl script set normal defaults enabling you to simply start the replication servers. If you wish to alter these defaults, see Managing Replication . |
Use Oracle Directory Manager to verify that the directory replication servers are running, then test directory replication by doing the following:
The identical entry appears in approximately 1 to 10 minutes on the RMS. You can adjust the timing in the replication server configuration set entry. If entries are modified on any nodes in the DRG, then the changes will be replicated.
Once you have installed and configured replication, you have the option of modifying the default parameters for server configuration and replication agreements. Replication agreements are entries that list the member nodes (in a replication group) that share their changes. Replication agreements are referenced by replication server configuration parameters that load when the directory replication server runs.
Directory replication server configuration parameters are stored as special attributes in directory entries. You can configure replication parameters and replication agreements the same way you configure the Oracle Internet Directory. You can do either of the following:
or
This section explains both approaches and contains the following topics:
The 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.
Table 23-1 lists and describes the 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 moved to the human intervention queue. 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 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. 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 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 my_host -p 389 -f mod.ldif
This example uses an input file named mod.ldif to change the change log life parameter to 10 hours:
mod.ldif as follows:
dn: cn=configset0,cn=oidrepld,cn=subconfigsubentry changetype: modify replace: orclChangeLogLife orclChangeLogLife: 10
configset0 parameter value as follows:
ldapmodify -h my_host -p 389 -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 my_host -p 389 -f mod.ldif
This example uses an input file named mod.ldif to change the number of worker threads used in change log processing to 7:
mod.ldif as follows:
dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry changetype: modify replace: orclthreadspersupplier orclthreadspersupplier: 7
configset0 parameter value as follows:
ldapmodify -h my_host -p 389 -f mod.ldif
"Restarting Directory Server Instances" for instructions on restarting the directory replication server
See Also:
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 9.0.2, only one replication agreement can be used.
In the parameter DirectoryReplicationGroupDSAs, type the host names for all of the nodes in the DRG. This list must be identical on all the nodes (see Identifying a Node as Independent of Its Host.
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, "Adding a Replication Node" explains the process of adding a new node to a replication environment. |
Because Oracle Internet Directory Release 9.0.2 supports only one configuration set for directory replication server, you do not need to specify a configuration set.
The Oracle9i Replication administrator can change the password for administering Oracle9i Replication on all nodes by using the -chgpaswd utility. To launch this utility, enter:
ldaprepl.sh -chgpswd
The -chgpswd utility 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 the -chgpswd utility asks you to enter it again, up to three times.
There are two ways to add a new node to a live replication group.
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 Chapter 24, "Addition of a Node by 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. For example, if your directory has more than a million entries, then use this method.
Before you add a replication node:
To add a replication node to a functioning DRG of any significant size, follow these general steps, each of which is more fully described later in this chapter.
Task 1: Stop the Directory Replication Server on All Nodes
Task 2: Identify a Sponsor Node and Switch the Sponsor Node to Read-Only Mode
Task 3: Backup the Sponsor Node by Using ldifwrite
Task 4: Perform Oracle9i Replication Add Node Setup
Task 5: Switch the Sponsor Node to Updatable Mode
Task 6: Start the Directory Replication Server on All Nodes Except the New Node
Task 7: Load Data into the New Node by Using bulkload
Task 8: Start LDAP Server on the New Node
Task 9: Start the Directory Replication Server on the New Node
|
Note: Commands shown in the following tasks require the following types of items to be stored as follows: Before beginning "Task 1: Install Oracle Internet Directory on All Nodes in the DRG", be sure that all three of these types of items are in the path. |
To stop the 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
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 4: Perform Oracle9i Replication 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 3: 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 23-2, first for the sponsor node then for the existing master sites.
| Requested Information | Definition |
|---|---|
|
MDS Global Name |
Net service name of the MDS database, as listed in the file |
|
System password for MDS |
System password for the Master Definition Site |
When you have identified all the existing master sites, enter N. The script then asks for the global name of the node you want to add, the system password for that node, and the replication administrator's database account password. 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.
|
Note: If for any reason you must interrupt the process before it is complete, then you must start from the beginning. If errors arise, see Troubleshooting Replication Setup |
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 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
|
Note: To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:
|
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
|
Note: If you need to change configuration or agreement parameters, see Managing Replication. |
To start the 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
At times, you may want to delete a node from a DRG. For example, if the addition of a new node did not fully succeed as a result of system errors, then you need to delete that node.
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 in this section.
Task 1: Stop the 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 Directory Replication Server on All Nodes
To stop the 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
|
Note: To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:
|
This script executes these operations:
Directory Replication Group.
As the script runs, it asks for the global name of the MDS, the global name of the node you want to delete, and the replication administrator's password. 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.
To start the directory replication server, type the following command:
oidctl connect=net_service_name server=oidrepld instance=1
flags='-h host -p port' start
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:
When the 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:
"OID Reconciliation Tool Syntax" for syntax and an explanation of how OID reconciliation tool works.
See Also:
In most deployments, a node in a DRG is uniquely identified by the name of the host where Oracle Internet Directory is installed. However, when there are multiple installations of Oracle Internet Directory on the same host, the host name cannot be a unique node identifier. In this case, you should use the orclReplicaId attribute of the Root DSE.
When you identify a node in a DRG by using orclReplicaId instead of the host name, follow the steps in this section.
orclReplicaId a unique value. For example, if there are three nodes on the same computer, and the corresponding directory servers are running on port1, port2 and port3, then you would perform following modifications:
ldapmodify -v -h host -p port1 << EOF dn: changetype: modify replace: orclreplicaid orclreplicaid : replica001 ldapmodify -v -h host -p port2 << EOF dn: changetype: modify replace: orclreplicaid orclreplicaid : replica002 ldapmodify -v -h host -p port3 << EOF dn: changetype: modify replace: orclreplicaid orclreplicaid : replica003
orclreplicaid on all the nodes, perform replication setup as described in "Installing and Configuring Replication".
orcldirreplgroupdsas attribute the same value you assigned to orclreplicaid. To use the previous example, you would give the orcldirreplgroupdsas attribute the values replica001, replica002, replica003.
If the replication setup fails, then do the following:
$ORACLE_HOME/ldap/admin/logs/ldaprepl.log file to see the status.
$ORACLE_HOME/ldap/admin and check the status of replication jobs by running the following command:
sqlplus system/password@net_service_name @ldaplogq.sql
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 Oracle9i Replication set up failed. In this case, you may:
|
 Copyright © 1999, 2002 Oracle Corporation. All Rights Reserved. |
|