At 08:35 PM 9/4/02 +0200, =?iso-8859-2?Q?Bogus=B3aw_Brandys?= wrote:

>>
>> I've just read technical paper from Borland's Intebase Web about
>Transaction
>> Inventory Pages(TIP) , Oldest interesting Transaction (OIT) and Oldest
>> Active Transaction (OAT) .
>> Not all are clear for me, but I have an interesting idea.(at the user
>point
>> of view)
>> Firebird is known from good shadowing and backup but do not have any log
>> file to rollback to some time point in the past .
>>
>> This is not quite exact , i think :-)
>>
>> I don't remember how this log is called in another database systems,but
>is
>> sometimes used becouse someone deleted critical information from database
>> (very bad database ;-) .
>>
>> Let me explain.
>> Firebird database manager does good housekeeping with old versions of
>> records,and here my idea occurs.
>> Assume we have ordinary database which is not swept during day but at
>night,
>> and backup is done once a week.
>> Define some server feature like "VANISH_TIMESTAMP":
>> VANISH_TIMESTAMP 12 (default = 12 hours)
>> Now all records should have not only transaction id but also a timestamp
>> when were created
>> (sufficient is to store one double value for record).Alternatively all
>> transactions in TIP could use timestamp, I don't know which is better (?)
>> When "VANISH_TIMESTAMP" is declared database manager should not delete
>> committed records which are "younger " than 12 hours from now ,even if are
>> many such records.
>> Gbak would have a feature to rollback database to some point in the past
>12
>> hours.
>> Making all records with timestamp also give us an option to easy replicate
>> database by just periodically check if there is new committed record and
>> replicate such record in another database (replication could stand
>internal
>> Firebird feature)
>>
>> This is of course an idea (and most of admins won't use it) but allows
>many
>> interesting things.
>>

Interbase actually had this functionality from the beginning of
time until Borland's version 5. The database journalled either
page changes or pages images (whichever was smaller) to a journal
server process that could be shared across any number of database
on a network.

During development of version 5, some crackerjack manager had a hot
idea on how to use the journal for a sequentially write redo log
in case of system failure, apparently getting something for close
to nothing. Unfortunately, when reviewed, it turned out that what
he gave up was the very nice principle that when journalling was
enable, a transaction wasn't reported as committed until the bits
were safely written on two pieces of oxide, eliminating all danger
from a single point of failure. So the old journalling system
was pitched with the new one.

I haven't checked the code, but there is no evidence that the
Borland developers knew that text editors could also delete
stuff from a source file, so I wouldn't be surprised if most
of the code was present but latent. The journal subsystem
itself was next to trivial, so re-writing it in modern C would
make as much sense as an archeological dig.

Journally has its problems, mostly the expense and gross
unreliability of tape driver (oh, ugh). But a journal to
a CDR or DVD-R drive might actually be worth thinking about.

Jim Starkey