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 Basis. Show all posts
Showing posts with label Basis. 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

Displaying Report Properties BASIS

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

Displaying Report Properties

Use

You can use Central Performance History Reports (CPH) to display selected performance values of the CPH directly or as a job. When you do this, the report itself (for example, when executed on the screen) does not contain the complete header data of the report ‑ such as the settings of the Report Definition or the execution time of the report.

You can find this information in the report properties. You can also edit the report properties to add your own remarks, and save the properties as a local file. No changes to the text have any effect on any function of the CPH.

Procedure

...

1. You can display the report properties from several functions:

¡ In the Report Browser, choose the desired report by double clicking it, and choose the Report Details pushbutton.

¡ Execute a report directly on the screen (see Scheduling and Executing a Report), and choose the Report Detailspushbutton.

2. In both cases, a screen appears on which the report properties are displayed. The screen has the following structure:

This graphic is explained in the accompanying text

3. To save the report properties as a local file, choose Save as a Local File (This graphic is explained in the accompanying text).

This graphic is explained in the accompanying text Central Performance History of the Monitoring Architecture start page



Keyword: BASIS
Title : Displaying Report Properties BASIS

Scheduling and Executing a Report BASIS

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

A report displays Central Performance History (CPH) data. The prerequisite for the execution of a report is that a suitable report definition exists (see Creating a Report Definition). You can execute a report on the basis of a definition of this type; either directly or scheduled as a periodic job.

When you execute a report, you define the report properties that are not determined by the report definition. You define the following properties when you execute the report:

· Period to which the report should refer

· File format in which the report should be output (file type, direct output to the screen or to the database)

· Layout of the report

· Settings that allow the report to be executed regularly as a job

Procedure

Executing and Scheduling a Report

...

1. You can execute a report from several functions:

¡ In the overview screen of the CPH (transaction RZ23N), choose, in the Data Output and Reporting group box, the Execute Reports pushbutton.

¡ Choose CCMS ® Configuration ® Alert Monitor, or call transaction RZ21. The Monitoring: Properties and Methods screen appears. Choose Technical Infrastructure ® Central Perf. History ® Execute Reports.

¡ You can display a standard report for the selected MTE classes directly in the Detail Data for Monitoring Attributes screen of the Alert Monitor (see Display Detail Data and Tailor Display). When you do this, daily data with an hourly resolution is used. To do this, choose Central Perf. History ® Display as Report.

2. In all cases, the Central Performance History Report Execution screen appears. The screen consists of two parts. In the left part of the screen, you define all settings for a manual or automatic report execution. This part of the screen has the following structure:

This graphic is explained in the accompanying text

3. Enter the desired definition in the input field Report Definition to be Executed.

4. In the Time Interval of the Report group box, enter the period to which the report should relate. The indicators have the following meaning:

Indicator

Description

Last

Time period that stretches for a defined period into the past from the day of the report execution (such as Last 7 days or Last 3 Months); the current time unit is not displayed

Maximum Available Data

Smallest time interval that includes all time periods in which data exists for at least one of the MTE classes of the report

Minimum Available Data

Smallest time interval that includes all time periods in which data exists for all of the MTE classes of the report

Fixed Time Interval

Time interval that is defined using a start date and an end date; a fixed time interval is only useful for a direct (single) report execution.

Example

This graphic is explained in the accompanying text

5. In the Report Output Target group box, enter the format in which the report is to be displayed. The indicators have the following meaning:

Indicator

Description

Output to the Screen

The report is displayed on the screen and is not saved. This is only possible for direct execution of the report.

Save in Report DB

The report is saved in a separate database. You can display the report any time in the Report Browser.

Save as ASCII file

The report is saved as an ASCII file. As an appendix to the report itself, the file contains the report properties.

Save as Microsoft Excel file

The report is saved as a Microsoft Excel file. As an appendix to the report itself, the file contains the report properties.

6. Enter the desired display mode. The two possible values have the following meaning:

Value

Description

one dimensional

For each row, the values for one point in time are displayed; a separate column is displayed for each group of the report

two dimensional

