My BIG concern is that my program (Delphi XE with good old IBX components)
run with the exactly same release, on 4 different clients generating
diferent results. 3 of these are in normal parameters (while working, the
gap between OIT/NT and OAT/NT and OST/NT increases by a few transactions / 5
sec) but when that particular client (same program, same FB client, same OS,
same ISP) starts my program, the mentioned values increase in an alarming
rate of 100...200 / 5 sec, so that at the end of a normal working day, the
gap is arround 1.5 mil transactions. People using the program at this
company complain about the slowdown in the afternoon compared with the
morning.

Anyway, I do a sweep each night, after a backup, so that in the morning
things are reset, but I want to figure out what goes on wrong.

I use MON$tables - this way I figured out who (IP) in slowing down the whole
thing. Tried different options to improve the design of the program.



Thank you,

Tiberiu




From: Ann Harrison
Sent: Friday, March 30, 2012 7:07 PM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] OIT / NT



On Fri, Mar 30, 2012 at 4:13 AM, Tiberiu Horvath
<tiberiu_horvath@...>wrote:

>
> I use Firebird Transaction Statistic Logger to see the problem. ... While
> this client is using my software, somehow the gap between OIT and NT
> increases 200 transactions each 5 seconds.

OK, time for my lecture on OAT and OIT.

The OIT is the oldest transaction in the system that did not commit -
usually a transaction that failed but could not roll itself back. They're
more common in Classic that SuperServer because the latter rolls back
transactions after a normal failure. But if one of the client processes is
killed, it will leave all its transactions marked as rolled back. There
are only two ways to increase the OIT. Backup/restore or sweep. The good
news is that an old, stuck OIT doesn't matter much at all. A very long
time ago when we could only dream of have a gig of disk (and not even
imaging a whole gig of memory), keeping a list of the states of old
transactions (at two bits per transaction) between the OIT and current
transaction was a problem. It's not any more.

So don't worry about the difference between the OIT and next, or if you
must worry, run a sweep from time to time.

The OAT is the oldest transaction that the system considers to be active.
It blocks garbage collection and induces database bloat. Transactions
that commit using "commit retaining" do not advance the OAT. Transactions
that are left open for hours - even transactions that have not changed
the database - leave the OAT stuck. Once the OAT is stuck, Firebird must
keep old versions of records that transaction might read if it ever wakes
up and starts working again.

Do worry about a stuck OAT. Use the MON$ tables to identify it and stop it.

Good luck,

Ann

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




TODAY(Beta) . Powered by Yahoo!
Longtime star quarterback's big gripe
Donovan McNabb says Tim Tebow has gotten a better deal than he has in at
least one respect.
Privacy Policy