db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Corrupted database
Date Wed, 17 Jun 2009 18:20:10 GMT
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