Subject | Very slow execution if Transaction.AutoCommit is true |
---|---|
Author | patrick_marten |
Post date | 2012-11-07T11:26:07Z |
Hello,
there are two versions of my application: the released one and a new one still in progress.
The released one ships with Firebird 2.1.3 and IBO 4.9.9 on Delphi 2007.
The new one will run on Firebird 2.5.2 and IBO 4.9.14 Build 52+ (or IBO 5) on Delphi XE.
There is a routine to fill in "missing" data into a simple table:
CREATE TABLE BANKCODES
(
ID INTEGER NOT NULL,
BANKGROUP SMALLINT NOT NULL,
BANKCODE INTEGER,
PAN VARCHAR( 19),
BIC VARCHAR( 11),
BANKNAME VARCHAR( 60),
SHORT_NAME VARCHAR( 30),
CITY VARCHAR( 60)
);
ALTER TABLE BANKCODES ADD CONSTRAINT PK_BANKCODES PRIMARY KEY(ID);
CREATE GENERATOR BANKCODES_PRIMARYKEY;
CREATE ASC INDEX BANKCODES_BANKCODE ON BANKCODES (BANKCODE);
CREATE ASC INDEX BANKCODES_BIC ON BANKCODES (BIC);
CREATE ASC INDEX BANKCODES_BANKNAME ON BANKCODES (BANKNAME);
CREATE ASC INDEX BANKCODES_SHORT_NAME ON BANKCODES (SHORT_NAME);
CREATE ASC INDEX BANKCODES_CITY ON BANKCODES (CITY);
I'm importing the basic data via a script from time to time, once the data was updated. Data in the column BIC is not complete. One record per BANKGROUP has the value, which applies to all others records of this BANKGROUP, so in that routine I'm creating an update script to fill the missing data.
It looks like
update BANKCODES set BIC = 'DEUTDEBBXXX' where ID = 45;
update BANKCODES set BIC = 'DEUTDEDBBER' where ID = 47;
update BANKCODES set BIC = 'BEVODEBBXXX' where ID = 66;
...
The table has about 25000 records, update script has about 13000 statements.
When doing this with the released version, it took maybe 2 minutes. If doing the same with the new version, it takes much longer - over 25 minutes.
Apparently the transaction settings do play a role here. Although it has worked fine before, it seems to be necessary now to use a transaction with isolation=tiConcurrency and AutoCommit=false, otherwise it takes much longer and additionally FastMM has reported some memory leaks sometimes, but somehow I can't reproduce them repeatedly.
While it's not the common case, that a transaction with AutoCommit=true is used, it should be fine, but I'm still wondering why it has worked in the first case and if the memory leaks really exist and can be fixed.
Because using the transaction with isolation=tiConcurrency and AutoCommit=false works fine, I thought it could be an IBO issue.
Best regards,
Patrick
there are two versions of my application: the released one and a new one still in progress.
The released one ships with Firebird 2.1.3 and IBO 4.9.9 on Delphi 2007.
The new one will run on Firebird 2.5.2 and IBO 4.9.14 Build 52+ (or IBO 5) on Delphi XE.
There is a routine to fill in "missing" data into a simple table:
CREATE TABLE BANKCODES
(
ID INTEGER NOT NULL,
BANKGROUP SMALLINT NOT NULL,
BANKCODE INTEGER,
PAN VARCHAR( 19),
BIC VARCHAR( 11),
BANKNAME VARCHAR( 60),
SHORT_NAME VARCHAR( 30),
CITY VARCHAR( 60)
);
ALTER TABLE BANKCODES ADD CONSTRAINT PK_BANKCODES PRIMARY KEY(ID);
CREATE GENERATOR BANKCODES_PRIMARYKEY;
CREATE ASC INDEX BANKCODES_BANKCODE ON BANKCODES (BANKCODE);
CREATE ASC INDEX BANKCODES_BIC ON BANKCODES (BIC);
CREATE ASC INDEX BANKCODES_BANKNAME ON BANKCODES (BANKNAME);
CREATE ASC INDEX BANKCODES_SHORT_NAME ON BANKCODES (SHORT_NAME);
CREATE ASC INDEX BANKCODES_CITY ON BANKCODES (CITY);
I'm importing the basic data via a script from time to time, once the data was updated. Data in the column BIC is not complete. One record per BANKGROUP has the value, which applies to all others records of this BANKGROUP, so in that routine I'm creating an update script to fill the missing data.
It looks like
update BANKCODES set BIC = 'DEUTDEBBXXX' where ID = 45;
update BANKCODES set BIC = 'DEUTDEDBBER' where ID = 47;
update BANKCODES set BIC = 'BEVODEBBXXX' where ID = 66;
...
The table has about 25000 records, update script has about 13000 statements.
When doing this with the released version, it took maybe 2 minutes. If doing the same with the new version, it takes much longer - over 25 minutes.
Apparently the transaction settings do play a role here. Although it has worked fine before, it seems to be necessary now to use a transaction with isolation=tiConcurrency and AutoCommit=false, otherwise it takes much longer and additionally FastMM has reported some memory leaks sometimes, but somehow I can't reproduce them repeatedly.
While it's not the common case, that a transaction with AutoCommit=true is used, it should be fine, but I'm still wondering why it has worked in the first case and if the memory leaks really exist and can be fixed.
Because using the transaction with isolation=tiConcurrency and AutoCommit=false works fine, I thought it could be an IBO issue.
Best regards,
Patrick