For each row, the values for a day are displayed (and therefore, depending on the resolution, between 1 and 1440 values). A separate row is displayed for each group of the report.

7. If you want to save the report as a file, specify where and under which name you want to save the file in the Filename and Path of the ASCII/Excel File/Name of the DB Entry group box.

If you want to save the report to the report database, specify in this group box the name under which the report is to be saved in the report database. If you do not specify a name, the name of the report definition used is used as the name.

8. If you want to execute the report directly, you can choose whether the file is to be saved on the local computer or on the current application server. If the report is scheduled as a job, the file can only be saved on an application server.

Note

Choose the Job Settings pushbutton to specify the application server on which the job is to run for automatic report execution. Use an application server with as high availability as possible for this. If the report is saved as a file, the report is saved on this application server. If you do not specify a path, the file is saved in the home directory of the application server (profile parameter DIR_HOME).

To avoid the files for older reports being overwritten if the report is executed repeatedly, enter a question mark (?) (such as Report?.xls). When the file is saved, the question mark is replaced by the current date (such as Report20021031.xls).

9. If the report is to be regularly executed as a job, choose the Execute Periodically pushbutton. The Schedule Report group box is now available. You can specify the first execution and the period for job execution in this group box. To schedule the job, choose Schedule (This graphic is explained in the accompanying text).

10. If you want to execute the report directly, choose Execute Directly.

11. If you want to execute the report immediately in the background, choose Execute in Background.

Displaying and Editing the Report Settings that Are Automatically Executed

Reports that are executed in the background (see above) are displayed in the right part of the screen in the Active Automatic Report Executions in the Background table. All settings that you specified during the scheduling of this report are displayed in the columns of this table.

To change the settings, choose the desired scheduling by double clicking it, make the desired changes, and reschedule it by choosing Schedule (This graphic is explained in the accompanying text).

Note

Note that the report definition is entered twice if you follow this procedure. If you do not want this, select the scheduling that you want to delete and choose Delete Selected Reporting Jobs (This graphic is explained in the accompanying text).

This graphic is explained in the accompanying text Central Performance History of the Monitoring Architecture start page



Keyword: BASIS
Title : Scheduling and Executing a Report BASIS

Update Repositories(CCMS) BASIS

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

Purpose

If background dispatching is activated on the corresponding system, the local SCR is automatically updated at every system start. You can also update an SCR at any time. You have the following options:

  • You can update the local SCR (see
  • Updating the Local Repository).
  • You can update the data for the local system in the central repository (see
  • Updating the Central Repository).
  • You can update the data for a subordinate system from the system of the central repository (see
  • Requesting an Update of the Repository).

This graphic is explained in the accompanying text



Keyword: BASIS
Title : Update Repositories(CCMS) BASIS

Basis Displaying the Technical View: Status Autoreaction CCMS

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

In the monitoring architecture, you can react automatically to an alert using auto-reaction methods. These methods are automatically started in the case of an alert and by default are executed in the system in which the alert occurs. Almost no assignments are made in the standard SAP system; however, there are several predefined auto-reaction methods in the monitoring architecture that you can assign to any MTE classes.

As of SAP Web Application Server 6.10, you can also define central auto-reaction methods. The auto-reaction methods are not started in the system, in which the alert occurs, but rather in the central monitoring system. In this way, it is possible for reactions to events that occur in monitored components to be performed immediately in a central location.

If problems occur during the execution of auto-reaction methods, it can be useful to check the status of the auto-reaction methods. You can find out the definition and runtime status of an MTE by choosing Display Details (This graphic is explained in the accompanying text). This method is very time-consuming for obtaining an overview of the auto-reaction methods for the MTEs of an entire monitor. The technical view Status Autoreaction exists as an alternative for this purpose.

In this technical view, you can also manually start the auto-reaction method for any MTE to which an auto-reaction method is assigned. To do this, choose the relevant MTE by double clicking it. This is especially useful during test phases.

Note

Note that when you start an auto-reaction method manually, it runs under your user name and therefore also under your authorizations. As the method runs under the SAPSYS user when it is started automatically, and this user has only very few authorizations, you can assume from a successful test with a manual start that the method will also run without problems during normal operation.

