File corrupted in chunk 1550574, expected page length 4..1024, got 1852517937 [1.4.191/6]

1,392 views
Skip to first unread message

Matt Hicks

unread,
Mar 3, 2016, 10:12:41 AM3/3/16
to H2 Database
I have a 9gig database file that was open when my Linux machine crashed and rebooted and now I get the following when I try to load the database:

[error] Caused by: java.lang.IllegalStateException: File corrupted in chunk 1550574, expected page length 4..1024, got 1852517937 [1.4.191/6]
[error] at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:773)
[error] at org.h2.mvstore.Page.read(Page.java:649)
[error] at org.h2.mvstore.Page.read(Page.java:195)
[error] at org.h2.mvstore.MVStore.readPage(MVStore.java:1939)
[error] at org.h2.mvstore.MVMap.readPage(MVMap.java:736)
[error] at org.h2.mvstore.Page.getChildPage(Page.java:217)
[error] at org.h2.mvstore.MVMap.binarySearch(MVMap.java:468)
[error] at org.h2.mvstore.MVMap.binarySearch(MVMap.java:469)
[error] at org.h2.mvstore.MVMap.binarySearch(MVMap.java:469)
[error] at org.h2.mvstore.MVMap.get(MVMap.java:450)
[error] at org.h2.mvstore.MVStore.getChunkIfFound(MVStore.java:954)
[error] at org.h2.mvstore.MVStore.getChunk(MVStore.java:931)
[error] at org.h2.mvstore.MVStore.readPage(MVStore.java:1930)
[error] at org.h2.mvstore.MVMap.readPage(MVMap.java:736)

I have run `Recover` but it also crashes with this:

[info] 2016.03.03 08:54:40:629 [main] ERROR t.n.c.NaboCloud$.main:38 - java.lang.IllegalStateException: File corrupted in chunk 1550574, expected page length 4..1024, got 1852517937 [1.4.191/6]
[info] at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:773)
[info] at org.h2.mvstore.Page.read(Page.java:649)
[info] at org.h2.mvstore.Page.read(Page.java:195)
[info] at org.h2.mvstore.MVStore.readPage(MVStore.java:1939)
[info] at org.h2.mvstore.MVMap.readPage(MVMap.java:736)
[info] at org.h2.mvstore.Page.getChildPage(Page.java:217)
[info] at org.h2.mvstore.MVMap.binarySearch(MVMap.java:468)
[info] at org.h2.mvstore.MVMap.binarySearch(MVMap.java:469)
[info] at org.h2.mvstore.MVMap.binarySearch(MVMap.java:469)
[info] at org.h2.mvstore.MVMap.get(MVMap.java:450)
[info] at org.h2.mvstore.MVStore.getChunkIfFound(MVStore.java:954)
[info] at org.h2.mvstore.MVStore.getChunk(MVStore.java:931)
[info] at org.h2.mvstore.MVStore.readPage(MVStore.java:1930)
[info] at org.h2.mvstore.MVMap.readPage(MVMap.java:736)
[info] at org.h2.mvstore.Page.getChildPage(Page.java:217)

Is there anything I can do to recover the data?  I've been using H2 in production systems because it's faster than other SQL databases, but if it's this easy to corrupt and lose data then I'm going to have to re-think that.

Any insights would be greatly appreciated.

Thanks,

Matt Hicks
OUTR Technologies, LLC

Zheng Wang

unread,
Jul 12, 2016, 1:37:45 AM7/12/16
to H2 Database
I met the same problem. H2 database 1.4.191 was corrupted after a Windows 7 crash. 
When connecting to the database via Squirrel using URL jdbc:h2:C:/Temp/database_corrupted/database/test;AUTO_SERVER=TRUE, I got below error

java.util.concurrent.ExecutionException: java.lang.RuntimeException: org.h2.jdbc.JdbcSQLException: File corrupted while reading record: null. Possible solution: use the recovery tool [90030-191]
at java.util.concurrent.FutureTask.report(Unknown Source)
at java.util.concurrent.FutureTask.get(Unknown Source)
at net.sourceforge.squirrel_sql.client.mainframe.action.OpenConnectionCommand.awaitConnection(OpenConnectionCommand.java:132)
at net.sourceforge.squirrel_sql.client.mainframe.action.OpenConnectionCommand.access$100(OpenConnectionCommand.java:45)
at net.sourceforge.squirrel_sql.client.mainframe.action.OpenConnectionCommand$2.run(OpenConnectionCommand.java:115)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: org.h2.jdbc.JdbcSQLException: File corrupted while reading record: null. Possible solution: use the recovery tool [90030-191]
at net.sourceforge.squirrel_sql.client.mainframe.action.OpenConnectionCommand.executeConnect(OpenConnectionCommand.java:171)
at net.sourceforge.squirrel_sql.client.mainframe.action.OpenConnectionCommand.access$000(OpenConnectionCommand.java:45)
at net.sourceforge.squirrel_sql.client.mainframe.action.OpenConnectionCommand$1.run(OpenConnectionCommand.java:104)
... 5 more
Caused by: org.h2.jdbc.JdbcSQLException: File corrupted while reading record: null. Possible solution: use the recovery tool [90030-191]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.mvstore.db.MVTableEngine$Store.convertIllegalStateException(MVTableEngine.java:195)
at org.h2.mvstore.db.MVTableEngine$Store.open(MVTableEngine.java:167)
at org.h2.mvstore.db.MVTableEngine.init(MVTableEngine.java:99)
at org.h2.engine.Database.getPageStore(Database.java:2460)
at org.h2.engine.Database.open(Database.java:692)
at org.h2.engine.Database.openDatabase(Database.java:270)
at org.h2.engine.Database.<init>(Database.java:264)
at org.h2.engine.Engine.openSession(Engine.java:65)
at org.h2.engine.Engine.openSession(Engine.java:175)
at org.h2.engine.Engine.createSessionAndValidate(Engine.java:153)
at org.h2.engine.Engine.createSession(Engine.java:136)
at org.h2.engine.Engine.createSession(Engine.java:28)
at org.h2.engine.SessionRemote.connectEmbeddedOrServer(SessionRemote.java:349)
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:72)
at net.sourceforge.squirrel_sql.fw.sql.SQLDriverManager.getConnection(SQLDriverManager.java:133)
at net.sourceforge.squirrel_sql.client.mainframe.action.OpenConnectionCommand.executeConnect(OpenConnectionCommand.java:167)
... 7 more
Caused by: java.lang.IllegalStateException: File corrupted in chunk 19309, expected page length 4..1024, got 745365880 [1.4.191/6]
at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:773)
at org.h2.mvstore.Page.read(Page.java:649)
at org.h2.mvstore.Page.read(Page.java:195)
at org.h2.mvstore.MVStore.readPage(MVStore.java:1939)
at org.h2.mvstore.MVMap.readPage(MVMap.java:736)
at org.h2.mvstore.Page.getChildPage(Page.java:217)
at org.h2.mvstore.Cursor.fetchNext(Cursor.java:150)
at org.h2.mvstore.Cursor.next(Cursor.java:50)
at org.h2.mvstore.MVStore.loadChunkMeta(MVStore.java:690)
at org.h2.mvstore.MVStore.readStoreHeader(MVStore.java:670)
at org.h2.mvstore.MVStore.<init>(MVStore.java:353)
at org.h2.mvstore.MVStore$Builder.open(MVStore.java:2888)
at org.h2.mvstore.db.MVTableEngine$Store.open(MVTableEngine.java:154)
... 23 more


When running the Recover command 'java -cp h2-1.4.191.jar org.h2.tools.Recover', I got below error

Exception in thread "main" java.lang.IllegalStateException: File corrupted in chunk 19309, expected page length 4..1024, got 745365880 [1.4.191/6]
        at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:773)

        at org.h2.mvstore.Page.read(Page.java:649)
        at org.h2.mvstore.Page.read(Page.java:195)
        at org.h2.mvstore.MVStore.readPage(MVStore.java:1939)
        at org.h2.mvstore.MVMap.readPage(MVMap.java:736)
        at org.h2.mvstore.Page.getChildPage(Page.java:217)
        at org.h2.mvstore.Cursor.fetchNext(Cursor.java:150)
        at org.h2.mvstore.Cursor.next(Cursor.java:50)
        at org.h2.mvstore.MVStore.loadChunkMeta(MVStore.java:690)
        at org.h2.mvstore.MVStore.readStoreHeader(MVStore.java:670)
        at org.h2.mvstore.MVStore.<init>(MVStore.java:353)
        at org.h2.mvstore.MVStore$Builder.open(MVStore.java:2888)
        at org.h2.mvstore.MVStoreTool.info(MVStoreTool.java:336)
        at org.h2.tools.Recover.process(Recover.java:342)
        at org.h2.tools.Recover.runTool(Recover.java:196)
        at org.h2.tools.Recover.main(Recover.java:159)

