db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Corrupted database
Date Mon, 22 Jun 2009 23:36:40 GMT
Along these lines, if you don't want to hack the code I would try the
following (note I have not ever tried this, so have no idea if it will
work - I thought about this for awhile and looked at the headers and 
could not come up with why it would not work).  For this you will need 
to know the seg0 file associated with
the table you are trying to recover and the seg0 file you will create
for a new dummy table.

o Shutdown the db you are working with cleanly with shutdown=true, make
   an offline copy of it and only work on the copy.
o In another db create a new table that has the same ddl as the original
   table - i will call this dummy table.  The most important part of
   this is that the new table has the
   same page size as the table you are trying to recover.  If you use 
the same ddl and you didn't set any page size properties when you 
created the original table then the page size should match.  The size and
   structure of the allocation part of page 0 is different for each of 
the 4 supported page sizes (2k, 4k, 8k, 32k) - basically there is a 
fixed header and "the rest" is used for the allocation page.  Thus the
bigger the page size the more pages the allocation bit map on page 0
o now insert as many rows as necessary into the dummy table such that it 
is as big as the table you are trying to recover.  The goal here is to
get the allocation map in page 0 to mark all the pages as allocated and
in use.
o now shutdown cleanly (ie. shutdown=true) - if you don't do this then
   the changes may only be in the log and not in the seg0 file.
o now with both db's shutdown cleanly, copy page 0 from the dummy file
over page 0 of the copied database table that you are trying to recover
and try booting, and checking the table.
On a unix system I think this can easily be done with one or two dd 
commands, let me know if you need more info.  Again do this only while
db's are shutdown cleanly otherwise all sorts of recovery problems may
o And of course after you do this you should run the consistency checker 
to see what else may be corrupted, note the consistency checker does not
check everything.  So I usually recommend the only safe thing to do when
using this kind of data corruption mining is to select the recovered 
data out of the bad db and then insert into a newly created good db 
otherwise the corruptions may lurk around and bite you later.  The 
checker is not perfect, it mostly does a good job of checking that the
index tree's are consistent internally and that they are consistent with
the base tables.  For instance I don't think it even reads data in base
that is not needed to check the indexes.


Bryan Pendleton wrote:
>>  Anyone adventurous enough to help me with this problem? Even a yes/no 
>> to the question whether it's possible and maybe some pointers how to 
>> reconstruct page 0 would be a lot of help I think.
> Well, anything's possible, since it's open source software and so you can
> change it and make it do what you need. However, this doesn't sound like
> a very easy thing to do. You've definitely exhausted all possible sources
> of backups?
> Here's some fairly high-level information about page formats:
> http://db.apache.org/derby/papers/pageformats.html
> My first thought would be that if you could make page 0 appear to look
> as though ALL other pages in the conglomerate were "in-use", so that it
> seemed to have no pages marked "available", then you could try opening
> the database and reading all the data out.
> So you'd like the FreePages bitmap to be empty, for this recovery scenario.
> thanks,
> bryan

View raw message