db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <kristian.waa...@oracle.com>
Subject Re: Derby database
Date Mon, 07 May 2012 10:41:50 GMT
On 05.05.12 12:13, Aristedes Maniatis wrote:
> Running Derby 10.8, a customer has managed to corrupt their database
> somehow (possibly by forcing the database to quit when it did not shut
> down fast enough to their liking). I see that when I connect to it with
> ij in embedded mode, I get the following:
> ERROR 40XD2: Container Container(0, 36049) cannot be opened; it either
> has been dropped or does not exist.

Hi Ari,

Do you have the stack trace for this exception?
The exception can be thrown from a few places, although the one in 
BaseDataFileFactory seems the most likely one.
Do you know when this exception was first seen?
Any other interesting errors in derby.log?
Are you aware of any power outages during this period, and if so, do you 
know if the write cache on the disk has been disabled? (it should be for 

> My reading so far suggests that page 0 of some data with id 36049 is
> corrupt. Is there further diagnostics I can do to determine whether this
> data is just an index which could be rebuilt or something else? Are
> there further tools I can use to progress? Can I excise the bad data and
> manually replace it later?

The 0 refers to segment zero. Derby currently only supports one segment, 
so it is always zero.
The container 36049 would live in the file seg0/c8cd1.dat - do you have 
that file?

Your options for recovery depends on the data and the schema in the 
database, and would require full understanding of the relationships 
between the different tables etc:
   o if you have the file and it is corrupt, you, or the Derby 
developers, may be able to extract something useful out of it. Before 
share anything you have to determine if distributing the data is 
acceptable to your customer.
   o if the file is gone, you may be able to boot the database and 
investigate further, but the data would likely be inconsistent. The best 
thing that could happen here is that it is an index you can drop and 

> I can restore from backup, however the loss of a day's work since that
> backup would be unfortunate. It does not appear that rollforward logs
> were enabled.
> mysql has a startup mode which allows it to start up in the face of data
> corruption and then attempt recovery. Does Derby have a similar concept?

No, not in terms of missing and/or destroyed conglomerates.
Recovery in terms of redo/undo, for instance if the VM crashes, is 
performed automatically when the database is booted.


> Regards
> Ari

View raw message