Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata


SAP® MaxDB - Analysis of SAP liveCache Problems


give help to analyze SAP liveCache Problems.

Moderators: Christiane Hienger

WIKI Space Editor: Thiago Lüttig.




Performance Problems

A good introduction to the topic performance analysis in liveCache is given by the "liveCache Monitoring Cookbook". Because of the dynamic character of the SAPNet it does not make sense to provide direct link access to the document here but it is recommended to identify it by means of the search functionality. It is additionally advantageous that the whole list of documents concerning this topic is provided and the most recent one can be chosen.

Other information for liveCache 7.4 can be found in BIS (which is accessible for SAP employees only) in a TechEd document:

When investigating liveCache performance problems it is important to take the general system load into account. Under UNIX, f.e. the CPU workload must be considered, if paging activities can be observed on the server and the user/system proportion must be looked at (DB analyzer -> CPU utilization).

If a high system part is observed further analysing must be done by means of operating system specific tools. A high system part means more than 20% to the disadvantage of the user part.

As the name liveCache indicates, the liveCache has a lot to do with the term Cache that is, data in the main memory of a server. The liveCache provides the DB procedures with functions (precisely classes and functions) to be able to work very fast with very large quantities of data. However, the desired performance is only achieved if the data is actually in the main memory of the liveCache server and does not need to be read from the disks. If the liveCache frequently has to reload data from the disks, its performance quickly falls to that of a normal database. Every liveCache performance analysis should therefore begin with an analysis of the memory management.

The liveCache manages data in two areas, in the data cache and on the OMS heap. Adjusting these two memory areas to the scope of the data to be managed, the number of users working in parallel, and the operating system and hardware restrictions is critical for the stability and performance of the APO applications.

You find most of the data that is required for a performance analysis in DBA Cockpit (transaction DBACOCKPIT) or transaction LC10. It is therefore seldom necessary to access the liveCache system tables directly. If however, the easiest way to do this is using the Database Studio. It can be installed on any Microsoft Windows PC, independent of liveCache.

The views used in liveCache area can be found in BIS (which is accessible for SAP employees only) in the following document:

back to top

Memory Problems

If memory problems occur under Microsoft Windows 2000, you should basically check whether the 3 GB option was activated. Without this option, meaningful operation of the liveCache is not possible. Consider SAP Note 112403 when activating and checking the option.

The DB analyzer delivers information to support the analysis of memory problems (DBAN_FILLING). Under UNIX the system heap and the size of the swap file have to be considered.

back to top

Crashes of the liveCache

As a start the actions to be taken in case of a liveCache crash are the same as for a SAP MaxDB Database Crash and the knldiag should be looked at. Furthermore the file rtedump shows which user tasks had been active at the time of the crash. This file can be edited directly without any conversion and contains the output of command


x_cons <liveCache name> show all.


With the help of the detail information for the affected task it can be checked if a DB procedure was executed.

