Hello, This issue happened again. The database was recovered with the recovery tool and was working fine for a few days. I am seeing an array index out of bounds exception. Stack trace: SELECT * FROM MRKMAGDTA.FMTSPF80 WHERE FMNAM = 'SHLBL131' AND FMMODL = 'ZTZ170XI3' [50000-162] at org.h2.message.DbException.getJdbcSQLException(DbException.java:329) at org.h2.message.DbException.get(DbException.java:158) at org.h2.message.DbException.convert(DbException.java:281) at org.h2.command.Command.executeQuery(Command.java:191) at org.h2.server.TcpServerThread.process(TcpServerThread.java:294) at org.h2.server.TcpServerThread.run(TcpServerThread.java:137) at java.lang.Thread.run(Thread.java:769) Caused by: java.lang.ArrayIndexOutOfBoundsException at org.h2.index.PageDataLeaf.getRowAt(PageDataLeaf.java:327) at org.h2.index.PageDataLeaf.getRowWithKey(PageDataLeaf.java:443) at org.h2.index.PageDataNode.getRowWithKey(PageDataNode.java:270) at org.h2.index.PageDataIndex.getRowWithKey(PageDataIndex.java:406) at org.h2.index.PageDataIndex.getRow(PageDataIndex.java:395) at org.h2.table.RegularTable.getRow(RegularTable.java:109) at org.h2.index.PageBtreeIndex.getRow(PageBtreeIndex.java:295) at org.h2.index.PageBtreeCursor.get(PageBtreeCursor.java:45) at org.h2.index.IndexCursor.get(IndexCursor.java:223) at org.h2.table.TableFilter.getValue(TableFilter.java:869) at org.h2.expression.ExpressionColumn.getValue(ExpressionColumn.java:175) at org.h2.command.dml.Select.queryFlat(Select.java:519) at org.h2.command.dml.Select.queryWithoutCache(Select.java:618) at org.h2.command.dml.Query.query(Query.java:297) at org.h2.command.dml.Query.query(Query.java:267) at org.h2.command.dml.Query.query(Query.java:36) at org.h2.command.CommandContainer.query(CommandContainer.java:82) at org.h2.command.Command.executeQuery(Command.java:187)
Any ideas here? The operating system is AIX, I know it isn't one of the supported platforms, are you aware of any issues with h2 on it? I have stack trace and database if desired. Regards, Geren On Thursday, December 19, 2013 8:54:11 AM UTC-5, Geren White wrote: > > Thomas, > Thanks for the reply. I'm thinking it was the I/O exception as we don't > use temporary tables. I didn't know that it could happen with I/O > exceptions and not just if the disk space ran out. Unfortunately our logs > from before the customer noticed the corruption issue aren't around anymore > so I can't check for any errors that would have caused the issue. > I understand that it happens, just wanted to double check that I'm not > using the database in an unsafe manner. I'm going to look into adding in > backups and automatic recovery for the future. > Anyways, thanks for the database and the continued work on it. Other than > this one problem it has worked great for us. > > Thanks, > Geren > > > On Wednesday, December 18, 2013 5:05:24 PM UTC-5, Thomas Mueller wrote: >> >> Hi, >> >> Yes, with version 1.3.162 and older, the following problem can occur: on >> out of disk space, the database can get corrupt sometimes, if later write >> operations succeed. The same problem happens on other kinds of I/O >> exceptions (where one or some of the writes fail, but subsequent writes >> succeed). Now the file is closed on the first unsuccessful write operation, >> so that later requests fail consistently. >> >> With version 1.3.171 and older: when using local temporary tables and not >> dropping them manually before closing the session, and then killing the >> process could result in a database that couldn't be opened. >> >> I think it could be either one of those problems. >> >> Database corruptions are really annoying, but unfortunately it is quite >> hard to ensure such problems can never occur. H2 currently uses quite a >> "traditional" database file format (b-tree pages of a fixed size, overflow >> pages, transaction log, undo log). The file format and transaction log / >> recovery logic are quite complex. Still there are corruptions sometimes... >> This is one of the reasons to change to a different, much simpler storage >> format (the MVStore) in the future. Of course there is still a risk, but my >> hope is that the risk is much lower, because the algorithm is simpler. >> >> Regards, >> Thomas >> >> >> On Tue, Dec 17, 2013 at 8:06 PM, Geren White <[email protected]> wrote: >> >>> Also, some additional information. The corrupted database error only >>> happened on a certain query. Here is the error and query: >>> >>> >>> *Message: File corrupted while reading record: "[2587] stream data >>> key:781 pos:11 remaining:0". Possible solution: use the recovery tool; SQL >>> statement:* >>> >>> *SELECT * FROM MRKMAGDTA.FLDSPF80 WHERE (FLFMNM = 'SHLBL70' AND FLDMOD = >>> 'ZTZ170XI3') OR (FLFMNM = 'WMOSLBL' AND FLDMOD = '*MASTER') [90030-162]* >>> I connected to the h2 database through H2 console and received the same >>> error if I ran that query. If I removed the OR portion the query would run. >>> >>> On Tuesday, December 17, 2013 12:15:38 PM UTC-5, Geren White wrote: >>>> >>>> Hello, >>>> I have an application that uses the H2 database and one of our >>>> customers had an issue with a corrupted database the other day. We run >>>> the >>>> tcp database server with allow others option set. On the customers >>>> environment we have two of our applications running, so two of the H2 >>>> database servers are running. They are configured to run on separate >>>> ports >>>> and handle connections to different databases. >>>> >>>> Our connection string is: jdbc:h2:tcp://localhost:PORT/ >>>> H2_DIR/H2_DB;MODE=MYSQL >>>> The port, h2_dir, and h2_db get filled in with valid values. From >>>> looking over other database corruption issues I don't believe we are using >>>> any dangerous options. I haven't seen anything against using the MYSQL >>>> option. >>>> We also have client applications that will connect in the same manner >>>> but obviously with the IP address instead of localhost. >>>> >>>> I was able to recover the h2 database using the recovery tool. Looking >>>> over the transaction log I do see one error but I'm unsure of what it >>>> means. I've attached the transaction log if someone else could take a >>>> look >>>> that would be greatly appreciated. The error that I noticed occurred on >>>> line 13682. >>>> I also have the corrupted database if any one would like to take a look >>>> at that. >>>> I'm pretty sure the database was created with version 1.3.162. I >>>> recovered it with version 1.3.173. >>>> >>>> From what I've seen there are two major corruption issues. If the >>>> server ran out of disk space and we attempted to write to the database. >>>> Also if there are temporary tables and the application was shut down >>>> unexpectedly. The server that was running the database has plenty of >>>> space. Also we're not using any temporary tables and the customer said >>>> that the application had been running for about a month with no shutdowns. >>>> So I don't think either of these could be the issue. >>>> >>>> Thank you, >>>> Geren White >>>> >>>> >>>> -- >>> 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 http://groups.google.com/group/h2-database. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- 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 http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out.
