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 <gtwh...@gmail.com> 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 h2-database...@googlegroups.com. >>> To post to this group, send email to h2-da...@googlegroups.com. >>> 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 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/groups/opt_out.