Found a similar issue https://github.com/h2database/h2database/issues/142 which seems indicating corruption is no longer an issue since 1.4.188, but actually it is still an issue. 

I hope H2 developers can look into this, as it is really shocking to lose all the data so easily.

Thanks

Thomas Mueller Graf

unread,
Jul 20, 2016, 11:33:00 AM7/20/16
to h2-da...@googlegroups.com
Hi,

I would be interested to analyze the database file if you still have them.

Regards,
Thomas
--
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 h2-database...@googlegroups.com.
To post to this group, send email to h2-da...@googlegroups.com.
Visit this group at https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

Zheng Wang

unread,
Jul 22, 2016, 9:06:53 AM7/22/16
to H2 Database
Hi Thomas,

I have sent the database files to you in an email. Please let me know if you have any finding. Thanks

Regards,
Zheng
To unsubscribe from this group and stop receiving emails from it, send an email to h2-database+unsubscribe@googlegroups.com.

Rachid OURIHC

unread,
Aug 19, 2016, 10:20:12 AM8/19/16
to H2 Database
Any news, 
I'm using the version 1.4.189 of H2; and, the databases are corrupted. 

vvm

unread,
Aug 25, 2016, 3:44:11 PM8/25/16
to H2 Database
To simplify various unrelated issues I am pasting a snippet from org.h2.mvstore.Page.java(line 666, coincidence?:) -- https://github.com/h2database/h2database/blob/master/h2/src/main/org/h2/mvstore/Page.java

"...
       if (check != (short) checkTest) {
        log.warn("Potentially corrupted chunk: @"+(start + pageLength)+" Expected: "+check+" vs "+checkTest +" Page length: "+pageLength);
       
        /*
            throw DataUtils.newIllegalStateException(
                    DataUtils.ERROR_FILE_CORRUPT,
                    "File corrupted in chunk {0}, expected check value {1}, got {2}",
                    chunkId, checkTest, check);
                    */
        }

..."
The page is written in a sequence of writes: pageLength(offset=0),page data(offset+4),check(offset+4+pageLength) 
The consistency check is rather simple not to incur any significant overhead (I guess). 

I commented out throw error part and let program run. I didn't encounter problems bypassing the error. And no, it doesn't go away on s.compactMoveChunks().
Potentially, one can overwrite the "check" int to avoid seeing this error all the time. 
Granted, this is not a good solution but I couldn't find other tools to simply recover one MVStore file that contained one record. Maybe I missed it.
Needless to say, this error prevented the whole application startup. It was rather annoying. I guess in my case, the "check" int was not written before the power cord was pulled (machined decided to rebooted)
But this error demonstrates a fragile nature of the write process.

So what would be a more robust solution than ignoring this error (smile)? A page post restore area where a copy of the old page is kept until check is written.
The page copy should be kept for a while. But that would probably dictate store format changes and incur a performance penalty. Again maybe I am missing something.

Post restore area should be configurable and created with allocated space for multiple pages with various (but fixed) sizes. 
Somehow, we need to overcome this with a more reliable hardware and a backups.

Vadim

vvm

unread,
Aug 25, 2016, 4:26:07 PM8/25/16
to H2 Database

With 9G file, you could probably write a custom program to trace from the end of the chunk and eliminate good pages from the offending one making assumption either "pageLength" or "offset" write was off. 
Check format of the chunk header and read off the "next chunk" and start from there up.

Not sure if you can manually fix one chunk but I would be interested to know what to do in this case myself.

P.S.
Would format be more robust if pageLength, check are written twice (just like file header). That would waste 8 bytes per page but perhaps might provide a better chance for recovery later on.



On Thursday, March 3, 2016 at 10:12:41 AM UTC-5, Matt Hicks wrote:
Reply all
Reply to author
Forward
0 new messages