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: [email protected] Subject: Re: [firebird-support] OIT / NT On Fri, Mar 30, 2012 at 4:13 AM, Tiberiu Horvath <[email protected]>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
