Gals and guys.
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.
Thanks,
Morc.
On 17/06/2009 20:27, Gabor 'Morc' Kormos wrote:
Mike,
You seem to know more than me about the structure. Is there a way
you think to reconstructs page 0 given the rest of the file is intact?
Thanks,
Morc.
On 6/17/2009 20:20, Mike Matrigali wrote:
Unfortunately it looks like your corruption is in page 0 of a regular
table (not the index). This is the worst case, as page 0 contains a
bunch of information necessary to access the rest of the table. From
the
subsequent errors you got after patching the code to ignore the
catch of the page being corrupted, it looks like the bit map on
the page is bad.
In addition to normal metadata about the table, page 0 also includes
the first part of the bit map for the table which tells the table
which pages are allocated or not.
Gabor 'Morc' KORMOS wrote:
On 17/06/2009 16:36, Kathey Marsden wrote:
Gabor 'Morc' KORMOS wrote:
Hi,
I saw a post just the other day detailing how to fix a CRC error
although this does not cover my problem because the corruption
does not surface during boot rather on query. I use Sonar which
uses Derby embedded, but unfortunately one of the versions which
is known to corrupt data, 10.3.1.4.
OK, so the problem is that on query the Debry instance just shuts
down detecting the CRC error. I used a hex editor to fix the CRC
(it's in the first page of the file) but then I get another error
(see below). Could someone help me fix this even by sending
her/him the whole database (not huge, 240MB uncompressed)?
You might start with a consistency check to determine what
table/index is corrupt:
http://wiki.apache.org/db-derby/DatabaseConsistencyCheck
Do this on your original corrupted database, not the one that you
changed with the hex editor.
Hopefully it is an index that you can drop and recreate.
Thanks
Kathey
Hi Kathey,
I'm passed this, I just forgot to include this info. Anyhow I ran
the two queries on that page although the first does not produce any
output except this:
ERROR XSDG2: DERBY SQL error: SQLCODE: -1, SQLSTATE: XSDG2,
SQLERRMC: Invalid checksum on Page Page(0,Container(0, 2384)),
expected=3,281,399,563, on-disk version=3,090,892,683, page dump
follows: Hex dump:
I found a mailing list thread that detailed how to find out
whether it's an index or table, but based on that I could not
determine if it's an index or table. The two queries suggested were
these (updated with the number from the error message):
SELECT C.CONGLOMERATENUMBER, C.CONGLOMERATENAME FROM
SYS.SYSCONGLOMERATES C WHERE CONGLOMERATENUMBER=2384;
SELECT C.CONGLOMERATENUMBER, T.TABLENAME FROM SYS.SYSCONGLOMERATES
C, SYS.SYSTABLES T WHERE C.CONGLOMERATENAME=T.TABLEID AND
C.CONGLOMERATENUMBER=2384;
These produce these outputs respectively:
CONGLOMERATENUMBER |CONGLOMERATENAME
-----------------------------------------------------------------------------------------------------------------------------------------------------
2384 |83ba410f-011d-aeeb-11a5-ffffd602c73a
CONGLOMERATENUMBER |TABLENAME
-----------------------------------------------------------------------------------------------------------------------------------------------------
2384 |PROJECT_MEASURES
This table does have an index, but even trying to drop it results
in the same error as above. I tried to figure out the file structure
from the source code and fix it with little luck, but I'm clear that
this page is the file header containing some vital info. Anyhow
dropping the table is not an option, we'd like to preserve as much
data as possible and only this table/file is corrupted. An important
question though: since this Sonar version uses a known data
corrupting Derby version does that help at all or this corruption is
not the one that was caused by the bug?
Thanks,
Morc.
