Subject Re: RE: [IB-Architect] Journaling support?
Author Jason
Rather than implement these freeze points within the GDB it could be
implemented as an exernal file, i.e. write a delta to the gdb & then write
it to the external delta file. I know this sounds very much like re-writing
IB to have a transaction log, but it appeals more than shadowing as we
already have disk mirrors.

If you could make the delta files trip lets say every hour, then they could
be applied in the background, this way I would be in control of a very
flexible backup fault tolerant system.

Currently back-ups with or without garbage collection damage server


----- Original Message -----
From: Jason Wharton <jwharton@...>
To: <>
Sent: Friday, March 24, 2000 6:57 AM
Subject: Re: RE: [IB-Architect] Journaling support?

> From: "Jason Wharton" <jwharton@...>
> >1. Drive failure could leave you without any file. Shadowing
> >or mirroring could solve this, but for a very large database
> >it's quite expensive.
> InterBase does shadow databases but I think that the shadow is required to
> be on the same physical machine, just a different volume? Perhaps it
> a connection to another machine on the LAN at the cost of performance I'm
> sure. Anyway, I think IB has this one covered sufficiently.
> >2. It doesn't help for situations where human errors or acts
> >of malice force you to restore the database to a point in the
> >past, hopefully not too distant ;-)
> Unfortunately InterBase does not cover this one very well at present. I
> been promoting some features that would most like allow InterBase to be
> usable in a huge database, 24X7 environment.
> Since IB is a versioning engine I have for a log time been promoting the
> idea of named freeze points that an administrator could establish. Then,
> backups could be performed based on freeze points so that if you had a
> huge database a daily backup wouldn't force an entire backup of the whole
> database but just since the last freeze point. Then, if a failure ever
> place it would only be a matter of restoring the backup to the freeze
> and then the last difference backup from that point.
> In anticipation of a failure a pre-restored base version could be ready
> waiting on the backup hardware so then is all that would have to be done
> apply the most recent diff backup and you would be good to go.
> Another benefit of the freeze points is that you could do an
> level rollback. This would allow a DBA to say roll this database back to
> named freeze point, such and such.
> Thinking a little for the folks who would implement this in the kernal of
> InterBase (since I'm not a C programmer it won't be me unfortunately) This
> obviously affects the garbage collection process quite a bit. Obviously,
> some garbage collection would not take place in order to preserve the
> freeze points. But, there would still be a certain amount of tidying up to
> consolidate records changes between freeze points. If one record was
> 10 times from point A to point B it is really only necessary that the
> at point A and point B remain in the database. The other intermediate
> changes would need to be garbage collected.
> This is just one little part of my "Enterprise InterBase" vision...
> I have every reason to believe that InterBase could be made to compete
> the likes of Oracle... Perhaps not head to head but... Why think small? I
> think InterBase has a lot of head room to grow into with the right pieces
> put in place.
> Jason Wharton
> InterBase Developer Initiative
> jwharton@...
> InterBase will be the database of the new millennium.
> ------------------------------------------------------------------------
> Special Offer-Earn 300 Points from for trying @Backup
> Get automatic protection and access to your important computer files.
> Install today:
> ------------------------------------------------------------------------
> To unsubscribe from this group, send an email to: