|Subject||Re: [IB-Architect] Super-transactions and Incremental Backup|
> > When we start talking about freeze points and such thingsI'm not sure I can. I certainly have nothing up my sleeve. Without the
> > 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.
> Although I think it's important to finish the discussion of
> freeze-point / incremental logical backup thread, I suspect
> (but can't prove) that it's a dry hole. The problems of
> handling deleted records and limbo transactions are likely
> to be hard sticking points. But perhaps Mr. Wharton will
> surprise us.
sources and even more important, an in-depth understanding of the MGA
architecture details, I'm shooting in the dark.
In my mind I don't see where deleted and limbo records would be a problem.
They just seem to fit in with all the rest of the stuff.
What I see as being the challenge is knowing how to efficiently traverse the
records in the order that their transactions were committed. This would need
to be a record-level operation and not purely a page-level one. There would
need to be a log of committed transactions to serve as an index to the
record changes within the "delta". It would only need to contain ones that
actually have changes within them. Now, the hard part is to decipher what
all changes took place for each transaction in the log. I can see how ugly
this could get and without some real magic this may not be a totally
feasible approach without imposing significant overhead to the engine.
I've not given up yet but perhaps I'll wait until I can actually familiarize
myself with the sources and have better researched suggestions.
> I think an examination into alternatives for physical backupIs the paging architecture still valid in todays OS and hardware
> (page level) will be useful though possibly less instructive.
> But since my goal is education and not just problem solving,
> we can wait.
environments? To me at least, I wonder if perhaps operating systems aren't
advanced enough such that the whole paging scheme can just be left up to the
Feel free to flame me but please understand that I do not know OS's at all
when programming at these levels. I would be very interested in hearing how
these layers come into play when dealing with reading and writing
information in the file system. I would also like to know the feasibility of
creating a database system that off-loaded the complexity of paging totally
to the OS.
I think perhaps the first thing I am going to hear is that with a cross
platform database being able to abstract this layer makes things much
simpler. Let's put that aside if we can for the sake of discussion. Jim's
replies would be nice but let's not all get into the habit of simply waiting
to see what Jim has to say, ok?
CPS - Mesa AZ