[
https://issues.apache.org/jira/browse/DERBY-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-2254:
----------------------------------
Deleting the log file is the easiest way to guarantee corruption in the derby
database. It is impossible to know what kind of
corruption might have happened but all the following are possible, because
derby rely's on the info in the log file to maintain
consistent data. Because of in memory database caching the database files on
disk may be severely out of date/inconsistent without proper recovery
processing using the log files. All the following corruptions are possible
when one deletes one or more
log files:
transaction inconsistent data between tables - many of these inconsistencies
can't be determined by derby
inconsistent data between base tables and indexes - running the consistency
checker does a good job of checking for this
inconsistent data in long rows - a long row may stretch across many pages and
the links depend on tranactional consistency if this
is broken a number of runtime errors may occur
inconsistent data in long columns - similar to long row a single column may be
linked across many pages and this consistency is
maintained by the transaction log.
If it is ever necessary to remove the log because of some derby bug the only
safe thing to do is to go back to your more recent
backup. If you don't have one, what I usually tell users is to assume the db
they are accessing is corrupt but accessible. The only
safe thing at that point is to data mine the existing db to copy whatever data
looks good out to a file and then load it into a newly
created db. Otherwise one will never know if future errors you encounter in
the db are because of this failed recovery.
> Assert during log file switch: log file position exceeded max log file size
> ---------------------------------------------------------------------------
>
> Key: DERBY-2254
> URL: https://issues.apache.org/jira/browse/DERBY-2254
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.3.1.4
> Environment: Solaris 10, Java SE 6 build 104
> Reporter: Olav Sandstaa
>
> When running simple tpc-b like transactions against a embedded Derby based on
> a SANE build of trunk the following assertion occurs for the background
> thread and all user threads:
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log
> file position exceeded max log file size
> This seems to occur during a switch to a new log file.
> derby.log contains the following call stack for the background thread:
> Exception trace:
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file
> position exceeded max log file size
> at
> org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120)
> at
> org.apache.derby.impl.store.raw.log.LogCounter.makeLogInstantAsLong(LogCounter.java:120)
> at
> org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java:1900)
> at
> org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3530)
> at
> org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:345)
> at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1185)
> at
> org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(LogToFile.java:1540)
> at
> org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(LogToFile.java:1357)
> at
> org.apache.derby.impl.store.raw.RawStore.checkpoint(RawStore.java:439)
> at
> org.apache.derby.impl.store.raw.log.LogToFile.performWork(LogToFile.java:3416)
> at
> org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(BasicDaemon.java:331)
> at
> org.apache.derby.impl.services.daemon.BasicDaemon.work(BasicDaemon.java:668)
> at
> org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:394)
> at java.lang.Thread.run(Thread.java:619)
> 2007-01-17 23:09:48.638 GMT Thread[derby.rawStoreDaemon,5,derby.daemons]
> Cleanup action starting
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file
> position exceeded max log file size
> at
> org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120)
> at
> org.apache.derby.impl.store.raw.log.LogCounter.makeLogInstantAsLong(LogCounter.java:120)
> at
> org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java:1900)
> at
> org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3530)
> at
> org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:345)
> at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1185)
> at
> org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(LogToFile.java:1540)
> at
> org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(LogToFile.java:1357)
> at
> org.apache.derby.impl.store.raw.RawStore.checkpoint(RawStore.java:439)
> at
> org.apache.derby.impl.store.raw.log.LogToFile.performWork(LogToFile.java:3416)
> at
> org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(BasicDaemon.java:331)
> at
> org.apache.derby.impl.services.daemon.BasicDaemon.work(BasicDaemon.java:668)
> at
> org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:394)
> at java.lang.Thread.run(Thread.java:619)
> Cleanup action completed
> For my user threads the call stack is similar:
> Database Class Loader started - derby.database.classpath=''
> 2007-01-17 23:09:36.401 GMT Thread[Thread-51,5,main] (XID = 12632406),
> (SESSIONID = 51), (DATABASE = /export/home/tmp/derby-db), (DRDAID = null),
> Cleanup action starting
> 2007-01-17 23:09:36.401 GMT Thread[Thread-51,5,main] (XID = 12632406),
> (SESSIONID = 51), (DATABASE = /export/home/tmp/derby-db), (DRDAID = null),
> Failed Statement is: UPDATE accounts SET abal = abal + ? WHERE aid = ? AND
> bid = ?
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file
> position exceeded max log file size
> at
> org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120)
> at
> org.apache.derby.impl.store.raw.log.LogCounter.makeLogInstantAsLong(LogCounter.java:120)
> at
> org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java:1900)
> at
> org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3530)
> at
> org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:345)
> at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1185)
> at
> org.apache.derby.impl.store.raw.data.LoggableActions.doAction(LoggableActions.java:221)
> at
> org.apache.derby.impl.store.raw.data.LoggableActions.actionUpdate(LoggableActions.java:85)
> at
> org.apache.derby.impl.store.raw.data.StoredPage.doUpdateAtSlot(StoredPage.java:8521)
> at
> org.apache.derby.impl.store.raw.data.BasePage.updateAtSlot(BasePage.java:1108)
> at
> org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.replace(GenericConglomerateController.java:479)
> at
> org.apache.derby.impl.sql.execute.RowChangerImpl.updateRow(RowChangerImpl.java:523)
> at
> org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:566)
> at
> org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:260)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:358)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1182)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1652)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:299)
> at
> com.sun.derby.perf.clients.tpcb.DBConnection.performTransaction(DBConnection.java:595)
> at com.sun.derby.perf.clients.tpcb.Client.run(Client.java:218)
> After this it seems like no user threads are able to connect to the database
> (not surpricing).
> This happend using a SANE build and I am unsure by just looking at the
> assertion in the code whether this situation would have been fatal also if I
> had been using an INSANE build.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
