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 Mon, 22 Jun 2009 12:48:24 GMT
  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.
>
>

Mime
View raw message