[Fedora-directory-users] Migration from i-planet 52
Richard Megginson
rmeggins at redhat.com
Fri Dec 15 23:52:24 UTC 2006
Eddie C 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
Try creating all of the required indexes first, then doing the import of
your original LDIF. Not only will the import+index creation be much
faster (than doing the import then creating the indexes one at a time),
but I think your database corruption problems will vanish.
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20061215/dd8bdac0/attachment.bin>
More information about the 389-users
mailing list