We have added search box. Key in SAP issue keyword to search
TopBottom

Announcement: wanna exchange links? contact me at sapchatroom@gmail.com.
Showing posts with label Monitor. Show all posts
Showing posts with label Monitor. Show all posts

Communications Monitor in CCMS BASIS

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

You can use this monitor to monitor the communication within an SAP system, between different systems, or to external applications. The monitor consists of the following six subtrees:

Subtree

Description and Additional Information

Gateway Service

Interface that enables communication between SAP R/2, ABAP, and external applications using the CPI-C protocol.

See Structure linkSAP Gateway

ALE

Technology for creating and operating distributed applications that ensures a distributed and integrated SAP installation; it includes a controlled exchange of messages with consistent data retention on loosely connected SAP application systems.

See Structure linkCentral Monitoring with the ALE CCMS Monitor

LDAP Directory Services

Access requests from SAP systems to a directory server; the accesses are performed using the Structure linkLDAP Connector.

See Newly Added Monitoring Functions in the Alert Monitor

SAPConnect

RFC interface for the integration of external communication into the SAP system with which external manufacturers connect their communication servers to the SAP system.

See Structure linkAlert Monitor for SAPconnect and SAPphone

System Log Messages

Recording of errors and events in the SAP system

See Communication subtree of the Syslog Monitor

Transactional RFC and Queued RFC

Function calls between systems; the call is only executed once in the target system, and either all or no calls of a Logical Unit of Work (LUW) are performed; queued RFC also guarantees the chronological processing of RFCs

See Transactional RFC and Queued RFC Monitor

Features

To obtain information about a particular monitoring tree element, select the MTE and choose F1. The system displays a short description of the node. To see a detailed description of the node, choose Long Text.

Activities

To start the monitor, follow the procedure below:

...

1. Start the Alert Monitor using transaction RZ20 or choose CCMS ®Control/Monitoring ® Alert Monitor.

2. On the CCMS Monitor Sets screen, expand the SAP CCMS Monitor Templates set.

3. Start the Communications monitor from the list by double-clicking it.



Keyword: BASIS
Title : Communications Monitor in CCMS BASIS

Filesystems Monitor in CCMS

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

This monitor displays a section of the Operating System Monitor, which displays all of the values collected by the operating system collector SAPOSCOL. You can use this monitor to monitor application servers and host systems of your choice and to check whether there is still enough free disk space available. The values are collected by the Structure linkoperating system collector SAPOSCOL. You can also monitor this data with the Structure linkoperating system monitor, which is assigned as the analysis method for most of the nodes of this monitor.

This graphic is explained in the accompanying text

Prerequisites

To be able to display operating system data for a particular server with this monitor, the operating system collector SAPOSCOL must be installed on that server (see Structure linkInstalling the Operating System Collector SAPOSCOL).

Features

The monitor contains the following monitoring tree elements (MTEs):

MTE Name
(MTE Class)

Meaning

Name
(FilesystemName)

Name of the file system

Freespace
(FilesystemFreeSpace)

Free disk space in the file system

Percentage_Used
(FilesystemPercentageUsed)

Usage of the available storage space for the file system as a percentage

Note

You can explicitly exclude file systems from the operating system collector monitoring. For more information, see Structure linkMonitoring Operating System Data with CCMS Agents.

Activities

To start the monitor, follow the procedure below:

...

1. Start the Alert Monitor using transaction RZ20 or choose CCMS ® Control/Monitoring ® Alert Monitor.

2. On the CCMS Monitor Sets screen, expand the SAP CCMS Monitor Templates set.

3. Start the Filesystems monitor from the list by double clicking it.



Keyword: BASIS
Title : Filesystems Monitor in CCMS

Transactional RFC and Queued RFC Monitor in CCMS

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

Transactional RFC and Structure linkqueued RFC are variants of the Remote Function Call that make the data transfer between different systems more reliable and more secure.

Transactional RFC guarantees the following attributes:

· The call is executed exactly once in the target system.

