Another DB just got corrupted. This time I have a bit more information.
Here is the exception with full stacktrace. Any clue?
org.h2.jdbc.JdbcSQLException: File corrupted while reading record:
"page[296100] data leaf overflow parent:296101 next:295586". Possible
solution: use the recovery tool [90030-176]
at
org.h2.message.DbException.getJdbcSQLException(DbException.java:344)
at org.h2.message.DbException.get(DbException.java:178)
at org.h2.message.DbException.get(DbException.java:154)
at org.h2.index.PageDataIndex.getPage(PageDataIndex.java:242)
at org.h2.index.PageDataNode.getLastKey(PageDataNode.java:215)
at org.h2.index.PageDataNode.getLastKey(PageDataNode.java:215)
at org.h2.index.PageDataNode.getLastKey(PageDataNode.java:215)
at org.h2.index.PageDataIndex.<init>(PageDataIndex.java:88)
at org.h2.table.RegularTable.<init>(RegularTable.java:84)
at org.h2.store.PageStore.addMeta(PageStore.java:1693)
at org.h2.store.PageStore.readMetaData(PageStore.java:1624)
at org.h2.store.PageStore.recover(PageStore.java:1406)
at org.h2.store.PageStore.openExisting(PageStore.java:368)
at org.h2.store.PageStore.open(PageStore.java:289)
at org.h2.engine.Database.getPageStore(Database.java:2366)
at org.h2.engine.Database.open(Database.java:657)
at org.h2.engine.Database.openDatabase(Database.java:260)
at org.h2.engine.Database.<init>(Database.java:254)
at org.h2.engine.Engine.openSession(Engine.java:57)
at org.h2.engine.Engine.openSession(Engine.java:164)
at org.h2.engine.Engine.createSessionAndValidate(Engine.java:142)
at org.h2.engine.Engine.createSession(Engine.java:125)
at org.h2.server.TcpServerThread.run(TcpServerThread.java:150)
at java.lang.Thread.run(Thread.java:808)
at org.h2.engine.SessionRemote.done(SessionRemote.java:606)
at org.h2.engine.SessionRemote.initTransfer(SessionRemote.java:129)
at org.h2.engine.SessionRemote.connectServer(SessionRemote.java:430)
at
org.h2.engine.SessionRemote.connectEmbeddedOrServer(SessionRemote.java:311)
at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:107)
at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:91)
at org.h2.Driver.connect(Driver.java:74)
at
slick.jdbc.DriverDataSource.getConnection(DriverDataSource.scala:98)
at
slick.jdbc.DataSourceJdbcDataSource.createConnection(JdbcDataSource.scala:64)
at
slick.jdbc.JdbcBackend$BaseSession.conn$lzycompute(JdbcBackend.scala:415)
at slick.jdbc.JdbcBackend$BaseSession.conn(JdbcBackend.scala:414)
at
slick.jdbc.JdbcBackend$SessionDef$class.prepareStatement(JdbcBackend.scala:297)
at
slick.jdbc.JdbcBackend$BaseSession.prepareStatement(JdbcBackend.scala:407)
at
slick.jdbc.JdbcBackend$SessionDef$class.withPreparedStatement(JdbcBackend.scala:346)
at
slick.jdbc.JdbcBackend$BaseSession.withPreparedStatement(JdbcBackend.scala:407)
at
slick.driver.JdbcActionComponent$InsertActionComposerImpl.preparedInsert(JdbcActionComponent.scala:498)
at
slick.driver.JdbcActionComponent$InsertActionComposerImpl$InsertOrUpdateAction.nativeUpsert(JdbcActionComponent.scala:557)
at
slick.driver.JdbcActionComponent$InsertActionComposerImpl$InsertOrUpdateAction.f$1(JdbcActionComponent.scala:540)
at
slick.driver.JdbcActionComponent$InsertActionComposerImpl$InsertOrUpdateAction.run(JdbcActionComponent.scala:553)
at
slick.driver.JdbcActionComponent$SimpleJdbcDriverAction.run(JdbcActionComponent.scala:32)
at
slick.driver.JdbcActionComponent$SimpleJdbcDriverAction.run(JdbcActionComponent.scala:29)
at
slick.backend.DatabaseComponent$DatabaseDef$$anon$2.liftedTree1$1(DatabaseComponent.scala:237)
at
slick.backend.DatabaseComponent$DatabaseDef$$anon$2.run(DatabaseComponent.scala:237)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:808)
On Tuesday, 19 June 2018 15:15:05 UTC+2, Noel Grandin wrote:
>
>
>
> On 2018/06/19 3:06 PM, Behroz Sikander wrote:
> > What is your opinion on the following statement that I originally
> posted?
> > "After digging into the corruption problem, we found that we use
> tcpAllowOthers and AUTO_SERVER=TRUE at the same time.
> > Due to this reason, we have sometimes "server" property in the .lock.db
> file and sometimes not. In all the corruption
> > cases, we found a .lock.db file with missing "server" property. We will
> remove this property soon."
> >
>
> Don't know. That may just mean that the crash happened during startup,
> before it became a server, but that doesn't mean
> that it correlates with the time of corruption. Corruption unfortunately
> tends to show up either during
> recovery/startup, or much later when a query touches the corrupted data.
>
> If the performance of LOBs doesn't matter to you, you could try
> synchronizing on some single application-wide lock
> object before doing any LOB work, which will minimise the chance that H2
> does something wrong.
> Also try confining LOB modifying SQL code to it's own JdbcConnection.
>
> > And also is there a way to set the trace file directory?
> > "Also, I want to enable tracing but is there a way to specify a
> directory for trace file? a property that I can set as
> > part of connection string? something similar to
> >
>
> Not to my knowledge.
> http://h2database.com/html/features.html#trace_options
>
>
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
