Hi, The most stable version is usually the second-latest version. Reason: Bugs are fixed as they are found so the latest version in theory should have the least bugs; but the latest version is new so it is less tested.
> I did a search in the mailing list for database corruption. Yes, unfortunately there were cases where the database was corrupt. In most cases this was due to using dangerous features such as disabling the transaction log or undo log, disabling file locking. But there were also some bugs in the database itself. Compared to how widely H2 is used the probability of a corrupt database is quite low, but it is there. If you use H2 as most people use it, the probability is quite low. The "risky" features are documented in the FAQ. But still, there is a risk. This was one reason for me to start working on the new storage engine "MVStore": to reduce the risk of corruption (the MVStore is quite a bit simpler than the current, traditional storage engine). It is still work in progress however. But even then there is a risk. All databases have that risk, for some it is lower and for some it is higher. Typically it is lower for those that are better tested in real-world scenarios, that means those that have a higher market share. But still there is a risk. And even if there are no bugs in the database itself, there is still a risk that there is a problem on the storage level. To deal with the risk, I suggest to create backups from time to time. > But I found it unreliable, with the result that the DB could lose ALL of its indexes without reporting an error. Hm, that's weird, so far I didn't hear about indexes disappearing. If anybody also got this problem please tell us! Regards, Thomas On Fri, Jul 19, 2013 at 2:40 PM, Bill Torcaso <[email protected]> wrote: > Hello all, > > I am Bill Torcaso and I have been lurking here for a few months. And > right up front, I want to say that H2 is well-supported and good for small > to medium data set sizes. > > We use H2 to hold very large amounts of data - 20GB up to 80GB. And I > have seen a problem, multiple times, but not investigated enough to get a > repeatable case. > > I inherited a legacy Java application with H2 embedded in it. In its > prime, the largest DB was much, much smaller. At a guess, DB's were > perhaps up to 1GB. > > The DB has about 5 tables, and the schema is very straightforward. It is > in effect read-only once created; users will only query, not update. I > receive the DB with minimal indexes, and as a result, many queries do a > full table-scan. I decided to add LOTS of indexes. > > I won't take you through all the steps. But I found it unreliable, with > the result that the DB could lose ALL of its indexes without reporting an > error. > > I suggest that you do some stress tests with an oversized DB for your > application. > > (And no, I can't be more specific at this time; creating 20 indexes on 44 > million rows takes a long time to execute, let alone troubleshoot. But I > send my thanks to all the H2 developers for their work ....) > > On Thursday, July 18, 2013 4:00:45 AM UTC-4, JList wrote: >> >> Hi all, >> >> I've been using H2 in production on a small server without any problems. >> I'm thinking about using it again in another application. I did a search in >> the mailing list for database corruption. It looks there there have been >> some reports of data corruptions, some of which were followed by fixes. I >> guess some H2 versions might be more reliable then others because they have >> been better tested and with relatively speaking lower risk changes. I >> wonder if there are any versions that are considered more reliable and more >> suited for production use? >> >> Thanks, >> Jack >> > -- > 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.
