cancel
Showing results for 
Search instead for 
Did you mean: 

New Initial Extraction for MDM

Former Member
0 Kudos

I am running a new initial load in my ECC system for MDM (MDM_CLNT_EXTR). It is running a bit longer than I expected and I was wondering if I needed to (or should have) removed the initial load records from table MDM_SELECT_TRANS using MDM_SERV_SELTRANS_MAINTAIN before starting the second initial load. Anyone have experience with this?

Thanks

Accepted Solutions (1)

Accepted Solutions (1)

michael_theis
Active Contributor
0 Kudos

Hi Keith,

MDM_SELECT_TRANS just stores some information about your extraction run. It should not impact the overall runtime. The runtime in generall is affected by other components like:

- current system load

- amount of available background processes

- amount of data to be extracted

- extraction variant configuration, especially the IDoc block size

- the way how IDocs are sent (e.g. collected into packages or immediately)

Usually MDM_CLNT_EXTR runs as background job using as many background and work processes available. If the amount of users currently working in the system is high, the amount of free processes is pretty low. So the overall extraction takes more time.

Best regards

Michael

Former Member
0 Kudos

Based on the SM50 process overview, it is just doing sequential BDCPV. My job has run over 4 hours and only created 3 of the expected 30 idocs. I have 10 vendors per CREMDM idoc set up in the job. Since BDCP is the change pointer table, I would not expect an initial load extract to be worrying about that table.

michael_theis
Active Contributor
0 Kudos

Hi Keith,

actually the change pointers have to taken into account. Change pointers list all changes of Vendors (and addresses, if enabled). So if you do an initial load, existing change pointers for those objects that are part of the initial load need to be set to processed. Otherwise you'd extract the same data again if you do a delta load somewhen after the initial load. Maybe it'd be a good idea to clean up the change pointer tables?! You can use transaction BD22 for this purpose.

Best regards

Michael

former_member205403
Active Contributor
0 Kudos

Thanks Michael for the information.

I have a query. Looks like Kieth is using Standard Content. My understanding is MDM_CLNT_EXTR sets the status of change pointer to processed after extraction is executed. Then why should we need to manual set status of change pointers. Is any case possible when, MDM_CLNT_EXTR will not change status of change pointer. Thanks in advance for the information.

Regards,

Shiv

michael_theis
Active Contributor
0 Kudos

Hi Shiv,

with BD22 you do not set any change pointer status manually. Actually you delete change pointers that are processed and/or obsolet from the related change pointer tables. The reason for that is quite simple:

If you only push change pointers into that table, its size will grow and grow. If you do selects on that specific table, it'll take more and more time to retrieve the desired change pointers. If you check the technical settings for the related tables, you see that BDCP is intended for "Data records expected: 40.000 to 160.000", whereas BDCPS has "Data records expected: 110.000 to 440.000". I've seen some ERP systems that had far more records in the tables - and therefore performance issues during change pointer processing. That's why you should clean up the change pointer tables from time to time.

Best regards

Michael

Answers (0)