1. In the user menu, choose liveCache Assistant (transaction LC10).
2. Enter the name of the database connection.
You can select the name from the list of existing names. You can restrict the search for the required name.
3. Choose liveCache ® Monitoring.
Calling up the liveCache Alert Monitor using the liveCache Assistant user menu usually activates the Alert Monitoring and the liveCache connection is added to the liveCache Alert Monitor Tree.
It may be necessary to update the liveCache Alert Monitor display. To do this, choose Refresh and Invalidate Data Cache in the liveCache Alert Monitor.
In some special cases you may choose or have to administer the liveCache connection in the liveCache Alert Monitor manually. In these cases you can use the report RSLVCALMON.
Execute the report RSLVCALMON.
1. Choose ABAP Editor (transaction SE38).
2. Enter RSLVCALMON.
3. Enter the name of the database connection
As an alternative to starting the report, you could also start the central instance.
Execute the report RSLVCALMDEL.
4. Choose ABAP Editor (transaction SE38).
5. Enter RSLVCALMDEL.
If data collection methods are periodically scheduled, alerts are automatically updated and forwarded to the monitoring tree. Analysis methods deliver additional information about the alert statuses, and auto-reaction methods can be configured for automatic reactions to new alerts.
You can use the following start options:
● Alert Monitor
In the liveCache Assistant, choose liveCache ® Alert Monitor ® MaxDB Monitoring ® liveCache.
or
In the liveCache Assistant, choose liveCache ® Monitoring ® Alert Monitor ® MaxDB Monitoring ® liveCache.
The Alert Monitoring is activated and the liveCache connection has been added to the liveCache Alert Monitor.
Every monitored element of the liveCache is displayed as part of a hierarchical tree (monitoring tree) and described as a monitoring tree element (MTE), or node. Online help (short and long texts) gives you the most important information about each node.
You can choose from the following displays for each liveCache node in the monitoring tree:
● Properties
● Space Management
● Performance
● Backup/Recovery
● Health
● liveCache Applications
● External Analysis Tools
● Green displays mean that the liveCache state is OK. The administrator does not need to intervene.
● Yellow or red displays mean that this state is putting production operation of the liveCache database instance at risk. The administrator must take measures to find and eliminate the cause of the alert.
τ To improve liveCache performance, the first step is to optimize the setting of the liveCache configuration parameters
τ If a shortage of main memory or CPU performance is detected, you should enlarge the main memory or increase the number of CPUs.
τ If you cannot find out why the performance is poor, call SAP Active Global Support and ask for an SAP APO/liveCache specialist.
Relevant SAP Notes 490958 and 496318
Download ADM555 - LiveCache Administration - http://www.easy-share.com/1905354899/ADM555
Download SAP eBooks - http://ebookssap.blogspot.com
τΊ
CACHE_SIZE Size of the global I/O buffer cache in pages (8 KB)τΊ
OMS_HEAP_LIMIT Maximum size of OMS cache in KBτΊ
MAXCPU Maximum number of CPUs used by liveCache UKTs with user tasksτΊ
MAXUSERTASKS Maximum number of connectionsτΊ
MAXDATADEVSPACES Maximum number of data devspaces used by the current liveCacheNote : For the latest liveCache parameter recommendations, check SAP Notes 490958 and 496318
Memory configuration parameters CACHE_SIZE, OMS_HEAP_LIMIT:
τΉ
Adjust the sizes according to the current or expected data volume.τΉ
If the SAP APO system is not yet in production, use the SAP Quick Sizer to calculate the expected data volume.τΉ
In liveCache 7.4, parameter OMS_HEAP_LIMIT should not be set to 0.- In live Cache 7.2, the recommended value was 0.
External Heartbeat
The collector uses an external program (DBMCLI) to periodically check if an SAP instance is able to access liveCache. A red alert is generated when a failure occurs.
Heartbeat
liveCache can have a number of statuses. liveCache is working properly when it has a status of "WARM." By default, the status is checked every 5 minutes; however, this value is userdefinable. A red alert is generated if any other status then "WARM" is detected.
System Error Messages
At user-definable intervals (the default is every 5 minutes), the collector reads the System Error Message log file. Every error message is reported as a red alert. A customization table is used to suppress notification of specific error messages and/or to modify how error messages are evaluated.
Synchronous BAPI Logging & Archive Logging
A customization table is used to set the logging level ("liveCache logging switched off," "synchronous logging turned on") and the archive logging (ON/OFF) for each client. A red alert is generated as soon as the actual value deviates from the default.
Connection to liveCache
The connection to liveCache is checked according to the specified interval. In addition to the connection tests, the system also checks if the appropriate entries for LDA (primary connection for multi-connect) and LCA (secondary connection) are present in the DBCON table.
OMS Data Cache, Converter Cache
The Object Management System (OMS) stores and manages the business objects. The data blocks are stored in cache for rapid access, and the references to the physical blocks are stored in the SYSTEMDEVSAPCE. Storing the references in the so-called converted cache enables them to be accessed more quickly. After each run, the collector reports the actual OMS data cache usage values and hit ratio as well as the hit ratio for the converter cache.
These values can be used for creating a performance graphic.
Status Checks
The collector periodically checks the status of:
Database Full YES/NO
Diagnosis Monitoring ON/OFF
Monitoring ON/OFF
Vtrace ON/OFFA red alert is generated as soon as the actual value deviates from the default, which is black and bold.
Initialization Log File
The initialization log file is refreshed every time liveCache is started and initialized. The collector searches the last log file for errors. The strings that the collector searches for in the log file are defined in a customization table. The "*" (asterisk) wildcard can be used in the string definitions. The alert threshold can be determined at the string level.
Functional Check / Simulation
A report is used to check liveCache's function ability. Test data is written to and read and deleted from the LC. A red alert is generated if an error occurs during the simulation. The last erroneous log file is always saved so that analyses can be performed at a later stage.
COM Routines
Application functions are implemented in liveCache as C++/COM routines. These functions enable the objects to be modified directly in memory.
Trace Level
The collector checks if at least one trace level is active. A red alert is generated when an active trace level is found.
Runtime (COM routines)
A COM routine's average runtime can provide an indication of the system's utilization. A customization table is used to define a COM routine's average response time. A red alert is generated when a defined response time is exceeded.
qRFC Ping
This connection test is twofold: First the availability of the connection to the APO clients is tested in the APO system itself, and then the so-called external CIF connections (RFC lines) of the R/3 systems that are connected to APO are tested. The collector automatically recognizes all of the connections that need to be tested and requests them periodically based on a user-definable interval (the default is 5 minutes). A red alert is generated if a connection failure is found.
qRFC Queue Length
Among other things, the number of entries per destination queue provides an indication of the APO system's processing speed. If there are problems processing a queue, the jobs may be assigned to another queue. Threshold values that determine the number of queue entries that are required to generate a yellow or red alert are specified in a customization table. The collector is scheduled to run at user-definable intervals (the default is 5 minutes).
qRFC Queue State
qRFC Runtime
The runtime of a queue's job also provides an indication of the APO system's processing speed. If a queue's currently active job exceeds a pre-defined runtime (e.g. APO's upload program has fallen into an endless loop or the process has halted) a yellow or red alert will be generated based on the settings. By default, a yellow alert is generated is the job's runtime exceeds 5 minutes and a red alert is generated if the job's runtime exceeds 15 minutes. Both of these threshold values are user-definable.
Logging/Debugging
The collector checks the current logging and debugging settings of the user that is registered in the RFC connection for all CIF connections. Logging and debugging default values can be individually defined for each user. A red alert is generated as soon as the actual value deviates from the default.
Consistency of the SAP Core Interface (CIF)
The collector checks the consistency of the SAP Core Interface. For the check, the data collector examines the APO-specific tables for inconsistencies. If inconsistencies will be found the data collector generates alerts providing information about how many inconsistencies have been found and which logical systems (SAP R/3) are affected.
