Thanks Ann.

I am pretty sure it is garbage collection now. Looks like my app had
a stuck transaction.

A further question though. I fixed the app but the transaction number
still seems stuck this morning but gbak is running. I would suppose
that gbak would need to run as some sort of concurrency transaction.
Would that cause the OAT to be stuck while the backup is running. If
so, doesn't that get you into a catch-22. You need to run the backup,
which is slow right now because of garbage collection but it in turn
is causing more garbage to be generated because it causes the OAT to
be stuck for several hours?


--- In firebird-support@yahoogroups.com, "Ann W. Harrison"
<aharrison@i...> wrote:

> Stephen,
>
> A frequent culprit in that sort of performance is the garbage
> collect thread, and the clues can be found in a gstat -a -r. Look for
> tables with large numbers of back versions and indexes with > 32,000
> instances of a single value. That combination puts the garbage collect
> thread into a state where it doesn't get enough time in any one quantum
> to do anything valuable. The resolution is to drop those indexes and
> replace them with more selective indexes - adding the primary key at

the

> end of the list of fields to be indexed for example.
>
> Regards,
>
>
> Ann