Procedure

To activate the Status Autoreaction technical view, follow the procedure below:

...

1. Choose CCMS ® Control/Monitoring ® Alert Monitor, or call transaction RZ20.

2. Expand the monitor set that contains the monitor that you require, and choose Load Monitor.

3. Choose Views ® Status Autoreaction. The alert tree now no longer displays the alert status and reported values, but information about the auto-reaction methods of the MTEs of the monitor.

This graphic is explained in the accompanying text

Result

The view displays the following information for the active monitor about the auto-reaction methods that are assigned to the individual MTEs:

· Assigned auto-reaction method

· Type of the auto-reaction method; depending on the definition of the method, the following types are possible:

Type

Description

[Central Autoreaction]

The method is defined as a central auto-reaction method.

[Running in Autoabap]

The method is executed in the dialog process.

[Running in Background]

The method is executed in the background process as a job.

[???]

The method type is not yet known; this type is only displayed for a short type after the method is created.

· Definition status of the method:

Type

Description

PRESET

The method has just been created; the properties of the method are still determined by the settings in the data supplier. After a maximum of five minutes, the system reads the current settings of the method from the active properties variant and the definition status is changed.

DBSET
CEN_SET
WPSET

The settings of the active properties variant are already included in the properties of the method in this status. However, as it is not in the CHECKED definition status, you should check whether the method is released as an auto-reaction method.

CHECKED

The method is released and can therefore be executed as a local auto-reaction method.

CEN_CHECKED

The method is released as a central auto-reaction method.

· Runtime status of the method:

Type

Description

Ready

The method is ready for the next execution; however, this is not yet due.

Run required

The method is to be executed, however the responsible dispatcher has not yet started the method.

Running

The method is currently running; the color of the corresponding attribute is yellow.

Error
Fatal Error

An error occurred during the last run of the method. The difference between the two statuses is that a method in the status Error is started again at the next scheduled run, a method in the status Fatal Error is not. A method in the status Fatal Error is only started again after a warm start of the monitoring segment (see Resetting the Segment to WARMUP Status). The color of the corresponding attribute is red.

Note

You can also reset the method status by selecting the corresponding MTE, choosing Display Details (This graphic is explained in the accompanying text), and, on the following screen, choosing Edit ® Method Status ® Reset ® Select Auto-Reaction Method.

Note

· The time specification after the runtime status shows the time since which the method has been in this status.

· The color of the nodes is not passed upward in the alert monitoring tree. Monitoring objects and summary nodes therefore always have the color Green.



Keyword: BASIS
Title : Basis Displaying the Technical View: Status Autoreaction CCMS

Basis Displaying the Technical View: Status Data Collector

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

Data suppliers deliver values that are displayed in the Alert Monitor. They each belong to the individual system components and create monitoring objects that report values to the monitoring architecture. These values are displayed in the monitor sets.

It can be useful to check the status of the data collection methods if problems occur in the monitoring architecture. You can find out the most important information about the assigned data collection methods on one hand by choosing Properties, if you choose the data collection method in the Methods tab page by double clicking it. On the other hand, you can find out the definition and runtime status of the data collection method of an MTE by choosing Display Details (This graphic is explained in the accompanying text)

This method is very time-consuming for obtaining an overview of the data collection methods and their status for the MTEs of an entire monitor. The technical view Status Data Collector exists as an alternative for this purpose.

In this technical view, you can also manually start the data collection method for any MTE to which a data collection method is assigned. To do this, choose the relevant MTE by double clicking it. This is useful, for example during test phases or for MTEs for which you require the current value, even if it is not yet time for the next start of the method.

Note

Note that when you start a data collection method manually, it runs under your user name and therefore also under your authorizations. As the method runs under the SAPSYS user when it is started automatically, and this user has only very few authorizations, you can assume from a successful test with a manual start that the method will also run without problems during normal operation.

Procedure

To activate the Status Data Collector technical view, follow the procedure below:

...

