Pages

Download SAP Certification Material for FREE @ http://sap-ebooks-den.blogspot.com

Showing posts with label Livecache. Show all posts
Showing posts with label Livecache. Show all posts

Tuesday, August 31, 2010

Displaying Error Codes in livecache

       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.

       4.      If no start application is displayed, or if you exit the application with Back, Exit, or Cancel, you can choose Utilities ® Error Codes in the menu.
 

Managing liveCache Connections in the liveCache Alert Monitor

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.

Adding a liveCache Connection to the liveCache Alert Monitor

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.

The liveCache Alert Monitor is started and the liveCache connection is added. 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.
 

Deleting a Database Connection from the liveCache Alert Monitor

Execute the report RSLVCALMDEL.

       4.      Choose ABAP Editor (transaction SE38).

       5.      Enter RSLVCALMDEL.

       6.      Enter the name of a database connection.
 
 

liveCache Alert Monitor

liveCache Alert Monitor used to identify memory problems in good time, to check the security of your liveCache database instance and to monitor performance.

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.

Integration

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.

     CCMS Monitoring
If Alert Monitoring is not activated (for example, when accessing liveCache alert monitor in the liveCache assistant), you should activate the alert monitor and add the liveCache connection to the liveCache alert monitor (see below: Managing 
liveCache Connection in the liveCache Alert Monitor)
Choose
SAP CCMS Monitor Templates for Optional Components ® MaxDB Monitoring ® liveCache in CCMS Monitoring
 

Nodes

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

 

Colors of the Alerts

     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.

 

Tuesday, August 3, 2010

Increasing liveCache Performance

 

􀂄 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

 

Configuration Parameters for liveCache 7.4

􀁺

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 liveCache
 

Note : 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.

 

SAP APO liveCache Monitoring

 

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/OFF

A 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.

 

SAP APO CIF Monitoring

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

A queue that is being processed can show a number of statuses. The collector checks if a queue has a failure status, in which case a red alert is generated.
 

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.

 

 

Tuesday, November 18, 2008

LiveCache operation modes


There are three liveCache operating modes:
􀂋OFFLINE: No liveCache kernel processes are running, memory areas (caches) are not
allocated. No user can use liveCache .
􀂋ADMIN: The liveCache kernel is active, but caches are not yet synchronized with the volumes. Users cannot connect to the liveCache. Only the liveCache administration user can connect and perform administrative tasks like restoring the database.
􀂋ONLINE: The liveCache kernel is active and data and log information is synchronized between caches and volumes. Users can connect to the liveCache.

Monday, October 27, 2008

Livecache Architecture




􀂄 ABAP Programs and the APO optimizers use native SQL for communicating through the standard SAP DB interface to liveCache. liveCache has an SQL interface that is used to
communicate with the SAP instances. With native SQL, ABAP programs call stored procedures in the liveCache that point to (LCA) routines written in C++. An SQL class provides SQL methods to access the SQL data through the LCA routines.

􀂄 The LCA routines are part of a dynamic link library that runs in the process context of the
liveCache instance. In the Windows NT implementation of liveCache, LCA routines and their
interface are registered in the Windows NT Registry. For the Unix implementation, a registry
file is provided by liveCache. A persistent C++ class provides the LCA routines with access to
the corresponding Object Management System (OMS) data that is stored in the liveCache.

􀂄 LCA Routines in APO are delivered in DLL libraries as SAPXXX.DLL and SAPXXX.LST on NT or as shared libraries SAPXXX.ISO and SAPXXX.LST on UNIX . The application specific
knowledge is built into these LCA routines based on the concept of object orientation.

