Eddie C wrote:
The document I had suggested using ldapsearch and ldapadd to migrate data. If lidf2db commands are faster/better I will use them.No, not exactly. I'm not really sure what went wrong. Feel free to try it again. It's just that for the initial data import, it's much faster to configure the indexes first, then use ldif2db to import the data and create the indexes at the same time.>> 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, EdwardOn 12/16/06, *Noriko Hosoi* < nhosoi@xxxxxxxxxx <mailto:nhosoi@xxxxxxxxxx>> 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@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx> >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > >------------------------------------------------------------------------ > >-- >Fedora-directory-users mailing list >Fedora-directory-users@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx> >https://www.redhat.com/mailman/listinfo/fedora-directory-users <https://www.redhat.com/mailman/listinfo/fedora-directory-users> > > -- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx <mailto:Fedora-directory-users@xxxxxxxxxx> https://www.redhat.com/mailman/listinfo/fedora-directory-users ------------------------------------------------------------------------ -- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
