Skip to Content
author's profile photo Former Member
Former Member

Performance improvement for ALE/IDOC processing

Dear experts,

Could you let me know any information to tune performance?

In our system (SAP R/3 Enterprise 6.20), material master data is distributed from one client to other clients in the same instance. It is because material master is maintained centrally, and is distributed to other clients for member companies.

During the night batch, distributing master data takes more than 2 hours. Although the distribution usually finishes without errors, we would like to explore ways to improve processing performance. Especially, program RBDMIDOC runs long time to create IDOC for MATMAS, even 0 master IDOC is set eventually.

OSS notes of the list for OS/DB/SAP parameters related to ALE/IDOC, tips in organizing batch jobs, etc, will be very appreciated.

Many Thanks,


Add comment
10|10000 characters needed characters exceeded

1 Answer

  • author's profile photo Former Member
    Former Member
    Posted on Sep 16, 2010 at 07:03 AM

    I'd recommend to profile the program at least once to see where there's possible room for improvements. I.e. an ABAP runtime analysis and SQL trace would be good for a start. You can check out the links in thread , which will give you some references if you need them. Once you have more details, you either know what you need to do or you can provide them and ask a more specific question (and thus you will receive much better answers).

    As a general remark though I've seen often poor performance initially on the changer pointer selection, because there are too many entries in the table (due to system generating unnecessary change pointers, which should be disabled or/and lack of proper reorganization, i.e. deletion of old/processed change pointers via BD22). Sounds like this is most likely also the cause of your problem, because otherwise it's hard to explain long run times without generating any master IDocs. You can check the number of change pointers easily via view BDCPV or BDCP2 - it depends how you store your change pointers (most likely you find them via view BDCPV in a 6.20 system, unless somebody switched it to the newer BDCP2).

    If you still have them in BDCPV (or the underlying tables to be more precise), check out [OSS note 305462 - MOD: Migration change pointer to table BDCP2|], which will provide you a general hint how to do that (and thus also improve the performance). However, if you're currently not deleting any old change pointers, you should ensure that a regular job runs for transaction BD22 (program RBDCPCLR). You'll easily find other (possibly relevant) OSS notes by doing a search yourself...

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      Hello Harald,

      Thank you very much for your advice. My colleague got SQL trace and we found unreasonably costly access to BDCPV, and then we found a lots of obsolete records in it.... Our first task was clearly set to delete them. It will take a bit more time.

      Best Regards,