· Calls that belong to a Logical Unit of Work (LUW) are either completely executed, or not executed at all.

If the target system is not available when the call is made, the call remains in the local wait queue. The calling dialog program can, however, proceed. If the target system does not become active within a certain amount of time, the call is scheduled as a background job.

Although tRFC significantly improves the reliability of the data transfer, it also has disadvantages. This method does not ensure that the sequence of LUWs specified in the application is observed. However, there is a guarantee that all LUWs will be transferred at some point.

Queued RFC (qRFC with Outbound Queue)

To offset this disadvantage, a serialization of tRFC is performed using wait queues. It is called queued RFC (qRFC). With this serialization, an outbound queue for tRFC was created, which is therefore referred to as qRFC with outbound queue. The main features of qRFC are as follows:

· A LUW is only transferred if it has no predecessor (in reference to the sequence defined in the applications) in the participating queues. After a qRFC transaction is executed, the system attempts to start the next qRFC transaction in the sequence from the queue.

· A queue name and a queue counter are required fore each qRFC transaction for queue administration. Each tRFC call that is to be processed chronologically is assigned a queue name determined by the application.

qRFC with Inbound Queue

Serialization of the incoming RFC calls from other systems is also possible. This ensures that incoming calls are always executed in the order of their arrival. This serialization of incoming calls also limits the maximum load on the target server caused by RFC.

Monitoring with the Alert Monitor

Using the Transactional RFC and Queued RFC subtree, you can quickly detect errors and blocked queues (in the context of transactional RFC and queued RFCs). The corresponding special monitors with which you can quickly eliminate the cause of the error are set as analysis methods. The subtree is in the Communications monitor of the SAP CCMS Monitor Templates monitor set.

Prerequisites

You have performed the setting up of the monitoring of qRFC calls.

Features

This graphic is explained in the accompanying text

The monitor contains the following monitoring tree elements (MTEs):

MTE Name
(MTE Class)

Meaning

ARFCSSTATE: Outbound tRFC Calls
(CCMS_tRFC_Outbound_Tbl)

Monitoring object with information about the LUWs and tRFC calls that are waiting to be executed on their target system or on an external component.

Calls w/ Communication Errors – CPICERR
(CCMS_tRFC_qRFC_CPIC_Errors)

Number of tRFC calls that were not executed due to problems creating the connection or the communication with the target system or an external component; depending on the settings (transaction SM59), the attempt may be repeated a number of times

Calls w/ Execution Errors – SYSFAIL
(CCMS_tRFC_qRFC_SYSFAIL_Errors)

Number of tRFC calls that could not be executed due to a problem with the execution in the target system or an external component

Calls w/o Server Resources – SYSLOAD
(CCMS_tRFC_qRFC_SYSLOAD_Status)

Number of tRFC and qRFC calls with outbound queue with status SYSLOAD; these are calls that could not be executed due to a lack of resources in the target system

ARFCSSTATE: Inbound tRFC/qRFC Calls
(CCMS_tRFC_qRFC_Inbound_TIDs)

Monitoring object with information about tRFC and qRFC calls that are waiting to be executed in this system; after they have been executed, they are deleted from table ARFCRSTATE

Total Calls
(CCMS_qRFC_Inbound_Total)

Number of tRFC and qRFC calls that are waiting to be executed in this system and are therefore stored in table ARFCRSTATE

Outbound Queues
(CCMS_qRFC_Outbound_
Queues_Summary)

Subtrees that contain the log messages of the outbound qRFC calls to external systems; these messages are sorted by the different queue groups: there is a monitoring object for each group with the name Outbound Queues

Inbound Queues
(CCMS_qRFC_Inbound_
Queues_Summary)

Subtrees that contain the log messages of the inbound qRFC calls from external systems; these messages are sorted by the different queue groups: there is a monitoring object for each group with the name Inbound Queues

Blocked Queues: Client
(_MSC_)

Log messages for the queues of an application, sorted by the different clients; the log messages contain the error messages that are returned during the qRFC call

The following statuses are immediately identified as “blocking”:

· CPICERROR (for Inbound/Outbound, error text available)

· SYSFAIL (for Inbound/Outbound, error text available)

· STOP (for Inbound/Outbound, no error text)

· ANORETRY (for Inbound/Outbound, error text available)

· WAITSTOP (for Inbound/Outbound, error text available)

· ARETRY (for Inbound/Outbound, error text available)

· RETRY (always for inbound, for outbound as of qRFC version 6.10.040, error text available)

· SYSLOAD (for outbound, up to qRFC version 6.10.033, no error text)

The following statuses are identified as “blocking” if they remain unchanged for longer than 30 minutes:

· READY (for inbound/outbound, no error text)

· RUNNING (for inbound/outbound, no error text)

· WAITUPDA (for outbound, no error text)

· EXECUTED (for inbound/outbound, no error text)

Note

For information about the possible statuses, see the Structure linkAppendix.

Queues not processed: Age Alerts
(_Age_Log)

Log messages for the queues of an application; the queues have not been processed for longer than the time defined in the associated threshold value (by default, seven days)

QIN Schedulers: Errors
(CCMS_qRFC_QIN_Scheduler_Object)

Monitoring object that contains information about the status of the QIN scheduler; the QIN scheduler controls the processing of incoming tRFC and qRFC calls within a client (see SAP Note 396007)

QOUT Schedulers: Errors
(CCMS_qRFC_QOUT_Scheduler_Object)

Monitoring object that contains information about the status of the QOUT scheduler; the QOUT scheduler limits the maximum number of parallel tRFC and qRFC connections to an RFC destination (see SAP Note 400330)

QIN Scheduler Error: All Clients
(CCMS_qRFC_QIN_Sched_Log)

Log messages with error messages for the QIN schedulers of all clients; an alert here indicates that the system could not process an incoming RFC call due to a communication or execution error

QIN Unregistered Queues: All Clients:
(CCMS_qRFC_QIN_Unreg_Log)

Log messages with error messages for the QIN schedulers of all clients; an alert here indicates that the scheduler found an RFC call with a non-registered queue

QOUT Scheduler Error: All Clients
(CCMS_qRFC_QOUT_Sched_Log)

Log messages from communication and system errors for the QOUT schedulers of all clients

Activities

To start the monitor, follow the procedure below:

...

1. Start the Alert Monitor using transaction RZ20 or choose CCMS ®Control/Monitoring ®Alert Monitor.

2. On the CCMS Monitor Sets screen, expand the SAP CCMS Monitor Templates set.

3. Start the Communications monitor from the list by double-clicking it.

4. Expand the Transactional RFC and Queued RFC subtree.

Procedure if an Alert Is Triggered

MTE

Procedure

ARFCSSTATE: Outbound tRFC Calls

The transaction Transactional RFC (SM58) is assigned as analysis method to all MTEs of this monitoring object. This tool lists only those transactional RFCs that could not be carried out successfully or that had to be planned as batch jobs.

Calls w/Communication Errors - CPICERR

Errors often occur in this attribute when an instance is shut down for maintenance. Once the instance is available again, the calls are automatically processed.

If this is not the case, you should check the RFC connection using the Display and Maintain RFC Destinations transaction (SM59).

Calls w/ Execution Errors - SYSFAIL

Errors in the execution of RFC calls are often caused by errors in the programs. These errors must therefore usually be individually processed.

Calls w/o Server Resources - SYSLOAD

RFC calls with the status SYSLOAD are automatically scheduled in a job. For more information about SYSLOAD status, see SAP Note 319860.

ARFCSSTATE: Inbound tRFC/qRFC Calls

For information about possible statuses and problems for table ARFCRSTATE, see SAP Notes 378903 and 366869.

Outbound Queues
Inbound Queues

Start the assigned analysis method. For the MTEs of this monitoring object, this is transaction SMQ1 or SMQ2 (qRFC Monitor).

QIN Schedulers: Errors
QOUT Schedulers: Errors