1. Choose CCMS ® Control/Monitoring ® Alert Monitor, or call transaction RZ20.

2. Expand the monitor set that contains the monitor that you require, and choose Load Monitor.

3. Choose Views ® Status Data Collector. The alert tree now no longer displays the alert status and reported values, but information about the data collection methods of the MTEs of the monitor.

This graphic is explained in the accompanying text

Result

The view displays the following information about the data collection methods that are assigned to the individual MTEs of the monitor:

· Assigned data collection method: If the MTE is assigned an active data supplier, the system will display in the corresponding column, as the active data suppliers are not defined in the monitoring architecture

· Type of the data collection method; depending on the definition of the method, the following types are possible:

Type

Description

[Running in agent]

The method is periodically executed in a Structure linkCCMS agent

[Running in Autoabap]

The method is executed periodically in the dialog process.

[Running in Background]

The method is periodically executed in the background process as a job.

[Kernel function]

The method is automatically executed in the C kernel.

[???]

The method type is not yet known; this type is only displayed for a short type after the method is created.

· Definition status of the method:

Type

Description

PRESET

The method has just been created; the properties of the method are still determined by the settings in the data supplier. After a maximum of five minutes, the system reads the current settings of the method from the active properties variant and changes the definition status.

DBSET
WPSET

The settings of the active properties variant are already included in the properties of the method in this status. However, as it is not in the CHECKED definition status, you should check whether the method is released as a data collection method.

CHECKED

The method is released and can therefore be executed.

CEN_CHECKED

The method is executed in a CCMS agent; as all settings for the method are set in the agent, do not change these settings manually.

· Runtime status of the method:

Type

Description

Ready

The method is ready for the next execution; however, this is not yet due.

Run required

The method is to be executed, however the responsible dispatcher has not yet started the method.

Running

The method is currently running; the color of the corresponding attribute is yellow.

Error
Fatal Error

An error occurred during the last run of the method. The difference between the two statuses is that a method in the status Error is started again at the next scheduled run, a method in the status Fatal Error is not. A method in the status Fatal Error is only started again after a warm start of the monitoring segment (see Resetting the Segment to WARMUP Status). The color of the corresponding attribute is red.

Note

You can also reset the method status by selecting the corresponding MTE, choosing Display Details (This graphic is explained in the accompanying text), and, on the following screen, choosing Edit ® Method Status ® Reset ® Select Data Collection Method.

Note

The time specification after the runtime status shows the time since which the method has been in this status.

· Frequency of the method call in seconds (Cycle):

Note

The color of the nodes is not passed upward in the alert monitoring tree. Monitoring objects and summary nodes therefore always have the color Green.



Keyword: BASIS
Title : Basis Displaying the Technical View: Status Data Collector

Basis Displaying the Technical View: Method Allocation

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

Use

The individual monitoring tree elements (MTEs) of the Alert Monitor are assigned methods. These methods determine the data collection of the MTEs (data collection methods) and the possible reactions to an alert in the MTE (auto-reaction and analysis methods). You can find out the assigned methods by selecting an MTE and choosing Properties. This method is very time-consuming for obtaining an overview of the assigned methods for the MTEs of an entire monitor. The technical view Method Allocation exists as an alternative for this purpose. This view displays the method assignments for the MTEs of the entire monitor:

· Assigned data collection method: If the MTE is assigned an active data supplier, the system will display in the corresponding column, as the active data suppliers are not defined in the monitoring architecture

· Assigned auto-reaction method

· Assigned analysis method

Note

· The nodes are always colored green in the technical view Method Allocation; as it contains no alert information.

· Summary nodes or monitoring objects can always be assigned methods; these assignments only take effect for the subordinate monitoring attributes, which can inherit their method assignment from the superordinate nodes.

· If no analysis or auto-reaction method is assigned to the MTE, is displayed in the corresponding column here.

Procedure

To activate the Central Method Allocation technical view, follow the procedure below:

...

1. Choose CCMS ® Control/Monitoring ® Alert Monitor, or call transaction RZ20.

2. Expand the monitor set that contains the monitor that you require, and choose Load Monitor.

