Hi Thomas,
Thanx for your initial reply. We would really like to get to the bottom of
this and find out what's wrong.
I still have two questions:
1. Is there any way to know for sure a database is consistent? Eg. By
running Recover with -trace and -transactionLog? Will this check all
internal indexes etc? It is important for us to be able to identify whether
a database was corrupted in some way (note that that is different from
knowing that there is no corruption left after an export (using Recover)
and an import into a new DB).
2. We have a (new) corrupted database from a machine that isn't
suffering from unexpected reboots (no critical errors according to the
Windows logs) and didn't experience an out-of-memory (that we know of)...
and we are looking at external factors: eg. Maybe the shadow copy (Windows
Restore Checkpoint) has interfered somehow with the DB, or maybe Windows
Restore has restored a corrupted snapshot, etc etc ... If you have any
ideas that we might want to check out, they are very welcome. It is a
customer with multiple computers, and this particular computer has had a
corrupted database 4 times in about two months. One of his other computers
had a corruption once, all other computers haven't had corruptions while
they are used by the same staff randomly. The DB is 8 GB in size.
Kind regards,
Rob.
Op zaterdag 27 juni 2015 13:30:34 UTC+2 schreef Thomas Mueller:
>
> Hi,
>
> I'm sorry that the risk of corruption is that big. I'm not sure what the
> problem could be. In the past, people did report corruptions now and then,
> but not at such a high rate as you have.
>
> I would not move to the MVStore yet, as there are known problem in case of
> power failure (in case of re-ordered writes). I'm working on that right
> now. There is also a known problem with corruption after out-of-memory,
> which is fixed in the trunk but not released yet.
>
> What I would probably use the old storage format ("mv_store=false" in the
> database URL). Whether you use the very latest 1.4.x version or 1.3.176
> will probably not make a big difference.
>
> I would consider creating online backups regularly, but I'm not sure if
> that's feasible in your case.
>
> Regards,
> Thomas
>
>
>
> On Friday, June 26, 2015, Rob Van Dyck <[email protected] <javascript:>>
> wrote:
>
>> Hi,
>>
>> I work for a small company using (the latest stable) H2 in our software.
>> Our client base is starting to grow (+-100 installations on client
>> computers, most have DB's multiple GBs in size) and we are starting to run
>> into more problems with broken (and sometimes worse: unrepairable) H2 DBs.
>> Our clients use lots of different OSes (all Windows/Mac OS X) on normal
>> commodity hardware. To give you an estimate about the failure rate: we have
>> had about 10 broken DBs in the last 6 months.
>>
>> We currently use an embedded persistent database with default connection
>> properties: "jdbc:h2:file:" + h2Path + ";IFEXISTS=TRUE" after which we set
>> autocommit to false. There is only one thread connected with the DB and the
>> database was created using the latest version stable H2 version.
>>
>> We know for sure a few instances happened a limited time after our
>> software ran into an out-of-memory situation. We also suspect some happened
>> after an OS-level crash which caused the computer to reboot without having
>> a chance to shutdown properly (e.g., power failure or the user pressing the
>> reset button).
>>
>> The data is privacy sensitive, so we are reluctant to provide it to you
>> unless that is the only option.
>>
>> We were hoping you might be able to hint us a little bit on what we might
>> do to avoid these issues?
>>
>> 1. We are converting our embedded persistent H2 DB to a (tcp)server
>> started by a different process. Hoping that OOMs in our software won't make
>> H2 corrupt since the H2 process can shutdown cleanly. Do you think this
>> might help for OOMs?
>> 2. We are wondering whether we are missing certain properties to set on
>> the connection? We looked at UNDO_LOG and LOG, but the default settings are
>> already the 'safest'.
>> 3. We are using the latest stable version 1.3.176 (and use the default of
>> its 'storage engines' called B-tree (?). I.e., we don't use MVStore).
>> Should we consider moving to the beta version? Could that possibly have
>> more protection against these types of failure?
>> 4. We know some instances of corruption happened in a virtualized
>> environment (where the guest OS 'crashed'). We tried to reproduce this by
>> running a Windows 8 guest on a Linux host, where we tried to reset and
>> shutdown our application multiple times (10) while it was performing heavy
>> database updates. We could not reproduce the issue.
>> 5. One of the issues is that we cannot reliably detect issues. At one
>> time we ran the H2 recovery tool which gave us no errors so we continued
>> using the existing DB, but immediately afterwards this resulted in H2
>> complaining about corruption. Is this possible (does the recovery tool
>> check all kind of errors? Or does it skip, e.g., index pages)? Is there a
>> way to know for sure that there is no corruption?
>> 6. We have tried on some occasions to run the recovery tool and re-import
>> the corrupted database, but at least on one occasion this gave us errors so
>> we were unable to restore the data. Unfortunately we do not have the error
>> output anymore.
>> 7. The next time this happens, is there anything that we should check
>> (e.g., the trace file)?
>>
>> I'll include some of the stacktraces, maybe this can give you an
>> indication of what might have gone wrong.
>>
>> Thanx for your answers and/or tips.
>>
>> Kind regards,
>> Rob.
>>
>> --
>> 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/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 [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/d/optout.
