13167
SAP R/3 System Management: Advanced Administration & CCMS
National Education Training Group, Inc.
Copyright © 1998 National Education Training Group, Inc.
All rights reserved. No part of the material protected by this copyright may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, broadcasting, or by any information storage and retrieval system, without permission in writing from National Education Training Group, Inc.
Written consent issued by:
NETG
Inc.
1751 West Diehl Road
Naperville
IL, 60563
630-639-3000
Contents
The Basis System for Advanced Users 5
Software Logistics 5
R/3 Data 5
Transport Request 5
System Change Option 5
Client Change Option 6
TMS 7
Domain Controller 7
Creating other Systems 7
Creating Virtual/External Systems 8
Backup Domain Controller 8
Creating Transport Routes 8
Checking and Activating Transport Routes 9
Other Software Logistics Tools 10
CTO 10
Workbench Organizer 10
Customizing Organizer 11
Transport Directory, Naming Conventions 12
Originals and Copies of Objects 12
Transport Options 12
Transporting a Transport Request 13
Creating Clients 13
Client Copy 14
Client Export 15
Client Import 16
Transport Options Overview 16
CCMS 18
Introduction to the CCMS 18
CCMS Overview 18
Tasks and Objectives 18
Performance Monitoring 18
Monitoring Overview 19
System Response Times 19
Workload Analysis Monitor (ST03) 20
SAP Buffer Monitor (ST02) 21
Database Monitor (ST04) 22
Operating System Monitor (ST06) 22
Day-To-Day Work of the R/3 System Administrator 23
Introduction 23
Work Process and User Overview 23
System Log, Short Dumps, Background Jobs 24
Database Monitoring 25
Update and Lock Overview 26
Performance Monitoring 26
Alert Monitoring 27
Introduction 27
Using the Alert Monitor 27
Own Monitor 28
Customizing the Monitor 28
Traces and Logs 29
Startup/Work Process Logs and Traces 29
Operating System Log 30
Database Message Log 30
Glossary 31
In the first lesson, you will learn how to specify whether or not transport requests can be created in an R/3 System or in a client. You will also find out more about the part of the R/3 System that processes transport requests and about the different request types.
A distinction is made between client-dependent and client-independent data in the R/3 System. Client-dependent data refers to one client only and includes, for example, application, Customizing, and user master data. Client-independent data affects the whole R/3 System. This data includes Repository objects and some Customizing data. With client-dependent data, it is important to realize that application data can never exist, or be transported, without the relevant Customizing data. Customizing data can, however, exist and be transported without application data.
If a development, quality assurance, and production system are installed - which is usually the case - you can transport changes and developments from one system to another using transport requests. You can either transport the changes from the predecessor system to the same client or to a different client in the successor system. These changes within an R/3 System are normally recorded in a so-called transport request. A distinction is made between client-dependent and client-independent changes and transport requests in the R/3 System. A client-dependent transport request, for example, is created when a change is made to the Customizing data. This data is then transported from the development system to the same client in the quality assurance system, with or without the associated application data. A typical client-independent transport request involves, for example, transporting a program change from the Repository of the development system. The program change affects all clients of the quality assurance system.
In order to be able to create changes and transport requests in an R/3 System, you first have to set the R/3 change option. Only after this option has been set can you specify whether or not Repository and client-independent Customizing objects can be modified globally. You can only make this setting if you have the appropriate administrator authorization for transports. You call up the transaction for setting the system change option by choosing:
Tools, Administration, Transports and Installation follow-up work.
In the Processing After Installation for CTO screen, you activate the system change option by clicking the appropriate pushbutton. The System Change Option screen then displays the 10 Repository and client-independent Customizing objects that can be modified globally. The namespaces and name ranges of the Repository objects are intended for client-independent Customizing. The first few characters, or the prefix, of these are usually the same. The objects that can be changed are selected in the Modifiable column in this screen. This will depend on the system settings and object in question and is usually managed by the administrator of the development system. You can select or deselect either individual objects, or groups of objects within a name range using the Edit menu. One of the options in this menu is Deselect all. If this option is chosen, you will no longer be able to change any of the objects displayed. To activate the change option for an individual object, you select the appropriate checkbox in the Modifiable column. Other objects are selected in the same way, providing you want to be able to change them. Only the Customer name range and Local objects should, however, be selected in the customer’s system, in order to protect other programs and reports. You can check when, how, and by whom objects were last set as globally modifiable by calling up a special log. You call up the log by clicking the Log pushbutton. The table in the Log: System change option setting screen only displays the namespaces with prefixes that have been changed at least once in the past. The settings made for each namespace are also displayed. The Expand pushbutton, which appears in front of the individual namespaces or namespace groups, provides further details on the settings. The information displayed tells you who was allowed or not allowed to use the system change option for this namespace, and when. A color key shows you how to interpret a message and also indicates whether this is a serious error or whether it just provides general information. You then decide whether or not the new system change settings made earlier are to be stored. To call up a dialog box which you can use to make this decision, you click the Global setting... pushbutton. The two radio buttons allow you to specify whether the objects selected earlier are to be stored as Modifiable or Not modifiable. If you choose Modifiable, these objects will be released and logged as being globally modifiable. If you choose Not modifiable, none of the objects are released as modifiable. All the object selections are then deleted and must, if necessary, be reset. Normally, all changes are allowed in a development system. A quality assurance system and a production system, however, do not allow any changes at all.
The general R/3 System change option for program groups and reports is managed using namespaces and name ranges. In addition to this, you can allow more specific changes at client level. This is carried out in Client Maintenance which you call up by choosing:
Tools, Administration, Administration, Client administration and Client maintenance.
The Display View ”Clients”: Overview screen lists all the clients currently being managed in the system. To call up details on one or more clients or to make a change, click the Display<->Change pushbutton. The system then calls up the standard table T000 (client independent), which manages all the clients of an R/3 System. If you confirm this information by clicking Continue Enter, you will call up the change mode for the clients listed. In order to display details on one of the clients or to change these, you activate the appropriate field and choose Goto and Details. The screen that appears contains formal data and system-specific information on a particular client. It indicates, for example, whether or not changes and transports are allowed for client-dependent objects. If necessary, you can change the setting by means of the radio buttons provided. The entry in the Client-independent object changes field is used to specify whether or not changes to Repository and client-independent Customizing are allowed. You can call up a list of possible settings for maintaining client-independent objects using the possible entries pushbutton.
The second lesson takes a look at the functions performed by the Transport Management System and shows you how this is defined and configured.
The Transport Management System (or TMS for short) organizes, monitors, and executes all transport requests within a system landscape. All R/3 Systems managed by the TMS are part of a transport domain. One of the R/3 Systems controls the transport domains, while all the other systems are supplied with copies of this reference configuration. The transport domains for all the R/3 Systems must be defined and configured before the TMS can be used. This should always be carried out in client 000 of the R/3 System in question. The first step involves creating the domain controller in the transport domain controller. You call up the TMS by choosing:
Tools, Administration, Transports and Transport Management System.
In the TMS: Configure Transport Domain dialog box, you have to enter a description for domain controller PB1. You then save this entry. The Transport Management System screen is displayed automatically, and tells you that you are logged onto the controller. You can then maintain other systems. You display the system overview by choosing Overview and Systems. Domain controller PB1 has been entered in the system overview and has been assigned a special symbol to indicate its role. Another symbol indicates that it is active.
In
the transport domain, you have to define and configure all the R/3
Systems that are managed by the TMS. To add other systems to the TMS,
you have to log onto client 000 of the new system and call up the
TMS. You call up the TMS by choosing:
Tools,
Administration, Transports and Transport Management System. The TMS:
Include System in Transport Domain dialog box
indicates the name of the log-in system
and the name of the transport domain. It also contains the name of
the domain controller and other system-specific information. To
create the PB2 system in the transport domain, save your data. The
message in the Transport Management System screen indicates that the
newly created PB2 system is still waiting to be included in the
transport domain. The steps for creating the third system, AUT,
in the transport domain are the same as before. In order to check the
two systems you have created, you go back to the PB1 system and the
system overview by choosing Overview and Systems. The only system
displayed in the System Overview: Domain DOMAIN_PB1 screen is PB1.
You refresh the overview by clicking the Refresh pushbutton. The two
other systems created are then also listed. The system and status
symbols are explained in a color key. You can call up this key by
choosing Extras and Key. The key contains the symbols which indicate
the system type and status. The Status group, for example, contains
symbols which indicate whether a system is active and whether it is
waiting to be included in the domain. The two new systems you have
created, AUT and PB2, then have to be included in the transport
domain and activated. In order for a system created to be included in
a transport domain, it has to be accepted within the system group.
For this purpose, you select the name of the appropriate system in
the system overview and choose R/3 System and Accept. To confirm
acceptance of the system, click the Yes pushbutton in the dialog box.
You will then be asked whether you want the accepted change to be
made to the system to be distributed to other systems in the group
immediately. To confirm that this change is to be distributed
immediately, click the Yes pushbutton.
The selected system is then included in the transport domain and is
active. The third system is included in the domain by following the
same procedure.
R/3 Systems are not usually all installed at the same time in an R/3 System landscape. In order to be able to model the transport routes, you can configure these systems as virtual systems. A real R/3 System will be used as an example of an external system. You create virtual and external systems in a client of the PB1 system domain controller. To do so, you choose:
Tools, Administration, Transports, Transport Management System, Overview, Systems, R/3 System and Create.
To create a virtual system, choose Virtual system. You can then maintain this system in the TMS: Configure Virtual System screen. You enter the name of the system in the System field and a short name in the Description field as an explanatory short text. You then save your entries. The system will ask you whether you want to distribute the created virtual system immediately to the other systems in the group. To confirm this, click the Yes pushbutton. The virtual system that you have just created is then also listed in the system overview for the domain. To create an external system, you choose External system. Once again, you have to enter the system name in the System field and an explanatory short text in the Description field. You enter the system path used to administer the external system in the Path field and save your data. The system is then also listed in the System Overview for the domain. Other virtual or external systems can be maintained in the same way.
If the domain controller in the R/3 System is not available, a different system is specified as the backup domain controller. This setting is stored in the transport domain configuration in the PB1 system. To do so, you choose:
Tools, Administration, Transports, Transport Management System, Overview, Systems, R/3 System and Change.
The Change TMS Configuration: System PB1 screen contains configuration descriptions of the transport domain, transport groups and RFC address. To select the AUT system as the backup domain controller, activate the Backup field. You can enter the name of the backup domain controller or select one using the possible entries pushbutton. If you choose the AUT system using the possible entries pushbutton, you select the appropriate name in the dialog box and copy it to the configuration by clicking the Choose pushbutton. The AUT system is thus set as the backup domain controller. You then save your changes. The system asks you whether you want the configuration change to be distributed to all of the other systems. You confirm this by clicking Yes. Once you have returned to the System Overview: Domain DOMAIN_PB1 screen, the appropriate symbol appears alongside the AUT system to identify it as the backup domain controller. You can find out more about the symbols and their meaning in a color key by choosing Extras. The key displays a group of system symbols including the symbol for the backup domain controller. You can also see which external systems have been created and how the domain controller is identified. All systems are active.
Once all the R/3 Systems have been defined and configured in the transport domain, you have to define the transport routes. You have to specify the target system in which you want to consolidate change requests and the R/3 Systems to which you want these requests to be forwarded automatically. The transport route is defined and maintained in a module of the Transport Management System. To set transport routes or to reassign these, you call up the appropriate transaction by choosing:
Tools, Administration, Transports, Transport Management System, Overview, Environment and Transport routes.
The
transport routes overview displays the systems of the transport
domain in the form of a hierarchy. A color key provides more details
on the meaning of the colors. To call this up, choose Utilities and
Legend. The legend indicates that you can assign both symbols and
colors to
the systems according to the status they have within the transport
route. To configure the transport routes, choose Configuration
and
Display <-> Change. The
system tells you that the new systems have been copied. Confirm this
to call up the change mode. You also need to assign a status to the
individual systems within a system group. This is how transport
requests are started. To do so, you choose Configuration and Standard
configuration. In the Standard Configurations
dialog box, you can choose one of three
options for configuring systems. If the group contains three systems,
choose the third option by clicking the appropriate radio button. A
further dialog box then appears in which you have to enter the system
names according to system type. After creating a new system or
changing a configuration, the hierarchy structure changes. This is
the case in the example here where new systems have been created. The
linear structure from before has now been extended to include an
additional level for the transport layers and transport routes. If
you click the nodes in front of each level, the information within
these levels is updated and can be checked. The data is saved once
all of the information has been updated and checked.
Test runs can be carried out after the systems have been created and configured in an R/3 System group. These test runs check whether the transport routes between the individual R/3 Systems have been defined correctly. These activities are carried out in the Transport Management System (TMS). To call up the Transport Management System, you choose:
Tools, Administration, Transports, Transport Management System, Overview and Transport routes.
Next, you choose Configuration. You can then specify whether the transport routes within your own system or all systems in the group are to be checked. If you want all the systems to be checked, choose All systems. The system tells you that it will take some time to check all the systems. Click the Yes pushbutton to confirm that you want the check to be initiated. A test log lists any errors detected during the check. A color key provides more details on the meaning of the colors. To call this up, choose Goto and Key. The symbols and different colors in the color key tell you whether the errors are serious or relatively harmless. Having closed the log, you have to activate the data that has been checked. To do so, choose Configuration and Activate. You can specify whether you want only the data in your own system or in all the systems in the domain to be activated. To activate the data in all the systems, choose In all systems in domain. The system asks you whether you want to distribute the configuration to the SAP systems. Confirm this with Yes. The status bar then confirms that the configuration has been activated in the three systems of the system group. In the Configuration status node, you can see that all three systems, which are highlighted in green, are active.
The third lesson introduces you to a number of tools with which you can organize, monitor, and manage transport requests in the R/3 System. It deals in particular with the Change and Transport Organizer, the Workbench Organizer, and the Customizing Organizer.
The Change and Transport Organizer (also referred to as the CTO) is a tool for organizing software development projects. It includes the three transactions Workbench Organizer, Customizing Organizer, and Transport Organizer. Transport requests can be managed in the Workbench and Customizing Organizers. You can create, change, search for, and release transport requests in both of these transactions. The Workbench Organizer can only manage client-independent transport requests. The Customizing Organizer, however, can be used to manage client-independent Repository objects and client-dependent transport requests. You can also use both tools to organize teamwork, for example, for Customizing developments or ABAP programming, by making a project manager responsible for a transport request. This transport request is assigned tasks that are carried out by specific developers. The transport request can only be released and exported by the project manager after the developers have released their individual steps. In contrast to the Customizing Organizer, you use the Workbench Organizer to assign development classes to the individual developments. It is also possible to lock objects in a transport request via version management. You call up the CTO by choosing:
Tools, Administration, Transports and Transport Organizer.
In the Transport Organizer: Initial Screen, you open the Workbench Organizer by clicking the appropriate pushbutton. From the Workbench Organizer: Initial Screen, you can manage all local and client-independent, transportable change requests of the client-independent Repository. To open the Customizing Organizer, click the Customizing pushbutton in the Transport Organizer. As in the Workbench, the Customizing Organizer: Initial Screen is the starting point for managing all change requests in Customizing.
The Workbench Organizer is a tool of the CTO. This transaction helps you manage and transport change requests from the client-independent Repository. You can access the Workbench Organizer via a request overview in which all usable change requests are displayed and can be expanded. You call up the Workbench Organizer by choosing:
Tools, Administration, Transports and Transport Organizer.
To work with the Workbench Organizer, click the Workbench pushbutton. In the Workbench Organizer, you can process change requests from different users. You can enter the users whose requests you want to process, or select these using the possible entries pushbutton. The Transportable and Local fields are defaulted which means that the system will search for one or several requests which are to be transported to successor systems. The Modifiable request status indicates that a search is to be made for one or several transport requests that have not yet been released for export. You can search for transport requests that took place during a specific period of time using the From and To date fields. The Transports pushbutton enables you to display the transfer status of exported or imported requests, by date. Clicking the Repairs pushbutton calls up information on corrections made to copies. After you have entered the user name and confirmed it, the system checks whether any transport requests exist for this user. This is why you always have to enter the user name when searching for transport requests. To process transport requests, click the Display pushbutton. In the Workbench Organizer: Requests screen, you can see requests with two different processing statuses. Requests with the status Modifiable have not yet been released for transport. Requests that have already been transported have the status Released. The second level of the structure displayed shows whether a request is Transportable to a successor system or remains Local in your own system. The ten-character request name is encrypted. The first three characters indicate the source system of the request. The fourth character refers to the command file. The fifth character is set by default and the last five characters are assigned automatically by the system. Each request is also assigned the appropriate user name and contains a short definition created by the user. To call up further details on all requests, click the Expand pushbutton. All requests in the screen are broken down to different levels. This structure is the same for all requests. The task for the change request is always entered directly underneath the request. The number of the task is always the final digit of the request (incremented by one). The specialist area in which the change has been made and the program name appear underneath the task. It is important here that the task is always released first before you export a request. To export the task, select it and click the Release pushbutton. You have to enter a freely-definable text for every export release. This is exported together with the task and must consist of at least three units. To save the text document, click the Save raw version pushbutton. The name of the released task appears in dark blue indicating that it was processed successfully. The request itself can then be released for export. First, select the request and click the Release pushbutton. The request has now been released and can be exported. You can see from the message on the screen that the export transaction is in progress. To find out exactly what the current status is, click the Refresh pushbutton. The message OK confirms that the request has been exported successfully. In the Workbench Organizer: Requests screen, the next request has been moved up to replace the released, exported request. To search for the released, exported request in the directory, you have to close the expanded request structure by clicking the Compress pushbutton and the nodes for modifiable and released requests. The released request is in this node and can be used for possible follow-up checks.
The Customizing Organizer is a tool of the Change Transport Organizer. Client-independent Repository objects and client-dependent transport requests are managed using this transaction. You call up the Customizing Organizer by choosing:
Tools, Administration, Transports and Transport Organizer.
To work with the Customizing Organizer, click the Customizing pushbutton. In the Customizing Organizer: Initial Screen, you can enter the users whose requests you want to process, or select these using the possible entries pushbutton. Customizing has been selected in the Category field group which indicates that you want to search for one or several transport requests in Customizing. The system will only search for the requests of the user logged on, otherwise the All clients checkbox must be selected. The Modifiable checkbox in the Request status field group has been selected which indicates that the system will search for modifiable transport requests. You can search for transport requests that took place during a specific period of time using the From and To date fields. The Transports pushbutton enables you to display the transfer status of exported or imported requests, according to the date. The Repairs pushbutton allows you to display information on possible corrections made to copies. After you have entered the user name and confirmed it, the system checks whether any transport requests exist for this user. This is why you always have to enter the user name when searching for transport requests. You can display or edit these transport requests by clicking the Display pushbutton The Customizing Organizer: Requests screen provides an overview of some of the requests. All the requests are modifiable and are assigned to Customizing. The ten-character request name is encrypted. The first three characters indicate the source system of the request. The fourth character refers to the command file. The fifth character is set by default and the last five characters are assigned automatically by the system. The client in which the Customizing request was created is displayed alongside the request name. The user name is displayed together with an explanatory short text which is assigned to each request by the user. To call up further details on a request displayed, click the node in front of the request name. At the next level down, you can see the encrypted task for the request together with its short text. The number of the task is always the final digit of the request (incremented by one). To display further details on a request, you click the nodes at the levels underneath this request. It is important here that the task is always released first before you export a request. To do so, select the task and click the Release pushbutton. You also have to attach an explanatory text to the released task consisting of at least three units. To save the text document, click the Save raw version pushbutton. You then release the request. To do so, you go back to the Customizing Organizer, select the request and click the Release pushbutton again. In the dialog box, you have to decide how you want to release the Customizing request. There are three different possibilities here. You can add the request to an existing request or create a new collective request if this facilitates organization. If you want to release and export the request immediately, click the appropriate pushbutton. In the Overview of all Transport Logs of the request released, you can see a message indicating that the export transaction is in progress. You update the log by clicking the Refresh pushbutton. The OK message indicates that the released request was exported successfully. The released request is no longer in the overview of listed requests and the next request is suggested for processing. If you scroll the overview, you can see the request that has been released and transported. This request remains stored in the directory for possible follow-up checks.
Transporting requests from the development system to several R/3 Systems enables you to synchronize Customizing and Repository data and developments in all R/3 Systems. Here, the transport route is usually only allowed in one direction. Released transport requests from the Workbench and Customizing Organizers of the test system are first exported to a central transport directory. Objects for tests and checks in the quality assurance system are imported from here. The objects are not imported to the target systems until the checks performed by the quality assurance system are complete. The central transport directory notes and manages the transport request objects received as data files in the data subdirectory. The command files of the individual transport requests are stored in the cofiles directory.
Original, copy, repair, correction, modification, and change are all terms used when discussing an R/3 System and its environment. Repository object originals are objects that belong to a particular system. Originals are unique. They cannot be changed. Changes that are made or transported to other systems are always copies.
The fourth lesson shows you which transport options are available in an R/3 System and how these are used. It focuses, in particular, on transporting transport requests and on client transports.
Released transport requests can be transported to the preselected R/3 System using the Transport Management System (TMS). The transport request is placed in the buffer of the successor system automatically via the predefined transport routes and can then be imported. You call up the transaction by choosing:
Tools, Administration, Transports, Transport Management System and Overview.
To call up information on the transport requests to be imported, you choose Imports. The import overview lists the queues of all the target systems to which imports can be made. In the example, the only transport requests in the queue that are waiting to be imported are for one system only. To display these requests, you select the name of the queue and choose Import queue and Display. The import overview contains the requests waiting to be imported and also tells you who they belong to. To start the import transaction, choose Queue and Start import. The dialog box that appears tells you that the target system has already been set but the target client has not. You can use the possible entries pushbutton to call up the Input help: Target client dialog box which lists all the clients currently installed in the target system. You select the target client by clicking the client number and confirming your selection with the Choose pushbutton. The selected target client is then copied to the Start Import dialog box. To start the import transaction, click the Start import pushbutton with the car icon in the dialog box. You then have to decide whether or not you want to import all requests to the target system. As you want to import both requests, you click the Yes pushbutton. If you confirm that you want to import all requests by clicking Yes, the screen for logging onto the target client of the target system appears automatically. Once you have made the necessary entries in the login screen, the system tells you that the import transaction to the target system has been started. You then confirm this information. While the import transaction is in progress, you can display the status of the transaction by choosing Goto and Import monitor. The TMS Import Monitor of the target system contains all the time-related and technical information on the transaction being executed. To check whether the transaction has been completed successfully, click the Refresh pushbutton. The transaction status is finished and the tp message indicates that the import has been completed successfully. Once you are sure that the transaction has been completed successfully, you can display or print the logs created for it in the import queue screen. You can display or print a log for each individual imported request. To do so, you have to select the appropriate request, choose Request and Display. To call up the overview of all the transport logs for the request, you choose Logs. This overview contains all the system, time and status information on the request export/import. You can call up further details on the import by double-clicking the Import text field. The Import Overview still contains the two requests that have already been imported. For this reason, you have to update the display by clicking the Refresh pushbutton. Once you have refreshed the display, it reflects the current status. To check the import queue as well, you choose Import queue and Display. The import queue for this system is empty as it no longer contains any requests.
After an R/3 System has been installed, it usually only contains three standard clients. You should not use these to carry out your day-to-day work. In order to copy a standard client, you have to create an empty test client. This is carried out in client maintenance which you call up by choosing:
Tools, Administration, Administration, Client administration and Client maintenance.
The first screen contains an overview listing all the clients that have been created in the system. To specify whether you want to display, change, or create client data, you use the Display -> Change pushbutton. The system outputs a message indicating that the table is client-independent. The table referred to here is the standard table T000 which manages all the clients of an R/3 System. You can then maintain clients in the Change View ”Clients”: Overview screen. To create a new client, you click the New entries pushbutton. You have to enter the client number and short name in the first two Client fields. You then enter the city. The short form of the country currency of the client is stored in the Standard currency field. To call up the list of currencies supported by the system, click the possible entries pushbutton. Copy the appropriate currency for the client by double-clicking it. In the Client role field, you have to enter the status of the client in the system. To find out which types of role are defined in the system, click the possible entries pushbutton and choose the appropriate role by double-clicking it. The radio buttons in the next field group are used to specify whether, and if so how, this client will be involved in changing and transporting client-dependent objects. A further field is used to specify whether or not the client may be included in client-independent changes to Customizing and Repository objects. This setting is assigned as a default value by SAP each time a client is created and can, if necessary, be modified. You can display the other fields by scrolling the screen. The client copy protection function and comparison tool are also preset by SAP for a new client. These settings can, if necessary, be changed. Once you have made all of the entries for the client, save your data. The test client created has now been entered in the Change View ”Clients”: Overview screen. To display all the clients in the overview, you have to scroll the screen. The new client is then displayed in the overview.
An R/3 System usually contains original standard clients. A copy is normally made to an empty test client to avoid any changes being made to the originals. You have to specify here which data is to be copied to the test client. First, you log onto the new empty test client and enter the user SAP*. This is usually always the case with new clients as no other users have been created yet. You overwrite the client number displayed in the Client field with the number of the new test client. The system will then ask for your password. With new clients, you always enter the password PASS for the user SAP. In the Language field, you enter the language in which all the displays, lists, and logs are to appear. To confirm that all entries in the logon screen are correct, you click the Enter pushbutton. The SAP Copyright dialog box then appears and you click Enter to continue. After you have completed this first step and logged onto the new client, you call up the local copy application by choosing:
Tools, Administration, Administration, Client administration and Client copy.
To create a client copy in your own system, you choose Local copy. After you have called up the transaction, the system will request the source client for the client copy. You can enter the source client or select one using the possible entries pushbutton. You choose the desired source client in the dialog box by double-clicking the client number. You then choose the profile in order to specify which data you want to copy from the source client. To display the default profiles in the system, click the possible entries pushbutton. To specify the data area you want to copy, you double-click one of the profiles. You then have to set the type of processing and the print output. To do so, click the Execute in background pushbutton. If you wish, you can enter a background server in the Schedule Client Copy in Background screen. To set the start time and print parameters, click the Schedule job pushbutton. In the Verification dialog box, you will then be asked whether you want to continue with the other settings with the parameters chosen for the local client copy. To continue, click the Yes pushbutton. In the Start Time dialog box, you can select different start times to suit your own requirements. As you want to make the client copy immediately, click the Immediate pushbutton. Once you have made your choice, an appropriate message will appear in the dialog box. You then save the start time. Standard SAP settings for print administration have already been entered in the Background Print Parameters dialog box. You can, however, change these if necessary. To select an output device for the client copy transaction, call up a list of the possible devices by clicking the possible entries pushbutton. To display the possible output devices, click the Continue Enter pushbutton in the Restrict Value Range dialog box. The Hit List displays the possible output devices. Choose the desired printer in the first column by double-clicking it. The Background Print Parameters dialog box is displayed again automatically. The printer you have chosen has been copied to the dialog box. You then save the parameters set. A message appears indicating the print format selected which you confirm by clicking the Continue Enter pushbutton. A further message indicates that the background job was scheduled successfully and tells you where the transaction log is displayed. Confirm this by clicking the Enter pushbutton. You can call up the transaction log via the copy logs function. You access the copy logs transaction by choosing:
Administration, Client administration and Copy logs.
The Client Copy Log Analysis indicates that the transaction was completed successfully. To call up details on the client copy transaction, select the target client and click the Choose pushbutton. This detailed log displays times, the source client, and the profile copied. You can display further details on this transaction, the status of the client copy and on the release of the R/3 System by selecting the date in the log and clicking the Choose pushbutton. If the client copy has not yet been completed, it is advisable to monitor these logs on a regular basis.
To create the client of one R/3 System in a second R/3 System, you have to export the client from the source system. To do so, you have to log onto the client of the source system and carry out the export transaction. To call up the client export transaction, you choose:
Tools, Administration, Administration, Client administration, Client transport and Client export.
After you have called up the transaction, the system will request the target system for the client export. You can enter the target system or select one using the possible entries pushbutton. To copy the target system selected, click the Choose pushbutton. In the Selected profile field, you have to enter the profile with which data is exported to the target system. To do so, display the default table profiles in the system by clicking the possible entries pushbutton, select the desired profile and copy it. You then have to set the type of processing and the print output. To do so, you click the Execute in background and Schedule job pushbuttons. In the Verification dialog box, you will then be asked whether you want to continue with the other settings with the parameters chosen for the client export. The system then displays detailed information on the client export conventions. To continue, click Continue Enter. In the Start Time dialog box, you can select different start times to suit your own requirements. As you want to export the client immediately, click the Immediate pushbutton. Once you have made your choice, an appropriate message will appear in the dialog box. You then save the start time. The default background print parameters in the dialog box can, if necessary, be changed. To select an output device for the client export transaction, call up a list of the possible devices by clicking the possible entries pushbutton. To display the possible output devices, click the Continue Enter pushbutton in the Restrict Value Range dialog box. In the hit list, you then choose the desired printer by double-clicking it. The Background Print Parameters dialog box is displayed again automatically. You then save the parameters set. The system displays two messages. The first indicates the print format selected. The second message indicates that the background job was scheduled successfully and shows you where the client export log is displayed. Confirm both messages by clicking the Continue Enter pushbutton. To check the client export log, call up the Copy logs function by choosing:
Administration, Client administration and Copy logs.
As you can see from the Client Copy Log Analysis, the transaction was completed successfully. To call up details on the transaction, select the export target client in the log and click the Choose pushbutton. This detailed log displays times, the source client, and the profile copied. To call up further details on the transaction, select the date in the log and click the Choose pushbutton. This log lists the names of the source and target systems, the copy type and all the data areas that were copied with the selected profile. The system tells you that the client export was completed successfully and indicates the number of transport requests created.
Once the source client of an R/3 source system has been exported successfully, it then has to be imported to the target client. To do so, you have to log onto the client of the target system to create a new client, and to carry out the import transaction. You can call up this transaction by choosing:
Tools, Administration, Transports, Overview and Imports.
If no transport requests are indicated, you can interrogate the import queue of each R/3 System in the system group directly. To do so, you select the system in question and call up the import queue for this system. If a transport request exists, the information displayed alongside it indicates the content of the request and to whom the source objects belong. In contrast to normal transport requests that are imported via queues, the transport request of a client export has to be imported as an individual preliminary import via the Import function in the Request menu. To minimize the risk involved with preliminary imports, a confirmation prompt appears here. Once this has been confirmed, you can continue with the preparatory steps for the import. Next, you have to check the target client to which the transport request is to be imported. To do so, you call up the list of possible clients via the possible entries pushbutton, select the appropriate client and start the import transaction for this client. The system requests you to verify whether you want to import the request to the target system specified. The client import transaction is not started until you confirm this. Technical information on the import is listed in the TMS Import Monitor and is confirmed with the text Everything OK. You can call up details on this client import by choosing Logs. The log overview contains the most important information on the export and import of the transport request. You can call up further details by double-clicking Import. This Display Log contains technical system details, for example version and release of the tp, as well as the end date and time of the client import. Return code 0 confirms that the transaction was completed successfully. Once the import transaction to the target system has been completed, the transport request is deleted from the import queue. The system asks you if you really want to delete the transport request from the import queue and indicates that data will be lost. Since the client was imported successfully, you can confirm this by clicking the Yes pushbutton. A text appears indicating that the import queue is empty. The transaction can then be closed.
There are four types of transport function in an R/3 System: the client export/import, the client copy, the client-dependent transport request, and the client-independent transport request. Client-independent and client-dependent data can be transported using the client export transaction. Up to three transport requests can be transported. These transport requests can be transported to the target client using the Transport Management System import tools. A client copy copies client-dependent data in an R/3 System from one client to a new one. It does not create a transport request. A client-dependent transport request transports client-dependent Customizing data from one R/3 System to the next. These transport requests are managed in transaction SE10. In order to import the requests to a different R/3 System, they must be released and imported to the successor systems using the TMS import tools. A client-independent transport request transports client-independent Repository data from one R/3 System to the next. These transport requests are managed in transaction SE09. In order to import the requests to a different R/3 System, they must be released and imported to the successor systems using the TMS import tools.
The first lesson introduces you to the most important features and components of the CCMS. It provides you with an overview of the objectives and tasks of this system as a central R/3 administrator tool.
For an R/3 System administrator, the CCMS is the most important tool for managing and monitoring an R/3 System and its database. In addition to controlling and monitoring the database and the R/3 System, the CCMS tools also support the daily tasks for optimizing the system. To call up the CCMS initial screen, you choose:
Tools and CCMS
This is your starting point for initiating other CCMS transactions.
As a central R/3 administrator tool, the CCMS performs a series of extremely important tasks. The CCMS performance tools provide you with an overview of the performance of an R/3 System on the basis of selected statistics and parameters. The tools allow you to intervene to regulate performance as necessary. Performance is assessed on the basis of response times for the R/3 System, database, operating system, and network components. The CCMS allows you to schedule and monitor background jobs and coordinate the chronological order in which they are processed. The CCMS enables you to call up information on the main memory, hard disk capacity, and backup media at any time, thus allowing you to intervene early enough and take any corrective action that may be necessary. You can use the operation modes supported by the CCMS to create different numbers of dialog and batch work processes, according to the requirements that prevail at different times of the day. You can also use the CCMS to monitor all the application servers of a system. The CCMS provides you with a number of different tools for creating database and log backups and for monitoring these. The CCMS also supports an event concept for triggering specific procedures when predefined events occur. All spool administration activities can be carried out from the CCMS.
The second lesson looks at the most important data of the different CCMS performance monitors and shows you how it can be analyzed. This means that you are always up to date on the status of the R/3 System at any given point in time, so that you can plan and implement further steps.
You can call up information on the performance of the R/3 System at any time via the Performance Monitoring menu of the CCMS. Special tools are available here for system administration. The most important performance monitoring tools are the workload analysis monitor for the transaction layer, the setup/buffers monitor for the R/3 buffers layer, the operating system monitor for the local operating system layer, and the database monitor for the database layer. To call up the performance monitors, you choose the Performance Menu. You access this system menu by choosing:
Tools, CCMS, Control/Monitoring and Performance Menu.
The Performance Monitoring initial screen is the starting point for using the four performance monitors, the workload monitor, the setup/buffers monitor for the SAP buffers, the operating system monitor, and the database monitor. To display the overviews of the analysis transaction, you have to call up the workload monitor by choosing Workload and Analysis. The other three monitors - namely the database monitor, the setup/buffers monitor for the SAP system layer, and the operating system monitor - can also be accessed from the workload analysis monitor. You should, therefore, use the workload monitor as the starting point for performance analyses. To call up the setup/buffers monitor, for example, from the Performance Monitoring screen, you choose Setup/Buffers for the SAP buffers. You then choose Buffers. The partial overview of the SAP buffers monitor displays the buffers with statistics expressed as percentage and real values. The screen can be scrolled horizontally and vertically to display further information. You can call up the operating system monitor from the Performance Monitoring screen by choosing Operating system, Local, and Activity. This monitor provides information on the operating system installed, which in the example is Windows NT. This screen can also be scrolled to display further information. To monitor the activities that take place at the database level, you have to choose Database and Activity in the Performance Monitoring screen. The database monitor is then opened. Once again, this monitor only shows part of the analysis data for the Oracle database which is installed in this example. You can display further information by scrolling the screen.
A distinction is made between different response times in the R/3 System. These have a considerable influence on the quality of the system performance and, therefore, have to be monitored on a regular basis. The average response time begins when the user request reaches the dispatcher queue and ends when the appropriate screen is sent back to the user. The response time does not, however, include the time taken to transfer this to the presentation server. The response time can be subdivided into a wait time and dispatch time, or into a wait time, processing time, load time, roll in time, and DB time, depending on the user request. The average CPU time is the time needed to execute the work process in the CPU. The average wait time begins when the user request is placed in the dispatcher queue and ends when the request made to the work process is released for processing. The wait time is, therefore, the time during which the request waits in the dispatcher queue. The dispatch time is the time that a work process needs for a user request. It does not include the wait time. The average load time is calculated from the times needed to load and generate objects from the database, for example ABAP source codes or screen information. The average roll in time is the time needed to load a user context for a work process. The average DB request time is the time required by the logical database to process a dialog step. The average processing time is the dispatch time, minus the DB request time, load time, and roll in time. All of the times described are encountered in the login example.
The workload monitor is one of the four important performance monitors of the Computing Control Management System. It enables you to display an overview of the response times and the workload of the R/3 System and to carry out extensive performance analyses. You can call up the workload analysis monitor in the Performance Monitoring screen by choosing Monitor and Performance, or via the usual menu path for calling up Performance Monitoring. You can call up the Workload Analysis Monitor via the usual menu path by choosing:
Tools, CCMS, Control/Monitoring, Performance Menu, Workload and Analysis.
In the Workload: Analysis of SAP System PB1 screen, you can specify the server for which you want to check the performance analysis. You select the server by clicking the appropriate pushbutton. You can then specify the time period for which you want to display the performance analyses of the system selected. If you want to check today’s performance data, you click the appropriate pushbutton. A scrollable overview appears with current performance information on the workload processes of the selected server for the current day. To interpret the analyses, you can choose Total (default setting), Dialog, Update, Background, RFC, or Spool. You should pay particular attention to the average response time values as these times have an immediate effect on the user. For this reason, it is advisable to check these values in a different report. To display this report, you click the Dialog pushbutton. The workload monitor then displays today’s average work process values. You can determine whether the system performance is normal or poor using general rules for interpreting the response times and their components. On the basis of the TARGET/ACTUAL comparison made between the predefined values and those displayed in the analysis, you can see that the values deviate. If the response time values are higher than normal, you should try and find the reason why in order to optimize system performance again. The possible reasons for these higher values are listed in a table. If the system response times deviate from the normal values, the workload monitor enables you to choose analyses of the previous minutes, or of specific days, weeks, or months in order to check different time periods. To analyze the response times in greater detail for a shorter period of time, select the same server again and then specify, for example, that you want to analyze the last few minutes in greater detail by clicking the Last minute load pushbutton in the Local Workload Data dialog box. In the Set Time Interval dialog box, you can enter the number of minutes for which you require more detailed information. This time interval can be between 1 minute and 999 minutes. 15 minutes have been entered in the example. The total analysis overview is displayed again for the workload monitor, in this case for the last 15 minutes. To evaluate the user transaction times for the work processes more accurately, click the Dialog pushbutton again. In contrast to the daily analysis, the values may be different again with this comparison. Having looked at the two workload analysis monitor variants for the current day and the last few minutes, you will be shown where and how to analyze periods further back in the past. To do so, select the same server again and click the Performance database pushbutton in the Local Workload Data dialog box. In the Choose Time Period dialog box, you can choose different time periods for further analysis. Since the performance values of the day before are also useful when evaluating higher response times, select the Previous days radio button. You then have to specify which one of the previous three days you want to analyze and confirm your selection. The system displays the cumulative analysis data (Total) of the period chosen. To compare the user transaction times with the previous results, call up the work processes again by clicking the Dialog pushbutton. The analysis data from the day before indicates that the average response time values are different to the values for the other two time periods. You can call up a transaction profile report by clicking the appropriate pushbutton to provide additional information on the poor performance of the system for a particular period. The Workload: Transaction Profile Report lists the transactions or programs executed. It also indicates the number of times they were executed and their respective response times. The average response time of the Main Menu program is particularly important here. If the threshold value of 150 milliseconds is exceeded, there is a general problem with system performance.
The SAP buffer monitor provides an overview of buffer and memory utilization for the current instance. This tool enables you to determine when the storage capacity of the buffers is exhausted and exported to swap areas, so that you can intervene to regulate performance as necessary. You can call up this monitor via the workload analysis monitor, or via the usual menu path for calling up Performance Monitoring:
Tools, CCMS, Control/Monitoring and Performance Menu.
To
open the SAP buffer monitor for the server selected, you choose
Setup/Buffers and Buffers. The Tune Summary overview of the SAP
buffer monitor is very detailed and can, therefore, be scrolled
vertically and horizontally in order to display all of the
chronological information. The Nametab name table contains the table
and field definitions activated in the R/3 System. These include the
four buffers Table definition, Field description, short nametab, and
Initial records which are all located in the jointly used memory
area. If buffers do not provide sufficient capacity for performing
certain transactions, additional memory is used on the hard disk of
the application server. This is referred to as swapping. You can see
this in the overview after scrolling it horizontally. Buffer swap
areas are highlighted in red. You can display details on a buffer by
double-clicking the red swap field of the buffer concerned. The Tune:
Detail Analysis screen provides further statistical information on
the size of the buffer, as well as its used and free capacity under
Size. If the Free field indicates that there is enough free memory,
but this is not available as a single block because of the gaps in
between, you have to restart the system in order to delete the gaps.
A free memory block will then be available for this buffer. To
display the profile parameters set for this buffer, you click the
Current parameters pushbutton. In the profile parameters screen, you
then have to decide whether you want to change the capacity of the
buffer via the profile parameters. This screen provides detailed
instructions on how to change these parameters.
In
the Tune Summary overview, you also have to check the SAP memory. The
SAP memory is in the second half of the monitor and includes areas
that can be occupied by any work process. It is important to note
that with Extended Memory, the value for maximum use will not be as
high as the value for In memory. If the value for maximum use is as
high as the value for In memory,
you have to increase the extended memory value by changing the
appropriate parameters. In order to find out where and how this is
carried out, double-click the Extended Memory field. The Tune: Detail
Analysis is displayed with all the technical information on the SAP
memory. You scroll the screen to display the other memory areas. To
call up the profile parameters for these memory areas, click the
Current parameters pushbutton. The Tune: Profile parameters for SAP
buffers overview contains all the information on the roll, extended
and heap memory areas. The profile parameter for extended memory
would have to be increased if the values for Max.use and In memory
were the same. If you scroll this screen, it explains exactly how you
make the necessary changes to the parameters.
The
SAP buffer monitor allows you to display further details on the
buffers. You can display the entire Tune Summary
overview by opening the monitor via the
conventional menu path. You then click the Detail analysis menu
pushbutton. The Tune: Detail Analysis Menu offers you a series of
pushbuttons for the different buffers. To display statistical
information on the buffers, for example, you scroll the screen and
click the for this server pushbutton. The screen Tune: Buffer history
of recent days contains, among other things, a chronological list of
data indicating how the buffer quality for the table definition
buffer changed each day. If you scroll further, the buffer history
indicates how many times the database of the server for the program
buffer was accessed each day. You can also see how the size of the
swap area increased.
The database monitor is one of the four important monitors for controlling the performance of the R/3 System. It provides database-specific information on the status of the database buffer and on the performance of the database. This monitor can either be called up via the workload analysis monitor, or via the usual menu path:
Tools, CCMS, Control/Monitoring and Performance Menu.
You can call up the active monitor overview by choosing Database and Activity. The overview is very detailed and can, therefore, be scrolled. The data buffer is one of the three most important database buffer areas. It stores Oracle blocks in the shared memory and measures how many times a database block requested by an Oracle process has already been loaded to the working memory. The most important value is the Quality of the data buffer which should be higher than 95%. The Buffer busy waits value indicates how many times a process has to wait in order to receive a compatible data buffer. Whereas the Shared Pool is used by Oracle for different memory structures, the redo log buffer contains information on data and object changes in the database. The allocation fault rate of the log buffer indicates how many unsuccessful attempts Oracle has made to find free memory space in the redo log buffer. In such cases, the user has to wait for buffer space to become available. If you scroll further, you will come to the field group which shows the type and number of accesses made to the database for Oracle processes. The rollback value indicates how many times an Oracle process was not able to complete the commit of an operation. In addition to monitoring database accesses, you can check the workload of the system according to users and internal operations. In the Table scans & fetches field group, the monitor indicates how the database data is accessed. A further section of the monitor shows the total number of sort operations and the number of sort operations carried out in the working memory or on the hard disk. In addition to the other statistical information in the monitor, you can also call up details on the database by clicking the Detail analysis menu pushbutton. In order to check the details of the database message log, for example, you choose this option by clicking the Database message log pushbutton. You then choose either Only alerts or All messages of the database. In the Database Performance Analysis: Oracle Database Overview screen, you can select the default parameter settings for database management by clicking the Parameter changes pushbutton (this is also possible in the next screen by clicking the Active parameters pushbutton). You can see, for example, the buffer size of the database, the number of CPUs in the database server, the number of buffered database blocks in the system global area, and the size of a database block. You can also check database locks by clicking the Exclusive lock waits pushbutton in the database performance analysis overview. A database lock occurs when a user locks a line of a table. If another user tries to process this line, this user has to wait until the first user releases the line again. If the system outputs a message indicating that it could not find any database locks, you can use the V$Lock pushbutton to find and, if necessary, eliminate tasks that are locked. This type of lock permits read access to the resource type but not write access.
The operating system monitor is one of the four important tools for monitoring system performance. This monitor provides information on the CPU workload, on the memory configuration and capacity, on swaps, and on the hard disk capacity. You can call up the operating system monitor via the workload analysis monitor or via the usual menu path:
Tools, CCMS, Control/Monitoring and Performance Menu.
You
activate this monitor via the Operating system menu and then specify
whether you want the monitor to be displayed for your own system or
for one of the systems in the group. You want to display the
performance analyses for your own system. To do so, you choose Local
and Activity. The monitor then provides an overview of the
statistical and technical data for the internal system. The most
important values in this part of the report are the CPU Utilization
idle and the Load average. The idle
value should always be above 30% and the load average should not
exceed 3, for between one and fifteen minutes. A series of functions
are made available when you click the Detail analysis menu
pushbutton. These functions can be used to call up specific analyses.
To display details on the processor, for example, click the CPU
pushbutton in the Snapshot
analysis field group. This dialog box shows the CPUs installed
together with their current usage values broken down according to
User, System, and Idle. If you choose the file system function in the
Snapshot analysis field group, the
current values for the free and occupied hard disk memory are
displayed. To display the current workload of the work processes, you
click the Top CPU processes pushbutton in the Snapshot analysis field
group. It indicates, among other things, the current percentage and
time values of the R/3 work processes dispatch and work.
By
clicking the OS collector pushbutton, you can find out more about the
OS collector. This collates selective statistical information on the
entire R/3 System. You can also display the status of the collector
in order to find out how it is reported. The Status report indicates
that the OS collector is active. The report also tells you when the
collector was started and for how long as well as when it is, or was,
active. It is important that this report is running as it provides
all the statistics for the operating system monitor.
The third lesson introduces you to the most important CCMS transactions that support the day-to-day work of the R/3 administrator. These transactions include process and user overviews, database checks, and background jobs.
Important tasks that are carried out during the day-to-day work of the R/3 System administrator include monitoring the process and user overviews, system logs, background jobs, short dumps, databases, updates and locks, as well as performance monitoring. These tasks serve to analyze the overall status of the R/3 System on a daily basis.
Daily monitoring of the system includes maintaining an overview of all the application servers of an R/3 System, the status of work processes, and all the users currently logged onto the system. There are two different ways of calling up the three transactions for the server, work process, and user overviews. You either enter the transaction name in the command field, or you choose the usual menu path which is the same for three transactions for the server, work process and user overviews. You can call up the transactions by choosing:
Tools, Administration, Monitor and System monitoring.
You can then call up each of the individual transactions Process overview, Servers, or User overview from this submenu. In the Servers transaction, you can also switch to the other two transactions. To call up the server overview and to find out how to switch to the other two transactions, you call up the Servers transaction. The SAP Servers screen lists the names of the active servers. The work process types are also displayed alongside this. To display the status overview for these work processes, you can switch to the process overview transaction. If necessary, you can also switch to other transactions from this server overview. You do this by choosing the appropriate function in the lower application toolbar. You can display the status of the work processes by clicking the Processes pushbutton. The Process Overview indicates which work processes are active and which processes are waiting. In the case of the active work processes, you can see the reports as well as the client and user under which the processes were activated. To check the user overview, you have to call up the SAP Servers screen and select the name of the server for which you want to display an overview of all the users currently logged onto the system. To display the list of users for the selected server, click the User pushbutton. This will switch the transaction again, this time to the user overview. This part of the user list displays the users currently logged onto the system, the client and terminal at which they are logged on, and when the last action was carried out in the system. To show the traces, you have to scroll the screen horizontally.
The
R/3 System includes a number of transactions for system
administration. These transactions help you detect errors or
irregularities in the system and suggest possible solutions. The
transactions include system logs, dump analyses, and background jobs.
All important R/3 actions are recorded in the system log.
By checking this system log report on a daily basis, you can identify
variances that can be examined in greater detail in dump analyses.
The background jobs transaction SM37 identifies bottlenecks or errors
that occur when background jobs are executed. If a job is not
executed properly, you have to take appropriate measures to remedy
this.
The system log is also known as
transaction SM21. You can call this up from the Servers overview or
by choosing the usual menu path:
Tools, Administration, and Monitor.
To call up the transaction, choose System log. You then have to specify the type of R/3 activity you want to display in the system log report as well as the time at which these activities took place. The current date and time and other settings are entered by the system. You can, if necessary, change these values. If you want the check to be carried out for the whole of the previous day, you have to enter appropriate values in the From date/time fields. All of the other default settings can be retained here. To check the R/3 activities for the period of time selected in the display, click the Reread system log pushbutton. All system log entries for the internal system are then displayed in chronological order for the time period selected. Alongside the names of the clients and users, you can see different texts which describe how the tasks or reports were executed. W or K is entered in column C for activities during which a problem occurred. The letters are also highlighted in different colors which indicate specific problem classes. A yellow W is relatively harmless, whereas a red K indicates an invalid activity. Double-clicking the line of an activity with a red K, for example, provides you with further details on this critical activity. The system then displays detailed information on the task and the problem class. The system also displays a detailed description of the cause of the error and the situation in which it occurred. If you scroll further, the log may contain short dumps with the red problem class. These short dumps are usually written for transactions or reports of ABAP programs that were terminated abnormally. You should always check the details of these dumps. You can display these details by double-clicking the appropriate line. The detail overview provides more information on the invalid task and on the problem and development class of this short dump. If you scroll the detail overview, you will see a detailed description of the problem and instructions on how to analyze this short dump further. Next, you want to check the error identified in the system log report. This dump analysis is also known as transaction ST22. You can call up the transactions by choosing:
Tools, Administration, and Monitor.
To
call up the transaction, choose Dump analysis. The ABAP Dump Analysis
screen lists the number of short dumps
carried out today and yesterday. To analyze a short dump in greater
detail, click the appropriate radio button. You can display
information on a short dump by clicking the Display list pushbutton.
To display more detailed information on what actually happened when
the first short dump was executed and on further measures that you
can implement to rectify this situation, you double-click the first
text line.
Another important
administrative task involves managing scheduled background jobs on a
daily basis. These jobs are user or job specific depending on
requirements. This transaction is also known as SM37 and can be
called up by choosing:
CCMS and Jobs.
You then choose Maintenance. In the Select Background Jobs screen, you can enter different selection criteria to restrict the job to be processed. If you want to list all pending jobs so that you can check them, the only setting made is for the period starting on the day before and ending on the current day. The alphabetical Job Overview is divided into columns which indicate the status of a background job. If a job has the status Canceled, you have to call up further details and try and find the reason why. You can display details by double-clicking the job name.
Three important transactions are supported for monitoring and maintaining the database. These enable you to check database consistency and to schedule, monitor, and log backups and database checks. Transaction DB02 provides you with an overview of how the database is assigned and used. In order to check these values, you call up the transaction by choosing:
Tools, CCMS, Control/Monitoring, Performance Menu, Database and Tables/Indexes.
The Database Performance: Tables and Indexes overview provides information on the capacity of the database, expressed as percentage and real values. It is important to check the percentage value displayed for Total free/kb. The current value in the example is 30%. The values of the last three fields should always be 0, both in the Tables and Indexes columns. If this is not the case, details can be called up by clicking the Missing indexes and Space critical objects pushbuttons. The total capacity of the database is displayed in the example in the field Total size/kb under Tablespaces. 70% of this capacity is currently being used. To find out how this is distributed, you click the Current sizes pushbutton. The Memory Management: Tablespaces screen provides information in the Size column on the size of the individual tablespaces. The Free column indicates how many kb of this are still free. The Used column indicates how much of the individual tablespaces is used in relation to the total capacity of the database. If the Used value for a tablespace is over 90%, this tablespace should be expanded gradually. Transaction DB02 allows you to switch directly to transactions DB13 or DB12 for planning, checking, and monitoring database backups. To do so, you have to enter /ndb13 or /ndb12 in the command field. You call up the initial screen for transaction DB13 or DB12 by following the usual menu path:
Tools, CCMS and DB Administration.
You
call up transaction DB12 for checking the database backup history via
Backup logs. To call up transaction DB13, which you can use to plan
database backups and carry out checks, you choose
DBA scheduling. All database backups
have to be entered in the calendar overview DBA Planning Calendar of
transaction DB13 with their respective dates and times. Green is used
in the calendar to indicate that the backups scheduled were carried
out successfully. If this changes to red, you have to check for
errors. In the event of an error, or at any other time for that
matter, you can reconstruct the steps performed during the backup by
selecting the appropriate backup entry and calling up the log via the
Job logs pushbutton. The backup entry chosen is selected and the log
can be called up by clicking the Job logs pushbutton. The Job Logs
screen indicates the backup status and the time it took to save the
data. If necessary, you can also display a detailed backup log.
You
can check the history of the database backups using transaction DB12.
You can also list the backups already performed according to
different criteria. If you click Overview of database backup logs,
for example, you can call up an overview of all the database backups.
You can display a detailed overview or cumulative overview
(chronological) of the redo logs by choosing the appropriate
functions.
There are two transactions in the R/3 System that adjust lock entries in tables and update terminations that were caused by system or program terminations, for example. These are the transactions Lock Entries, SM12, and Update, SM13. When a user in the R/3 System accesses a table, this table is locked. Transaction SM12 lists all the tables currently locked or unlocks them, if existing locks are not to be reset via system or work process terminations. If data is added, modified, or deleted in the R/3 System, a distinction is made between phases V1 and V2 when an update is performed. If the update is terminated during one of the two phases, it is listed in transaction SM13. An attempt is then made to perform the update again or the update is deleted. The two transactions Lock Entries SM12 and Update SM13 are called up via the same menu path :
Tools, Administration and Monitor.
In
the expanded Monitor menu, you can then choose one of the two
transactions, Lock entries or Update. To determine which table locks
are currently set, you choose Lock entries. In the
Select Lock Entries screen, you can use
the selection criteria offered to choose an individual or a series of
lock entries. You can choose and check a specific locked table, for
example. If you want to check a list of all the current lock entries,
you have to delete all the selections. In the list of locked entries,
you then have to decide whether you want to unlock a single table or
all tables using the delete function. To unlock a single table, you
have to select the appropriate line. You can then remove the lock for
the entry selected by choosing Lock entry and Delete. You have to
confirm that you want to delete the lock entry in a dialog box.
Before doing so, you should consult the user responsible.
Another
transaction used in conjunction with system or program terminations
is Update, SM13 for update terminations. In the Update Records: Main
Menu, you can, if necessary, select the client, user, update status,
and time period for which you want to create the list of terminated
updates. If the system finds an update termination for the time
period selected, this is displayed in the Update Records list
together with the client, user, date, time, and transaction code for
the update record. To find out which type of update module this
update record belongs to, you select the information line of the
update record and call up the update module of the update record by
clicking the appropriate pushbutton. In addition to the name of the
update module, the update type (V1 or V2) is also selected in the
update module overview. The update has to be carried out again using
the transaction in which it was terminated. The update termination
has to be deleted in this transaction beforehand, however. To delete
the update termination, you choose Update Records and Delete. You can
specify whether you want to delete individual or all update records.
The four most important transactions supported by the R/3 System for daily overviews and performance checks are ST03, ST02, ST04, and ST06. This means that you can call up information on the quality of the system performance at any time. This transaction provides an overview of the workload, the SAP buffer area, database performance, and operating system performance of the R/3 System. You can call up these four transactions either via the Performance Monitoring menu or via the workload analysis monitor. The four transactions are called up using the same menu path:
Tools, CCMS, Control/Monitoring and Performance Menu.
Each
of the four transactions can all be called up from the Performance
Monitoring screen.
The workload analysis monitor also allows you to display analyses on
the instances shown here. In the Local Workload Data dialog box, you
specify the criteria according to which you want to list the
analysis. In the Choose Time Period
dialog box, you specify the period of
time for which you want to display the results. To choose a three-day
period that you can define more precisely later on, you select the
Previous days radio button. In a further dialog box, you specify
which one of the previous three days you want the analysis to be
based on. The system then displays the performance workload overview
for the chosen time period for which different task types can be
chosen. You should display the response times which are important for
the user in the dialog work processes report.
The
other three monitors, for example the SAP buffers monitor, can be
accessed easily from the workload analysis monitor by choosing
Monitor and Performance. Of the parameters listed here, the maximum
use value for the Extended Memory is particularly important. It must
not be as high as the In memory value. When checking the analysis,
you should also make sure that the storage capacity of the buffers is
adequate. If the buffer is overloaded, the swap field of the buffer
will be highlighted in red thus indicating that additional memory is
required. If gaps occupy a considerable percentage of the capacity of
the buffer, the used capacity will be released again when the system
is restarted. Otherwise, you can click the Current parameters
pushbutton to adjust the parameters and increase the capacity.
When
checking the database monitor, you should pay particular attention to
the Quality value of the Data buffer which should be higher than 95%.
If not, this buffer has to be increased carefully or you should try
to improve the SQL statements.
The
most important value in the overview of the operating system is
Utilization idle. It is important to make sure that this value does
not fall below 30% and that the load
average does not exceed 3, for between one and fifteen minutes.
The fourth lesson takes a closer look at alert monitoring, and explains how to use it, and how it will help you to monitor the R/3 System continuously on a daily basis. It also shows you the advantages of having your own alert monitor.
Alert Monitoring is an integral part of the CCMS and enables you to monitor the R/3 System on a continuous basis. Alert monitors warn against possible bottlenecks. They enhance availability and facilitate administration of the R/3 System. The alert monitors clearly indicate system bottlenecks and errors by means of green, yellow, and red traffic lights. Alert Monitoring in Release 4.0 also enables several R/3 Systems to be monitored simultaneously from one R/3 System.
The alert monitor uses the colors red, yellow, and green to indicate the status of the R/3 Systems being monitored. Bottlenecks or errors, in other words alerts, are indicated using yellow and red. These alerts must then be followed up. You can call up the initial screen for the alert monitor by entering the transaction name /nrz20 in the command line or by choosing:
Tools, CCMS, Control/Monitoring and Alert Monitor (4.0).
In the CCMS Monitor Sets screen, you call up the basic monitor by double-clicking the node underneath Monitor sets. You then have to select the basic monitor in order to load it and work with it. You can load the monitor in two different ways. You either click the appropriate pushbutton or choose Edit and Load monitor. In doing so, you call up the SAP domain in which you can expand and check the nodes for your R/3 System. The alert monitor first has to be updated, however, via the Current status pushbutton as the system indicates that no alert data is available. You then click the Open alerts pushbutton to instruct the system to check for any unprocessed alerts. The system outputs a message indicating that open alerts have been found. The color of the system PB1 in the example changes to red which indicates that there is a problem with this instance. To follow up the problem, you double-click the node in front of the system to open the next level down in the system hierarchy of this instance. You can then see the server and spool system at the next level down. The field highlighted in red takes you one step further to the cause of the problem. You can then open the next level down by double-clicking the appropriate node. This system of colors makes it relatively easy to work your way back to the cause of a problem. In keeping with the system’s hierarchical structure, red alerts are always displayed at the top node and can be broken down until the problem area is found. In addition to the red problem nodes, you will come across white nodes without any data, green nodes that are OK, and yellow nodes which are used as warnings. To process a yellow or red alert, you have to click the checkbox in front of the appropriate alert. You can display more detailed information on the selected object by clicking the Display alerts pushbutton. The system then displays more detailed information on the object, for example on its status and attribute, and on the date and time at which the problem occurred. To call up an analysis tool for this object, select the checkbox at the start of the line again and call up the tool via the Start analysis tool pushbutton. The monitor with the analysis overview for the problematic object is then displayed automatically. This could be the SAP buffer monitor, for example, if the capacity of an SAP buffer is too low. You can then decide how you want to rectify the problem. You can, for example, expand the buffer or delete the gaps in the buffer. Once the alert problem has been rectified, you have to select it as being completed. You can do this by clicking the Complete alerts pushbutton. Once the alert has been completed, the system outputs a message indicating that no further alerts exist. All the nodes are green, indicating that all the problems have been resolved.
You can define your own monitors in the alert monitor. Database administrators can, therefore, create their own monitors with relevant database information. You can call up the alert monitor for creating your own monitor by choosing:
Tools, CCMS, Control/Monitoring and Alert Monitor (4.0).
In the CCMS Monitor Sets screen, you first call up the basic monitor by double-clicking the node underneath Monitor sets. You can load the monitor either by clicking the appropriate pushbutton or by choosing Edit and Load monitor. You then select the areas from the hierarchy trees that you want to assign to your own monitor. You can also choose areas from different R/3 Systems. To do so, you have to open the appropriate branches of the nodes and select the areas from the hierarchy trees that you want to assign to your own monitor. Once you have selected the sub-trees, you create the monitor you have defined by choosing Monitor.
In the R/3 System, standard threshold values can be adapted to suit the requirements of your own system or new tools can be developed for alert monitoring. These changes can be made using the alert monitor. You can call up the alert monitor by choosing:
Tools, CCMS, Control/Monitoring and Alert Monitor (4.0).
In the CCMS Monitor Sets screen, you call up the basic monitor by double-clicking the node underneath Monitor sets. You then have to select the monitor with which you want to carry out the changes. Following this, you load it so that you can work with it. You can load the monitor in two different ways. You either click the appropriate pushbutton or choose Edit and Load monitor. You then have to decide for which nodes the threshold values need to be changed. To do so, you open the instance nodes to find out where the problems lie (indicated by the color of the node). The system then indicates the number of alerts, the colors of which change on a regular basis when the preselected time period is compared with the predefined percentage threshold values. You can then adjust the preselected threshold values for the node in question. To do so, you select the appropriate node and click the Customizing pushbutton to call up the change mode in order to reset the threshold values. After you have changed the threshold values, the statistical alert values of the node are no longer up to date. To update these values, you call up the alerts of the selected node via the Display alerts pushbutton and select the checkbox at the start of the line of each alert. To mark the alerts as completed, you click the Complete alerts pushbutton. Once the alerts have been processed, the nodes displayed are green again.
The fifth lesson provides you with an overview of the traces and logs used in the R/3 System. You will learn, for example, how to display startup and work processes, operating system error logs, and database message logs from the R/3 System, in order to analyze them.
The R/3 System enables you to display individual logs and traces that were written during the startup phase. The same transaction is used to check the logs that were created for each individual work process. To call up the transaction, you choose:
Tools, Administration, Monitor, Traces and Developer traces.
The logs displayed are extremely detailed and can, therefore, be scrolled. The traces and logs listed below can be selected in the error log and the detailed work process logs checked via the Display pushbutton.
The
startup traces and logs have the following names:
1.
sapstart. log, sapstart.trc Log and trace log of the SAP
startup
procedures
2.
stderr1 Startup log file for the database
3.
stderr2 Startup log file for the message server
4.
stderr3 Startup log file for the dispatcher
The
names of the work process traces are as follows:
5.
dev_ms Trace file of the message server
6.
dev_disp Trace file of the dispatcher
7.
dev_w0...n Trace file of the individual work processes
These traces and logs are located at the operating system level in the directory usr\sap\<SAPSID>\<Instance_name>\work. If you encounter problems when the system is being started up or if a work process is aborted, these traces and logs will provide you with more detailed information.
You can display the log of the operating system used from the R/3 System, to analyze operating system errors or malfunctions. You can call up the reports of the logs in the operating system via the operating system monitor. You can call up this transaction by choosing:
Tools, CCMS, Control/Monitoring, Performance Menu, Operating system, Local, Activity (transaction ST06) and Detail analysis menu.
To display the overview of the operating system log, click the appropriate pushbutton in the Previous hours field group. This overview is broken down according to time and events and can be scrolled.
If problems occurred at the database level that have to be analyzed, the R/3 System enables you to display the database message log for the database used. You can call up this transaction by choosing:
Tools, CCMS, Control/Monitoring, Performance Menu, Database, Activity (transaction ST04), Detail analysis menu and Database message log.
The Database Messages overview contains a series of informative values and parameters that you can display by scrolling the screen. The processes line, for example, tells you how many processes Oracle can process simultaneously. The shared_pool_size line provides information on the buffer areas defined. The entry in the log_buffer line provides information on the log buffer area defined. If you scroll further, you can see the log entries for sequences which are numbered consecutively. Every entry is duplicated in the line directly underneath.
In this case, integration of an R/3 System in the transport domain.
Tool of the CCMS which enables the R/3 System to be monitored on a continuous basis by means of traffic lights.
Warning indicating that a problem has occurred with a particular object in the R/3 System. The node of the SAP domain is displayed in yellow (warning) or red (error).
R/3 System that can assume the functions of the transport domain controller if the transport domain controller fails (backup concept).
Computing Center Management System; provides a series of tools in particular for monitoring and checking the R/3 System.
Option in Client Maintenance which is used to specify whether or not client-dependent changes and transports and/or changes to client-independent objects are allowed.
Transaction SCCL; copying client-dependent data of a client to a new empty client within an R/3 System.
Transaction SCC8; transporting client-dependent data with/without client-independent Customizing data of the client of one R/3 System (source system) for creating the client in a second R/3 System.
Transaction SCC4; transporting the exported data of the source client of one R/3 System to the target client of a second R/3 System (target system).
Entry of client-dependent Customizing data which is transported from an R/3 System to the successor system.
Information file of a change request (for Repository objects and Customizing settings); integral part of a transport request; contains, among other things, information on the transport type, object class and any necessary import steps; is located in the central transport directory (usr/sap/trans for UNIX; usr\sap\trans for Windows NT).
Contain system-specific information on the execution of completed client exports, client imports and client copies.
The Change and Transport Organizer is a tool for organizing software development projects.
Transaction SE10; module of the CTO; can be used to manage transport requests of client-independent Repository objects and client-dependent objects.
Options for adapting default threshold values to company-specific requirements via the alert monitor.
Integral part of the database monitor; enables database messages to be displayed and analyzed in the R/3 System.
Transaction ST04; performance monitor of the CCMS; provides, among other things, information on the status of the database buffer and database performance.
Daily tasks involved in maintaining, checking, monitoring and administering an R/3 System and the modules of the CCMS.
Name of the R/3 System that assumes the functions of the transport domain controller within an R/3 system landscape.
Transaction ST22; lists the number of short dumps from the previous and current days; enables short dumps to be analyzed in greater detail thus helping to identify the problem; also displays additional criteria which can be used as a basis for starting an error search in the Online Service System (OSS).
A table is read or write locked when a user accesses a table; this prevents other users accessing the same table (see also Lock Entry/Lock Entries).
Non-contiguous memory space within a buffer, for example; cannot be used individually; gaps are relocated to form one single memory block by restarting the R/3 System.
In this case, copying the objects of an exported transport request to the target client of the target R/3 System; module of the TMS.
Tables, which are read or write accessed, are locked by means of enqueue work processes at the row level (shared locks, exclusive locks); transaction SM12 lists all the tables currently locked or unlocks them, if existing locks are not to be reset via system or work process terminations.
A namespace is used to group Repository objects for client-independent Customizing; the first few characters, or the prefix, are usually the same.
Function within the operating system monitor; enables operating system messages to be displayed analyzed in the R/3 System.
Transaction ST06; operating system monitor; performance monitor of the CCMS; provides information on CPU utilization, memory configuration and utilization, as well as disk utilization.
Tool of the operating system; collates selective statistical information on the R/3 System for statistical purposes and overview; always has to be active.
User-defined monitor within the alert monitor; enables, for example, a database administrator to monitor the database areas of all the R/3 Systems in a system landscape.
Provide an overview of the workload and performance of the R/3 System; transactions: Workload Analysis Monitor (ST03), SAP Buffer Monitor (ST02), Database Monitor (ST04), Operating System Monitor (ST06).
In this case, function performed within transport request management ; stores a transport request at the operating system level.
See SAP Buffer Monitor.
Table locks; usually a read access to a table; this means that several users can access a table simultaneously.
Startup log file for the database.
Startup log file for the message server.
Startup log file for the dispatcher.
Indicates the storage capacity that has been exported to swap areas in the event of insufficient memory.
Option in transaction SE06 which enables you to specify whether or not changes and transport requests are allowed in an R/3 System.
In this case, list of all the systems created in a transport domain; provides information on the type and status of a system within a transport domain.
Performance data on the times required to execute individual processing steps in an R/3 System; should be monitored at regular intervals on the basis of the recommended threshold values (general rules for interpreting response times).
Part of a transport request for Repository objects and Customizing settings; contains project objectives as well as status and other special information. A task is sent together with a transport request.
Unit(s) of measure for relative variable or time-interval comparisons in the R/3 System; supplied as default values recommended by SAP; can usually be adapted to suit individual requirements.
Transport Management System; transaction STMS; organizes, monitors, and carries out all transport requests within a system landscape.
Most important functions performed by the TMS:
- Defines the role of an R/3 System within a
system landscape or
transport domain
- Configures transport routes using a graphical or hierarchical list editor
- Lists the import queues of all the R/3 Systems
in one transport
domain
- Starts the import of transport requests from one import queue
- Performs transports between R/3 Systems
with/without common
transport
directory
Used in alert monitoring to indicate the status of
the R/3 System.
Green = everything is
OK, yellow = warning and red = error.
Central directory containing the files of all released transport requests from the Workbench Organizer and Customizing Organizer; TMS accesses command files and data files directly in the transport directory (path: usr/sap/trans).
Module of the TMS; contains all the R/3 Systems administered by the TMS; before the TMS is used for transports, all R/3 Systems in the transport domain have to be defined and configured.
R/3 System for administering transport domains (domain controller) within a system landscape; the other R/3 Systems are supplied with copies of the transport domain of the controller system.
Client export/import, client-dependent transport and client-independent transport.
Contains developments and changes made to objects in an R/3 System which are transported to the successor system of an R/3 System landscape; a distinction is made here between client-dependent and client-independent transport requests.
Transport routes specify how and where transport requests are forwarded to within a system group; the routes are defined/configured using a graphical or hierarchical list editor in the TMS.
Transaction SM13 is used to list and delete update terminations of inserted, modified or deleted data; depending on the update phase (V1 or V2), an update termination is deleted before or after the update; the person responsible for the update should be consulted beforehand.
R/3 Systems configured as placeholders for R/3 Systems in a system landscape that have not yet been installed; transport routes can be defined for virtual systems and the import queue set up and displayed; the systems are created in the domain controller (PB1 system).
Transaction SE09; tool of the CTO; can be used to manage transport requests of client-independent Repository objects.
Transaction ST03; performance monitor of the CCMS; provides an overview of the system response times and workload of the R/3 System; initial monitor for accessing the three other Performance Monitoring monitors.