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
controls.
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
happen.
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.
/mikem
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
