Eddie C wrote: > 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 at 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. > Is this after you imported your ldif file to the backend 'idsk_services'? When you imported the ldif file, did you get any errors from ldif2db? This is an sample output when we import Example.ldif. Did you see any messages other than these? [18/Dec/2006:04:00:48 -0800] - dblayer_instance_start: pagesize: 4096, pages: 1009265, procpages: 23476 [18/Dec/2006:04:00:48 -0800] - cache autosizing: import cache: 204800k [18/Dec/2006:04:00:48 -0800] - li_import_cache_autosize: 50, import_pages: 51200, pagesize: 4096 [18/Dec/2006:04:00:48 -0800] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [18/Dec/2006:04:00:48 -0800] - dblayer_instance_start: pagesize: 4096, pages: 1009265, procpages: 23476 [18/Dec/2006:04:00:48 -0800] - cache autosizing: import cache: 204800k [18/Dec/2006:04:00:48 -0800] - li_import_cache_autosize: 50, import_pages: 51200, pagesize: 4096 [18/Dec/2006:04:00:49 -0800] - import example: Beginning import job... [18/Dec/2006:04:00:49 -0800] - import example: Index buffering enabled with bucket size 100 [18/Dec/2006:04:00:49 -0800] - import example: Processing file "/export/DS7.2-24471/server/usr/share/fedora-ds/data/Example.ldif" [18/Dec/2006:04:00:49 -0800] - import example: Finished scanning file "/export/DS7.2-24471/server/usr/share/fedora-ds/data/Example.ldif" (160 entries) [18/Dec/2006:04:00:50 -0800] - import example: Workers finished; cleaning up... [18/Dec/2006:04:00:50 -0800] - import example: Workers cleaned up. [18/Dec/2006:04:00:50 -0800] - import example: Cleaning up producer thread... [18/Dec/2006:04:00:50 -0800] - import example: Indexing complete. Post-processing... [18/Dec/2006:04:00:50 -0800] - import example: Flushing caches... [18/Dec/2006:04:00:50 -0800] - import example: Closing files... [18/Dec/2006:04:00:51 -0800] - All database threads now stopped [18/Dec/2006:04:00:51 -0800] - import example: Import complete. Processed 160 entries in 2 seconds. (80.00 entries/sec) Thanks, --noriko > So then i reran db2index....verify_db again...same result. > > Edward > > > On 12/15/06, *Eddie C* <edlinuxguru at gmail.com > <mailto:edlinuxguru at 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 > > > ------------------------------------------------------------------------ > > -- > 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: 3237 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20061218/22a5c08d/attachment.bin
