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 03:41:39 GMT
Hi Stanley,

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

I ran ij from the command-line, and connected to one of the problematic 
databases after killing the load.  Sure enough 1313 refers to the 
primary key of text_table (there are no other indexes defined on this 
table).  This is what is output:


1313                |SQL080331145004520

This is the SQL we used to create this table:

CREATE TABLE text_table (guidhigh BIGINT NOT NULL,
                          guid BIGINT NOT NULL,
                          data BLOB (1G) NOT NULL,
                          PRIMARY KEY (guidhigh, guid))

What is interesting is if I perform a simple query on text_table, I get 
the following:

ij> select count(*) from text_table;
ERROR XSDG2: Invalid checksum on Page Page(0,Container(0, 1313)), 
expected=304,608,373, on-disk version=2,462,088,751, page dump follows: 
Hex dump:
00000000: 0076 0000 0001 0000 0000 0000 27ea 0000  .v..............
00000010: 0000 0006 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0001 0000 0000 0000 0000 0000  ................

Same as my application.  I have also noticed the connection is 
automatically closed, as is the case in my application if I try and 
perform another operation.

ij> select count(*) from text_table;
ERROR 08003: No current connection.

Reconnecting to the database has the same result.

So I guess it is not surprising now that conglomerate 1313 is always 
returned since all worker processes create the same database on startup. 
  However the corruption is always happening on page 0.  If we were 
experiencing true disk problems, I'd expect the page number to be random 
across the machines.

Any ideas on what to try next?


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