Problem with MCEX_UPDATE_02 COLL.RUN Init

[Former Member]

Hi,

I have a problem with Queued Delta Update Method.

I have activated the queued delta for "02: purchasing"

for datasources 2lis_02_hdr, 2lis_02_itm, 2lis_02_scl.

The data are transfered correctly (maybe!) from Extraction Queue to Delta Queue (daily, the amount of data is almost 1000 a day).

But if i check sm13 transaction I find this situation

1 ME_UPDATE_DOCUMENT V1 NORMAL OK

2 EINKBELEG_WRITE_DOCUMENT V1 NORMAL OK

3 MCE_STATISTICS_UPD_V1 V1 NORMAL OK

4 MCE_STATISTICS_UPD_V2 V2 NORMAL OK

5 MCEX_UPDATE_02_V1 V1 NORMAL OK

<b> 6 MCEX_UPDATE_02 COLL.RUN Init </b>

7 ME_CREATE_MRPRECORD_PO V1 NORMAL OK

8 ME_UPDATE_REQUISITION_PO V1 NORMAL OK

9 ME_UPDATE_QTY_SCHEDULE V1 NORMAL OK

10 RV_MESSAGE_UPDATE V1 NORMAL OK

My system has worked correctly for 2 years, I have got three ODS on BW (0PUR_O01, 0PUR_O02, 0PUR_O03),

where every week I load data from R/3 (datasources 2LIS_02_HDR, 2LIS_02_ITM, 2LIS_02_SCL).

But in sm13 I have 260000 records with this problem (from 2005 when I initialized the delta):

<b> 6 MCEX_UPDATE_02 COLL.RUN Init </b>

Could someone help me?

thank you

Fede

[Former Member]

Is it possible my problem depends on "Main System Profile Parameters for Updates",

in particular parameter "rdisp/vbreorg"?

It specifies whether an update server is to search for incomplete update records and delete these;

therefore, reorganization is active if value = 1.

In my system it's set to 0, then the reorganization of my system is deactivated

I have to run report rsm13002 to delete the incomplete update records?!?

thanks

Federico

[Former Member]

Hi,

for your info: rdisp/vbreorg is set to 0 as well our sys.

and YES, you'll have to run this rpt/ or you stop restart your update srvs...

Please read the OSS...

hope this helps

Olivier.

[Former Member]

I think there can be some problem with your other datasources in 02 application component (a mechanism is collecting data for some other flow that you have activated only for a while, for example)...

I think your problem is mainly related to the space needed to store this unuseful records, right ? Well, try to contact SAP to further investigate about this issue (and I strongly suggest to you to avoid to change anything in SM13, especially if you are loading in BW without problem...)

Let us know...

Bye,

Roberto

[Former Member]

Yes Roberto, my problem is mainly related to the space needed to store this records!!!

It's possible there can be some problem with the datasouces in 02,

indeed, they have been modified from the standard when they have been activeted!

Then, I think, I have to check them out!

Thanks

Federico

[Former Member]

Hi Federico,

the first thing, is this really an issue for you? if yes what is the symptom?

In SM13 you can see update records in error.

This can happen anytime when a user is kicked out in the middle of saving a document because of network problems for example.

When you double click on one of these records, you'll see which module is affected. Usually the status is in init which is correct since the transaction was not commited.

Until here there is nothing to worry about.

Nevertheless these update records should be cleaned up from time to time in order to avoid that somenone having authority process an update which is out of date.

For instance, our previous user has been kicked out, but leter on he went back and reproccessed the document with success; in this case updating the update record will screw it up and generate an inconsistency....

Ask one of your basis expert (ensure that he knows what are are talking about...) to cleanup (reorganize) the update record queue.

Hoping this will help you to understand what's going on there

Olivier.

Message was edited by:

Olivier Cora

[Former Member]

Hi Olivier,

It's possible that a user is kicked out when he was saving a document...

I have seen that all records have this "error" but they are loaded on the Delta Queue, then I think that it isn't an issue for me!

But it's a problem for my db administrator, he's told me they are too many!!!

Thank you!

Federico

[Former Member]

but that's what I said, the queue should be reorganized....

It is important to clear it regularly otherwise VBMOD and VBDATA could get huge and the reorganization could take a while thus inducing real updates to be locked

please read not 67014 and related...

Since we have faced this issues some year ago we are reorganizing incomplete updates every months...

hope this helps

Olivier.

[Former Member]

did you schedule the "update processing" job in the logistics workbench (transaction LBWE)???

you'll find this as "job control" next to your logistics application (in your case "02: Purchasing)