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.
