At 02:43 AM 3/24/00 +0000, jerzy.tomasik@... wrote:

>I remember seeing "Journaling" in old InterBase manuals (3.3)
>but I've never used it. Today I've tried to find out how
>to set it up in the 6.0 beta, and to my surprise, I couldn't
>find it anywhere in the documentation. I've gone back to
>version 4.0 and it looks like journaling was already
>removed (for example "enable" keyword not in gfix).

Versions 2 & 3 of InterBase had an optional after-image
journalling subsystem - it was always on the kit, but
its use was optional and its performance was abysmal.
Worse, it didn't work with the superserver architecture.
It was abandoned.

>Is there any history behind it? Are there any plans to
>resurrect journaling?

At the moment, resurrecting journalling is not at the
top of our priorities - which include shipping V6 and
getting the source out.

>IMHO, journaling is essential for 7x24 applications
>where up to the minute recovery is a must.
>
>Is there an alternative mechanism that I'm not seeing?

Interbase has some characteristics that make journalling
less necessary that it is for other databases.

The first is automatic crash recovery - in theory, you pull
the plug, plug it back in, the database comes up running.
In practice, it works. I wouldn't do it for sport, but
it's a way to survive a power outage.

The second is shadowing. If you lose a disk, you can
switch to the shadow. Shadowing doesn't have the
performance problems that our journalling had ... for
reasons that escape me a the moment. Assuming that
you don't have simultaneous disk crashes on the
shadow disk and the database disk, shadowing should
take care of a physical disk failure.

The third is on-line backup. Obviously, that makes
frequent backups easier, so there's less to recover
if you must go back.

There are cases in which nothing works but journalling.

If your database becomes corrupt, the shadow is just
as corrupt. We take corrupt databases very seriously.
Corruption in indexes, for example, can be corrected
without going to a backup.

Replication can help in the case of database corruption
caused by bugs. The remaining data corruption bugs are
third and fourth level interactions - a bunch of things
have to go wrong all at once to cause the error. With
even modest luck, the same things won't go wrong in the
replicated database. Journalling is a safer solution,
but replication is a reasonable bandaid.

The case that makes me less unhappy to think about is
the user who inadvertently destroys data. Then, the
ability to bring the world up to the moment before the
disaster is a salvation. Even replication doesn't
handle that case.

On the down side, our normal backup creates a logical
serialization of the database - all the data's there
with instructions for putting it into a new database.
That doesn't work with after-image journalling because
there's no way to identify a particular record and so
you can say, "this one just went away." (Right, primary
key, but they're optional.)

Anyway, I'm certainly aware of your concerns and the
rational behind them. There's just no obvious solution
right now.

Ann