Default Profile

Parameter Definition	Parameter Name in Profile
Name of the database host	SAPDBHOST
Name of the update server	rdisp/vbname
Name of the enqueue server	rdisp/enqname
Name of the server for handling background processing events	rdisp/btcname
Name of the computer on which the message server is running	rdisp/msname
Name of the TCP service under which the message server can be reached	rdisp/msserv
Name of the computer on which the SNA Gateway is running	rdisp/sna_gateway
Name of the TCP Service under which the SNA Gateway can be reached	rdisp/sna_gw_service

This profile is read first by R/3 instance in the system when it started.

You cannot choose a name for the default profile. It is always called DEFAULT.PFL

The default profile, like all other profiles, is located in the global profile directory of the SAP System. For example, under UNIX it is located in the directory

/usr/sap//SYS/profile ( = SAP System name). There is always one active default profile.

Default profiles are also called system profiles.

SAP Profiles

SAP profiles are operating system files that contain instance setup information. SAP Systems can consist of one or more instances. Individual setup parameters can be customized to the requirements of each instance. These individual parameters allow you to configure

• The runtime environment of the instance (resources such as main memory size, shared memory, roll size)
• Which services the instance has available (work processes)
• Where other services can be found (database host).

SAP profiles are stored in a special file directory. This directory can be made accessible from all hosts depending on current needs:

UNIX systems : /usr/sap//SYS/profile

Windows NT systems: \sapmnt\sysprofile

( = SAP system name and = name of the NT machine on which the global profile directory is physically located)

All hosts in an SAP System can access these profiles. It is possible for several R/3 instances to use a single profile simultaneously. Separate profiles are not required for each R/3 instance.

You should maintain setup profiles using the Computing Center Management System (CCMS). You should therefore not edit the active profiles directly at operating system level.

There are three profiles in SAP

• Start profile
• Default profile
• Instance Profiles

Remote function call

It is basically a technical interface with which SAP systems are usually connected. RFC is a call of function module of the other systems.

RFC Interface – SAP has its own interface protocol which is based on the CPI-C. CPI-C stands for common programming interface for communication.

Different types of RFC :-

• Synchronous RFC

It is used to connect different web-AS environment. In this client waits until the server has computed it works or processing.

• Asynchronous RFC

The client will not have to wait for 2-way communication.

• Transactional RFC

TID (unique number) is along data. It resolves problem of data redundancies.

Transactional RFC(tRFC, previously known as asynchronous RFC) is an asynchronous communication method that executes the called function module just once in the RFC server. The remote system need not be available at the time when the RFC client program is executing a tRFC. The tRFC component stores the called RFC function, together with the corresponding data, in the SAP database under a unique transaction ID (TID).

If a call is sent, and the receiving system is down, the call remains in the local queue. The calling dialog program can proceed without waiting to see whether the remote call was successful. If the receiving system does not become active within a certain amount of time, the call is scheduled to run in batch.

tRFC is always used if a function is executed as a Logical Unit of Work (LUW). Within a LUW, all calls

• are executed in the order in which they are called
• are executed in the same program context in the target system
• run as a single transaction: they are either committed or rolled back as a unit.

• Qued RFC

It includes logical unit of work.  To guarantee that multiple LUWs are processed in the order specified by the application, tRFC can be serialized              using queues (inbound and outbound queues). This type of RFC is called queued RFC (qRFC). qRFC is therefore an extension of tRFC. It transfers              an LUW (transaction) only if it has no predecessors (based on the sequence defined in different application programs) in the participating                        queues. Implementation of qRFC is recommended if you want to guarantee that several transactions are processed in a predefined order.

Lock Management

TCode – SM12 (Lock Management)
Enqueue table size is defined by the parameter
Enqueue/table_size=4MB (Earlier 1 MB to 4 MB) in Netweaver systems this can be increased to 100MB

Shared Mode
Exclusive Mode.

Locks are monitored in transaction SM12. In principle the lock which are older than one hour should be reported to the escalation manager. If the lock table is filled (Enque/ Table_size) an overflow occurs in the lock table.

1. Check whether the update server is still performing the updates. If the updating has stopped, then the lock table can quickly become over filled with the locks held by update requests. We can resolve the problem by restarting the updates. If updating has not been interpreted, then we must enlarge the lock table.

Note: Enque table overflow is recorded in SM21 and ST22

Eg: Execute SU01 from Shawn user/ 800 and edit shramana user
Execute SU01 from Shawn user/800 and edit shramana user

Following message is displayed

And now execute SM12 which displays the Exclusive Mode lock

2. Enque time is too high
As a part of the response time enqueue time should be 1ms – 5ms for Central instance and 100Ms in case of the request that is coming form Dialogue instance.

Then we can consider the following

1. Lock table is overflow and the locks are held in SM12

2. Update is deactivate (SM14) due to any of the issues in DB. If the update gets deactivated then the locks are not released.

