Jim et all,

Taking your cue, I'd like to review the operation of GBAK.

To start with, what would account for the "sluggish" performance of
GBAK? Or in other words, what exactly does GBAK do?

In comparison, to say, MSSQL server which can run at speeds (that I've
seen) of 100-150Mbit per second.


Sean

> -----Original Message-----
> From: Jim Starkey [mailto:jas@...]
> Sent: Wednesday, June 21, 2000 10:50 AM
> To: IB-Architect@egroups.com
> Subject: Re: [IB-Architect] Super-transactions and Incremental Backup
>
>
> At 07:09 AM 6/21/00 -0700, Markus Kemper wrote:
> >
> > 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.
> >
>
> 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.
>
> I think an examination into alternatives for physical backup
> (page level) will be useful though possibly less instructive.
> But since my goal is education and not just problem solving,
> we can wait.
>
> Jim Starkey
>
> --------------------------------------------------------------
> ----------
> SALESFORCE.COM MAKES SOFTWARE OBSOLETE
> Secure, online sales force automation with 5 users FREE for 1 year!
> http://click.egroups.com/1/2658/6/_/830676/_/961599108/
> --------------------------------------------------------------
> ----------
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>