Skip Navigation Links | |
Exit Print View | |
Oracle Directory Server Enterprise Edition Troubleshooting Guide 11g Release 1 (11.1.1.5.0) |
1. Overview of Troubleshooting Directory Server Enterprise Edition
2. Troubleshooting Installation and Migration Problems
3. Troubleshooting Replication
Analyzing Replication Problems
Overview of Replication Data Collection
Setting the Replication Logging Level
Example: Troubleshooting a Replication Problem Using RUVs and CSNs
Possible Symptoms of a Replication Problem and How to Proceed
Troubleshooting a Replication Halt or Replication Divergence
Possible Causes of a Replication Halt
Possible Causes of a Replication Divergence
Collecting Data About a Replication Halt or Replication Divergence
Collecting Error and Change Logs
Collecting Data Using the insync and repldisc Commands
Collecting Information About the Network and Disk Usage
Analyzing Replication Halt Data
Resolving a Problem With the Schema
Analyzing Replication Divergence Data
Advanced Topic: Using the replcheck Tool to Diagnose and Repair Replication Halts
Diagnosing Problems with replcheck
Repairing Replication Failures With replcheck
Troubleshooting Replication Problems
Using the nsds50ruv Attribute to Troubleshoot 5.2 Replication Problems
Using the nsds50ruv and ds6ruv Attributes to Troubleshoot Replication Problems
Determining What to Reinitialize
Doing a Clean Reinitialization
4. Troubleshooting Directory Proxy Server
5. Troubleshooting Directory Server Problems
6. Troubleshooting Data Management Problems
7. Troubleshooting Identity Synchronization for Windows
8. Troubleshooting DSCC Problems
9. Directory Server Error Log Message Reference
This section describes how to analyze your topology to determine which systems need to be reinitialized. It also describes the methods you can use to reinitialize your replication topology.
Note - When a replica has been reinitialized, all of its consumer replicas must also be reinitialized.
When you reinitialize your topology, you take a good copy of the data from a supplier and overwrite the bad data on the consumers in the topology. Before you reinitialize your topology, determine which systems are unsynchronized and need to reinitialized. This critical step can prevent your from wasting time by overwriting data that is already synchronized.
For example, the following figure illustrates a topology where replication is broken on hub 1.
Because hub 1 provided data to consumers A and B, you need to reinitialize hub 1, consumer A, and consumer B.
In the following example, consumers A and B also receive updates from hub 2.
Consumers A and B may be synchronized with the supplier of the reinitialized replica because they receive updates from both hubs. Their status depends on which replica you select to reinitialize your topology. If you use RUVs to ensure that you have the latest changes, then these replicas may be up-to-date and you may not need to reinitialize consumers A and B.
All of the reinitialization methods copy unnecessary data, for example data that contains values that were deleted or that maintain state information or other historical data. This unnecessary data makes the entry larger in disk. Also, the entry state information may need to be purged. If the root cause of the replication problem is related to this state information, the data is still present in the database and can cause another replication error. To avoid importing this unnecessary and potentially problematic data, you can do a clean reinitialization of your topology.
When you do a clean reinitialization, you create a clean master copy of the data that contains smaller databases, indexes, and empty change logs. A clean reinitialization uses less disk space and takes less time because it does not make backup copies of the database files. It also reduces index fragmentation, which can reduce performance. However, it requires you to stop the server that is being cloned to ensure that the database files are in a coherent state.
Specify the -Q option so that replication information is not included in the export.
# dsadm export -Q instance-path suffix-DN /tmp/clean-export.ldif
# dsadm import instance-path /tmp/clean-export.ldif suffix-DN
The master server now contains clean data, meaning it contains smaller databases, indexes, and empty change logs.
This method requires a replication agreement between the supplier and the consumers suffixes. Use this method to reinitialize a single suffix or to reinitialize many small suffixes.
Note - If you are using an earlier version of the Directory Server console, go to the Configuration panel and select the Replication node. Select the suffix you want to initialize in the consumer. Select the replication agreement to the consumer. Right click the agreements and select Initialize consumer now.
Select Initialize Suffix from Data from the drop-down menu.