Migrating User Data Manually

If your topology does not support automatic data migration, you must migrate the data manually. This involves exporting the data from the existing instance and re-importing it to the new instance.

To migrate data manually, perform the following steps:

If you already have data in the new instance, back up any conflicting suffixes in the new instance.
If you are migrating a master server instance in a replicated topology, make sure that the master is synchronized with all servers that are direct consumers of that master.

It is not possible to migrate the change log manually. A new change log is created in the 11g Release 1 (11.1.1.5.0) instance.
Export the required suffixes to LDIF by using the db2ldif command. This command exports all the suffix contents to an LDIF file, when the server is either running or stopped.

The following example exports two suffixes to a single LDIF file.
```
$ serverRoot/slapd-serverID/db2ldif -a example.ldif \
 -r -s "ou=people,dc=example,dc=com" -s "ou=departments,dc=example,dc=com"
```
In this example, -a specifies the resulting LDIF file, -r indicates that replication information should be exported, and -s specifies the suffixes to be included in the export.
On the new instance, import the LDIF files by using the dsadm import command. For example, the following commands import the LDIF file created previously into the two suffixes that were exported.
```
$ dsadm import instance-path example.ldif ou=people,dc=example,dc=com
$ dsadm import instance-path example.ldif ou=departments,dc=example,dc=com
```
If the retro change log was configured on the old instance, export the retro change log to LDIF by using the db2ldif command.
```
$ serverRoot/slapd-serverID/db2ldif -a changelog.ldif \
 -s "cn=changelog"
```
In this example, -a specifies the resulting LDIF file, and -s specifies the changelog suffix.
On the new instance, import the retro change log using the dsadm import command. For example, the following command imports the change log LDIF file created previously.
```
$ dsadm import instance-path changelog.ldif cn=changelog
```
Start the new instance.

Note - During data migration, Directory Server checks whether nested group definitions exceed 30 levels. Deep nesting can signify a circular group definition, where a nested group contains a group that is also its parent. When a group with more than 30 nesting levels is encountered, Directory Server stops calculating the isMemberOf attributes for additional levels.

Each time this happens, Directory Server logs an error. You safely ignore these errors, although you should examine the definition of the group mentioned in the error message for potential circular definitions.

Skip Navigation Links
Exit Print View
	Oracle Directory Server Enterprise Edition Upgrade and Migration Guide 11 g Release 1 (11.1.1.5.0)