Apologies if the appears twice, but it doesn't appear to have been
sent the first time.

Ann;
Thanks. I am pretty sure that garbage collection is the culprit. My
app had a stuck transaction. I have fixed this but I see that the OAT
is still stuck. GBAK is running at the moment though. I would
suspect that gbak must run as some sort of 'concurrency' transaction.
Would this cause the OAT to be stuck while GBAK is running? If so,
doesn't this lead to a catch-22? gbak is running slowly because it is
doing garbage collection, which leads to more garbage because the OAT
is stuck?

--- 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