--- In ib-support@y..., "csswa" <csswa@y...> wrote:

> sweeps of the db via gfix (no other connections) take the same

time:

> 16 min. Watching the server process I can see the db file being
> walked sequencially from beginning to end at about 100k per

second.

> This contrasts with a backup which rips along at 1 meg per second
> (gbak with default settings)!

Hmm, the plot thickens. I copied the 100+meg db to my second
firebird 1.0 installation: a 333mhz win95 setup with old 1 gig drive
and 128mb ram... and the sweep ran at about 300k per second... this
compared to my main 850mhz 512meg 20gig hd NTsp6 setup of 100k per
second!! On the NT system I have been careful to have minimal
processes running, no virus checker, etc. It's very strange that my
old machine can run the sweep 3 times faster than my workhorse
machine! The only difference I can see right now is the platform.
I'll keep whittling away to see if I can isolate the conditions.

Regards,
Andrew Ferguson

>
> Gfix sweeping is a lot lighter on system resources (virtually none)
> than gbak, though.
>
> Header reveals:
>
> Page size 4096
> ODS version 10.0
> Oldest transaction 287
> Oldest active 288
> Oldest snapshot 288
> Next transaction 289
>
> So no weirdness there.
>
> Regards,
> Andrew Ferguson
>
>
> --- In ib-support@y..., "Ann W. Harrison" <aharrison@i...> wrote:
> > No, sweeping and garbage collect eliminate both the record
> > and references to it in indexes. It finds the records by
> > walking through the tables sequentially (natural order).
> >
> > To remove entries from indexes, the code gets the value from
> > the record version it's removing, checks that the values isn't
> > used in a version of the record that's staying (reasonably cheap,
> > unless you do something like modifying the same record 500
> > while some transaction is open). If the value no longer applies
> > to the record, Firebird/InterBase goes to the index and looks for
> > the value paired with the record id. Only values propagate up in
> > the index, so it must examine all entries in the index with that
> > value until it finds the one with the matching record id. Here's
> > the nasty bit. Duplicates are stored at the front of the chain,
> > so the oldest records are last. Walking a table in natural order
> > removes the oldest records first.
> >
> >
> >
> >
> > Regards,
> >
> > Ann
> > www.ibphoenix.com
> > We have answers.