Subject Re: Transaction ID
Author Adam
--- In firebird-support@yahoogroups.com, "Alan McDonald" <alan@...>
wrote:
>
> > > > What happens to the garbage collection when it rolls over? I
was under
> > > > the impression that this limit was a show-stopper that you
had to
> > > > backup-restore pre-emptively to prevent.
> > > >
> > > > Adam
> > >
> > > a 24x7 system where you don't do regular garbage collection
backups?
> > > Alan
> > >
> >
> > Of course this happens nightly, but the oldest transaction will
end up
> > being significantly greater than the current transaction when it
rolls
> > over. I can't see how the MGA mechanisms can work if it simply
cycles
> > over.
> >
> > To quote Helen "bad things will happen" when the Transaction ID
overflows.
> >
> > (The Firebird Book p512 for details)
> >
> > Adam
>
> of course this could be an issue..
> but in a web environment, how does the oldest Transaction be much
greater
> than the current (next). Each page delivered is committed or
explictly
> rolledback. There are no long running transactions.
>
> I've just check my web DBs and this is typical.
>
> Oldest transaction 1079651
> Oldest active 1079652
> Oldest snapshot 1079652
> Next transaction 1079653
> Creation date Nov 15, 2005 21:53:41
>
> a diff of 1 between oldest and next...
> Now lets do some sums
> April 14 to Nov 15 last year = 150 days
> therefore 7200 transactions per day
> is that high? is that low? - high to some, low to others, very low
to yet
> others.
> 5 Transaction per minute
> Lets dream up a very heavy website
> 50 Transactions per second (can your CPU and HD handle it?)
> 4 million Transactions per day
> Total available
> 2,147,483,648
> = 536 days
> Not long at this rate....

A bit more, I think it is unsigned (or at least the book refers to it
as a 4GB limit, so make that ~1000 days)

> For me... at my rate.... it's 300,000 days = 800 years.
> I don't think I'm in much danger....
> Someone is asking questions about a major application for a Banking
System -
> they want 5 million Transactions per month - that's 2 per second
(not 50) or
> 35 years.
> Someone else is arguing that 700,000 per day is large... that's 8
> Transaction per second
> that's 8 years life before a backup/restore.
> Bottom line - know your transaction rate and act accordingly....
agree?

Absolutely, even at our largest customer our transaction rate is
usually below 3000 a day so I have even longer. But in a 100
transactions per second type database, you are not even going to get
1.5 years.

By garbage collection, I was not referring to the sweep process but
rather how the MGA works in Firebird. Lets just say you are
transaction 1 (after the rollover) and there is a record version
written by transaction 2147483600 (which is committed). You should be
able to see this record, but because 1 is smaller than it it will be
ignored, because there would be no way for knowing it had overflowed.

Adam