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
