cancel
Showing results for 
Search instead for 
Did you mean: 

Performance issue

Former Member
0 Kudos

Guys,

RIMODGEN & RIMODCA background jobs are running very slow. Any clue ?

Mike

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

You can consider running dbms stat on certain tables. This helped us a lot.

Answers (3)

Answers (3)

Former Member
0 Kudos

Hi Mike,

I will recommand following solutions to improve performance of RIMODINI & other CIF jobs -

1) Please check setting of transaction CFC2 - CIF maintenance ...To improve performance you can set log setting as normal rather than detail.You can use this to set whether and how data records should be logged in the application log for the user specified.

If you still need detail application log than follow below process to archive logs that should improve your CIF job performance.

Detailed logging in productive operation can quickly lead to large database tables and therefore to a drop in performance. In this case, we recommend the following procedure:

a) Archive the logs regularly using transaction CFGD or schedule this

transaction as a background job.

b) Configure the application log using transaction CFC6 so that only

the important data records are logged (only applies to detailed

logging).

2) I will also recommand to check setting of CFC3 - check block size of filter object setting.The size of the filter object blocks influences performance. Small filter object blocks can be processed faster by the system, although this advantage is diminished if a very large number of filter objects are caused by a high number of smaller blocks. Large filter object blocks can lead to problems because of the long processing time for each

lock. The block size that should be used in each individual case is largely dependent upon the current data situation.

3) You can use Parallelized process.Parallelized processing can provide a significant improvement in

performance. The block size (that is, the maximum number of filter objects that are processed per block) is specified using transaction CFC3, as before.

Parallelized transfer is currently only supported for the following object types:

o Material masters

o Production process models

o Sales orders

o Stocks of all types

o Planned orders and production orders

o Purchase orders and purchase requisitions

o Sources of supply (contracts, purchasing info records, scheduling

agreements)

Hope this will help you..

Sanjay Karkun

Edited by: sanjay karkun on Oct 10, 2008 2:29 AM

Former Member
0 Kudos

To improve performance you need to do setting/changes for change pointers ,table CIF_IMOD and some other setting for MARC table.

Please check below SAP note and do correction as suggested.

Note 436687 - Collective note: Performance APO integration

613711 - Performance improvement with access to table CIF_IMOD

489151 - APO publication not material-related

439489 - Termination of the initial supply for planned orders

437946 - Bad performance when creating integration models

436687 - Collective note: Performance APO integration

329110 - CIF: Perform. problems/time out due to change pointer

Hope it will help you.

Manish

Former Member
0 Kudos

please delete obsolete and processed change pointers ,it will improve the performance a lot. You can use bd22 for this and run them making use of parallelization process

Former Member
0 Kudos

Thanks for the information. I will try this.