Re: [h2] Database corrupt after computer power failure.
Hi, Until this problem is fixed, it might make sense to use the PageStore storage engine, by appending ;mv_store=false to the database URL. Regards, Thomas On Friday, May 8, 2015, Mikael Nordenberg mik...@ikanos.se wrote: Thank you for your response and time to investigate this. That is very interesting! I attach another case when this happened, in case it can be used to verify your assumption. I have not been able to reproduce this on a test machine yet. But it has happened twice in just a matter of days on one client machine, so it may be reproducible on that PC. (The affected PC runs Windows 7, and uses a Samsung 850 EVO SSD drive if that matters.) /Mikael Den fredag 8 maj 2015 kl. 18:12:07 UTC+2 skrev Thomas Mueller: Hi, Thanks a lot! I have analyzed the database file, and I think I know what the problem is. It looks like the disk (or operating system) re-ordered write operations, so that changes later in time (and later in the file) were written, but one earlier change (both in time and in the file) was not written. (Detail for later reference: various entries (in chunks 'aad4' to 'aadb', from 16:05:10.378 to 16:05:13.916) think that chunk 'aad3' (later than 16:05:09.369, earlier than 16:05:10.378) is in block 2, but block 2 actually contains the earlier chunk 'aa7b' from 16:04:24.742). The MVStore should detect this and automatically discard chunks that were written later than 16:05:10.378. It does not currently do that, this is a problem. I will implement this for the next release. I think what also can happen is write re-ordering causes a file to be truncated too early. This would explain a different corruption problem. The fix for that would need to be different however (truncation would need to wait for 45 seconds). Regards, Thomas On Thursday, May 7, 2015, Mikael Nordenberg mik...@ikanos.se wrote: Same corruption happened again today on a clients computer when power disappeared. Will try to reproduce tomorrow in our lab. /Mikael Den torsdag 7 maj 2015 kl. 15:42:48 UTC+2 skrev Mikael Nordenberg: Hi, We are using H2 version 1.4.185 with mv-store. After an unclean shutdown the database file was corrupt. The database is attached. Opening the database results in http://pastebin.com/PXceifPx The database is used from a single thread. Hope this gives anything... /Mikael -- 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+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout. -- 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+unsubscr...@googlegroups.com javascript:_e(%7B%7D,'cvml','h2-database%2bunsubscr...@googlegroups.com'); . To post to this group, send email to h2-database@googlegroups.com javascript:_e(%7B%7D,'cvml','h2-database@googlegroups.com');. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
Re: [h2] Moving from H2 1.3.176 to 1.4.187 results in sporadic ArrayIndexOutOfBoundsExceptions?
Hi Thomas, The default page size is 4096 bytes, did you set it manually to 2048 bytes? No, I didn't change it. Do note, that the databases were created with 1.3.176 and the crashes happened with 1.4.187. I've reverted to 1.3.176. That stopped the crashes almost immediately, although we are still getting a few. These newer crash messages refer to 4096 bytes. eg: Caused by: java.lang.ArrayIndexOutOfBoundsException: 4096 at org.h2.store.Data.writeVarInt(Data.java:1187) at org.h2.store.Data.writeValue(Data.java:531) at org.h2.index.PageBtreeIndex.writeRow(PageBtreeIndex.java:394) at org.h2.index.PageBtreeNode.writeData(PageBtreeNode.java:454) at org.h2.index.PageBtreeNode.write(PageBtreeNode.java:427) at org.h2.store.PageStore.writeBack(PageStore.java:1047) at org.h2.util.CacheLRU.removeOld(CacheLRU.java:216) at org.h2.util.CacheLRU.removeOldIfRequired(CacheLRU.java:142) at org.h2.util.CacheLRU.put(CacheLRU.java:116) On Saturday, 9 May 2015 02:12:07 UTC+10, Thomas Mueller wrote: Hi, I don't know what the problem could be. There were no changes in this area. What is strange is: The exception says it is trying to read past the end of a page that is 2048 bytes long. The default page size is 4096 bytes, did you set it manually to 2048 bytes? According to the database URL it doesn't look like. Regards, Thomas On Wednesday, May 6, 2015, Steve McLeod steve@gmail.com javascript: wrote: Today I released an update for my product, Poker Copilot. Until today, it used H2 1.3.176. Today's update uses H2 1.4.187, with MV_STORE=false appended to the database URL. After today's update, we are getting many H2 crash reports on both Windows and OS X. Poker Copilot is a mature product that has been using H2 for six years, and is used by many people each day; until this release we were getting infrequent crash reports. It does initially look like this is a sporadic H2 problem, although I am, of course, open to the idea that it is caused by my own programming mistakes. On OS X, the database URL is jdbc:h2:/Users/steve/Library/Application Support/com.barbarysoftware.pokercopilot/database/pokercopilot;DATABASE_EVENT_LISTENER='com.barbarysoftware.pokercopilot.database.DatabaseListener';COMPRESS_LOB=DEFLATE;MV_STORE=false;CACHE_SIZE=65536 The most common crash reports are variants of: java.lang.ArrayIndexOutOfBoundsException: 2048 at org.h2.store.Data.writeVarLong(Data.java:1254) at org.h2.store.Data.writeValue(Data.java:523) at org.h2.index.PageBtreeIndex.writeRow(PageBtreeIndex.java:393) at org.h2.index.PageBtreeNode.writeData(PageBtreeNode.java:453) at org.h2.index.PageBtreeNode.write(PageBtreeNode.java:426) at org.h2.store.PageStore.writeBack(PageStore.java:1046) at org.h2.util.CacheLRU.removeOld(CacheLRU.java:215) at org.h2.util.CacheLRU.removeOldIfRequired(CacheLRU.java:141) at org.h2.util.CacheLRU.put(CacheLRU.java:115) at org.h2.store.PageStore.getPage(PageStore.java:857) at org.h2.index.PageDataIndex.getPage(PageDataIndex.java:233) at org.h2.index.PageDataNode.getRowWithKey(PageDataNode.java:279) at org.h2.index.PageDataIndex.getRowWithKey(PageDataIndex. java:426) at org.h2.index.PageDataIndex.getRow(PageDataIndex.java:415) at org.h2.table.RegularTable.getRow(RegularTable.java:106) at org.h2.index.PageBtreeIndex.getRow(PageBtreeIndex.java:301) at org.h2.index.PageBtreeCursor.get(PageBtreeCursor.java:45) at org.h2.index.IndexCursor.get(IndexCursor.java:260) at org.h2.table.TableFilter.getValue(TableFilter.java:913) at org.h2.expression.ExpressionColumn.getValue( ExpressionColumn.java:186) at org.h2.command.dml.Select.queryFlat(Select.java:580) at org.h2.command.dml.Select.queryWithoutCache(Select.java:685) at org.h2.command.dml.Query.query(Query.java:322) at org.h2.command.dml.Query.query(Query.java:290) at org.h2.command.dml.Query.query(Query.java:36) at org.h2.command.CommandContainer.query( CommandContainer.java:90) at org.h2.command.Command.executeQuery(Command.java:197) ... 18 more and Caused by: java.lang.ArrayIndexOutOfBoundsException: 2048 at org.h2.store.Data.writeStringWithoutLength(Data.java:263) at org.h2.store.Data.writeValue(Data.java:566) at org.h2.index.PageBtreeIndex.writeRow(PageBtreeIndex.java:393) at org.h2.index.PageBtreeNode.writeData(PageBtreeNode.java:453) at org.h2.index.PageBtreeNode.write(PageBtreeNode.java:426) at org.h2.store.PageStore.writeBack(PageStore.java:1046) at org.h2.util.CacheLRU.removeOld(CacheLRU.java:215) at org.h2.util.CacheLRU.removeOldIfRequired(CacheLRU.java:141) at org.h2.util.CacheLRU.put(CacheLRU.java:115)
