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.
