DB_RUNRECOVERY: Fatal error, run database recovery problems

DB_RUNRECOVERY: Fatal error, run database recovery problems 01:33 Monday the 8th of October 2007 8 Comments

My blog seemed to stop accepting comments at some point tonight. The error message returned was:

DBRunRecoveryError: (-30978, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Invalid argument')

This first thing I managed to figure out by googling was that there is a db_recover tool to recover the bdb database I use for comments, however I didn't seem to have the tool on my system and couldn't find a Debian package that contained it. It turned out that the correct name on Debian is db4.2_recover. Sadly even after running it the database wasn't working.

Eventually I figured out how to dump and reload the database. I first dumped the database using

db4.2_dump dbfile > dbfile.dump

The backed up the database file (dbfile) and deleted it. Then ran

db4.2_load dbfile < dbfile.dump

And that sorted it. I'm still not clear on what caused the corruption, as there where no crashes or any other noticeable problems today. I thought I would make a note of this here, both to help me if I ever hit the problem again and to hopefully help others avoid the endless googling I had to go through to figure it all out. Thanks to Tim Kerstin for reporting the problem.

Add Comment

Comments

So?

lapa 17:23 Wednesday the 10th of October 2007

The so is pretty simple. It was a terrible pain to figure this out. So I put it up for two reasons. First so I could refer to it myself if I needed to fix the same problem. And secondly for those googling for the same problem to find an actual solution. Looking at my logs it would appear several people have already arrived here from google looking for exactly that.

Sean O'Donnell 17:24 Wednesday the 10th of October 2007

I just got a similar error from SVN: DB_RUNRECOVERY: Fatal error, run database recovery This site: http://subversion.tigris.org/faq.html#stuck-bdb-repos recommends to just run the following command: svnadmin recover /path/to/repos

Markus 17:25 Wednesday the 10th of October 2007

Thanks Markus, unfortunately in my case it wasnt a subversion repository that was giving the error, but thanks for the tip (part of the problem I had was googling for the error only gave instructions on recovering a subversion repository).

Sean O'Donnell 17:26 Wednesday the 10th of October 2007

Thanks Sean for your pratical approach. I met the same problem recently. But I don't know the reason. The first time I met this problem, I thought it's because I wrote and read the DB without accurate access control / lock. So I re-created a DB, and maintain two copies, one for writing, another for reading. However, the fact is that I get the same problem again.

I use "m_db.open(NULL,fname,NULL,DB_HASH, DB_CREATE | DB_THREAD, 0644);" to open DB. But I don't do any db environment configuration. To simpify the issue, I use single process and single thread to write DB. Now this problem really upsets me. Do you know the reason of this problem and the solution?

Regards, Gerry

Gerry 16:26 Monday the 9th of March 2009

Sorry Gerry, I have no idea what the root cause is, it happened to me every 2 months or so and eventually I moved off bdb completely rather than put up with it.

Sean O'Donnell 18:09 Monday the 9th of March 2009

Sean, when I use db_dump to dump the db file, I got error: "db_dump: DB->stat: DB_PAGE_NOTFOUND: Requested page not found". Seem databases have seriously corrupted. There is no chance to restore them.

gerry 13:28 Friday the 13th of March 2009

I had similar problems with the .db files of nicotine (a python soulseek client), and the dump/load method fixed it. Here the command in case anybody needs it (on a Debian, with db4.8-utils installed): for i in ~/.nicotine/*db; do db4.8_dump $i>$i.dump; mv $i $i.bk; db4.8_load $i <$i.dump; done

torino 18:54 Friday the 2nd of April 2010