/sapapo/om02 - LiveCache Tracing for Optimization Run problems

[Former Member]

We are doing IR (Inventory Replenishment) Optimization runs. They take up a significant portion of our processing.

We have been using internal parallelization (/sapapo/sdp_par) that creates dialog work processes (up to 99 of them - 2 digit field) that processes these concurrent 99 threads in Livecache. This part of the process is efficient.

The last phase of this process runs a isingle thread in LiveCache which runs for around 800 to 1000 seconds. I don't know what is being done during this phase.

I want to use the /sapapo/om02 transaction to diagnose what is running in this thread. The problem is, unlike ST05/SE30/ST01 and trace of these likes, they trace whatever you wish (SQL, RFC, Enqueue, Buffer, ABAP) in the work processes or userid's you wish to trace.

The /sapapo/om02 trace has TRACE and CHECK levels for a multitude of groups, like API, BASIS, SCHEDULER, PEGGING, etc.

I want to figure out what is running in that LC thread for a given user, but am unclear (due to no documentation on how to effectively run this transaction) to determine why this process is taking this long.

Is there a document I simply cannot find in SDN or OSS out there that someone can share? Has anybody had experience running these traces to diagnose livecache issues?

Please advise.

Thanks,

Dale.

[former_member229109 · Accepted solution]

Hello Dale,

For further analysis of the LCA problems < liveCache applications issues, LCA routines errors > liveCache application development < !! > support may be need to activate the so called LCA trace(transaction /SAPAPO/OM02), the C++ profiling (transaction /SAPAPO/OM20) and the logging of function modules (transaction /SAPAPO/OM22). Switching on the trace might lead to a decrease in system performance for the relevant user for the time the trace is active, but these tools are required for analysis for LCA development support.

< You could review the LCA transactions in /n/sapapo/om00 >

In the LCA trace, which is written on the liveCache server in the liveCache directory, additional information will be written - tracing LCA Objects, if the trace level is changed, and this information will help the LCA developers to get clear on the LCA routine issue.

You are running the APO applications => you are SAP customer. I recommend you to create the OSS ticket 'BC-DB-LCA' where your problems & LCA transactions could be discussed in more details, if it is needed. And we could logon to your system via OSS and check the status of the issue.

If you have any questions on the liveCache/Lca topic please post it on the MAXDB/liveCache forum.

You wrote ::

"The last phase of this process runs a isingle thread in LiveCache which runs for around 800 to 1000 seconds. I don't know what is being done during this phase.

"

Please monitor your system first:

-> Check in /nsm50 if LCA routines are running long time;

What is the name LCA routine?

-> If yes, check the active tasks in liveCache;

-> Use the x_cons tool on the liveCache server, run for example:

x_cons <SID-LC> show all

x_cons <SID-LC> show active

-> Check errors in knldiag, knldiag.err & LCA trace number 1;

-> Switch on the DB Analyzer in liveCache & check warnings;

-> Please review additional information at

https://www.sdn.sap.com/irj/sdn/wiki?path=/display/maxdb/main&;

-> MaxDB Support Guide -> liveCache

-> SAP Note 820824 MaxDB/liveCache technology

SAP Note 974758 Scheduling of sapact shell script

-> SAP link :: service.sap.com/liveCache -> Release Information

Thank you and best regards, Natalia Khlopina