[
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,
-Rick
> 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: 10.6.1.0
> 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
> Source)
> ... 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
