Hi Thomas and list, 2015-07-03 Thomas Mueller <[email protected]>:
>> 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 [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.
global-adjusted.trace.db
Description: Binary data
records-adjusted.trace.db
Description: Binary data
