I am enjoying this thread as I'm curious to see what we
can all come up with as a viable solution. I've been
taught by my seniors over the years that managing the
MGA via an appropriate client transaction model is the
key to linear performance and 24x7 success with InterBase.

When we start talking about freeze points and such things
I get a bit nervous. I like to see databases snappy
clean from garbage with a very narrow gap between the
OIT and OAT at all times ( currently a problem with gbak
backup and VLDBs on a high volume system ). It is likely
that my training has made me leary of database garbage as
all I've ever seen it do is create excess work for the
engine and slow down the MGA.

Perhaps the engine can be taught to preserve back record
versions ( garbage collected but, space not reclaimed )
that are invisible to the live system but, available for
this proposed incremental backup feature. This would
likely lead to database file bloat ( which I do not like )
but, at least it would be from the instruction of the
developer and preferrably not a default mode of operation.

There once was a feature created by Deej in the days of
InterBase 3.x called gds_replay. I've never used this
feature as it was not a documented thing and depricated
with the release of 4.0. Actually, I believe Deej created
it to debug a customers production environment problems.

Others may no more details about how it worked and if it
would be appropriate but, I've always wanted to see this
feature come alive again. What does it do you ask?

From what I know, the feature sits somewhere between where
client requests are made and executed. gds_replay captures
the gook ( that once was a SQL request ) into sequential
( as executed by the engine ) log-like script that can
be replayed against the engine to recreate a multi-user
environement on a stand-alone machine. Maybe something
like this can be massaged into an incremental backup
feature. I can say that it would surely assist Support
R/D and QA in reproducing complex customer run-time issues.

OT: I'd love to see a few more global variables like Dalton
suggests. That and some embedded string/blob functions
would make the trig/proc language a lot more powerful.

Markus



Doug Chamberlin wrote:

>
> At 6/20/00 03:59 PM (Tuesday), Jim Starkey wrote:
> >Unless the super-transaction that defines a freeze point performs updates,
> >the newest pre-freeze point record versions and the at-freeze point record
> >versions are one and the same.
>
> Agreed. I guess we are referring to the same records with different labels.
>
> I don't see the super transaction that establishes the freeze point doing
> anything other than work directly required to establish the freeze point. A
> possible exception would be rebuilding the current records so they are all
> full records without reference to those versions before or after. That
> would free the garbage collector to not have to do this at another time and
> thus complicating it further.
>
> ------------------------------------------------------------------------
> Old school buds here:
> http://click.egroups.com/1/5536/4/_/830676/_/961536251/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com