On Thu, Jun 6, 2013 at 6:45 PM, sir_wally_lewis <rgilland1966@...>wrote:

> Hi,
>
>
> There are no long running transactions.
>

OK, then just gstat -h won't show any significant difference between the
OAT and the Next Transaction.

>
> Your assuming my code is the source of the issue, is fascinating to me. It
> is a large "Jump to conclusion". Maybe it should be on the "Jump to
> conclusion mat", that was a joke for anyone who saw "Office space" the
> movie.
>
>

Many people have used Firebird and InterBase for nearly three decades
without finding a case where a high transaction
number caused the database to slow down unless the transaction number
approached 2**32. Lots of people have had
databases become slow because of a build-up of old record versions. When
you've got time, run gstat with the -a -r switches - send the output to a
file. The -r switch causes gstat to report the max, min, and average
numbers of back versions of records for each table. That's the definitive
answer to whether your slowdown is caused by excessive back versions - if
so, there are a number of diagnostic steps that can help avoid that problem.

One other question. If you are running a version and architecture that
supports several garbage collection options, (cooperative, separate thread,
mixed) you might try changing the options. Firebird supports three options
for garbage collection because different work loads put different stresses
on garbage collection and you may find that a different strategy works
better for you.

Good luck,

Ann


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