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.
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.
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/libtsdp_api.sl) 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)
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").
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:
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:
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.
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.