Long wait time when generate a data load request!

[Former Member]

Hi,

We got a infosource which load data into 3 ods. There are about 700+ requests in each ODS. When trigger the data load with infopackage, the system take like 3 mins to generate a new request number and start that data load. Look like after click start, the system keep scanning system table like RSSELDONE. And, during the data load , the system's performance is very bad. Is this normal? We apply solution 2 of note 620361. The performance issue is solved. Is this how system was designed? Is there any easy way to compress the ods requests to one? It is really not making any sense to copy each ods's data out and reload it back again after certain period of time.Please advise.

Best Regards,

Jeff

[alexander_peter]

Hi Jeff,

the system has been designed that way that it scans all new requests if there is a new request to be inserted: it checks the statuses of all previous requests. This concept was suitable for weekly or daily data loads, but as soon as we are dealing with 'real-time data loads' (e.g. 100 data loads a day), we have to use the workaround described in the mentioned note.

For release BW 7.0 (previously called BW 4.0 - to be released in Q1 2005), we are going to change the request handling and make real-time data load possible without the cumbersome work-around of collapsing several requests into a single one ...

What makes me wonder is that you already experience performance drawbacks with 700 requests ... maybe there is something wrong with indices? Maybe it's worth to open an OSS ticket for this ...

Kind Regards,

Alex PETER, Product Management BI, SAP AG

[Former Member]

Hi Alex,

Thx for the answer. We do open a oss. But, the support keep saing its a consultant issue. I am wondering do they really know what the problem is. You mentaion about something wrong with the indices. you mean indices of those system table or ods? Please advise. Thank you.

BR/Jeff

[alexander_peter]

Hi Jeff,

then please use the SQL Trace ST05 in order to trace the whole activity and identify the worst/longest access times to DB tables. You should check these especially if all indices are ok (you can also see this in the explain query plan -...)

If you have any problems reading the explain plan, please read my performance paper in SAP Service Marketplace alias /bw -> performance -> Tools section or check with a local BW consultant!

Kind Regards,

Alex PETER, Product Management BI