on 10-09-2008 5:48 PM
Guys,
RIMODGEN & RIMODCA background jobs are running very slow. Any clue ?
Mike
You can consider running dbms stat on certain tables. This helped us a lot.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
13 | |
4 | |
3 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.