How to archive CRM Middleware tables

[former_member190996]

Hi Everyone,

Since the performance of our CRM production system is very bad, I'm trying ways to improve it. The first step I took towards that is to delete the application logs from SLG2. There were like 58,000+ logs that have been deleted which were expired.

Now, I see that the size of the middle-ware tables, SMW3_BDOC* are huge. They are like 500-1000MB. What's the best way to archive them initially and then periodically to keep the size in control, may be not more than 50MB? Are there any standard programs that helps to achieve this?

Also, the background job SM06_REORG02 has been running all the day long. Is this due to the huge middle-ware tables?

Thanks for the help.

Regards,

SB

[Former Member · Accepted solution]

Dear Sai,

The way to reorganize the Bdoc tables is to schedule background job for report SMO6_REORG2, as you already did.

To improve the performance, could you please try the following options?

1. Run the basis report RSRLDREL2 for relation table  SMW0REL before running SMO6_REORG2 report. This will delete the object links for BDoc's.

2.  Run report "RSMW0_CLEAN_TABLE_NEW" which will delete the obsolete entries ( which does not have corresponding entries in SMW3_BDOC) from SMW3_BDOC2 table.

3. Report SM08_FLOW_REORG can be used to delete the BDOCs which are processed.

4. The reorg job SMO6_REORG2 only clean fully processed BDoc-messages, but not "yellow" or "red" ones. BDocs in the error state are stored in the system for the correction of the problem. After the relevant BDoc message are set to "green" status the job / report reorgs the relevant tables. Please check SMW01 to see how many such BDocs exist in your system. Change the status of unwanted yellow BDOCs to 'green' by marking it as complete in SMW01 and then these bdocs will be available for deletion.

5. Please ensure that indexes are updated regularly as described in note 707820.

6. Please also consider note 1138051 - Deactivation of BDoc to Object links

7. Please schedule the report as background job. The report SMO6_REORG2 calls many different reports and you can see the options for reorg different objects. You can define variants to separate the options in different jobs.

Best regards,

Ellen

[former_member190996 · Accepted solution]

Hi Ellen,

Thanks a lot for the detailed explanation.

Now, I'm more concerned about the two pressing issues:

1. The inbound queues in CRM are staying in READY status for a while before changing to RUNNING and this is causing lot of delay to push the BP to ECC. Can you please let me know what should be done to make queue more robust?
2. I see there are thousands of dumps in CRM at ST22. All the errors are MESSAGE_TYPE_X. Please suggest where do I have check to get more details of the error?

    

Thank you,

SB

[Former Member · Accepted solution]

Hi Sai,

1. If you are using delta download for BP, you can set parameter CRM_MAX_QUEUE_NUMBER_DELTA in R/3 (note 765236 point 6) and parameter CRM_IN_EQUAL_OUT_QUEUE in CRM (note 624436) to serialize the queues.

(if you are using request load, you can set parameter CRM_MAX_NO_QUEUES_PER_REQUEST to enable parallel processing.)

If there is sysfail status in the queue, all the subsequent queues with the same queue name will not be executed, so you need to resolve the sysfail first.

2.Regarding the dump issue, all documents must have a sold-to partner that can be mapped to a business partner in CRM. In order to find out what partners are missing in CRM for the related documents then you can check note 1528118 or just check the partner in ERP and load it with transaction CRMM_BUPA_MAP.

Best Regards,

Ellen

[former_member190996 · Accepted solution]

Hi Ellen,

Thanks a lot for the continuous support.

I have checked all the parameters and they are good. For now, I have deregistered the SalesDocs inbound queue on CRM and this has stopped the dumps but the inbound queue is piling up.

Mainly, the job SMO6_REORG2 has been running for the last 2 days and it's completed only 50%. What should I do. I have checked all the points and the notes that you have mentioned and everything seems to be fine. Please let me know what am I missing here.

Regards,

SB

[Former Member · Accepted solution]

Dear Sai,

The report SMO6_REORG2 calls many different reports and you can see the options for reorg different objects. You can define variants to separate the options in different jobs.

For example,  define a variant containing only this one option "reorganize processed Bdoc messages" and schedule background job with this variant.

If this is still slow and the previous points are also considered, maybe the data is indeed huge. After running for the first time, you need to schedule this job regularly. Then next time will be faster.

Best regards,
Ellen