I agree with you. Running the Recover tool with the "-transactionLog" option gave me no evidences. Is there some particular section of the sql file I should examine?
Follows an excerpt from the recover output when ran on a database that had no problems on the 2nd import (no errors on the trace file and db size almost unchanged) but had problems on the 3rd one (namely errors on the trace file and db size increased). So, if the errors on the trace file and the db size increase/uncommitted transactions are related, is there something I could do to detect the cause (even debugging)? Thomas Mueller-6 wrote > Hi, > > Please note it's not the *size* of an uncommitted transaction that is a > problem. The problem is, once you have an uncommitted transaction (which > could mean there is only one row changed in the uncommitted transaction), > then the transaction log is not truncated starting from that point on. So > the *starting* time of the uncommitted transaction is the problem. > > To get more details about transactions, you could run the Recover tool > with > the "-transactionLog" option. This option is not yet documented, because I > thought it is not useful in general. But I will document it now. -- View this message in context: http://h2-database.66688.n3.nabble.com/h2-Continuous-Increase-in-H2-db-size-after-dropping-and-loading-same-data-repeatedly-tp4026836p4027193.html Sent from the H2 Database mailing list archive at Nabble.com. -- 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.
