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
durability)
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
recreate.
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,
--
Kristian
Regards
Ari
