Again: File ID mismatch
Luis Neves
I'm using a recent version of H2 (1.0.66 or 1.0.67) and I'm getting
this error again, which I thought was fixed:
File ID mismatch got=1819240287 expected=21 pos=163226 true
org.h2.store.DiskFile:/persistent/cff997169b1fa385fcf428d9a4e36825.data.db
blockCount:1795832418 java.lang.Error: File ID mismatch got=1819240287
expected=21 pos=163226 true
org.h2.store.DiskFile:/persistent/cff997169b1fa385fcf428d9a4e36825.data.db
blockCount:1795832418 at
org.h2.message.Message.getInternalError(Message.java:126) at
org.h2.store.DiskFile.getRecord(DiskFile.java:504) at
org.h2.store.Storage.getRecord(Storage.java:65)
I have the db files online if someone wants to look at it:
<http://netservices.sapo.pt/debug/h2_snafu.zip>
Thanks!
--
Luis Neves
www.ePortfel.com
Something bad is in H2. Few users of my desktop app get similar
errors:
> File ID mismatch got=1819240287 expected=21 pos=163226 true
Unfortunately I am not able to reproduce it, even being an active user
of this app.
But I am sure there has to be problem in H2. This causes H2 is not
ready for production purposes.
What can we do to solve the problem?
Thomas Mueller
Yes you are using version 1.0.67. I also thought the problem is fixed.
There are a few 'connection not closed' stack traces in the .trace.db
file, it looks like you didn't close the connection but let the
garbage collector close it. This shouldn't be a problem however.
The problem is, the file allocation table say a record belongs to the
table id 21, but the record is in fact empty. You can open the
database by appending ;RECOVER=1 to the database URL. No data is lost.
The question remains, why is there a bug the file allocation table. I
will try to find out by using a similar table structure than you did:
two table, one large varchar column (this column is 40 KB on average
per row).
I have a few more questions:
- Did you use multiple connections?
- Is the application multi-threaded?
- Do you use any settings or special features (for example, the
setting LOG=0, or two phase commit, linked tables, cache settings)?
(it doesn't look like, but just to make sure)
- On what operating system, file system, and virtual machine (java -version)?
- Is the database usually closed normally, or is process terminated
forcefully or the computer switched off?
- Is it possible to reproduce this problem using a fresh database
(sometimes, or always)?
Thanks a lot for your help!
Thomas
Thomas Mueller
To eportfel: Corruption problems have top priority for me. I have a
few question:
- Could you send the full stack trace of the exception?
- What is your database URL?
- What version H2 are you using?
- Did you use multiple connections?
- The first workarounds is: append ;RECOVER=1 to the database URL.
Does it work when you do this?
- The second workarounds is: delete the index.db file (it is
re-created automatically) and try again. Does it work when you do
this?
- The third workarounds is: use the tool org.h2.tools.Recover to
create the SQL script file, and then re-create the database using this
script. Does it work when you do this?
- Do you use any settings or special features (for example, the
setting LOG=0, or two phase commit, linked tables, cache settings)?
- Is the application multi-threaded?
- On what operating system, file system, and virtual machine (java -version)?
- How big is the database?
- Is the database usually closed normally, or is process terminated
forcefully or the computer switched off?
- Is it possible to reproduce this problem using a fresh database
(sometimes, or always)?
- Are there any other exceptions (maybe in the .trace.db file)? Could
you send them to me please?
- Was the database originally created with an older version of H2?
- Do you still have any .trace.db files, and if yes could you send them?
Regards,
Thomas
Luis Neves
"Thomas Mueller" <thomas.to...@gmail.com> wrote:
> The problem is, the file allocation table say a record belongs to the
> table id 21, but the record is in fact empty. You can open the
> database by appending ;RECOVER=1 to the database URL. No data is lost.
> The question remains, why is there a bug the file allocation table. I
> will try to find out by using a similar table structure than you did:
> two table, one large varchar column (this column is 40 KB on average
> per row).
>
> I have a few more questions:
> - Did you use multiple connections?
No, I use only one connection.
> - Is the application multi-threaded?
Yes.
> - Do you use any settings or special features (for example, the
> setting LOG=0, or two phase commit, linked tables, cache settings)?
> (it doesn't look like, but just to make sure)
These are the connection string parameters:
"LOG=0;MAX_MEMORY_UNDO=1000;MAX_MEMORY_ROWS=1000;WRITE_DELAY=500;CACHE_TYPE=TQ"
> - On what operating system, file system, and virtual machine (java
> -version)?
OS -> Linux version 2.6.18-5-686 (Debian 2.6.18.dfsg.1-13etch4)
FS -> ext3 (rw,errors=remount-ro)
JVM -> Sun JVM, version "1.6.0_04"
> - Is the database usually closed normally, or is process terminated
> forcefully or the computer switched off?
The database process is not forcefully terminated.
> - Is it possible to reproduce this problem using a fresh database
> (sometimes, or always)?
Sorry, I can't reproduce it.... but last time this happen the sequence
of events went something like this:
- select a large number of rows, which requires an external sort
- loop trough the resultset only to break the loop halfway due to an
application logic detail.
- immediately execute the previously select statement do have another
go at the data.
- *kaboom*
Thanks for your help.
--
Luis Neves
Luis Neves
I forgot to mention one important fact... while looping through the
resultset the rows are processed
by another thread and deleted after being successfully processed.
> - immediately execute the previously select statement do have another
> go at the data.
> - *kaboom*
--
Luis Neves
Thomas Mueller
"LOG=0;MAX_MEMORY_UNDO=1000;MAX_MEMORY_ROWS=1000;WRITE_DELAY=500;CACHE_TYPE=TQ"
The documentation for LOG 0 is:
" Logging can be disabled to improve the performance when durability
is not important, for example while running tests or when loading the
database. Warning: It may not be possible to recover the database if
logging is disabled and the application terminates abnormally. If
logging of index changes is enabled, opening a database that was
crashed becomes faster because the indexes don't need to be rebuilt. "
I suggest not to use LOG=0.
You wrote "The database process is not forcefully terminated.";
however the application didn't always close the connection, so I'm not
sure...
I will still try to reproduce this problem.
Is CACHE_TYPE=TQ faster than the default cache setting for you?
Regards,
Thomas
www.ePortfel.com
I cannot now diagnose such error because have no user that called me
lately about this. But it happens from time to time. The biggest
problem is I cannot reproduce it nor even get database files as my app
is personal finance manager and usually users do not want to send me
their financial data.
> - Could you send the full stack trace of the exception?
http://www.eportfel.com/?q=node/91#comment-151
where user has put two stacktraces - second of them is about our
problem. Got it on Vista system (begins with b/ out_vista.log).
> - What is your database URL?
to application dir "C:/Program Files/ePortfel/db/db".
> - What version H2 are you using?
For now I use 1.0.61 - but has no reports of this error lately. Now I
get infos that there are errors in AES encrypted databases - users
claim the dbs do not open anymore claiming the password is wrong (when
it is correct for sure).
I found on the forum that there is bug about it and wait for upgrade
(you know this is critically important for me - in fact I am losing
users because of it).
By the way - about errors with encrypted db - last user said he has no
*.corrupted files in db directory so it can be something different
that the bug that was raised on forum here? Should I ask the user for
more info and try to get db data from him? Can we do something about
it?
> - Did you use multiple connections?
it opens and closes multiple connections (saw in logs) - but I do not
know if there exist any connections silmutaneously.
Lately I included DBCP pooler.
> - The first workarounds is: append ;RECOVER=1 to the database URL.
> Does it work when you do this?
> - The second workarounds is: delete the index.db file (it is
> re-created automatically) and try again. Does it work when you do
> this?
> - The third workarounds is: use the tool org.h2.tools.Recover to
> create the SQL script file, and then re-create the database using this
> script. Does it work when you do this?
complete? I don't remember now, but I had problems.
> - Do you use any settings or special features (for example, the
> setting LOG=0, or two phase commit, linked tables, cache settings)?
This is JPOX config:
props.setProperty("org.jpox.cache.collections","true");
props.setProperty("org.jpox.cache.collections.lazy","false");
props.setProperty("org.jpox.connectionPoolingType","DBCP");
props.setProperty("org.jpox.rdbms.stringDefaultLength","255");
and some props like autocreation of schema or schema validation,
nothing special.
> - Is the application multi-threaded?
more but no one of them uses database. All database calls are in GUI
thread.
> - On what operating system, file system, and virtual machine (java -version)?
> - How big is the database?
you saw is about newly installed version - on such the db can be 1MB
or something.
> - Is the database usually closed normally, or is process terminated
> forcefully or the computer switched off?
maybe this should be the tip.
> - Is it possible to reproduce this problem using a fresh database
> (sometimes, or always)?
> - Are there any other exceptions (maybe in the .trace.db file)? Could
> you send them to me please?
> - Was the database originally created with an older version of H2?
the db files created by itself.
Luis Neves
On Sat, 8 Mar 2008 11:49:02 +0100
"Thomas Mueller" <thomas.to...@gmail.com> wrote:
>
> Hi,
>
> "LOG=0;MAX_MEMORY_UNDO=1000;MAX_MEMORY_ROWS=1000;WRITE_DELAY=500;CACHE_TYPE=TQ"
>
> The documentation for LOG 0 is:
>
> " Logging can be disabled to improve the performance when durability
> is not important, for example while running tests or when loading the
> database. Warning: It may not be possible to recover the database if
> logging is disabled and the application terminates abnormally. If
> logging of index changes is enabled, opening a database that was
> crashed becomes faster because the indexes don't need to be rebuilt. "
>
> I suggest not to use LOG=0.
Ok, I will change it.
> You wrote "The database process is not forcefully terminated.";
> however the application didn't always close the connection, so I'm not
> sure...
What I meant was that I didn't "kill -9" the process, however we use
"supervise" (from daemontools) for service control and monitoring and
"supervise" restarts services by sending then a TERM signal... but as
far as I can see, all shutdown hooks run and it all ends smoothly.
> I will still try to reproduce this problem.
>
> Is CACHE_TYPE=TQ faster than the default cache setting for you?
It's not faster but it seems to be more consistent and It gives me fewer issues.
Thanks!
--
Luis Neves
krtonozka
i got the same problem. I'll try to also answer your questions:
> - Could you send the full stack trace of the exception?
java.lang.Error: File ID mismatch got=-1923380067 expected=25
pos=176704 true org.h2.store.DiskFile:N:\tmc\dvp\archive\client\mnt\rds
\archive\storage\znr12@MIGRAT0\2008-03-13\2008-03-13.data.db
blockCount:627293977; SQL statement:
CREATE PRIMARY KEY ON PUBLIC.COMMON(TYPEID, TS) [50000-67]
at org.h2.message.Message.getSQLException(Message.java:89)
at org.h2.message.Message.convert(Message.java:174)
at org.h2.engine.MetaRecord.execute(MetaRecord.java:73)
at org.h2.engine.Database.open(Database.java:539)
at org.h2.engine.Database.<init>(Database.java:197)
at org.h2.engine.Engine.openSession(Engine.java:52)
at org.h2.engine.Engine.getSession(Engine.java:100)
at org.h2.engine.Session.createSession(Session.java:182)
at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:965)
at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:946)
at org.h2.Driver.connect(Driver.java:52)
at java.sql.DriverManager.getConnection(DriverManager.java:525)
at java.sql.DriverManager.getConnection(DriverManager.java:193)
at
com.sitraffic.archive.kernel.storage.jdbc.StorageJDBC.getConnection(StorageJDBC.java:
921)
at
com.sitraffic.archive.kernel.storage.jdbc.StorageJDBC.setConnection(StorageJDBC.java:
747)
> - What is your database URL?
\znr12@MIGRAT0\2008-03-13\2008-03-13;IFEXISTS=TRUE;TRACE_LEVEL_FILE=0;TRACE_LEVEL_SYSTEM_OUT=0;CACHE_SIZE=1024
> - What version H2 are you using?
> - Did you use multiple connections?
> - The first workarounds is: append ;RECOVER=1 to the database URL.
> Does it work when you do this?
03-13 13:44:16 database: opening N:\tmc\dvp\archive\client\mnt\rds
\archive\storage\znr12@MIGRAT0\2008-03-13\2008-03-13 (build 67)
03-13 13:44:16 fileLock: save {method=file,
id=118a82b5c4df5ba8c0e46cb2840405909b66335697d}
03-13 13:44:16 fileLock: load {method=file,
id=118a82b5c4df5ba8c0e46cb2840405909b66335697d}
03-13 13:44:16 database: opening N:\tmc\dvp\archive\client\mnt\rds
\archive\storage\znr12@MIGRAT0\2008-03-13\2008-03-13
java.lang.Error: unexpected code path
at org.h2.message.Message.getInternalError(Message.java:126)
at org.h2.message.Message.getInternalError(Message.java:186)
at org.h2.store.DiskFile.init(DiskFile.java:356)
at org.h2.engine.Database.open(Database.java:458)
at org.h2.engine.Database.<init>(Database.java:197)
at org.h2.engine.Engine.openSession(Engine.java:52)
at org.h2.engine.Engine.getSession(Engine.java:100)
at org.h2.engine.Session.createSession(Session.java:182)
at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:965)
at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:946)
at org.h2.Driver.connect(Driver.java:52)
at java.sql.DriverManager.getConnection(DriverManager.java:525)
at java.sql.DriverManager.getConnection(DriverManager.java:193)
at
com.sitraffic.archive.kernel.storage.jdbc.StorageJDBC.getConnection(StorageJDBC.java:
921)
at
com.sitraffic.archive.kernel.storage.jdbc.StorageJDBC.setConnection(StorageJDBC.java:
747)
at
com.sitraffic.archive.kernel.storage.jdbc.StorageJDBC.load(StorageJDBC.java:
1073)
at
com.sitraffic.archive.kernel.impl.StorageAccessImpl.retrieve(StorageAccessImpl.java:
181)
at
com.sitraffic.archive.kernel.impl.StorageAccessImpl.retrieve(StorageAccessImpl.java:
190)
at com.sitraffic.archive.databundle.helper.CollectorArchiver
$1.run(CollectorArchiver.java:72)
at com.sitraffic.util.PriorizedExecutor
$RunnerThread.execute(PriorizedExecutor.java:86)
at com.sitraffic.util.PriorizedExecutor
$RunnerThread.run(PriorizedExecutor.java:65)
Or also on database created by version 1.0.50:
03-11 14:08:11 database: opening
N:\tmc\dvp\archive\client\mnt\rds\archive\storage
\znr15@MIGRAT0\2008-03-01\2008-03-01
java.lang.Error: double allocation in file
N:\tmc\dvp\archive\client\mnt\rds\archive\storage
\znr15@MIGRAT0\2008-03-01\2008-03-01.data.db
page 886 blocks 56704-56767
> - The second workarounds is: delete the index.db file (it is
> re-created automatically) and try again. Does it work when you do
> this?
index.db was created.
> - The third workarounds is: use the tool org.h2.tools.Recover to
> create the SQL script file, and then re-create the database using this
> script. Does it work when you do this?
INSERT INTO O_369 VALUES(3, 1205370000000,
X'00000088404d494752415430000ca70800000118a5a692800000008473710c71740af573f1715530d4336170f0f5740f720c3160e059cec1c0c028b174d9a40646106371f7af290c0c0c4c8c0c8b0c1882037c424219185880320c0e4c0cdbc2b78583984e4c0d290d298c20a60b42d48da9e1070881c53d1a1a1b1a4018c806f1191872ef320000');
-- ERROR:blockCount=418332359 block:0 blockCount:418332359
storageId:-1 recordLength: -1 valueId:-1
-- dump: ??>???}?W??????q????x?9~??s????>??"=?V+?????WP??q????6?P?W+|?
{?7???J??????r???z??P"W+ ??q"??x??(?k.?:??5J??;b??(?k??5??$J??ep???
-- dump: 18 ef 3e c7 f7 c7 7d 8e 57 12 e3 dd e7 f8 8f 71 9f e3 15 c5
78 f7 39 7e 01 ee 73 bc b2 18 ef 3e c7 1f 22 3d 08 56 2b 8c ab 15 bd
d5 57 50 1a a5 71 b5 b2 b7 ba 36 8d 50 1c 57 2b 7c ab 7b f3 37 94 c7
d5 4a df ea 0f f8 02 05 72 b5 e2 b7 7a 0e cb 50 22 57 2b 7f ab f7 71
22 08 d6 78 14 d7 28 80 6b 2e e1 3a 94 c9 35 4a e0 1a 3b 62 cd 83 28
94 6b 14 c1 35 8f f3 24 4a e5 1a 65 70 cd df f9
-- ERROR:blockCount<0 block:0 blockCount:-1409524763 storageId:-1
recordLength: -1 valueId:-1
-- dump: ??[??*?V????U???o? ??[??*?V????U???o? ??[??*?V?S?O??E???S?O??
E???S?O??E???S?O??E???S?O??E???S?O??U?T?S?O??U?T?S?O??U?T?S?O??U?T?
-- dump: ab fc 5b e5 df 2a ff 56 f9 b7 ca bf 55 fe ad f2 6f 95 7f ab
fc 5b e5 df 2a ff 56 f9 b7 ca bf 55 fe ad f2 6f 95 7f ab fc 5b e5 df
2a ff 56 f9 53 e4 4f 91 3f 45 fe 14 f9 53 e4 4f 91 3f 45 fe 14 f9 53
e4 4f 91 3f 45 fe 14 f9 53 e4 4f 91 3f 45 fe 14 f9 53 e4 4f 91 3f 45
fe 14 f9 53 e4 4f 95 3f 55 fe 54 f9 53 e5 4f 95 3f 55 fe 54 f9 53 e5
4f 95 3f 55 fe 54 f9 53 e5 4f 95 3f 55 fe 54 f9
-- block 35263 - 1407572307
> - Do you use any settings or special features (for example, the
> setting LOG=0, or two phase commit, linked tables, cache settings)?
> - Is the application multi-threaded?
accessing database at one time.
> - On what operating system, file system, and virtual machine (java -version)?
Filesystem: reiserfs
Java:
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05)
Java HotSpot(TM) Client VM (build 1.5.0_13-b05, mixed mode, sharing)
> - How big is the database?
> - Is the database usually closed normally, or is process terminated
> forcefully or the computer switched off?
outage (3 times). The last case i am not sure yet.
> - Is it possible to reproduce this problem using a fresh database
> (sometimes, or always)?
on version 1.0.50, onetime on 1.0.67
> - Are there any other exceptions (maybe in the .trace.db file)? Could
> you send them to me please?
> - Was the database originally created with an older version of H2?
> - Do you still have any .trace.db files, and if yes could you send them?
I put database corrupted by v1.0.50 on http://krtonozka23.savana.cz/created_by_v1.0.50.zip
The one created by 1.0.67 is a bigger one, i can provide it later if
wanted. It has the same structure.
Thomas Mueller
Thanks a lot for the information, but I am sorry that I can't help you at the moment. You wrote:
> Usually closed normally.
>The corruption happens most probably on power
> outage (3 times). The last case i am not sure yet.
> TRACE_LEVEL_FILE=0
To easier find the problems, it would be great if you use the default setting, that is TRACE_LEVEL_FILE=1
Like this unclosed connections and other exceptions are also logged.
Regards,
Thomas
Jeffrey Krzysztow
I have a table that gets corrupt and then I will start getting:
org.h2.jdbc.JdbcSQLException: General error: java.lang.Error: File ID mismatch got=0 expected=129 pos=825 true org.h2.store.DiskFile:C:\Millers Remote Studio Resources\java\database\RemoteStudio.data.db blockCount:0 [50000-68]
This does not seemed to happen until I've done:
DELETE FROM Thumbnail
It does not happen immediately, so I am having a hard time duplicating in "simple" steps, but it is possible to duplicate.
I have the DB with this issue all zipped up if you want it.
This seemed to start with the 08-02-22 version and is most definitely still there. If I can get the steps simplified, I will post that information as well.
Jeffrey
www.ePortfel.com
about the error. Unfortunately I cannot still get db files.
What I noticed however is that the problem seems to appear on Windows
Vista systems and once on Linux. I don't remember it on Windows XP. It
may be of course accidential but maybe we should check it. Did you
perform full testing on H2 on Vista machine?
krtonozka
i got some news there. We are getting the error now with 1.0.67
pernamently even during using one jdbc connection. Everytime it takes
different time to reproduce it, but after some time of using one jdbc
connection it is there suddenly.
I realised we are using one more setting not directly on the dtb URL,
which is SET MAX_LENGTH_INPLACE_LOB 65536. We use this, because of
storing large amount of bigger LOBs so we wanted to keep the dtb
compact in one file if possible. Without setting this parameter i was
not able to reproduce this error so far. Maybe this setting can cause
troubles.
I also got the traces when the error popups. Interesting thing is,
there is executed the set of SELECTs from one table and some of them
are executed succesfully, but two of them fails. There is no writing
to dtb logged between these SELECTs, see trace http://krtonozka23.savana.cz/short_trace.txt
The error occurs first time in 9:15:15. Another interesting thing is
that after set of these SELECTs the connection is closed somehow hard,
because when trying to INSERT there something, new connection is
opening. This can be caused by our application, but the File id
mismatch error occured just before.
I can provide more traces from the time before if needed, it is just
rather big with debug tracing.
Br,
Petr
On Mar 17, 8:03 pm, "Thomas Mueller" <thomas.tom.muel...@gmail.com>
wrote:
>
> Thanks a lot for the information, but I am sorry that I can't help you at
>
> the moment. You wrote:
> > Usually closed normally.
> >The corruption happens most probably on power
> > outage (3 times). The last case i am not sure yet.
>
> I think it would be quite important to know when the corruption happened
> with version 1.0.67. I know that using ReiserFS should solve power outage
> problems, but I have never tested it so far.
>
> > TRACE_LEVEL_FILE=0
>
> To easier find the problems, it would be great if you use the default
> setting, that is TRACE_LEVEL_FILE=1
> Like this unclosed connections and other exceptions are also logged.
>
> Regards,
> Thomas
>
Thomas Mueller
> Did you perform full testing on H2 on Vista machine?
No, I don't have Windows Vista. I don't think this is the problem, but
probably we should verify this is not the problem. Could you run the
unit tests on such a machine and post the result please? Use 'ant
test' to run the tests (so you need to install Java, and Ant).
Regards,
Thomas
Thomas Mueller
Could you send me the test application you have used? If not, I would
maybe create such a test application, but I would need the complete
.trace.db file that includes creating the database, tables, and so on.
Also great would be a SQL script file.
Thanks for your help!
Thomas
Petr Mikolas
sorry for delay. The complete trace is stored here:
http://krtonozka23.savana.cz/2008-03-21.trace.zip It is quite big,
cause of big lobs stored.
Where i want to point is:
03-21 17:47:39 database: closing /mnt/rds/archive/storage/
znr12@MIGRAT0/2008-03-21/2008-03-21 from shutdown hook
03-21 17:47:39 session: disconnecting #2
03-21 17:47:39 database: closing /mnt/rds/archive/storage/
znr12@MIGRAT0/2008-03-21/2008-03-21
03-21 17:47:39 database: closed
03-21 17:47:39 session: disconnected #2
03-21 17:47:39 database: closing /mnt/rds/archive/storage/
znr12@MIGRAT0/2008-03-21/2008-03-21
03-21 17:47:39 database: closed
What does it mean closing from shutdown hook? The error happens after
a few SELECTs after such closing. I am not sure if we closed the JDBC
connection intentionaly in this case or we somehow terminated it hard
way. Anyway i think H2 should handle such situation or? I'll try to
find out what causes this close, but it will take some time probably.
Br,
Petr
On Mar 20, 8:00 pm, "Thomas Mueller" <thomas.tom.muel...@gmail.com>
wrote:
> Hi,
>
> maybe create such a test application, but I would need the complete
> .trace.db file that includes creating the database, tables, and so on.
> Also great would be a SQL script file.
>
> Thanks for your help!
>
> Thomas
>
>
> > Hi again,
>
> > i got some news there. We are getting the error now with 1.0.67
> > pernamently even during using one jdbc connection. Everytime it takes
> > different time to reproduce it, but after some time of using one jdbc
> > connection it is there suddenly.
>
> > I realised we are using one more setting not directly on the dtb URL,
> > which is SET MAX_LENGTH_INPLACE_LOB 65536. We use this, because of
> > storing large amount of bigger LOBs so we wanted to keep the dtb
> > compact in one file if possible. Without setting this parameter i was
> > not able to reproduce this error so far. Maybe this setting can cause
> > troubles.
>
> > I also got the traces when the error popups. Interesting thing is,
> > there is executed the set of SELECTs from one table and some of them
> > are executed succesfully, but two of them fails. There is no writing
>
> read more »
Petr Mikolas
i have simplified the error replication. Can you check the application
bellow if you can also reproduce the error?
1. get application here: http://krtonozka23.savana.cz/mismatch_error.zip
2. unpack and execute: java -jar executeh2script.jar
3. it will copy the prepared database from basedb into dbtest
directory and execute the crashScript.txt upon it.
4. connect to created dbtest database with h2 console and execute:
SELECT Data FROM FD_12_5001 WHERE TypeId=4 ORDER BY Ts DESC;
5. you should got something like: General error: java.lang.Error: File
ID mismatch got=1707400262 expected=41 pos=57219 true
org.h2.store.DiskFile:E:\WiMax\projects\Java\ExecuteH2Script\dbtest
\dbtest.data.db blockCount:-755423910 [50000-67] (Help)
I was not able to shorten the SQL script, seems whole set of SQL
commands is needed to error occurence. Strange thing is the SELECT
command from step 4 is executed at the end of script succesfully, but
fails after closing and opening in h2console.
The application source project for Eclipse is stored in "source"
directory within the zip file.
BR,
Petr
> sorry for delay. The complete trace is stored here:http://krtonozka23.savana.cz/2008-03-21.trace.zipIt is quite big,
>
> read more »
Petr Mikolas
last time. Execution takes about 5 minutes.
On Apr 6, 10:23 pm, Petr Mikolas <krtono...@gmail.com> wrote:
> Hi Thomas,
>
> i have simplified the error replication. Can you check the application
> bellow if you can also reproduce the error?
>
> 1. get application here:http://krtonozka23.savana.cz/mismatch_error.zip
> 2. unpack and execute: java -jar executeh2script.jar
> 3. it will copy the prepared database from basedb into dbtest
> directory and execute the crashScript.txt upon it.
> 4. connect to created dbtest database with h2 console and execute:
> SELECT Data FROM FD_12_5001 WHERE TypeId=4 ORDER BY Ts DESC;
> 5. you should got something like: General error: java.lang.Error: File
> ID mismatch got=1707400262 expected=41 pos=57219 true
> org.h2.store.DiskFile:E:\WiMax\projects\Java\ExecuteH2Script\dbtest
> \dbtest.data.db blockCount:-755423910 [50000-67] (Help)
>
> I was not able to shorten the SQL script, seems whole set of SQL
> commands is needed to error occurence. Strange thing is the SELECT
> command from step 4 is executed at the end of script succesfully, but
> fails after closing and opening in h2console.
>
> The application source project for Eclipse is stored in "source"
> directory within the zip file.
>
> BR,
> Petr
>
> On Mar 30, 10:15 pm, Petr Mikolas <krtono...@gmail.com> wrote:
>
> > Hi,
>
>
> read more »
Thomas Mueller
Thanks for your help! I will try to reproduce this problem. I have a
question: did you already try with version 1.0.69?
Regards,
Thomas
Petr Mikolas
just tried it with version 1.0.69 and the problem persists.
Br,
Petr
On Apr 6, 10:38 pm, "Thomas Mueller" <thomas.tom.muel...@gmail.com>
wrote:
> Hi,
>
> question: did you already try with version 1.0.69?
>
> Regards,
> Thomas
>
>
> read more »
Thomas Mueller
I am sorry, it seems the base database is already corrupted. I have
run the following statement:
script to 'test.sql' and the result was an exception. Did you try
using the recovery tool?
Regards,
Thomas
Petr Mikolas
Ok. I have found the place of first occurence hopefully. Please get
the new basedb and script here: http://krtonozka23.savana.cz/mismatch.zip
Run java -jar executescript.jar and it should fail on the last
statement. The resulting dtb is stored into dbtest dir. Or just
execute crashScript.txt on basedb database in the console.
I hope it will be reproducible for you.
Br,
Petr
On Apr 8, 7:50 pm, "Thomas Mueller" <thomas.tom.muel...@gmail.com>
wrote:
> Hi,
>
> run the following statement:
> script to 'test.sql' and the result was an exception. Did you try
> using the recovery tool?
>
> Regards,
> Thomas
>
>
> read more »
tsukasa
again.. Later this day I will go there and get a copy of all his
database backups. Hopefully helps for something, altough I don't have
sql logs.
>
> leer más »- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -
Thomas Mueller
Thanks a lot for your test case! Too bad I made a release yesterday...
I can reproduce the problem now: empty space is re-used too early if
large records (8 KB or larger) are updated or deleted, when not using
BLOBs or CLOBs, or when using many columns. I made my own test case
that inserts and deletes very large records.
A workaround is to use CLOB / BLOB, another workaround is to set the
system property 'h2.reuseSpaceQuickly' to 'false' before loading the
H2 driver (System.setProperty("h2.reuseSpaceQuickly", "false");
I will fix this problem and release a new version earlier than usual
(maybe at the end of this week).
Regards,
Thomas
Petr Mikolas
thanks for support. Workaround with the forbidden quick reuse is
working fine in my tests. I will give it try on our real system also.
Br,
Petr
On Apr 21, 8:56 pm, "Thomas Mueller" <thomas.tom.muel...@gmail.com>
wrote:
> Hi,
>
>
> I can reproduce the problem now: empty space is re-used too early if
> large records (8 KB or larger) are updated or deleted, when not using
> BLOBs or CLOBs, or when using many columns. I made my own test case
> that inserts and deletes very large records.
>
> A workaround is to use CLOB / BLOB, another workaround is to set the
> system property 'h2.reuseSpaceQuickly' to 'false' before loading the
> H2 driver (System.setProperty("h2.reuseSpaceQuickly", "false");
>
> I will fix this problem and release a new version earlier than usual
> (maybe at the end of this week).
>
> Regards,
> Thomas
>
>
> read more »
tsukasa
setting that property as a workaround, h2.reuseSpaceQuickly, works
since which H2 version? 1.0.63 included? I ask because maybe I will
keep using that version, as I don't use mvcc and use only one
connection per database, and this is the only serious problem I have
seen so far. Thanks.
On 21 abr, 14:56, "Thomas Mueller" <thomas.tom.muel...@gmail.com>
wrote:
> Hi,
>
Thomas Mueller
> setting that property as a workaround, h2.reuseSpaceQuickly, works
> since which H2 version? 1.0.63 included?
No, it is supported since version 1.0.68 (2008-03-18).
I will release a new version later this week (probably on Friday)
where this problem is fixed.
Regards,
Thomas
Joel Turkel
We're seeing this problem but upgrading from 1.0.69 to 1.0.71 isn't
currently feasible since we have local H2 modifications and are going
into production soon. We'd like to just apply the changes required for
this bug fix... do you have a listing of the revision/files fixed this
bug?
Thanks,
Joel
On Apr 21, 2:56 pm, "Thomas Mueller" <thomas.tom.muel...@gmail.com>
wrote:
> Hi,
>
>
> I can reproduce the problem now: empty space is re-used too early if
> large records (8 KB or larger) are updated or deleted, when not using
> BLOBs or CLOBs, or when using many columns. I made my own test case
> that inserts and deletes very large records.
>
> A workaround is to use CLOB / BLOB, another workaround is to set the
> system property 'h2.reuseSpaceQuickly' to 'false' before loading the
> H2 driver (System.setProperty("h2.reuseSpaceQuickly", "false");
>
> I will fix this problem and release a new version earlier than usual
> (maybe at the end of this week).
>
> Regards,
> Thomas
>
>
> read more »
Thomas Mueller
> We're seeing this problem but upgrading from 1.0.69 to 1.0.71 isn't
> currently feasible since we have local H2 modifications and are going
> into production soon. We'd like to just apply the changes required for
> this bug fix... do you have a listing of the revision/files fixed this
> bug?
Sorry, I'm afraid doing a 'bugfix only' release will be very hard or
impossible. The problem is that I work a lot without internet
connection, and therefore can't commit the changes with meaningful
comments. Also, there have been other bug fixed which may or may not
be related (I don't remember fully). I think it makes more sense to
integrate your changes to the newest version.
> we have local H2 modifications and are going
> into production soon.
According to the license of H2, you need to publish the source code of
those changes if you want to distribute your product. See also the
License FAQ at http://www.h2database.com/html/license.html
* You can use H2 for free. You can integrate it into your
application (including commercial applications), and you can
distribute it.
* Files containing only your code are not covered by this license
(it is 'commercial friendly').
* Modifications to the H2 source code must be published.
* You don't need to provide the source code of H2 if you did not
modify anything.
Even if you don't plan to distribute your product, I think it is in
your interest to publish your changes (sending them to me is enough),
so that I can integrate them. This will also reduce the work you have
when upgrading to a new version.
Regards,
Thomas