Database could not be opened anymore after crash: HAM_IO_ERROR

[Michael Möllney]

Hi,

now that journal files seems to behave well,  I was looking into crash safety of the database.

I had a program creating a database in an environment which was created with the following flags:

ham_u32_t envFlags = (HAM_ENABLE_RECOVERY | HAM_ENABLE_TRANSACTIONS | HAM_ENABLE_FSYNC);

I went to Windows 7 64bit Task Manager and killed (end task) the database accessing program.

When intentionally killing/crashing the database program the re-opening of the environment/database leads to an error:
HAM_NEED_RECOVERY

In those cases I re-open the environment with the flags:

ham_u32_t envFlags = (HAM_ENABLE_RECOVERY | HAM_AUTO_RECOVERY | HAM_ENABLE_TRANSACTIONS | HAM_ENABLE_FSYNC);

Most of the time this works well :-)

But now I had a situation, where I got an error:
HAM_IO_ERROR instead of the HAM_NEED_RECOVERY.

Looking in the database folder I could see the database file and two journal files. Both had the same size of 45306 KByte!

What might have went wrong?

Any help would be great.

I plan to use the database program on a system, that might loose power any time :-O

Thanks,
Michael

[Christoph Rupp]

Hi Michael,

is it possible that you share the files with me - the database file and the two journal files?

thanks
Christoph

--
You received this message because you are subscribed to the Google Groups "hamsterdb User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hamsterdb-use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Möllney]

Hi Christoph

Well, the database file was a 75GByte file ..... I hope you have some nice DSL line .... :-)

No actually I erased the file allready... sorry..

Next time i will keep the files... hopefully it will happen again (or better not again?) with a smaller file....

Michael

[Christoph Rupp]

Hi Michael,

i will look into this. Give me a few days please.

best regards
Christoph

[Christoph Rupp]

Hi Michael,

just letting you know that i can reproduce this issue. At first glance it looks like the journal was incomplete (your records are relatively large, and if you kill the process while the journal is written to disk then this can happen.)

When the incomplete journal is then opened it seems that the recovery routines are not able to handle this gracefully.

I'll try to fix this over the weekend.

Best regards
Christoph

2014-09-11 10:53 GMT+02:00 Michael Möllney <michael...@gmail.com>:

--

[Michael Möllney]

Hi Christopher,

Thank you for letting me know, that you can reproduce the issue. This saves me some time :-)

Just because I am curious: The key-record pair that was about to be inserted would first be put in the journal? And there might be up to 16 insert transactions in the journal. How many transactions will be lost by the "corrupted" journal?

I hope my question is not to basic to be asked in this forum...

Thanks for your quick reactions.

[Michael Möllney]

Sorry for the wrong name... the autocompleter on my kindle fire seems to "think" it knows your name better than me :-(