db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sitsky <s...@nuix.com>
Subject Re: ERROR XSDG2: Invalid checksum on Page Page(0,Container(0, 1313))
Date Tue, 01 Apr 2008 01:35:12 GMT
Hi Stanley,

Thanks for your message.

> The problem is happening on the Page 0 [the first page] of conglomerate 
> 1313 (the conglomerateId) - you can see what table/index this 
> corresponds to with the following query:
>  from sys.sysconglomerates
>  where conglomeratenumber =  1313;
>  From the errors in your log I suspect this to be the table or one of 
> the indexes of the failing query listed:
>    INSERT INTO text_table (guidhigh, guid, data)

That's correct - there are essentially two types of queries which seem 
to cause the issue on the text_table table.  Either the insertion of 
blob data into text_table (it is compressed text), or a select call 
check for the existence of an entry given guidhigh and guid.

> Does your database reboot without any errors after the shutdown/crash?
> You wrote:  " /Derby locates the error, reboots the database, but seems 
> to inevitably report the same error again./ "
> I assume this means you get the same exception when the database reboots 
> (indicating the change was written to the transaction log and is 
> replaying the error as the database attempts to recover when the db 
> reboots).

That's right.  I just tried explicitly restarting the application by 
killing off the process (there is a nanny process which detects this and 
automatically restarts it).  However I still get the same derby errors 
on startup.

> 1) the databases are created in the directory D:\temp...   If you 
> suspect that this directory is every purged/cleared then this in not a 
> good place to have database files.  The files should be in a permanent 
> and secure location.

In this case the d:\ is a raid array, and even though it is written to a 
directory called temp, nothing is being deleted from it.  There are no 
virus scanners running either.

> anything.   Alternately if you shutdown the system then attempt to 
> access the database from a newly started JVM ( I would use IJ) and still 
> get the exception this shows that uncollected derby objects are not the 
> problem.

Yes - I have confirmed that restarting the JVM still reports the same 
error on startup I am afraid.

Any ideas on what to check for now?


Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia    Ph: +61 2 9280 0699
Web: http://www.nuix.com                            Fax: +61 2 9212 6902

View raw message