Kbase P98099: Will a transaction in the Begin state cause bi growth?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
01/04/2009 |
|
Status: Verified
GOAL:
Will a transaction in the Begin state cause bi growth?
GOAL:
At what stage of the transaction does the bi chain get locked?
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
FIX:
Transaction states for Progress transactions can be checked under -
promon > R&D > 1. Status Displays ... > 4. Processes/Clients ... > 3. Active Transactions
When debugging issues involving excessive bi growth (e.g. when the 2GB limit has been reached), checking what transaction state a transaction is in can be useful. A long-running transaction is one in the ACTIVE state - data are then being processed in the transaction - could clearly be implicated in bi growth, but can the same be said for a transaction in the BEGIN or ALLOCATED state? That is, if a transaction remains in the BEGIN or ALLOCATED state, will it cause bi growth?
The BEGIN or ALLOCATED state is the first state a transaction will enter (depending on the Progress/OpenEdge version). A transaction in the BEGIN or ALLOCATED state is one for which "A transaction table entry was allocated, and a start record is being logged". (Database Administration Guide and Reference). A transaction in the BEGIN or ALLOCATED state will not cause bi growth, since at the point in time the transaction enters the BEGIN or ALLOCATED state, no writes are actually made to the bi file. If it never does anything, both the transaction begin note and the transaction end note will be optimized away when the transaction end.
The following test illustrates the behaviour -
1. Create a test database:
$ prodb test sports2000
3. Start the test database
$ proserve sports
ls -l test.b1
-rw-rw-rw- 1 user group 2228224 Apr 3 11:30 test.b1
4. Connect Client session #1 and run the following code, do nothing (don't space bar through the pause).
$ mpro sports -p transaction.p
/* transaction.p */
DO TRANSACTION:
FIND FIRST customer EXCLUSIVE.
PAUSE.
END.
promon shows that the transaction started under session #1 is in the Begin state:
Status: Active Transactions
Usr-Name-----Type-Login-time-----Tx-start-time--Trans-id-Trans-State
--6-pluto----SELF-04/03/08-08:39----------------------76-Begin
5. Connect Client session #2 and run the following code:
mpro sports -p addrecord.p
/* addrecord.p */
DEFINE VARIABLE newnum AS INTEGER INIT 1 NO-UNDO.
DEFINE VARIABLE itrans AS INTEGER NO-UNDO.
DO itrans = 1 TO 1:
DO WHILE newnum <=1000:
CREATE customer.
ASSIGN Customer.Name = "breakbi" + string(newnum)
customer.comment = FILL('S',30000).
IF newnum MODULO 250 = 0 THEN DISPLAY newnum ETIME / 1000.
newnum = newnum + 1.
PROCESS EVENTS.
END.
PAUSE 10 NO-MESSAGE.
END.
promon shows that the transaction started under session #1 is still in the Begin state and session #2 is in the Active state:
Usr-Name-----Type-Login-time-----Tx-start-time--Trans-id-Trans-State
--6-pluto----SELF-04/03/08-08:39----------------------76-Begin
--7-donald---SELF-04/03/08-08:40-04/03/08-09:13----10275-Active7. When the procedure finishes, wait at least 60 seconds (specifically, the value for -G for the database - by default this is 60 seconds).
Waiting ensures that the clusters used have aged and have been flushed (-Mf).
Check the size of the bi file:
ls -l test.b1
-rw-rw-rw- 1 user group &nb.sp; 34209792 Apr 3 11:30 test.b1
8. re-run client session#2:
If the Begin state tx of Client session #1 was preventing cluster reuse, the bi would now immediately start to grow. Since the tx would be preventing reuse of the space from the first cluster onwards.
However, the bi doesn't grow, the clusters are getting reused from those already added to the bi cluster chain during the previous run of client session #1.
Check the size of the bi file:
ls -l test.b1
-rw-rw-rw- 1 user group 34209792 Apr 3 11:30 test.b1.