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 18:27:27 GMT
   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.


Mime
View raw message