The document I had suggested using ldapsearch and ldapadd to migrate data. If lidf2db commands are faster/better I will use them. >> Try creating all of the required indexes first, then doing the import of >> your original LDIF. I am willing to try this, but It is scary to me. I would have rather you said I must be doing something wrong...because.... Our LDAP database has been in production for 6 years. We add indexes to our i-planet on average twice a year due to new software or new features. Your advice is almost suggesting that adding new indexes can corrupt the database. I will try again from scratch using everyones advice of course. Thank you, Edward On 12/16/06, Noriko Hosoi <nhosoi at redhat.com> wrote: > > Richard Megginson wrote: > > > 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. > > > Are there any reason to use ldapadd instead of ldif2db? ldif2db should > be much faster... > > >> 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 > >> > > > >------------------------------------------------------------------------ > > > >-- > >Fedora-directory-users mailing list > >Fedora-directory-users at redhat.com > >https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20061217/e0d1923d/attachment.html
