corrupted database

[fschmidt]

Below is an exception that I got. The database is 3 gig and I use
MVCC=TRUE. It is a very simple database with just one table used as
an HTTP cache. I have kept the database if you want to look into it.

Exception in thread "main" org.h2.jdbc.JdbcSQLException: General
error: java.lang.RuntimeException: double allocation in file E:\n2.h2-
cache\cache.index.db page 112 blocks 7168-7231 [50000-117]
at org.h2.message.Message.getSQLException(Message.java:105)
at org.h2.message.Message.convert(Message.java:274)
at org.h2.engine.Database.open(Database.java:610)
at org.h2.engine.Database.openDatabase(Database.java:220)
at org.h2.engine.Database.<init>(Database.java:215)
at org.h2.engine.Engine.openSession(Engine.java:58)
at org.h2.engine.Engine.openSession(Engine.java:140)
at org.h2.engine.Engine.getSession(Engine.java:120)
at org.h2.engine.SessionFactoryEmbedded.createSession
(SessionFactoryEmbedded.java:17)
at org.h2.engine.SessionRemote.connectEmbeddedOrServer
(SessionRemote.java:245)
at org.h2.engine.SessionRemote.createSession(SessionRemote.java:223)
at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:110)
at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:94)
at org.h2.jdbcx.JdbcXAConnection.<init>(JdbcXAConnection.java:73)
at org.h2.jdbcx.JdbcDataSource.getXAConnection(JdbcDataSource.java:
288)
at org.h2.jdbcx.JdbcDataSource.getPooledConnection
(JdbcDataSource.java:318)
at org.h2.jdbcx.JdbcConnectionPool.getConnectionNow
(JdbcConnectionPool.java:223)
at org.h2.jdbcx.JdbcConnectionPool.getConnection
(JdbcConnectionPool.java:201)
at H.main(H.java:10)
Caused by: java.lang.RuntimeException: double allocation in file E:
\n2.h2-cache\cache.index.db page 112 blocks 7168-7231
at org.h2.message.Message.throwInternalError(Message.java:185)
at org.h2.store.DiskFile.setPageOwner(DiskFile.java:782)
at org.h2.store.DiskFile.setBlockOwner(DiskFile.java:661)
at org.h2.store.DiskFile.init(DiskFile.java:410)
at org.h2.engine.Database.open(Database.java:598)
... 16 more

[Thomas Mueller]

Hi,

I am sorry to say that, but it looks like a corruption problem. I am
very interested in analyzing and solving this problem. Corruption
problems have top priority for me. I have a few questions:

- What is your database URL?
- Do you use Tomcat or another web server?
Do you unload or reload the web application?
- You can find out if the database is corrupted when running
SCRIPT TO 'test.sql'
- 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?
- With which version of H2 was this database created?
You can find it out using:
select * from information_schema.settings where name='CREATE_BUILD'
- 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?
- What operating system, file system, and virtual machine
(java -version) do you use?
- Is it (or was it at some point) a networked file system?
- How big is the database (file sizes)?
- 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 please?
- Do you still have any .trace.db files, and if yes could you send them?
- Could you send the .data.db file where this exception occurs?

Regards,
Thomas

[Franklin Schmidt]

On Sat, Aug 22, 2009 at 3:28 AM, Thomas
Mueller<thomas.to...@gmail.com> wrote:
>
> I am sorry to say that, but it looks like a corruption problem.

Luckily it is only a cache, so I don't need the data.

> I am
> very interested in analyzing and solving this problem. Corruption
> problems have top priority for me. I have a few questions:
>
> - What is your database URL?

jdbc:h2:file:E:/n2.h2-cache/cache;MVCC=TRUE

> - Do you use Tomcat or another web server?

I use Jetty. I wrote a HTTP caching filter for Jetty that uses H2.

> Do you unload or reload the web application?

no

> - You can find out if the database is corrupted when running
> SCRIPT TO 'test.sql'

Sorry I don't understand.

> - What version H2 are you using?

1.1.117

> - Did you use multiple connections?

Yes, many.

> - 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?

I don't care about recovery, this is only a cache.

> - With which version of H2 was this database created?
> You can find it out using:
> select * from information_schema.settings where name='CREATE_BUILD'

