Today I discovered something very interesting. I took a corrupted database 
that 199 tripped over and tried running the recovery tool. This resulted in 
a similar exception our application logged at the time the database got 
corrupted:

jambo@jambo8:~$ java -cp h2-1.4.199.jar org.h2.tools.Recover
Exception in thread "main" java.lang.IllegalStateException: Reading from 
nio:/home/jambo/database.mv.db failed; file length 1127067648 read length 
4096 at 1152263673 [1.4.199/1]
at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:883)
at org.h2.mvstore.DataUtils.readFully(DataUtils.java:420)
at org.h2.mvstore.FileStore.readFully(FileStore.java:98)
at org.h2.mvstore.MVStore.readBufferForPage(MVStore.java:1048)
at org.h2.mvstore.MVStore.readPage(MVStore.java:2186)
at org.h2.mvstore.MVMap.readPage(MVMap.java:554)
at org.h2.mvstore.Page$NonLeaf.getChildPage(Page.java:1086)
at org.h2.mvstore.Cursor.hasNext(Cursor.java:53)
at org.h2.mvstore.MVStore.readStoreHeader(MVStore.java:793)
at org.h2.mvstore.MVStore.<init>(MVStore.java:401)
at org.h2.mvstore.MVStore$Builder.open(MVStore.java:3343)
at org.h2.mvstore.MVStoreTool.info(MVStoreTool.java:347)
at org.h2.tools.Recover.process(Recover.java:344)
at org.h2.tools.Recover.runTool(Recover.java:195)
at org.h2.tools.Recover.main(Recover.java:158)
Caused by: java.io.EOFException
at org.h2.mvstore.DataUtils.readFully(DataUtils.java:408)
... 13 more

So I decided to try the same thing using 196:

jambo@jambo8:~$ java -cp h2-1.4.196.jar org.h2.tools.Recover

what gives? NO ERROR! Version 196 succesfully created a SQL script and I 
was able to create a new database from it using:

jambo@jambo8:~$ java -cp h2*.jar org.h2.tools.RunScript -url 
jdbc:h2:./database -user sa -script database.h2.sql

I have yet to determine if there is anything missing from this recovered 
database, which will not be easy. But from where I stand 199 trips over a 
database file that 196 can process. Of course I understand that this does 
not mean all would be fine using the database in 196 but does this make any 
sense to you? Could it be that 199 is more likely to throw an exception on 
the same database? Or could this just be an example of 196 functioning 
improperly on a database that has been written to by 199 without throwing 
an exception at all?

I will start evaluating the recovered database to see if it is a complete 
recovery and report back here. In the meantime any insights into this 
matter would be very appreciated.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/h2-database/796fc36d-ad70-4040-85d9-8c172205e4b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to