After a classification of the library which led to the crash, the customer message can be sent to the component BC-DB-LCA in some cases. If libraries are shown at the beginning of the back trace which stem from the sap directory and which are loaded after the start of the liveCache (f.e. /sapdb/LCA/db/sap/ the problem should be investigated by the developers of the application under LCA component.

On the other hand crashes in library liboms point to an error in the liveCache itself. Please make sure that all collected information is inserted as internal memo for the customer message.


In the following example the crash occurred within an LCA routine, so the customer message could be sent to component BC-DB-LCA.

Information from file rtedump: Task 552 was active at the time of the crash; all other user tasks had state "Command Wait".


T538  11    561 User     13617* Command wait         no 0           225 3599571(r)
T552  11    575 User      3704* DcomObjCalled  !      0 12              3599571(r)
T568   9    591 User          0 Command wait         no 0             8 3704447(r)


Detail information for task 552:


--------------------  T552  USER              ( pid =   3704 ) ---------------
 remote_node   :                   remote_pid    : 3704
 COM procedure : SAPTS_GET_AGGREGATED_DATA_RIW                                 
 OMS callback  :                                       callback_cnt  : 37138
 dispatcher_cnt: 2945                                  command_cnt   : 142
 exclusive_cnt : 57517825                              self_susp_cnt : 0
 Resume count 0  total 6107       History [ T2 T70 T70 ]
 state_vwait   : 0          state_vsleep  : 2801       state_vsusp   : 0
 rcv_rpl_count : 142        rcv_rpl_long  : 0          avg_rcv_rpl_t : 0.0000

 As there is nothing shown for "OMS callback" this indicates that the LCA routine ran within its own coding at the time of the crash and not within liveCache kernel code.

Excerpt from the knldiag:


2007-01-24 16:12:22     0 ERR 11599 BTRACE   ----> Symbolic Stack Back Trace <----
2007-01-24 16:12:22     0     12825 TASKING  state 29 before shutkill(1)
2007-01-24 16:12:22     0 WNG 11824 COMMUNIC Releasing  T482 database shutdown
2007-01-24 16:12:22     0 WNG 11824 COMMUNIC Releasing  T502 database shutdown
2007-01-24 16:12:22     0     12768          UKT10 stopped
2007-01-24 16:12:22     0 ERR 11599 BTRACE      0: 0xc0000000130071ec
__acxx_delete__dtor_thunk__2__FPv +0x001c
2007-01-24 16:12:22     0 ERR 11599 BTRACE          /sapdb/LCA/db/sap/
2007-01-24 16:12:22     0 ERR 11599 BTRACE         Frameinfo [0x8000021031c5e870]
2007-01-24 16:12:22     0 ERR 11599 BTRACE      1: 0xc000000000151af4
2007-01-24 16:12:22     0 ERR 11599 BTRACE                            criptor +0x00ac
2007-01-24 16:12:22     0 ERR 11599 BTRACE          /usr/lib/pa20_64/libCsup.2
2007-01-24 16:12:22     0 ERR 11599 BTRACE         Frameinfo [0x8000021031c5e870]
2007-01-24 16:12:22     0 ERR 11599 BTRACE      2: 0xc00000000014f9a4 
2007-01-24 16:12:22     0 ERR 11599 BTRACE                            4TPCtoExceptionDescriptor +0x002c
2007-01-24 16:12:22     0 ERR 11599 BTRACE          /usr/lib/pa20_64/libCsup.2
2007-01-24 16:12:22     0 ERR 11599 BTRACE         Frameinfo [0x8000021031c5e7f0]
2007-01-24 16:12:22     0 ERR 11599 BTRACE      3: 0xc00000000014caa0 
ThrowException__FPvRC19TExceptionThrowTypeR17THPStackWalkState +0x01f8 
2007-01-24 16:12:22     0 ERR 11599 BTRACE          /usr/lib/pa20_64/libCsup.2
2007-01-24 16:12:22     0 ERR 11599 BTRACE         Frameinfo [0x8000021031c5e730]
2007-01-24 16:12:22     0 ERR 11599 BTRACE      4: 0xc00000000014c1c0 __throw__FPvT1 +0x0158
2007-01-24 16:12:22     0 ERR 11599 BTRACE          /usr/lib/pa20_64/libCsup.2
2007-01-24 16:12:22     0 ERR 11599 BTRACE         Frameinfo [0x8000021031c5e6b0]
2007-01-24 16:12:22     0 ERR 11599 BTRACE      5: 0xc0000000009680fc
Throw__11OMS_GlobalsSFsPCcRC13OMS_ObjectId8T2UiP11OMS_Session +0x177c
2007-01-24 16:12:22     0 ERR 11599 BTRACE          /sapdb/LCA/db/lib/lib64/
2007-01-24 16:12:22     0 ERR 11599 BTRACE         Frameinfo [0x8000021031c5d980]


back to top 

Bad Pages in liveCache 

If bad pages appear within a liveCache and all actions described here are taken, it may additionally be useful to collect information about the corresponding APO planning versions. See also note 573558 ("Assigning corrupt liveCache pages to APO planning versions").

back to top 

Problems with DB Procedures

As of version 7.4.02 the COM/LCA routines are delivered and installed directly together with the liveCache software. Thus it is guaranteed that they do fit to the used liveCache version.

The problem known from earlier versions that transactions are aborted with error message '-4016 unknown procedure' is obsolete now. In the predecessor version of the support guide SAP employees find a continuative description of the error diagnosis and additionally the release matrix for APO versions 3.1 (and smaller) if the error should occur anyhow:

back to top

HRESULT errors

If there are problems with loading the system tables in the liveCache environment these are often caused by DCOM HRESULT errors. These errors are recorded in the files knldiag and knldiag.err:

05-04 09:20:29 0x158 ERR 18262 DCOM CoGetClassObject - HRESULT: -2147221164, Context: INPROC 05-04 09:20:29 0x158 ERR 18263 DCOM COCLSID: {FC2F8866-6983-11D2-A97F-00A0C94311A5} 05-04 09:20:29 0x158 ERR 51260 HRESULT 80040154

Often these errors are caused by the fact that the file dbpinstall has not been registered correctly. If the MS Developer Studio is installed the meaning of the error number can be determined as follows:

  • Choose menu item Tools -> Error Lookup
  • Insert the HRESULT error number (f.e. 0x80040154)
  • Press the button Look Up

  • In this example the error description means that a class is not registered and thus f.e. the registration of dbpinstall should be checked.

There are also a number of error numbers that cannot be determined with the Error Lookup. These are listed in the following table:

Error number

Error text


















































back to top

KB Net Response Timeout

A timeout occurs if the communication for an ABAP table transport lasts longer than 30 seconds, or longer than set with the liveCache parameter OMS_STREAM_TIMEOUT. The "Command timeout" error is logged by the MaxDB runtime environment in the knldiag file. If the corresponding database procedure reacts correctly to the error, the message "System error: KB Net response timeout" is also logged.



09-25 17:55:44    54 WNG 11824 COMMUNIC Releasing  T286 command timeout#
09-25 17:55:44    54 ERR 51000 OBJECT   omsTerminate will be triggered:#
09-25 17:55:44    54 ERR 51000 OBJECT   SAPAPO_PP_ORDER_CHANGE#
09-25 17:55:44    54 ERR 51000 OBJECT   file: PpApi/PpApiObj.cpp#
09-25 17:55:44    54 ERR 51000 OBJECT   line: 95#
09-25 17:55:44    54 ERR 51000 OBJECT    DbpError -9221 in SAPAPO_PP_ORDER_CHANG#
09-25 17:55:44    54 ERR 51000 OBJECT   E (file: PpApi/PpApiObj.cpp, line: 95),#
09-25 17:55:44    54 ERR 51000 OBJECT   System error: KB Net response timeout#
09-25 17:55:44    54     51000 OBJECT   omsTerminate called  DbpError -9221 in S#
09-25 17:55:44    54     51000 OBJECT   APAPO_PP_ORDER_CHANGE (file: PpApi/PpApi#
09-25 17:55:44    54     51000 OBJECT   Obj.cpp, line: 95), System error: KB Net#
09-25 17:55:44    54     51000 OBJECT    response timeout#


In general, 30 seconds should be sufficient for this communication. If this error occurs repeatedly, you should first check, whether there are network problems. This problem is also described in SAP Note 557069.


back to top