Hi Robert,

what you can do for your own information:

query the database headers per:

gstat -h

that shows you the relevant transaction informations, and also if the
internal housekeeping (sweeping) is activated - and when, at what
interval (delta between oldest active transaction and oldest snapshot,
see below: gstat-sample-header)
From what i've read your database/application turns slower every day
until you perform a backup/restore - that is what resets the whole
transaction system.
That also could be done manually by gfix -sweep or managed by the
firebird server per gfix -housekeeping <Number>, wherein the default
value is 20000. Which one you choose depends on the application and
performace requirements.

Regarding transactions and performance: See
http://www.firebirdsql.org/manual/gfix-housekeeping.html
and
http://www.firebirdsql.org/manual/gstat-example-header.html

Marcus
sir_wally_lewis wrote:

>
> Hi Sean,
>
> While I don't pretend to understand Firebird at the atomic level. I am
> just trying to cope with database slowdowns. We find the only bullet
> proof methodology to solve database slowdowns is a backup restore. So
> we are searching for a method to be able to resolve database
> slowdowns, while keeping the database online.
>
> I am not concerned with whether theoretically firebird should or
> should not require a backup/restore. It seems that in practice under
> large database conditions to be a requirement.
>
> Our networks guy is going to spend some time seeing if he can give
> evidence of this requirement. Of course we will try any method to
> attempt to resolve this.
>
> In the past we have not found sweeping the database to help, but we
> will continue to do everything we can to resolve this for our
> customers sake.
>
> Kind Regards,
>
> Robert
>
>

[Non-text portions of this message have been removed]