error: SQLCODE: -1, SQLSTATE: XSDG2, SQLERRMC: Invalid
checksum on Page Page(0,Container(0, 474144)), expected=229,350,622, on-disk
version=1,888,684,690, page dump follows: Hex dump:
: 0076 0001 93b4 .v..ﾓﾴ..
0010: 0006
What can I do to just delete this table and then rebuild it from the Mirror
file?
Can you use RENAME TABLE?
Then you can create your new table with the old name, and just
leave that old, damaged table around.
Of course, you'll want to arrange a more long-term solution,
but that might get you
with invalid checksum on page
Date: Mon, Mar 10, 2014 14:55
What can I do to just delete this table and then rebuild it from the Mirror
file?
Can you use RENAME TABLE?
Then you can create your new table with the old name, and just
leave that old, damaged table around.
Of course, you'll want
and hex dump.
- Reply message -
From: Bryan Pendleton-3 [via Apache Database] [hidden
email]http://user/SendEmail.jtp?type=nodenode=137791i=0
To: EagleS [hidden
email]http://user/SendEmail.jtp?type=nodenode=137791i=1
Subject: deleting a corrupted database with invalid checksum on page
Hi,
I have an intensive data-processing application which utilises Apache
Derby
version - 10.3.1.4.
My Customer is running this application on Windows 2003 and has 30GB derby
database size.
Customer has reported the following error.
ERROR XSDG2: Invalid checksum on Page Page(0
on database directory G:\Nortel\ddb
Database Class Loader started - derby.database.classpath=''
BEGIN SHUTDOWN ERROR STACK -
ERROR XSDG2: Invalid checksum on Page Page(0,Container(0, 1216)),
expected=2,123,489,974, on-disk version=4,195,712,410, page dump follows:
Hex
.
ERROR XSDG2: Invalid checksum on Page Page(0,Container(0, 1216)).
Hi Devi,
I suspect you've been hit by a data corruption bug present in Derby
10.3.1.4 and 10.3.2.1: https://issues.apache.org/jira/browse/DERBY-3347
You'll have to recover the database from backup and upgrade to a Derby
version
-Original Message-
From: David Sitsky [mailto:s...@nuix.com]
Sent: Monday, June 15, 2009 12:11 AM
To: Derby Discussion
Subject: Re: Repairing a corrupted database with invalid checksum on page
Thank you for posting your solution. I added a reference to this thread
in:
https
I would suggest considering the creation of a recovery mode where the user
has access to a simple interface (or command line) and the process is more
automated and logged.
This would definitely be the best outcome.. as an end-user, being able
to launch something like ij in recovery mode, and
Thank you for posting your solution. I added a reference to this thread in:
https://issues.apache.org/jira/browse/DERBY-1648
Perhaps you could post your patch there and hit the grant to apache button
in case someone wants to use it as the basis for an integrated solution.
Done.
--
Cheers,
David Sitsky wrote:
I realise this is hackery, but would there be any benefit for a
polished version of this to go into the main code? Sadly, corruption
is a fact of life, whether it is due to software or hardware (or
humans)..
Hi David,
Thank you for posting your solution. I added a
Kathey Marsden wrote:
Mike Matrigali wrote:
Then you could figure out how important container 1105
is. The best case is if 1105 is an index then one need only drop the
index and recreate it. From the conglomerate id I think it is an
index:
Once you get your database in a bootable state you
ERROR STACK -
ERROR XSDG2: Invalid checksum on Page Page(3586,Container(0, 1105)),
expected=1,077,491,282, on-disk version=1,792, page dump follows: Hex dump:
: 0075 .u..
0010: 0006
:\Baulderstone\Stores\Complete-bea2c17c113d42519b6ff5aa5d9b0141\Stores\EvidenceDatabase
BEGIN SHUTDOWN ERROR STACK -
ERROR XSDG2: Invalid checksum on Page Page(3586,Container(0, 1105)),
expected=1,077,491,282, on-disk version=1,792, page dump follows: Hex dump:
Mike Matrigali wrote:
Then you could figure out how important container 1105
is. The best case is if 1105 is an index then one need only drop the
index and recreate it. From the conglomerate id I think it is an
index:
Once you get your database in a bootable state you can identify the
David Sitsky wrote:
Ok - we are restructuring the application, so that now, we can get
away with a primary key field of just an INTEGER, rather than the two
BIGINT columns. Also, because of the restructure, we don't need to
check for the existence of a duplicate record before insertion, so we
Ok - we are restructuring the application, so that now, we can get away
with a primary key field of just an INTEGER, rather than the two BIGINT
columns. Also, because of the restructure, we don't need to check for
the existence of a duplicate record before insertion, so we can now
create the
David Sitsky [EMAIL PROTECTED] writes:
For what its worth, I did another run last night on my 6 quad-core
system. This time I had the derby issue happen for a JVM process on
machine 1, two processes on machine 4, and one on machine 5. I run
four JVM processes per quad-core machine.
All
[EMAIL PROTECTED] wrote:
David Sitsky [EMAIL PROTECTED] writes:
For what its worth, I did another run last night on my 6 quad-core
system. This time I had the derby issue happen for a JVM process on
machine 1, two processes on machine 4, and one on machine 5. I run
four JVM processes per
(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
Hi Dave -
The good news is that it looks like you do not have to recover this
database from backups because:
1) since you can boot the database using IJ the corruption is not in
the transaction log (I assume you did not directly modify or delete any
files in the database directory tree in
than a
hardware one.
The OS has not reported any disk issues at all.
Cheers,
David
Narayanan wrote:
Hi David,
You might find the following links containing earlier discussions on
the similar issue useful,
http://www.nabble.com/invalid-checksum-tt9528741.html#a9528741
http://www.nabble.com
a software issue than a
hardware one.
The OS has not reported any disk issues at all.
Cheers,
David
Narayanan wrote:
Hi David,
You might find the following links containing earlier discussions on
the similar issue useful,
http://www.nabble.com/invalid-checksum-tt9528741.html#a9528741
http
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:
select CONGLOMERATENUMBER, CONGLOMERATENAME
from sys.sysconglomerates
where
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:
: 0076 0001
Hi David,
You might find the following links containing earlier discussions on the
similar issue useful,
http://www.nabble.com/invalid-checksum-tt9528741.html#a9528741
http://www.nabble.com/Derby-crash-%28urgent%29-tt16217446.html#a16265491
https://issues.apache.org/jira/browse/DERBY-2475
a
hardware one.
The OS has not reported any disk issues at all.
Cheers,
David
Narayanan wrote:
Hi David,
You might find the following links containing earlier discussions on the
similar issue useful,
http://www.nabble.com/invalid-checksum-tt9528741.html#a9528741
http://www.nabble.com/Derby
we installed the app serveral times and i think the following lines are per
installation (so per installation it happend on the same page):
org.hibernate.util.JDBCExceptionReporter - Invalid checksum on Page
Page(28,Container(0, 1248)), expected=3'455'715'557, on-disk
version=3'357'396'866
and i think the following lines are per
installation (so per installation it happend on the same page):
org.hibernate.util.JDBCExceptionReporter - Invalid checksum on Page
Page(28,Container(0, 1248)), expected=3'455'715'557, on-disk
version=3'357'396'866, page dump follows: Hex dump
|
|-+
-|
|
|
| To: Derby Discussion derby-user@db.apache.org
|
| cc:
|
| Subject: Re: 'Invalid checksum
:
|
| Subject: Re: 'Invalid checksum on Page' error
|
| cc:
|
| Subject: Re: 'Invalid checksum on Page' error
of this posting ) indicates an invalid
checksum on a page . I have only included the first few lines.
This may have occurred when i was selecting data from the database.
If I restart the application, I sometimes get the same SQLException on the
thread that is inserting data , after a few succesful inserts
'.
The derby.log file (at the end of this posting ) indicates an invalid
checksum on a page . I have only included the first few lines.
This may have occurred when i was selecting data from the database.
If I restart the application, I sometimes get the same SQLException on the
thread that is inserting
34 matches
Mail list logo