Start the assigned analysis method. For the MTEs of this monitoring object, this is transaction SMQR or SMQS (QIN/QOUT Scheduler).

See also:

Monitoring qRFC and tRFC Calls



Keyword: BASIS
Title : Transactional RFC and Queued RFC Monitor in CCMS

Buffers Monitor in CCMS BASIS

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

You can use this monitor to check the utilization of the SAP buffer, and its hit and swap rates. For a general introduction to this topic, see Structure linkSAP buffers.

This graphic is explained in the accompanying text

Features

This monitor contains values for the following SAP buffers, sorted by application server:

MTE Name
(Prefix of the MTE Class)

Additional Names of the Buffer

Contents of the Buffer

Program
(R3BufferProgram)

ABAP buffer
PXA buffer

Compiled SAP programs

GenericKey
(R3BufferGenericKey)

Generic keys

Wholly or partly buffered database tables

SingleRecord
(R3BufferSingleRecord)

Single record buffer.

Individual records from utilized database tables

Screen
(R3BufferScreen)

Dynpro buffer
Presentation buffer

Screen pages from ABAP programs

CUA
(R3BufferCUA)

Menu buffer

Menus and pushbuttons from ABAP screen pages

TableDefinition
(R3BufferTableDefinition)

TTAB buffer

Table definitions from the ABAP repository

FieldDescription
(R3BufferFieldDescription)

FTAB buffer

Field descriptions from the ABAP repository

InitialRecords
(R3BufferInitialRecords)

IREC buffer

Initial record layout (initial values for the fields of a database segment) of a table

ShortNameTAB
(R3BufferShortNameTAB)

SNTAB buffer

Combination of the TTAB and FTAB buffers

The monitor displays the following values for each buffer type:

MTE Name
(Suffix of the MTE Class)

Description

DirectoryUsed
(DirectoryUsed)

Percentage usage of the directory (number of entries)

SpaceUsed
(SpaceUsed)

Percentage usage of the buffer storage

HitRatio
(HitRatio)

Percentage of the database queries that were met from the buffer (hit rate) and did not have to be passed on to the database

Swap
(Swap)

Swaps due to a full buffer per minute

Note

The MTE class of a monitoring attribute consists of the prefix of the MTE class of the relevant buffer and the corresponding suffix (such as R3BufferProgramDirectoryUsed).

Activities

To start the monitor, follow the procedure below:

...

1. Start the Alert Monitor using transaction RZ20 or choose CCMS ® Control/Monitoring ® Alert Monitor.

2. On the CCMS Monitor Sets screen, expand the SAP CCMS Monitor Templates set.

3. Start the Buffers monitor from the list by double-clicking it.

Procedure if Buffer Is Full or Swap Rate Is too High

SAP buffers use intelligent procedures to replace old buffered data with new requested data. Allocating too much space to a buffer can also lead to other problems (operating system paging) without significantly increasing the hit rate (buffer quality).

The goal of the buffer setting is therefore to have a sufficiently large buffer to maintain a high rate, and to do so with a low swap rate and a minimal effect on operating system paging.

Here are a few guidelines about when certain SAP buffers must be increased in size:

· Increase the size of the buffer if the swap rate (the replacing of buffer objects) is very high, or if the hit rate is below the target threshold value.

· Increase the size of the buffer if alerts are frequently triggered in the associated node. Frequent alerts indicate that the buffer exchange mechanism cannot create enough free space for effective buffer operation.

· As far as possible, you should always increase the amount of space available for the GenericKey buffer if it becomes full.

· Increase the size of the program buffer if the hit rate becomes too low, or the swaps become too frequent. Development systems require a larger program buffer than normal systems. It is, however, almost impossible to avoid swapping in a development system.

· If undesired side effects occur after increasing the size of the SAP buffer, monitor the operating system paging for significant increase and the SAP Memory Management subtree (in the Entire Systemmonitor) for new alerts.

Procedure if Hit Rate Is Too Low

