One of our busy sites has more than 120 TPS and it cannot last longer than 6
month. The database is online 24-7 and number of simultaneous users ranging
from 0 to 50. Currently, its transaction number is at 2,089,589,687
By calculation, an average of 39 transactions per second (TPS) corresponds
to
It is feasible to roll over the transaction ID without putting the database
offline? i.e. when ID is close to limit, reset it to 0 from the code?
--
View this message in context:
http://firebird.1100200.n4.nabble.com/Firebird-Transaction-ID-limit-solution-tp4230210p4240359.html
Sent from the fire
28.12.2011 17:34, Yi Lu wrote:
> It is feasible to roll over the transaction ID without putting the database
> offline? i.e. when ID is close to limit, reset it to 0 from the code?
It will result in comple data loss. "DROP DATABASE" has the same result, but
easier to do.
--
SY, SD.
-
On Wed, Dec 28, 2011 at 5:34 PM, Yi Lu wrote:
> It is feasible to roll over the transaction ID without putting the database
> offline? i.e. when ID is close to limit, reset it to 0 from the code?
Seems that PostgreSQL AutoVacuum daemon do that for Postgresql databases :
http://www.postgresql.org
> It is feasible to roll over the transaction ID without putting the database
> offline? i.e. when ID is close to limit, reset it to 0 from the code?
In theory there is a "simple" code change which would provide you another 6
months breathing room.
But there is no permanent solution which is cu
no exceptions raises when DATABASE-level trigger on transaction ROLLBACK fails
--
Key: CORE-3712
URL: http://tracker.firebirdsql.org/browse/CORE-3712
Project: Firebird Core