3. If the Enqueue time increases i.e. there could be RFC issue or Enque wait time is increasing then consider increasing Enqueue work processes.

4. Dead locks (Usually never occurs, but there is a collision between PP, Manufacturing and Material Module, so highlight this issue to SAP)

In some instances we may need to release the locks but we need to follow certain process.
Do not release the lock in SM12 (Even though there is an option)
Lock deletion is recorded in SM21.

1. Users complaint that he could not update a record and message pop up stating that the record is locked by user XYZ.

2. Check the period of lock (if it is older than 1 hour inform to the escalation manager)

3. Get the written B&W approval from the user and terminate the session of that user using SM04.

Monitors

The CCMS monitoring infrastructure, a solution within SAP NetWeaver, centrally monitors any IT environments – from individual systems through networked SAP NetWeaver solutions, to complex IT landscapes incorporating several hundred systems. In this section, you learn about the different functions of the Alert Monitor (transaction RZ20) – from creating your own rule-based monitors to using the predefined auto-reaction methods of the Alert Monitor.

For general information about monitoring, see Monitoring.

 

About Monitor Templates and Monitor Definitions

SAP Monitor Templates for SAP NetWeaver and Key Components of SAP Solutions (SDN Blog)

SAP NetWeaver provides a matured infrastructure for centrally monitoring SAP landscapes, using predefined monitors.

Creating a Rule-Based-Monitor (SAP Tutor)

This SAP tutor shows how to create a rule-based monitor within the CCMS monitoring infrastructure.

Editing Monitors and Monitor Sets (SAP Help Portal)

A monitor is a set of monitoring tree elements (MTEs) that are arranged in a hierarchical structure. These monitors are combined in monitor sets. You can create, copy, edit, and delete both monitors and monitor sets, and transport them into other systems. All of these processes are deliberately kept simple, so that the creation of a monitor or a monitor set is not only useful for setting up your own, specialized work center, but also as the central control position for concrete problems.

How to use the monitor set “SAP CCMS Technical Operation Templates” (SDN Blog)

The monitor set SAP CCMS Technical Operation Templates is designed for regular monitoring of your system landscape with the Alert Monitor (transaction RZ20). The monitors in this set contain a selection of the most important messages and performance values for both ABAP and Java systems.

Using Auto-Reaction Methods

Configuring the Sending of E-Mails as an Auto-Reaction (SAP Tutor)

The CCMS monitoring infrastructure allows you to define auto-reactions that are automatically executed when an alert occurs. If an alerts occurs in an MTE to which you have assigned this method, you are informed about it by e-mail, fax, or pager, even if you are not working in the Alert Monitor.

Central and Assigning Auto-Reactions in CCMS (SAP Tutor)

The monitoring Infrastructure allows to define auto-reactions, which are executed automatically in case of an alert. These methods can be executed locally and centrally. This tutorial describes the configuration of a local and a central auto-reaction method, exemplified at an automatic alert notification per e-mail.

CUSTOMIZATION

Select Solution Monitoring under Operations Setup

 

Click on System Administration.

 

 

System Administration
Select “Central System Administration” for the system you want to administer.

 

 

Change Mode :Central System Administration -Tranings Company Producti
Expand the tree

 

 

Expand the tree

 

 

 

Select the System Type you wish to customize.
We are going to customize the Production System.

 

 

Click on the System Type to alter it.

 

 

 

Enter “SCM”.

 

 

 

Click here to save your changes.

 

 

 

To Customize Communication with mySAP components, Select the “Involved Component” tab.

 

 

 

Select “addSAP ITS Task Group Structure?”

 

 

 

Seve your selection.

 

 

 

You should now load frequencies over which the Task should be carried out. Load the default frequencies, which can be edited.

Select “Load Default Frequencies”.

 

 

 

Some Tcodes

ST02

SAP transaction ST02 can be used to view SAP Buffer and memory configuration for a SAP instance and review SAP memory quotas for individual user job or process as well as current SAP buffer status, SAP memory utilization at SAP instance or user/transaction level. This post would cover following areas:

1. How to run SAP memory usage monitor and navigate through important ST02 screens.

2. How to understand SAP ST02 screens: main/summary screen or SAP memory Quota screens etc.

3. How to use SAP ST02 to do SAP memory and buffer performance analysis.

SM13

This Transaction Is Useful To Figure The Status Of Update System. Incase An Update Is Inactive We Can Figure Out The Same From This Transaction And Necessary Action Can Be Taken And Update Can Be Activated Again.

Sm14 Transaction Can Be Called Internally From Sm13. These Both Transactions Are Useful For Update Administration.

In Sm13, You Can Select Status (Canceled, To Be Updated, V1 Executed, V2 Executed, All ) And Time Interval During Which You Would Like To View The Status Execute To Check The Overview Of Updates As Per The Status And Time Interval Selected.

SM37

This Transaction Will Be Useful To Have An Overview Of Jobs With Different Statuses.

