Hi Thomas and list, 2015-07-03 Thomas Mueller <thomas.tom.muel...@gmail.com>:
>> Is there any way to know for sure a database is consistent? > > The statement "script to <fileName>" will detect most corruptions. It will > not detect corruptions in just the secondary indexes, but those are quite > rare. It appears it doesn't detect the error we see most when using this DB: 'Row not found when trying to delete from index "PUBLIC.""idx_Person_birthDate""'. Both Script and Recovery produce an SQL file without any error messages but some have strange file sizes. (original DB is 8 GB, the Script-generated SQL: 6 GB, the Recovery-generated with extra logging (-trace -transactionLog): 14 GB, the Recovery-generated without extra logging: 11.7 GB). The only problem arises when trying to import the SQL file: During the reimport (RunScript) of the Recovery-generated (without extra logging) one I got a 'java.io.IOException: Stream closed' [1] (somewhere while doing a rollback?). The strange thing was that the restored DB was already 12 GB, with extra temp.db's where one was more than 8 GB big. At that time I only had 3 GB of storage left on the particular machine (where I was testing the restore). But it seems to me that needing +20 GB to restore a 8 GB database would be rather strange. Do you know what might be the cause of the 'Stream closed' exception? [1] org.h2.jdbc.JdbcSQLException: IO Exception: "java.io.IOException: Stream Closed"; "C:/Users/[..]/AppData/LocalLow/[..]/temp/records-restored.66233827.7.temp.db" [90031-176] at org.h2.message.DbException.getJdbcSQLException(DbException.java:344) at org.h2.message.DbException.get(DbException.java:167) at org.h2.message.DbException.convertIOException(DbException.java:329) at org.h2.store.FileStore.setLength(FileStore.java:362) at org.h2.engine.UndoLog.getLast(UndoLog.java:96) at org.h2.engine.Session.rollbackTo(Session.java:594) at org.h2.command.Command.executeUpdate(Command.java:278) at org.h2.jdbc.JdbcStatement.executeInternal(JdbcStatement.java:186) at org.h2.jdbc.JdbcStatement.execute(JdbcStatement.java:160) at org.h2.tools.RunScript.process(RunScript.java:261) at org.h2.tools.RunScript.process(RunScript.java:191) at org.h2.tools.RunScript.process(RunScript.java:329) at org.h2.tools.RunScript.runTool(RunScript.java:142) at org.h2.tools.RunScript.main(RunScript.java:69) Caused by: java.io.IOException: Stream Closed at java.io.RandomAccessFile.length(Native Method) at org.h2.store.fs.FileDisk.truncate(FilePathDisk.java:422) at org.h2.store.FileStore.setLength(FileStore.java:357) ... 10 more >> We have a (new) corrupted database from a machine that isn't suffering >> from unexpected reboots > > Even thought my main priority is now to get the MVStore stable (which > hopefully will fully solve the corruption problem), I would still be > interested to understand why you have that many corruptions. My guess is > that your use case is slightly different than what others do. I have a list > of questions I have used before (you have answered some of those questions > already): > > - What is your database URL? We actually have two databases. Both have a separate thread which is the only one communicating with the DB. They each use a URL like this: "jdbc:h2:file:" + h2Path + ";IFEXISTS=TRUE" after which we set autocommit to false. > - Did you use LOG=0 or LOG=1? Did you read the FAQ about it? No, we use the default LOG=2. > - Did the system ever run out of disk space? Not that we know of. It currently has about 80 GB of 180 GB in use. I searched the Windows system log for 'quota' and 'space' didn't give any results. > - Could you send the full stack trace of the exception including message > text? This is included in the trace.db file right? > - Did you use SHUTDOWN DEFRAG or the database setting DEFRAG_ALWAYS with H2 > version 1.3.159 or older? No > - How many connections does your application use concurrently? One per DB. > - Do you use temporary tables? No. > - 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. 176. > - Did the application run out of memory (once, or multiple times)? That is possible, we have not noticed any out-of-memory errors in our logs, but we see our application stopped without logging at least 3 times. That could indicate our process was killed, or because of a JVM exit or something. > - Do you use any settings or special features (for example cache settings, > two phase commit, linked tables)? No. > - Do you use any H2-specific system properties? No. > - Is the application multi-threaded? Yes. > - What operating system, file system, and virtual machine > (java -version) do you use? Win7 Home Premium - SP1 (6.1 amd64), NTFS, Java: 1.7.0_79 64. > - How did you start the Java process (java -Xmx... and so on)? -Xmx800M -XX:MaxPermSize=128M -XX:-OmitStackTraceInFastThrow -Dsun.security.smartcardio.t0GetResponse=false > - Is it (or was it at some point) a networked file system? No. > - How big is the database (file sizes)? 8 GB. > - How much heap memory does the Java process have? 800 MB. > - Is the database usually closed normally, or is process terminated > forcefully or the computer switched off? This particular computer hasn't been powered off incorrectly. Our application has been terminated (without a clean JVM shutdown) 3 times according to our logs. > - Is it possible to reproduce this problem using a fresh database > (sometimes, or always)? No. > - Are there any other exceptions (maybe in the .trace.db file)? > Could you send them please? See next question. > - Do you still have any .trace.db files, and if yes could you send them? I will attach them. > - Could you send the .h2.db file where this exception occurs? This is hard because the data is confidential. Thanx for your time, 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 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/d/optout.
global-adjusted.trace.db
Description: Binary data
records-adjusted.trace.db
Description: Binary data
