At 07:56 AM 9/5/2002 +0200, Boguslaw Brandys wrote:

>As I understand You are talking about a journal to separate process (an
>later to an external file).

Actually no, the database server itself writes to the journal
file.

>This would be great for some replication schemma
>(one database is Master another - Slave like in MySQL)

That's actually reasonably easy to implement with triggers and
events. I'd worry quite a lot about using code that has been
not been tried in nearly 12 years, given that there is an reasonable
external way to get that job done.

>I was thinking about something different : how to use existing feature of
>Interbase (record versioning) for avoid redo log completly.

That's an idea that comes up from time to time. There's considerable
value in being able to recreate the state of the database just before
something dreadful happened. Adding eight bytes to every record is
quite expensive. One might, as an alternative, log the next transaction
id every 10 minutes or so to create a timeline. Then, if garbage
collection were disabled - or relegated to a special process that
understood how long the old versions were needed - a recover process
could be created that would move the database back to a specific time,
more or less. All transactions that had started at that time and
eventually committed would be considered committed.

The cost of turning off garbage collection is the open question.


Regards,


Ann