Hello, Ville; Ville Silventoinen wrote: > After I import about 1400 accounts to a new database (ebiRoot, People > subtree), I get lot of errors when I run verify-db.pl (slapd has been > stopped): > > Verify log files in db ... Good > Verify db/ebiRoot/uid.db4 ... Good > Verify db/ebiRoot/mail.db4 ... > DB ERROR: db_verify: Page 37: out-of-order key at entry 247 > DB ERROR: db_verify: Page 37: out-of-order key at entry 503 > ... > > Same error for ancestorid.db4, objectclass.db4, parentid.db4, cn.db4, > givenName.db4 and sn.db4. How about id2entry.db4? Is it broken? (It's a primary db file.) > > I have run db2index and re-run verify-db.pl but I don't see any > difference. Here is what db2index says about ebiRoot: > > [29/Mar/2007:12:04:26 +0100] upgrade DB - ebiRoot: Start upgradedb. > [29/Mar/2007:12:04:26 +0100] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to > access the database > [29/Mar/2007:12:04:26 +0100] - import ebiRoot: Index buffering enabled > with bucket size 100 > [29/Mar/2007:12:04:27 +0100] - import ebiRoot: Workers finished; > cleaning up... > [29/Mar/2007:12:04:28 +0100] - import ebiRoot: Workers cleaned up. > [29/Mar/2007:12:04:28 +0100] - import ebiRoot: Cleaning up producer > thread... > [29/Mar/2007:12:04:28 +0100] - import ebiRoot: Indexing complete. > Post-processing... > [29/Mar/2007:12:04:28 +0100] - import ebiRoot: Flushing caches... > [29/Mar/2007:12:04:28 +0100] - import ebiRoot: Closing files... > [29/Mar/2007:12:04:29 +0100] - import ebiRoot: Import complete. > Processed 1424 entries in 3 seconds. (474.67 entries/sec) > > > Does that WARNING "No other process is alloed to access the database" > mean something is wrong? No, that's just a warning not to access the backend ebiRoot. > > How can I locate those "out-of order keys" the db_verify lists? I > tried with dbscan but I don't think I'm giving the right entry id: Right. 247 is the Berkeley DB's internal id. > > $ ./dbscan -K 247 -f db/ebiRoot/mail.db4 > Can't set cursor to returned item: DB_NOTFOUND: No matching key/data > pair found What happens if you just run dbscan for all the keys in mail.db4 (without the -K option)? E.g., ./dbscan -n -r db/ebiRoot/mail.db4 Do you get any errors? > Is there a way to find out which entries are causing the problem? Can > there be illegal characters in the entries? Could it be possible to share your data with us? (sample data would be good.) Thanks, --noriko > > If I import a considerably smaller set of entries (120), I get no > errors. I noticed there was a similar thread here but no conclusion: > > http://www.mail-archive.com/fedora-directory-users at redhat.com/msg04461.html > > > Sorry for so many questions, I've spent couple of days trying to solve > the problem. > > If I delete a database with the Console, it leaves behind couple of > index files: > > -rw------- 1 w3secure systems 16384 Mar 28 17:05 ancestorid.db4 > -rw------- 1 w3secure systems 18 Mar 28 17:03 DBVERSION > -rw------- 1 w3secure systems 32768 Mar 28 17:05 id2entry.db4 > > These index files don't seem to shrink when new entries are imported. > dbscan still shows the deleted entries in id2entry. > > I noticed a problem when I import a small set of entries, delete the > database, import large set of entries and if I query the entries, I > get the entries from the first set (they don't exist in the second > set). I can reproduce the problem. If I delete ancestorid.db4 and > id2entry.db4 manually when I delete the database, I don't have this > problem. Is there a reason why those two files are not deleted? Or can > this whole thing be caused by corrupted data? > > > Ville > > -- > 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/20070329/fa711062/attachment.bin
