baanpro
5th June 2007, 19:44
Session: tdltc1230m000 - Delete Lots.

We are having heavy performance issue . The session takes more than 1 minute to delete 1 lot. After tracing and troubleshooting, it turns out that when baan code commit.transaction is executed, it goes in some heavy processing (taking 97% of processing on win2k m/c). And it takes around 1 min just to execute commit.transaction. The selects, updates, deletes query are taking normal time

Is this a porting set issue?. Or can it be Baan-informix tuning problem?. How do we resolve it?

Regards
baanpro

norwim
7th June 2007, 14:58
Hi there,

I'm not certain whether I'm right here, but I would assume that the checks for consistency will be the problem. If you have the chance to test it in a test environment, you should try and change the field relations (meaning the severity of checks to be done).
Another idea would be to give the user a session, where he can enter the records to be deleted and do the actual deletion in a background batch job running permanently but invisible for the user, so that the user doesn't have to wait for the deletion to be finished.

hth

Norbert

EdwinvdBorg
7th June 2007, 15:01
Hi baanpro,

I believe this is a programming issue and not a technical issue.
Have you run the program for deleting lots in profile mode (including subsequent DLL's)?
I suggest you send the output files to INFOR Support to look at those.
This session is known for its performance problems since BAAN IV.

baanpro
7th June 2007, 20:35
Thanks Guys.
norwim is right. Seems like the reference checks on tdltc001 is causing the problem. There are 7 tables are refering to tdltc001, out of which only 3 tables have data. tdilc401(around 456k), tdilc402(176k) and tdltc102(3.5M).
These 3 tables has Lookup restricted delete mode.
So after db.delete on tdltc001, whenever any other sql statement is encountered, it goes in heavy processing mode..Initially i thought its a commit.transaction causing the issue.. but later, i changed the logic of standard program to do commit after X number of deletes. But after db.delete, when it try to check on tcqms100 (its empty) for next record, the issue arises.

I am not sure but can it be occuring because of informix version?. Can it be a bug in baan porting set?. We have other client who is on newer version of informix(9??) and installation is on HPUX. The same delete on their system is much more faster..eventhough the data and references are more (heavily customized).
Is there any tuning parameter which can improve the reference check during delete?

BTW, this issue is not just on tdltc001. Its occuring on across all master tables where there is multiple reference tables. For transaction tables deletes, its very fast!.