Em 4/6/2013 22:23, sir_wally_lewis escreveu:

> It became clear to us that to keep the system going we have to run a backup/restore every weekend because of slow downs when transaction counts got too high which means the system is barely keeping it's head above water.
>

I can't see a reason why transaction count (transaction ID) getting high
would make the engine slower...

The back-up/restore process would reorganize the data (no record
versions, balanced indices, indices statistics up to date, no fragmented
tables/records, etc.) and since it's a new database, the transaction ID
would be reset, but the fact that the transaction ID is a low number has
nothing to do with server slowness...

I think you are looking at the wrong numbers... If you run gstat when
your database became slow, you could find the real culprit (long running
transaction, lot of record versions, fragmented tables, etc.)

The back-up/restore could in fact make you database faster, but it has
nothing to do with the transaction counter being reset.

see you !