As Part Of Daily Monitoring, Sap Basis Administrator Should Use This Transaction To Findout Canceled Jobs And Active Jobs(For Eg: Long Running – More Than 24hrs Etc).

Incase Of Canceled Jobs, Root Cause For The Failure To Be Figured Out From The Logs Of The Respective Job And To Be Actioned By Rescheduling Etc.

Incase Of Long Running Jobs, We Need To Figure Out The Reason For Long Running And Action Them Accordingly.

 

Increasing the size of traces in SAP

Sometimes, it is required in SAP to increase the size of a trace file from default value so that more trace or log can be captured.  Mostly SAP requests this change to resolve an Oss message. This can be done as follows:

Login to SAP ABAP system. Go to transaction RZ11

, please provide the SAP parameter rstr/max_filesize_MB and click on display button which results in the below screen

As shown in the description, this parameter sets the maximum file size of a trace. Default value of trace file is 16MB. The maximum value is 100MB.

To view documentation related to this click on “documentation” push button.

To change the value, click on “Change Value” push button which results in following screen.

screen set the new value and also select “switch on all servers” checkbox if you would like to change this parameter across all the application servers of an SAP system.

However, if you would like to change this parameter in any specific application server, please make sure this checkbox is unticked.

 

System trace files

If you want to record the internal SAP system activities, use the function SAP System Trace (transaction ST01).

The system trace is primarily used when an authorization trace is to be used. The system log or the developer traceare recommended for system monitoring and problem analysis.

The following components can be monitored using the SAP system trace:

•   Authorization checks
•   Kernel functions
•   Kernel module
•   Database accesses (SQL trace)
•   Table buffers
•   RFC calls
•   Lock operations (client side)

There are two ways of selecting what traces you want displayed. In the initial screen, select the components to be logged, and additional filters, if required. You can reuse the filters and restrictions from the traces that have these settings when the traces are evaluated.

Initial Screen

The initial screen of the system trace looks like this:

Proceed as follows:

1. Switch on the trace and select the required components:
   Switch Trace On and Off
2. Perform the tasks that lead to the error or problem.
3. Switch off the trace.
4. Evaluate the Trace

Protecting Trace Information from Being Overwritten

If you want to protext a trace from being overwritten later, choose  Save on the initial screen, or choose Go To→ Save from the menu.

On the next screen, you can create a short text for a trace, and choose whether the new file that is created specifically for this trace should be automatically created, or whether you want to specify a file. If you do not specify an absolute path, a file of this name is created in the log directory. In the case of automatic file creation, the system determines the filename and stores the file in the log directory. The advantage of this is that, unlike a manually created file, the F4 help can be used for to search for the file from the analysis screen.

If you choose automatic creation, you can delete the file again in this transaction (use the  button in the analysis screen). This is not possible if you specify a filename. If you want to delete this kind of file, you have to do so at the operating system level.

 

Alert Monitoring

The monitoring architecture, a solution within mySAP Technology, centrally monitors any IT environments – from individual systems to networked mySAP.com solutions to complex IT landscapes consisting of several hundred systems. It is available in every mySAP.com solution and can be used immediately after installation. You can easily extend the architecture with SAP and non-SAP components.

 

Alerts are a central element of monitoring that report problems – such as when a value exceeds or falls below a particular threshold value, or an IT component is inactive for a specified length of time – quickly are reliably. These alerts are displayed in the Alert Monitor; this reduces the workload of the system administration, as they must only watch the problem messages instead of monitoring vast amounts of system data.

The Alert Monitor is therefore the central tool with which you can efficiently adminster and monitor distributed mySAP.com solutions or client-server systems. The Alert Monitor displays problems quickly and reliably

 

The Alert Monitor provides the following functions:

• You can use the Alert Monitor to obtain complete and detailed monitoring of all SAP and non-SAP systems, the host systems, and the database.
• All errors generate alerts, which are displayed in a tree structure.
• The alerts contain a status indicator with a color and a numerical value. Yellow represents a warning, red represents a problem, and the numerical value represents the severity of a possible error. In the tree structure, the most severe alerts are displayed upwards in the display hierarchy. If a tree node is not displaying an alert, there is no error in the whole branch below it.

• You can assign analysis and auto reaction methods to the alerts. These assist you to process the error quickly. If you double click the alert, the monitoring architecture starts the assigned analysis method (for example, the job management transaction for a job that has terminated prematurely). An auto reaction method, on the other hand, starts automatically as soon as the alert occurs. Auto reaction methods include executing operating system commands, and sending an e-mail or SMS message to the system administrator.

• The Alert Monitor contains various views in which either the current or the open (that is, those that have not yet been analyzed) problem messages are displayed. Alerts are also archived.
• Threshold values, methods and detailed help for a large number of monitoring attributes, and three extensive monitor sets with monitors for all aspects of system management are predefined in the monitoring architecture on the basis of best practices and are available for you to use in every SAP system.
• You can individually adjust all settings and configure your own monitors.