Hi,

After a program crash, I realized the DB was corrupted and tried to
recover it. But I get some fatal error regarding wrong LSN on forward
pass. I tried both normal and catastrophic recovery, and they fail.
Then I found on some forum that this could possibly happen if one
tries to open it normally before realizing that it needs recovery. It
seems that it's impossible to recover a corrupted database if recovery
is not first thing you do it after it got corrupted. I'm embedding DB
in my application I'd like my users not to have to worry about
recoveries, and in general not to be concerned at all about the fact
that BDB is managing storage under the hood.

So, is there a safe API that I could call preventatively on startup to
check for an environment integrity and possibly run recovery if need
be? Simply running a fatal recovery (no matter what) takes too much
time and slows down the appearance of the first application screen by
40sec.

Thanks,
Boris

Passing DB_REGISTER and DB_RECOVER flags to DB_ENV->open should do
what you want. That is, they will run recovery if some other process
has exited with the envionment open:

http://www.oracle.com/technology/doc...y-db/db/api_c/
env_open.html#DB_REGISTER

Regards,
Michael Cahill, Oracle.

Thanks Michael! I'll that a try...

Regards,
Boris

On Feb 9, 12:13 am, michael.cah... (AT) gmail (DOT) com wrote:

Hi,

It looks like this doesn't help . I'm using Berkeley DB 4.4 from
Java (not the Java edition per se, though). The application hangs
because of an unreleased lock held by a cursor. It is killed with Ctrl-
C. Then I'm unable to recover. Here's how the environment is
configured:

EnvironmentConfig envConfig = new EnvironmentConfig();
envConfig.setAllowCreate(true);
envConfig.setInitializeCache(true);
envConfig.setInitializeLocking(true);
envConfig.setInitializeLogging(true);
envConfig.setTransactional(true);
envConfig.setTxnWriteNoSync(true);
envConfig.setRunRecovery(true);
envConfig.setRegister(true);

After the improper exit, I get this error:

Log sequence error: page LSN 1 743903; previous LSN 1 745019
Recovery function for LSN 1 745099 failed on forward pass
PANIC: Invalid argument
PANIC: fatal region error detected; run recovery

Or perhaps, there are simply cases where recovery is impossible?

Thanks,
Boris


On Feb 9, 12:13 am, michael.cah... (AT) gmail (DOT) com wrote: