Hi, > I actually do disable the transaction log because I don't require > durability and I need the performance. Right now I disable both the > UNDO_LOG (thinking this affects atomicity) and the LOG (thinking this > affects durability).
This is documented at http://h2database.com/html/faq.html#reliable > Can you give an advice on what settings to use if I don't require > atomicity and durability, but I do not want the database to become > corrupted when killing the process. Yes, see http://h2database.com/html/performance.html#database_performance_tuning and below. Regards, Thomas > > regards, > > Vasco > > >> Hi, >> >> If you get such problems, it's typically a database corruption. There >> are some known reasons to get such problems, for example by disabling >> the transaction log; it's also possible that there is still a bug in >> the database engine in this area. To recover the data, use the tool >> org.h2.tools.Recover to create the SQL script file, and then re-create >> the database using this script. >> >> Some known causes are: >> >> With version 1.3.162 and older: 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. >> >> Important corruption problems were fixed in version 1.2.135 and >> version 1.2.140 (see the change log). Known causes for corrupt >> databases are: if the database was created or used with a version >> older than 1.2.135, and the process was killed while the database was >> closing or writing a checkpoint. Using the transaction isolation level >> READ_UNCOMMITTED (LOCK_MODE 0) while at the same time using multiple >> connections. Disabling database file protection using (setting >> FILE_LOCK to NO in the database URL). Some other areas that are not >> fully tested are: Platforms other than Windows XP, Linux, Mac OS X, or >> JVMs other than Sun 1.5 or 1.6; the feature MULTI_THREADED; the >> features AUTO_SERVER and AUTO_RECONNECT; the file locking method >> 'Serialized'. >> >> If this is not the problem, I am very interested in analyzing and >> solving this problem. Corruption problems have top priority for me. >> The questions I typically ask is: >> >> - Did the system ever run out of disk space? >> - Could you send the full stack trace of the exception including message >> text? >> - Did you use SHUTDOWN DEFRAG or the database setting DEFRAG_ALWAYS >> with H2 version 1.3.159 or older? >> - What is your database URL? >> - How many connections does your application use concurrently? >> - Do you use temporary tables? >> - Did you use LOG=0 or LOG=1? >> - With which version of H2 was this database created? >> You can find it out using: >> select * from information_schema.settings where name='CREATE_BUILD' >> or have a look in the SQL script created by the recover tool. >> - Did the application run out of memory (once, or multiple times)? >> - Do you use any settings or special features (for example cache settings, >> two phase commit, linked tables)? >> - Do you use any H2-specific system properties? >> - Is the application multi-threaded? >> - What operating system, file system, and virtual machine >> (java -version) do you use? >> - How did you start the Java process (java -Xmx... and so on)? >> - Is it (or was it at some point) a networked file system? >> - How big is the database (file sizes)? >> - How much heap memory does the Java process have? >> - Is the database usually closed normally, or is process terminated >> forcefully or the computer switched off? >> - Is it possible to reproduce this problem using a fresh database >> (sometimes, or always)? >> - Are there any other exceptions (maybe in the .trace.db file)? >> Could you send them please? >> - Do you still have any .trace.db files, and if yes could you send them? >> - Could you send the .h2.db file where this exception occurs? >> >> Regards, >> Thomas >> >> >> >> On Tue, Mar 20, 2012 at 10:26 PM, Vasco Visser <[email protected]> >> wrote: >>> I wanted to run a debugger over the H2 source today but haven't been >>> able to reproduce this bug. Seems like something undeterministic is >>> going on. This is also corroborated by the fact that the problem last >>> week occurred with different selections for different database >>> instances. So, Last week I had the problem three times in a row, each >>> time starting a DB from scratch and now I can't reproduce it. I >>> realise this is probably to vague for anyone in the group to says >>> something useful about, nevertheless, I want to ask if anyone has any >>> input? >>> >>> regards, Vasco >>> >>> >>> On Sat, Mar 17, 2012 at 8:23 PM, Vasco Visser <[email protected]> >>> wrote: >>>> Hi, >>>> >>>> I'm getting an ArrayIndexOutOfBoundsException in both 1.3.162 and 1.3.164: >>>> >>>> 03-17 19:33:32 jdbc[2]: exception >>>> org.h2.jdbc.JdbcSQLException: General error: >>>> "java.lang.ArrayIndexOutOfBoundsException: 0"; SQL statement: >>>> SELECT * FROM "SYS_2003652629_mc" ORDER BY "p_T1_ORG_NAME_edi" DESC >>>> [50000-164] >>>> 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.jdbc.JdbcStatement.executeInternal(JdbcStatement.java:173) >>>> at org.h2.jdbc.JdbcStatement.execute(JdbcStatement.java:152) >>>> at org.h2.server.web.WebApp.getResult(WebApp.java:1311) >>>> at org.h2.server.web.WebApp.query(WebApp.java:1001) >>>> at org.h2.server.web.WebApp$1.next(WebApp.java:964) >>>> at org.h2.server.web.WebApp$1.next(WebApp.java:967) >>>> at org.h2.server.web.WebThread.process(WebThread.java:166) >>>> at org.h2.server.web.WebThread.run(WebThread.java:93) >>>> at java.lang.Thread.run(Thread.java:662) >>>> Caused by: java.lang.ArrayIndexOutOfBoundsException: 0 >>>> at org.h2.index.PageDataLeaf.getRowAt(PageDataLeaf.java:327) >>>> at org.h2.index.PageDataCursor.nextRow(PageDataCursor.java:97) >>>> at org.h2.index.PageDataCursor.next(PageDataCursor.java:49) >>>> at org.h2.index.IndexCursor.next(IndexCursor.java:238) >>>> at org.h2.table.TableFilter.next(TableFilter.java:353) >>>> at org.h2.command.dml.Select.queryFlat(Select.java:513) >>>> 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) >>>> ... 9 more >>>> >>>> >>>> I haven't been able to reproduce on simple data. The table has 1 >>>> million rows and about 160 cols. About fifty cols are varchar(255), 10 >>>> cols Integer and the rest is tinyint (at this point all null values). >>>> There is a one field auto increment primary key. >>>> >>>> I noticed that the reducing the size of the selection enough makes >>>> that the problem does not occur. I also noticed that the actual size >>>> of the selection starting from which the problem occurs various for >>>> different instances of the database (building the table multiple >>>> times, each time with the same content). Also important is that the >>>> order by seems not relevant at all, that is, the problem also occurs >>>> when selecting without ordering (I used a query with an order by >>>> because the web interface has an implicit limit which makes the >>>> problem not occur without the order by). The data I use cannot be >>>> posted in the group. If this is a bug in H2 and you need anything from >>>> me wrt the data used, then please contact me directly. >>>> >>>> Kind regards, >>>> >>>> Vasco Visser >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "H2 Database" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/h2-database?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "H2 Database" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/h2-database?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups "H2 > Database" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/h2-database?hl=en. > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