Same, it was created yesterday.

> - Do you use any settings or special features (for example, the setting
> LOG=0, or two phase commit, linked tables, cache settings)?

No, just MVCC=TRUE.

> - Is the application multi-threaded?

Very, it's web serving.

> - What operating system, file system, and virtual machine
> (java -version) do you use?

Windows server 2003, NTFS, java version "1.5.0_19"

> - Is it (or was it at some point) a networked file system?

no

> - How big is the database (file sizes)?

total 3 gigs

-rw-r--r-- 1 fschmidt Administ 301989936 Aug 22 00:55 cache.data.db
-rw-r--r-- 1 fschmidt Administ 57876528 Aug 21 21:50 cache.index.db
drwxr-xr-x 257 fschmidt Administ 0 Aug 21 20:43 cache.lobs.db
-rw-r--r-- 1 fschmidt Administ 640899 Aug 22 02:14 cache.trace.db

> - Is the database usually closed normally, or is process terminated
> forcefully or the computer switched off?

It is rarely closed, only when restarting the service, in which case
it closes with JVM shutdown.

> - Is it possible to reproduce this problem using a fresh database
> (sometimes, or always)?

I just started using H2 a few days ago, so no.

> - Are there any other exceptions (maybe in the .trace.db file)?
> Could you send them please?
> - Do you still have any .trace.db files, and if yes could you send them?

That's an interesting file. Many things I need to fix. I will attach it here.

> - Could you send the .data.db file where this exception occurs?

Too big. But I can give you direct access to the machine where the
error occurred if you send me a private email. I have the database
still saved.

[Steve McLeod]

I also use H2 with MVCC.

I was getting plenty of crash reports from my users with these errors
("double allocation in file"). A week ago I rolled out an update that
used added ";LOG=2" to the URL. Since then I've not received a single
"double allocation in file" error. I'm not ready to conclude yet that
this has fully solved the problem. However I have about 1000 users who
use my software daily, and the software uses the database heavily.

Regards,

Steve

On Aug 22, 11:31 am, Franklin Schmidt <fschm...@gmail.com> wrote:
> On Sat, Aug 22, 2009 at 3:28 AM, Thomas
>

>  cache.trace.db
> 845KViewDownload

[tsukasa]

I have a corrupted database (1.0.79 version). At startup it logs
something like:

08-24 17:40:35 index: open existing TEMP_TABLE_2_0 rows: 0

do I send the files for you? I don't have all the trace for when it
first happenned the error, only the steps to make it appear again
starting with the files I have.
The curious thing is that even if I do a scriptto and a runscript, it
keeps failing again.

BTW to which H2 version do you recommend to upgrade now? (only
speaking about stability)

Thanks.

[Sam Van Oort]

> BTW to which H2 version do you recommend to upgrade now? (only
> speaking about stability)

Upgrade to the *LATEST* version whenever possible. MVCC bugs are
constantly being patched, and the last few patches fixed a lot of
them. The next release has a couple fixes for MVCC problems as well.

You're only likely to get compatibility issues if you're using
experimental features.

Regards,
Sam Van Oort

[Thomas Mueller]

Hi,

>> BTW to which H2 version do you recommend to upgrade now? (only
>> speaking about stability)

I would also use the latest version. Of course there is always a risk
to do that, but I think the risk is relatively low. There are many
test cases that ensure things don't break. See also the changelog at
http://www.h2database.com/html/changelog.html

Regards,
Thomas

[Thomas Mueller]

Hi,

> I was getting plenty of crash reports from my users with these errors
> ("double allocation in file"). A week ago I rolled out an update that
> used added ";LOG=2" to the URL.

Unfortunately I don't have a reproducible test case for this problem.
Anyway, I will add the following paragraph to the FAQ:

"
Some users have reported that after a power failure, the database can
sometimes not be
opened because the index file is corrupt. In that case, the index file
can be deleted
(it is automatically re-created). To avoid this, append ;LOG=2 to the
database URL.
See also: <a href="grammar.html#set_log">SET LOG</a>. This problem
will be solved
using the new 'page store' mechanism (currently experimental).
"

Regards,
Thomas