We are having several huge performance problems regarding loading data to Siebel EIM tables (from other DB2 tables with same DB2 version etc) + same problem with Siebel EIM jobs loading the data into all the Siebel tables.

One "primitive" and somwhat unstable work around we have found is to "disable" runstat on index. Wich boost the load/insert performance a lot.

Note1: Data volyme, number of users, etc are relatively small. HW muscles are relative big.

Note2: Huge problem in the region of same amout of hours instead of minutes.

QUESTION:
a) Anyone with good (or bad) experience/comments with W2K3/DBV816/Siebel77 ??
b) Or is DB2V8.2 a better /more stable version than DB2.1.6 on windows

is this a native load done by siebel or using import or load utility ?
from which source ? files / database ?
if database to database (db2 to db2) try define a nickname and do load from cursor..
any additional info to add ?
Best Regards, Guy Przytula

Well.
yes its db to db (within same box) trying both with federated and without. Using views as well as raw tables.
Performance issue regards both native db2 and siebel.
Rewriting SQL does does a lot but not enough by far. One strange thing. visual explains tells SQL OK. But running it is another long running story.

So.. we are starting suspecting there is something in the "combination" siebel/db2/windows.

Our problem is that there are, in our part of the world, not to many around running on DBV8/Siebel77/WIN2K3.

Few thoughts -

* Before running EIM, have you disabled "Transaction Logging = False" in siebel?

* Why are you using DB2 v8. with FP6, i thought IBM has already recalled that and instead you should be using FP6a or higher eg: 8.2

* How have you divided your EIM batch? I mean - are you doing an import or import/update as well? In that case, split your data into batches using IF_ROW_BATCH_NUM indicating whether it is a import or update.

* Hope you have already taken care of synonyms = false, default column/fixed column etc

Let me know which part specifically causing problem.

HTH.