On Thu, Jun 6, 2013 at 6:45 PM, sir_wally_lewis <rgilland1...@gmail.com>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]