Hit rate alerts indicate that bad buffer performance is damaging the performance of the application server. As the buffer is of great importance for good system performance, you should investigate the Structure linkbuffer quality problem in great detail and take corrective measures.

In general, bad buffer quality means that the buffer is too small. If a buffer is too small, it is more likely that requested objects (such as table entries or programs) are not found in the buffer. This leads to a lower hit rate, and, if the buffer is already full, to increased swapping. The more often requested objects replace older objects in the buffer, the more swapping takes place.

To improve the hit rate, you should increase the size of the buffer. You should ensure, however, that the buffer quality has not been reduced by a temporary problem: after a system or application server is started, all buffers perform badly, as the buffers must first be filled. The default setting for the monitoring architecture is therefore not to trigger any buffer alerts during the first 20 minutes of operation.

The performance of a program buffer can also be reduced if developers are working in the system or if objects are imported into the system using the ABAP transport system.

Note

With the exception of the SingleRecord buffer, the hit rate for buffers should always be above 95 percent if the buffers are large enough. The performance of the SingleRecord buffer can be regarded as good if the hit rate is between 80 and 90 percent.

Increasing the Size of SAP Buffers

To increase the size of a buffer, change the system profile parameters that specify the size of the buffer. For some buffers, you can set the size of the buffer and the maximum number of entries in separate parameters. For other buffers, there is only a size parameter, and the system automatically calculates the required system parameters.

Name of the Buffer

Responsible System Parameters

Typical Size/Number of Entries

Program

Size: abap/buffersize [KB]
Number of entries is determined by size

240,000 – 400,000 KB

GenericKey

Size: zcsa/table_buffer_area [Bytes]
Entries: zcsa/db_max_buftab

50 MB
10,000 entries

SingleRecord

Size: rtbb/buffer_length [KB]
Entries: rtbb/max_tables

30,000 KB

Screen

Size: zcsa/presentation_buffer_area [Bytes]
Number of entries is determined by size

150 - 200 MB

CUA

Size: rsdb/cua/buffersize [KB]
Number of entries is determined by size

3,000 -6,000 KB

TableDefinition

Size is determined by the number of entries
Entries: rsdb/ntab/entrycount

30,000 entries

FieldDescription

Size: rsdb/ntab/ftabsize [KB]
Entries: 2 * rsdb/ntab/entrycount + 1

20,000 -30,000 KB

InitialRecords

Size: rsdb/ntab/irbdsize [KB]
Entries: 2 * rsdb/ntab/entrycount + 1

4,000 KB

ShortNameTAB

Size: rsdb/ntab/sntabsize [KB]
Entries: 2 * rsdb/ntab/entrycount + 1

2,500 KB

Note

For more information about setting buffer sizes, see Structure linkTypical Parameter Settings for SAP Buffers. See also SAP Note 0103747.

It is often not possible to set the size of a buffer so that it never becomes full. Above a certain size, which is greatly dependent on the hardware and the operating system, the performance advantage of the buffer is canceled out by increased operating system paging. A buffer that occupies too much main memory forces the operating system to perform expensive paging.

The goal of buffer management is to assign the buffers enough memory so that they achieve a high hit rate with low swap rates, without causing much operating system paging. After each change of the buffer size, you should monitor paging and memory usage to ensure that the new buffer size does not cause any other performance problems.

As a rule of thumb, we recommend that you assign space to the SAP buffers rather than the database buffers, if main memory becomes limited. In SAP systems, every application server has its own buffer. These buffers should not be confused with the buffers of the SAP database system.



Keyword: BASIS
Title : Buffers Monitor in CCMS BASIS

Availability and Performance Overview Monitor (CCMS)

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

With this monitor, you can perform availability monitoring for selected ABAP and Java systems and their instances. For ABAP systems, you can also monitor the availability of logon groups, and the most important performance attributes for the status of the dialog system are also displayed for the monitored ABAP instances.

For more information about selecting systems and application servers for monitoring, see Configuring Availability Monitoring.

Description of the Tree Structure of the Monitor

This graphic is explained in the accompanying text

This graphic is explained in the accompanying text

