At 06:12 PM 6/20/00 -0400, Doug Chamberlin wrote:

>At 6/20/00 05:30 PM (Tuesday), Jim Starkey wrote:
>>But let me repeat my question. Why do you need to preserve the records at
>>the "freeze point"? Assuming the rest of the problems have solutions, the
>>records that exist at the freeze points are the only records you don't
>>need to produce an incremental backup. What is the gain in trying to
>>preserve them?
>
>How else can you do a backup of the database state at the time of the
>freeze point? I'm assuming the creation of the freeze point and the backing
>up of the database as of that point are not connected and could be done
>days apart.
>
>I suppose the records could be reconstructed but that would mean any delta
>records would just have to be preserved. I thought it would be easier to
>just preserve what was already there.
>

If you built a mechanism to snapshot and save the state of the
super-transaction's transaction inventory vector, you could
determine whether any given record version was commited relative
to the super-transaction. Or, even simpler, have the backup
utility ask the engine (politely) to preserve the transaction
inventory state at the time the transaction started. If you
made a system table to hold the preserved state, primary key
transaction id, you could have any number of preserved transactions,
garbage collection wouldn't be affected, and the state of a
record version relative to any given preserved state could be
computed (and computed cheaply, no less).

OK, you've got a way to identify (internally, at least) records
that have been inserted, modified, or deleted since a given
preserved transaction. If we agree, try to solve the remaining
problems. I'm running low on hints.

And, no Claudio, I won't keep anybody from running off the cliff.
Sorry. I'll just make sure they don't crash into the ground.
Nothing like a little suspense.

Jim Starkey