Hi Thomas, thanks for your quick reply. I'll try to answer your questions as well as I can in comments below.
On Jul 5, 7:43 pm, Thomas Mueller <[email protected]> wrote: > Possibly the database was corrupt before, but this was not detected. > What version of H2 was used before? Did you migrate the database using > SCRIPT TO / RUNSCRIPT FROM or did you just use a new version of the > h2*.jar file? I exported the database using the old h2 jar and imported it using the new h2 jar. This is an automated process that I have tested thoroughly and that seems to work well. > What is the complete error message, including error codes and all stack > traces? See end of this mail. > > - What can be the best and what the worst result one can hope for when > > attempting recovery? > > The best result is that no data is lost (if only an index is corrupt). > The worst result is that some of the data is lost. Does the Recovery tool report whether it was able to restore all data? Or to what degree data was restored? I'm interested in building automatic recovery into the application and as this needs to be fully automatic I would need to know, how well things went. > I am very interested in analyzing and solving this problem. Corruption > problems have top priority for me. I have a few questions: > > - How many connections does your application use concurrently? It uses a C3P0 connection pool with a max of 5 connections (the pool in turn is used by Hibernate). The app may use that many connections, though it is more likely, it uses less. > - Do you use temporary tables? No. At least I don't explicitly create them myself. > - Did you use LOG=0 or LOG=1? The connection string I use is jdbc:h2:C:\Users\xxx \somefile;TRACE_LEVEL_FILE=1;TRACE_LEVEL_SYSTEM_OUT=1;LOCK_TIMEOUT=10000;CACHE_SIZE=16384 I guess LOG has the default value, whatever that is. > - 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. I don't have access to user databases. This makes these things hard to check. But, if the database was created from a SQL script using H2 1.3.155, I would assume that is also the database version that created the database. > - Did the application run out of memory (once, or multiple times)? Possible, but I couldn't find any evidence of it (for this particular case), which I usually do, if that's the case. > - Do you use any settings or special features (for example cache settings, > two phase commit, linked tables)? Please see the above mentioned connection string. > - Do you use any H2-specific system properties? Please see the above mentioned connection string. > - Is the application multi-threaded? Yes. > - What operating system, file system, and virtual machine > (java -version) do you use? The app runs on both Windows and OS X. This particular case happened on Win 7 with Java 1.6.0_25 (32 bit). But I have also seen this on OS X 10.6.8 with Java 1.6.0_26 (64bit). The app always runs on Java 6 in server mode. > - How did you start the Java process (java -Xmx... and so on)? My Windows settings are: -server -Xms${vm.memory.heap.min} -Xmx${vm.memory.heap.max} -Xloggc:gc.log -XX:+PrintGCDetails -XX:MaxPermSize=${vm.memory.perm.max} -XX:MaxDirectMemorySize=${vm.memory.direct.max} -Djava.net.useSystemProxies=true -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true OS X settings are very similar ms, mx MaxPerm and MaxDirect are all set to a couple of hundred megs. How many exactly depends on the number of processors. > - Is it (or was it at some point) a networked file system? This users stores his DB locally. > - How big is the database (file sizes)? At this point I can't say this anymore, as the user already deleted the database to get the app to run again. > - How much heap memory does the Java process have? Probably around 700M. > - Is the database usually closed normally, or is process terminated > forcefully or the computer switched off? At regular shutdown, the SQL shutdown command is issued. When the app crashes, that obviously does not happen. > - Is it possible to reproduce this problem using a fresh database > (sometimes, or always)? I haven't been able to. > - Are there any other exceptions (maybe in the .trace.db file)? > Could you send them please? I don't have access to this file anymore, but I'll will send you some other logs. > - Do you still have any .trace.db files, and if yes could you send them? Sorry, no. > - Could you send the .h2.db file where this exception occurs? Sorry, no. I put together a zip file with anonymized user logs: http://www.beatunes.com/download/h2databasecorruption.zip (please let me know, once you downloaded the file, so that I can remove it from the server again). There is a lot of crap in the logs, but I'm sure you can find the relevant bits by searching for "h2". App starts can be found by searching for "Copyright (c) 2006-2011 tagtraum industries incorporated" - there you can also find some basic info about the process in question (JVM, OS, etc.) The logs feature time in ms since app start, current thread name and logging class. At application shutdown there should be multiple "shutdown" messages. If there aren't any, the app most likely crashed. The next time a user reports this or another corruption issue, I will try to get the trace.db and the database file along with the logs. Nevertheless, I hope the logs in the zip package provide any useful information for you. Thank you! -hendrik -- 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.
