db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5659) Database corrupted after delete operation - results in sqlcode XSDB2
Date Fri, 16 Mar 2012 16:43:41 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231364#comment-13231364

Rick Hillegas commented on DERBY-5659:

Hi Ratish,

My sense from looking at this derby.log is that it merely records failed attempts to boot
the database after it was corrupted. I do not see any information about the DELETE statement
which you suspected was involved in the original corruption. At this point you can't boot
the database to extract the data using friendly tools. You have two options:

1) Restore the database from a backup. See the "Backing up and restoring databases" section
of the Derby Server and Administration Guide.

2) If you don't have a recent backup, then you can try to extract the data from the conglomerates
in the seg0 directory using the DataFileReader class attached to DERBY-5201. For an unbootable
database, this is likely to be very painful since you will first have to figure out which
of the conglomerates are tables (those are the ones you want to dump) and which are indexes
(you can ignore the indexes). If you have a script which creates an empty database, then it
is possible that the new database has the same conglomerate numbers as the corrupted database
and you can figure out the conglomerate numbers in the corrupted database by querying SYS.SYSCONGLOMERATES
in the new database. If the corrupted container is a table (rather than an index), then DataFileReader
won't be able to help you dump that table. Conglomerate file names in the seg0 directory have
the form c#.dat where # is the hex representation of the conglomerate number from SYS.SYSCONGLOMERATES.

I hope this helps,
> Database corrupted after delete operation - results in sqlcode XSDB2
> --------------------------------------------------------------------
>                 Key: DERBY-5659
>                 URL: https://issues.apache.org/jira/browse/DERBY-5659
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:
>         Environment: Windows 7 32 bit
>            Reporter: ratish ram
>            Priority: Critical
>              Labels: corruption, xsdb2
>         Attachments: derby.log
> Derby Embedded Database became non-accessible after a delete operation. Trying to connect
to the database now results in the following exception.
> Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE:
XJ040, SQLERRMC: Failed to start database 'XXXX' with class loader org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@73983ad7,
see the next exception for details.::SQLSTATE: XSDB2Unknown container format at container
null : 1,702,392,933
> 	at org.apache.derby.client.am.Connection.completeSqlca(Unknown Source)
> 	at org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(Unknown Source)
> 	at org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(Unknown Source)
> 	at org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(Unknown Source)
> 	at org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(Unknown Source)
> 	at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(Unknown Source)
> 	at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(Unknown Source)
> 	at org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(Unknown Source)
> 	at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source)
> 	at org.apache.derby.client.net.NetConnection.<init>(Unknown Source)
> 	at org.apache.derby.client.net.NetConnection40.<init>(Unknown Source)
> 	at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(Unknown
> 	... 52 more

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message