All,

 

I tested this from scratch.

I used the ldif_2db function which did work much faster! 112 seconds...rather then about 20 minutes.

 

However I think the verify_db and db2_index functions are not in agreement.

 

Create indexes.

After my initial import.

[root@ldap3 slapd-ldap3]# more out.after.final.txt
*****************************************************************
verify-db: This tool should only be run if recovery start fails
and the server is down.  If you run this tool while the server is
running, you may get false reports of corrupted files or other
false errors.
*****************************************************************
Verify log files in db ... Good
Verify db/o_idsk_com/id2entry.db4 ... Good
Verify db/userRoot/ancestorid.db4 ... Good
Verify db/userRoot/entrydn.db4 ... Good
Verify db/userRoot/cn.db4 ... Good
Verify db/userRoot/numsubordinates.db4 ... Good
Verify db/userRoot/aci.db4 ... Good
Verify db/userRoot/parentid.db4 ... Good
Verify db/userRoot/objectclass.db4 ... Good
Verify db/userRoot/id2entry.db4 ... Good
Verify db/userRoot/nsUniqueId.db4 ... Good
Verify db/idsk_services/ancestorid.db4 ...
DB ERROR: db_verify: Page 4: out-of-order key at entry 252
DB ERROR: db_verify: Page 7: out-of-order key at entry 194
DB ERROR: db_verify: Page 7: out-of-order key at entry 450
DB ERROR: db_verify: Page 11: out-of-order key at entry 69
DB ERROR: db_verify: Page 11: out-of-order key at entry 325
DB ERROR: db_verify: Page 11: out-of-order key at entry 581
DB ERROR: db_verify: Page 12: out-of-order key at entry 22
DB ERROR: db_verify: Page 16: out-of-order key at entry 249
DB ERROR: db_verify: Page 16: out-of-order key at entry 498
DB ERROR: db_verify: Page 16: out-of-order key at entry 754
DB ERROR: db_verify: Page 17: out-of-order key at entry 195
DB ERROR: db_verify: Page 17: out-of-order key at entry 451
DB ERROR: db_verify: Page 17: out-of-order key at entry 707
DB ERROR: db_verify: Page 18: out-of-order key at entry 148
DB ERROR: db_verify: Page 21: out-of-order key at entry 254
DB ERROR: db_verify: Page 21: out-of-order key at entry 510
DB ERROR: db_verify: Page 21: out-of-order key at entry 766
DB ERROR: db_verify: Page 22: out-of-order key at entry 207
DB ERROR: db_verify: Page 22: out-of-order key at entry 463
DB ERROR: db_verify: Page 22: out-of-order key at entry 719
DB ERROR: db_verify: Page 23: out-of-order key at entry 160
DB ERROR: db_verify: DB->verify: db/idsk_services/ancestorid.db4: DB_VERIFY_BAD: Database verification failed
Secondary index file ancestorid.db4 in db/idsk_services is corrupted.
Please run db2index(.pl) for reindexing.
 

So then i reran db2index....verify_db again...same result.

 

Edward

 

On 12/15/06, Eddie C <edlinuxguru@gmail.com> wrote:

I recently did an ldif backup of our iplanet 52 database. Its about an 88 MB ldif file.

I took this to a new FDS server Dell 850 3 ghz duel core 2 sata hard disks.

I ran an ldapadd  the data imported perfectly.

Then I tried to cutover some systems and give the database some load.

 

System went 200% processor

 

Eventually I realized I was missing indexes so I added them through the graphical tool.

 

The log seemed to do something like this
generating index 1%

generating index 2%

....
generating index 49%
Done

Seemed weird that they would jump from 49% to Done

At this point the new system was running at 100% processor

But the queries are running faster on our old 440 MHZ sparc t1 server52 database

 

I ran
DB ERROR: db_verify: Page 30: out-of-order key at entry 498
DB ERROR: db_verify: DB->verify: db/o_com/channelcontentowner.db4: DB_VERIFY_BAD: Database verification failed
 

then I tried db2_index. The program seemed to be in a tight loop complaining about 1 missing entry.

 

I do not realize how the data can be so corrupted right after an import.

 

These are someone generic symptoms. Any ideas? Thanks