3. Choose Views ® Method Allocation. The alert tree now no longer displays the alert status and reported values, but information about the methods assigned to the MTEs of the monitor.

This graphic is explained in the accompanying text



Keyword: BASIS
Title : Basis Displaying the Technical View: Method Allocation

Monitoring the Enqueue Service in CCMS BASIS

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

The enqueue service allows ABAP applications to lock data so that only they can use it. The locking of the data avoids parallel changes to the data, which would lead to data inconsistency. For more information, see Structure linkThe SAP Lock Concept (BC-CST-EQ).

There are two different trees in the monitoring infrastructure for monitoring the enqueue service:

· Enqueue monitor in the SAP CCMS Monitor Templates monitor set

This monitor includes a large number (see below) of monitoring values for the enqueue service. Since the monitor is supplied with values by an ABAP data collection method, the values are updated every five minutes.

· Enqueue subtree in the R3Services subtree of the Entire System Monitor (SAP CCMS Monitor Templates monitor set)

This subtree includes only the most important monitoring values for the enqueue service. Since the data is supplied by an active data supplier directly from the kernel, current data is reported immediately in the monitoring infrastructure.

Enqueue Monitor

This graphic is explained in the accompanying text

This graphic is explained in the accompanying text

Features

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

MTE Name
(MTE Class)

Meaning

Enqueue Server
(R3EnqueueStat)

Enqueue server that provides the enqueue service for the system

Enqueue Requests
(R3EnqueueStatEnqReq)

Number of lock requests

Enqueue Request Rejects
(R3EnqueueStatEnqRej)

Number of rejected lock requests

Enqueue Requests Errors
(R3EnqueueStatEnqErr)

Number of errors that occurred during lock requests

Dequeue Requests
(R3EnqueueStatDeqReq)

