Re: Corrupted database

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