Prerequisites

Availability monitoring uses the standalone agent CCMSPING, you must therefore have performed the installation of the availability agent CCMSPING.

Features

Availability of Systems

For availability monitoring, CCMSPING checks the availability of the message server of the corresponding system. A system is regarded as available if the responsible message server responds to the availability agent’s query and at least one application server is registered as active with the message server. The system availability is monitored by one or more CCMSPING agents, depending on the configuration of your availability monitoring.

MTE Name
(MTE Class)

Meaning

ABAP: Checked by
(Availability_SysPercent_ABAP)

Availability of the system according to information from the responsible ABAP message server; checked by specified CCMSPING

Java: Checked by
(Availability_SysPercent_J2EE)

Availability of the system according to information from the responsible Java message server; checked by specified CCMSPING

Release/Description
(Availability_Release)

Additional information about the monitored system

System Configuration
(Availability_SysConfig)

Note

In the case of ABAP+Java systems, if you have specified both message servers in the configuration of the availability monitoring, both availability values are displayed here.

Availability of ABAP Instances

The monitor displays the following MTEs for the monitored ABAP instances:

MTE Name
(MTE Class)

Meaning

Instance Availability
(Availability_InstPercent)

Percentage value of the availability (reported active to the message server), by default averaged over the last 15 minutes

Logon-Check Availability
(Availability_RFCPercent)

Percentage value of the availability (server responds to RFC call), by default averaged over the last 15 minutes

Logon-Check: RFC Error Message
(Availability_RFCError)

Details for the Logon-Check Availability message

Server Type
(Availability_Servertype)

Type of the server; in this case: ABAP Application Server

Dialog Response Time
(Availability_DiaRespTime)

Average response time for processing a dialog step

Standardized Response Time
(Availability_StdRespTime)

As Dialog Response Time, but for a predefined standard transaction

Users Logged On
(Availability_UsersLoggedOn)

Number of users that are logged on to an application server

Note

For more information about the performance values for the dialog system, see Dialog Overview Monitor.

Availability of Java Instances

Java instances are displayed under different names, depending on which message server (ABAP or Java) is used for the availability monitoring of the system:

· In the case of monitoring purely using the ABAP message server, Java instances are displayed under the name of the assigned ABAP instance with the suffix :Java (such as: Host1_C11_00:Java). This is only possible if the relevant system is a double-stack system).

· In the case of monitoring using the Java message server, Java instances of the relevant system are displayed under their server ID with the prefix J2EE (such as J2EE7305550). This is also the case, if the monitoring is performed using both message servers.

The monitor displays the following MTEs for the monitored Java instances:

MTE Name
(MTE Class)

Meaning

Instance Availability
(Availability_InstPercent)

Percentage value of the availability (reported active to the message server), by default averaged over the last 15 minutes

Server Type
(Availability_Servertype)

Type of the server; in this case: J2EE Application Server

Host
(Availability_DSJ2EEHost)

Additional information about the Java instance

HTTP Port
(Availability_DSJ2EEPort)

Available J2EE Server Nodes
(Availability_DSJ2EELB)

Availability of Logon Groups

In the case of ABAP systems, you can monitor logon groups for their availability. A logon group is regarded as available, if it is possible to log on to the application server with the best dialog system quality in this group. In addition to the availability of the logon groups in the last 15 minutes, the system also displays the application server of the group with the best dialog system quality in the monitor.

Analysis Method

If you double-click a node in this monitor, you start the analysis method Configure Availability and Performance Overview. (see Configuring Availability Monitoring).

Activities

To start the monitor, follow the procedure below:

...

1. Start the Alert Monitor using transaction RZ20 or choose CCMS ® Control/Monitoring ® Alert Monitor.

2. On the CCMS Monitor Sets screen, expand the SAP CCMS Monitor Templates set.

3. Start the Availability and Performance Overview monitor from the list by double-clicking it.



Keyword: BASIS
Title : Availability and Performance Overview Monitor (CCMS)

T r a n s l a t e to your language