Number of release requests (DEQUEUE)(

Dequeue Requests Errors
(R3EnqueueStatDeqErr)

Number of errors that occurred when releasing locks

DequeueAll Requests
(R3EnqueueStatDeqAll)

Number of releases of all locks of an LUW (such as at the end of an LUW)

CleanUp Requests
(R3EnqueueStatCleanReq)

Number of releases of all locks of an application server (such as when the server is started or shut down)

Backup Requests
(R3EnqueueStatBackupReq)

Number of update calls for which locks were forwarded to the update. The update process receives the lock owner ID of the caller, the caller receives a new lock owner ID.

Reporting Requests
(R3EnqueueStatReportReq)

Number of operations for reading the lock table.

Owner Names
(R3EnqueueStatOwnerNames)

Maximum number of lock owner IDs that can be stored in the lock table. Lock owner IDs are assigned to a user context or to an update request.

Owner Names Peak Utilization
(R3EnqueueStatOwnerNamesPeak)

Maximum number of lock owners that have been stored simultaneously in the lock table.

Owner Names Actual Utilization
(R3EnqueueStatOwnerNamesUtil)

Current number of lock owners in the lock table

Granule Arguments
(R3EnqueueStatGranuleArg)

Maximum number of different lock arguments that the lock table can contain; locks of different owners or with different lock modes, but with the same lock argument occupy one entry

Granule Arguments Peak Utilization
(R3EnqueueStatGranuleArgPeak)

Maximum number of different lock arguments that have been stored simultaneously in the lock table.

Granule Arguments Actual Utilization
(R3EnqueueStatGranuleArgUtil)

Current number of different lock arguments in the lock table

Granule Entries
(R3EnqueueStatGranuleEntries)

Maximum number of elementary locks that the lock table can contain (each elementary lock occupies one entry)

Granule Entries Peak Utilization
(R3EnqueueStatGranuleEntriesPeak)

Maximum number of elementary locks that have been stored simultaneously in the lock table.

Granule Entries Actual Utilization
(R3EnqueueStatGranuleEntriesUtil)

Current number of elementary locks in the lock table

Update Queue Peak
(R3EnqueueStatUpdQuePeak)

Maximum number of open update requests with locks that has occurred so far

Update Queue Actual
(R3EnqueueStatUpdQueActual)

Current number of open update requests with locks

Total Lock Time
(R3EnqueueStatTotLockTime)

Total time spent in the critical path of the lock table for lock operations

Recent Lock Time (per minute)
(R3EnqueueStatLockTime)

Time spent in the critical path of the lock table for lock operations (in seconds per minute)

Total Lock Wait Time
(R3EnqueueStatTotLockWaitTime)

Total wait time of parallel processes before entering the critical path of the lock table

Recent Lock Wait Time (per minute)
(R3EnqueueStatLockWaitTime)

Wait time of parallel processes before entering the critical path of the lock table (in seconds per minute)

Total Server Time
(R3EnqueueStatTotServerTime)

Total time spent in the enqueue server

Recent Server Time (per minute)
(R3EnqueueStatServerTime)

Total time spent in the enqueue server (in seconds per minute)

Runtime of Data Collector
(R3EnqueueStatDataCol)

Node that is assigned to the data collection method; this is used to monitor the runtime of each data collection

Enqueue Clients

There is one instance with an enqueue service for each system ‑ this instance becomes the central instance of the system because it has this service. This monitoring object contains performance attributes for requests from the other instances to this service.

__
(R3EnqueueClient)

Instance name

EnqueueFreq
(R3EnqueueFreq)

Enqueue operations (logical data locks) per minutes that are coming from another instance to the central instance

Connection to Standalone Enqueue

If the system contains a Structure linkStandalone Enqueue Server, this subtree provides information about the connection to the application server of this standalone enqueue server.

__
(R3HAEnqueue)

Instance name

Description
(R3HAEnqueueText)

Version of the standalone enqueue server

Status
(R3HAEnqueueStatus)

Status of the connection of the instance to the standalone enqueue server

ReplicationStatus
(R3HAEnqueueReplicationStatus)

Together with an enqueue replication server, the standalone enqueue server forms a high-availability enqueue server. If a replication server is installed, its current status is displayed here.

ReplicaAvailability
(R3HAEnqueueReplicaAvailability)

Availability of the replication server. If the server is not installed, the node contains the value 0%.

Log
(R3HAEnqueueLog)

Messages of the standalone enqueue server

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 Enqueue Server monitor from the list by double-clicking it.

Enqueue Subtree in R3Services

This graphic is explained in the accompanying text

Features

The subtree contains the following MTEs:

MTE Name
(MTE Class)

Meaning

Enqueue
(R3Enqueue)

Enqueue service subtree

EnqueueClient
(R3EnqueueClient)

Subtree for the enqueue client; this exists on every instance

EnqueueFreq
(R3EnqueueFreq)

Enqueue operations (logical data locks) per minutes that are coming from another instance to the central instance

EnqueueServer
(R3EnqueueServer)

Subtree for the enqueue client; this only exists on the central instance

QueueLength
(R3EnqueueQueueLength)

Length of the enqueue queue as a percentage of its maximum length

ErrorsInWpENQ
(R3ErrorsInWpENQ)

Number of errors in the enqueue work processes since the monitoring segment was created (that is, since the application server was started)

ErrorFreqInWpENQ
(R3ErrorFreqInWpENQ)

Number of errors in the enqueue work processes per minute

EndedWpENQ
(R3EndedWpENQ)

Number of enqueue work processes terminated after an error; you can use the Process Overview (transaction SM50) to determine whether a work process should be restarted after an error

Utilization Owner Names
(R3EnqueueUtilOwner)

Current number of lock owners in the lock table as a percentage of the maximum number

Utilization Granule Arguments
(R3EnqueueUtilArguments)

Current number of different lock arguments in the lock table as a percentage of the maximum number

Utilization Granule Entries
(R3EnqueueUtilEntries)

Current number of elementary locks in the lock table as a percentage of the maximum number

Activities

To display the subtree, proceed as follows:

...

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 Entire System monitor from the list by double-clicking it, and expand the monitoring tree along the path ® ApplicationServer ® ® R3Services ® Enqueue.



Keyword: BASIS
Title : Monitoring the Enqueue Service in CCMS BASIS

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