db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabor 'Morc' KORMOS <m...@baxter-it.com>
Subject Re: Corrupted database
Date Wed, 17 Jun 2009 15:00:19 GMT
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.

Mime
View raw message