Re: Corrupted database

> 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.