DB_RUNRECOVERY: Fatal error, run database recovery

Question

I am getting this error when trying to add data to QUEUE. But after I restart my app, this error does not happen anymore.
2009-08-16 10:27:12.558990 [ERR] mod_cdr_bdb.c:370 Unable to add cdr to Queue. Error=DB_RUNRECOVERY: Fatal error, run database recovery
Does anyone know what could be the cause of the error?

Answer 1

Hi,
Do you know the steps that lead up to this error? Can you reproduce it?
Were there any error messages sent to the error log file? Can you confirm that you have verbose error messages turned on by always initializing one of the error callback interfaces in your environment. This will provide verbose error messages:
DB_ENV->set_errcall, DB_ENV->set_errfile, DB_ENV->set_errpfx, and DB_ENV->set_verbose.
What flags are you using when opening the environment and the database?
The procedure you have to follow when you receive this error is described here: [DB_RUNRECOVERY|http://www.oracle.com/technology/documentation/berkeley-db/db/ref/program/errorret.html#DB_RUNRECOVERY]
DB_RUNRECOVERY:
There exists a class of errors that Berkeley DB considers fatal to an entire Berkeley DB environment. An example of this type of error is a corrupted database page. The only way to recover from these failures is to have all threads of control exit the Berkeley DB environment, run recovery of the environment, and re-enter Berkeley DB. (It is not strictly necessary that the processes exit, although that is the only way to recover system resources, such as file descriptors and memory, allocated by Berkeley DB.)
When this type of error is encountered, the error value DB_RUNRECOVERY is returned. This error can be returned by any Berkeley DB interface. Once DB_RUNRECOVERY is returned by any interface, it will be returned from all subsequent Berkeley DB calls made by any threads of control participating in the environment.
Applications can handle such fatal errors in one of two ways: first, by checking for DB_RUNRECOVERY as part of their normal Berkeley DB error return checking, similarly to DB_LOCK_DEADLOCK or any other error. Alternatively, applications can specify a fatal-error callback function using the DB_ENV->set_event_notify method. Applications with no cleanup processing of their own should simply exit from the callback function.Thanks,
Bogdan Coman