􀂄 liveCache is a hybrid of a relational and object-oriented database
􀂄 The relational part of the liveCache is available as the open source data base SAP DB (see http://www.sapdb.org/)

􀂄 The SQL part as well as the OMS part of the liveCache are based on the same DBMS basis
functionality which supplies services as for instance transaction management, logging, device handling and caching mechanisms

􀂄 Object and SQL data are stored on common devices
􀂄 All liveCache data is stored in the caches as well as on disks in 8 KB blocks called pages.

􀂄 liveCache stores the OMS objects in page chains, the pages in the chain being linked by
pointers. SQL table data are stored in the B*trees. SQL and OMS data reside together in the data cache and the data devices of the liveCache.

􀂄 liveCache, similar to the standard SAP RDBMS, can be administered within the SAP system.
The SAP transaction LC10 makes it possible to monitor, configure and administer liveCache.

􀂄 The LC10 applies the Database Manager CLI (DBMCLI) to administer the liveCache. Therefore, it is obvious that all functionalities of an SAP System are still available without the LC10 and could also be performed with the „native“ data base administration tool DBMCLI.

􀂄 In addition to the DBMCLI the administration tool DBMGUI is available, which is a graphical
user interface to the liveCache management client tool DBMCLI.

􀂄 While the DBMGUI works only on Windows NT/2000, running the WEB DBM requires only an internet browser and the DBM Web Server which can be installed anywhere in the net.

􀂄 DBMCLI, DBMGUI and WEB DBM should not be used for starting or stopping the liveCache,
even if LC10 itself calls DBMCLI for starting or stopping the liveCache. They should only be used for changing liveCache parameters, defining backup media and for liveCache monitoring. That is because the LC10 runs in addition to starting, stopping and initializing application specific reports. Moreover, it registers the LCA routines each time the liveCache is started.

The liveCache can be administered by
􀂄 Transaction LC10 in the SAPGUI
􀂄 Database Manager CLI (DBMCLI) command line interface
􀂄 Database Manager GUI (DBMGUI) graphical user interface for Windows NT/2000 only
􀂄 Web Database Manager (WEB DBM)

What is Livecache ? (LC10)




Why the Livecache has been developed ?


􀂄 For the development of the Advanced Planning and Optimization (APO) component a database system was needed which allows fast access to data organized in a complex network.

􀂄 Applying conventional relational database management systems as data sources for the APO showed a poor performance since disk I/O and the non-appropriate data description in the relational schema limited the performance.



􀂄 To read data from an application buffer which is in the same address space as the application
takes about 0.1ms. Reading data from a database takes about 1ms if the corresponding record
is already in the database buffer and even 10 ms if the record must be read from a hard disk
before.

􀂄 Working with an application having a too small buffer to accommodate all required data causes a huge data traffic between application and database server.

􀂄 An additional problem of the traditional buffering is that after reading data into the application buffer they are still organized in a relational schema which is not appropriate to describe complex networks.

􀂄 To achieve a good performance for applications which require access to a large amount of data (i.e. APO) it is necessary to bring the application logic and the application data together in one address space. One possible solution could be to shift the application logic from the application server to the database server via stored procedures. However, this impairs the scalability of R/3. On the other hand one could shift all required data to the application server.
But this requires that each server is equipped with very large main memory. Furthermore, the
synchronization of the data changed on each server with the data stored in the database server is rather complicated.

􀂄 To overcome performance problems the liveCache was introduced which is a dedicated server tier for the main memory-based temporary storage of volatile shared data.

Monday, June 30, 2008

LiveCache Monitoring (LC10)

In a liveCache application (such as an APO system), you should not just analyze the application at regular intervals, but also liveCache itself, to detect and avoid bottlenecks. The following problems in the liveCache environment can cause bottlenecks:
· Unsuitable hardware
· Incorrectly configured memory areas
· Algorithm errors in the DB procedures or the liveCache kernel
· Unsuitable parameter settings
Use the functions of the Computing Center Management System (CCMS) in the SAP system to monitor liveCache. The CCMS provides you with the following tools:
· liveCache Assistant
· liveCache Alert Monitor

In the user menu, choose liveCache Assistant (transaction LC10).
Enter the name of the database connection. You can predefine the name of a database connection with a default value. This name appears when you start the liveCache Assistant for the first time. If you call the liveCache Assistant again in a database session, the name of the last used database connection is always displayed.
You can choose between the following functions:
· Integration
· liveCache: Monitoring
· liveCache: Console
· liveCache: Alert Monitor

Determining the liveCache Status

Name of the database connection
This name is displayed when transaction LC10 is first called. If transaction LC10 is called after this during a database session, the name of the last-used database connection is always displayed.

liveCache name
The physical name of the liveCache is a property of the liveCache.The liveCache name is the name of the database instance on the liveCache server. The liveCache name can vary from the name of the database connection.

liveCache server
The name of the liveCache server is a property of the liveCache.The name of the liveCache server is case-sensitive. You can also use the IP address of the liveCache server.You can change specifications for liveCache server using the liveCache integration.

liveCache version
The version of the software of the liveCache kernel is a property of the liveCache.

liveCache state
The current operational state of a liveCache is a property of the liveCache.
· Green: The liveCache is operational (operation state ONLINE) and users can log on.
· Yellow: The liveCache is only available for the administrator for administrative purposes (operation state ADMIN).
· Red: The liveCache is not operational (operation state OFFLINE).

Procedure
Use the Properties display in the liveCache Assistant.
Use the displays State and Installation in the liveCache Alert Monitor.
Related Posts Plugin for WordPress, Blogger...