[Fedora-directory-users] db_verify

Noriko Hosoi nhosoi at redhat.com
Thu Mar 29 17:51:24 UTC 2007


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@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://listman.redhat.com/archives/fedora-directory-users/attachments/20070329/fa711062/attachment.bin>


More information about the Fedora-directory-users mailing list