Subject Re: [firebird-support] Over-sweeping
Author Ivan Prenosil
Garbage is not much problem - it can be removed
by sweep, but sooner or later it will be removed
by normal cooperative garbage collection anyway.

What is the problem is stuck OIT, which can slow down
starting new transactions and increase memory demands
for each snapshot transaction.
But even OIT is not problem in most applications,
since it can stuck only on some relatively rare occasions -
either after server crash, or after rollback of transaction
that updated lot of data.
There are only two ways how to get rid of stuck OIT -
by sweep, or by creating new database (i.e. backup/restore).

Regarding auto-sweep - it dos not start every 20000 transactions !!!
It starts when difference between OIT and OAT is 20000 !
which usually means when OIT get stuck; in most applications
automatic sweep will never start !


----- Original Message -----
From: "JS.staff" <jsparrow@...>
To: <>
Sent: Tuesday, March 09, 2004 10:41 AM
Subject: [firebird-support] Over-sweeping

> Alan,
> So long as we've agreed that sweeping doesn't have any drawbacks (beyond
> slowdown during the sweep itself). I certainly got the impression from
> our chat you thought nightly sweeping was a bad idea.
> I would absolutely agree that backup/restore is a 'better' solution from
> the point of view of the db file structure - it would just also involve
> making the database unavailable, and introducing the possibility of
> corruption if someone attempts to connect while restore takes place.
> Hence I don't use it for regular maintenance.
> On the point of 20,000 transaction-auto-sweep being "never meant to be a
> frequent event" - it would happen every couple of days for me!
> Disconnected and web-based systems necessarily have a higher transaction
> count than 'connected' apps, I suppose. Ie 1 transaction to populate the
> menu, a second to populate the edit screen, and a third to do the
> UPDATE. Multiply that by 10 users and a couple of hundred views / edits
> per day, and it mounts up!
> Helen, thanks for the info!
> John