Skip to Content
Author's profile photo Former Member

SCM APO Performance Tuning

From my own experience of SCM-APO administration, I have tried to outline few key areas that are often found to be the main reason for performance issues. As APO system operation depends on connected OLTP system, Livecache and Optimizers so overall APO performance is dependant on those systems and their internal connectivity also.

In the following few sections I tried to capture some of the practical performance related issues that are commonly faced by APO Basis administratior.

Performance in APO system depends on areas like CIF communication, APO & DB instance, Livecache performance front-end communication etc. Below mentioned sections contains on those key areas :-

1. CIF Communication (continuous CIF monitoring, ensuring queues are not blocked)

  1. Ensure RFC for CIF communication works fine and no queue is blocking CIF communication. For queue blocking issues follow the steps mentioned in APO tips document. Apart from proactive monitoring of CIF queues, various methods, tools can be used for CIF monitoring.
  2. SMQR & SMQS shouldn’t show any CPICERR status.
  3. If RFC load balancing is used at R/3 side with multiple application servers, ensure availability of them particularly after any maintenance activities.

There may be a number of reason for CIF* related error messages. Some of the  CIF* errors and their common causes are mentioned below :-

a) If errors like “Command to tRFC/qRFC: Execute LUW again” is reported and executing them once doesn’t clear the queues then it is possibly locking some object and preventing queue execution. Addressing the issue related to the object lock addresses these queues execution.

 CIF Queue

b) When CIF* errors are specific on LC connection or Db connectivity and repeatedly multiple times similar errors get reported then you may stop/start LC (keeping the functional team informed and stopping CIF queues through OM17) once from LC10->LCA->Monitoring->Operating area.

c) If the CIF* errors are pointing towards issues related to “user id/password problem” – immediately check the RFC connection between R/3 system and APO.

2. APO instance and APO DB (resource utilization, running key reports)

Many issues on APO instance and APO DB can influence the overall performance. Some of the common performance issues are mentioned below :-

2.1 Background Job

One of the most common concern for APO server performance issue comes from long running background jobs.

2.2.1 Integration Model Jobs

Integration model jobs are used for periodic master data transfer from R/3 to APO system. At times integration model jobs performance may be slow. Ensure to run change pointer cleanup jobs with CIF* variants at regular interval.

Jobs with RBDCPCLR program should be run with CIFCUS (customer master), CIFECM, CIFMAT (for material), CIFMTMRPA, CIFVEN (vendor master), CIFSRC etc message types at regular intervals.

2.2.2 Other background jobs

If certain CTM or SNP related jobs are taking more time to run than before then please check tables which are accessed during those job runs. Certain key tables are /SAPAPO/MATMOD, /SAPAPO/LOC,/SAPAPOMATKEY etc tables.

Running update statistics on those tables may improve the performance.

2.2 Availability work process

Another performance issue for APO system could be for non availability of dialog work processes. This may happen when a large no. of queues (containing  large no. of LUW’s) getting executed at the same time.  Using parameter rdisp/rfc_min_wait_dia_wp a certain number of dialog work process can be reserved may be helpful in those scenarios.

2.3 Data consistency

Data between OLTP & APO (external consistency) and also APO & Livecache should be always consistent. /SAPAPO/OM17 and /SAPAPO/DELTAREPORTS3 is used to check external and internal consistencies respectively.

3. Livecache (regular log, data backup, running LC specific reports)

As Livecache is an integral part of APO system landscape so any issues at LC can have a major impact on performance. Some of the common LC related issues mentioned below :-

3.1 LC data and log backup

Major issue with APO operation can happen if LC logs are almost full or backup not taken regularly. If LC backup jobs are failing or not configured properly then ensure to address the issue. RSLVBACKUP program is used for data backup. It is advisable to backup data once in a day.  

LC Job

Backup job can be scheduled from APO application level also. Check periodic backup completion status from SM37 logs.

LC Log



LC log backup can be taken either using autolog backup mode or manually from DBMGui/LC OS level. It is preferable if LC log is set in autosave mode.

If LC10 -> LCA -> LC status shows operational then Livecache is running fine.

3.2 LC Memory and disk access

Apart from backups another important area for checking LC performance is its memory and disk access. There are certain general recommendations related to LC disk dev spaces like each Livecache dev space should on a separate disk – bigger the dev space higher is the I/O parallelization. Moreover it is recommended to set up all dev spaces with the same size also because of performance optimization when distributing I/O among dev spaces / disks and also to use raw devices for the dev spaces instead of file systems. This can improve performance as well. But these are things to consider for a new system. For a running in-production LC system’s performance we check the following things :-

  • Check Livecache alert monitor status for possible performance issues. Possible alert areas should be “red” in color with appropriate warnings.
  • Data cache hit ratio should be more than 99.99%. Average data cache hit ratio should be over 99.9%. Poor data cache hit ratio could be due to insufficient (smaller) size of data cache or for long-running version/long-running transaction.



  • To find the number of executed LCA routines look for the row ‘External DBPROC calls’. For LiveCache this number corresponds to the number of LCA routines executed.

LC Status


  • Another way to measure LC response times for any transaction is check ST3N transaction and check whether “DB Proc” time is relatively high.
  • /SAPAPO/OM13 provides overall checks on LC performance. Look for the entries under “Check” tab like /sapapo/om_reorg_daily, /sapapo/om_lcaalerts, /sapapo/om_delete_old_simses etc which should be all green. Else certain background jobs related to these are failing and you need to take of them.

4.0 Optimizer (should be up and running, no change is .exe file locations)

As it’s an integral part of APO system landscape so any issue with Optimizer can cause a big impact on performance.  Few things can be checked for optimizers :-

  • 1) Optimizer services is running fine at optimizer box.
  • 2) APO to Optimizer RFC is working fine.
  • 3) Optimizer exe file is there at it’s original location

5.0 Connectivity

APO system works in sync with Livecache, optimizers, OLTP and as well as with BW systems, So always ensure that RFC connections between these systems works fine.


Above mentioned points and views are based my own experience of APO Basis support. With these guidance and performance areas are in view, always try to keep your APO and Livecache system updated as per SAP suggestion. Follow EarlyWatch or golive session reports to analyze suggestions for your APO systems.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Dhandapani Satheeshkumar
      Dhandapani Satheeshkumar
      Thanks it is very Informative !!
      Author's profile photo Richard Howard
      Richard Howard
      You mention the use of load balancing on the R/3 side for the CIF.  What about doing the same on the SCM side?  Our Central Instance was overloading with the CIF traffic connected CI to CI, so we put load balancing on both sides following note 593058.  We still use that today in SCM 4.1 but we're questioning whether we'll need it in SCM 7.0, as well.



      Author's profile photo Digambar Narkhede
      Digambar Narkhede
      Very helpful info in blog format...