SAP Labs - SAP R3 Overview

BC360
Introduction
R/3 Basis R/3 Basis Administration Administration 4.0 4.0
Introduction
SAP AG
BC360 Technical Core Competence
2-1
BC360
Introduction
Course Roadmap
Introduction CCMS Configuration
Database Adm inistration and Backups DBA: Daily Check Procedures
Starting and Stopping R/3
System Monitoring Background Processing
R/3 Authorization Installation Check Data Archiving in R/3
SAP Online Service System
Software Logistics Spool and Print
SAP AG
2-2
BC360
Introduction
Introduction
Contents:
Review essential R/3 term s and concepts Recap some basic R/3 system steps (as described in SAP50)
Objectives:
At the end of this unit, you will be able to: Explain certain important R/3 concepts and terminology Outline the system steps triggered during an R/3 logon or while a transaction is being executed
SAP AG
2-3
BC360
Introduction
R/3 System Clients
SD Vertrieb MM M aterialMaterialwirtsch. PP Prod. planung
Client 000 Client 001 Client 066

FI Finanzwesen CO Controlling
Default clients
QM Qual.m anagem ent PM Instandhaltung HR Personalwirtsch.
R/3 Basis
Client 100
TR Treasury
Client 200
PS Projektsystem WF WF W orkflow Workflow IS Branchenlsungen
Customer clients for separating and isolating business data
Client xxx
SAP AG
R/3 System clients are organizationally independent. Each client has its own data environment with its master data and transaction data, user master data, and its own customizing parameters. Users in different clients co-exist in the same R/3 System, but their data is isolated and cannot be accessed from another client. Only users with the necessary authorizations can view or process data in a specific client. This isolation concept is reflected in R/3 table design, both at the application level and in Customizing, which is a customer-specific adaptation of the R/3 System. Client 000 is defined as the SAP standard and may not be changed by the customer. This client serves as a copy template for the creation of further clients. A maximum of 997 clients can be created by the customer.
2-4
BC360
Introduction
R/3 System Logon Steps

Ex.: IP: X.Y.Z.10
2
Ex.: IP: a.b.c.73 SAPGUI

10 3
IP: X.Y.Z.20 Dispatcher
IP: X.Y.Z.10 Dispatcher
M
9 4
...
5
D
8
...
Database processes
7 6
Database
SAP AG
When a SAPGUI process is started on the front end, a command line parameter is sent, indicating one of the following: A specific dispatcher can be accessed directly The logon must first be sent to the message server for purposes of logon load balancing When using logon load balancing, the message server returns the IP address and instance number of a specific dispatcher. The number of dispatchers available for a particular logon is configured in the system. Logon load balancing is useful if certain user groups are assigned to work on specific servers. The message server returns the IP address of one of these assigned dispatchers, which has for example shown the best response time during the last five minutes. Response times are stored in the collected Workload data. The frontend process then connects to the assigned dispatcher, which selects a free dialog work process to compare the logon user data with the user data stored in the database. If the logon user data does not agree with the stored user data, no logon is allowed. If the logon is successful, this dispatcher and its work processes are used for the duration of the session. If a user logs off and then logs on again to the system, logon load balancing may cause the message server to select another dispatcher for the user to work with.
2-5
BC360
Introduction
Defining "Instance" and "Application Server"

Instance A
Dispatcher
Instance B
Dispatcher
...
...
Central Instance C
Dispatcher
...
M essage server
SAP AG
An instance is a group of R/3 services which are started are stopped together. Usually the term signifies one dispatcher with its work processes, although strictly speaking, other standalone services such as a Gateway can be called an instance. A central instance is a dispatcher offering all the R/3 system processes: DVEBMGS. In this example, see Instance C, where all the processes except the Gateway are shown. An R/3 application server consists mainly of a dispatcher, its work processes and main memory assigned to it. In the R/3 environment, client and server are often considered as software, therefore several application servers can run on one computer. From the hardware point of view, however, an application server can be defined as a computer on which at least one dispatcher, also called a dialog instance, is running. The following restrictions apply to the number of each type of work process: Dialog: each dispatcher needs at least two dialog work processes (not shown above) Spool: 1 / R/3 System (more than one per dispatcher allowed) Update: 1 / R/3 System (more than one per dispatcher allowed) Background: 2/ R/3 System (more than one per dispatcher allowed) Enqueue: =1 / R/3-System (only one Enqueue work process is required and allowed)
2-6
BC360
Introduction
System Dialog Step

Dialog request queue
2 1 3
Dialog work process

5
Taskhandler Dynpro processor

6
Dispatcher
SAPGUI
9 8
ABAP processor Database interface
12
10
Roll in
4
Roll out
11
Database
User context in main mem ory
SAP AG
Once you have established a connection with a dispatcher through the SAPGUI, and a session is started for you in the system, the following steps are executed for each request: Data is passed from the SAPGUI to the dispatcher using the SAPGUI protocol based on TCP/IP The dispatcher classifies the request and places it in the appropriate request queue The request is passed in order of receipt to a free dialog work process The subprocess taskhandler restores the user context in a step known as roll in. The user context contains mainly data from currently running transactions called by this user and its authorizations The taskhandler calls the dynpro processor to convert the screen data to ABAP variables The ABAP processor executes the coding of the Process after Input module (PAI module) from the preceding screen, along with the Process before Output module (PBO module) of the following screen. It also communicates, if necessary, with the database The dynpro processor then converts the ABAP variables again to screen fields. When the dynpro processor has finished its task, the taskhandler becomes active again The current user context is stored by the taskhandler in shared memory (roll out) Resulting data is returned through the dispatcher to the front end
2-7
BC360
Introduction
W ork Process Multiplexing

...
Request queues
1
Dynpro100 Dynpro200
SAPGUI
9 10 18
Request queues
...
Dispatcher
M
8 3
11
Dispatcher
17 12
...
4
D
7
B
13
D
16
...
Database processes
6 15 5
Database
SAP AG
14
If a transaction involves the use of more than one screen, the system dialog steps shown on the preceding page are normally performed by several different dialog work processes in a dispatcher. This is known as work process multiplexing. Each dialog request is first placed by the dispatcher in the dialog request queue, from where it can later be assigned to a free dialog work process. The work processes do not perform database operations. Rather, they pass data and commands to the assigned database processes using their own database interface.
2-8
BC360
Introduction
Summary of this Unit

In this unit, you have reviewed the following:
The steps executed in R/3 during logon The terms instance and application server, as used in the R/3 environment Processing of a system dialog step Work process m ultiplexing as performed by dialog work processes
SAP AG
2-9
BC360
Introduction
Further Documentation
SAP50 - Basis Technology SAP Technology Infrastructure (Brochure available in SAPNet under Inform ation R/3 System - Basis Technology) R/3 Online Documentation OSS Notes: 39412 (Number of W orkprocesses) 21960 (2 Instances on one computer) 5424 (FAQ: enqueue/locking) and others in BC-KRN-CST
SAP AG

R
SAP AG
2-10
BC360
2-11
BC360

Contents:
Processes and services in an R/3-UNIX-Oracle environment Start and stop processes and procedures
Objectives:
At the end of this unit you will be able to: Describe R/3 start and stop processes Explain the relationship between database processes, R/3 processes, and operating system processes Start and stop an R/3 System Analyze error situations during system startup or shutdown
R
SAP AG
Once you have completed this unit you will be able to: Describe R/3 start and stop processes Explain the relationship between database processes, R/3 processes, and operating system processes Start and stop an R/3 System Analyze error situations during startup or shutdown
2-12
BC360
Course Roadmap
Introduction CCM S Configuration
Database Administration and Backups
DBA: Daily Check Procedures
System M onitoring Background Processing
R/3 Authorization SAP O nline Service System Data Archiving in R/3
Installation Check

R
SAP AG
2-13
BC360
Starting the R/3 System

R/3 administrator tasks
Operating system UNIX UNIX shell
Logon
1
<sid>adm
<host>> startsap ( startsap_<host>_<instance no>)
2 3 4 5
Central Instance
saposcol
Database
SAP AG
The operating system user logs on to the UNIX operating system as user <sid>adm. To start R/3, run the shell script startsap_<host>_<instance_no> from the home directory of user <sid>adm. The script startsap_<host>_<instance no> has the alias "startsap". startsap starts the saposcol process, which is the statistics collector for operating system resource data, if it is not yet running. startsap calls the script startdb, which starts the database if it is not already started. startsap then starts the central instance. The R/3 administrator can start additional instances and application servers. To start the instances independent from the database, use the startsap script. startsap has the following options: startsap r3: Checks if the database is running; if it is, only the instance is started startsap db: Starts only the database startsap all: Default entry; starts both the database and the R/3 instance
2-14
BC360
Starting the R/3 System

UNIX shell
Start profile
Instance startup sequence
> startsap_<host>_<nr>
sapstart
Default and instance profile Processes
SE
CO
MS
Disp+work
Services
WP
WP
gwrd
Connection
Database
SAP AG
This graphic displays the R/3 start procedure in more detail. The startsap script calls program SAPSTART. Program SAPSTART reads the start profile /usr/sap/<SID>/SYS/profile/START_<INSTANCE>_<hostname> and starts the listed R/3 components or services. On a central instance, SAPSTART starts the message server, dispatcher, collector, and the sender. On a dialog instance, only the sender and the dispatcher are started. The collector and sender are used to implement the central R/3 System log. The dispatcher forks and creates child processes, such as the work processes and the gateway reader. The work processes are created according to the information in the profiles /usr/sap/<SID>/SYS/profile/<SID>_<INSTANCE>_<hostname> and /usr/sap/<SID>/SYS/profile/DEFAULT.PFL. The gateway reader, however, is not dependent on the profiles, and it is always started. The work processes then connect to the database, which is already running.
2-15
BC360
Process Overview at the Operating System Level

UNIX shell host> ps -ef | grep ora oratc1 26348 1 0 14:32:23 ? host>ps -ef | grep sap.TC1 tc1adm 12812 12804 0 Apr 29 tc1adm 12806 12787 0 Apr 29 tc1adm 12805 12787 0 Apr 29 tc1adm 1691 1 0 Apr 22 tc1adm 12787 1 0 Apr 29 tc1adm 12809 12804 0 Apr 29 tc1adm 12811 12804 0 Apr 29 tc1adm 12804 12787 0 Apr 29 0:00 oracleTC1 (DESCRIPTION=(LOCAL=NO
? ? ? ? ? ? ? ?
0:07 0:00 0:00 221:17 0:00 58:09 2:27 3:32
dw.sapTC1_DVEBMGS00 pf=/usr/sap/ se.sapTC1_DVEBMGS00 -F pf=/usr/sap/ co.sapTC1_DVEBM GS00 -F pf=/usr/s /usr/sap/TC1/SYS/exe/run/saposcol /usr/sap/TC1/SYS/exe/run/sapstart pf=/us dw.sapTC1_DVEBM GS00 pf=/usr/sap/ dw.sapTC1_DVEBMGS00 pf=/usr/sap/ dw.sapTC1_DVEBMGS00 pf=/usr/sap
Dispatcher; parent process is sapstart
R/3 work process forked by the dispatcher
Collector and sender started by the dispatcher

R
SAP AG
The process IDs of the various R/3 processes clearly show the R/3 startup procedure. sapstart creates the dispatcher, collector, and the sender. saposcol is started directly from the startsap script. The UNIX init process has the process ID 1.
2-16
BC360
Assigning Parameter Values
3 2
Instance profile
R/3 work processes
Default profile
Param eter read sequence
1
C source
SAP AG
In order to provide a stable startup procedure, the parameter read sequence (also known as the parameter replace sequence) is defined during startup as follows: R/3 processes read the appropriate parameters from a C source in the R/3 kernel The default profile /usr/sap/<SID>/SYS/profile/DEFAULT.PFL is read; profile values already defined in the C source are replaced with the values in the default profile The instance profile /usr/sap/<SID>/SYS/profile/<SID>_<INSTANCE>_<hostname> is read; profile values already defined in the default profile or in the C source are replaced with the values defined in the instance profile This procedure ensures that system parameter values reflect the instance profile and the values in the default profile and the C source. To display the replace sequence for a particular parameter, execute report RSPFPAR in Transaction SE38 or SA38. The R/3 Kernel (disp+work) reads the default and instance profile. Therefore, if you change one of these profiles you have to restart the respective R/3 instance.
2-17
BC360
Database Startup Logs and Traces

Log file script startdb
Script startdb
$HOME/<sid>adm /startdb.log
Oracle alert file
$ORACLE_HOME (/oracle/<SID>/)
Oracle instance <SID>
saptrace/background/alert_<SID>.log saptrace/usertrace/ora_<pid>.trc
Oracle trace information
UNIX shell
<host> > sapdba
sapcheck\ sapreorg\... sapbackup\back<SID> \ ...

R
sapdba log files
SAP AG
During database startup, startsap calls the script startdb, which writes the appropriate log file startdb.log. All significant events, such as starting and stopping the database and any database errors, are logged in the Oracle alert file /oracle/<SID>/saptrace/background/alert_<SID>.log. Detailed error information is logged in the Oracle trace file /oracle/<SID>/usertrace/ora_<pid>.trc. If the administrator <sid>adm uses sapdba to start the database, sapdba writes additional log files to directory /oracle/<SID>/sapreorg , /sapcheck, /sapbackup, depending on the actions executed.
2-18
BC360
R/3 Startup Logs and Traces

$HOME/<sid>adm /startsap_<host>_<instance no.> $HOME/<sid>adm /startsap_<host>_<instance no.>.log /sapm nt/<SID>/<Instance><No>/work/ ...
stderr1 m sapstart<m >.trc sapstart.log dev_ms dev_disp
Standard error files of program SAPSTART Trace files of program SAPSTART Startup log of program SAPSTART Trace file of the m essage server Trace file of the dispatcher
R
Tim e
SAP AG
dev_w0 n
Trace files of the work processes
The R/3 startup scripts log their actions to log files in the home directory of the user <sid>adm. R/3 work directories contains trace files and error files for messages relating to the startup of work processes. There is a work directory for each R/3 instance. The work directory contains information that may not be found in the R/3 System log. The work directory files are initialized in chronological order. To define the level of information written to the trace files, set the profile parameter rdisp/TRACE in the instance profile. The values for this parameter are:
0: 1: 2 3 Write only errors (no traces) Write error messages and warnings (default) : : Write error messages and a short trace Write error messages and the complete trace
2-19
BC360
Startup Diagnostics
UNIX shell
c:> startsap
startsap.log
UNIX shell
c:> sapdba -startup Script startdb Program sapstart
sapstart.*
startdb.log Oracle instance <SID>
R/3 instance
R/3 System log
Sapdba logfiles
alert_<SID>.log ora_<nr>.trc
R/3 tracefiles dev*

R
SAP AG
This graphic shows the possible points of failure during R/3 System startup. If an error occurs, you must locate the error information and determine the cause of the problem. If access is denied on resources such as startdb script or sapstart, this could be because: The file system permissions are not correct User <sid>adm is not installed correctly Umask problems exist If the database has not been started, the work processes cannot connect to the database, and the R/3 System cannot be started. The database could fail to start because: The environment variables are not correct The database is running in DBA mode Database files are lost or corrupt Data files have been renamed in the database but not at operating system level If the R/3 System does not start, it could be because: The UNIX kernel is not configured correctly There are errors in the Memory Management configuration The R/3 profiles are not accessible (file permissions) If you can log on to the R/3 System, use the R/3 System log to analyze startup problems.
2-20
BC360
Reasons for Stopping the R/3 System

Planned downtime
Profile parameter changes
...
Parameter_1 = 0 Parameter_2 = 0
Start / Stop Activation
...
Parameter_1 = 3 Parameter_2 = 5
System maintenance (OS, DB) R/3 upgrades
R/3 System
Up
g ra
de
Unplanned downtime
Hardware failure
Data
R
SAP AG
There are two reasons for stopping the R/3 System; for planned downtime and unplanned downtime. Planned downtime should be scheduled to: Change profile parameters Perform an R/3 upgrade Perform operating system or hardware maintenance Unplanned downtime can occur because of hardware errors, such as a disk crash, or configuration problems.
2-21
BC360
Before Stopping the R/3 System

Check background and batch input jobs
Are any jobs active or planned?
Job log Display Release
SAP R/3
Display System Help
W ill R/3 jobs be triggered from external systems?
Check update status with SM 13 Send system message with SM 02 Check logged-on users with SM04 Check external interfaces
R/3 System External application
R
SAP AG
Before the R/3 System is stopped, the R/3 administrator should check the: Job Overview Check if any background jobs from any application server are active or have been triggered externally. Use Transaction SM37, or choose System Services Jobs Job overview. Process Overview Check if the background work process BTC is running in any application server. Choose Tools Administration Computing Center Management System Control All work processes. Batch Input Overview Check if any batch input jobs are running. Choose System Services Batch input Edit Overview. Update records Check if any update records are open when the system is stopped, the records are rolled back and set to status init. At startup, the records are processed again. The R/3 administrator must decide whether to interrupt the jobs or wait until they are finished. You should also give system users an advanced warning about the system shutdown by creating a system message, using Transaction SM02. Before shutting down the system, use Transaction SM04 to check whether users are still logged on, and ask them to log off. The R/3 administrator and administrators of external systems must also inform one another about data transfers between their respective systems.
2-22
BC360
Stopping the R/3 System

R/3 administrator <sid>adm
Ed it
Select
Mo nito rin g
Co ntrol ?
U tilities
System
He lp
Cho ose RefreshDetails Cho ose
UNIX
R/3 CCMS
c:> stopsap [r3|all]
Oracle Server Manager
UNIX
c:> sapdba -shutdown
1a
1b
Script stopdb
R/3 additional instances
R/3 central instance
Oracle instance <SID>
SAP AG
To stop the R/3 System, the R/3 administrator must: Stop the application servers (dialog and central instances). There are two ways to do this: Use the CCMS in R/3, or Run the script stopsap_<hostname>_<instance no> by calling the alias stopsap r3 Stop the database. There are three ways to do this: Use stopsap all or stopsap; here the script stopdb is called Use the Oracle Server Manager Use SAPDBA
2-23
BC360
Backup Offline: Database Reconnect

Instance profile
Disp+work WP WP WP
R/3 buffer preserved
Application server running in "reconnect" status
Database shut down
Database
SAP AG
If the database reconnect is configured for R/3, you do not have to stop the application server for an offline backup. The R/3 buffers are not cleared, and the work processes have the status "reconnect" until the database is restarted. Set the parameter rsdb/reco_trials = n, where n = how many times the work processes attempt to connect to the database. Set the parameter rsdb/reco_sleep_time = m, where m = how many seconds the work processes "sleep" between attempts. During an offline backup, the database must be shut down. The work processes will receive an error return code of class "reconnect" from the database. Each time a user request occurs, or the sleep time is expired, the work processes retain the status "reconnect" and try to connect to the database. Prior to an offline database backup, the R/3 administrator should send a message to all users, preventing them from logging on to the system and restarting work processes.
2-24
BC360
Stopping Error Diagnostics

Database cannot stop
UNIX shell
UNIX shell
c:> sapdba -shutdown
c:> stopsap [ r3 | all ]
Cannot stop
Database
R
SAP AG
If the database cannot be stopped when the R/3 System is stopped, it could be because: The database is performing a rollback of aborted transactions caused by the shutdown of the R/3 system. Depending on the last commit and the application, this can take a long time. An online backup is running. You should wait until the online backup is finished. The archiver becomes stuck exactly at the same time you are stopping the R/3 System. You should save the archives to tape, in order to free the file system. If there is no obvious reason why the database cannot be stopped, the database administrator should check the R/3 System log, using Transaction SM21, and the database alert file. Ensure that the problem is solved before making further attempts to stop the database. For further information, see also the R/3 Online Documentation, Database Backup, Reorganization, and Recovery.
2-25
BC360

Now you are able to:
Describe R/3 start and stop processes Explain the relationship between database processes, R/3 processes, and operating system processes Start and stop an R/3 System Analyze error situations during system startup or shutdown
SAP AG
2-26
BC360
Unit Actions
Do the exercises
Answer the questions Fill in the blanks
Solutions for the exercises Answers to the questions

R
SAP AG
Note:
There may not be sufficient time to work through all the exercises during the course. The exercises marked Optional should be seen as supplementary examples that can be used, time permitting, during the course. Attendees can also use these exercises after the course, to consolidate what they have learned.
2-27
BC360
No. 1) 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 1.14
Exercise Start and stop the R/3 System using the startsap script. Log on to the UNIX operating system as user ora<sid>. Start the startsap script. Check the UNIX processes and the R/3 startup logfiles. Are there any problems? Try to analyze the situation. Log on to UNIX as user <sid>adm. Start the startsap script and repeat steps 1.3 and 1.4. Start the SAPGUI. Log on to the R/3 System (ask the course instructor for an R/3 user). Display the name of your server and find out the R/3 process types for which the server has been configured. Is an application server configured in your system? Display the Job overview. Display the Batch Input overview. Display the overview of active users. Send the following message to the active users: "System Stop at 14:00. Please exit your transaction and log off."
1.15 1.16
Stop only one R/3 instance. Stop the entire R/3 System. (DB)
2-28
BC360
No. 1) 1.1 1.2 1.3
Solution Start and stop the R/3 System using the startsap script. Log on to the UNIX operating system as user ora<sid>. Enter startsap in the UNIX shell. To analyze R/3 UNIX processes, use command ps ef | grep dw. Analyze the R/3 trace files /usr/sap/<SID>/DVEBMGS00/work/dev*
1.4 1.5 1.6 To analyze R/3 UNIX processes, use command ps ef | grep dw.
1.7 1.8 1.9 To display the server name, use Transaction SM51 or display the system status. Information about the process types is also displayed. Alternatively, you can use Transaction RZ10. To check if an application server is configured in the system, use Transaction SM51. To display the Job overview, use Transaction SM37, or choose System Jobs Job overview. Services
1.10 1.11
1.12
To display the Batch Input overview, use Transaction SM35, or choose System Services Batch input Edit Overview To display the overview of all active users, use Transaction SM04. To send a message to all active users, use Transaction SM02, or choose Tools Administration System messages. As user <sid>adm, run the script stopsap r3 on a UNIX shell. As user <sid>adm, run the script stopsap db on a UNIX shell.
1.13 1.14
1.15 1.16
2-29
BC360
In the following, you will find excerpts from the Operation Manual, Chapter 3 Starting and Stopping R/3, in the section Stopping the R/3 System. To perform these exercises, complete the table in the excerpts as follows: 1 The table under Tasks. For your company, determine the activity group (person responsible), and the frequency with which each of the listed tasks should be performed for the production system <PRDSID>, the quality assurance system <QASSID>, and the development system <DEVSID>. Enter this information and the appropriate transaction for the task in the table (the first row is already completed to provide an example).
Tasks
Activity Frequency <PRD <QAS <DEV SID> Displaying active users AR SID> AR SID> AR Tools Administration Monitor Performance Exceptions/Users Active Users Users global Tools Administration Administration System Messages Create Tools CCMS Control/ Monitoring All work processes Tools CCMS Jobs Maintenance System Services Batch-Input Edit Tools Administration Monitor System monitoring Gateway monitor Stopping R/3 and its database W: Weekly D: Daily <R3ADM>: System administrator SAP Service Manager and SAPDBA AL08 <R3ADM> Menu Path (NT or R/3) Transaction Activity Group
Sending system messages Displaying the status of work processes Displaying background jobs Displaying Batch Input jobs Checking interfaces
M: Monthly
Y: Yearly
AR: As required
2-30
BC360
No. 1) 1.1 1.2 1.3 2) 2.1 2.2 2.3 2.4 3) 3.1 3.2 3.3 4) 4.1 4.2 4.3 4.4 5) 5.1 5.2 5.3 6)
True?
Question: Which user should be logged on to the UNIX operating system, in order to start the R/3 System? <sid>adm guest ora<sid> The program SAPSTART is called from: The user <ora>sid. The script startsap_<hostname>_<instance no.>, which is referenced with the alias startsap. The script startsap, which is executed by the user root. The user <sid>adm entering startsap on a UNIX shell. The first component that is started is: The database. The saposcol. The central instance. To start the work processes, the R/3 dispatcher reads: The instance profile. The default profile. The C source and the UNIX user environment first, then the start profile. The C source and the UNIX user environment first, then the default and the instance profile. To start the dispatcher and message server, the startsap script reads: The instance profile. The default profile. The start profile. How can you check the database and R/3 logs and traces that were written during startup or shutdown?
2-31
BC360
6.1 6.2 6.3 6.4
Only in the work directory of the R/3 System. In the home directory of user <sid>adm. Use the Database alertfile at the operating system level, or use Transaction ST04. Use the R/3 CCMS and choose DB Administration --> DBA Scheduling, or use the CCMS and choose Control/Monitoring --> Control Panel --> Utilities --> Trace files. Use the R/3 monitoring traces (developer tracefiles dev*) during or after R/3 System startup.
6.5
2-32
BC360
No. 1) 1.1 1.2 1.3 2) 2.1 2.2 2.3 2.4 3) 3.1 3.2 3.3 4) 4.1 4.2 4.3 4.4 5) 5.1 5.2 5.3 6)
True?
Question: Which user should be logged on to the UNIX operating system, in order to start the R/3 System?
<sid>adm guest ora<sid> The program SAPSTART is called from: The user <ora>sid.
The script startsap_<hostname>_<instance no.>, which is referenced with the alias startsap. The script startsap, which is executed by the user root.
The user <sid>adm entering startsap on a UNIX shell. The first component that is started is: The database.
The saposcol. The central instance. To start the work processes, the R/3 dispatcher reads:
X X
The instance profile. The default profile. The C source and the UNIX user environment first, then the start profile.
The C source and the UNIX user environment first, then the default and the instance profile. To start the dispatcher and message server, the startsap script reads: The instance profile. The default profile.
The start profile. How can you check the database and R/3 logs and traces that were written during startup or shutdown?
2-33
BC360
6.1 6.2 6.3 6.4 X X X
Only in the work directory of the R/3 System. In the home directory of user <sid>adm. Use the Database alertfile at the operating system level, or use Transaction ST04. Use the R/3 CCMS and choose DB Administration --> DBA Scheduling, or use the CCMS and choose Control/Monitoring --> Control Panel --> Utilities --> Trace files. Use the R/3 monitoring traces (developer tracefiles dev*) during or after R/3 System startup.
6.5
CCMS Configuration
CCMS Configuration
SAP AG
2-34
BC360
CCMS Configuration
CCMS Configuration
Contents:
Setting up the CCMS Starting and stopping instances with the CCMS
Objectives:
At the end of this unit you will be able to: Set up the CCM S: Import and maintain profiles Define operation modes Maintain instance definitions Schedule operation modes Start and stop instances with the CCM S
R
SAP AG
2-35
BC360
CCMS Configuration
Course Roadm ap

R
SAP AG
2-36
BC360
CCMS Configuration
CCMS: Overview
The Com puting Center M anagement System (CCMS) allows you to m onitor, control, and configure R/3 It provides functions for: Profile m aintenance Unattended 24-hour system m anagement using operation modes, instance definitions, and scheduling Starting and stopping instances Processing and controlling background jobs, scheduling database backups Automatic reporting of system alerts Dynamic logon load balancing System and network monitoring and analysis
R
SAP AG
The Computing Center Management System (CCMS) is integral part of the R/3 Basis. CCMS provides tools for managing: R/3 System and performance Database and archiving Workload Output Security You can use the CCMS to analyze and distribute client workloads and report on resource consumption for system components. The CCMS also provides graphical monitors and management utilities. CCMS provides 24-hour unattended system management functions from within R/3 through operation modes and instances. The CCMS must be configured correctly prior to use.
2-37
BC360
CCMS Configuration
Setting up the CCMS

Import and maintain R/3 profiles Setup process Define operation m odes Create instance definitions Adapt instance definitions and operation m odes Maintain timetable for normal operation
SAP AG
Before you can work with the CCMS, it must be set up correctly for your environment. Consistency and accuracy of CCMS functioning depend primarily on how it is initially configured by the customer. Set up the CCMS in the following steps: Maintain R/3 profiles. Normally, you import the profiles of all active servers after installation. They are then automatically saved to the database and activated. Define at least one operation mode. Generate instance definitions for the instances created during R/3 System installation. Assign instance definitions to operation modes, if necessary, and adapt the work process distribution. Define the timetable for normal operation for a full 24-hour cycle. If operation modes, instances, or timetable are not correctly defined, the CCMS will not display meaningful data.
2-38
BC360
CCMS Configuration
Transaction RZ10: Profile Maintenance

Used for maintenance of all R/3 profiles:
Start profile Default profile Instance profile
Allows you to change profile parameters using basic mode or extended mode Provides version management Lets you list the active parameters of application servers
SAP AG
Import R/3 profiles before setting up your R/3 operating modes, using the CCMS tool for R/3 profile maintenance, Transaction RZ10. Call this transaction directly or, from the main R/3 menu, choose Tools CCMS Configuration Profile Maintenance. In RZ10, you can display administrative data for each profile, including profile name, type, version, corresponding operating system file, reference server, and modification and activation data. There are two modes for editing profiles: In basic mode you can edit a set of parameters that are changed most frequently. You do not have to know the technical parameters names. Parameters are grouped together to reflect interdependencies. If you change one parameter, the dependent parameters are automatically adjusted. In extended mode you use a editor-like tool. You have to know the technical names of parameters and their dependencies. Additionally, you can delete a single version or all versions of a profile, compare profiles in the database with active profiles, and check profiles in various ways.
2-39
BC360
CCMS Configuration
R/3 Profiles
R/3 installation program R3SETUP
Global profile directory

In D St ar tp fl .
ef au lt pf l.
st an ce pf l.
R
SAP AG
The profile parameter values according to resources such as main memory and start profile and instance profile are created automatically during R/3 installation by the R/3 installation program R3SETUP. When the very first R/3 instance is installed, a default profile is generated in addition to the start profile and the instance profile. When installing subsequent instances, the existing default profile is updated. When the installation is complete, the profiles are used as parameter files for the R/3 instances. R3SETUP assigns shared memory on the server where the R/3 instance is installed. In a distributed R/3 environment consisting of application servers of the same platform type, a global profile directory should be set up in a shared file system.
2-40
BC360
CCMS Configuration
Maintaining R/3 Profiles

Save 3 Database
Im port 1 R/3 System Operating System INSTANCE_PROFILE START_PROFILE DEFAULT_PROFILE
R/3 Profile Maintenance RZ10

2 Change Activate 4
INSTANCE_PROFILE START_PROFILE DEFAULT_PROFILE
Profiles generated by R3SETUP
Active profiles
R
SAP AG
To change profiles belonging to different application servers from a single screen, the profiles have to be stored in the database. However, after installation, profiles are stored at operating system level. To import them into R/3, from the Profile Maintenance screen, choose Utilities Import profiles Of active servers. All three types of profiles are imported and a first check on parameters is performed. The profiles are automatically saved in the R/3 database and activated by being written back to the operating system level. If you import single profile files or create profiles, you have to check, save and activate the profiles manually. You can also create and maintain several profiles in the database under the same name, by assigning different version numbers to different files. Each time you save an altered profile a separate version is created. The database thus contains mirrored operating system profile files, old versions, modification histories, and parameter documentation. NOTE: The R/3 application server is always started using the profile file at the operating system level. From an R/3 point of view, a profile consists of two logical parts: entries in database tables and an operating system file that resides in the global profile directory. If you want to activate a profile, you must write it to the operating system level and restart the R/3 System. If other profile files exist with the same name, a confirmation prompt is issued when you activate the profiles from the database to allow the previous files to be overwritten. Additionally, a backup file is written. When activating the profile, a header is inserted in the operating system file, containing the name of the profile, the user, who modified the profile, and the change date and time. You can only activate the most recent version of a profile.
2-41
BC360
CCMS Configuration
Changing R/3 Profile Parameters
R/3 profile m aintenance with Transaction RZ10
In
Changing instance services
SAP AG
Use the standard values proposed by the system, which are valid for almost all cases. You should only change the standard values with the agreement of SAP or a SAP partner. For example, the EarlyWatch service may recommend changing certain parameter settings. Changing the standard settings may be necessary to: Start or delete an additional SAP service process on a given computer, for example, a message service (the start profile requires changing) Change a global system parameter that is valid for all instances, for example, if you want to move the R/3 database from one computer to another to improve performance (the default profile requires changing) Change a parameter value for an R/3 instance, for example, the number of background work processes (the instance profile used at startup for that instance requires changing) Changes to profiles are automatically checked before leaving either the basic or the extended maintenance mode. Any errors or inconsistencies are displayed. All parameter changes are documented in the operating system file after activation. When you modify profile parameters, the changes do not take effect immediately in the associated R/3 instance. Dynamic switching (activation of parameters without system restart) is possible only for the memory management parameters of the instance profile.
St ar tp fl
.
st
Changing global instance param eters
ef au lt pf l.
Changing instance param eters

R
an ce pf l.
2-42
BC360
CCMS Configuration
Checking and Com paring R/3 Profiles
R/3 Profile Maintenance (RZ10)
Single profile check Check of all profiles: All profiles of active servers All profiles in operation modes Comparison of database profile and active server profile
R
SAP AG
You can carry out extensive health checks for one or more profiles. These checks include making profile syntax checks, spell checking the parameter names, and semantic checks. Running these checks produces a log containing warnings and error messages where appropriate. When you check single profiles, the parameters are divided into classes. For each class there is a separate check rule. For example, the check rule for parameter class time value reports an error if the value of a parameter belonging to this class (for example, rdisp/btctime) is smaller than 0. See R/3 Online Documentation. When you check all profiles, in addition, all profiles of one type used in an R/3 System can be tested to see whether they are consistent with each other. For example, all start profiles can be checked to see whether exactly one message server is started, or all instance profiles checked to see whether an enqueue work process was configured. You can check either all profiles of active servers or all profiles in operation modes. After an application server has been started, an automatic check is performed to see whether the server's profile data as stored in the database still matches the active profiles at operating system level. If this is not the case, an alert is triggered in the Alert Monitor. This allows you to determine whether the operating system files have been changed manually. You can also perform this check manually.
2-43
BC360
CCMS Configuration
Operation Modes: Overview

To use operation modes to maximize usage of system resources: Define operation m odes Create instance definitions Assign instance definitions to operation modes and adapt configuration Switch operation m odes Schedule operation modes Perform operation mode switch diagnostics
R
SAP AG
2-44
BC360
CCMS Configuration
Operation Modes: Concept
11 10 9 8 7
12
1 2 3 4
BTC
Dialog processing Day
Background processing Night
Tim e
8 pm
6 am
SAP AG
Typically, customers require more dialog processes during the day and more background processes during the night. There are two ways to adjust the proportions of the various R/3 work processes to suit different phases of system activity. You can maintain the instance profile and restart the system, or you can define operation modes and use the operation mode switch. Using operation modes thus maximizes system resources for different phases of system activity. Operation mode switching reconfigures your R/3 System dynamically, which means you do not need to change the instance profiles for your server and therefore lose no time due to the system being unavailable. An operation mode configures the use of resources for all the instances in your R/3 System based on the following factors: The services or type of work processes needed The time interval chosen
2-45
BC360
CCMS Configuration
Choosing an Operation Mode (1)

DAY_OPERATION Server 1 Dialog Background Server 2 Dialog Background 3 2 4 2
Server 1
Server 2
Dispatcher
Dispatcher
SAP AG
Day operation usually requires more dialog processes. Good response times must be guaranteed for important data entry transactions, for example, SD order entry. Dialog processing is used for: Interactive processing, such as posting documents or creating sales orders Sending a limited data volume to be inserted and updated in the database User activity with limited transaction steps Time-critical processing
2-46
BC360
CCMS Configuration
Choosing an Operation Mode (2)

NIGHT_OPERATION Server 1 Dialog Background Server 2 Dialog Background 2 3 2 4
Server 1
Server 2
Dispatcher
Dispatcher
SAP AG
Night operation usually requires more background processes. Background processing resources must be available for high priority jobs. Background processing is used for tasks requiring database activity that is is too time-intensive for dialog processing, such as: Background tasks, such as list balances, and payments List processing Periodical processing Inserting and updating large data volumes
2-47
BC360
CCMS Configuration
Creating Operation Modes

Transaction RZ04 M ainly used for dialog processing Operation m ode: Day
M ainly used for background processing
Operation m ode: Night
SAP AG
To set up the CCMS you have to define at least one operation mode. Use Transaction RZ04 or, from the main R/3 menu, choose Tools CCMS Configuration OP Modes/Servers. If no operation modes have been defined, the test operation mode DUMMY will be displayed. It is automatically configured so that system functions, such as the control panel and background job scheduling, can be used for monitoring purposes. Operation mode DUMMY cannot be used for operation mode switching, that is, be assigned in a timetable. Operation modes can be of type productive or test. NOTE: Only productive operation modes can be assigned in the timetable.
2-48
BC360
CCMS Configuration
Creating Instance Definitions

Instance setup by R3SETUP Transaction RZ04
Instance definition 1 Instance data according to profiles Instance definition 2
Server 1
Server 2
SAP AG
Instances are created during R/3 System installation. For each R/3 instance, profiles are automatically created. You must create instance definitions in R/3 after creating at least one productive operation mode. It is not advisable to create instance definitions manually. Two non-manual methods in the CCMS are: If you have several servers, you can generate the current instance definition for all the active servers. If you have few servers or if you want to add new servers, you can create an instance definition for one server by taking current settings from an active instance When generating instance definitions, the system imports the current instance data of every application server that is active.
2-49
BC360
CCMS Configuration
Adapting Instance Definitions and Operation Modes

Transaction RZ04 Server 1: Day Dialog Background Night Dialog Background Server 2: Day Dialog Background Night Dialog Background
Operation mode: Day
Instance definition 1
Adapt original work process distribution
3 2 2 3
Operation mode: Night
Instance definition 2
4 2 2 4
SAP AG
If you choose to take the current settings from active instances when generating instance definitions, each productive operation mode that has been created previously will be assigned with the current work process distribution of the instance to each new instance definition. If you create a new instance definition not based on current settings of active instances, you have to assign operation modes manually. For each assigned operation mode you can adapt the related work process distribution for the instance definition. You can change the type of work processes. You cannot change the total number of work processes, because it is determined in the instance profile. The minimum number of work processes for dialog and also for background processing is 2. The total number of dialog work processes is always the total number of all work processes minus all non-dialog work processes. See R/3 Online documentation on further restrictions. It is possible to reserve one or more background work processes exclusively for high priority jobs (class A jobs).
2-50
BC360
CCMS Configuration
Operation Mode Switch: Concept

Shutdown
NIGHT_OPERATION
DAY_OPERATION
Shutdown
Server 2
Server 1
Dispatcher
Dispatcher
D/B
D/B
D/B
SAP AG
When switching between operation modes, work processes are redistributed automatically, without stopping and restarting the instances. No time is lost due to the system being unavailable. Only work process types are changed. The total number of work processes remains unchanged after the operation mode switch. If processes still have jobs at switch time, they are switched one by one when the jobs are completed. Thus, normal system operation is not interrupted. No program will be cancelled. System performance is maintained, as R/3 buffers such as ABAP buffers and table buffers are not refreshed. Operation mode switches are recorded in the system log. The old and the new process type are recorded for each switched work process.
2-51
BC360
CCMS Configuration
Scheduling Operation Modes

Timetable for normal operation (24-hour cycle) 08.00 - 21.00 21.00 - 08.00 Op. m ode A Op. m ode B Tim etable for exceptional operation for M arch 29 M arch 29 3 p.m . - 4 p.m. Op. m ode C
B B A
A C A
B
March 28
B
March 29
00.00
08.00
15.00
17.00
21.00
23.59
R
SAP AG
The automatic switching of operation modes is controlled by timetables. Timetables must also be maintained for CCMS monitoring. To maintain or check the timetable, use Transaction SM63 or, from the main R/3 menu, choose Tools CCMS Configuration OP Modes Timetable. The timetable allows scheduling in terms of 24-hour days, divided into intervals of 60, 30, or 15 minutes. You can define normal and exceptional operation.
In normal operation, the defined time intervals for operation modes are repeated in a 24h cycle. You must
schedule a complete period of 24 hours, not just part of a day. Otherwise, problems may occur during operation mode switching.
In exceptional operation, the defined time intervals for operation modes are activated once for a specified
time period. The timetable has a higher priority than the timetable for normal operation. You can specify part of a day (without defining a 24-hour cycle). Note that only productive operation modes can be switched automatically, that is, entered in a timetable. If the timetable for normal operation is not defined, the start configuration according to the profile will remain active and no automatic operation mode switch occurs.
2-52
BC360
CCMS Configuration
Switching Operation Modes Manually
Control panel (Transaction RZ03)
00.00
08.00
21.00
23.59
SAP AG
Sometimes it may be necessary to switch operation modes manually. You should do so only in exceptional cases, for example, when automatic switching did not work correctly. Use Transaction RZ03, or, from the main R/3 menu, Choose Tools CCMS Control/Monitoring Control Panel. In the Control Panel screen, you can switch to a particular operation mode either on all servers or on an individual server. Ensure that a manual operation switch does not disrupt system operation by, for example, providing too few dialog processes. You should always first carry out a simulation of the switch. To simulate an operation mode switch, choose Tools CCMS Control/Monitoring Control Panel Control Switch OP mode Simulation. A test log describes which switches are possible and the errors that may occur when a real switch takes place. To switch the operation mode after a simulation, Control Switch OP mode. The servers will remain in the manually activated operation mode until the next switch time.
2-53
BC360
CCMS Configuration
Operation Mode Switch Diagnostics

SAP R/3 instance
disp+work.exe
WP
...
WP
gwrd
Inconsistencies
Operation mode switch failure
Operating system
DB Configuration according to operation mode
Start and instance profile
Start and DB instance profile

R
SAP AG
If the operation mode switch fails, the administrator must investigate the cause of the failure. The cause is most likely to be inconsistencies in the system. Inconsistencies can occur, for example, if there is a discrepancy between in the number of work processes: In the instance profile on the operating system On the database Within the operation mode definition You should check regularly whether the number of currently running work processes is the same as the number entered in each of these three parts of your system. If you change profiles and restart the system, you must adapt operation modes as well as instance definitions according to the current status. Further helpful transactions: To check the OP mode switch and the work process switch within the system log, use Transaction SM21 or, from the main R/3 menu, choose Tools-->Administration-->Monitor-->System monitoring-->Process overview. To check the work process switch within the process overview, use Transaction SM50 or, from the main R/3 menu, choose Tools-->Administration-->Monitor-->System monitoring-->Process overview.
2-54
BC360
CCMS Configuration
Starting and Stopping Instances with the CCMS
Control Panel (Transaction RZ03)
Start / stop
Instance A
Instance B
Control instance and database started from operating system

R
SAP AG
You can start and stop R/3 instances with the CCMS. CCMS profiles and operation modes should be maintained correctly. When starting instances with the CCMS: The database and at least one R/3 instance (the "control instance") must have been started using operating system tools You can use the Control Panel of the CCMS (Transaction RZ03) to select an operation mode and start the remaining instances remotely. You can start multiple instances or special instances. The Control Panel enables you to check the startup log for each instance that has been started. On UNIX platforms, the rexec functionality is used to start servers remotely. Therefore, you need to maintain a startup user and password within the instance definition. On platforms that have not rexec, it is necessary to use a tool which provides a substitute for rexec. For example, to start instances of a Windows NT server from a UNIX server, a rexec daemon must be running on the Windows NT server.
2-55
BC360
CCMS Configuration

Set up the CCMS: Import and maintain profiles Create operation modes and instance definitions Maintain operation m odes and instance definitions Schedule operation modes Start and stop instances with the CCMS
SAP AG
2-56
BC360
CCMS Configuration
Unit Actions
Do the Exercises
Answer the Questions Fill in the Blanks
Solutions for the Exercises Answers to the Questions

R
SAP AG
2-57
BC360
The R/3 System should be in initial status regarding profiles, operation modes, and instance definition.
No. 1 1.1 1.2 1.3 2 2.1 2.2 2.3 2.4
Exercise Prepare your R/3 System to start Go to the global profile directory. Create a subdirectory called BACKUP, and save the profiles in the new subdirectory. If the R/3 System is not already running, start it. Which methods exist to import profiles into the R/3 System? Which method is most suitable in the present case? Importing, maintaining, and activating profiles Import all profiles into the R/3 System, and perform a consistency check. Check the administration data. Does it correspond with the operating system paths data? If not, correct it. Determine the number and the type of the R/3 System work processes. Use the R/3 System tool Profile Maintenance to change the number of dialog work processes to at least 4, and the number of background work processes to at least 2. Check if the number of enqueue and spool work processes are both equal to one. The total number of work processes should not exceed 10. Are the names of the directories of your instance specified correctly? If not, change them with the maintenance tool. If you have not done so already, activate the profiles. Check the result at operating system level. Activating your changes Restart the R/3 System. Which work processes are running now? Compare 2.3. Check the profile parameters Create Operation Modes and Instance Definitions If the R/3 System is not already running, start it. Create two productive operation modes: Day and Night. Create the instance definitions for your R/3 System if it is not yet done.
2.5 3 3.1 3.2 3.3 4 4.1 4.2 4.3
2-58
BC360
4.4
Assign operation modes and work process distributions to each instance. NOTE: During the time of the course, at least 2 background work processes should be running. Schedule Operation Modes Maintain the operation timetable. One of the operation modes should become active within the next 15 minutes. Manual switch of Operation Mode Activate one operation mode manually.
5 5.1 6 6.1
2-59
BC360
No. 1 1.1 1.2 1.3
Solution
NT: The global profile directory is \usr\sap\<sapsid>\SYS\profile. UNIX: The global profile directory is /usr/sap/<sapsid>/SYS/profile. See unit Starting and Stopping the R/3 System. The R/3 System offers you two methods to import profiles: The first method is most suitable. 1. You can import all relevant profiles at once, for example, after a new installation. Choose: CCMS --> Configuration --> Profile Maintenance --> Utilities --> Import profiles --> Of active servers. 2. You can import a single profile manually. Use Transaction RZ10, or, from the main R/3 menu, choose CCMS --> Configuration --> Profile Maintenance and specify a name for the profile you are importing. Choose Create and enter administration data. Enter a short description and the type of profile you are importing. Choose Copy. Choose Profile --> Import and enter the path of the profile you are importing. Choose Copy. Save.
2 2.1 2.2 See 1.3.1. To perform a consistency check, choose CCMS --> Configuration --> Profile Maintenance. Choose a profile and choose Check. Check the administration data. If the operating system paths (case-sensitive) are incorrect, correct them. Choose Back and save your changes. You can also activate the profiles for the default profile and the start profile. Use Transaction SM50 or, from the main R/3 menu, choose: Tools --> Administration --> Monitoring --> System monitoring --> Process overview. Use Transaction RZ10, Profile Maintenance, as above, and edit the profile parameters of the instance. If they do not coincide with the operating system paths of your instance, change the directories. Choose Copy. Change the work process distribution. Choose Copy. Save and activate the instance profile. 2.5 3 3.1 3.2 3.3 4 See unit Starting and Stopping the R/3 System. Use the process overview (Transaction SM50). Choose: Tools --> CCMS --> Configuration --> Profile Maintenance --> Goto --> Profile values --> Of a server. You can check the result in the global profile directory (see 1.1).
2.3 2.4
2-60
BC360
4.1 4.2
See Starting and Stopping the R/3 System. From the CCMS menu, choose Configuration --> OP Modes and Servers --> Create, and specify the name of the operation mode, a short description, and its type (in this example, productive operation mode). Choose Save and repeat this procedure for the second operation mode. From the CCMS menu, choose Configuration --> OP Modes/Servers (Transaction RZ04) --> Instances/OP Modes. To import all instance profiles at once, choose Settings --> Based On Active Status --> New Instance --> Create. Double click the row where the operation mode is specified. Choose Other OP Mode and choose one of the operation modes defined above. Assign a work process distribution to the operation mode and save. Repeat this procedure for the next operation mode. Save the entire table.
4.3
4.4
5 5.1 From the CCMS menu, choose Configuration --> OP Mode Timetable --> Change. Choose a 15-minute interval. Double click the beginning and the end of the time interval and assign this interval to a defined operation mode. Repeat this procedure until the whole timetable is filled. Save.
6 6.1 From the CCMS Control Panel, choose an operation mode. Double click one instance and choose Control --> Switch OP Mode --> Selected Server.
2-61
BC360
In the following, you will find excerpts from the Operation Manual, Chapter 4 Configuring R/3, in the section Operation Modes. To perform these exercises, complete the tables in the excerpts as follows: 1 The table under Tasks. For your company, determine the activity group (person responsible), and the frequency with which each of the listed tasks should be performed for the production system <PRDSID>, the quality assurance system <QASSID>, and the development system <DEVSID>. Enter this information and the appropriate transaction for the task in the table (the first row is already completed to provide an example).
The tables under Configuration Documentation. Define two or three suitable operation modes for your company and distribute the work processes available in your system in the table Work Process Distribution. In the table Timetable for Normal Operation (24 Hour), enter the start and finish times for these operation modes.
Tasks
Task Frequency <PRD <QAS <DEV SID> Defining an operation mode AR SID> AR SID> AR Tools CCMS Configuration OP-Modes/Servers. RZ04 Menu Path (NT or R/3) Transaction Activity
Group
<R3ADM>
Dynamic operation mode switchover Tools CCMS Configuration OP-Modes/Servers Operation mode Timetable. Select Normal operation. Choose Change. Manual operation mode switchover Tools CCMS Control/Monitoring Control Panel Edit Choose OP mode. Select an operation mode, then a server. Control Switch OP mode Selected server. Scheduling Exception Operation Tools CCMS Configuration OP-Modes/Servers Operation mode Timetable Select Exception operation. Choose Change.
2-62
BC360
W: Weekly D: Daily <R3ADM>: System administrator
M: Monthly
Y: Yearly
AR: As required
Configuration Documentation
Work Process Distribution An operation mode switchover can only change work process distribution, not the number of work processes in an instance. System Name Name of Active Operation Mode Dialog Batch Batch A Spool Update Update Enqueue V1 V2 Total Work Proc. <PRDSID> <PRDSID> Day Night 4 2 2 4 0 0 1 1 1 1 1 1 1 1 10 10
<QASSID> <QASSID>
<DEVSID> <DEVSID>
Timetable for Normal Operation (24 Hour) Operation modes assigned in the timetable for normal operation are switched over daily. The complete 24 hour cycle must be defined. System Name <PRDSID> <PRDSID> Day Night Name of Active Operation Mode Start/End Time 06:00 - 20:00 20:00 - 06.00
<QASSID> <QASSID>
2-63
BC360
<DEVSID> <DEVSID>
2-64
BC360
No. 1 1.1 1.2 1.3 2 2.1 2.2 2.3 3 3.1 3.2 3.3 4 4.1 4.2 4.3 5 5.1 5.2 5.3 6 6.1
True
Question: You can use the R/3 profile maintenance tool to maintain the: System profiles of the R/3 application servers System profiles of the R/3 application servers and the database profiles User profiles in R/3 administration R/3 System profiles on the application server are: Created by the R/3 administrator at operating system level after installation Created at operating system level during R/3 System installation in accordance with the installation parameters Delivered pre-configured by SAP After installation, SAP recommends that you: Delete the profile files at operating system level Import the profile files into the R/3 System using the R/3 profile maintenance tool Transfer the profile files at operating system level to the operating system superuser An R/3 instance profile defines: Which services are made available by the application server The size of the memory areas allocated by the application server The default times for automatic online logon load balancing Easy mode in profile maintenance: Displays the estimated memory requirements for the configured R/3 instance Gives you the option of excluding specific R/3 users from logging on to specific application servers Lets you determine which and how many R/3 work processes are generated at operating system level at system startup You can use the profile maintenance check functions to: Compare the consistency of the R/3 application server names with the name of the database server
2-65
BC360
6.2 6.3 6.4 6.5 7 7.1 7.2 7.3
Check the consistency of an instance profile Compare an active instance profile with its parent version in the database Check multiple instances, for example, for the number of enqueue processes in the entire system Check the number of Basis number range intervals When an R/3 instance profile is activated: The parent version of the profile is copied from the database as a file to the profile directory at operating system level The call parameter for the SAP program sapntstartb / sapstart is reset at operating system level The R/3 application server is restarted automatically with the new configuration after a warning is sent to all active users and after waiting 5 minutes Operation modes are useful because: They define which background jobs should be released They are one of the requirements for workload balancing They optimize workload distribution by separating workgroups and using separate job servers The R/3 System does not need to be stopped in order to change the type of specific work processes. An operation mode defines: Which instances are controlled The number of application servers in the system The work processes of an instance Many dialog work processes are needed during daytime business processing: To allow user interactive processing Because small volumes of data are inserted or updated in the database For periodical processing To get good response times Many background work processes are needed during night business
8 8.1 8.2 8.3 8.4 9 9.1 9.2 9.3 10 10.1 10.2 10.3 10.4 11
2-66
BC360
processing: 11.1 11.2 11.3 12 12.1 12.2 12.3 12.4 13 13.1 13.2 13.3 14 14.1 14.2 14.3 15 15.1 15.2 15.3 16 16.1 16.2 For list processing and tasks such as list balances Because a large volume of data needs to be inserted/updated in the database For time-critical processing The operation mode timetable for normal operation: Defines which operation mode will be active at what time of day Is required for CCMS monitoring Is required for automatic operation mode switching Defines the types of services offered by the SAP R/3 System as timedependent The operation mode timetable in exceptional operation: Defines which operation mode will be active at a particular time or a particular day Can only be defined for a whole day Has a higher priority than the operation mode timetable for normal operation You can switch between operation modes: Manually, using the CCMS Automatically, using the operation mode timetable for normal or exceptional operation By shutting down one instance and starting the required instance You can switch between operation modes manually: By choosing CCMS > Control/Monitoring > System Monitor By choosing CCMS > Control/Monitoring > Control Panel By using the Job Scheduling Monitor During operation mode switch: The R/3 System does not shut down The dialog work processes switch to background work processes or vice versa, depending on the instance definition
2-67
BC360
16.3 16.4
The instances profiles are changed R/3 buffers are not refreshed
2-68
BC360
No. 1 1.1 1.2 1.3 2 2.1 2.2 2.3 3 3.1 3.2 3.3 4 4.1 4.2 4.3 5 5.1 5.2 5.3 6 6.1
True
Question: You can use the R/3 profile maintenance tool to maintain the:
System profiles of the R/3 application servers System profiles of the R/3 application servers and the database profiles User profiles in R/3 administration R/3 System profiles on the application server are: Created by the R/3 administrator at operating system level after installation
Created at operating system level during R/3 System installation in accordance with the installation parameters Delivered pre-configured by SAP After installation, SAP recommends that you: Delete the profile files at operating system level
Import the profile files into the R/3 System using the R/3 profile maintenance tool Transfer the profile files at operating system level to the operating system superuser An R/3 instance profile defines:
X X
Which services are made available by the application server The size of the memory areas allocated by the application server The default times for automatic online logon load balancing Easy mode in profile maintenance:
Displays the estimated memory requirements for the configured R/3 instance Gives you the option of excluding specific R/3 users from logging on to specific application servers
Lets you determine which and how many R/3 work processes are generated at operating system level at system startup You can use the profile maintenance check functions to: Compare the consistency of the R/3 application server names with the name of the database server
2-69
BC360
6.2 6.3 6.4 6.5 7 7.1 7.2 7.3
X X X
Check the consistency of an instance profile Compare an active instance profile with its parent version in the database Check multiple instances, for example, for the number of enqueue processes in the entire system Check the number of Basis number range intervals When an R/3 instance profile is activated:
The parent version of the profile is copied from the database as a file to the profile directory at operating system level The call parameter for the SAP program sapntstartb / sapstart is reset at operating system level The R/3 application server is restarted automatically with the new configuration after a warning is sent to all active users and after waiting 5 minutes Operation modes are useful because: They define which background jobs should be released They are one of the requirements for workload balancing They optimize workload distribution by separating workgroups and using separate job servers
8 8.1 8.2 8.3 8.4 9 9.1 9.2 9.3 10 10.1 10.2 10.3 10.4 11 X X X X X X
The R/3 System does not need to be stopped in order to change the type of specific work processes. An operation mode defines: Which instances are controlled The number of application servers in the system The work processes of an instance Many dialog work processes are needed during daytime business processing: To allow user interactive processing Because small volumes of data are inserted or updated in the database For periodical processing To get good response times Many background work processes are needed during night business
2-70
BC360
processing: 11.1 11.2 11.3 12 12.1 12.2 12.3 12.4 13 13.1 13.2 13.3 14 14.1 14.2 14.3 15 15.1 15.2 15.3 16 16.1 16.2 X X X X X X X X X X X X X For list processing and tasks such as list balances Because a large volume of data needs to be inserted/updated in the database For time-critical processing The operation mode timetable for normal operation: Defines which operation mode will be active at what time of day Is required for CCMS monitoring Is required for automatic operation mode switching Defines the types of services offered by the SAP R/3 System as timedependent The operation mode timetable in exceptional operation: Defines which operation mode will be active at a particular time or a particular day Can only be defined for a whole day Has a higher priority than the operation mode timetable for normal operation You can switch between operation modes: Manually, using the CCMS Automatically, using the operation mode timetable for normal or exceptional operation By shutting down one instance and starting the required instance You can switch between operation modes manually: By choosing CCMS > Control/Monitoring > System Monitor By choosing CCMS > Control/Monitoring > Control Panel By using the Job Scheduling Monitor During operation mode switch: The R/3 System does not shut down The dialog work processes switch to background work processes or vice versa, depending on the instance definition
2-71
BC360
16.3 16.4 X
The instances profiles are changed R/3 buffers are not refreshed
2-72
BC360
CCMS Configuration
Further Docum entation
R/3 Basis Knowledge Product: System M anagement R/3 Online Docum entation: BC Com puting Center M anagement System R/3 Notes in the Online Service System (OSS), under components:
BC-C CM-CNF-OPM BC-C CM-CNF-PFL
R
SAP AG
Database Adm inistration
SAP AG
2-73
BC360
2-74
BC360
Database Adm inistration and Backups

Contents:
Database fundamentals Backup strategies
Objectives:
At the end of this unit you will be able to : Set up the database for performing backups Schedule and perform database backups Schedule and perform offline redo log file backups Verify the backups Verify the database structure on disk Recognize and solve error situations
R
SAP AG
Once you have completed this unit, you will be able to: Define an effective and secure backup strategy Schedule and perform database backups Schedule and perform offline redo log file backups Verify the backups Verify the database structure
2-75
BC360
Course Roadmap
Installation Check

R
SAP AG
2-76
BC360
ORACLE: Overview
RDBMS Processes DBWR LGWR
R/3 work processes
1:1 Shadow Shadow Shadow Configurable (init<SID>.ora) Row cache

Redo log buffer
PMON
Shared Oracle processes M emory area

SGA Database buffer pool Shared pool
Shared SQL Area
Database files
Profile Control files

SAP AG
Data files
Online redo log files
SMON
ARCH
CKPT
Oracle listener process
Offline redo log files

R
When an Oracle database instance is started several processes are created. The listener process is responsible for communication with Oracle over the network. For each database session a dedicated shadow process is started. Shared processes perform tasks required for the functioning of the Oracle database management system Database data is stored in 8KB blocks in data files on disk. To accelerate read and write access to data, these data blocks are cached in the database buffer pool in main memory. Modifications to database data are logged in the online redo log files. This procedure ensures data security. To ensure fail-safe database operation, without using additional operating system utilities, the control files and the online redo log files of the database system should be mirrored. The Oracle database management system holds the executable SQL statements in the Shared SQL Area, which is part of the shared pool, only once for all processes. Each R/3 work process: Connects to the database as one database user, SAPR3 Handles requests from the different R/3 System users Communicates with a corresponding shadow process on the database. R/3 System users do not have a database system user.
2-77
BC360
ORACLE: Starting and Stopping the Database

Oracle processes:
Profile DBWR PMON SMON SGA
R
ARCH
Mount
Control files Oracle listener process

Database buffer pool
Open
Data files
Shared pool
Redo log buffer

SAP AG
An Oracle database is started in three phases: In the No mount phase, the database instance is built up. Operating system resources are allocated using configuration information stored in the profile init<SID>.ora. In the Mount phase, the control files of the database are evaluated. The system reads the information about the file structure of the database. No data files are opened yet. In the Open phase, all files in the database system are opened. If required, an instance recovery is performed immediately after opening the database. Pending transactions on the database are ended, according to the transaction logic. The system administrator can shut down the database using one of three commands: SHUTDOWN NORMAL: All logged on users must log off. The database is closed systematically; all files are closed, the database is dismounted, and the instance is shut down. The database is consistent after shutdown. SHUTDOWN IMMEDIATE: Only the current commands are executed. PMON ends all sessions and performs a rollback of the open transactions. The database is then closed systematically (as for a normal shutdown). The database is consistent after shutdown. Caution: DBWR and ARCH may require up to 1 hour post-processing time. SHUTDOWN ABORT: Emergency database shutdown. Users are not logged off, and a rollback of the open transactions is not performed. The database is not consistent after shutdown. An instance recovery is automatically performed at the next database startup.
CKPT
Nom ount
LGWR
2-78
BC360
ORACLE: Writing Data and Log Files

Profile
Process processes and mem ory m emory
Control files CKPT DBW R Data files LGW R Online redo log files
Database buffer pool
Redo log buffer
Profile init<SID>.ora ARCH Offline redo log files

log_archive_start = TRUE log_archive_dest = ?/saparch/ ARCHIVELOG M ODE: TRUE
R
SAP AG
An Oracle database system has three processes that write information from the Shared Global Area (SGA) to the appropriate files: During a checkpoint, the Database writer (DBWR) asynchronously writes the changed blocks from the SGA to the database data files. To speed up the writing of checkpoints, the Checkpoint (CKPT) process is started. The Logwriter (LGWR) synchronously writes the change log from the SGA redo log buffer to the currently active online redo log file. In a production database system, the database must always run in ARCHIVELOG mode and have the Archiver process (ARCH) started (init<SID>.ora: log_archive_start = TRUE). ARCH archives a completed online redo log file into an offline redo log file in the archive directory. ARCH determines the archive directory from the init<SID>.ora parameter log_archive_dest (default: ?/saparch/) and determines the file name from the parameter log_archive_format. Once the offline redo log file has been successfully created, the corresponding online redo log file is released to be overwritten with new log information. If there is no freespace available in the archive directory the Archiver will not archive the file. The database will be "stuck" after a corresponding number of redo log switches. Database changes cannot be commited as long as this archiver stuck situation persists.
2-79
BC360
R/3 Naming Conventions

Tablespace nam e Prefix PSAP Abbreviation <TS_name> Extension D (data) or I (index) Directory nam es Files nam es
PSAP<TS_name> PSAPBTABD <TS_nam e>_1 btabd_1 <TS_nam e>.data1 btabd.data1 <TS_nam e>_2 btabd_2 <TS_nam e>.data2 btabd.data2 Logical layer Physical layer
Prefix Tablespace nam e Ext.

PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP PSAP SYSTEM ROLL TEMP EL<Release> ES<Release> LOAD SOURCE DDIC PROT CLU POO L STAB BTAB DOCU USER1
M eaning
Oracle DDIC Rollback segments Sort processes Development environment loads Development environment sources Screen and report loads (ABAP) Screen and report sources (ABAP) ABAP Dictionary Log-like tables (for example, spool) Cluster tables Pool tables (for example, ATAB) Master data and transparent tables Transaction data, transparent tables Documentation, SAPscript, SAPfind Customer tables
Used by
O racle RDBMS O racle RDBMS O racle RDBMS R/3 Basis R/3 Basis R/3 Basis R/3 Basis R/3 Basis R/3 Applications R/3 Applications R/3 Applications R/3 Applications R/3 Applications R/3 Applications R/3 Applications
R
D D D D D D D D D D D D
or or or or or or or or or or or or
I I I I I I I I I I I I
SAP AG
The Oracle database uses tablespaces. From a logical point of view, a tablespace is a container for database objects, such as tables and indexes. On disk, a tablespace consists of one or more data files. The capacity of a tablespace can be increased by adding files to it. The R/3 naming convention for tablespace names is defined as follows: PSAP<tablespace_name><extension>. The abbreviations in the tablespace name are part of the directory name and file name of each data file. Directories and data files are numbered. The objects located in the tablespaces SYSTEM, PSAPROLL and PSAPTEMP belong either to the Oracle database users SYS or SYSTEM. Do not create any objects owned by other users in these tablespaces. The objects located in the other tablespaces belong to the SAP R/3 database user SAPR3. NOTE: The R/3 System and SAP tools, such as SAPDBA, require that the naming conventions be observed. The installed system constitutes a logical unit, which should not be changed.
2-80
BC360
Oracle Directory Structure in R/3

Directory
dbs bin saptrace sapdata1 . . sapdata<n> sapbackup saparch sapcheck sapreorg origlogA origlogB m irrlogA m irrlogB BRBACKUP, BRRESTORE logs BRARCHIVE logs, O racle archive dir SAPDBA logs (-next, -check, -analyze) SAPDBA (default), default compression directory Online redo log files Online redo log files Online redo log files Online redo log files log_tg101_m1.dbf, log_tg103_m1.dbf log_tg102_m1.dbf, log_tg104_m1.dbf log_tg101_m2.dbf, log_tg103_m2.dbf log_tg102_m2.dbf, log_tg104_m2.dbf R ctrl<SID>.dbf Profile init<SID>.ora log_archive_format = % t_% s
Contains
SAP and O racle profiles, Oracle executables Background (Oracle alert file) usertrace Data files
File name exam ples

init<SID>.ora, init<SID>.dba, init<SID>.sap,
/btabd1/btabd.data1, system.data1, ctrl<SID>.dbf, /btabi1/btabi.data1
...
SAP AG
Directory and file names are standardized in the R/3 environment. We recommend that you use the following standards: Tablespace files reside in the sapdata<n> directories. The online redo log files reside in the origlog and mirrlog directories. The offline redo log files are written to the saparch directory. There should be at least 3 copies of the Oracle control file on different disks. The profile init<SID>.ora configures the Oracle instance, and resides in directory database. The profile init<SID>.sap configures the backup tools brbackup and brarchive, and resides in directory database. The profile init<SID>.dba configures the sapdba tool, and resides in directory dbs. Trace files written by the Oracle shadow processes are written to the directory saptrace/usertrace The Oracle alert file is written to directory saptrace/background. During reorganization, export datasets are written to directory sapreorg. The directories saparch, sapcheck, sapreorg, and sapbackup are used by the SAP database tools.
2-81
BC360
Database Adm inistration Calendar
Day
Backup the
Database backup database and
6am
12pm
6pm
12 am
Offline redo log file backup log files Daily m onitoring Storage management Alert handling Optim izer statistics
R
offline redo
Daily tasks
SAP AG
Regular tasks
Scheduling operations
The daily backup tasks of a system administrator include: Backing up the entire database Backing up the offline redo log files Monitoring the success of the backups
2-82
BC360
The Importance of Database Backups

Physical errors Physical errors
(Such as a hardware failure)
External factors External factors

(Such as fire or water dam age)
Logical errors Logical errors

( Such as a deleted table)
DELETE MARA
Data loss
To prevent data loss, a valid backup is necessary

R
SAP AG
External factors, physical errors, and logical errors can all lead to data loss and system downtime. An effective backup strategy and recovery plan is essential in minimizing system downtime and data loss. To ensure the availability of your R/3 System, the backup strategy developed by your database administrator must be carefully tested.
2-83
BC360
Database and Offline Redo Log File Backups

Data files

Database backup Database backup
Control file Profiles Offline redo log files
O ffline redo log O ffline redo log file backup file backup
SAP AG
Each database management system stores data in suitable structures on disk and writes data modifications in the database log. For the Oracle RDBMS: The data is stored in the data files of the tablespaces. The log information is recorded in the currently active online redo log file. Administration data is stored in the parameter and control files. The data files, the online redo log files, profiles and a control file are backed up during a database backup. When the currently active online redo log file is full, Oracle automatically writes to the next online redo log file. The Oracle archiver copies the completed online redo log file to the archive directory. The copy is called the offline redo log file. The offline redo log files are backed up during an offline redo log file backup. Both database and offline redo log file backups are necessary to ensure that the database can be recovered to a point in time as close as possible to when data loss occurred. To perform a restore, use a backup of the data files (or a part of the backup) for the starting point . The log information, which was generated during and after the database backup, is used to recover all modifications, which subsequently have been applied to the data. This log information is usually retrieved from the offline redo log file backups.
2-84
BC360
Preventing and Handling Errors

Logical data check: Verify database consistency
O RA-1578: Oracle data block corrupted
Physical data check: Verify backup on tape
Oracle data files

R
SAP AG
Your backup strategy should include verifying both the data to be backed up as well as the database backups. Perform a logical data check to verify the consistency of the Oracle database. Corrupt Oracle blocks (error ORA-1578) can appear in your R/3 database as a result of operating system or hardware errors. Corrupt Oracle blocks may make a backup unusable. The existence of these blocks only becomes evident during the next read access attempt to a table within the database. Since this particular access attempt may not occur often and corrupt Oracle blocks are not recognized during a database backup, these corrupt blocks might remain undetected in your system for a long time. Therefore, you should perform a logical data check at regular intervals. For optimal performance, perform this check during periods of low system activity, such as on weekends. Perform a physical data check to verify the tapes used for a database backup. To check the physical correctness of the data transferred, the tapes should be read after a successful backup.
2-85
BC360
Offline Backups
R/3 instance 00
SPO WP BTC WP BTC WP DIA WP DIA WP Dia WP
SAPGUI .... .... ______________________ ______________________ ______________________ ______________________ ....
Data files
Reconnect: rsdb/reco_trials = 3
Oracle processes Listener DBWR LGWR PMON SMON ARCH CKPT

d
O ffline backup
Database buffer pool t
st
e rt
Control file Profiles

SGA
Shared pool

O ffline redo log file backup
R
Redo log buffer
SAP AG
When an offline backup is performed, the database is shut down and remains unavailable while the backup is running. Because the Oracle data files remain unchanged, a full offline backup is consistent. The following files are backed up when an offline backup is performed: The data files of all tablespaces belonging to the database The online redo log files The control file The profiles init<SID>.ora, init<SID>.sap, and init<SID>.dba You must back up the offline redo log files when the offline backup is finished. Although the R/3 System is set up to remain online throughout the backup (reconnect parameters in the R/3 instance profile), the R/3 System users cannot use R/3 until the database is available.
2-86
BC360
Online Backups
R/3 instance 00
SPO WP BTC WP BTC WP DIA WP DIA WP Dia WP
SAPGUI .... .... ______________________ ______________________ ______________________ ______________________ ______________________ ....
Data files
Oracle processes Listener DBWR LGWR PMON SMON ARCH CKPT
Shadow Shadow Shadow Shadow Shadow Shadow
N ot
bac

k ed up
O nline backup
Database buffer pool SGA

O ffline redo log file backup
R
Shared pool
Redo log buffer
SAP AG
During an online backup, the Oracle database and the R/3 System remain available. Online backups cause a small reduction in system performance. The following files are backed up when an online backup is performed: The data files of all tablespaces belonging to the Oracle database The control file The profiles init<SID>.ora, init<SID>.sap, and init<SID>.dba CAUTION: Online backups are not consistent because the data files are updated concurrently. An online backup can only be consistent and usable in conjunction with the log information written during the online backup. After an online backup is finished, the SAP tool BRBACKUP switches to a new online redo log file and the Oracle archiver copies the previously active online redo log file to the directory saparch. The entire log information generated during the online backup is contained in the offline redo log files. Back up the offline redo log files when the online backup has finished. You do not have to back up the online redo log files when an online backup is performed.
2-87
BC360
Offline Redo Log File Backups

.../saparch Offline redo log files Oracle archiver
init<SID>.ora
Log switch
log_archive_start = TRUE log_archive_dest = .../saparch/
BRARCHIVE
Offline redo log file backup
Com plete recovery not possible Complete

Recoverable Lost
O ffline redo log files available
Missing offline redo log file
Today Online backup Log backup O ffline backup Log backup Online backup Log backup Log backup Error
R
SAP AG
Offline redo log files are copies of online redo log files which have been saved by the Oracle archiver to directory saparch. Online redo log files are cyclically overwritten. Log information is constantly generated when database data is modified. Therefore, disk space in the archive directory must be continuously released for new log files. When the archiver is unable to write to the directory specified by the parameter log_archive_dest, Oracle reports error 257: Archiver is stuck or error 255: Error archiving log, and the database becomes stuck. An error message is then written to the Oracle trace files. If, in the case of a restore, only one of the required offline redo log files does not have a valid backup, data loss occurs. The offline redo logs files must not be deleted from the archive directory without being backed up to tape. For security reasons, back up 2 copies of each offline redo log file on separate tapes. NOTE. In the case of a database failure, you may be unable to recover all the database changes not contained in the latest redo log file backup. Remember: An online backup is useless without the log information that was generated during the database backup.
2-88
BC360
Backup Cycle Recommendations
Verify the database Verify the backup Offline
Verify the backup Online Offline redo log file backup (x2)
28 days
Additional
Online Offline redo log file backup (x2)
SAP AG
SAP recommends a backup cycle of 4 weeks. A pool of tapes for database and offline redo log file backups is required. Ensure that enough tapes are provided in each tape pool to span the entire backup cycle. We recommend having 30% more tapes than required. Backup tapes can be reused at the end of a backup cycle (after 28 days). Perform a full online backup each workday. Perform a full offline backup at least once in the backup cycle. You must back up the offline redo log files each workday, as well as after every online and offline backup. Ensure that you back up the offline redo log files twice, on separate tapes, before they are deleted. To verify a backup, you must check the database for logical errors and the database backups for physical errors. You must perform this backup verification at least once in the backup cycle, however, you should try to perform it once a week. Remove the last verified full offline backup of each cycle from the tape pool, and keep this backup in long-term storage. Replace the tapes, and initialize new ones. Perform additional backups after each database structure modification or a system upgrade. Place these additional backups in long-term storage.
2-89
BC360
SAP Backup Tools
CCMS P lanning Calend ar Planning G oto Listing Help System M ON M ON M ON M ON TUE W E D T HU T UE WE THU TUE W E D T HU T UE WE THU TUE W E D T HU T UE WE THU TUE W E D T HU T UE WE THU FRI FRI FRI FRI S AT SAT S AT SAT S AT SAT S AT SAT SUN SUN SUN SUN
Data files
BRBACKUP

BRARCHIVE
O ffline redo log O ffline redo log file backup R file backup
SAP AG
Database backups are performed by the SAP tool BRBACKUP. Offline redo log file backups are performed by the SAP tool BRARCHIVE. There are three ways to call these tools: Using the DBA Planning Calendar (Transaction DB13) Using the SAPDBA at operating system level Directly, at the operating system level SAP recommends the following procedure: Schedule all regular backups with the DBA Planning Calendar (Transaction DB13) Perform additional backups with the SAPDBA All the steps of a backup are logged to operating system files and in database tables.
2-90
BC360
Im plementation Questions
Security requirem ents High availability Maximum downtime System online 7x24h Backup cycle Long-term storage Data volum e
Hardware requirem ents: Backup devices Backup m edia
Backup strategy
Schedule backups Initialize tapes Set up authorizations Define an em ergency emergency plan
R
SAP AG
To determine the best backup strategy for your company, you must consider the: Operational requirements Management security requirements Hardware components required Availability of the system (24 hours per day, 7 days per week) Implementing a backup strategy includes: Defining the tapes to be used and their storage location Scheduling the backups Defining the persons responsible for the backups Setting up the appropriate R/3, operating system, and database authorizations Training all persons involved in the backup procedure Defining an emergency plan Determining who must be contacted in case of an emergency In addition to planning your backup strategy, you should create a manual that contains information about each step of the backup procedure. This manual should always be available for all persons involved in the backup procedure.
2-91
BC360
Backup Profile Parameters for Tape Initialization
init<SID>.sap
.... .... .... .... ? ??? ? ? #1-1 #1-1 NEW NEW NEW NEW
tape_use_count expir_period expir_period backup_ dev _type volume_backup volum e_backup volume_archive volum e_archive
= = = = =
100 28 tape (<SID>B01, <SID>B02, ...) (<SID>A01, <SID>A02, ...)
To edit init<SID>.sap, use a standard text editor init<SID>.sap,

SAP AG
Before a backup can be performed, you must initialize the tapes to be used. This means you must: Set the backup profile parameters Label the tapes The profile init<SID>.sap is used to set the following parameters: tape_use_count defines how often a tape can be resued. expir_period defines the length of the backup cycle. To allow the tape to be reused after 28 days, set this parameter to 28. backup_dev_type defines the type of backup device used. To perform backups to a local tape device, enter tape. Other options include pipe (remote), tape_auto (auto loader), util_file (backint interface), and disk. volume_backup defines the tape pool for the database backups volume_archive defines the tape pool for the offline redo log file backups
2-92
BC360
Initializing Backup Tape Pools

init<SID>.sap
volum e_backup= (<SID>B01, <SID>B02, <SID>B03, <SID>B04) volum e_archive= (<SID>A01, <SID>A02, ? ? <SID>A03, <SID>A04) Tape Tape ??? Pool Pool ? #1-1 #1-1
Use SAPDBA to initialize tape pools
brbackup -i force
new new
<SID>B01 <SID>B02 <SID>B03 <SID>B04
brarchive -i force
<SID>A01 <SID>A02
R
SAP AG
The tape initialization procedure should be performed as follows: Set the init<SID>.sap parameters volume_backup and volume_archive. In this example: volume_backup=(<SID>B01, <SID>B02, <SID>B03, <SID>B04) volume_archive=(<SID>A01, <SID>A02, <SID>A03, <SID>A04) To initialize the tape pools, use SAPDBA or BRBACKUP and BRARCHIVE with call option -i force (where -i = initialize and force = do not evaluate tape label). In this example, tape labels <SID>B01, <SID>B02, <SID>B03, <SID>B04 and <SID>A01, <SID>A02, <SID>A03, <SID>A04 are initialized. During initialization, the label .tape.hdr0 is written as the first file on every tape. This label is always read and checked by BRBACKUP and BRARCHIVE. BRBACKUP and BRARCHIVE record the tape usage in the tape label, the backup logs, and in the database. To overwrite the default settings defined in volume_backup or volume_archive, use BRBACKUP and BRARCHIVE with call option -v/-volume. Depending on your backup strategy, a sufficient number of tapes should be initialized. The number of tapes required depends on the size of the database, the size of your tapes, the compression factor and the amount of log information generated. Add 30% freespace reserve to the required tape capacity.
2-93
BC360
Compressing Data
Use SAPDBA to determine the compression ratio once per cycle
<SID>B01 <SID>B02 <SID>B03 <SID>B04
init<SID>.sap .... .... .... .... ? ? ???
com press
= hardw are <SID>B01
SAP AG
Use the init<SID>.sap parameter compress to choose the mode of compression. If your tape device supports hardware compression, set this partameter to hardware. You can also specify yes for software compression or no for no compression. When using hardware or software compression, data on tape requires less storage space. The compression factor indicates the degree of compression possible for the backup data. Use SAPDBA to determine the compression ratio with which your data can be backed up. This factor depends on the fill level of the database files to be backed up. Because of the changing fill level, you should redetermine the compression rate frequently (at least once per backup cycle).
2-94
BC360
Profile Parameters for Database Backup
init<SID>.sap
.... .... .... .... ? ??? ? ?
backup_ mode backup_ type volume_backup tape_ size compress com press
= = = = =
all online [offline] (<SID>B01, <SID>B02, ...) 70000M hardware

SAP AG
Use the following init<SID>.sap parameters to set up program BRBACKUP: Set parameter backup_mode to all in order to perform a complete database backup backup_type defines whether the backup is online or offline tape_size defines the physical tape size for tapes used by BRBACKUP. Specify the size of the smallest tape in your tape pool (in MB). For example, specify 70000M for a 70GB tape. NOTE: The value specified for this parameter must be equal to the amount of uncompressed data the tape can hold. When data is backed up sequentially to several tapes and only one tape device is available, BRBACKUP requests the tapes in the order defined by the parameter volume_backup. Both rewind and no-rewind tape drivers are required by the SAP backup tools. A no-rewind driver must be assigned to parameter tape_address, and a rewind driver to parameter tape_address_rew.
2-95
BC360
Profile Parameters for Offline Redo Log Backup

archive_function volume_archive tape_size_arch = copy_delete_save
= (<SID>A01, <SID>A02, ...)
init<SID>.sap
? ??? ? ? .... .... .... ....
= 6000M
Use copy_delete_save to: 1) Back up the offline redo log files that have already been backed up once 2) Delete these offline redo log files from directory saparch 3) Back up the offline redo log files that have not yet been backed up
R

SAP AG
Use the following init<SID>.sap parameters to set up program BRARCHIVE: Set parameter archive_function to - cds (copy_delete_save). This ensures that two copies of one offline redo log file are backed up to different tapes. Option -cds (copy_delete_save): Creates a second backup of the oldest offline redo log files already backed up once Deletes the offline redo log files that have been backed up twice from the archive directory, in order to free disk space Backs up all new offline redo log files for the first time tape_size_arch defines the physical tape size for tapes used by BRARCHIVE. Specify the size of the smallest tape in your tape pool (in MB). For example, specify 6000M for a 6GB tape. tape_address_arch and tape_address_rew_arch specifiy the drivers of the tape devices to be used by BRARCHIVE to perform the offline redo log file backup. If they are not defined, BRARCHIVE uses parameters tape_address and tape_address_rew to determine the drivers.
2-96
BC360
Scheduling Database Backups

CCMS Planning Calendar
P lanning Goto Listing Help System
Volumes needed
MON ON
BRARCHIVE
MON ON
TUE
W SAT S Create ED newTHU a action FRI Tue AT for 05
S UN SUN
Start time 18:00:00

TUE
Period: 1
Calendar

Log files
.... .... .... .... .... .... .... .... ....
MON ON
MON ON
BRBACKUP
Action W ED THU FRI SAT S UN S AT SUN Full DB offline + archive logs backup Full database offline backup Full DB online + archive logs backup Full database online backup TUE W ED THU FRI SAT S UN S AT SUN Archive logs backup Partial database offline backup Partial database online backup TUE W ED THU FRI SAT S UN S AT SUN Check optimizer statistics Create new optimizer/space statistics Compute and adapt next extents Check database structure Options for Database Backup
"
Profiles Verify
Init<SID>.SAP
SAPDBA backup option query only

SAP AG
Data files
"
R
Use the DBA Planning Calendar (Transaction DB13) to schedule database and offline redo log file backups. Online as well as offline backups can be scheduled. At least once in the backup cycle you must verify your full offline backup. To perform a physical and logical verification of the data backed up, use the Verify option. The names of the tapes to be used for the backup are determined from the parameters volume_backup (for program BRBACKUP) and volume_archiv (for program BRARCHIVE). You can overwrite the default volume names in the dialog box Volumes to use. To verify the number and names of the tapes required for a backup, choose Volumes needed from the DBA Planning Calendar (Transaction DB13) or use the SAPDBA (option query only). The number of tapes calculated is based on the size of the database, the parameter tape_size, and the compression factor. Log files are written by BRBACKUP (default directory sapbackup) and by BRARCHIVE (default directory saparch). These log files provide information about the type and state of activities performed. The activities of BRBACKUP and BRARCHIVE are also loggged in the database.
2-97
BC360
Daily Monitoring: Database Backups

Possible backup errors: Tape defect W rong tape label Tape too sm all Corrupted blocks
Schedule a new database or log file backup
CCM S Planning Calendar
M on Tue ed Thu Sat P lanning Goto WListing HelpFriSystem Tue S un
Check the success of the database and offline redo log file backups
P lanning G oto Listing Help System MON MO Full On line O nline MON MO TUE Full O ffline Offline TUE WE D W ED THU FRI S AT S UN
WE D W ED
THU
FRI
S AT
S UN
CCM S Database Backu p Logs P lanning G oto N M O Listing Help System TUE WE D MO W ED Recovery report Recovery report SAT
S un
THU
FRI
S AT
S UN
Refresh Refresh THU FRI S AT S UN
M ON M on Full Online
M on
Tue
TUE FullW ed Offline O ffline TUEW ed

W ed
WED WE
Thu
THU
Fri Sat
FRI
SUN S UN
MON TUE WE D MO W ED Last successful database backup Last successful database backup O verview of all database backup logs O verview of all database backup logs
M ON
Tue
Thu WED WE
Fri
THU
Sat
FRI S un
S un
SAT
SUN S UN S tatus of log directory S tatus of log directory
M on
Tue
Thu
Fri
Sat
M ON
TUE
WED WE
THU
FRI
SAT
SUN S UN
S tatus of most recent redo logs S tatus of most recent redo logs O verview of all recent redo log backup logs O verview of all recent redo log backup logs
M ON
TUE
WED WE
THU
FRI
SAT
SUN S UN
SAP AG
The Backup Log Monitor (Transaction DB12) display information about: The database and the offline redo log file backups The log files written by BRBACKUP and BRARCHIVE The last unsuccessful backup The last successful backup All the backup actions The state of the archive directory How your database and offline redo log file backups could be used for a recovery The DBA Planning Calendar (Transaction DB13) displays the status of all the activities that were performed.
2-98
BC360
Summary: Setting up your Backup Strategy

Provide tapes for backups Verify backups Check data volume changes Check compression ratio changes com pression Check redo log volume changes Verify the database
Cycle
Length of backup cycle Data volume Compression ratio Redo log volume
init<SID>.sap .... .... .... ....
CCMS P lann ing Calendar P lanning G oto Listing Help System M ON TUE W ED THU FRI S AT SUN ED S UN M ON TUE W ED THU FRI S AT SUN ED S UN M ON TUE W ED THU FRI S AT SUN ED S UN M ON TUE W ED THU FRI S AT SUN ED S UN
CCM S Database Backup Logs P lanning Goto Listing Help System CCM S Planning Calendar P lanning Goto Listing Help System M ON TUE WE D THU FRI SAT S UN ON W ED T HU S AT SUN M ON TUE WE D THU FRI SAT S UN ON W ED T HU S AT SUN M ON TUE WE D THU FRI SAT S UN ON W ED T HU S AT SUN M ON TUE WE D THU FRI SAT S UN ON W ED T HU S AT SUN
? ???
? ?
Define strategy
Initialize backup tools
Schedule regular backups
Perform and m onitor backups
SAP AG
To set the backup parameters in the profile init<SID>.sap you must: Determine the backup cycle Estimate the volume of data to be backed up (use the sizing information provided by your hardware partner) Estimate the volume of the offline redo log files to be backed up Determine the compression factor, using either SAPDBA or BRBACKUP Determine the number of tapes required (to allow for database growth, add 30%) Initialize the tapes to be used for your backups. Schedule your regular backups using the DBA Planning Calendar (Transaction DB13). Perform and monitor the backups, which includes: Providing the tapes required for the backups Monitoring and verifying the success of the backups Checking for changes in the volume of data to be backed up Re-checking the compression rate (at least once per backup cycle) Verifying the database logically (at least once per backup cycle) Replacing and initializing tapes used for long-term backup storage
2-99
BC360
Using the One Tape Strategy

CCM S P lanning Calendar P lanning Goto Listing Help System MO N T UE W ED THU FRI S AT S UN M ON TUE SUN
Log file
Data files
.... .... ....
MO N T UE W ED THU FRI S AT S UN M ON TUE SUN MO N T UE W ED THU FRI S AT S UN M ON TUE SUN MO N T UE W ED THU FRI S AT S UN M ON TUE SUN
brbackup ... -a <options>

Determ ines the tapes required Determ the tapes Backs up the database Backs up the Calls BRARCHIVE Calls
Volume_backup
brarchive <options>
Backs up the offline redo log files
Log file
.... .... ....
SAP AG
As of R/3 Release 4.0, you can back up the database and offline redo log files to the same tape by: Using the CCMS DBA Planning Calendar (Transaction DB13) Running BRBACKUP with the call option -a <BRARCHIVE options> or alternatively Running BRARCHIVE with the call option -b <BRBACKUP options> Using the SAPDBA There are three steps in the one tape strategy: 1 BRBACKUP connects to the database to determine the tapes required for the backup 2 When the database backup is finished, BRBACKUP calls BRARCHIVE 3 BRARCHIVE then backs up the offline redo log files, without prompting for a new tape Only tapes defined with the parameter volume_backup are considered for both the database and the offline redo log file backups. However, you must also have an emergency tape pool for BRARCHIVE. BRBACKUP cannot resolve an archiver stuck situation. If an archiver stuck stiuation occurs, call BRARCHIVE and perform an offline redo log file backup. Backing up both the database and the offline redo log files to the same tape ensures that: Less tapes are required Only one backup run for both backups is required Less administrative tasks need to be performed
2-100
BC360

Define an effective backup strategy Perform database backups Perform offline redo log file backups Verify the database backups
SAP AG
Now you are able to : Define an effective backup strategy Schedule backups Perform database backups Perform offline redo log file backups Verify the backups Remember: An effective backup strategy is essential in minimizing system downtime and data loss.
2-101
BC360
Unit Actions
Do the exercises
Solutions for the exercises Answer the questions

R
SAP AG
2-102
BC360
No. 1) 1.1 1.2
Exercise Preparations For an online backup, you must ensure that the database is in ARCHIVELOG mode. Activate this mode, if it has not already been done. Set the parameters so that the default backup is a full online database backup without compression to disk and the offline redo log files are backed up once and not subsequently deleted. Database backup using CCMS Use the DBA Planning Calendar to schedule a partial online backup of tablespace PSAPUSER1D to start in 5 minutes. In which directory is the backup performed, and how much disk space is required? After the backup has been performed, use the log files to check whether the backup was successful. Optional: Database backup using SAPDBA Use SAPDBA to perform a partial online backup of tablespace PSAPUSER1D. After the backup has been performed, use the log files to check whether the backup was successful. Offline Redo log file backup using CCMS Use the DBA Planning Calendar to schedule an offline redo log file backup to start in 5 minutes. In which directory is the backup performed, and how much disk space is required? After the backup has been performed, use the logs to check whether the backup was successful. Optional: Offline Redo log file backup using SAPDBA Use SAPDBA to perform an offline redo log file backup. After the backup has been performed, use the log files to check whether the backup was successful.
2) 2.1 2.2 2.3 3) 3.1 3.2 4) 4.1 4.2 4.3 5) 5.1 5.2
2-103
BC360
No. 1) 1.1 1.2
Solution
Stop the R/3 System. From the SAPDBA, choose f Archive mode. To switch the mode, choose a Toggle database log mode. Set the following parameters in profile init<SID>.sap: backup_type = online backup_dev_type = disk compress = no archive_function = save
2) 2.1 Double-click today's date and the appropriate starting time for the backup. Choose Partial online database backup Continue. To select the tablespace PSAPUSER1D, use P-, P--, P+ or P++ to scroll down the screen. Because this is a backup to disk, you do not need to enter any Volumes. Choose Continue again. To verify the back up, select Verify in the dialog box displayed. To save your scheduled backup, choose Continue. To display a list of scheduled backups, double-click today's date in the DBA Planning Calendar. Place the cursor on the backup scheduled in 2.1, and choose Volumes needed. Place the cursor on the backup that you scheduled for exercise 2.1, and choose Action logs. To display the log file for BRBACKUP, choose Oper. system log.
2.2
2.3
3) 3.1 Start SAPDBA and choose h - Backup database. To back up tablespace PSAPUSER1D, choose d Objects for backup. To start the backup, choose S Start BRBACKUP. From the initial SAPDBA screen, choose l Show/Cleanup a Show log files / Profiles e BRBACKUP log files. Select the appropriate log file.
3.2
4) 4.1 Double-click today's date and the appropriate starting time for the backup. Choose Archive redo log files Continue. Because this is a backup to disk, you do not need to enter any Volumes. Choose Continue again. In the dialog box displayed, select s (this is the option for BRARCHIVE). To verify the back up, select Verify in the dialog box displayed. To save your scheduled backup, choose Continue.
2-104
BC360
4.2
To display a list of scheduled backups, double-click today's date in the DBA Planning Calendar. Place the cursor on the backup scheduled in 4.1, and choose Volumes needed. Place the cursor on the backup that you scheduled for exercise 4.1, and choose Action logs. To display the log file for BRBACKUP, choose Oper. system log.
4.3
5) 5.1 Start SAPDBA and choose i - Backup archive logs. If you have not already done so, choose a single backup of the offline redo log files. Choose a Archive function a Save archive logs q Return. To start the backup, choose s Start BRARCHIVE. From the initial SAPDBA screen, choose l Show/Cleanup a Show log files / Profiles f BRARCHIVE log files. Select the appropriate log file.
5.2
2-105
BC360
In the following, you will find excerpts from the Operation Manual, Chapter 8 Performing Backup, in the section Backup on Database Level. To perform these exercises, complete the tables in the excerpts as follows: 1 The table under Tasks. For your company, determine the activity group (person responsible), and the frequency with which each of the listed tasks should be performed for the production system <PRDSID>, the quality assurance system <QASSID>, and the development system <DEVSID>. Enter this information and the appropriate transaction for the task in the table (the first row is already completed to provide an example).
The tables under Configuration Documentation. In your system, find out which backups are scheduled and use this information to complete the tables.
Tasks
Task Frequency <PRD <QAS <DEV SID> Creating a backup strategy Backing up archive logs AR SID> AR SID> AR Tools CCMS DBAdministration DBA scheduling Use SAPDBA or Tools CCMS DBAdministration DBA scheduling Backing up the database Use SAPDBA or Tools CCMS DBAdministration DBA scheduling Checking backup logs Use SAPDBA or Tools CCMS DBAdministration Backup Logs Testing restore and recovery W: Weekly D: Daily <DBADM>: Database administrator SAPDBA DB13 <DBADM> Menu Path (NT or R/3) Transaction Activity Group
M: Monthly
Y: Yearly
AR: As required
Use the following tables to document your R/3 backup operations. Note that the R/3 database and the archive log files are always backed up on separate tapes. Timetable for Database Backups Ensure that the tapes to be used for backup have been initialized. It is easiest to initialize all tapes to be used for backup at the same time. The backup strategy recommended by SAP requires 30 tapes for backing up the database, and 30 tapes for backing up the archive logs. In the following table, enter when the backups are to be made for the respective R/3 System, and whether it is to be an offline or an online backup.
2-106
BC360
R/3 System <PRDSID> <QASSID> <DEVSID>
Mon.
Tue.
Wed.
Thu.
Fri.
Sat.
Sun.
(For each database backup, use a new tape.) Timetable for Archive Log Backup Archive logs must be backed up more frequently to avoid the directory %ORACLEHOME%\saparch becoming full. In the following table, enter when the archive log backups are to be made for the respective R/3 System. R/3 System <PRDSID> <QASSID> <DEVSID> Mon. Tue. Wed. Thu. Fri. Sat. Sun.
Unscheduled Backups Unscheduled, offline backups are required: After changing the structure of the database Before and after major changes to an R/3 System, such as upgrade to a new R/3 Release Enter backup runtimes in the following table. When more data are entered into the R/3 System, you can check the extent to which the runtime has changed. Date R/3 System <DEVSID> <DEVSID> <DEVSID> Database Backup Runtime Transaction Log Backup Runtime
2-107
BC360
No 1) 1.1
True?
Question: Which of the following statements are true? In a restore and recovery situation, the loss of a backed up data file will lead to loss of data, even if you have an older version of the file and all the required redo log archives.
1.2
In a restore and recovery situation, the loss of a redo log, which is more recent than the backed up data files that you need to restore, will lead to loss of data. If your backup tapes cannot be read properly or are lost or damaged, you risk losing your entire company database. During an online database backup, blocks modified during the backup are automatically recognized by the system and added to the database backup tape, so that the online backup is consistent.
1.3 1.4
1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12
The default brbackup database backup also backs up the control files and the init.ora file. The default brbackup database backup also backs up your Oracle programs (binaries, executables).
You should backup at least the affected data file (more simply, the affected tablespace) when you change the structure of a tablespace. If a backup to tape returns with no errors, you are guaranteed to be able to read the tapes later if you need them for a restore.
X X
Some customers have been known to go live without testing their backup strategy by performing a restore and recovery. Some customers have nearly lost their production database because they have not tested whether their tapes were really readable. Oracle requires you to restore the entire database, even if only one file is damaged.
You can only restore a single data file if you have the necessary redo logs to bring that data file back in sync with the rest of the database.
2-108
BC360
No. 1) 1.1
True?
Question: Which of the following statements are true? In a restore and recovery situation, the loss of a backed up data file will lead to loss of data, even if you have an older version of the file and all the required redo log archives.
1.2
In a restore and recovery situation, the loss of a redo log, which is more recent than the backed up data files that you need to restore, will lead to loss of data. If your backup tapes cannot be read properly or are lost or damaged, you risk losing your entire company database. During an online database backup, blocks modified during the backup are automatically recognized by the system and added to the database backup tape, so that the online backup is consistent.
1.3 1.4
1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12
The default brbackup database backup also backs up the control files and the init.ora file. The default brbackup database backup also backs up your Oracle programs (binaries, executables).
You should backup at least the affected data file (more simply, the affected tablespace) when you change the structure of a tablespace. If a backup to tape returns with no errors, you are guaranteed to be able to read the tapes later if you need them for a restore.
X X
Some customers have been known to go live without testing their backup strategy by performing a restore and recovery. Some customers have nearly lost their production database because they have not tested whether their tapes were really readable. Oracle requires you to restore the entire database, even if only one file is damaged.
You can only restore a single data file if you have the necessary redo logs to bring that data file back in sync with the rest of the database.
2-109
BC360
SAP System Management CD Oracle Database Administration CD SAP Online Documentation:

Database Administration Oracle
BC505 Oracle Database Administration
SAP AG
The topics covered in this unit are available on the following SAP Knowledge Product CDs: SAP System Management Oracle Database Administration The R/3 Online Documentation Database Administration Oracle describes the parameters of profile init<SID>.sap and the call parameters of programs BRBACKUP and BRARCHIVE in detail. To improve database administration skills, the following database workshop is offered: BC505 Oracle Database Administration
2-110
BC360
DB Administration: Daily Check Procedures
SAP AG
2-111
BC360
DB Administration: Daily Check Procedures

Contents:
Oracle Cost-Based Optim izer Storage management Tablespace m anagement Database backup Daily monitoring areas
Objectives:
At the end of this unit you will be able to: Monitor an Oracle database Maintain an Oracle database Minimize system downtim e
R
SAP AG
Once you have completed this course, you will be able to: Monitor an Oracle database Prevent error situations Minimize system downtime Recognize and solve error situations
2-112
BC360
Course Roadmap
Installation Check

R
SAP AG
2-113
BC360
Database Monitoring: Overview
Day
Backup
6am
12pm
6pm
12am
Archive Daily monitoring m onitoring Storage m anagem ent Daily m onitoring management Alert handling Storage management Optim izer statistics Optimizer Alert handling Optim izer statistics Daily tasks Regular tasks
SAP AG
Scheduled operations
To improve performance and to minimize system downtime, the Oracle database must be monitored daily. For an overview of system performance indicators, the Computing Center Management System provides the following monitors: The Database System Check Monitor (Transaction DB16) displays an overview of all the main database functions and statuses. The Backup Log Monitor (Transaction DB12) displays information about the status of database and offline redo log file backups. The Tables and Indexes Monitor (Transaction DB02) displays an overview of the storage behavior of the database and the status of the database objects. The Database Performance Monitor (Transaction ST04) displays an overview of the load and configuration of the database management system and the database. The DBA Logging Monitor (Transaction DB14) provides access to the logs of all database administration actions, including updates of the optimizer statistics. Check these monitors daily to prevent: The Cost-Based Optimizer from using obsolete information A large number of extents from being created Freespace problems from occurring
2-114
BC360
Oracle Cost-Based Optimizer

R/3 System SAP R/3
init<SID>.ora
O PTIMIZER_MODE = choose
Possible access paths

Index A Index A
Costs
Database table ADDR
SELECT * FROM ADDR W HERE name = "miller" nam e "m iller" AND pnum = "123" AND city = "Houston"
Index B Index B
$$ $$$
Full Full table table scan scan
$$
Which is the optim al access path? optimal
OPTIMIZER
SAP AG
The Cost-Based Optimizer uses an SQL statement to determine the most effective strategy for retrieving or manipulating database data. The access strategy used depends on the information in the: Queried table (or tables, for a view or join) Fields specified in the WHERE clause of the SQL statement Indexes defined for the tables queried The Cost-Based Optimizer computes the cost of several strategies for accessing the tables, and chooses the one that requires the smallest amount of data accesses. To calculate the cost of a strategy, the optimizer requires statistical information about the tables and indexes of the database, such as: Number of table or index rows and number of blocks allocated for the object Number of distinct values in each column of the table The statistical information for a table or index is stored in the data dictionary of the database. To collect the statistical information, use the Oracle SQL command analyze table. NOTE: The analyze command is expensive. Table and index sizes and value distributions can change. If the current number of rows of a table differs greatly from the values determined by the last analyze table run, the optimizer may choose an ineffective strategy and the database access time becomes longer. You should refresh the optimizer statistics at least once a week.
2-115
BC360
SAP Two-Phase Strategy

1) Database objects requiring an update of optimizer statistics are determined and marked in table DBSTATC
SAPDBA x
Control table DBSTATC

DB object TO DO flag AUFK x x x x
SAPDBA
sapdba -checkopt PSAP%
EKPO KNVK LIPS MKPF RESB VBUK
sapdba -analyze DBSTATCO
2) Database objects that are marked in table DBSTATC are updated

R
SAP AG
Only up-to-date statistical information can ensure that the Oracle Cost-Based Optimizer chooses the optimal access path. However, gathering optimizer statistics is expensive and negatively affects system performance. SAP recommends the following two-phase strategy: In the first phase, the SAP tools determine which tables require a statistical update. The command sapdba -checkopt PSAP% determines which database objects contain obsolete statistics, and modifies the control table DBSTATC accordingly. In the second phase, the statistics of the tables marked TODO in the control table DBSTATC are refreshed using command sapdba -analyze DBSTATCO. This two-phase strategy ensures: Up-to-date statistics for all tables Optimal analysis runtime
2-116
BC360
Updating Oracle Optimizer Statistics

x
FRI S AT 10:00 Checkopt Checko pt SUN S UN 5:00 Analyzetab
M ON
Create aUE new action for Sun 08 TUE W ED THU T ED

Period: 1 Calendar
Start time 05:00:00
Action Full DB offline + archive logs backup TUE W ED THU T UE ED Full database offline backup Full DB online + archive logs backup Full database online backup Archive logs backupW ED M ON TUE THU T UE ED Partial database offline backup Partial database online backup Check optimizer statistics M ON TUE W ED THU T UE ED Create new optimizer/space statistics Compute and adapt next extents CheckKeyword structure database for analyze
M ON
FRI
S AT 10:00 Checkopt
SUN S UN 5:00 Analyzetab
FRI
S AT 10:00 Checkopt
FRI
S AT 10:00 Checkopt
DBSTATCO: all tables marked in DBSTATC
DBSTATCA-TAB: all application tables in DBSTATC Keyword for Checkopt DBSTATCAA-TAB: all application only tables in DBSTATC
DBSTATC-TAB: all tablestablespaces in DBSTATC DBSTATCA-TSP: all in DBSTATC DBSTATCA-TAB: all application tables in DBSTATC NOO PTSTAT: all tables without statistics DBSTATCAA-TAB: all application only tables in DBSTATC PSAP% : all SAP tablespaces DBSTATCA-TSP: all tablespaces in DBSTATC TSP-LIST: select SAP tablespaces PSAP% : all SAP tablespaces ! " TSP-LIST: select SAP tablespaces
Determ ine which objects require a statistical update once a week w eek Refresh the statistics once a week w eek
R
!
SAP AG
"
Use the DBA Planning Calendar (Transaction DB13) to schedule the two phases of the strategy to run consecutively. The analysis commands are performed by program SAPDBA. Check optimizer statistics determines the tables requiring an analyze table run. To determine which database objects require a statistical update, choose the keyword PSAP%: all SAP tablespaces. Update optimizer statistics at least once a week during periods of low system activity. Create new optimizer/space statistics updates the table statistics. To refresh the statistics of all tables with the TODO flag set in table DBSTATC, choose the keyword DBSTATCO: all tables marked in DBSTATC.
2-117
BC360
Monitoring Oracle Optim izer Statistics

DB02 (Oracle): Checks: Analysis for Cost-Based O ptimizer
x x
DB Analysis Edit Goto Monitor System Help All tables All tables SAPDBA logs SAPDBA logs
E dit
COST - BASED OPTIMIZER Actions

S ystem Help Sort Sort End of action 22.03.1998 21.03.1998 15.03.1998 14.03.1998 10.03.1998 10.03.1998 10.03.1998 04.02.1998 04.02.1998 20.01.1998 19.01.1998 17.01.1998 16.01.1998 16.01.1998 16.01.1998 16.01.1998 16.01.1998 16.01.1998 16.01.1998 16.01.1998 16.01.1998 16.01.1998 11.01.1998 10.01.1998 02:28:12 02:24:54 02:21:09 02:27:17 14:22:54 11:59:12 11:02:54 13:00:55 11:21:22 07:58:57 18:29:35 11:02:27 19:23:03 19:01:41 19:00:11 18:11:20 18:07:39 16:34:06 15:54:59 15:31:56 15:27:15 15:25:18 05:04:28 11:01:41 Fct aly opt aly opt aly opt opt aly aly aly opt opt aly opt opt aly opt opt opt aly opt opt aly opt Object DBSTATCO PSAP% DBSTATCO PSAP% PSAP% PSAP% PSAP% D010T D010L DBSTATCO PSAP% DBSTATC_TAB DBSTATCO DBSTATC_TAB DBSTATC_TAB DBSTATCO DBSTATC_TAB DD02T DBSTATC_TAB DBSTATCO DBSTATC_TAB DBSTATC_TAB DBSTATCO DBSTATC_TAB
R
10.03.1998 15:41:59 BIN hs0061 Tables analyzed for Cost based optimizer
S elect options S elect options Begin of action
RC 0002 0001 0000 0000 0000 0002 0000 0000 0000 0000 0000 0002 0000 0000 0000 0001 0000 0000 0000 0000 0000 0002 0000 0000
22.03.1998 21.03.1998 15.03.1998 14.03.1998 Last SAPDBA-checkopt/analyze runs for cost based optimizer: 10.03.1998 checkopt (opt): date/time: 10.03.1998 11:59:12 return code: 0000 10.03.1998 analyze (aly): date/time: 20.01.1998 07:58:57 return code: 0000 For details see Transaction DB14 -> Function-IDs opt/aly10.03.1998 04.02.1998 04.02.1998 Table owner20.01.1998 Date of last analysis SAPR3 SYSTEM 19.01.1998 others 17.01.1998 16.01.1998 5 never analyzed 115 83 16.01.1998 0 older one year 0 1 16.01.1998 0 31 - 365 days 28 0 16.01.1998 0 8 - 30 days 0 0 16.01.1998 70 0 7 days 4.025 1 16.01.1998 16.01.1998 75 Total 4.168 85 16.01.1998 16.01.1998 16.01.1998 11.01.1998 10.01.1998
Init<SID>.ora parameter: OPTIMIZER_MODE: CHOOSE DB_FILE_MULTIBLOCK_READ_COUNT: 32
02:01:22 02:01:17 02:01:18 02:01:19 14:22:43 11:02:59 10:48:46 13:00:15 10:15:23 07:45:13 18:00:35 11:00:26 19:21:20 19:00:49 18:58:39 18:09:10 18:05:31 16:34:06 15:53:28 15:29:36 15:26:12 15:23:25 05:00:57 11:00:23
SAP AG
Use the following R/3 database monitors to check the state of the statistics. To display an overview of the analysis dates, use the Database Tables and Indexes Monitor (Transaction DB02) and choose Checks Dates of table analysis. To display detailed information about the table statistics for tables contained in the control table DBSTATC, choose All tables. To display the logs of the SAPDBA actions performed to refresh the optimizer statistics, use the DBA Logging Monitor (Transaction DB14) and choose DB Optimizer. To display either the SAPDBA check action logs (function ID opt) or the SAPDBA analyze action logs (function ID aly), choose Function IDs. Check the return code of the actions performed. Actions that did not end successfully are marked either yellow (warning) or red (errors). To display the details of a SAPDBA log, double-click a SAPDBA action.
2-118
BC360
Storage Management
Data objects
Tablespace
PSAPBTABD PSAPBTABD
Insertions
...\sapdata<i>\ btabd_1\ btabd_1\ ...\sapdata<j>\ btabd_3\ btabd_3\
btabd.data3
Logical layer Physical
btabd_2\ btabd_2\
Data files
btabd.data1 btabd.data2
Error
O RA-1653 O RA-1654 Insufficient free space for this extent
Extents of table 1 Extents of table 2 Extents of table 3 Gaps
Add data file
File size depends on the estimated increase of the tablespace objects
Extent allocation
0 Initial extent 1 2 3 4 5 300 ORA-1631 ORA-1632 Next extents
Error
MaxExtent
SAP AG
Each table and index is assigned to a tablespace, which consists of one or more data files at the operating system level. All table and index data is stored in the data files of the tablespace. Oracle stores tables and indexes in individual data blocks that are 8 KB in size. Several data blocks of a table or index are grouped together to form an extent. Oracle data objects have several storage parameters that influence growth. The first extent (initial extent) should be large enough for the expected table or index size. If an extent of a data object becomes full during an insert or update operation, the Oracle storage management system attempts to allocate another extent in the tablespace. An object can allocate extents up to the limit MaxExtents. The R/3 default value for MaxExtents is 300. If the maximum number of extents per object is reached, the error message ORA-1631 (for a table) or ORA-1632 (for an index) is displayed. If this occurs, you must increase the parameter MaxExtents and check the size of the next extent. The step-by-step allocation of extents ensures that objects only allocate space when they need it. If there is not enough contiguous freespace to allocate a new extent, the Oracle error message ORA-1653 (for a table) or ORA-1654 (for an index) is displayed. Oracle error messages are written to the Oracle log file and the R/3 System log (Transaction SM21).
2-119
BC360
Database System Check: sapdba -check

x
THU FRI SAT S AT SUN
P lanning G oto Listing Help System MON MO 01:00 CheckDB TUE W ED
10:00 CheckOp t 5:00 AnalyzeTab CheckO pt
Schedule sapdba -check to run once a week to check: TUE W ED THU FRI SAT SUN S AT Physical consistency of database 10:00 CheckOp t 5:00 AnalyzeTab CheckO pt Table and index fragmentation Database filling MON TUE W ED THU FRI SAT To display the results of sapdba -check, SUN MO S AT 01:00 Check Severe database errors in the alert log use 10:00 CheckOp t 5:00 AnalyzeTab CheckO pt the Database System Check Monitor Profile init<SID>.ora
MON MO 01:00 Check
01:00 CheckDB
01:00 MON check
M on
TUE
W ED
THU
Display view Table messages for DB system check: O verview FRI SAT SUN S AT
10:00 CheckOp t CheckO ystem AnalyzeTab T able view Edit Goto S election Spt 5:00Help V ariable list V ariable list
sapdba -check generates the log file <DateTim e>.chk in directory sapcheck and in the database
Error ORA ORA ORA DBA DBA DBA
Parameter ID 1113 600 600 CRITICAL_SEGS CRITICAL_SEGS CRITICAL_SEGS
Check time 9801171000 9801151708 9801141933 9801120401 9801110400 9801101000
Severity E E E W W W
Check description ORA-1113 signaled during: ORA-00600: internal error ORA-00600: internal error SEGMENT(S) DOKTL_____0 WOULD SEGMENT(S) DOKTL_____0 WOULD SEGMENT(S) DOKTL_____0 WOULD
R
SAP AG
Use the SAP tool SAPDBA to check the following: Table and index fragmentation Tablespace filling Physical consistency of the database. That is, the consistency of the control files, redo log files, and data files Severe error messages in the alert log init<SID>.ora parameter settings Database problems specific to the R/3 environment Schedule SAPDBA to run once a week, using either the DBA Planning Calendar (Transaction DB13) or entering the following command at the command prompt: sapdba -check. Command sapdba -check generates a log file called <DateTime>.chk, which is written to directory sapcheck. The log information is also written to a database table and can be viewed using the R/3 Database System Check Monitor (Transaction DB16). This log information should be monitored after each sapdba -check run. If a database or system error occurs, you can also use command sapdba -check to check the log information.
2-120
BC360
Daily Monitoring: Next Extent Problems

- ... Database performance: T ables and Indexes Database Checks x
Tablespaces Tables/Indexes
Tables or indexes grow and allocate m ore extents than expected
O RA-1631 O RA-1632 Insertions ... Error 300
Run sapdba -next PSAP% weekly

CCMS P lanning Calend ar P lanning Goto Listing Help System M O N TUE WE D THU FRI S AT S UN ON W ED F RI SUN M O N TUE WE D THU FRI S AT S UN ON W ED F RI SUN M O N TUE WE D THU FRI S AT S UN ON W ED F RI SUN
m ax
1 extent per object last 4 weeks
Database System Check Monitor

Display view Table m essages for DB system check: Overview
M O N TUE WE D THU FRI S AT S UN ON W ED F RI SUN
SAPDBA
d - Reorganization Alter storage param eters

R
Table view Edit G oto S electio n S ystem Help V ariable list V ariable list
Error ORA ORA ORA DBA DBA DBA Parameter ID 1113 600 600 CRITICAL_SEGS CRITICAL_SEGS CRITICAL_SEGS Check time 9801171000 9801151708 9801141933 9801120401 9801110400 9801101000 Severity E E E W W W Check description ORA-1113 signaled dur ORA-00600: internal e ORA-00600: internal e SEGMENT(S) DOKTL_____0 SEGMENT(S) DOKTL_____0 W SEGMENT(S) DOKTL_____0 W
The results of sapdba -next are written to file <DateTim e>.nxt in directory sapcheck
SAP AG
To avoid problems with the next extent size, SAPDBA has an automatic extent adjustment (-next). Use the DBA Planning Calendar (Transaction DB13) to schedule this adjustment to run at least once a week for critical tablespaces that have high data growth. To run the SAPDBA extent adjustment from the command prompt, enter: sapdba -next PSAP%. The results of sapdba -next are written to directory sapcheck in file <DateTime>.nxt and can be displayed using the DBA Logging Monitor with function ID nxt. To adjust the storage settings for single objects, use SAPDBA, and enter d - Reorganization. The value for the next extent (Next) should be at least 10% of an object's current size. To display a list of tables and indexes that have allocated more than 1 extent in the last four weeks, use the Tables and Indexes Monitor (Transaction DB02) and choose Check Check next extent size. Look for objects that, as a result of frequent insert operations, have allocated too many extents or approach the MaxExtents limit. The R/3 Database System Check Monitor (Transaction DB16) displays information about objects that are exceeding a threshold of extents (default: 80) or are approaching the MaxExtent limit.
2-121
BC360
Daily Monitoring: Freespace Problems

Tablespace extension
Error
Insertions
Tablespace (tables or indexes)
ORA-1653 ORA-1654
Objects grow and allocate new extents until the pre-allocated disk space is full
-
Database System Check Monitor

x
Display view Table m essages for DB system check: Overview
Table view E dit Goto S election S ystem Help V ariable list V ariable list
Error ORA ORA ORA DBA DBA DBA Parameter ID 1113 600 600 CRITICAL_SEGS CRITICAL_SEGS CRITICAL_SEGS Check time 9801171000 9801151708 9801141933 9801120401 9801110400 9801101000 Severity E E E W W W C heck description ORA-111 3 signaled dur ORA-006 00: internal e ORA-006 00: internal e SEGMENT (S) DOKTL_____0 SEGMENT (S) DOKTL_____0 W SEGMENT (S) DOKTL_____0 W
Extents
- ... Database performan ce: Tables and Indexes x
New disk?
-
Database Checks
SAPDBA
Tablespaces Tables/Indexes
Add data file
c - Tablespace adm inistration

R
SAP AG
Use the Tables and Indexes Monitor (Transaction DB02) to: Analyze the tablespaces that are marked as having critical freespace problems Check the rate of the fill level to determine when a tablespace reaches a critical fill level Check the Database System Check Monitor (Transaction DB16) for freespace problem alerts. Potential bottlenecks in the freespace reserve of a tablespace are displayed in the log of command sapdba -check. Extend critical tablespaces early. To do this, use the SAPDBA and select c - Tablespace administration. NOTE: Extending tablespaces may take a long time, for example, if a new disk must be purchased and installed. Ensure that the size of the new data file, which is the location of the tablespace extension, is large enough. If necessary, you can add a new hard disk and create a sapdata<n> directory. Check the maximum number of data files allowed in your database. This number is defined in the init<SID>.ora parameter DB_FILES. NOTE: A hard limit of data files (MAXDATAFILES) is defined during database creation. This hard limit can only be changed by recreating the Oracle control file. After the structure of the data files have been changed, back up the database, or at least the newly added data file and the control files.
2-122
BC360
Daily Monitoring: Backup

Possible backup errors: Tape defect W rong tape label Tape too sm all Corrupt blocks
Schedule a new database or log backup
-
Check the success of the database and offline redo log backups
MON MO Full On line O nline MON MO

TUE Full O ffline Offline TUE WE D W ED THU FRI S AT S UN
P lanning G oto Listing Help System
WE D W ED
THU
FRI
S AT
S UN
CCM S Database Backu p Logs THU FRI
x
S AT S UN
M ON Full Online M ON

TUE Full Offline O ffline TUE WED WE THU FRI SAT SUN S UN
P lanning G oto N M O Listing Help System TUE WE D MO W ED Recovery report Recovery report Refresh Refresh
MON TUE WE D MO W ED Last successful database backup Last successful database backup O verview of all database backup logs O verview of all database backup logs
THU
FRI
S AT
S UN
WED WE
THU
FRI
SAT
SUN S UN S tatus of log directory S tatus of log directory
M ON
TUE
WED WE
THU
FRI
SAT
SUN S UN
S tatus of most recent redo logs S tatus of most recent redo logs O verview of all recent redo log backup logs O verview of all recent redo log backup logs
M ON
TUE
WED WE
THU
FRI
SAT
SUN S UN
SAP AG
The Backup Log Monitor (Transaction DB12) displays information about: The database and offline redo log file backups The log files written by BRBACKUP and BRARCHIVE The last unsuccessful backup The last successful backup All the backup actions performed The state of the archive directory How your database and offline redo log file backups could be used for a recovery The DBA Planning Calendar (Transaction DB13) displays the status of all the activities that were performed.
2-123
BC360
Daily Monitoring: Archive Directory

SAPGUI is hanging
- . APG . S .... UI x ______________________ ______________________ ______________________ ______________________
DBM S
ARCHIVELOG m ode
...\saparch O ffline redo log files
Ensure there is enough free space in directory saparch for the offline redo log files created in one day
- Comm and prom pt x brarchive -cds (copy_ delete_ save)
Archiver
Archiver is not running Archive directory is full Backup Logs: Overview
Archiver stuck when:
BRARCHIVE
< SID> A01 <SID>A01 < SID> A01
SAPDBA
Archiver not running: start archiver

SAP AG
Status of lo g directory Status of lo g directory Status of m ost recent redo logs Status of m ost recent redo logs
R
Overview of all recent redo log backup logs Overview of all recent redo log backup logs
If an archiver stuck situation occurs: The database system cannot write to the online redo log files The database cannot perform any modifications to the database data SAPDBA cannot connect to the database If the archiver becomes stuck, monitor the database error logs. The archiver can become stuck if : The database is in archive mode, but the Oracle archiver is not running. If this occurs, SAPDBA displays an error message. Use SAPDBA to start the Oracle archiver. The archive directory overflows, due to a large amount of data manipulation (such as from upgrades or batch input). If this occurs, you must make space available in the archive directory. To make space available in the archive directory, back up the offline redo log files to tape, using SAPDBA or the BRARCHIVE function cds. Offline redo log files should only be deleted if they are backed up twice. NOTE: When there is space available, create "temporary files" (the same size as the offline redo log files) in the archive directory. In the case of an archiver stuck situation, these files can be deleted to free up space.
2-124
BC360

Monitor the storage behavior of the database Extend tablespaces Monitor the storage behavior of data objects Adjust data object storage Avoid error situations Monitor the state of the optimizer statistics Refresh the optimizer statistics
SAP AG
To prevent database errors from occurring, perform the following monitoring and maintenance tasks on your Oracle database: Monitor the state of the optimizer statistics Update the optimizer statistics Monitor the database alert log Check the tablespace fill levels and increase their size when necessary Monitor the table and index extent growth Monitor the offline redo log activity
2-125
BC360
Unit Actions
Do the exercises

R
SAP AG
2-126
BC360
No. 1) 1.1 1.2 1.3 2) 2.1
Exercise Cost based optimizer Use the CCMS to schedule the action that determines which database tables in all tablespaces require newer statistics. Use the CCMS to schedule the action that updates the statistics of all database tables determined by the action scheduled in exercise 1.1. Use CCMS to display an overview about the state of the optimizer statistics. Check the database Start sapdba -check from operating system (this can take about 10 minutes) and check the log. Monitoring tablespaces Check whether there are space problems in a particular tablespace, or whether there will be any space problems in the next 10 days. What should you do when a tablespace is too small? Increase the size of the tablespace PSAPUSER1D by 10%. Archiver Stuck Check whether there is still enough space in the archive directory.
3) 3.1 3.2 3.3 4) 4.1
2-127
BC360
No. 1) 1.1
Solution
Open the DBA Planning Calendar (Transaction DB13). Double-click todays date. In the dialog box displayed, select Check optimizer statistics. In the next dialog box, select PSAP%. Open the DBA Planning Calendar (Transaction DB13). Double-click todays date. In the dialog box displayed, select Create new optimizer statistics/space statistics. In the next dialog box, select DBSTATCO: all tables marked in DBSTATC. Open the Tables and Indexes Monitor (Transaction DB02). Choose Checks Dates of table analysis.
1.2
1.3
2) 2.1 3) 3.1 Log on to the R/3 System. From the main menu choose Tools CCMS Control/Monitoring Performance menu Alerts Global Database System. Check the traffic light beside Freespace Management checked on <timestamp>. If the traffic light is green, there is enough space in your database. If the traffic light is not green, choose Freespace Management checked on <timestamp> to display a list of all tablespaces and a warning message about the space problem. Add a datafile using SAPDBA. Modify the file init<SID>.dba. Enter the value 10 in parameter tspadd_tspname PSAPUSER1D. Start SAPDBA and choose c - Tablespace administration a - Enter tablespace name. Enter PSAPUSER1D. To add a data file, choose f - Alter tablespace PSAPUSER1D add datafile, and then choose s - Start. 4) 4.1 Log on to the R/3 System and choose Tools CCMS DB Administration Backup logs. Choose Status of log directory. Alternatively, call SAPDBA at operating system level and choose f - Archive mode c - Show all archive information To view the results displayed by the Database System Check Monitor (Transaction DB16), using the log file in the sapcheck directory.
3.2 3.3
2-128
BC360
In the following, you will find excerpts from the Operation Manual, Chapter 7 Database Administration, in the section DBA Planning Calendar. To perform these exercises, complete the tables in the excerpts as follows:
The tables under Configuration Documentation. In your system, check when optimizer statistics functions are scheduled and enter this information in the appropriate tables.
Enter your timetables for database processes in the following tables. Schedules for backups are documented in Chapter 8, Performing Backups. Timetable for Check Optimizer Statistics The automatic checking of statistics on data distribution in tables must be scheduled regularly. This check is resource-intensive and should therefore occur during periods of low system load. Document your scheduling in the following table: System Name <PRDSID> <QASSID> <DEVSID> Mon. Tue. Wed. Thu. Fri. Sat. Sun.
Timetable for Create New Optimizer/Space Statistics Statistics which are regarded as outdated by the system during the Check optimizer statistics process are newly generated in the process Create New Optimizer/Space Statistics. This process is resource-intensive and should therefore occur during periods of low system load. Document your scheduling in the following table: System Name <PRDSID> <QASSID> <DEVSID> Mon. Tue. Wed. Thu. Fri. Sat. Sun.
2-129
BC360
No. 1) 1.1
True?
Question: Which of the following statements are true: Oracle for R/3 is configured in a way that Oracle will automatically allocate more space on an available disk if a tablespace becomes full. Therefore, you do not have to monitor available freespace in an Oracle database. It is completely normal and unavoidable that end user transactions regularly run into errors due to full tablespaces. Oracle can define an unlimited number of extents for tables and indexes. There is nothing you can do about excessive extent growth for tables and indexes. You should always perform a complete reorganization of a table that has more than 20 extents. Up-to-date statistics are necessary to ensure that the Oracle CostBased Optimizer chooses the optimal access path.
1.2 1.3 1.4 1.5 1.6
2-130
BC360
No. 1) 1.1
True?
Question: Which of the following statements are true: Oracle for R/3 is configured in a way that Oracle will automatically allocate more space on an available disk if a tablespace becomes full. Therefore, you do not have to monitor available freespace in an Oracle database. It is completely normal and unavoidable that end user transactions regularly run into errors due to full tablespaces.
1.2 1.3 1.4 1.5 1.6 X X
Oracle can define an unlimited number of extents for tables and indexes. There is nothing you can do about excessive extent growth for tables and indexes. You should always perform a complete reorganization of a table that has more than 20 extents. Up-to-date statistics are necessary to ensure that the Oracle CostBased Optimizer chooses the optimal access path.
Oracle Database Administration CD SAPNet:

TechNet
R/3 Online Documentation:

SAP Database Administration: Oracle C CMS Database Administration
BC505 Oracle Database Administration
SAP AG
2-131
BC360
The topics covered in this unit are available on the SAP Knowledge Product CD: Oracle Database Administration. The R/3 Online Documentation provides further information about using the CCMS and monitoring the database. To improve database administration skills, such as handling error situations, the following database workshop is offered: BC505 Oracle Database Administration
Background Processing
SAP AG
2-132
BC360
Introduction to Background Processing

Contents:
Overview of the R/3 background processing environment
Objectives:
At the end of this unit you will be able to: Describe the basic capabilities of background processing Describe the following components and explain what they do: ABAP program s, external programs, external comm ands, events, internal and external API function modules, RFC interface Define and schedule background jobs Execute: ABAP program s External programs External comm ands
SAP AG
2-133
BC360
Introduction to Background Processing

Objectives (cont.):
Describe the background workload distribution capabilities Assign background job classes to prioritize your jobs Monitor background jobs Explain the authorizations for: System administrators End users Describe how ABAP internal and external job API function modules can be used Make use of the R/3 background processing functionality
SAP AG
2-134
BC360
Course Roadmap
SAP AG
2-135
BC360
W hat are Background Jobs?

Background jobs are:
Collections of one or more ABAP programs, external programs or external commands that run sequentially, without user intervention.
Background jobs can:

Process routine tasks automatically Process data collected from legacy system s Be scheduled to run dynamically based on events occurring in and out of the R/3 system Process mass data loads at times of low system activity, without affecting online transaction processing
SAP AG
2-136
BC360
Background Processing Features (1)

Scheduled jobs use the workload distribution functionality unless they are assigned to a specific application instance Background jobs are assigned to class A, B, or C Background work processes can be reserved for jobs assigned to class A
You can reserve one or more background work processes to execute only class A jobs. Jobs assigned to class B or C are never scheduled in these reserved work processes
SAP AG
2-137
BC360

Operation modes can be used for switching between dialog and background work processes without having to stop and start the R/3 Instance Jobs can be scheduled to run based on events raised inside or outside of the R/3 system Jobs can be scheduled to execute external programs and external commands in the R/3 system
SAP AG
2-138
BC360

The Job Scheduling M onitor in CCM S provides a graphical view of the background processing environment. Jobs can be scheduled and managed using:
ABAP program s based on the standard SAP delivered internal function modules (Job API) SAP standard application transactions using the Application Programm ing Interface (Job API) Standard SAP-delivered external function m odules that form the External Job Application Programming Interface (XBP-API) for use in external systems
SAP AG
2-139
BC360
Scheduling and Processing

Dialog and Background Server
W Ps Dia Dia Btc Btc Btc
Job-scheduling table
Job# Nam e Cls Tim e Target 0010 0020 0030 0040 0050 0060 Job Job Job Job Job Job 1 2 3 4 5 6 A C C B C A 08:00 09:10 10:20 10:20 14:50 14:50
Dialog and Background Server Dialog Server

W Ps Dia Dia Dia Btc Btc
SAP AG
W Ps Dia Dia
Background processes can be configured on any R/3 instance using the Instance profile parameter (rdisp/wp_no_btc). The combination of Job# and Job Name make the job unique in the system. Background jobs can be scheduled in Class A, B, or C. A minimum of 2 dialog work processes are required per instance, and these are distributed as follows: The background scheduler uses 1 dialog work process for checking and scheduling background jobs. The user needs 1 dialog work process for online work. There is no minimum requirement for the number of background work processes. Background work processes are defined based on the amount of background jobs to be processed in each instance. Note: When using the transport system, a minimum of 2 background work processes must be made available.
2-140
BC360
Jobs Selected for Execution

Dialog and background server
System Clock
Job# Nam e Cls Tim e Target 0010 0020 0030 0040 0050 0060 Job Job Job Job Job Job 1 2 3 4 5 6 A C C B C A 08:00 09:10 10:20 10:20 14:50 14:50
Background scheduler
Table checked every 60 seconds

Dialog and background server
System Clock
Dialog server
Background scheduler
SAP AG
Every server with defined background work processes has a background scheduler active on it. The background scheduler checks the job-scheduling table periodically. To specify the interval between periodic checks, set the instance profile parameter rdisp/btctime. The default value is 60 seconds. Jobs can be scheduled, for example, as Immediate, Date/Time, Event-based. If Immediate or Event-based jobs cannot be executed due to lack of resources, they are placed in the job scheduling table and processed as Date/Time scheduled jobs. After activation, the background scheduler: Checks the job-scheduling table Selects jobs that have not yet been executed and have a start time and date already passed, or are scheduled to start immediately Gives control to the Dispatcher which assigns a Btc work process.
2-141
BC360
W orkload Balancing
Dialog and Background Server1
System clock Message server The message server maintains a table of available servers with BTC work processes
Job# Nam e Cls Tim e Target 0010 0020 0030 0040 0050 0060 Job Job Job Job Job Job 1 2 3 4 5 6 A C C B C A 08:00 Server1 09:10 10:20 10:20 14:50 14:50

System clock

SAP AG
For event-based jobs, the message server checks its table of servers to determine where the available BTC work processes are and randomly selects a server based on this observation to execute the jobs. For time-based jobs, the background scheduler servicing the Job Scheduling table at this time makes a request to the dispatcher on its server, to execute the selected background jobs in its available BTC work processes. Jobs that have been selected for execution but cannot run because a BTC work process is not available may be selected for execution by another server when that server's background scheduler starts. NOTE: If you designate a target server, you lose the advantage of automatic workload distribution. However, you may need to designate a target server to make use of its particular resources.
2-142
BC360
Operation Mode Setup and Switching

Server1 From startup
WPs
Server1 After operation mode switch

W Ps
Dia Dia Dia Dia Btc Btc

Application server: Server 1 Op. mode: Daily O perations Instance Work Processes Dialog 4 Background 2 - Class A 0 Update 0 V2 Update 0 Enqueue 0 Spool 0
Total 6
Op. mode definitions
Dia Dia Btc Btc Btc Btc

Application server: Server 1 Op. mode: Daily Background Operations Instance Work Processes Dialog 2 Background 4 - Class A 1 Update 0 V2 Update 0 Enqueue 0 Spool 0 Total 6
SAP AG
Operation modes are used to change the distribution of dialog and background work processes and to reserve background work processes for Class A jobs. From startup, all instances should be configured with an operation mode that matches the instance profile. In this example, Server1 is configured with the operation mode Daily Operations based on parameters specified in the instance profile. After an Operation Mode Switch, Server1 is configured based on the entries specified in the operation mode Daily Background Operations, as shown in this example. If there are jobs running in the processes to be switched, they are flagged as having a switch pending, but the jobs are allowed to complete.
2-143
BC360
Scheduling Priorities
Dialog and Background Server 1
System clock Message server The message server maintains a table of available servers with BTC work processes
Job# Nam e Cls Tim e Target 0010 0020 0030 0040 0050 0060 Job Job Job Job Job Job 1 2 3 4 5 6 A C C B C C 08:00 Server1 08:00 08:00 08:00 08:00 08:00

System clock

SAP AG
This job is selected but must wait for an available Btc work process
All scheduled jobs are prioritized at runtime. The job-scheduling table in this example shows jobs scheduled for 08:00. The job scheduler uses the following selection criteria: 1. Class A jobs with a designated target server 2. Class A jobs without a designated target server 3. Class B jobs with a designated target server 4. Class B jobs without a designated target server 5. Class C jobs with a designated target server 6. Class C jobs without a designated target server
2-144
BC360
Configure a Background Job

Define Background Job Job Edit Goto System Help Start date Steps
Define Background Job
General data Job name Job class Status Target host Job start
Create the step(s)
Scheduled Spool list recipient
Schedule the job

Recipient determination Recipient G eneral attributes Reply required Copy No printing Express
Job frequency
ToDo Blind copy No forwarding Repeat send
Copy
SAP AG
Fax entry
Address
To define a background job, perform the following steps: Choose Tools CCMS Jobs Define. Specify a job name and job class. To send the spool requests to an SAPoffice user: Choose Spool List Recipient. Enter one of the following in the field Recipient: A user's SAPoffice mail name SAPoffice distribution list R/3 user ID An external electronic mail address Activate any mailing options you wish to use, for example, Express, which notifies the recipient as soon as a spool list is available. To save the recipient, choose Copy. All spool requests generated by the job are now sent to this recipient. To specify the step information, choose Steps, then save the step information. To specify the scheduling information, choose Start Date then save it. Save the job data.
2-145
BC360
Executing Programs in the Background

R/3 System Job 1 1 Step Execute ABAP program Step 1 ABAP program
R/3 System Job 2 2 Steps Execute Ext. program(s) or Ext. Com m and(s) using RFCs
SAPXPG Server program SAPXPG Server program
Step 1 External program-1 Step 2 External program-2
1 1
1 1
Synchronous processing - The job waits until SAPXPG returns with the final status from the external program . Return codes can also be processed. Asynchronous processing - The job proceeds im m ediately to the next job step once it has started SAPXPG. Return codes cannot be reacted to, but they are visible in the job log.
SAP AG
ABAP programs can be executed in background jobs. However, a variant may be required if the report has a selection screen. The R/3 System starts an external program/command by starting the server program SAPXPG on the target host system through a Remote Function Call (RFC). External programs can consist, for example, of non-R/3 programs, commands, and scripts, which can be executed only by users with the R/3 background administrator authorization. External commands are defined by the background administrator and can consist, for example, of non-R/3 programs, scripts, and commands, which are executed by users with the proper R/3 authorizations. ABAP programs are executed synchronously, while external programs and commands can be run either synchronously or asynchronously, depending on the user's operational needs. All job executions are recorded in the job log. Remember that all jobs can be scheduled for execution in many different ways: Immediately - Date/Time - Dependent on an Event - Dependent on a Job - etc.
2-146
BC360
Defining New Events Using CCMS

Edit User Events
Choose Event identifier System Help Display C reate Action log Delete
Event identifier SAP_LANGUAGE_IMPORT SAP_DATA_IMPORT . . . .
Description Language import Data copying completed . . . .

Create New Entry
END_OF_DATA _TRANSFER Event ID Description This is a new user-defined event
Choose
Save
Cancel
SAP AG
To define new events using CCMS, choose Tools-->CCMS-->Jobs-->Define event. New events must be defined as either an R/3 System event or a USER event. Typical R/3 System events are: SAP_END_OF_JOB SAP_OPMODE_SWITCH SAP_SYSTEM_START SAP_SYSTEM_STOP SAP_TRIGGER_RDDIMPDP Do not use the R/3 System events for your own programs, as these events may be changed by future R/3 releases. An example of a USER event is: END_OF_DATA_TRANSFER
2-147
BC360
Internal Triggering of Events

Event Release Event in Background Processing Edit Goto System Help ?
Choose pulldown
Event Nam e Param eter

E ND_O F_DATA_TRANS FER
Choose
Trigger
Background processing event Background processing event SAP_BRANCHE_IMPO RT SAP_DBA_ACTIO N SAP_EIS_DATA_IMPO RT SAP_END_OF_JOB SAP_LANGUAGE_FILL SAP_LANGUAGE_IMPORT SAP_NEW _CONTRO L_RECIPES END_OF_DATA_TRANSFER
Double-click
SAP AG
To manually trigger an internal event from within the R/3 System, choose Tools-->CCMS-->Jobs-->Raise event. A complete list of all events defined in the R/3 system is displayed in the pulldown screen. You can select a name from the list or enter the name of the event. An optional parameter ID can be used to distinguish identical events from one another. After triggering the event, any jobs waiting on the event named END_OF_DATA_TRANSFER are now scheduled for execution. You can also start events using the R/3 standard function module BP_EVENT_RAISE. To do this, choose Tools-->ABAP Workbench-->Function builder.
2-148
BC360
External Triggering of Events

Internal or external environment Sapevt program
Event End_OF_DATA_TRANSFER is triggered in the message server
R/3 System
Any background job(s) waiting on the event END_OF_DATA_TRANSFER are now scheduled for execution
SAP AG
To trigger an event on an external system, use the operating system executable sapevt. The syntax for sapevt is: \usr\sap\<SID>\SYSexe\runsapevt <event ID> [ -p <event parameter> ] [ -t ] [pf=<profile name>] [name=<SID>] [nr=<instance number>] <event ID> <event parameter> -t <profile name> <SID> = event name as defined in the CCMS (required) = parameter specified (optional) = tracefile creation (optional) = pf=(pathname to profiles) (optional) = name of R/3 System (optional)
<instance number> = R/3 System instance number (optional) Example: sapevt END_OF_DATA_TRANSFER name=C11 nr=10 A TCP/IP connection is made through the R/3 message server.
2-149
BC360
Executing Programs Based on Events

Step 1 External program 1 Step 2 External program 2 is sapevt, w hich triggers the event END_OF_DATA_TRANSFER
R/3 System Job 3 2 Steps Execute external program (s) or external com m and(s) through RFCs
R/3 System Job 4 1 Step Execute ABAP program triggered by event END_OF_DATA_TRANSFER
Job step 1 ABAP program
SAP AG
ABAP programs and external programs can raise events which cause other background jobs to be scheduled for execution, dependent on these events.
2-150
BC360
Add Steps to an Existing Background Job 1

Job Overview: Alphabetic Job Edit Goto System Help Job log Job name DISPLAY_ACTIVE_USERS DISPLAY_ACTIVE_USERS_1 DISPLAY_ACTIVE_USERS_2 Release Refresh Spool list Steps
Scheduled Released Ready Active Finished Cancelled X X X
Job Overview Screen

1. Select Job to ADD steps to 2. Select Job Change
Edit Job DISPLAY_ACTIVE_USERS_2 Job Edit Goto System Help Back Start date General data Job name Job class Status Target host Job start Steps Job details Predecessor job Successor job(s)
DISPLAY_ACTIVE_USERS_2 C Scheduled
Job frequency
Edit Job Screen

3. Choose STEPS
SAP AG
To display the Job Overview Screen, use Transaction SM37. From the main selection screen, choose Enter. To add steps to an existing job, follow the steps shown in this screen. You can only change a job that has the status Scheduled or Released. Jobs that are running or have already run can not be changed. To change the status of a job that has already run, select Job Copy. You can give the job a new name or you can keep the same name. Now the status is Scheduled, and the job can be maintained.
2-151
BC360
Add Steps to an Existing Background Job 2

Create Step 3 User D012345
Step List Step Edit Goto System Help
Program values ABAP program External command External program
Back No. 1 2
Spool list Program name/command RSUSR000 RSPARAM

ABAP program Nam e Ext. Pgm. List Parameters Variant Language
User D022785 D022785
Create Step Screen

5. Enter your step data then SAVE
DEW1
Step List Screen

4. Choose ADD
External com mand (command pre-defined by system adm inistrator) Nam e Param eters Operat. system Target host
External program (direct command input by system adm inistrator) Nam e Param eter Target host
Check
Print specifications
Variant list
SAP AG
When the steps have been added and saved, the job can be rescheduled for execution. Remember to save all the job changes and the scheduling information.
2-152
BC360
Reschedule a Background Job

Job Overview: Alphabetic Job Edit Goto System Help Job log Job name DISPLAY_ACTIVE_USERS Start Tim e Imm ediate
1
Release Refresh
Spool list
Steps
Scheduled Released Ready Active Finished Cancelled X
Date/Tim e
After job
After event
At operation mode
>>
Select the job to be rescheduled Select: Job --> Schedule job--> Repeat Click on the button for the type of scheduling wanted Save the job
SAP AG
Date/Tim e Scheduled start No start after After job
Date Date
22.06.1998
Time Time
16:04:52
At operation mode
After event
Periodic job
4
Check
Period values
Restrictions
To display the Job Overview screen, use Transaction SM37. From the main selection screen, choose Enter. To reschedule a job that has already run, follow the steps as shown in this screen. When you use the function Schedule Job, you can only specify job scheduling information. No other job changes may be performed here. To reschedule a job that is still in Released or Scheduled status, choose: Job-->Change. Then change the scheduling criteria and any other information about the job.
2-153
BC360
Reviewing the Background Job Log for Errors

Job Overview: Alphabetic Job Edit Goto System Help Job log Job name DISPLAY_ACTIVE_USERS Release Refresh Spool list Steps
Job Log Entries for DISPLAY_ACTIVE_USERS Job log Edit Goto System Help
1
Select the job to be viewed Choose Job log Review the job log for error m essages
Long text Date
Previous page Time 16:04:52 16:04:52 16:04:53
Next page Msg.ID/No 00 00 00 516 550 517 Message Job started Step 001 started (program RSUSR000, Job finished
22.06.1998 22.06.1998 22.06.1998
SAP AG
To review the background joblog for errors, access Job Overview and follow the steps as shown in this screen. If the job shows errors, use Transaction SM21 to review the SAP System Log (SAPLOG) for details.
2-154
BC360
Review Spool Lists from Background Jobs

Job Overview: Alphabetic Job Edit Goto System Help Job log Job name DISPLAY_ACTIVE_USERS Release Refresh Spool list Steps
Spool: Requests Spool request Edit G oto Environment SystemRequest 0000027404 Spool: Help Spool request Edit Goto Environment System Help
1
Select the job to be viewed Choose Spool List Choose the entry you want Choose the glasses icon
SAP AG
Back Spool No.
Output requests As attr. User name Generation Output Title or Back Hex Number of list lines Date Time Status Pages Spool req. name System TC1 0000027404 22.06.98 14:04 Day, Time 1 22.06.1998 LIST1S RSUSR000_WIR 16:04:52
Active instance pswdf694_TC1_00 1
Number of active users 2 2 users
destinations with
To display the spool list, access Job Overview and follow the steps shown in this screen. To send a spool list to a printer, display the Spool List screen, then choose Printer.
2-155
BC360
Job Monitoring - Job Overview

Job
Job log
Edit
G oto
System
Job O verview: Alphabetic Help

Steps
Job Overview screen
Release Refresh
Spool list
Job name
Scheduled Released Ready Active Finished Canceled X X X X X X X X X X
SAP R/3 Job Edit G oto
System
Job name User nam e Start date
* Smith
Date From To
05.02.1997 06.02.1997
APPL-RW_FI Help ARFC:9B38012130E83311209B2000E ARFC:9B38013D1FBB8311223740043 CATT PS COLLECTOR_FOR_PERFORMANCEMONITOR COLLECTOR_FOR_PERFORMANCEMONITOR COLLECTOR_FOR_PERFORMANCEMONITOR EC-PCA EC-PCA SAP-LANGUAGE-EXEC-RSLANGCP
Or start after event Further selection criteria Only jobs with status
Job has no start time specified Job scheduled and waiting for selection
x Scheduled x Released x Ready
x x x
Active Finished Canceled
Job has been selected for execution Job is executing Job finished execution successfully Job executed with problems
SAP AG
The information displayed on the Job Overview screen depends on the selections you have made from the main selection screen (SM37). When you have jobs scheduled waiting on an event, you must remember to select the field Or start after event on the main selection screen. When you have jobs that have not been assigned a start date, remember to select Jobs without start date in the main selection screen. When you have jobs that have been scheduled based on a previous job, you must remember to select Jobs with previous job on the main selection screen. From the job overview screen, you can also change the status of scheduled jobs.
2-156
BC360
Job Monitoring - Job Scheduling Monitor

Com puting Center Management System
Job Scheduling M onitor SAP-System TC1

Th 16 April 1998 14:00 15:00
Job Server
hs5821 hs5821 hs5821
Reserved for Class A C
hs5825 hs5825
hs5860 Th 26.05.94 13:49:59
SAP AG
To access the Job Scheduling Monitor, use the following menu path: Tools-->CCMS-->Control/Monitoring-->Job Schedul. monitor. The column Job Server indicates the names of the servers. Duplicate names indicate multiple BTC work processes configured for the server. If a server name is not displayed, no operation mode has been defined for that server. If an operation mode has been configured to reserve BTC processes for class A jobs, this is also indicated in the display. Each box displayed by the Job Scheduling Monitor represents a background job. To find detailed information about the job, select one of the boxes. For an explanation of all items and colors displayed, choose Legend.
2-157
BC360
Programm ing a Job W orkflow with ABAP

Job dependencies in SAP standard
Jobs can be run sequentially.
Jobs developed with the Job API

A job can be started and controlled from another job that was started periodically.
Job 1
Job 2
Job 3 Job 3 starts when Job 2 is finished
Job 1 Job 1 periodically started
Job 2
Job 2 Job 1 Job 3 Jobs can be run in parallel.
Jobs can be run in parallel and then be followed by another background processing job. Job 2 Job 1 Job 3
Job 4
SAP AG
To manage and schedule jobs from your ABAP programs, use the internal function modules grouped together in the Background Job Application Programming Interface (Job API) You can use the Job API to: Schedule jobs to run sequentially Schedule a job to be triggered by another job that runs periodically Incorporate decision logic into your job processing environment To find these ABAP Internal API function modules, access the ABAP Workbench, and choose Function Builder. The naming convention for the internal function modules is: BP_ followed by the function each module performs.
2-158
BC360
The External Job XBP-API / CCMS XMI-API
Offers a comprehensive set of interfaces that use the XMI function modules to integrate CCM S with existing system management environments Core competence remains with CCM S since external tools use the CCM S XM I function modules CCM S remains the complete tool for R/3 management
SAP AG
XMI - eXternal Monitoring Interface In the R/3 System, all external CCMS interfaces use the same function modules. These function modules can also be grouped together in an interface. The XMI is an interface that logs the activities of users and agent programs each time an XMI function module is called. XBP - eXternal Interface for Background Processing is the external background job-scheduling interface. Only XBP API function modules can be used to connect agents. The Job API in ABAP uses internal BG function modules and therefore cannot be used as an external job-scheduling interface. The naming convention for the external function modules is: SXMI_ followed by the function each module performs.
2-159
BC360
XBP Concept
R/3 System: C11

Dispatcher Dialog Batch Job AA Query Job Status Start a Job XBP
Non R/3 Job Scheduling System

Job AA on R/3 C11 1 2 3
10 9 8
Job BB on R/3 XYZ Job ZZ on Non-R/3 System 4

11
12
1 2 3 4
R/3 System : XYZ

Dispatcher Dialog Batch Job BB
Interface
Non-R/3 System
Start a Job
Job ZZ
SAP AG
In this example, the external job-scheduling system executes the following tasks: 1. Query the job status on the R/3 System C11 2. Start job AA on the R/3 System C11 3. Start job BB on the R/3 System XYZ 4. Start job ZZ on the non-R/3 system Jobs can be created and monitored from outside the R/3 environment using certified 3rd-party software tools. For a list of available certified solutions, see: SAP Complementary Software Program (CSP) XBP (EXternal Interface for Background Processing) is the external job-scheduling interface.
2-160
BC360
Tools for Administrators and End Users

Responsibilities
Define and configure R/3 Authorizations Define and execute external commands Execute ABAP programs Execute external programs Execute external commands Define and configure background jobs Execute background jobs Define and configure operation modes Develop user interface with API function modules Configure the RFC interface Monitor the background environment Define and raise events
R/3 End Adm in user X X X X X X X X X X X X X X X X X
Tools
PFCG ,SU01,SU02,SU03 SM49,SM69 SA38 SM36,SM37 SM36,SM37 SM36,SM37
*)
SE38, SA38, SM37 *) RZ04,RZ10,SM63 SE38 RZ12,SM59 RZ01,SM37,SM39,SRZL RZ10 SM62,SM64
* Standard application transactions can also define and execute background jobs
SAP AG
This list contains some of the tools that administrators and end users can use to control the background environment. Some administrators may want to restrict the use of these tools for their end user environments. The above table shows the general use of the tools and should not be thought of as the absolute answer in all environments. Overall decision-making for use of these tools is the responsibility of the administrators.
2-161
BC360
Authorization Objects for Background Jobs

Change Activity Group: Authorizations Authorizations Edit Goto Utilities Environment System Help Open Changed Maintained Org. levels... 27 Non-maintained org. levels, 170 open fields, Status: Unchanged batch user id 50000277 BC_A Changed Basis: Administration Standard Batch Processing: Batch Administrator S_BTCH_ADM 5 M 5 5 M M 5 5 M Standard Batch Processing: Batch Administrator R-50000277 Batch administrator ID Y BTCADMIN Standard Batch Processing: Operations on Batch Jobs S_BTCH_JOB Standard Batch Processing: Operations on Batch Jobs R-50000277 Job operations DELE, LIST, PLAN Summary of jobs for a group * Maintained Batch Processing: Batch User Name Maintained Batch Processing: Batch User Name Background user name for autho BACKGROUND JOBACTION JOBGROUP S_BTCH_NAM R-50000277 BTCUNAME
Maint.: BATCH_USER 5 5
Not Authorized Authorized

SAP AG
S_BTCH_ADM Grants authorizations to an administrator, enter Y. The administrator can access jobs in all clients. Without this authorization, users can only work on jobs in the client in which they are logged on. S_BTCH_NAM Determines which authorized users you can choose when scheduling a job. An authorized user provides the authorizations required for performing a background job. S_BTCH_JOB Determines the following functions: DELE Delete jobs of other users LIST Display spool requests created by jobs of other users PROT Display job logs created by other users RELE Release your own jobs automatically during scheduling SHOW Display job definitions of other users
2-162
BC360
Authorization Objects for External Com mands

Change Activity Group: Authorizations Authorizations Edit Goto Utilities Environment System Help Open Changed Maintained Org. levels... 27 Non-maintained org. levels, 170 open fields, Status: Unchanged batch user id 50000277 Standard 5 5 M 5 5 4 5 5 M Changed Cross-application Authorization Objects AAAB Standard Authorization check for transaction start Standard Transaction code AC08, AL01, AL02, AL04, AL05, S_TCODE TCD S_LOG_COM R-5000027700 S_RZL_ADM R-5000027700 ACTVT
Maint.: BATCH_USER 5
Authorization check for transaction start R-5000027700
Basis: Administration BC_A Maintained Authorization to execute logical ... Maintained Authorization to execute logical ... Standard CC control center: System administration Standard CC control center: System administration Activity 01, 03

SAP AG
S_RZL_ADM This authorization is required to grant update and maintenance capabilities to the system administrator for CCMS functions. Activity code 01 grants the administrator all management functions with CCMS. Activity code 03 grants only display capabilities in CCMS. S_LOG_COM Grants authorization to execute external commands. The following fields are available: COMMAND: Logical name of the external command. OPSYSTEM: Name of the operating system on the target host. HOST: Host name of the target system. S_TCODE Grants authorization to execute Transactions SM49 (Display/Execute) and SM69 (Define/Display/Execute) for external commands.
2-163
BC360
Authorization Objects for External Management Interfaces (XMI)

Change Activity G roup: Authorizations Authorizations Edit Goto Utilities Environment System Help Open Changed Maintained O rg. levels... 27 Non-maintained org. levels, 170 open fields, batch user id 50000277 Manual 5 5 5 5 Basis: Administration Manual Manual Manual Manual Internal access authorization for XMI log Internal access authorization for XMI log
Maint.: BATCH_USER 5
Status: Unchanged BC_A S_XMI_LOG R-5000027700 XMILOGACC R-5000027700 EXTCOMPANY EXTPRODUCT INTERFACE R-5000027701
Access method for XMI log General access to XMI interfaces
Auth. for external management interfaces (XMI) S_XMI_PROD
XMI logging: Company name of e * XMI logging: Program name of e * Interface ID (for example, XBP * Manual Authorization for external management interf.

SAP AG
S_XMI_PROD This authorization object is used to define which XMI interface and which external tools may be used by an R/3 user. Defined fields are: EXTCOMPANY: Name of authorized company EXTPRODUCT: Company's tool INTERFACE : ID of XMI interface that the R/3 user may use '' = General XMI functions * = All XMI interfaces S_XMI_LOG This authorization object specifies whether R/3 users may access the XMI interface log and how they may access it. Defined fields are: XMILOGACC: Access method SELECT = Read log entries REORG = Reorganize log
2-164
BC360

Define background jobs Maintain background jobs Execute background jobs Distinguish between the various background processing features Set up authorizations to
Define Execute M onitor background jobs
Access the internal and external Job API function modules
SAP AG
2-165
BC360
Unit Actions
Do the exercises
SAP AG
2-166
BC360
Explanations: ##: Group number <SID>: Your R/3 system name <nr>: Your instance number opt.: optional, can be done if there is enough time No. 1 opt. Exercise Check the Background Processing Environment The following steps give you practice in evaluating your background environment. Always perform these steps if problems occur in your system. 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 2 Are there BTC work processes available on your server for starting background jobs? How many BTC work processes are running? How many background jobs can you run at the same time? Which instance profile parameter defines the BTC work processes? Which profile parameter defines a batch scheduler on an application server? How often is the batch scheduler activated? Can you run background jobs of class A on your server? Can you find out if you have BTC work processes reserved for class A in your process overview (Transaction SM50), or in your instance profile? Do you have the necessary authorizations for creating, changing, and executing background jobs? What can you do if you have no BTC work processes and you cannot restart your server? Create and Schedule a Background Job Exercise: Set up and execute background jobs using different methods. Evaluate the job results. 2.1 opt. 2.2 Execute the report RSUSR000 in the background
Create and schedule a background job for the report RSUSR000. (Execute immediately) Job name is RSUSR000_ ##. Choose the appropriate job class. Enter the appropriate target host.
2-167
BC360
2.3
Check whether your job is running successfully. Find data relating to the start date, steps, spool list, job log, and job details such as client and user name. Is the spool list printed automatically?
2.4 opt. 3
Find the actual execution time and check if the job is running with a time delay Create and Schedule a Job with a Variant Exercise: Execute an ABAP program using an existing variant. Use the ABAP editor to create a new variant.
3.1
Create a job named Authorizations_## to execute the program RSUSR040, which collects information about the authorization object S_TCODE by using the variant SAP&_STANDARD. Create Events, then Schedule Jobs Dependent on These Events Exercise: Create a User defined event, then schedule a job to be executed based on this event. Trigger the event from CCMS and from an external program.
4.1 4.2 4.3
Create the event Test_event_## Create and schedule the report RSUSR000 in the job Event_job_##, which is periodic and depends on the event created in 4.1. Check whether the job is running successfully. Find out what event the job is waiting on.
4.4
Raise the event and check the job again. How often do you see this job in the job overview? Why?
4.5 5
Trigger this event from outside the R/3 system and check your job again. Define Job Chains Exercise: Create a job that is dependent on the job created previously in Exercise 4.
5.1 5.2 5.3 5.4 6
Create the job After_event_job_##, which will execute the ABAP program RSUSR000. This job should run dependent on the job defined in Exercise 4 (Event_job_##). What is this job waiting for? How can you run this job? Check both jobs while they are running and then check the result. Create and schedule jobs with external commands and programs
2-168
BC360
Exercise: Define jobs that execute external programs and external commands running at the operating system level. 6.1 Create an external command ZTRANS_## and display the output of the tp help command. For example, you can use the following command: tp pf=/usr/sap/trans/bin/TPPARAM help. Note: For Windows NT always use \ and not / in the path specifications and specify the operating system in Uppercase: WINDOWS NT 6.2 6.3 6.4 Create a job named External_command_## based on the external command ZTRANS_## Check if your job is running successfully, then check the output of the tp help command. For Unix systems: Create a new job named External_program_## based on the Unix command ls with the parameter -l, for the directory /sapmnt/<SID>/profile. Find out which R/3 profiles you have in your server. For Windows NT: Create a new job named External_program_## based on a command file at the operating system level that lists the contents of directory e: (or another existing directory on your server) 6.5 Check the job log and the contents of the directory /sapmnt/<SID>/profile for Unix. For Windows NT, check the contents of directory e: 7 opt. Review and Execute the ABAP Internal/External API Function Modules Exercise: Use the function module BP_EVENT_RAISE to raise an event. Then check the jobs dependent on this event. 7.1 7.2 Raise an R/3 event Test_event_## using the function module BP_EVENT_RAISE. Check the job Event_job_## defined in exercise 4.
2-169
BC360
Explanations: ##: Group number <SID>: Your R/3 system name <nr>: Your instance number opt.: optional, can be done if there is enough time No. 1 opt. Solution Check the Background Processing Environment The following steps give you practice in evaluating your background environment. Always perform these steps if problems occur in your system. 1.1 1.2 1.3 1.4 1.5 1.6 Use Transactions SM50 and SM51 to find out whether your application server has any BTC work processes. Use Transaction SM50 to check the number of processes. As many as the BTC work processes you have available. For example, if you have three BTC work processes, you can run three background jobs at the same time. In the instance profile <SID>_<INSTANCE NAME><NR>, find the parameter rdisp/wp_no_btc. Use Transaction RZ10 to review the instance profile parameters. The parameter rdisp/wp_no_btc. Use Transaction RZ10 to review the instance profile parameters. Using the transaction RZ10, check the default profile DEFAULT.PFL and find the parameter rdisp/btctime. If rdisp/btctime is not specified in any profile, the system default value of 60 seconds is used. You can run background jobs of class A on any server where BTC work processes are running. These processes are only visible in the operation mode definition. In Transaction RZ04 choose Instances/OP modes. Call Transaction SU01. Enter your user name, then choose Display --> Profile folder. Select a profile, then choose Details. To find the background processing authorizations assigned to the profile selected, search for the word 'batch'. Choose System --> List --> Find. If there are no BTC work processes running, define an operation mode for switching dialog work processes to background work processes. Note: You should configure at least 2 dialog work processes in each instance. Create and Schedule a Background Job Exercise: Set up and execute background jobs using different methods. Evaluate the job results. 2.1 Choose System --> Services --> Reporting.
1.7 1.8 1.9
1.10
2)
2-170
BC360
opt.
Enter the name of the report RSUSR000. Choose Program --> Background --> Execute immediately Choose Goto --> Job overview --> Execute. Find the report RSUSR000 and check its status.
2.2
Choose Tools --> Administration --> CCMS --> Jobs --> Define Enter the name of the job RSUSR000_ ## Enter Class C (since the job does not have a high priority, it is not a Class A or Class B job). If you have only one server with BTC work processes running, you do not need to enter a server name. If you have several application servers, choose one server with a BTC work process on which to execute the program. Choose Steps. Choose ABAP Program, enter the program name, then choose Save. Choose Start date --> Immediate --> Save.
2.3
Choose Tools --> Administration --> CCMS --> Jobs --> Maintain --> Execute. Search for your job name in the job overview. Read the status of this job, then choose Job --> Display --> Steps --> Start date --> Details. The spool list is only printed automatically if you have defined this in your user defaults by entering a printer name and specifying Output immediately. If automatic printing has not been defined, a spool list is created which must then be printed explicitly. You can also access the Job Scheduling Choose Tools --> CCMS --> Control Monitoring --> Job scheduling monitor Monitor:
If your job is aborted, look for reasons in the job log, copy the job to a new one, change the new job by changing steps or dependencies and reschedule the job with a new start date. 2.4 opt. 3 Choose Tools --> CCMS --> Jobs --> Maintain --> Goto --> Job analysis --> Execute. Select your job Create and Schedule a Job with a Variant Exercise: Execute an ABAP program using an existing variant. Use the ABAP editor to create a new variant. 3.1 Choose Tools --> CCMS --> Jobs --> Definition. Enter the name of the job Enter Job class C
2-171
BC360
Choose Steps Under ABAP Program, enter the program name. Choose Variant list, then select the variant SAP&_STANDARD. Choose Save --> Goto --> Variant --> See the content of the variant --> Back --> Back Choose Start date --> immediate, then save. Save your job data. To review the job results, choose Jobs --> Maintenance. You can also create your own variant: Using Transaction SE38, enter the program name, then choose Variants --> Change and enter the name ZS_TCODE_##. Choose Create --> Continue. In the field Authorization object, enter S_TCODE, then choose Continue. Enter a description of the variant, then choose Save --> Back 4 Create Events then Schedule Jobs Dependent on These Events Exercise: Create a User defined event, then schedule a job to be executed based on this event. Trigger the event from CCMS and from an external program. 4.1 Choose Tools --> CCMS --> Jobs --> Define events. Under User event names, choose Maintain --> Execute --> Event identifier --> Create. Enter the name and a description of the event, then choose Save. Choose Tools -->CCMS --> Jobs --> Define Enter the name of the job. Enter Job class B. Choose Steps. Chooose ABAP Program, enter the program name, then Save --> Back Choose Start date --> After event, enter the newly-defined event name. Choose Periodic job --> Save. Save your job data. 4.3 See Answers 2.3 and 2.4 in order to check your job. To find jobs based on events, go to the main selection menu and enter * in the field Or start after event. The job is waiting for the event to be raised. 4.4 Go to Tools --> CCMS --> Jobs --> raise event. Enter the event name, then choose Trigger. To check your job, see Answers 2.3 and 2.4. To display jobs based on events, go to the main selection menu and enter * in the field
4.2
2-172
BC360
named Or start after event. The job is displayed twice because it is periodic and it has the status Finished and Scheduled. 4.5 Log on to the operating system as <sid>adm. Enter the following command: sapevt TEST_EVENT_## name=<SID> nr=<nr> To check your job, see Answers 2.3 and 2.4. To display jobs based on events, go to the main selection menu and enter * in the field named Or start after event. 5 Define Job Chains Exercise: Create a job that is dependent on the job created previously in Exercise 4. 5.1 Choose Tools --> CCMS --> Jobs --> Definition Enter the name of the job Enter class B. Choose Steps. Choose ABAP Save --> Back Program, then enter the program name.
Choose Start date --> After job. Enter the job name Event_job_##. status-depend --> Save. Save your job data.
Choose Start
Note: When displaying the Job overview, you must select Jobs with previous job in the main selection screen. 5.2 5.3 The previous job Event_job_## must run first. Raise the event Test_event_## (see 4.4) to schedule the job Event_job_## The job named After_event_job_## will run after the job named Event_ job_## 5.4 To check your jobs, see answers to 2.3 and 2.4. Note: in order to see jobs based on events or defined as After job, enter * in the field named Or start after event and select Jobs with previous job in the main selection screen. 6 Create and schedule jobs with external commands and programs Exercise: Define jobs that execute external programs and external commands running at the operating system level. 6.1 Choose Tools --> CCMS --> Configuration --> External commands --> Change -->
2-173
BC360
Create. For Command name, enter ZTRANS_##. For the Operating system command, enter /usr/sap/<SID>/SYS/exe/run/tp. For Parameters for operating system command, enter the tp help command: pf=/usr/sap/trans/bin/TPPARAM help Save these parameters. (Save --> Save) Note: For Windows NT, enter the name of the operating system in upper case letters. 6.2 Choose Tools --> CCMS --> Jobs --> Definition. Enter the name of the job. Enter the class C. Choose Steps. Select external command. Enter the command name ZTRANS_##, operating system and the name of the target host (your host). Save --> back. Choose Start date --> Immediate --> Save. Save your job data. 6.3 6.4 See Answers in 2.3 and 2.4. To find the output of the tp help command, check the job log. For Unix systems: Choose Tools --> CCMS --> Jobs --> Definition. Enter the name of the job. Enter class C. Choose Steps Choose External program, Enter the command name ls. Use the parameter -l /sapmnt/<SID>/profile. Enter the name Choose Save --> Back. of the target host (your host).
Choose Start date --> Immediate --> Save. Save your job data.
2-174
BC360
For Windows NT: Create a command file dire##.cmd at operating system level with the contents dir e:. Choose Tools --> CCMS --> Jobs --> Definition. Enter the name of the job. Enter class C. Choose Steps. Choose External program, Enter the command file name dire##.cmd (with the path where this command file is created). Enter the name Choose Save --> Back. of the target host (your host).
Choose Start date --> Immediate --> Save. Save your job data. 6.5 7 opt. See Answers in 2.3 and 2.4 and compare the contents of the job log with the contents of these directories at operating system level. Review and Execute the ABAP Internal/External API Function Modules Exercise: Use the function module BP_EVENT_RAISE to raise an event. Then check the jobs dependent on this event. 7.1 Choose Tools --> ABAP/4 Workbench --> Function builder. Enter BP_EVENT_RAISE. Choose Single test. For the EVENTID, enter TEST_EVENT_##. Execute the event. 7.2 To check your job, see answers 2.3 and 2.4. Note: To see jobs based on events, enter * in the field Or start after event in the main selection screen.
2-175
BC360
In the following, you will find excerpts from the Operation Manual, Chapter 5 Background Processing.. To perform these exercises, complete the tables in the excerpts as follows: 1 The table under Tasks. For your company, determine the activity group (person responsible), and the frequency with which each of the listed tasks should be performed for the production system <PRDSID>, the quality assurance system <QASSID>, and the development system <DEVSID>. Enter this information and the appropriate transaction for the task in the table (the first row is already completed to provide an example).
The tables under Configuration Documentation. In your system, find out whether the jobs listed below in the tables Reorganization Jobs and Other Jobs are scheduled as background jobs. Enter the required information in the tables.
Tasks
Task Frequency <PRD <QAS <DEV SID> Scheduling jobs Checking job status and job logs AR SID> AR SID> AR Tools CCMS Jobs Definition Tools CCMS Jobs Maintenance SM36 <R3ADM> Menu Path (NT or R/3) Transaction Activity Group
M: Monthly
Y: Yearly
AR: As required
Reorganization Jobs The following table is for routine maintenance jobs in R/3, such as deleting the old spool requests of background jobs. Job Name Program Start Time SAP_REORG_JOBS _<client> SAP_REORG_ABAPDUMPS SAP_REORG_SPOOL RSSNAPDL RSSPO0041 RSBTCDEL <PRD <QAS <DEV SID> D SID> D SID> D Delete old jobs in the respective clients Delete old short dumps Delete old spool requests Task
2-176
BC360
SAP_REORG_BATCHINPUT RSBDCREO _<client> SAP_REORG _JOBSTATISTIC RSBPSTDE
Delete old Batch Input logs
Delete job statistics
H: Hourly
D: Daily
W: Weekly
M: Monthly
AR: As required
Other Jobs In the following table, document all other important background jobs: Program Start Time RSCOLL00 <PRD <QAS <DEV SID> H SID> H SID> H Collect statistics to be displayed in performance monitors SAP_COLLECTOR_FOR_ JOBSTATISTIC SAP_SPOOL_ CONSISTENCE_<client> RDDIMPDP_CLIENT _<client> RDDIMPDP RDDIMPDP RDDIMPDP RSPO0043 RSBPCOLL Collect data to be displayed in job statistics Perform consistency check of the spool database Run program to import data to the respective client Run program to import data to all clients RDDGENLD RDDGENLD Generate report after upgrade Task
Job Name
COLLECTOR_FOR_ PERFORMANCEMONITOR
2-177
BC360
No. 1 1.1 1.2 1.3 2 2.1 2.2 2.3 3 3.1 3.2 3.3 4 4.1 4.2 4.3 5 5.1 5.2 5.3 6
True?
Question: How many Btc work processes should you have in an instance? It is not necessary to have Btc work processes in every instance. You need at least 2 Btc work processes in an R/3 system. You need at least one Btc work process in each instance. The Job scheduler is activated in the SAP default every 60 seconds 60 minutes 3 minutes How can you configure Btc work processes in your environment? By defining the instance profile parameter rdisp/wp_no_btc > 0 By switching some Dia work processes to Btc work processes By defining the default profile parameter rdisp/btcname If the job creates an ABAP List, where do you find the output file? In Job overview, by accessing Spool list In the developer traces In the system log What kind of programs can you execute in the background using the R/3 job-scheduling tools? ABAP programs External commands External programs You want to execute two programs, arranging for one program to run first and the second program to be executed only after the successful completion of the first. How do you do this? Define a job with two steps, the second step being status-dependent. Define a job with two variants, status dependent Define two jobs. The first job executes the first program. The second job, which is a status-dependent After job based on the first, executes
6.1 6.2 6.3
2-178
BC360
the second program. 7 7.1 7.2 7.3 8 8.1 8.2 8.3 9 9.1 9.2 9.3 10 10.1 10.2 10.3 11 11.1 11.2 11.3 12 12.1 12.2 12.3 13 How can you raise an event? Use the CCMS Job menu in order to raise the event. Execute the program sapevt from the operating system level. Use the SAP standard function module BP_EVENT_START. An event-scheduled job has to run immediately. What should you do? Access Job overview, select the job and release it. Access Job overview, select the job and change the Start time/date to immediate. Use the CCMS Jobs menu to raise the event. Which jobs can be captured? Running jobs Released jobs Scheduled jobs How can you find out if a job is running ? Access Job Overview, then look in the column Active to check the status. Look in the Process Overview. Look in the R/3 system log. If a job is cancelled, where can you look for logs? Access Job Overview, then find the Job log. In the Job Scheduling Monitor In the dev_w<work process number> trace file in the work directory. Can I reserve background work processes for individual applications or users? You can only reserve background work processes for super users. You can only reserve background work processes for special R/3 applications. You can only reserve background work processes for Class A jobs. How can I influence the priority of the jobs, regardless of the job class?
2-179
BC360
13.1 13.2 14 14.1 14.2 14.3
In distributed systems, with a well-designed distribution of Btc work processes on the servers. By executing the jobs with super user authorizations. What happens if the background work process needs to be switched and a job is running in that work process ? Jobs are never terminated by the R/3 System to make way for an operation mode switch. The job is canceled. The job is canceled and then run again after the switch.
2-180
BC360
No. 1 1.1 1.2 1.3 2 2.1 2.2 2.3 3 3.1 3.2 3.3 4 4.1 4.2 4.3 5 5.1 5.2 5.3 6
True?
Question: How many Btc work processes should you have in an instance?
X X
It is not necessary to have Btc work processes in every instance. You need at least 2 Btc work processes in an R/3 system. You need at least one Btc work process in each instance. The Job scheduler is activated in the SAP default every
60 seconds 60 minutes 3 minutes How can you configure Btc work processes in your environment?
X X
By defining the instance profile parameter rdisp/wp_no_btc > 0 By switching some Dia work processes to Btc work processes By defining the default profile parameter rdisp/btcname If the job creates an ABAP List, where do you find the output file?
In Job overview, by accessing Spool list In the developer traces In the system log What kind of programs can you execute in the background using the R/3 job-scheduling tools?
X X X
ABAP programs External commands External programs You want to execute two programs, arranging for one program to run first and the second program to be executed only after the successful completion of the first. How do you do this? Define a job with two steps, the second step being status-dependent. Define a job with two variants, status dependent
6.1 6.2 6.3 X
Define two jobs. The first job executes the first program. The second job, which is a status-dependent After job based on the first, executes
2-181
BC360
the second program. 7 7.1 7.2 7.3 8 8.1 8.2 8.3 9 9.1 9.2 9.3 10 10.1 10.2 10.3 11 11.1 11.2 11.3 12 12.1 12.2 12.3 13 X X X X X X X X X X How can you raise an event? Use the CCMS Job menu in order to raise the event. Execute the program sapevt from the operating system level. Use the SAP standard function module BP_EVENT_START. An event-scheduled job has to run immediately. What should you do? Access Job overview, select the job and release it. Access Job overview, select the job and change the Start time/date to immediate. Use the CCMS Jobs menu to raise the event. Which jobs can be captured? Running jobs Released jobs Scheduled jobs How can you find out if a job is running ? Access Job Overview, then look in the column Active to check the status. Look in the Process Overview. Look in the R/3 system log. If a job is cancelled, where can you look for logs? Access Job Overview, then find the Job log. In the Job Scheduling Monitor In the dev_w<work process number> trace file in the work directory. Can I reserve background work processes for individual applications or users? You can only reserve background work processes for super users. You can only reserve background work processes for special R/3 applications. You can only reserve background work processes for Class A jobs. How can I influence the priority of the jobs, regardless of the job class?
2-182
BC360
13.1 13.2 14 14.1 14.2 14.3
In distributed systems, with a well-designed distribution of Btc work processes on the servers. By executing the jobs with super user authorizations. What happens if the background work process needs to be switched and a job is running in that work process ?
Jobs are never terminated by the R/3 System to make way for an operation mode switch. The job is canceled. The job is canceled and then run again after the switch.
2-183
BC360
Additional Documentation
R/3 Knowledge Products
SAP System Managem ent Reference Job scheduling System Periodic Tasks Help on the Basis Background Jobs Technical Im plem entation Setup Background Processing Background Action Plan Results/O utput Manage Background Processing (Production) Background Action Plan Results/O utput Design Workload Balancing Background Action Plan Results/O utput Daily Tasks (Production) Background Results/O utput
SAP AG
2-184
BC360
R/3 Online Docum entation
R/3 Online Documentation Com puter Center M anagement System
SAP AG
Software Logistics
Software Logistics
SAP AG
2-185
BC360
2-186
BC360
Software Logistics
Software Logistics
Contents:
Transport Managem ent System (TM S) Client copy and client transport Customizing Organizer (CO) and Workbench Organizer (W BO)
Objectives:
At the end of this unit you will be able to: Use the TMS to adm inister your R/3 Systems, configure your transport routes, and import your change requests Explain the features and limitations of R/3 client tools Coordinate and distribute changes using the CO and WBO
SAP AG
2-187
BC360
Software Logistics
Course Roadmap
DBA: Backup and Restore
DBA: Daily Check
System M onitoring Start and Stop Background Processing
User Administration Installation Check Archiving
Software Logistics Spooling and Printing

R
SAP AG
2-188
BC360
Software Logistics
Software Logistics in General

The primary logistics question is: How do you get the right objects to the right place at the right time? Distributed software development always requires coordination for example, within the ABAP W orkbench in various R/3 Systems. In such cases, the question is:
How can the source code be adm inistered? How can the changes be m ade? How can the developm ent projects be organized?
SAP AG
Like any other logistics-related subject, Software Logistics deals with the distribution of objects in the R/3 System. In the R/3 System, these objects can include settings made during Customizing, or in-house software developed by a customer for use with R/3. Such in-house software may need to be transported between different R/3 Systems. The ABAP development environment provides tools to help the customer develop software in-house. Using these tools, several developers can work together on a software project involving one, or several different, R/3 System(s). For large-scale development projects which are sometimes running simultaneously at different locations, the administration of source code is an important problem. This problem is not limited to the R/3 environment; it is a typical issue arising during any major development project. The administration of source code requires: Recording changes to the source code Identifying the original and copies of the original In this course, we will initially survey the structure of the R/3 System. Next, we will discuss the solutions SAP provides for the above-mentioned logistics problems.
2-189
BC360
Software Logistics
Data Structure of an R/3 System

Client 000
Appl. data Customizing
Client 999
Appl. data
. . .
User
Customizing
Client-independent Customizing
R/3 Repository
R
SAP AG
The R/3 System consists of various data types. Certain types of data are only accessible from a particular client. Such data types include business application data (documents, material master records, and so on) as well as most Customizing settings. These settings: Define the customer's organizational structures, such as distribution channels, company codes, and so on Adjust the parameters of R/3 transactions to fit customer-specific business operations Client-dependent data types are closely interdependent. Thus, when application data is entered, the system checks whether the data matches the client's Customizing settings. If there are inconsistencies, the application data is rejected. Therefore, application data usually only makes business sense in its specific Customizing environment. In addition to client-dependent data, R/3 can have other settings which, once defined, are valid for all clients. This data includes: Client-independent Customizing, such as printer settings The R/3 Repository, which contains all objects in the R/3 Dictionary (tables, data elements, and domains), as well as all ABAP programs, menus, CUAs, and so on Therefore, in the case of client-independent settings, an ABAP report that was originally developed in a certain client may be immediately usable in another client.
User
2-190
BC360
Software Logistics
Types of Adaptation
Customizing
User
. . . . Custom izing
Custom izing Customizing
Client-independent Custom izing
R/3 Repository Developm ent M odifications Customer enhancem ents

R
SAP AG
In accordance with the various data types in the R/3 System, there are various types of changes and adjustments to data. Since the R/3 System is delivered in standard form, it must be adjusted to the customer's requirements during the implementation phase. This procedure is called Customizing. As shown above, Customizing includes the clientdependent and -independent Customizing data. An R/3 upgrade may require a limited amount of additional Customizing. Unlike Customizing, enhancements or adjustments to the R/3 Repository are not required in order to operate an R/3 System. To adapt the R/3 Repository to a customer's requirements, in-house software can be developed by the customer. In addition, customer enhancements can be added to the R/3 Repository. In this case, customer-defined objects are used to complement the SAP delivery standard. The precise locations where enhancements can be inserted are specified by SAP. Finally, R/3 objects such as reports and table definitions can be modified directly. In this case unlike the previous two methods , the R/3 Repository delivered by SAP is not merely enhanced; it is changed. During the next R/3 upgrade, these modifications may therefore have to be adjusted before being incorporated into the new Repository, which can be a time-consuming process.
User
Appl. data
Appl. data
2-191
BC360
Software Logistics
Consequences: Software Logistics in R/3

User User Appl. data Customizing Appl. data Customizing
Different clients for:

Execution Testing Productive usage
Client-independent Custom izing R/3 Repository
of Custom izing
Separate R/3 System s for customer in-house development, and for changes made to the R/3 Repository
DEV Q AS PRD
SAP AG
Due to the R/3 System features described above, the type and number of clients and R/3 Systems are subject to the following requirements: Customizing is not used in the client where it was developed and tested. For this reason, every implementation of R/3 requires several clients. For larger R/3 installations, different parts of a Customizing project may need to be tested jointly in a separate client. Production operation ultimately requires yet another, final client. At the technical level, the distribution of these clients, along with other (possible) clients, across the R/3 System, depends on whether changes need to be made to the R/3 Repository. If changes are necessary, the development and production environment must be subdivided and distributed across several different R/3 Systems. Otherwise, ABAP programs that were created in the development client, but still need to be tested, would immediately become available in the production client. This would cause serious security and performance problems. Therefore, for any changes made to the R/3 Repository, SAP recommends at least two better yet, three R/3 Systems. The third R/3 System can subsequently be used for mass testing and for quality assurance. In summary: Customizing settings must be transported between clients. Changes to the R/3 Repository must be transported between R/3 Systems.
2-192
BC360
Software Logistics
Transport Management System (TMS): Concepts

Transport domain 1 Transport dom ain 2
Transport group 1 Transport group 1

/usr/sap/trans /usr/sap/trans
Transport group 2
/usr/sap/trans
= Transport dom ain controller
SAP AG
The Transport Management System (TMS), which was developed for R/3 Release 4.0, allows the transports between different R/3 Systems to be administered centrally. The TMS classifies R/3 Systems into transport groups and transport domains: A transport group consists of all R/3 Systems which (as with earlier R/3 releases) can access a common transport directory. A transport domain consists of one or more transport groups. Thus, as of R/3 Release 4.0, system landscapes consisting of several transport directories are supported. To enable transports to be administered centrally, all systems in the transport domain must be capable of being administered by a designated R/3 System, called the transport domain controller. For the administration of transports, the following information is stored centrally: The systems participating in the transports Their transport routes Thus, such configuration data no longer needs to be set manually in every R/3 System. Instead, using RFC, the transport domain controller distributes the data to all participating R/3 Systems. The next section covers system administration and transport route configuration. At the end of this unit, we will discuss how transports are imported using the TMS.
2-193
BC360
Software Logistics
TMS: Administering Your R/3 Systems
System Overview: Dom ain DOMAIN_QAS Number of systems: System DEV QAS PRD Description Development Quality Assurance Production 3 Release 4.5A 4.0A 4.0A Status
SAP AG
To create a transport domain, define the transport domain controller when you call the TMS in the transport group for the first time. As soon as the domain has been created, additional systems can apply for acceptance by the domain. For security reasons, these systems are not accepted until they have been authorized by the transport domain controller. The TMS System Overview displays the various system statuses: Waiting for acceptance by the domain Active System locked for the TMS System not accepted System deleted Technically, TMS can connect systems with different R/3 release statuses. However, SAP does not support any transports between such systems. Because of its central importance, the transport domain controller should run on an R/3 System with a high availability.
2-194
BC360
Software Logistics
TMS: Configuring Your Transport Routes

Drag & drop new system s to be inserted into configuration Define transport routes by inserting arrows; choose type of transport route Distribute and activate configuration
SAP
Integration Consolidation Delivery
DEV
ZDEV ZDEV
QAS
PRD
Delivery routes Consolidation routes Standard transport layer

SAP AG
To configure the transport routes between systems in the domain, use the hierarchical list editor and graphical editor provided by the TMS. Define these settings in the transport domain controller. The transport routes can be either consolidation or delivery routes. For consolidation routes, a transport layer is used, for example to define a route between the Development and the Quality Assurance System. Delivery routes connect systems, for example the Quality Assurance and the Production System. They do not use transport layers. To create transport routes in the graphical editor, use drag & drop. After the transport routes have been configured in the transport domain controller, they can be distributed across all systems in the domain. In the systems belonging to the domain, these settings must be activated. This can also be done centrally by the transport domain controller. To enable previous configurations to be reused, you can create versions in the TMS.
2-195
BC360
Software Logistics
System Change Options

System Change Option
Global setting: Repository and client-indep. Custom izing can be changed

Namespace / Name range
Customer name range Local objects R/3 application components R/3 Basis System N amespace for nonstandard development /A1234567/
Prefix
M odifiable
SAP AG
In R/3 4.0, the concept of name ranges was extended from the (existing) name ranges for in-house software developed by a customer (Y* and Z*), to namespaces that can be reserved by SAP's customers and partners. These namespaces are designed for large-scale customer enhancements as well as SAP partners who have developed add-ons. For smaller-scale software, the existing namespaces will remain sufficient. The syntax for objects from reserved namespaces is: /<namespace>/<object name>, for example /abcdefgh/customer. The namespace prefix can have a maximum of 10 characters. For every R/3 System, the customer can define whether the objects contained in the namespaces and name ranges may be changed. To enable objects to be changed, the R/3 System must not be globally locked to changes.
2-196
BC360
Software Logistics
Client Change Options

SAP
Changes and transports for client-dependent objects
Changes to client-independent objects
SAP
Protection with respect to the client copy and com parison tools
R
SAP AG
As soon as the R/3 Systems have been installed, the required clients must be created. As with the system change options for the entire R/3 System, the customer must set the client change options. The permissibility of changes depends on a client's function. For example, no changes should be permitted on a client currently used in production operation. To prevent changes to a client, the customer can impose restrictions at several levels. First, the customer must decide whether and how to allow client-dependent settings to be changed. In making this decision, the customer must distinguish between clients in which: No changes are allowed, Changes are allowed, but they remain within the client (for example, clients used for training), or Changes are allowed, and which are open to transports. In the latter case, the customer must decide whether changes should be recorded automatically by the Customizing Organizer, or only transported manually. In addition, the customer must decide whether to allow the R/3 Repository and/or client-independent Customizing to be changed. For clients with production data or other data that could be a security risk, additional safety measures can be taken. At the so-called protection level, the customer can define whether to allow a client to be overwritten by a client copy, or whether to make client data accessible externally for example, for a comparison among Customizing settings across client and system boundaries.
2-197
BC360
Software Logistics
Sum mary: Setting up an R/3 Transport Landscape

1. M ake the transport directory available. 2. Configure the transport domain controller and define the domain. 3. Configure the transport program (tp). 4. In the TM S: - Include all remaining systems in the domain. - Define the transport routes. 5. Set the system change options according to the role of the R/3 System. 6. Create clients and set the client change options, such as Production System, Development System, and so on.
R
SAP AG
The steps for setting up a transport landscape are summarized below. To set up an R/3 transport landscape: 1. Make a transport directory available to every R/3 System that will be transporting. The TMS allows a local transport directory for every R/3 System. 2. To configure the TMS, define the transport domain controller. 3. Configure the R/3 transport control program (tp). To set the parameters for tp, use file TPPARAM in transport subdirectory bin. Enter at least the name and host of the R/3 Systems. (If there is more than one transport directory, TPPARAM must be identical in all directories.) 4. In the TMS: Include all remaining systems in the domain. Define the transport routes. 5. Set the system change options according to the role of the R/3 System. 6. Create clients in every R/3 System and set the client change options, such as Production System, Development System, and so on.
2-198
BC360
Software Logistics
Transports in a Single R/3 System

Existing client Source client New client
Client copy
User User User Appl. data Client copy change request Appl. data Appl. data
Custom izing
Custom izing
Custom izing
SAP AG
After the R/3 Systems and their clients have been created, these systems and clients must be customized and filled with data. First, we will take a look at the distribution of these adjustments and data within an R/3 System. The first step in adjusting an R/3 System to a customer's requirements consists in the Customizing process. Customizing is done in a separate client, from which the settings can be distributed across other clients in the R/3 System. During this distribution process, it is important to differentiate between: Target clients with existing data that must be retained, and Empty target clients that have yet to be filled with data. For target clients with existing data, distribute the Customizing settings using Transaction SCC1. This transaction allows single table entries to be transported without deleting the target client completely. For empty target clients that need to be newly configured, the Customizing settings should be distributed using a local client copy. A local client copy can transport all of the Customizing settings, possibly even including all application data. Because of the above-mentioned data dependencies, the target client is normally deleted before data is copied to it. Therefore, a local client copy cannot be used to merge the data of several different clients; rather, its purpose is to newly configure empty target clients.
2-199
BC360
Software Logistics
Local Client Copy
User
User
User
Custom izing
C ustom izing
Custom izing
SAP AG
Next, we will describe the individual tools in greater detail, starting with the local client copy. The local client copy distributes client-dependent objects among the clients belonging to an R/3 System. These objects include Customizing data, application data, and user master data with authorizations. Here, again, application data only makes business sense in its specific Customizing environment. For this reason, R/3 does not permit copying application data without simultaneously copying Customizing. However, separate copies of user master data and Customizing data are allowed. For Customizing data, any existing data in the target client is normally deleted before the Customizing data is copied. After the data to be copied has been selected, it is transported by ABAP reports which search all tables to be copied for entries belonging to the source client. To ensure data consistency during the copy phase, the R/3 System prevents users from logging on to the target client. Since copying involves large-scale data transports in the database, the client copy should only be started as a background job.
User
Appl. data
A ppl. data
2-200
BC360
Software Logistics
Transports Between System s: Setup Phase
Transport directory
Client transport and change requests
RFC
Rem ote client copy

R
SAP AG
The next step is the transports between different R/3 Systems in the transport domains. During these transports, you must differentiate between the: Setup phase, where there is as yet no relevant client-dependent data in the target R/3 System, and the subsequent Maintenance phase, where a complete dataset exists in the target R/3 System For the setup phase, R/3 provides the following tools: The Workbench Organizer and the Transport System Remote client copy and client transport During the setup phase, the R/3 Repository must first be replicated. Customer in-house software such as ABAP programs must be transported to the new R/3 System using change requests, which are executed by the Workbench Organizer and the Transport System. Next, the Customizing settings are transported to the new system. The tools remote client copy and client transport are used to transport the Customizing data. Client transport and change requests use the transport directory to reach their target system. Remote client copy transports data using an RFC connection. Remote client copy and client transport are not designed for transferring large-scale production clients, or for database migration.
2-201
BC360
Software Logistics
Remote Client Copy and Client Transport

Rem ote client copy
Client transport
User User Appl. data Custom izing Client-independent Custom izing R/3 Repository Appl. data Custom izing Client-independent Custom izing R/3 Repository
Transport directory
Change requests (W orkbench Organizer)

R
SAP AG
Normally, both remote client copy and client transport work with the same data as a local client copy that is, with Customizing, applications, and user data. Thus, the same restrictions apply as those mentioned above. In addition, client transport and remote client copy (the latter as of Release 4.5A) are also used to transfer client-independent Customizing. The remote client copy procedure is entirely analogous to that of a local client copy, since in both cases, an ABAP report does the processing. However, whereas a local copy writes the data back to the same tables (the only change having been made in the key field Client), during a remote copy, the data is transferred using RFC that is, using a network connection. Client transport reads the data from the tables, and writes it to the transport directory. Depending on the client, the resulting files can grow to as large as several gigabytes. A prerequisite for the use of both of these tools is that the source and target R/3 Repositories be identical. If there are any differences, data may not be copied correctly. Finally, a client transport is imported using the TMS. A separate R/3 transaction is required for postprocessing.
2-202
BC360
Software Logistics
Transports Between System s: Maintenance Phase
Customizing Organizer
Custom izing Client-independent Custom izing R/3 Repository
Transport directory
Custom izing Client-independent Custom izing R/3 Repository
W orkbench Organizer
SAP AG
As soon as the data has been written to the R/3 Systems, and needs to be retained, remote client copy and client transport can no longer be used in order to transport changes to Customizing. Therefore, further changes are distributed using the Customizing Organizer (CO). To use the CO, you must first activate automatic recording of changes for the client. As with the Workbench Organizer (WBO), the CO records the objects that have been changed. In the case of Customizing, these changes are primarily table settings. During the maintenance phase, changes to the R/3 Repository and to client-independent Customizing continue being transported using the WBO. Thus, the main difference between these two tools is that the CO is used primarily to manage changes to Customizing. However, the CO can also be used to manage Workbench requests. To keep Customizing and Workbench development logically separate, changes to the R/3 Repository should only be managed using the WBO. Both Customizing and the WBO allow the recorded objects to be transported to the local transport directory. From there, the data is imported into the target system, using the Transport System.
2-203
BC360
Software Logistics
Change Request Management

W orkbench Organizer
Coordinates development efforts Complete recording and docum entation of changes Teamwork Version managem ent Object locking Development classes Connected to the Transport System
SAP AG
Custom izing Organizer

Coordinates Customizing work Com plete recording and documentation of changes Team work Table logging
Connected to the client copy and the Transport System s

R
The logical structure of the WBO and the CO is very similar. Both of these tools are designed to record and transport changes, and they support the coordination of Customizing and development projects by means of teamwork. Again, the differences between these two tools are only due to their being used to record and manage different objects. Repository objects such as ABAP programs, table definitions, and so on, have a well-defined structure. Table entries which have been made during Customizing do not have this structure. Therefore, version management, a lock option, and the assignment to development classes can only be done for Repository objects which are managed using the WBO. To obtain a history of the changes made to Customizing settings, you must activate the table log. To activate the table log, use the profile parameter rec/client and the table history in the Customizing menu.
2-204
BC360
Software Logistics
Change Requests and Tasks

Change request (Team Leader) Task A (Team Leader)
Object 1 Object 3
Responsibility
re c o rd
e d in
Task B (Member 1)
Object 1 Object 2
recorded in
Task C (Member 2)
Object 4
re c o r d e d in
Task D (Member 2)
Object 5
.. . .. ..
re c o rd e d in
R
..
SAP AG
The WBO and the CO allow you to work with a team on a development or Customizing project, and allow the changes made to the R/3 System to be recorded. These changes are recorded using change requests which can be assigned to an entire project. These requests contain smaller units consisting of the tasks that have been allocated to a project team member. In these tasks, the changes made by this team member are recorded; that is, a list of changed objects is maintained. In general, an object can be listed in several tasks belonging to the same change request (with the exception of repairs). Likewise, a team member can own several tasks belonging to a change request. The recorded objects are only transported in the context of the entire change request. Thus, the project representing this change request can only be imported in its entirety into another R/3 System. SAP Software Change Registration (SSCR): Before Workbench objects are processed, every developer must be registered in OSS. When SAP objects are modified, an object key must also be requested in OSS for every modified object. Further processing can only be done with this key.
2-205
BC360
Software Logistics
Customizing
R/3 Reference Model
FI
SD
Enterprise IMG CO
Project IM Gs
Customizing transactions
CO
MM
PS
CO MM FI
M aintain calendar
...
...
PP
HR
MM
PS
Project 002 Project 001
FI
PS
SAP AG
...
When an R/3 System is implemented, Customizing is of central importance. The SAP delivery standard must be adapted to the company's requirements. For this purpose, SAP delivers the R/3 Reference Implementation Guide (IMG). This implementation guide contains the Customizing for all available modules. In general, when an R/3 System is installed, only certain modules are chosen by the customer, for example only FI and CO. The Customizing actions required for implementation are summarized in the Enterprise IMG, which must be generated at the start of Customizing. However, even the Enterprise IMG usually contains too many Customizing transactions. Therefore, the Enterprise IMG is subdivided into Project IMGs, which can be used by a project team. Both the Enterprise IMG and the Project IMG are client-independent. The changes made by Customizing transactions which are summarized in a Project IMG can be recorded in a change request, for example in the Customizing Organizer.
2-206
BC360
Software Logistics
Customizing Procedure
Perform custom izing Settings are assigned to a Customizing request Automatic assignment to a task
Customizing finished?
Release task Release change request
Export
Transport directory
R
SAP AG
When a Customizing transaction is executed and the settings are saved, the settings are recorded by the Customizing Organizer. These changes are assigned to a change request. This request may already exist (although it must not yet have been released), or it is created by the user. In this request, the changes are saved in the respective user's task. This assignment of changes occurs automatically using the user name. As soon as the required settings have been made, the task can be released. When a task is released, documentation can be created to describe the type of change and the reasons for it. After all tasks belonging to a request have been released, the change request can be released. Normally, with this release, the objects are exported to the transport directory, in whichever form they exist in the database at that specific time. Both during the export and during the concluding import into the target system (using the TMS), it makes sense to check the transport. The Transport System reports errors using return codes. A return codeof 0 signifies an error-free transport step; 4, a warning; and a return code of 8 or greater, an error always requiring postprocessing.
2-207
BC360
Software Logistics
W orkbench Development Procedure

Create object Assign object to a development class Assign object to a change request Autom atic assignm ent to a task
Lock
Developm ent finished?
Release task Release change request
Export
R
Transport directory
SAP AG
Individual R/3 Repository objects, such as ABAP reports, are developed in a process similar to Customizing. Workbench development is only different from Customizing because of the different kinds of objects involved. A new development project begins when an object is created, for example in the ABAP Editor or in the R/3 Dictionary. This object must first be assigned to a development class. In this way, an object is logically assigned to a larger project, for example Development for HR; in addition, the transport attributes are defined. The data is then recorded, as in the Customizing Organizer, in the form of requests and tasks. However, when dealing with Repository objects, these objects are locked to access by non-request members. In this way, the project work is clearly defined. After all tasks belonging to a request have been released, the change request is released. When the request has been released, the objects are exported, versions are created, and the locks are deleted. The objects are then free for new projects. If the changes to R/3 Repository objects do not involve newly developed software, but rather consist only of changes to existing reports, a development class does not have to be assigned. However, you must distinguish between objects existing as an original, and those existing only as a copy in the respective R/3 System. Examples of copies in customer systems are any objects belonging to the SAP delivery standard.
2-208
BC360
Software Logistics
TMS: Im port Buffer Status
Import
Import
Transport directory
SAP
Import Overview: Dom ain DOMAIN_QAS Number of import queues: 3 Queue Description Requests DEV QAS PRD Devel. System Quality Assurance Production System
R
Status
0 12 48
SAP AG
The last step in the transport of Customizing settings and Workbench objects between different R/3 Systems is the import from the transport directory into the target system. The TMS handles this import. The most important organizational structure for the management of imports into a system is a system-specific buffer in the transport directory. In this buffer, the change requests to be imported are collected in the order in which they have been released. Thus, the buffer implements an import queue. Using the TMS, you can display the import queue of all R/3 Systems of a transport domain from any system belonging to the domain. For every import queue, the number of change requests as well as the queue status are displayed. The status can be one of the following: Open that is, new change requests can be added and imported during the next import. Closed that is, newly added requests are not imported during the next full queue import. The queue contains incorrect or running imports, or it could not be read. The display of the data in the import queue is not automatically refreshed by the TMS.
2-209
BC360
Software Logistics
TMS: Im port Procedure

Import Queue: System QAS Request for QAS: Number 1 2 3 4 5 6 Request DEVK900032 DEVK900143 DEVK900002 DEVK900037 DEVK900085 DEVK900033 6 / 12 Owner SMITH ARENDT RAUPP HENRY STEIN LONG Short text Condition table Reports for FI Sales org. Org. structure IMG notes Matchcodes
You can display:

Order and names of transport requests User and short text Object list Documentation Transport logs
SAP AG
After you have chosen a system, the TMS displays the details of the selected import queue. If the requests have originated from the same domain, these details include: The order and names of the transport requests The request owner, and an accompanying short text The object list, documentation, and transport logs belonging to a request Using the TMS, the requests in any import queue can be transported from any system in the transport domain into the selected target system. It is important to differentiate between the import of all requests in the queue, and the preliminary import of a single request. Because of the interdependence of data in the R/3 System, SAP recommends always working only with a complete import. Therefore, the import of the entire import queue is the default setting in the TMS. Single requests can also be imported using the TMS. However, in this case, the importer must ensure that there are no inconsistencies, for example as a result of missing required objects. Thus, an ABAP report which is copied without the table(s) to which it refers triggers a short dump as long as the table has not yet been written to the target system. In addition, the TMS allows you to monitor the transport procedure using an alert monitor. For further analysis, you can use the various transport logs at the operating system level.
2-210
BC360
Software Logistics
Transports Between Different Transport Groups

Transport Domain Transport Group 1 Transport Group 2
DEV
Transport route
QAS 3. Im port
1. Export
QAS queue
QAS queue
Data cofile
Data cofile
2. Adjustment
R
SAP AG
The TMS incorporates different transport groups into one transport domain. This incorporation allows transports between R/3 Systems belonging to different transport groups in the transport domain. Transports between R/3 Systems belonging to different transport groups require a transfer of transport request data between the different transport directories. Before a transport request transfer can be made, the import queue of the target system must be adjusted. To make this adjustment, the system searches for requests for the selected system in all transport groups. If requests are found, they are displayed for transfer. The TMS also copies the associated data and cofiles from the specific transport directory to the transport directory which is connected to the target system. Transport logs are not transported to a different transport group. To display the transport logs, for example, for an import in an R/3 System in transport group 1, you must use the TMS in an R/3 System in this transport group.
2-211
BC360
Software Logistics
Authorizations
Authorizations for CO and W BO
Superuser: S_CTS_ALL Project leader: S_CTS_PROJEC Developer: End user: S_CTS_DEVELO S_CTS_SHOW
TM S default user
TMSADM : TMSSUP: Profile S_A.TMSADM Authentication when logging on to a new R/3 System
SAP AG
User authorizations for the Workbench Organizer and the Customizing Organizer are issued in the following categories: Superuser has all authorizations related to requests and tasks Project leader can create and manage requests and tasks Developer can only use existing requests End user only has display authorization The basic authorization object is S_TRANSPRT. How does communication between different R/3 Systems in the TMS take place? The technical basis is an RFC connection generated by the TMS. The default user through whom the connection to another system is established is TMSADM. This user only has display authorization. As soon as more extensive authorization is required, the connection is established through user TMSSUP. This user has no password in R/3, and must therefore be reauthenticated for every target system. In this way, the user authorizations are determined.
2-212
BC360
Software Logistics

Use TMS to administer your transport systems and configure your transport routes Coordinate your development and Customizing efforts using the Workbench and Custom izing Organizer Transport changes between different clients and systems Use TMS to im port change requests
SAP AG
2-213
BC360
Software Logistics
Unit Actions
Do the Exercises
Solutions for the Exercises Answers to the Questions

R
SAP AG
2-214
BC360
No. 1 1.1 1.2 1.3 2 2.1 3 3.1
Exercise Configuration in the TMS In the TMS, check the current system landscape configuration. How many delivery systems currently exist? Create an additional system as a virtual system. Install this new system as a delivery system. Optional: Creating a client Create a new client. Optional: Performing a local client copy Change to the new client you created in Exercise 2, and copy only user data from the default client to the new client. Optional: Working with the Customizing Organizer. In the default client , create a Customizing request in the Customizing Organizer. Create a new country ATLANTIS with the abbreviation ATL: In Customizing, choose Global Settings --> Set Countries --> Define countries. Release your Customzing request. Optional: Client copy change request Log on to the client you created for Exercise 2. Use the client copy change request to enter the country you created for Exercise 4. Workbench Development In the customer namespace, create an ABAP report of your choice. Use development class ZTCC. Release the change request belonging to this ABAP report. Administration of transport requests in the TMS Get an overview of the pending transports in the Quality Assurance System (QAS) of your transport landscape. Import all pending requests into the QAS. Check the import. Confirm that the imported requests have reached the import queue of the delivery systems.
4 4.1 4.2
4.3 5 5.1
6 6.1 6.2 7 7.1 7.2 7.3 7.4
2-215
BC360
2-216
BC360
No. 1 1.1
Solution Configuration in the TMS To go to the TMS of the transport domain controller, choose Tools --> Administration --> Transports --> Transport Management System (or call Transaction STMS). To display the existing systems, use Overview --> Systems. To display the transport route configuration, EITHER: choose Environment-->Transport route; OR, from the initial TMS screen, choose Overview --> Transport routes. The current configuration consists of a three-system landscape with a virtual delivery system. In the TMS system overview, choose R/3System --> Create -->Virtual system. Enter a name of your choice, and distribute the new information. In the transport route overview, choose Goto --> Graphical editor. Define the newly created system as a further delivery system by marking the new system in the upper window area, and dragging it to the lower window area. Choose Configuration --> Transport Route --> Create, and draw a connecting line from the Quality Assurance System to the new system. Give the new transport route the attribute Delivery route. Save. Distribute this configuration using Configuration --> Distribute. Activate the configuration centrally from the transport domain controller, or locally on the individual systems, by going to the transport route overview, and choosing either Configuration --> Activate --> In all domains or Configuration --> Activate --> Local. Optional: Creating a client To go to the maintenance screen for clients, choose Tools --> Administration --> Administration --> Client Administration --> Client Maintenance (or call Transaction SCC4). Select the Change mode, and choose New entries. Enter the required information about the new client. Save. Optional: Performing a local client copy Log on to the new client as user SAP* with password pass. For the copy procedure, choose Tools --> Administration --> Administration --> Client Administration --> Client Copy --> local copy (or call Transaction SCCL). You must enter the profile SAP_USER here. For the following two input fields, use the current default client as the source client. Run the copy as a background job. Check the logs using Transaction SCC3: choose Tools --> Administration --> Administration --> Client Administration --> Copy Logs. Optional: Working with the Customizing Organizer. Call the Customzing Organizer (Transaction SE10), and choose DISPLAY. In the subsequent screen, create a new Customizing request. Choose Tools --> Business Engineer --> Customizing. To go to the appropriate Customizing transaction, use the Enterprise IMG. Choose New entries and enter a new country. Save. Next, the system suggests a change request. Check the suggested entry, and if appropriate, accept it. In the Customizing Organizer, release the task, write the appropriate documentation, and save. To do so, mark the request, and choose Release. As soon as the task has
1.2
1.3
2 2.1
3 3.1
4 4.1
4.2
4.3
2-217
BC360
been released, the request can be released as well. 5 5.1 Optional: Client copy change request Choose Tools --> Administration --> Administration --> Client Administration --> Special Functions --> Special Functions. Enter the source client and the name of the Customizing request from Exercise 4. Start the copy. Workbench Development In the ABAP Editor, call Transaction SE38, or choose Tools --> ABAP Workbench --> ABAP Editor. Enter a name starting with Z, and choose CREATE. Maintain the attributes and save. The system asks for a development class. Choose ZTCC. In the subsequent dialog box regarding the change request, choose Create Request. For this new request, enter a brief description. In the Workbench Organizer, you can release the change request you have just created. To get to the Workbench Organizer, choose Tools --> ABAP Workbench --> Overview --> Workbench Organizer. To display the current requests, choose Display. First, release the request, write the appropriate documentation, and save. Mark the task, and choose Release. As soon as the task has been released, the request can be released. Administration of transport requests in the TMS Go to the TMS. Choose Overview --> Imports. To display the corresponding import queue, double-click the Quality Assurance System. In the import queue overview, start the import by choosing Queue --> Start Import. To display the transport logs, choose Request --> Display --> Logs. To display information about the status of the transport program, call the Import Monitor by choosing Goto --> Import Monitor. View the import queues of the delivery systems. The imported requests should be listed in the import queues of both delivery systems the one given, and the one newly created in Exercise 1.
6 6.1
6.2
7 7.1
7.2 7.3
7.4
2-218
BC360
In the following, you will find excerpts from the Operation Manual, Chapter 10 System Landscape, in the section Setting Up TMS and CTS, and Maintaining Clients. To perform these exercises, complete the tables in the excerpts as follows: 1 The table under Tasks. For your company, determine the activity group (person responsible), and the frequency with which each of the listed tasks should be performed for the production system <PRDSID>, the quality assurance system <QASSID>, and the development system <DEVSID>. Enter this information and the appropriate transaction for the task in the table (the first row is already completed to provide an example).
The tables under Configuration Documentation. Examine the way your system landscape is set up, and enter the required data in the appropriate tables.
Tasks
Task Frequency <PRD <QAS <DEV SID> Performing installation follow-up work AR SID> AR SID> AR Tools Administration Transports Installation follow-up work Configuring the Transport Domain Controller and transport domains Applying to be included in the transport domain Tools Administration Transports Transport Management System Confirming inclusion in the transport domain Tools Administration Transports Transport Management System Defining transport routes Tools Administration Transports Transport Management System Setting the system change option Tools Administration Transports Installation follow-up work Goto System change Tools Administration Transports Transport Management System SE06 DDIC Menu Path (NT or R/3) Transaction Activity Group
2-219
BC360
option Checking and changing client settings Tools Administration Administration Client admin. Client maintenance
M: Monthly
Y: Yearly
AR: As required
Transport Domain and R/3 Systems Transport domain Transport Group R/3 System Name
Description
<DEVSID> <QASSID> <PRDSID> Development system Quality assurance system Production system
Transport Routes Source System Target System Type of Transport Route Transport Layer (For transport route type Transport) <DEVSID> <QASSID> Transport Z<DEVSID>
System Change Option System Name <DEVSID> <QASSID> <PRDSID> Global Setting Modifiable Name Ranges or Name Spaces
Clients in the Development System <DEVSID> Customizing and development are performed in the development system.
2-220
BC360
Client
Function / Role
Modifiability Client-Dependent Objects Client-Independent Objects No changes to Repository and client-independent custom. obj.
000
SAP standard / SAP reference
No changes allowed
2-221
BC360
No. 1 1.1 1.2
True?
Question: Which of the following statements concerning an R/3 System is / are correct? An R/3 System includes one or more application servers accessing a single database. An R/3 System consists of several clients. Each client contains its own business-related data, its own Customizing, and its own Repository objects. The basic implementation component of the R/3 System includes a transport system, which is linked closely to the Workbench Organizer and the Customizing Organizer. The R/3 Transport System... ...is used only to move clients from one R/3 System to another. ...generally requires some initialization steps. ...moves development and Customizing changes from one R/3 System to another. Customizing of an R/3 System... ...is performed at the start of the implementation process, but stops once ABAP Workbench development work begins. ...should only be performed using an Implementation Guide. ...is necessary regardless of the modules installed by the customer. The advantages of an R/3 System landscape with three databases include which of the following? Development, testing, and production can take place in separate database environments, and thus do not affect one another. This type of system landscape enables automatic transport into the Production System. A transport request is tested first in the Quality Assurance System and, when error-free, can be imported into the Production System. To create an additional client within the same R/3 System,... ...the Customizing and Repository objects from the source client are copied to the new client using a client copy. ...the source client is exported and then imported into the new client using a client export.
1.3
2 2.1 2.2 2.3 3 3.1 3.2 3.3 4 4.1 4.2 4.3 5 5.1 5.2
2-222
BC360
5.3 5.4 6 6.1 6.2 6.3 7 7.1 7.2 7.3 7.4 7.5 7.6
...the selected Customizing, application, and user data from the source client is copied to the target client using a client copy. ...a remote client copy is performed between clients. In the Development System, SAP recommends that... ...client DEV be set to record Customizing changes automatically. ...the system change option allow for changes to Repository objects. ...different namespaces not be defined. A client transport... ...can copy both client-dependent and client-independent data from the source client to the target client. ...is used to copy clients between two different R/3 Systems. ...requires that the system administrator create a change request. ...generates log files showing the client transport status as well as details of which objects were actually copied. ...generates a large data file at the operating system level if performed using remote copy. ...is recommended only for the initial creation of clients in an R/3 System. Changes made to client-independent objects in an R/3 System... ...are never transported to other R/3 Systems. ...can be transported to a target system so that the changes take effect in all clients of that target system. ...must be released to a target system that is different from the target system for client-dependent objects. Multiple R/3 Systems... ...are recommended so that development work can be done on a separate R/3 System, away from the production environment. ...share a common database for synchronization purposes. ...are maintained using client copy and client transport tools. When a change request is released from the source system,... ...a transport request is created and automatically imported into the
8 8.1 8.2 8.3 9 9.1 9.2 9.3 10 10.1
2-223
BC360
defined target system. 10.2 10.3 11 11.1 11.2 11.3 12 12.1 12.2 12.3 12.4 12.5 12.6 13 13.1 13.2 13.3 13.4 13.5 14 14.1 14.2 14.3 ...the system administrator must create the appropriate transport request using the tp command. ...a transport request is automatically created, with files residing in the subdirectories of the transport directory. In a three-system landscape, ideally... ...there is an import queue for each system. ...the Production System import queue receives transport requests only after they have been imported into the Quality Assurance System. ...the Quality Assurance System import queue is always identical to that of the Production System. You can view transport log files... ...at the operating system level. ...using Transaction SE09. ...from within the target system after import. ...from within the source system. ...using Transaction SE10. ...using the TMS. The Transport Management System... ...can only be used from the operating system level. ...allows administration and configuration of the transport system from a central R/3 System. ...requires a detailed knowledge of R/3 tables for configuring the Transport System. ...provides a graphical editor for defining transport routes. ...can manage different transport directories. In an R/3 System, Customizing change requests... ...may contain Repository objects and table entries. ...can be included in a transportable change request. ...when released, create versions of all objects included in the change request.
2-224
BC360
14.4 14.5 15 15.1 15.2 15.3 16 16.1 16.2
... activate the necessary locks on objects in the change request. ...contain only client-dependent changes. A transportable change request... ...must be assigned manually to a target system. ...is required if a developer modifies or creates a new Repository object. ...is required if a developer modifies an SAP-owned object. The Workbench Organizer and the Customizing Organizer promote... ...teamwork by allowing customer-owned objects to be shared by all developers assigned to the same change request. ...the maintenance of a system landscape through the creation of change requests and the release of these requests to the Transport System. ...version management by locking all objects and table entries in the change requests. ...the documentation of changes by automatically providing information about the reasons for and purpose of the change. ...project management through the use of authorizations to control the creation and release of change requests. In SAP terminology, a repair is considered... ...a change to an SAP-owned object. ...a change to any Repository object owned by another R/3 System. ...a change to any Repository object made by SAP during an upgrade. In SAP terminology, a modification is defined as... ...a change to an SAP-owned object. ...a change to any Repository object owned by another R/3 System. ...a change to any Repository object made by SAP during an upgrade. Using OSS, you must register... ...all users of the R/3 System. ...all SAP-owned objects that will be modified by a developer. ...all Repository objects.
16.3 16.4 16.5 17 17.1 17.2 17.3 18 18.1 18.2 18.3 19 19.1 19.2 19.3
2-225
BC360
19.4 19.5 19.6 20 20.1 20.2 20.3 20.4 20.5
...all persons who wish to customize the R/3 environment. ...all developers who will create new Repository objects. ...all developers who will modify SAP-owned Repository objects. The TMS can be used to... ... import change requests into the target system, which can be done from any system of the transport domain. ...upgrade an R/3 System. ...monitor an import of a change request. ...define virtual systems. ...only for the management of up to three systems in transport domains.
2-226
BC360
No. 1 1.1 1.2
True?
Question: Which of the following statements concerning an R/3 System is / are correct?
An R/3 System includes one or more application servers accessing a single database. An R/3 System consists of several clients. Each client contains its own business-related data, its own Customizing, and its own Repository objects.
1.3
The basic implementation component of the R/3 System includes a transport system, which is linked closely to the Workbench Organizer and the Customizing Organizer. The R/3 Transport System... ...is used only to move clients from one R/3 System to another.
2 2.1 2.2 2.3 3 3.1 3.2 3.3 4 4.1 4.2 4.3 5 5.1 5.2 X X X X X X
...generally requires some initialization steps. ...moves development and Customizing changes from one R/3 System to another. Customizing of an R/3 System... ...is performed at the start of the implementation process, but stops once ABAP Workbench development work begins. ...should only be performed using an Implementation Guide. ...is necessary regardless of the modules installed by the customer. The advantages of an R/3 System landscape with three databases include which of the following? Development, testing, and production can take place in separate database environments, and thus do not affect one another. This type of system landscape enables automatic transport into the Production System. A transport request is tested first in the Quality Assurance System and, when error-free, can be imported into the Production System. To create an additional client within the same R/3 System,... ...the Customizing and Repository objects from the source client are copied to the new client using a client copy. ...the source client is exported and then imported into the new client using a client export.
2-227
BC360
5.3 5.4 6 6.1 6.2 6.3 7 7.1 7.2 7.3 7.4 7.5 7.6
...the selected Customizing, application, and user data from the source client is copied to the target client using a client copy. ...a remote client copy is performed between clients. In the Development System, SAP recommends that...
X X
...client DEV be set to record Customizing changes automatically. ...the system change option allow for changes to Repository objects. ...different namespaces not be defined. A client transport...
X X
...can copy both client-dependent and client-independent data from the source client to the target client. ...is used to copy clients between two different R/3 Systems. ...requires that the system administrator create a change request.
...generates log files showing the client transport status as well as details of which objects were actually copied. ...generates a large data file at the operating system level if performed using remote copy.
...is recommended only for the initial creation of clients in an R/3 System. Changes made to client-independent objects in an R/3 System... ...are never transported to other R/3 Systems.
8 8.1 8.2 8.3 9 9.1 9.2 9.3 10 10.1 X X
...can be transported to a target system so that the changes take effect in all clients of that target system. ...must be released to a target system that is different from the target system for client-dependent objects. Multiple R/3 Systems... ...are recommended so that development work can be done on a separate R/3 System, away from the production environment. ...share a common database for synchronization purposes. ...are maintained using client copy and client transport tools. When a change request is released from the source system,... ...a transport request is created and automatically imported into the
2-228
BC360
defined target system. 10.2 10.3 11 11.1 11.2 11.3 12 12.1 12.2 12.3 12.4 12.5 12.6 13 13.1 13.2 13.3 13.4 13.5 14 14.1 14.2 14.3 X X X X X X X X X X X X X ...the system administrator must create the appropriate transport request using the tp command. ...a transport request is automatically created, with files residing in the subdirectories of the transport directory. In a three-system landscape, ideally... ...there is an import queue for each system. ...the Production System import queue receives transport requests only after they have been imported into the Quality Assurance System. ...the Quality Assurance System import queue is always identical to that of the Production System. You can view transport log files... ...at the operating system level. ...using Transaction SE09. ...from within the target system after import. ...from within the source system. ...using Transaction SE10. ...using the TMS. The Transport Management System... ...can only be used from the operating system level. ...allows administration and configuration of the transport system from a central R/3 System. ...requires a detailed knowledge of R/3 tables for configuring the Transport System. ...provides a graphical editor for defining transport routes. ...can manage different transport directories. In an R/3 System, Customizing change requests... ...may contain Repository objects and table entries. ...can be included in a transportable change request. ...when released, create versions of all objects included in the change request.
2-229
BC360
14.4 14.5 15 15.1 15.2 15.3 16 16.1 16.2 X X X X X
... activate the necessary locks on objects in the change request. ...contain only client-dependent changes. A transportable change request... ...must be assigned manually to a target system. ...is required if a developer modifies or creates a new Repository object. ...is required if a developer modifies an SAP-owned object. The Workbench Organizer and the Customizing Organizer promote... ...teamwork by allowing customer-owned objects to be shared by all developers assigned to the same change request. ...the maintenance of a system landscape through the creation of change requests and the release of these requests to the Transport System. ...version management by locking all objects and table entries in the change requests. ...the documentation of changes by automatically providing information about the reasons for and purpose of the change. X ...project management through the use of authorizations to control the creation and release of change requests. In SAP terminology, a repair is considered... X X ...a change to an SAP-owned object. ...a change to any Repository object owned by another R/3 System. ...a change to any Repository object made by SAP during an upgrade. In SAP terminology, a modification is defined as... X ...a change to an SAP-owned object. ...a change to any Repository object owned by another R/3 System. ...a change to any Repository object made by SAP during an upgrade. Using OSS, you must register... ...all users of the R/3 System. X ...all SAP-owned objects that will be modified by a developer. ...all Repository objects.
16.3 16.4 16.5 17 17.1 17.2 17.3 18 18.1 18.2 18.3 19 19.1 19.2 19.3
2-230
BC360
19.4 19.5 19.6 20 20.1 20.2 20.3 20.4 20.5 X X X X X
...all persons who wish to customize the R/3 environment. ...all developers who will create new Repository objects. ...all developers who will modify SAP-owned Repository objects. The TMS can be used to... ... import change requests into the target system, which can be done from any system of the transport domain. ...upgrade an R/3 System. ...monitor an import of a change request. ...define virtual systems. ...only for the management of up to three systems in transport domains.
2-231
BC360
Software Logistics
Basis Knowledge Product: Software Logistics Online Documentation BC-Basis: Change and Transport System SAP TechNet: Software Logistics
SAP AG
Users and Authorizations
Users and Authorizations in the R/3 System
SAP AG
2-232
BC360
2-233
BC360
Users and Authorizations in the R/3 System

Contents:
Authorization concept Profile Generator User adm inistration
Objectives:
After this unit, you will be able to: Describe the R/3 authorization concept Maintain authorizations Create R/3 users and assign authorizations
SAP AG
2-234
BC360
Course Roadmap
SAP AG
2-235
BC360
Users in the R/3 Environment

Present. Server Operating System OS User R/3 User
Application Server
Dispatcher
Operating System
...
OS User Adm in. User
Database Server
Database Server
Operating System
OS User DB User
SAP AG
There are several different users residing outside the R/3 System, such as the operating system (OS) user, the database (DB) users, and administrator users. Administrator users (for example <sid>adm) and DB users (for example sapr3) must log on at the operating system level. This unit focuses on the R/3 user within the R/3 System. The R/3 user is only known within the R/3 System, and it cannot be used to log on to the operating system or the database. Therefore, before accessing the R/3 System as an end user, you must first log on to your own operating system. To access R/3 data and functions, users must have the appropriate authorizations. For example, an R/3 user responsible for maintaining user master records has the authorizations required to perform tasks in that area, but is not authorized to post a sales document in Sales and Distribution.
2-236
BC360
Authorization Concept
User master record Profile Authorizations for task A Action User master record Profile Authorizations for task B Action
Transaction permitted? Authorizations assigned? Objects needing protection Vendor Com pany code
SAP AG
M aterial Plant
Authorizations ensure limited access to transactions and objects in the R/3 System that need protection, for example, the company code or vendor. Authorizations are assigned to the user master record in profiles. For each user activity or transaction, an authorization check is performed to see if the required authorizations have been assigned to that user. The R/3 authorization concept enables authorizations to be assigned at the transaction level. If the user is not authorized to perform a certain task, a message is sent denying access to that transaction. If the user has the required authorizations, further checks are performed during the transaction to see if the user has access to protected objects such as company code.
2-237
BC360
Authorization Objects
Authorization Authorization object Object class
Financial accounting
Customer company code: Authorization A

0001-0009 Display, change
Object: Customer company code

Com pany code
Activity
Customer company code: Authorization B *

Display
SAP AG
Authorizations always belong to the authorization object for which they were created. Authorization objects are grouped together in object classes, which are organized by business area. The authorization object is used as a model for maintaining authorizations and for authorization checks in the program. To create or change an authorization, you must enter certain values in the fields of the authorization object. In this example, the values Display and Change are entered in the authorization object field Activity for Authorization A. Authorization B contains only the value Display. Within transactions and reports, authorization objects are checked. The combinations of fields to be checked are specified in the authorization object. Note: All authorizations are positive, in that they grant permissions to the user.
2-238
BC360
User Authorization Tree

User master record
Profile 1 (Activity group 1)
Profile 2 (Activity group 2)
Profile 3 (m anual)
Authorization a for object F1
Authorization b for object F1
Authorization c for object F2
Value xyz
Value abc
SAP AG
The user authorization tree shown here indicates how authorizations are assigned to a user master record. A user master record contains one or more profiles, which may result from an activity group assignment. Composite profiles contain a collection of single or composite profiles. A user is assigned all authorizations contained in each profile entered in the user master record. Profiles can be created and entered in the user master record using either of the following methods: Using the Profile Generator Manual creation (as in earlier R/3 Releases)
2-239
BC360
Authorization Check
Dynpro
AUTHORITY CHECK
User authorizations in the user buffer
OK?
No
Yes
M essage Processing
SAP AG
All authorizations that have been assigned through the profiles to the user master record are entered at logon into the user buffer. Before a transaction is executed and within a transaction or report, the field combination of the authorization object is compared with the authorizations in the user buffer. If an authorization for that particular authorization object contains the required combination of field values, access is allowed and the processing continues. If none of the authorizations contain the required combination of field values, a message is sent denying the user access to that object.
2-240
BC360
Profile Generator: Overview (1)
Transaction 1
. . .
Activity group 1
Transaction m
. . .
Activity group i
Transaction n Transaction s
. . .
Activity group j
. . .
Transaction t
SAP AG
The Profile Generator simplifies the assignment of user authorizations by selecting from the company menu transactions that belong together from the company point of view, then grouping these transactions together in activity groups. The activity groups generated in this way are then assigned to one or more users. Users can also be assigned to one or more activity groups.
2-241
BC360
Activity group 1
Transaction 1
. . .
Authorization 1
. . .
Transaction m
Authorization i Authorization profile for the activity group
SAP AG
Once certain transactions have been assigned to an activity group, the Profile Generator automatically identifies the authorization objects that need checking in those particular transactions. Values needed for the check are also supplied by the system, if they are customer-independent. When using the Profile Generator, the administrator must perform the following steps: Maintain organizational units such as company codes in one central area in the activity group for all authorizations that use organizational units. Check authorizations proposed by the system. Maintain fields that are not organizational units and cannot be supplied by the system. Generate authorization profiles for activity groups. The authorizations needed for these profiles are created and generated by the Profile Generator. Assign users to the activity groups. Then the user master records are checked, and the activity group profiles are entered in the user master records.
2-242
BC360
Activity group 1
Responsibility 1 Transaction 1 Authorization 1
Responsibility N Authorization 1
. . .
. . .
. . .
Transaction m
Authorization i Authorization profile for this responsibility
Authorization i Authorization profile for this responsibility
SAP AG
The Profile Generator enables you to generate activity groups with responsibilities. Transactions assigned to this type of activity group are valid for all the responsibilities included in that group. Using responsibilities, the same functional descriptions can be created for different organizational levels. The authorization profiles and users are assigned to particular responsibilities and not to the activity group. From R/3 Release 4.0A, if a number of activity groups do not differ in their functional descriptions (and therefore in the transactions assigned to them), but only through their different values for organizational levels and authorizations, you can create one activity group with several responsibilities. When using responsibilities: You only have to select the transactions once for each activity group. If the functional description for all the responsibilities of one particular activity group is changed, for example, if a transaction is added to the description, this change must be executed only once. You must maintain organizational levels and authorizations for each responsibility. You cannot make any functional changes to a particular responsibility if the activity group contains more than one responsibility.
2-243
BC360
Profile Generator: Worksteps

Specify activities
Optional: Create responsibilities
Create authorization profile
Assign users
User master data update
SAP AG
To access the Profile Generator, choose Tools Administration User Maintenance Activity groups, or run Transaction PFCG. Specify activities for a particular activity group: In the company menu, select all transactions that belong together from the company point of view. The traffic lights show whether all transactions (green), some transactions (yellow) or no transactions (red) have been selected from the company menu. When using an activity group with responsibilities, you must define the responsibilities to be included in the group. In this case, the following steps must be performed for each responsibility. Create an authorization profile: Maintain the organizational levels, and all authorizations with no values received from the system. Then check the authorizations that have been given values by the system. Use the Profile Generator to generate the authorizations and the profile of the activity group. To enter the profile of an activity group or responsibility in the user master record of one or more users, use the following functions in the Profile Generator. Assign users: This function assigns users to the activity group or responsibility. The authorization profile is not yet entered in the user master record. User master record update: The authorization profile of the activity group or responsibility is entered in the user master records.
2-244
BC360
Profile Generator: Create Authorization Profile

Change activity group: Authorizations
Authorizations Edit Goto Utilities Environment System Help
Open M aint.:
Changed
M aintained
Org. levels... Status: changed AAAB S_TCODE S_TCODE T_5000362600
0 Non-maintained org. levels,
Open fields,
Standard Cross-application authorization objects
Standard Prfung auf den Transaktionscode bei Transaktionsstart Authorization check for transaction start Transaction code check for transaction start Transaction code FD02
+ + + -
Standard Financial accounting Standard Standard Standard Standard Standard Activity Company code Customer: Change authorization for certain fields Customer : Application authorization Customer : Account authorization Customer : Authorization for com pany codes Customer : Authorization for com pany codes 02 0001-0009
FI F_KNA1_AEN F_KNA1_APP F_KNA1_BED F_KNA1_BUK T_5000362600
SAP AG
Once transactions have been assigned to an activity group, the Profile Generator displays all authorization objects checked for these transactions. The display is divided into three levels: The first level contains object classes such as financial accounting (FI). The second level contains authorization objects such as Customer: Authorization for company codes F_KNA1_BUK. The third level contains authorizations such as Customer: Authorization for company codes T_500. For each authorization, fields and values are displayed, for example, Activity 02. Check the authorization values entered by the Profile Generator. Then maintain organizational units such as company code for each activity group in a central area (choose Org. levels). To maintain authorizations that have no entries generated by the Profile Generator, click the pencil icon next to those fields. To find documentation, double click an authorization object's text in the second level. Traffic lights indicate the status of your authorizations: Green: All authorizations have been maintained Yellow: Some authorizations must still be maintained Red: Organizational levels must be maintained To display technical names and icons, use the menu item Utilities Technical names on To view the key for icons and colors used in this screen, choose the icon to the right of Org. levels...
2-245
BC360
User Master Record

User Data
Profiles Task profiles Usertype Init. Password
Default
Date form at Printer... Start m enu
Address
Form of address... Name... Telephone...
Parameters
BUK TAB
0001 T005
SAP AG
To set default values for a printer, spool requests, a user menu, date format, or default system language, choose Defaults. To define a business address for your documentation, enter data in the option Address. To set default values in R/3 fields for a user, enter parameter values in the option Parameters. To change a user password, use the option Change Password. Users can maintain their own settings by choosing System User profile Own data.
2-246
BC360
Settings for System Profile Parameters

Set the minimum length of logon password Require change of password
Lock users after incorrect logons
Prevent automatic unlocking at midnight
End logon procedure after incorrect logon
Deactivate sap*/pass
SAP AG
To adjust the R/3 System to meet the requirements shown here, use system profile parameters beginning with login/. After several failed attempts at logon, a user is denied access to the system. The limit on the number of failed attempts is set in the system profile parameter: login/fails_to_user_lock At midnight, all users locked due to incorrect logon are unlocked. To prevent automatic unlocking at midnight, maintain the following system profile parameter: login/failed_user_auto_unlock (See OSS Note 66533) To lock or unlock users, or assign new passwords, use Transaction SU01. To access the information system and find a list of locked users or users showing incorrect logons, use Transaction SUIM. When changing your password, observe the following points: Your password must be different from the last five you have chosen Do not begin with any sequence of three characters that is contained in your user name Do not use 'pass' or 'sap' as your password Do not begin with three identical characters Do not begin with a question mark or exclamation mark
2-247
BC360
Security
Do not use "pass" or "sap*" as your password
Initial Logon Procedure in SAP Clients
Client User Initial Password
000 SAP*
001 DDIC
066 EarlyW atch
New Client SAP*
06071992
19920706
support
pass
!
SAP AG
Because these users are known users, you must protect them against unauthorized access !
Clients 000, 001 and 066 are part of the R/3 delivery system. In client 000 and 001 there are two special users: SAP* for initial access to the R/3 System DDIC for the transport and correction system To protect SAP* and DDIC from unauthorized access, you must change the initial passwords for these users in all clients of your R/3 System. SAP recommends adding the user group SUPER to the user master records. This user group can only be accessed by the superuser. Client 066 is the EarlyWatch client. Customers must change the initial user password in their own system. In every client, there is a hard-coded user SAP* with the password pass, which has all authorizations. This user can be used if no user master record exists for SAP* in the client. For reasons of security, a user master record must exist for SAP* in every client. To deactivate the hard coded user SAP*, use the system profile parameter: login/no_automatic_user_sapstar. (See OSS Note 68048) Note: When creating a new client, you must temporarily activate the hard-coded user SAP*.
2-248
BC360
Information System
I N F O R M A T I O N User Master Records Authorization Profiles Authorization Objects Authorizations Change History Activity Group W here-Used List
SAP AG
The information system enables you to select user master records and profiles based on the authorization objects they contain. The information system also provides you with a change history, which reports all changes to a user password, user type, user group, and changes to the user's authorizations. To access the information system, use Transaction SUIM.
2-249
BC360
Authorization Traces
System Host P30 hs1021
System Trace
Options for Trace Analysis
Switches
Restrictions
User Process Transaction Program
Trace for authorization checks
Start Date Start Time
SAP AG
The R/3 System enables you to find out which authorization objects are checked when you run a particular program. To record authorization checks, use the system trace. To start the system trace, choose Tools Administration Monitor Traces System trace (See OSS Note 66056) To analyze an authorization failure, call Transaction SU53 and determine which authorizations are required for your task. To display all the authorizations contained in your user buffer, call Transaction SU56. If all your authorizations are not displayed by this transaction, check whether: Activity groups have been maintained since you last logged on to the R/3 System. To display your new authorizations, log off from the system and then log on again. You have received new authorizations through a transport. To display these authorizations, reset the user buffer by choosing SU01 Environment Mass changes Reset all user buffs. The user buffer is too small. Maintain the following R/3 profile parameter: auth/auth_number_in_userbuffer.
2-250
BC360
Summary

Maintain activity groups using the Profile Generator Assign R/3 users to these activity groups Create and maintain user m aster records
SAP AG
2-251
BC360
Unit Actions
Do the Exercises
Solutions for the Exercises Answer the Questions
SAP AG
2-252
BC360
Note: Changes created with the Profile Generator are Customizing changes and result in repeated system prompts, reminding you to to include such changes in a Customizing request.
No. 1 1.0 1.1 1.2 1.3 1.4 1.5 2 2.0
Exercise Create users Create the user ADMIN1 with the specifications as defined in 1.1 through 1.5. Maintain the name of the user Enter an initial password for the user Assign this user to the user group SUPER Define a default logon language for the user Enter the user parameter XUS with the value ADMIN1 Create an activity group without responsibilities. Create the activity group MONITORING1 without reponsibilities using the specifications as defined in 2.1 through 2.4. For Name, enter a text, for example, Limited Monitoring. Specify activities for this goup:: Select Transactions SM50, SM51 and SM04 from the menu tree. Save these entries. Create an authorization profile: Check the automatically generated authorizations. Choose Utilities --> Settings all the icons and the technical names. Save these new settings. Display the legend. Which transactions (see 2.1) require the authorization object S_ADMI_FCD? Which transactions require the authorization object S_ADMI_FCD with the value PADM? Generate the authorization profile and the authorizations.
2.1
2.2
2.3 2.4
Assign users: Assign the user ADMIN1 to the activity group created above. Update user mater data: Now update the ADMIN1 user master data. Check whether the activity group and the authorization profile were assigned to the correct user. The following exercises are optional.
Check the user ADMIN1.
2-253
BC360
3.1 3.2 3.3 3.4 4 4.1 5 5.1 5.2 6 6.1 6.2
Log on to the R/3 System as user ADMIN1, then check if the user can execute the transactions you assigned. Is user ADMIN1 authorized to maintain its own address? Is user ADMIN1 authorized to execute Transaction SU53? Log off from the R/3 System (ADMIN1) and continue working as a course participant. Copy a user Create the new user FI1 by copying user ADMIN1, without copying the authorization profile or the activity group assignment Lock users Lock the user ADMIN1. Check the information system and find out which users are locked. Create an activity group with responsibilities. Create the activity group CUSTOMER0001 with responsibilities Create activities: Select Transactions FD01, FD02 and FD03 from the menu tree. Save these entries. Create responsibilities: Create the responsibility Company code 0001. Create authorization profile: Maintain the organizational unit for Company code 0001. Do you need to maintain the open authorizations? Read the help text for authorization objects. Generate the authorization profile and the authorizations.
6.3 6.4
6.5 6.6
Assign users: Assign user FI1 to the responsibility Company code 0001. Update the user master data: Now update your user master data. Check that the responsibility and the authorization profile have been assigned to the correct user.
7 7.0 7.1
Check user FI1. Log on to the R/3 System as user FI1. Create new customer using Transaction FD01.
2-254
BC360
7.2
In the field Company Code under Customer, and in the section Reference, enter the value 0001. In the section Reference, select customer BCTCC-Customer0001, then choose Enter. Maintain the name and location, then save your entries. Use F4 Help to display all customers. Is the customer you created in this list? Create other responsibilities. Create the new user FI2 by copying user ADMIN1, without copying the authorization profile or the activity group assignment Repeat exercises 6.3 through 6.6 for Company code NZ01 and user FI2. Check user FI2. Log on to the R/3 System as user FI2. Create new customer using Transaction FD01. In the field Company Code under Customer, and in the section Reference, enter the value NZ01. In the section Reference, select customer BCTCC-CustomerNZ01, then choose Enter. Maintain the name and location, then save your entries. Use F4 Help to display all customers. Is the customer you created in this list?
8 8.1 8.2 9 9.1 9.2 9.3
2-255
BC360
Note: Changes created with the Profile Generator are Customizing changes and result in repeated system prompts, reminding you to to include such changes in a Customizing request.
No. 1 1.0 1.1 1.2 1.3 1.4 1.5 2 2.0 2.1
Solution
Choose Tools --> Administration --> User maintenance --> Users or call Transaction SU01. Enter user name ADMIN1 and choose Create. Maintain the name under Address Under Logon data, enter exactly the same password twice Under Logon data, maintain the field User group Maintain data in the field Logon language under Defaults. Enter the parameter XUS with the value ADMIN1 under Parameters Save your data.
Choose Tools --> Administration --> User maintenance --> Activity groups, or call Transaction PFCG Call Transaction PFCG and choose the option Menu. To switch on the technical names, choose Edit --> Technical name --> Technical name on Alternatively, you can choose Edit --> Find and enter the transaction code SM50 etc. to find the path to the transactions. Select the transactions specified. Save your data.
2.2
Call Transaction PFCG with the option Authorizations. Choose Utilities --> Key, or activate the icon next to Org. levels... Activate the mountain icon for the authorization object S_ADMI_FCD. Transactions SM50, SM51, SM04 are displayed. To read the help text for this object, double click the text of the authorization object (not the authorization). Transactions SM50, SM51, SM04 and SM37 Choose Authorization --> Generate, or activate the icon Generate. A dialog box appears the first time you do this. The box shows which number range has been assigned to the name of this activity group. Any changes to this assignment must be made now.
2.3
From the Profile Generator, choose Agents --> Assignment --> Create --> Create assignment (F5). Then select the user ADMIN1.
2-256
BC360
2.4
Use the Profile Generator: Choose Agents, then Goto --> User master data update. Execute the update. All users needing updates are displayed. To confirm the update, choose User master record. To check if the correct activity group has been entered in user master record for user ADMIN1, and if the correct authorization profile is entered under Profile, execute Transaction SU01.
3 3.1 3.2 3.3 3.4 4 4.1 Use Transaction SU01. In Transaction SU01, enter ADMIN1, choose the Copy icon, then enter the name FI1. Deselect Auth. and Task profile. Enter a new password for FI1 twice. 5 5.1 5.2 6 6.1 6.2 6.3 6.4 Choose Tools --> Administration --> User maintenance --> Activity groups, or call Transaction PFCG. Enter activity group CUSTOMER0001 and choose Create. Use Transaction PFCG, then see Exercise 2.1 Use Transaction PFCG --> Responsibilities. Activate the icon Create. Position the cursor on the responsibility Company code 0001 and activate Authorization profile. In the dialog box, maintain the value 0001 for the company code. No, all open authorizations are optional. Choose Authorization --> Generate, or activate the icon. Use Transaction SU01 Use Transaction SUIM, choosing User --> List of User Master Records Locked Due to Incorrect Logon The transactions selected above are now available. No No
2-257
BC360
6.5 6.6
Position the cursor on the responsibility Company code 0001. From the menu, choose Processor --> Assigned processor --> Create. Enter user FI1. Position the cursor on the responsibility Company code 0001 and activate User master data. Execute the update. All users needing an update are displayed. To confirm the update, activate User master data again. Use Transaction SU01, check if the correct responsibility has been entered in the User master data of user FI1 under Tasks profile, and if the correct authorization profile has been entered under Profile.
7 7.0 7.1 7.2 8 8.1 8.2 9 9.1 9.2 9.3 Use Transaction SU01.
2-258
BC360
In the following, you will find excerpts from the Operation Manual, Chapter 2 User Administration, in the section Authorizations and the Profile Generator. To perform these exercises, complete the table in the excerpts as follows: 1 The table under Tasks. For your company, determine the activity group (person responsible), and the frequency with which each of the listed tasks should be performed for the production system <PRDSID>, the quality assurance system <QASSID>, and the development system <DEVSID>. Enter this information and the appropriate transaction for the task in the table (the first row is already completed to provide an example).
Tasks
Task Frequency <PRD <QAS <DEV SID> Creating activity groups AR SID> AR SID> AR Tools Administration User maintenance Activity groups Generating authorization profiles Tools Administration User maintenance Activity groups Authorization profiles Assigning activity groups to users Tools Administration User maintenance Users. Enter the user. Choose Change Utilities Assign activity group Using the Infosystem Tools Administration User maintenance Users Information Information System Analyzing missing authorizations Menu Path (NT or R/3) Transaction Activity
Group
PFCG <AUADM>
W: Weekly M: Monthly D: Daily <AUADM>: Authorization administrator
Y: Yearly
AR: As required
2-259
BC360
No. 1 1.1 1.2 1.3 1.4 2 2.1 2.2
True
Question Can an authorization prevent printing on a particular printer, if another authorization allows printing and the user has both authorizations? Yes, if this is selected through the corresponding profile parameters No Yes Yes, if the authorizations are in different profiles Which of the following statements are true? If the Profile Generator is not being used, composite profiles must be created. If the Profile Generator is being used, all authorizations must be generated before you can create an authorization profile for an activity group. If the Profile Generator is being used, manually created profiles cannot be assigned to a user. If the Profile Generator is being used, either all activity groups must be based on responsibilities, or no activity groups may be based on responsibilities. Can different responsibilities in an activity group have different values for the authorization object S_TCODE? Yes, due to the selection of transactions when defining activities. No Yes, if these values are changed manually when maintaining the authorization profiles corresponding to the responsibilities. Yes, if an authorization for authorization object S_TCODE is entered manually when maintaining the authorization profiles corresponding to the responsibilities. How can you find out if the user buffer is too small for a user? The user must call Transaction SU53 and receive the message: User buffer too small! The administrator must position the cursor on the user in Transaction SM04 and choose User info. The user must call Transaction SU56, and check at the end of the alphabetically ordered list, if the last authorization object/authorization is
2.3 2.4
3 3.1 3.2 3.3 3.4
4 4.1 4.2 4.3
2-260
BC360
displayed. If it is not displayed, the user buffer is too small. 5 5.1 5.2 5.3 Does it make sense to enter a profile for an activity group or responsibility manually in the user master record of a user? No, because the report RHAUTUP1 removes these profiles from the user master record. Yes. If a profile is entered manually in the user master record, subsequent changes to the activity group have no effect on this user. Yes. There is no difference between adjusting the profile manually and adjusting the profile through the activity group or responsibility in the user master record.
2-261
BC360
No. 1 1.1 1.2 1.3 1.4 2 2.1 2.2
True
Question Can an authorization prevent printing on a particular printer, if another authorization allows printing and the user has both authorizations? Yes, if this is selected through the corresponding profile parameters
No Yes Yes, if the authorizations are in different profiles Which of the following statements are true? If the Profile Generator is not being used, composite profiles must be created. If the Profile Generator is being used, all authorizations must be generated before you can create an authorization profile for an activity group. If the Profile Generator is being used, manually created profiles cannot be assigned to a user. If the Profile Generator is being used, either all activity groups must be based on responsibilities, or no activity groups may be based on responsibilities. Can different responsibilities in an activity group have different values for the authorization object S_TCODE? Yes, due to the selection of transactions when defining activities. No
2.3 2.4
3 3.1 3.2 3.3 3.4 X X
Yes, if these values are changed manually when maintaining the authorization profiles corresponding to the responsibilities. Yes, if an authorization for authorization object S_TCODE is entered manually when maintaining the authorization profiles corresponding to the responsibilities. How can you find out if the user buffer is too small for a user? The user must call Transaction SU53 and receive the message: User buffer too small! The administrator must position the cursor on the user in Transaction SM04 and choose User info.
4 4.1 4.2 4.3 X
The user must call Transaction SU56, and check at the end of the alphabetically ordered list, if the last authorization object/authorization is
2-262
BC360
displayed. If it is not displayed, the user buffer is too small. 5 5.1 5.2 5.3 X Does it make sense to enter a profile for an activity group or responsibility manually in the user master record of a user? No, because the report RHAUTUP1 removes these profiles from the user master record. Yes. If a profile is entered manually in the user master record, subsequent changes to the activity group have no effect on this user. Yes. There is no difference between adjusting the profile manually and adjusting the profile through the activity group or responsibility in the user master record.
2-263
BC360
Basis Knowledge Product: System Managem ent Topic: User Adm inistration Online Documentation Docum entation Authorizations Made Easy from the R/3 Simplification Group SAP TechNet: System Management Forum OSS: BC-CCM-USR-ADM, BC-CCM -USR-KRN, BC-CCM-USR-PFC R/3 Note 80210 - Profile Generator: Com posite note
SAP AG
2-264
BC360
Appendix: Authorization Concept

DEV
Activity groups Profiles Master user
QAS
Activity groups Profiles M aster user
PRD
Activity groups Profiles M aster user User 1 User n
Testing
Do not develop!
Authorization administrator
SAP AG
Profile administrator
User administrator
The SAP standard templates for activity groups enable a distribution of power among administrators: SAP_ADM_AU: Authorization administrator (maintains authorizations) SAP_ADM_PR: Profile administrator (generates profiles) SAP_ADM_US: User administrator (maintains R/3 users) Activity groups, profiles and user templates should be generated in the development system (DEV). The authorization concept is tested in the quality assurance system (QAS). In the production system (PRD), the user administrator generates new R/3 users by copying user templates. An R/3 user with development authorizations can avoid the authorization check by using a modified or selfgenerated report. The production system should therefore be configured in such a way as to prevent any development from being performed there.
2-265
BC360
Appendix: Setting up the Profile Generator

Display Structure: Sam ple Enterprise IM G Structure Edit Goto Information Utilities Default settings System Help Expand/collapse What other projects? Implementation Guide for R/3 Customizing (IMG) 4 5 4 5 0 5 0 5 0 0 0 0 0 Training and Event Management Basis Components Basis Services System Administration Tables Changes Recording Users and Authorizations Define nonpermitted passwords Maintain authorizations and profiles using profile generator Activate profile generator Work on SAP check indicators and field values Generate Company menu Generate activity group / profile and assign users Update profile validities in user master record
SAP AG
You can set up the Profile Generator from the company IMG in Customizing. Select Maintain authorizations and profiles using profile generator, then execute the following steps: Activate Profile Generator Work on SAP check indicators and field values Generate company menu Generate activity group / profile and assign users Update profile validities in user master record See also OSS Composite Note 80210.
2-266
BC360
Appendix: User Adm in. Authorizations I

Authorization Objects Authorization Objects
User Master Maintenance: U ser Master Maintenance: Authorizations A uthorizations (S_USER_A UT) (S_USER_A UT)
Fields Fields
ACTVT: Activity ACTVT: Activity AUTH: Authorization nam e AUTH: Authorization nam e OBJECT: Authorization object OBJECT: Authorization object
User Master Maintenance U ser Master Maintenance User groups U ser groups (S_USER_GRP) (S_USER_GRP) User Master Maintenance User Master Maintenance Authorization profile Authorization profile (S_USER _PRO) (S_USER _PRO)
ACTVT: Activity ACTVT: Activity CLASS: U ser groups CLASS: U ser groups
ACTVT: Activity ACTVT: Activity PROFILE: A uthorization profiles PROFILE: Authorization profiles
SAP AG
This part of the appendix lists the authorization objects that are checked when working with the Profile Generator and when maintaining users. Authorization object Protected activities S_USER_AUT Create and change authorizations, enter authorizations in profiles,... S_USER_GRP Administrate users assigned to a user group S_USER_PRO Create and change profiles, enter profiles in user master records,...
2-267
BC360
Appendix: User Adm in. Authorizations II

Transaction code check Transaction code check at transaction start at transaction start (S_TCODE) (S_TCODE)
Fields Fields
TCD: Transaction code TCD: Transaction code
H R: Transaction code HR: Transaction code (P_TCODE) (P_TCODE)
TCD: Transaction code TCD: Transaction code
PD: Personnel planning PD: Personnel planning and development and development (PLOG) (PLOG)
INFOTYP: Info type INFOTYP: Info type ISTAT: Planning status ISTAT: Planning status OTYPE: Object type OTYPE: Object type PLVAR: Plan variant PLVAR: Plan variant PPFCODE: Function code PPFCODE: Function code SUPTYP: Sub type SUPTYP: Sub type
SAP AG
The authorization object S_TCODE is checked at the start of a transaction. In the authorizations contained in this authorization object, transaction codes are listed for all the transactions that can be started by the user. Further authorization checks are usually performed during the transaction. The authorization object P_TCODE is required for HR transactions and works similarly to S_TCODE. The Profile Generator (PFCG) is an HR transaction. The authorization object PLOG is required for integrating HR with basis functionalty.
2-268
BC360
Appendix: User Adm in. Authorizations III

B ackground processing: Background processing: B ackground administrator Background administrator (S_BTCH_ADM) (S_BTCH_ADM) B ackground processing :: Background processing Operations on background Operations on background jobs jobs (S_BTCH_JOB) (S_BTCH_JOB) Change and transport Change and transport organizer organizer (S_TRAN SPRT) (S_TRAN SPRT)
Fields Fields
BTCADMIN: ID for background BTCADMIN: ID for background adm inistrator adm inistrator
JOBACTION :: Operations on one JOBACTION Operations on one job job JOBGROU P: A num ber of jobs JOBGROUP: A num ber of jobs grouped together grouped together ACTVT: Activity ACTVT: Activity TTYPE: Request Type (Change TTYPE: Request Type (Change and Transport System )) and Transport System
SAP AG
The authorization objects S_BTCH_ADM and S_BTCH_JOB are checked during background processing, for example, when user master records are checked and updated in the background. When working with the Profile Generator, all objects generated and saved are recorded by the Customizing organizer. Within the Customizing organizer the authorization object S_TRANSPRT is checked. A user administrator needs at least the activities Change and Release for request type TASK for assignment to and recording in a Customizing task.
2-269
BC360
R/3 Spool and Print
R/3 Spool and Print
SAP AG
2-270
BC360
R/3 Spool and Print
R/3 Spool and Print

Contents:
Introduction R/3 Spool System overview Managing printers Frontend printing Spool server definition Managing spool requests Spool problem analysis Spool and print authorizations
SAP AG
2-271
BC360
R/3 Spool and Print
R/3 Spool and Print

Objectives:
At the end of this unit you will be able to: Describe the overall functionality of the R/3 Spool System Define output devices for local, rem ote, and frontend printing Define a logical spool server and use it on an output device Transport output devices and server definitions Manage spool and output requests Analyze and solve simple printing errors Identify the spool authorizations
SAP AG
2-272
BC360
R/3 Spool and Print
Course Roadmap
SAP AG
2-273
BC360
R/3 Spool and Print
Introduction
R/3 application ABAP editor, report list
Print
R/3 Spool System
Document
Document
Imm ediate printing

SAP AG
Delayed printing
List printing
The R/3 System has different ways of outputting information through its internal spool system. R/3 applications produce business data in the form of invoices, purchase orders, and requests for quotations. Each time a user creates a purchase order, for example, an output format is created. This output format is the format in which the information contained in the purchase order is communicated to another party through a specified media (such as in printed form, fax, or EDI). The document in this output format represents a message. Once a message is created, it is placed in the message (output) queue, and from there it is released as required for printing or transmission. A message can be transmitted immediately, upon saving the purchase order (immediate printing), or transmission can take place at a later time ( delayed printing). In addition to message control, the R/3 System uses a combination of a printing program and a SAPscript form to produce the output document. The purpose of the printing program is to extract the data for the document from the R/3 database. The SAPscript form specifies the layout of the printed document. Other forms of output documents in R/3 are reports and ABAP program listings. Usually these documents are output through the print function available from the tool bar or the system menu.
2-274
BC360
R/3 Spool and Print
R/3 Spool System
Print
R/3 Spool System
Operating system spool
Printer
SAP AG
To provide a uniform interface to the spooling services of diverse host operating systems, the R/3 System has its own internal spool system. This internal spool system is capable of generating a print-ready output stream for a variety of supported printers. This document output capability means that the R/3 System can format and output documents independently of the formatting services offered by the operating system. The R/3 System only requires the operating system spool and print services to pass a print-ready output stream to the physical device. The operating system spooler manages the physical device queue. In order for the R/3 applications to use a physical device, the system administrator must define a corresponding output device in R/3.
2-275
BC360
R/3 Spool and Print
Spool and Output Requests
Print
R/3 Spool System
Spool request
Spool: O ther device type Type HPLJ4 instead POSTSCPT with incorrect results? Yes No Cancel
Output request Printer A Copies: 1
Output request Printer B Copies: 2
Output request Printer C Copies: 3
SAP AG
Spool processing starts with a document that has been requested for printing from an R/3 application. The R/3 Spool System distinguishes between two types of objects: A spool request is created when a document in R/3 is requested to be printed but has not yet been sent to an output device. The spool request contains the data to be printed in an R/3 generic internal format. Some print data sources are: ABAP reports (lists) SAPscript Programming editor An output request is created when the document is actually sent to an output device. The output request is based upon the corresponding spool request. The output request contains the data to be printed in a devicespecific format. Multiple output requests can be generated from one spool request. Each output request may have different attributes, such as the target printer, the number of copies, the range of pages to be printed and so on. Although a spool request can be sent to different printers, choosing a printer with a different device type could cause incorrect results. In the example above, the spool request was generated for a POSTSCPT type of printer. Printing the spool request to printer C which has a different device type will cause the warning message to be displayed.
2-276
BC360
R/3 Spool and Print
TemSe Database
Print
R/3 Spool System
Tem Se
Spool request
Spool request data
Output request Printer A Copies: 1
Output request Printer B Copies: 2
Output request Printer C Copies: 3
SAP AG
The R/3 Spool System stores the following spool requests information in the R/3 database: Origin of the request Date it was created Name of the creator Logical printer name Client number The spool request data, however, is stored in a repository called the temporary sequential database (TemSe). Spool request data is the data to be printed. The R/3 Spool System uses generic representations of printer formatting commands and the R/3 internal character set to represent the characters to be printed. TemSe can store the data inside the database or at the operating system level. To determine where the data is stored, set the parameter rspo/store_location as follows: db stores the data in the database (default) G stores the data in an operating system file in the global directory Output requests are stored in the R/3 database only as control records. The print-ready output stream that is generated as part of the output request is passed on to the operating system spooler without being stored in the R/3 Spool System. This output stream is device-specific.
2-277
BC360
R/3 Spool and Print
Spool W ork Processes
Print
R/3 Spool System
Tem Se
Spool work process
Spool request data
Printer
SAP AG
When the R/3 Spool System is requested to print a document, a device-specific output stream must be created and sent to the operating system spooler. This process is carried out by a spool work process. As of R/3 Release 4.0A, you can configure your R/3 instance to run multiple spool work processes. Whether an instance consists of one or more spool work processes, a spool work process always handles one output request at a time. An R/3 instance running one or more spool work processes is considered a spool server. The role of a spool work process, in formatting the output stream, is to take the raw print data from the spool request and: Convert R/3 generic print controls into device-specific commands Add device-specific initialization and output event sequences (printer initialization, end of line, end of page, and so on) Convert the internal R/3 character set into the device-specific character set Once the formatting process is complete, the spool work process transfers the print-ready output stream to the operating system spooler. The final step of the print process is handled by the operating system spooler, which passes the output stream to the output device.
2-278
BC360
R/3 Spool and Print
R/3 Output Devices
Print
R/3 Spool System
Tem Se
O utput device: PR01 Device type: POSTSCPT - Print controls - Formatting actions - Character sets
Spool work process
Spool request data
Printer
SAP AG
To produce a device-specific output stream from a spool request, the spool work process needs some information. This information is stored in two R/3 spool objects, the output device and the device type, and is the same as the information held in printer drivers in the operating system. When users create spool requests, they must specify an output device. This output device points to a device type. The device type specifies the: R/3 character set used for the device Printer driver used for formatting SAPscript output Device-specific commands used for converting generic R/3 print controls and formatting actions The output devices that have the same characteristics use the same device type. For example, all the laser printers from one manufacturer, which are the same type and model, use the same device type.
2-279
BC360
R/3 Spool and Print
R/3 Local Printing

R/3 application server
Physically local printer

O perating system spooler C or L Spool w ork process R/3 Spool System
TCP/IP network
Network printer
Physically rem ote printer

SAP AG
The R/3 Spool System must send a print-ready output stream to the operating system spooler. This data transfer is called the access method, which can be either local or remote. R/3 local printing uses a local access method. Local printing is the fastest and most reliable way of printing in R/3. When using local printing, an R/3 spool work process passes the print-ready output stream to the operating system spooler in the same host. Local printing does not mean that the printer is physically attatched to the host running the R/3 spool work process. The operating system spooler can print on either a locally or remotely attached printer. When an output device is defined in R/3, an access method must be specified. Depending on the operating system, R/3 uses one of two different local access methods: Access method L: The output request is passed to the UNIX spooler using UNIX commands, for example lp or lpr. The form of the command is specified in the R/3 System profile. Access method C: On Windows NT systems, the spool work process uses operating system calls to pass output to the printer manager using the Windows NT API.
2-280
BC360
R/3 Spool and Print
R/3 Rem ote Printing

R/3 application server Network printer
Spool w ork process R/3 Spool System
TCP/IP network S
SAPLPD
Operating system spooler
PC printer
Host-bound printer
SAP AG
R/3 remote printing uses a remote access method. When using remote printing, an R/3 spool work process passes the print-ready output stream to the operating system spooler in a different host. This data transfer requires moving the output stream across a network link. The operating system spooler can then print on either a locally or remotely attached printer. The operating system receiving the output stream should have the line printer demon (lpd) running. For those platforms which do not support lpd, SAP provides the program SAPLPD, which receives the output stream and transfers it to the operating system spooler. The program SAPLPD runs on Microsoft Windows systems and OS/2. For Macintosh systems, refer to OSS Notes 2863 and 18802. Some printers can be directly attached to a network through a network card interface. These are called network printers, and can also receive output from R/3. Depending on the host receiving the output stream, there are two different remote access methods: U Which is used for UNIX systems and network printers S Which is used for Windows systems For performance reasons, the remote access methods are only suitable for LAN environments and require reliable communication partners.
2-281
BC360
R/3 Spool and Print
Spool Administration
Spool Adm inistration: Initial Screen Configuration Administration Goto Utilities Settings Environm ent System Help Extended admin. Full administration Selection model Configuration O utput devices O utput devices Spool server Access m ethods Destination hosts Global pattern No pattern
Administration Check installation Delete old spool requests Consistency check of spool database Print request overview
SAP AG
Transaction SPAD is used for R/3 Spool administration. Spool administration tasks carried out using Transaction SPAD are divided into three sections: Simple administration Extended administration Full administration This unit focuses only on simple administration tasks. The simple administration section is used for: Maintaining output devices (that is, creating, modifying, and transporting output devices) Maintaining spool servers (that is, creating, modifying, and deleting spool servers) Listing the access methods available for defining printers Listing the destination hosts used in remote printer definitions Maintaining spool requests (that is, reorganizing the TemSe database and checking the consistency of spool objects) To define a printer, use Transaction SPAD and choose Output devices.
2-282
BC360
R/3 Spool and Print
Defining a Local Printer

Spool Adm inistration: Change Output Device (Change) O utput device Edit G oto Extras Utilities System Help Logical device Paper tray info LocalPrinter Spool requests Short nam e
O utput device Device type Spool server Host printer Device class
LT02
POSTSCPT PostScript-Printer ISO Latin 1 pswdf694_TC1_00 pswdf694 PR02 Printer L Print locally via LP/LPR
Access m ethod to host spool M odel Location M essage
Data Center SAP AG, Walldorf
Lock printer in R/3 System SAP title page
SAP AG
To define a local printer in R/3, the following fields are used: Output device: Specify the printer name as defined in R/3. Printer names are case-sensitive. As of R/3 Release 4.0A, printer names can be 30 characters long. Short name: Specify the name that the spool system uses to access the printer. The short name can be automatically generated by the system when the printer is defined. Device type: Specify the type of printer. To display the device types available, press F4. Spool server: Specify the R/3 application server that formats the output requests for the printer. NOTE: When a local printer is defined, both the spool server and the host spooler receiving the print-ready output stream must reside on the same host. Host name: Is automatically generated by the system from the spool server name. Host printer: Specify the name of the printer defined at the operating system level. This name is also casesensitive. Device class: Specify the class of the device being defined, for example, a printer or fax. Access method to host spool: Specify the data transfer method to the host spooler. For local printers, use L for UNIX and C for Windows NT systems.
2-283
BC360
R/3 Spool and Print
Defining a Remote Printer

Spool Adm inistration: Change Output Device (Change) O utput device Edit G oto Extras Utilities System Help Logical device Output device Device type Spool server Destination hosts Host printer Device class Paper tray info Spool requests Short nam e REMO
RemotePrinter
POSTSCPT PostScript-Printer ISO Latin 1 pswdf694 pswdf694_TC1_00 hwpri06 P026 Options... Printer U Print on LPDHOST via Berkeley protocol
Atlanta Training Center - 23rd floor
SAP AG
To define a remote printer in R/3, the following fields are used: Output device: Specify the printer name as defined in R/3. Printer names are case-sensitive. As of R/3 Release 4.0A, printer names can be 30 characters long. Short name: Specify the name that the spool system uses to access the printer. The short name can be automatically generated by the system when the printer is defined. Device type: Specify the type of printer. To display the available device types, press F4. Spool server: Specify the R/3 application server that formats output requests for the printer. Host name: Is automatically generated by the system from the spool server name. Destination host: Specify the name of the host system where the output stream will be sent. For example, this host could be a UNIX system or a PC running SAPLPD. NOTE: Ensure that the host name and IP address of the destination host are entered in the Hosts file of the R/3 server. Host printer: Specify the name of the printer defined in the destination host. This name is case-sensitive. If the printer is a network printer, the Microsoft UNC name from Windows Print Manager can be used, for example: \\P13209\P025. Device class: Specify the class of the device being defined, for example, a printer or fax. Access method to host spool: Specify the data transfer method to the host spooler. For remote printers, use U for UNIX and S for Windows systems.
2-284
BC360
R/3 Spool and Print
R/3 Frontend Printing

SAPLPD/lpd
Print
Dialog w ork process R/3 System
R/3 application server
SAP AG
Frontend printing allows R/3 users to send output to printers that are not defined as output devices in R/3. Frontend printing uses access method F. If the frontend is a Windows PC, the output is sent to program SAPLPD on the frontend PC. If SAPLPD is not running, it is started on the frontend PC automatically. SAPLPD passes the output to the Windows default printer. In the case of a UNIX or Macintosh frontend, the output is passed to the lpd. Since UNIX and Macintosh do not recognize default printers, the lpd sends the output to the printer specified in the output device. In frontend printing, all spool processing takes place in a dialog work process. The dialog work process has to wait until the output has been sent to the frontend before it can continue processing any other requests. Therefore, performance problems can occur when frontend printing is used.
2-285
BC360
R/3 Spool and Print
Defining a Frontend Printer

Spool Adm inistration: Change Output Device (Change) O utput device Edit G oto Extras Utilities System Help
Logical device O utput device Device type Host printer Device class
Paper tray info
Spool requests Short nam e FRON
Frontend SWIN SAPWIN __DEFAULT Printer
Printing on front end computer
Frontend Printer
SAP AG
This graphic displays a frontend device defined for printing on Windows frontends. Using device type SWIN allows R/3 to use any printer that has a driver installed in Windows, even if this printer type is not directly supported by R/3. If the Host printer field is specifed as __DEFAULT, the Windows default printer is used. For UNIX and Macintosh frontends the printer name specified in the field Host printer must be the same name used in the frontend workstation or PC. For example, if __DEFAULT is entered in the field Host printer, then the frontend workstation must have a printer named __DEFAULT.
2-286
BC360
R/3 Spool and Print
R/3 Logical Spool Server

R/3 output device Nam e : Printer_A Device type : HPLJ4 Spool server : Production_Print R/3 logical spool server Nam e Mapping R/3 output device Nam e : Printer_B Device type : PO STSCPT Spool server : Production_Print Host spooler : Production_Print : hs5821_TC1_00 R/3 real spool server Nam e : hs5821_TC1_00
Printer_A
Printer_B
SAP AG
Logical spool servers introduce a new layer in the spool server architecture. Logical spool servers provide the following benefits: Spool server switchover Ability to transport the spool server architecture to another system Protection against server failure Load balancing among spool servers NOTE. This unit only covers the spool server switchover and the architecture transport A logical spool server can be mapped to a real spool server. A real spool server is an R/3 application server that has at least one spool work process and can process output requests. A logical spool server can be used instead of a real spool server in R/3. For example, an output device definition can address a logical spool server as well as a real spool server.
2-287
BC360
R/3 Spool and Print
Spool Server Switchover

R/3 output device Nam e : Printer_A Device type : HPLJ4 Spool server : Production_Print R/3 logical spool server Nam e Mapping R/3 output device Nam e : Printer_B Device type : PO STSCPT Spool server : Production_Print : Production_Print : hs5821_TC1_00 hs5822_TC1_00 R/3 real spool server Nam e : hs5821_TC1_00
R/3 real spool server Nam e : hs5822_TC1_00
Host spooler
Printer_A
Printer_B
SAP AG
If an output device uses a logical spool server, it can easily be switched from one real spool server to another. For example, if a real spool server is down for maintenance, you can switch all of its devices to another server by changing the mapping in the logical spool server. NOTE: To implement this configuration, both of the R/3 real spool servers must have access to the host spooler controlling printer_A and printer_B.
2-288
BC360
R/3 Spool and Print
Defining a Logical Spool Server

Spool Adm in.: Server (Change) Spool server Edit Goto View Utilities System Help
Mapping
O utput requests
Production_Print System nam e Logical Spool Server for Production Printers Attributes Server class
Unclassified M apping Alt. server pswdf694_TC1_00
E Logical server
Non-exclusive spool server
SAP AG
To define a logical spool server, use Transaction SPAD, and define the following fields: System name: Specify the logical spool server name, as defined in R/3. Logical server names are casesensitive. Logical server: To identify the spool server as a logical spool server, select this check box. Mapping: Specify the name of the R/3 real spool server that the logical server is mapped to. The advanced feautures of the R/3 spool server, such as server class, non-exclusive spool server, and alternate server are explained in the Basis Training course Advanced System Administration (BC305).
2-289
BC360
R/3 Spool and Print
Transporting the Printer Architecture

SAP
R/3 output device
R/3 output device
R/3 output device
R/3 output device
R/3 output device
R/3 output device
Prod_Printer_A
Prod_Printer_B
Vol_Printer_A
Prod_Printer_A
Prod_Printer_B
Vol_Printer_A
Logical spool server
Production_Print
Volume_Print
Production_Print
Volume_Print
Real spool server
Real spool server
Real spool server
hs5820_TST_00
hs5821_PRD_00
hs5822_PRD_00
Quality Assurance System TST
Production System PRD
SAP AG
Logical servers provide a uniform method for defining and transporting a complete printer architecture with minimal changes. This example shows that a printer architecture can be transported from an R/3 quality assurance system to a production system. All the output devices and logical spool servers from the quality assurance system are transported to the production system. To activate printing in the target system, only the mapping in each logical server definition needs to be customized for the new R/3 System environment. Transaction SPAD provides the functions for transporting both output device definitions and spool server definitions.
2-290
BC360
R/3 Spool and Print
Managing Spool Requests

End users can:
Display and delete their own spool requests Change attributes of their own spool requests Print their own spool requests
The spool administrator can:

Check spool consistency Perform spool maintenance
SAP AG
End users can manage their own spool requests without any special spool authorization. For example, end users can: List spool requests Delete spool requests Change attributes of spool requests Display and print spool requests To maintain spool requests, use transaction SP01. The spool administrator requires additional authorizations to manage spool requests for the entire system. The administrator can: Manage other user's spool requests (such as list, display, print, and delete) Check the consistency of spool tables, spool requests, output requests, and data Delete obsolete spool requests To maintain the spool system, use Transaction SPAD. NOTE: The spool system authorizations are listed at the end of this unit.
2-291
BC360
R/3 Spool and Print
Managing Spool Requests

Spool: Request Screen Spool request Edit G oto Environment System Help
Spool request num ber Spool request nam e User name From Client Authorization O utput device Format Title Recipient Department Note To access the error log for spool request printout, select Goto->Spool requests from the menu. RAULV 27.05.1998 100
to
27.05.1998
SAP AG
Use Transaction SP01 to display a list of spool requests, based on the selection criteria, such as the spool request number and creation date.
2-292
BC360
R/3 Spool and Print
Spool Request List

Spool: Requests Spool request Edit G oto Environment System Help
Back Spool No.
O utput requests Generation Output Date Time Status -
As attr. Pages
User name Title or Spool req. name 1 LIST1S P026 SAPMSPAD_RAU 1 LIST1S LT02 RSMON000_RAU 1 LIST1S LT02 RSMON000_RAU
0000027008 27.05.98 12:10
0000027006 27.05.98 12:10 Error 0000027004 27.05.98 12:10 Compl.
SAP AG
The status of each request is displayed in the spool request list. To display a list of all output requests that have been generated for a spool request, mark a spool request and choose Output requests. If an output request is not completed successfully, a log is generated, which can be used for error analysis.
2-293
BC360
R/3 Spool and Print
Deleting Old Spool Requests
Online
Transaction SPAD Delete old spool requests
Background processing
ABAP program RSPO0041 Client 100 Requests past expiration date 10 M inim um age in days Printed requests with P m inim um age All requests with A m inim um age
Spool DB
SAP AG
To delete old spool requests, use Transaction SPAD or schedule program RSPO0041 to run periodically in the background. When program RSPO0041 is used, a variant must be created. The input parameters for program RSPO0041 are: Expiration date Minimum age (in days) Target client When Transaction SPAD is used, the delete functions are limited to the client where they are started, for security reasons. Report RSPO0041 allows old spool request across multiple clients to be deleted.
2-294
BC360
R/3 Spool and Print
Spool Database Consistency Check
Online
Transaction SPAD Consistency check of spool database
Background processing
ABAP program RSPO0043 Release locks after ... m inutes
30
Spool DB
SAP AG
To check the consistency of the spool database, use Transaction SPAD or schedule program RSPO0043 to run periodically in the background. This consistency check ensures that the tables containing spool requests, output requests, and output data are consistent with each other.
2-295
BC360
R/3 Spool and Print
Spool Problem Analysis

YES Was the printout generated? NO
YES
Does the printout contain any errors?
NO
YES
W as a spool request created?
NO
Wrong printer chosen? Incorrect printer definition? Incorrect user-defined device type?
No problem
Missing authorization? Application problem? Basis problem? Analyze dumps... Status of spool request?
-Request was not submitted as "Print immediately" ...
Wait Request waiting in R/3 spool ... R/3 spool server down? R/3 spool work process busy?
Com pl./Error Request completed in R/3, but ... Stuck in host spooler? Destination host unreachable? SAPLPD not running? Printer offline?
SAP AG
This flowchart displays how you can analyze errors in the R/3 Spool System. If a document is printed with unexpected results (such as missing characters), check if: The spool request was created for a particular device type, and it was printed on a different device type (for example, POSTSCPT vs. HPLJ4) The printer has an incorrect user-defined device type (such as an incomplete character set or missing format actions) If a document is not printed at all, check if: The spool request was created, but the print request has not been completed. If this occurs, analzye the status of the spool request to determine the possible cause. If there are no problems in the R/3 Spool System, check the host spooler for possible errors. The spool request was not created. If this occurs, there may be a problem in the application or in the basis system (for example, if a SAPScript form is not active or an ABAP program fails). To analyze R/3 Spool System errors, use the following tools : Output controller (Transaction SP01) and display the output request logs R/3 System log (Transaction SM21) ABAP Dump Analysis (Transaction ST22) Process overview (Transaction SM50) and display the work process trace file
2-296
BC360
R/3 Spool and Print
Spool and Print Authorization

Object
Spool action (S_SPO_ACT)
Fields
SPOACTION
Value
BASE PRNT REPR REDI DELE DISP AUTH ATTR value
M eaning
List spool requests Print once Repeat printing Redirect Delete m anually Display Change authorization Change attributes Value for w hich the user is authorized. This value must match the authorization field in the spool request.
SPOAUTH
System authorization (S_ADMI_FCD)
S_ADMI_FCD
SP01 SP0R SPAD SPAR SPAA SPAB SPAC SPAM SPTD SPTR
Adm inistration of spool requests (all clients) Same as SP01 (own client) Spool adm inistration (all clients) Client-dependant spool administration Define output devices Define real and logical O MS M aintain device types and related objects Administration of spool requests (all clients) Tem Se administration (all clients) Same as SPTD (own client)
SAP AG
End users have full control over their spool requests in the output controller. Spool administrators can manage all spool requests through authorization objects S_ADMI_FCD and S_SPO_ACT. Authorization object S_ADMI_FCD allows the administrator to perform diferent management tasks, such as spool request administration and output device administration. Authorization object S_SPO_ACT specifies what actions the administrator can perform on which spool requests. For example, SPOACTION = BASE,DISP and SPOAUTH=xyz allow the administrator to list and display all spool requests with the authorization field equal to xyz. Prior to R/3 Release 4.0, a spool request was only protected if an explicit value was entered in the authorization field. As of R/3 Release 4.0, a spool request has its owner's user ID as default value for the authorization field. Therefore, all spool requests are implicitely protected.
2-297
BC360
R/3 Spool and Print
Spool and Print Authorization

Object
Device authorization (S_SPO_DEV)
Fields
SPODEVICE
Value
value
M eaning
Long name of the output device
Maxim um num ber of pages (S_SPO _PAGE)
SPODEVICE SPOPAGES
value value
Long nam e of the output device Number of pages permitted
SAP AG
Use authorization object S_SPO_DEV to limit printer access by name. Authorization object S_SPO_PAGE specifies the maximum number of pages a user can print on a specific output device. To activate this authorization object, set parameter rspo/auth/pagelimit =1 in the instance profile. Once the authorization object is activated, all users must have S_SPO_PAGE authorization to be able to print.
2-298
BC360
R/3 Spool and Print

Describe the function of the R/3 Spool System Define output devices for local, remote, and frontend printing Define a logical spool server and use it on an output device Transport output devices and server definitions Manage spool and output requests Analyze and solve simple printing errors Use the spool authorizations for end users and system adm inistrators
SAP AG
2-299
BC360
R/3 Spool and Print
Unit Actions
Do the exercises
Solutions for the exercises Answers to for the questions
SAP AG
2-300
BC360
No. 1 1.1 1.2 1.3 2 2.1 2.2 2.3 2.4 3 3.1 3.2 3.3 3.4 4 4.1 4.2 4.3 4.4
Exercise Define a local R/3 printer Check that the printer is functioning properly in the host environment. (The instructor will provide the printer name). Create the local output device in R/3 for the printer. Submit an output request to the output device you just defined, and check that the output is correct. Define a remote R/3 printer Check if you can reach the destination host from the R/3 server. (The instructor will provide the destination host name). Check if the printer can be accessed from the destination host. (The instructor will provide the printer name). Create the remote output device in R/3 for the printer. Submit an output request to the output device you just defined, and check that the output is correct. Define a logical server and assign it to an output device Create a logical spool server in R/3. Check that it maps to an active real spool server. Display the logical server mapping information and discuss the hierarchy and the color coding in the diagram. Change both the local and remote output devices created in exercises 1 and 2 so that they use the logical server. Submit an output request to both printers, and check that the output is correct. Manage spool requests using Transaction SP01 Display all of your own spool requests. Display the contents of a spool request. Print two copies of one spool request from the list. Display all output requests generated for the spool request you just printed and check their status. Display the attributes of the spool request printed in step 4.3. Note that the number of copies for the spool request is still 1.
4.5
Change the attributes of the spool request printed in step 4.3 to specify a default of 2 copies.
2-301
BC360
4.6 5 5.1 5.1 5.2
Delete all of your own spool requests. Analyze a simple spool problem (optional) Modify the mapping of the logical spool server created in step 3.1. Change the field Mapping to Dummy_server. Submit an output request to either your local or remote printer, and check the status of the spool request. Use the available tools to determine the cause of the problem. Hint: Refer to the spool problem analysis flowchart in this unit.
5.3
Fix the problem based on the information you have gathered. Check that the spool requested has completed successfully.
2-302
BC360
No. 1 1.1
Solution
To check the printer in the host environment, use command print if the host is a Windows NT system, or use command lp or lpr if the host is a UNIX system. Example for Windows NT: Print /D:\\P13209\P025 c:\winnt\system32\drivers\etc\hosts (where \\P13209\P025 is the printer name).
1.2
To create the local output device, run Transaction SPAD and choose Output devices. In the screen displayed, choose Change and then choose Create. Fill in the following fields: Output device: BC310_LOC_XX (XX = group number) Device type: Depends on the printer type. The instructor will provide this information (for example, POSTSCPT). Spool server: Use the default value Host printer: Enter the name provided by the instructor in step 1.1 Device class: Use the default value Access method: L or C (depends on the host operating system) Save your output device definition, and exit Transaction SPAD.
1.3
To print the list of application servers, run Transaction SM51 and choose System --> List --> Print. In the screen displayed: Specify the output device created in step 1.2 Specify the Number of copies as 1 Select Print immediately Do not select Delete after print Choose Print. A spool request should be generated by the system. Note the spool request number. Check that your print request was successful.
2 2.1 To test the connection to the destination host, use the ping command from the R/3 server. For example, enter command ping hwpri06.
2-303
BC360
2.2
To check if the printer can be accessed from the destination host, use command print if the destination host is a Windows system, or use command lp or lpr if the destination host is a UNIX system. To create a remote output device, run Transaction SPAD, and choose Output devices. In the screen displayed, choose Change and then choose Create. Fill in the following fields: Output device: BC310_REM_XX (XX = group number) Device type: Depends on the printer type. The instructor will provide this information (for example, POSTSCPT). Spool server: Use the default value Destination host: Enter the name provided by the instructor in step 2.1 Host printer: Enter the name provided by the instructor in step 2.2 Device class: Use the default value Access method: U or S (depends on the operating system of the destination host) Save your output device definition, and exit Transaction SPAD.
2.3
2.4
To print the list of work processes, run Transaction SM50 and choose System --> List --> Print. In the screen displayed: Specify the output device created in step 2.3 Specify the Number of copies as 1 Select Print immediately Do not select Delete after print Choose Print. A spool request should be generated by the system. Note the spool request number. Check that your print request was successful.
2-304
BC360
3.1
To create a logical spool server, run Transaction SPAD, and choose Spool server. In the screen displayed, choose Change and then choose Create. Fill in the following fields: System name: BC310_XX (XX = group number) (Optional) Enter a brief description of the logical server Server class: Use the default value Logical server: Select this option Non-exclusive spool server: Do not select this option Alt. Server: Leave this field blank Choose Enter. The mapping field is displayed. To display the list of possible entries for the mapping field, press F4. Select a real spool server from the list. If possible, select the spool server running on your application server. NOTE: The real servers are highlighted in green. Save your spool server definition, and exit Transaction SPAD.
3.2
To display the mapping information, run Transaction SPAD, and choose Spool server. Place the cursor on the logical server you defined in step 3.1, and choose Mapping. A diagram showing the relationship between the logical server and the real server is displayed. The coloring of the logical server should indicate that this is a logical server with assigned spool service. If this is not the case, check your server definition. Return to the Spool Administration Initial Screen.
3.3
From the Spool Administration Initial Screen, choose Output devices. If you are in display mode, choose Change. In the new screen displayed, double-click the local output device defined in step 1.2. Place the cursor in the field Spool server and press F4. Select the logical spool server defined in step 3.1. Save the revised output device definition, and go back to the previous screen. Double-click the remote output device defined in step 2.3. Place the cursor in the field Spool server and press F4. Select the logical spool server defined in step 3.1. Save the revised output device definition, and exit Transaction SPAD.
2-305
BC360
3.4
To print the list of work processes, run Transaction SM50 and choose System --> List --> Print. In the screen displayed: Specify the local output device modified in step 3.3 Specify the Number of copies as 1 Select Print immediately Do not select Delete after print Choose Print. A spool request should be generated by the system. Note the spool request number. Check that your print request was successful. Now repeat this procedure for the remote output device.
4 4.1 To display your spool requests, run Transaction SP01. Use the default values for all fields in the selection screen, and choose Enter. 4.2 To display the contents of a spool request, mark a spool request from the list, and choose Display. Go back to the previous screen. 4.3 Mark one spool request from the list and choose Print. The print parameters are displayed. Specify the Number of copies as 2, and then choose Print. Check the results of your print request. Mark the spool request you just printed and choose Output requests. All the output requests generated for the selected spool request are displayed. To display the status description, double-click one of the output requests in the status column. 4.4 Mark the spool request you printed in step 4.3 and choose Attributes. To display the number of copies, choose Attributes II. 4.5 Specify the Number of copies as 2. Save the spool request. To verify the new default value for number of copies, display the attributes of the spool request. 4.6 5 Mark all the spool requests from your list and choose Delete. To delete all spool requests, choose Yes.
2-306
BC360
5.1
Run Transaction SPAD and choose Spool server. If you are in display mode, choose Change. In the screen displayed, double-click the name of your logical server. Enter Dummy_server in the Mapping field. Save the modified spool server definition, and exit Transaction SPAD.
5.1
To print the list of work processes, run Transaction SM50 and choose System --> List --> Print. In the screen displayed: Specify either the local or remote output device Select Print immediately Do not select Delete after print Choose Print. A spool request should be generated by the system. Note the spool request number. Run Transaction SP01 and check the status of the spool request created. The status should be Wait.
5.2
To display the output request list for the spool request, run Transaction SP01. Select the spool request and choose Output request. The status for the output request should be Waiting for output formatter. To display the status description, double-click the status column. The output request has not been printed because it is waiting for a spool server. Dummy_server is not an active spool server.
5.3
Run Transaction SPAD and choose Spool server. If you are in display mode, choose Change. In the screen displayed, double-click the name of your logical server. Change the mapping field to an active real server. Save the modified spool server definition, and exit Transaction SPAD. The waiting spool request is automatically redirected to the active real server.
2-307
BC360
In the following, you will find excerpts from the Operation Manual, Chapter 6 Printing, in the section Printer Requirements. To perform these exercises, complete the tables in the excerpts as follows: 1 The table under Tasks. For your company, determine the activity group (person responsible), and the frequency with which each of the listed tasks should be performed for the production system <PRDSID>, the quality assurance system <QASSID>, and the development system <DEVSID>. Enter this information and the appropriate transaction for the task in the table (the first row is already completed to provide an example).
The tables under Configuration Documentation. In your system, find out which printers are configured and use this information to complete the table.
Tasks
Task Frequency <PRD <QAS <DEV SID> Finding out your printer requirements Documenting your printer landscape AR SID> AR SID> AR <R3ADM> Menu Path (NT or R/3) Transaction Activity Group
D: Daily W: Weekly <R3ADM>: System administrator
M: Monthly
Y: Yearly
AR: As required
Use the following table to document your printers for R/3. The data shown in the table below is sample data. R/3 Output Device Device Type Location Spool Server Host Printer Spool Access Meth. P122 HPLJIII Room 3 LANSERV LPT1 C Personal Non-critical printing Dept. Used for
2-308
BC360
2-309
BC360
No. 1 1.1
True?
Question: Which of the following statements is true? The R/3 System has its own internal spool system, which is capable of producing a print-ready output stream for a variety of supported printers. The R/3 Spool System controls the printer queue at the operating system level. The R/3 Spool System never formats a document for printing. The formatting always has to be done by the operating system spool service. Which of the following statements are true? The TemSe database is used by the R/3 Spool System to store the spool request data. The TemSe database can reside in the R/3 database or at the operating system level. The R/3 Spool System always stores spool request data in a file at the operating system level. This procedure cannot be changed by the system administrator. A spool request in R/3 is always stored in a device-specific format. A spool request contains the data to be printed in an R/3-generic internal format. Which of the following statements are true? An R/3 spool request can have a maximum of two output requests. Multiple output requests can be generated from an R/3 spool request. Whenever an R/3 spool request is created, the R/3 System automatically generates an output request and stores it in the database. An output request contains the data to be printed in a device-specific format. As of R/3 Release 4.0, which of the following statements is true? An R/3 instance can have a maximum of three spool work processes. An R/3 instance must have at least three spool work processes. An R/3 instance can have multiple spool work processes. When an R/3 output device uses a local access method, such as C or
1.2 1.3
2 2.1 2.2 2.2
2.3 2.4 3 3.1 3.2 3.3 3.4 4 4.1 4.2 4.3 5
2-310
BC360
L, which of the following statements are true? 5.1 5.2 5.3 5.4 6 6.1 6.2 6.3 The R/3 spool work process passes a print-ready output stream to the operating system spooler in the same host. The R/3 spool work process passes a print-ready output stream to the operating system spooler in a different host. The physical printer must be locally attached to the host running the R/3 spool work process. The physical printer can be either locally or remotely attached to the host running the R/3 spool work process. Which of the following statements are true? Access method U is used for R/3 local output devices. Program SAPLPD is used to receive an output stream from an R/3 spool work process and to transfer it to the operating system spooler. Access method S is used to define an R/3 output device for a printer that is attached to a PC, which is running Windows. Program SAPLPD must run on the PC. When using access method S, the physical printer must be locally attached to the PC running program SAPLPD. Which of the following spool administration tasks can be executed from the Simple Administration menu of Transaction SPAD? Defining an R/3 local output device. Modifying an R/3 standard device type. Deleting old spool requests. Defining a logical spool server. Which of the following statements are true about frontend printing? All spool processing takes place in a dialog work process. All spool processing takes place in a spool work process. Access method F must be used. In an R/3 frontend output device that is defined for a Windows frontend, the Host printer field can be specified as __DEFAULT, in order to use the Windows default printer. Which of the following statements are true about logical spool servers? A logical spool server definition can be transported between R/3 Systems.
6.4 7 7.1 7.2 7.3 7.4 8 8.1 8.2 8.3 8.4
9 9.1
2-311
BC360
9.2 9.3 9.4 10 10.1 10.2 10.3 10.4
A logical spool server can be used instead of a real spool server in an R/3 output device definition. A logical spool server can be mapped to three or more real spool servers at the same time. A logical spool server can be mapped to a real spool server or to a logical spool server. Which authorization object is used to limit the number of pages that a user can print on a specificprinter? S_SPO_DEV S_SPO_ACT S_ADMI_FCD S_SPO_PAGE
2-312
BC360
No. 1 1.1
True?
Question: Which of the following statements is true?
The R/3 System has its own internal spool system, which is capable of producing a print-ready output stream for a variety of supported printers. The R/3 Spool System controls the printer queue at the operating system level. The R/3 Spool System never formats a document for printing. The formatting always has to be done by the operating system spool service. Which of the following statements are true?
1.2 1.3
2 2.1 2.2 2.2 X X
The TemSe database is used by the R/3 Spool System to store the spool request data. The TemSe database can reside in the R/3 database or at the operating system level. The R/3 Spool System always stores spool request data in a file at the operating system level. This procedure cannot be changed by the system administrator. A spool request in R/3 is always stored in a device-specific format.
2.3 2.4 3 3.1 3.2 3.3 3.4 4 4.1 4.2 4.3 5 X X X X
A spool request contains the data to be printed in an R/3-generic internal format. Which of the following statements are true? An R/3 spool request can have a maximum of two output requests. Multiple output requests can be generated from an R/3 spool request. Whenever an R/3 spool request is created, the R/3 System automatically generates an output request and stores it in the database. An output request contains the data to be printed in a device-specific format. As of R/3 Release 4.0, which of the following statements is true? An R/3 instance can have a maximum of three spool work processes. An R/3 instance must have at least three spool work processes. An R/3 instance can have multiple spool work processes. When an R/3 output device uses a local access method, such as C or
2-313
BC360
L, which of the following statements are true? 5.1 5.2 5.3 5.4 6 6.1 6.2 6.3 X X X X The R/3 spool work process passes a print-ready output stream to the operating system spooler in the same host. The R/3 spool work process passes a print-ready output stream to the operating system spooler in a different host. The physical printer must be locally attached to the host running the R/3 spool work process. The physical printer can be either locally or remotely attached to the host running the R/3 spool work process. Which of the following statements are true? Access method U is used for R/3 local output devices. Program SAPLPD is used to receive an output stream from an R/3 spool work process and to transfer it to the operating system spooler. Access method S is used to define an R/3 output device for a printer that is attached to a PC, which is running Windows. Program SAPLPD must run on the PC. When using access method S, the physical printer must be locally attached to the PC running program SAPLPD. Which of the following spool administration tasks can be executed from the Simple Administration menu of Transaction SPAD? X Defining an R/3 local output device. Modifying an R/3 standard device type. X X Deleting old spool requests. Defining a logical spool server. Which of the following statements are true about frontend printing? X All spool processing takes place in a dialog work process. All spool processing takes place in a spool work process. X X Access method F must be used. In an R/3 frontend output device that is defined for a Windows frontend, the Host printer field can be specified as __DEFAULT, in order to use the Windows default printer. Which of the following statements are true about logical spool servers? X A logical spool server definition can be transported between R/3 Systems.
6.4 7 7.1 7.2 7.3 7.4 8 8.1 8.2 8.3 8.4
9 9.1
2-314
BC360
9.2 9.3 9.4 10 10.1 10.2 10.3 10.4
A logical spool server can be used instead of a real spool server in an R/3 output device definition. A logical spool server can be mapped to three or more real spool servers at the same time.
A logical spool server can be mapped to a real spool server or to a logical spool server. Which authorization object is used to limit the number of pages that a user can print on a specificprinter? S_SPO_DEV S_SPO_ACT S_ADMI_FCD
S_SPO_PAGE
2-315
BC360
R/3 Spool and Print
R/3 Online Docum entation:

BC Printing Guide
Basis Training Course:

Advanced System Administration (BC305)
R/3 Knowledge Products
SAP AG
For a complete list of spool request statuses, see the R/3 Online Documentation: BC Printing Guide The Basis Training course Advanced System Administration (BC305) provides further information about: Failure protection and load balancing of logical spool servers Advanced features of the R/3 spool server functions, such as: Server class Non-exclusive spool server Alternate server
2-316
BC360
R/3 Spool and Print
Appendix
SAP AG
Menu paths of transactions used in this unit are: Tools --> CCMS -->Spool -->Spool administration (Transaction SPAD) System -->Services -->Output controller (Transaction SP01) Tools -->Administration -->Monitor -->Dump Analysis (Transaction ST22) Tools -->Administration -->Monitor -->System log (Transaction SM21) Tools -->Administration -->Monitor -->System monitoring -->Process overview (Transaction SM50)
2-317
BC360
Data Archiving in R/3

R
SAP AG
2-318
BC360

Contents:
Why archive data? Data archiving technology Using R/3 data archiving tools
Objectives:
At the end of this unit, you will be able to: Perform the necessary preparations for data archiving Archive application data in conjunction with business departm ents Monitor archiving runs and find solutions to problem situations Access and display archived data
SAP AG
R
This unit is structured as follows: The first part explains the need for data archiving and how archiving fulfils the technical demands. The second part introduces the archiving Transaction SARA, and the prerequisites for data archiving.
2-319
BC360
Course Roadmap

R
SAP AG
2-320
BC360
W hat is Data Archiving?

Application data
Stored in files on the hard disk Deleted in the database Evaluated in files without reloading into the database
SAP AG
To differentiate between the many data backup and archiving methods, the term data archiving is used here to indicate the removal of application data belonging to completed business processes from the database. This data is then compressed and stored in another location, for example, in a file system, an optical archive, or in Hierarchical Storage Management (HSM) systems.
2-321
BC360
W hy Archive Data in R/3?

Rapid database growth can lead to
Longer backup and recovery times Insufficient free space on hard disks Reduced performance when accessing data
Business and legal concerns resulting from

External audit W arranty obligations Data reusability
The database contains data that is no longer accessed or only rarely used
R
SAP AG
As the database steadily increases in size, backup times also increase. Certain data on the other hand, although it is no longer accessed or only rarely used, must not be deleted before its expiration date. This data can also be held outside the R/3 database. Bearing in mind the factors described above, you must decide how often to archive data. Use the following points to assist with planning your archiving schedule: The rate of growth of your database Information provided by the business departments Business reasons, such as the changeover to the Euro or the end of a fiscal year, which may interrupt your normal archiving schedule
2-322
BC360
How to Archive Data

Archiving objects
R/3 database
Archive files
R/3 application data objects
W rite program for the archiving object

R
Data archiving run

SAP AG
Archiving application data references information stored in archiving objects in the R/3 System. Only R/3 System data that is described in the archiving objects can be archived. An archiving object contains the following main elements: Information about tables containing data to be archived A write program that selects the data and writes it to an archive file or files A delete program, that compares the data in the archive files with the data in the database, and deletes the database data if both are identical Documentation for the archiving object, called through Info in the archiving Transaction SARA. To call this transaction, select Tools Administration Administration Archiving, or access it from the application.
2-323
BC360
Data Archiving Process

R/3 Database
14.12 14.13 14.14
W rite program for the archiving object
13.22 13.23 13.24
Delete program for archive file 1

Archive file 1
...
Archive file 2
R
SAP AG
When writing the archive files, data is usually compressed by a factor of 5. However, clustered tables are never compressed. Data archiving can run parallel to normal user workload and will affect system performance depending on the archiving object used, and the amount of data to be archived. Before deleting the data in the database, the delete program compares the contents of the archive file with the same data stored in the database. Deletion takes place only if both sets of data are identical. Deletion can be selected to start automatically or manually in the Customizing of each individual archiving object. If an automatic start of deletion has been selected in Customizing, a deletion program starts after each archive file is completed. This two-step archiving procedure guarantees maximum data security during archiving.
2-324
BC360
Archive Development Kit (ADK)

R/3 System Database
Application
ADK structures and num ber format

SAP ArchiveLink
Conversion of codepage, record
Operating system
M anual
Archive file
Archiving system with tertiary storage m edia

SAP AG
The Archive Development Kit (ADK) is the interface between the archiving programs of the applications and the archive files. The archiving programs use the functionality of the ADK (in the form of function modules) to write the archive data to disk. Selects on the archived data are started by application programs. The physical access to the archived data is performed by the ADK. The ADK sometimes splits the data to be archived among several archive files. If you use the SAP ArchiveLink interface for secure storage of archived data, the ADK transfers the data from the archiving program to SAP ArchiveLink. If an ABAP program accesses an archive file, the ADK ensures that the data is returned in the same format as currently found in the R/3 Repository. This adaptation is independent of the hardware platform on which the data was archived. You can use the ADK to create your own archiving objects and use these to archive data from tables defined by your company. Do not use the ADK to create archiving objects for archiving data from tables defined in the R/3 standard.
2-325
BC360
Accessing Archived Data

Analysis (Reporting)
Individual program s for each archive object Generic tools / Browser
Direct access
Individual program s for accessing certain archiving objects Generic direct access tool
Reload
Available for a few archiving objects Used only for correcting errors after archived data is deleted Data records incorrectly selected for archiving Residence tim e incorrectly customized
SAP AG
R
Almost all archiving objects are supplied with an individual analysis program, which sequentially reads the archive files and creates a spool list. For some archiving objects, you can simultaneously analyze archived data and data in the database. For example, almost all analyses of FI documents can use data from the database and/or the archives. All programs referring to the logical database BRF can use the functionality of this database to automatically access data in the database and in archive files. No special coding is needed. The following data can be directly accessed in the archive files: FI documents - Transaction FB03 Material documents -Transaction MB61 SD invoice documents -Transaction VF03 and others Reload should only be used for correcting errors, for example when data is archived too soon and deleted in the database. Reload is available, for example, for: FI documents restricted after changeover to the Euro SD documents Note: From R/3 Release 4.0, or from 3.0D with the appropriate preliminary transport, reloading of SD documents is no longer supported.
2-326
BC360
Preparations for Data Archiving I

Define an archiving structure
Include business department colleagues who are responsible for data archiving
Study the docum entation on archiving objects to be used
Identify fast-growing database tables using Transactions DB02, DB15
SAP AG
Archiving can be considered from two points of view: From the application point of view, some data becomes obsolete after a certain time, or is no longer needed online. For system (database) administrators, data archiving is needed when backup times increase due to database growth. The path you use to access archiving functions depends on your point of view: Application team members accessing archiving functions from an application menu Administrators using Transaction SARA: Tools Administration Administration Archiving Before archiving data, all available documentation should be read carefully: Online documentation Information in the Transaction SARA, supplied specifically for each archiving object OSS Notes for the applications BC- CCM- ADK and BC- SRV- ARL To identify fast growing tables, administrators can access the CCMS and run Transaction DB15. This transaction shows the sizes of all tables belonging to one archiving object.
2-327
BC360
Preparations for Data Archiving II

Customize the archiving object, including test and production variants for the delete program (Dep.)
Delete program Start automat. Comm it counter Test run variant Pro d. run variant
B B
Configure at least 2 background work processes (IT)
Ensure that sufficient hard disk space is available (IT)
Customize logical file and path names (Dep.)

R
Dep. = Business department (Ex.: HR department) IT= Information Technology department

SAP AG
Customizing is performed for each archiving object, to define, for example: Residence time after which data can be removed from the database Size of the archive files to be written Number of data records in each archive file Startup of the delete program (automatic or manual) Test and production variants Because the delete program can be started automatically, you should make at least two background work processes available for parallel processing of the write programs and the delete programs. The write program should be executed on the server where the database is located. For workload distribution purposes, the delete jobs should run on additional application servers. The job Submit handles the submission of the write job and finds all available background work processes. An archiving run is completed only after all the delete programs have successfully deleted the archived data from the database. To customize the logical file and path names, use Transactions SF01 and FILE. To determine how much hard disk space is needed for archiving, perform a test run without writing data to files.
2-328
BC360
Data Archiving Steps

Use Transaction SARA or access from an application (Dep.) M aintain one variant for each specific archiving run (Dep.)
Archiving object
2 variants for the delete program (only defined once)
Delete program S tart auto mat. Comm it counter Test run P rod. run Clien t Variant Testrun Prodrun V ariant V ariant User nam e
Archiving run
1 variant for each archiving run
100 Eschivierung0815 DO KTORS PO OL M aintain
SAP AG
An archiving run is started either by the administrator in agreement with the person(s) responsible in the application, or by a member of the business department who has the necessary authorizations. For each archiving run, there is a specific program variant that determines which data should be archived. Depending on the archiving object, there may be several parameters to maintain. The program variant can be reused, provided that the background job that used the program variant has been deleted.
2-329
BC360
Monitoring an Archiving Run

M onitor background jobs using Transaction SM37 (IT) Proofread spool lists (Dep.) Analyze management data in Transaction SARA (IT) Check additional information in the net graphic (Ex. FI_ACCRECV)
FI_DOCUMNT FI FI_ACCRECV FI
Financial accounting documents archived: 1.8.98
Custom er m aster data archived:
FI_MONTHLY
FI
Sales figures A/P, A/R, G/L archived:

SAP AG
1.8.98
To monitor background processes, use Transaction SM37. Check whether the scheduled archiving runs were processed, and at what time the processing occurred. Depending on the settings in Customizing, especially on the maximum number of data objects and the file size, a certain number of write jobs is generated. For each write job, one delete job may be created. These jobs create spool lists that can be viewed by using the usual R/3 functionality. The management data displayed in Transaction SARA provides, for example, information on the size and location of archive files, and the number of data records contained in each archive file. The net graphic provides an overview of dependencies between various archiving objects and a plan for ordering your archiving. For example, you must not archive customer master records until all FI documents belonging to this customer have been archived. Follow this plan when archiving data.
2-330
BC360
Error Handling
Termination due to:
External problems result in term ination of the background process An archive file exists with the same name File system is full, archiving directory not available
Terminated archiving runs can be executed again
SAP AG
There are three possible outcomes of a data archiving run: All the data is successfully archived Data archiving is terminated due to an error before the files are deleted One or more of the delete runs are terminated Bear in mind that several archive files are written during an archiving run. For each archive file, a delete job is started. If an error occurs, proceed as follows, no matter what prompted the termination of the run: If an archive file cannot be fully written, back up the completed archive files and delete the partially written ones. Then restart the archiving run to archive the remaining data that was not written and deleted. If all the archive files are written, but the delete jobs are not processed or are only partially processed, restart the delete jobs manually. If the write job is terminated and delete jobs are configured to start manually, you can delete archive files that were fully written before termination, then restart the archiving run.
2-331
BC360
Authorizations
S_ARCHIVE
Adjust for each archiving object Archive Read Reload (if available)
Application authorization
Read docum entation M M_M ATBEL Plant authorization (For which plants am I authorized to archive data?)
Background job authorization

R
SAP AG
S_ARCHIVE is the main authorization object used for data archiving. Specify in S_ARCHIVE exactly which archiving objects are to be processed and which options are to be used. To ensure that maximum amounts of data are archived, you also need appropriate authorizations from the application where the data is produced. To find these authorizations, read, for example, documentation on the archiving object MM_MATBEL (Material documents). This documentation is accessed through "Info" in Transaction SARA. Because data archiving runs in the background, you also need authorization for creating background jobs.
2-332
BC360

Explain the need for data archiving Prepare the system for an archiving run Customize an archiving object Start and m onitor an archiving run (in conjunction with the business departm ent) Check the results
SAP AG
Successful archiving depends on a number of factors: Cooperation between the business departments and the system administrators A thorough knowledge of the available documentation, for example Online Help Info in Transaction SARA OSS Notes Availability of sufficient background work processes Optimal modifications during Customizing Well-organized storage for archive files
2-333
BC360
Unit Actions
Do the exercises
Solutions for the exercises
SAP AG
2-334
BC360
No. 1 1.1 1.2
Exercise Archiving data (optional) Call Transaction SARA, enter the object US_PASS, then display the net graphic. Customize this object using the following values: Size: 10 MB # of objects given by your trainer: (Ex. 5) To start the delete program automatically, check the box Automatic start Commit: 500 Define two variants for the delete program Choose Archive, then define a variant for this special archiving run. Set Archiving to run in the background. Call Transaction SM37 to control the background jobs. View spool lists and job protocols. Find documentation (optional) Select the object MM_Matbel, and find out the name of the delete program used. Use Transaction DB15 to see the tables in which the delete program is set to delete data.
1.3 1.4 2 2.1 2.2
2-335
BC360
No. 1) 1.1 1.2 1.3 1.4 2) 2.1 2.2
Solution
Call the transaction, or use the menu path provided in the presentation. (PP.5, 9) Choose Customizing --> Tech. Settings, and set parameters to the values given.
Check in unit "Background processing" for instructions on how to handle Transaction SM37.
Enter the name of the archiving object in Transaction SARA, choose Archiving, activate the Info button, then choose the hyperlink to Program documentation. Using Transaction DB15, choose Table --> Object, enter the name of the archiving object, activate Tables with deletion. Then Show Objects.
2-336
BC360

CBT SAP R/3 3.0 Archive M anagement Archiving Applications Online Documentation Info in Transaction SARA OSS Notes: BC- CCM- ADK, BC- SRV- ARL 53030 Online archiving versus data integrity 53062 Database reorganization and R/3 archiving 53064 W hat is important when reloading from archives? 89324 Archiving: Revised ADK versions ( Read this before reloading data)
R
SAP AG
2-337
BC360
Appendix: Check List for Data Archiving I

Archiving processes Before using a particular archiving object for the first tim e Agree on a strategy with business departm ent Check dependencies Check applicationspecific custom izing Check ADK custom izing
Platform indep. file names Size of archive files ArchiveLink installation (opt.) Settings for delete program
SAP AG
R
Before the first archiving
For each archiving run
Agree on a strategy with business departm ent Check dependencies
Agree on a strategy with business departm ent Make disk space available Schedule archiving run Check archiving run Back up archive files
This appendix outlines general procedures to follow when archiving. Before the 1st data archiving session, check the general customizing: Check whether the logical file names are maintained. If you are using ArchiveLink, check whether the settings are maintained. Before using a particular archiving object for the first time, check the archiving object-specific customizing (ADK): Check whether the file name is correctly assigned. If you are using ArchiveLink, check whether the document type has been assigned. Maintain the delete program variants (N.B. the variants are client-dependent) Check whether the archive file size is correctly set. Check whether the delete program is called automatically.
2-338
BC360
Appendix: Check List for Data Archiving II

Archiving Processes Before using a particular archiving object for the first tim e Agree on a strategy with business departm ent Check dependencies Check applicationspecific custom izing Check ADK custom izing
Platform indep. file names Size of archive files ArchiveLink installation (opt.) Settings for delete program
SAP AG
R
Before the first archiving
For each archiving run
Agree on a strategy with business departm ent Check dependencies
Agree on a strategy with business departm ent Make disk space available Schedule archiving run Check archiving run Back up archive files
Follow the procedures outlined below for each data archiving session: Coordinate the activities of application and system management. Check in the net graphic to see if dependencies exist and whether other archiving objects must be archived first. Schedule the data archiving session (maintain variants). If the delete program is not called automatically, call the delete program manually. If archive files are to be stored using ArchiveLink, call the storage manually. If the storage is manual - Copy archive files to tape. - Note the name of the tape in archive management.
2-339
BC360
System Monitoring
System Monitoring
SAP AG
2-340
BC360
System Monitoring
System Monitoring
Contents:
Alert Monitor 4.0 Alert Monitor configuration Alert Monitor handling
Objectives:
At the end of this unit you will be able to: Explain the Alert Monitor Customize the Alert Monitor Configure your own Alert Monitor Handle alerts
SAP AG
The Alert Monitor is a comprehensive performance analysis and availabilility tool for analyzing the R/3 System workload. It is supplied by the R/3 Computing Center Management System (CCMS). This unit describes the architecture of the R/3 System and explains which components are critical for obtaining good overall system performance. Detailed instructions for using the Alert Monitor are provided, so that after completing this unit, participants will be able to monitor their own system. Configuration details are also covered.
2-341
BC360
System Monitoring
Course Roadmap
DBA Backup
DBA - Daily Check
Start and Stop
System M onitoring
User Adm inistration Installation Check Archiving
Software Logistics Spooling and Printing
SAP AG
2-342
BC360
System Monitoring
Monitoring in SAP R/3 4.0: PART 1
Basis Development ( Basic monitor ) M onitoring Edit Goto Views Extras System Help View: Open alerts ( 30.03.1998 , 10:22:26 )
SAP domain
rc h r in g A o o n it M
4 4 4
C11 TC1 Self-monitoring
tu re it e c
SAP AG
2-343
BC360
System Monitoring
Monitoring: W hat, W hy, W ho and W hen?

W hat? Components in R/3:
R/3 (application servers, buffers, applications )
W hy?
Keep the system running Im prove performance
W ho?
Database: (performance, backup, ) Administrators
Operating system: (CPU, file system, )
W hen?
Periodically
11 10 9 8 7 6 5 4
12
1 2 3
SAP AG
The R/3 System consists of many software and hardware components that contribute to the overall availability and performance of your R/3 installation. These components include the operating system which comprises for example the CPU, the physical memory and the disks. The next major components are the database, the R/3 buffers and R/3 services (dialog, update, enqueue, spool...). All these components must be monitored regularly. The main goals of system monitoring are as follows: To keep the system running To analyze and correct errors To improve performance and thus increase user acceptance of R/3 System monitoring is performed by different persons depending on their area of responsibility: R/3 System administrators are responsible for assuring the performance of R/3 Database administrators are responsible for assuring the consistency of the database and for restoring the database if a database inconsistency or database loss occurs Operating system administrators are responsible for providing physical storage media The R/3 System should be monitored regularly at least once a day. However, SAP recommends more frequent monitoring than this, depending on the size of the installation.
2-344
BC360
System Monitoring
Concept of Monitoring in R/3 4.0 (I)

<SID> <SID> <SID> <SID> SD SD Transport Transport <host>_<SID>_<No> <host>_<SID>_<No> Database Database
Backup Backup Operating Syst. Operating Syst.
Performance Performance
Disk Disk
CPU CPU
Buffers Buffers
All objects summarized in one tree Display history and present state, especially alerts
CPU idle % CPU idle %
Assign tools for Analyzing Reaction to alerts Data collection
SAP AG
As of R/3 release 4.0, all objects to be monitored are summarized in one tree, which displays all the information necessary for monitoring and maintaining your system. Each component is represented by a monitoring object. These objects have different attributes, for example, CPU utilization is an attribute of the object CPU, and the buffer hit ratio is an attribute of the object buffer. Use this information to display the current status of your system or to analyze its history and any alerts that occur. In addition to displaying the status of your system, you can also assign tools to specific monitoring objects. These tools may respond to alert situations, e.g. send e-mail, or help you to analyze the alert. Several R/3 systems can be displayed in one tree. In future releases, this monitoring infrastructure will also enable you to observe transports in your transport landscape and to monitor application transactions. The monitoring infrastructure is implemented in C and offers C and ABAP interfacesfor adding new Monitoring Tree Elements. This means that external providers can also embed their objects or tools in the monitoring tree.
2-345
BC360
System Monitoring
Concept of Monitoring in R/3 4.0 (II)

<SID> <SID>
Monitoring Tree elements M onitoring Tree elements Monitoring Tree elem ents Monitoring Tree elem ents
<host>_<SID>_<No> <host>_<SID>_<No>
All nodes All nodes in the tree in the tree
Represent one physical or logical object

Operating Syst. Operating Syst.
Monitoring objects Monitoring objects

CPU CPU
Disk Disk
Summ arize alerts and propagate to higher nodes Receive data and may create alerts Use data for Analysis Alerts
CPU idle % CPU idle %
Monitoring attributes Monitoring attributes
SAP AG
The monitoring tree in R/3 introduces some new terminology: The term monitoring tree element (MTE) is used to denote any node in the tree. Monitoring objects are special nodes in the tree which represent physical or logical objects such as the CPU or the R/3 dialog service. Each monitoring object is related to one or more nodes called monitoring attributes which hold the data for one special property of the object. For example, the monitoring object CPU may point to the attributes CPU utilization and CPU queue length. Depending on the data the attribute can hold, you should distinguish between: Performance attributes Message attributes (single or container) Heartbeat attributes Text attributes To study the interaction of these components, consider the following example: In a given system, the CPU utilization exceeds one predefined threshold. The corresponding data is collected in the monitoring attribute CPU utilization. Tools designed to analyze the alert work with the data in this attribute. The alert itself is sent to the monitoring object CPU and then propagated to higher nodes according to its priority rating. This method ensures that the top node of the tree always indicates the most important alert.
2-346
BC360
System Monitoring
Preparing the Monitor (I): Customizing

MTE class
O p.Syst .
General customizing: Messages Visibility
Disk
CPU
Alert priority
CPU idle %
Gen. Key
Program
Type specific custom izing, e.g. performance attribute: Value for thresholds When to create alert Alert text
Hit ratio
Hit ratio
Customizing group
SAP AG
To determine the definition and appearance of the alerts and to ensure efficient use of the monitor, you must perform a number of preparations. For each MTE class except those of virtual MTEs, you can customize the following: Description Level of visibility (operator, administrator,) Alert priority These settings then become valid for all MTEs assigned to this class. By grouping MTEs in classes, you avoid having to make the same settings for each element. Monitoring attributes that logically belong together are grouped together in customizing groups. To customize groups, set the following: Thresholds for the alerts Creation mode (for example, when the actual value exceeds the threshold) Alert text (if needed) Customizing groups are either performance groups with performance specific settings or single message groups, depending on the different types of attributes comprising the group.
2-347
BC360
System Monitoring
Preparing the Monitor (II): Tool Assignm ent

M TE class
Op.Syst .
Assign tools via MTE class to all related MTEs for: Collecting data
Disk
CPU
Analyzing alerts Reaction to alerts (OnAlert tool)
CPU idle %
O p.Syst .
Disk
CPU
Override MTE class tool settings for an individual M TE
CPU idle %
SAP AG
After configuring your alerts, you can assign tools to the MTEs. These tools may be used for collecting data in cases when the underlying actual component does not generate data accessible to the R/3 System, for example the CPU. Other types of tools are used for reaction to alerts or for analyzing the alert. Tool assignment may be defined as follows: At the MTE class level By defining tools for an entire MTE class, you can ensure that those tools are assigned to all MTEs belonging to this class. By inheriting tools from a parent class. This functionality saves you a lot of work by enabling you to define a consistent tool environment for all MTEs belonging to one sub tree. Inheritance is the default setting. For a single MTE To assign tools to an individual MTE, you must override settings derived from the MTE class using MTE specific tools.
2-348
BC360
System Monitoring
Tool Assignment: Process

STEP 1: Define tool and specify
Type (report, function module, transaction, ) Location (arbitrary server, database server, ) Operation modus (background, manually, )
STEP 2: Release tool for specific purpose STEP 3: Assign tool to M TE class or individual MTE
Enter the tool directly Use inheritance from MTE classes Define no tool at all
SAP AG
Tools are predefined. To assign new tools to MTE classes or directly to an MTE, perform the following steps: Define the tool, specifying Type of tool: For example, report, function module, transaction, or logical commands Start location: For example, on which server the tool should run Operation mode: For example, whether the tool is to run in the background or be started manually Release the tool for This means, for example, that the same transaction can be used for its specific purposes alert response and alert analysis if you release it for each of these tasks separately. Assign the tool to an You can decide to specify the tool directly or to use inheritance MTE class or to a as described above single MTE You can also decide to assign no tools to the MTEs. The tools predefined by SAP have the prefix CCMS. Customers should use Y and Z as name range for own created tools.
2-349
BC360
System Monitoring
Using the Monitor: Basic Monitor

Switch view: Current status <-> Open alerts
Basis Development ( Basic monitor ) Current status Display alerts Complete alerts Custom izing
View: Open alerts ( 30.03.1998 , 15:37:08 ) SAP domain 4 5 5 4 4 4 5 5

C11
Virtual m onitoring tree element

pswdf694_TC1_00
OperatingSystem DatabaseClient R3Services
TC1
Monitoring summ ary
R3BasisSystem Buffers 4 4 5
Program SingleRecord
Monitoring object Monitoring attribute: Type perform ance

51 % < 60 % 15 min. mean value
Propagation of highest alert
GenericKey
DirectoryUsed SpaceUsed
HitRatio
SAP AG
In R/3 Release 4.0, you can work with many monitoring trees. They are summarized in monitor collections. Each monitor collection involves at least the basic monitor, which consists of all monitoring objects of the R/3 system. In every monitor you can switch between a display of the current status of the system and the open alert view. In the open alert view, the most important alert is propagated to higher nodes. This enables you to find the most critical situation immediately without expanding the whole tree. In the example shown here, the bad-hit ratio for the Generic Key buffer is passed to the highest node. In case of alerts (marked red) and warnings (marked yellow), you find next to the monitoring attribute the short alert text which indicates that an error occurred. You can also display the alert history of this node and a more detailed view of the attribute. After selecting one monitoring attribute, you can branch to the customizing for this attribute or call the corresponding analysis tool.
2-350
BC360
System Monitoring
Using the Monitor: Creating your own Monitor

M onitor design ( <<< New m onitor >>> ) 5
TC1
5
pswdf694_TC1_00
4 4 4 5
OperatingSyst DatabaseClient R3Services R3BasisSystem

5
Select parts of the tree, according to your: Role Situation Save the new m onitor
TraceSwitches R3DeveloperTrace R3SystemTrace
4 5
MemoryManagement Buffers
4 4 5
Program SingleRecord GenericKey DirectoryUsed SpaceUsed HitRatio
SAP AG
The basic monitor generally includes too many objects to suit your specific needs. For example, a database administrator may not be interested in details concerning a particular R/3 service, or you may need to create monitors adapted to a special situation such as an upgrade. To suit your specific needs, you can create your own monitor. This monitor belongs to the monitor collection in which it is created. Technically speaking, the new monitor consists of a subset of MTE's taken from the basic monitor. To create a new monitor, select the desired MTEs and save the new tree. All customizing and assigned tools are also copied during this process. Since you can define the visibility of your own monitors, they are also suitable for operators or developers who need to see only a limited amount of information about their system. When working with two or more monitors, you can switch quickly and easily between them without leaving the monitoring infrastructure.
2-351
BC360
System Monitoring
Monitoring in SAP R/3 4.0: PART 2
Process
CPU
No 0 1 2 3 4 5 6 7
r in g n ito o al M and p e c i e c ts S o o ls O b j n d in g T espo c o rr

Program Overview of Processes User session Edit Goto System
Debugging Detail info
Help
Refresh
Delete session
Type
PID 42 43 44 45 46 47 48 49
Status run wait run wait wait run wait wait
...
Report
User
...
DIA DIA DIA UPD UPD2 ENQ BTC SPO
RSMON00
RFEBEL05
M eyer Sm ith M iller
RM SDCA02
sapbatch
SAP AG
The monitoring architecture provides a framework for plugging in monitoring functionality quickly and easily.
2-352
BC360
System Monitoring
R/3 Syslog
Basis Development ( Basic monitor ) Current status Display alerts Complete alerts
Transaction SM 21 Syslog displays data showing the history of your R/3 System
View: Open alerts ( 30.03.1998 , 15:37:08 ) 5
TC1
5
pswdf694_TC1_00
4 4 4 4 4 5
OperatingSyst DatabaseClient R3Services R3BasisSystem R/3 ABAP R/3 Syslog SyslogID SyslogFreq
SAP AG
In the alert monitor, every application server is displayed separately. All application servers have the same structure. They are divided into the following parts: Operating system Database R/3 services (R/3 work processes) R/3 basis system, where the buffers and memory management are contained R/3 ABAP R/3 System log, where important messages are collected The R/3 System log provides information about these different parts of your R/3 System.
2-353
BC360
System Monitoring
R/3 Syslog: Details

Local log file message 1 Local log file message 2
Application server 1
rslgsend
rslgsend
Unix only!
Local log file
Central log file
rslgcoll
message x
rslgsend
Central instance
SAP AG
The system log contains information about the R/3 System, which is categorized as follows into problem classes: S Start and stop the R/3 System and the work processes Operation mode switches W Rollbacks performed K Kernel program errors T ABAP transaction errors resulting in short dumps The information shows the timestamp, client, user, transaction code, and a short text. The work process which caused the message is also displayed. The system log must be monitored separately for each application server. You can collect the system log in a central log in UNIX systems only.
2-354
BC360
System Monitoring
R/3 Services
View: Open alerts ( 30.03.1998 , 15:37:08 ) 5
Provides an overview of users, work processes, and services in R/3
TC1
5
pswdf694_TC1_00
4 4 5 4 4 4 4 4 4 4 4 4
OperatingSyst DatabaseClient R3Services Gateway_Summary Dialog Background Update Spool Enqueue StatisticRecords R3BasisSystem R/3 ABAP
Transactions SM 51 SM 50 SM 66 SM 04 AL08 SM 12 SM 13 ST22 ST03 SM LG
SAP AG
The MTE R3Services provides an overview of all R/3 work processes. Background and spool processes are discussed in later units. More detailed information about the following three work process types together with their related transactions is provided later in this unit: Dialog Update Enqueue
2-355
BC360
System Monitoring
Monitoring: R/3 Servers

SM51
Information Instance names Types of work process Application server 2 Q ueue information ...
. . .
Application server x
Action Change your current application server ...
SAP AG
Transaction SM51 provides you with an overview of available servers. You can use this transaction to Examine the processes of the server you are logged in Display the users of the system Display the system log Display the OS collector state Dynamically switch to another server Release Notes in this transaction shows R/3 kernel release R/3 release Database release OS release
2-356
BC360
System Monitoring
Monitoring: R/3 W ork Processes
Application Server 1
Dispatcher D D V E B S
SM50/SM66
Information W P type and status Detail Info CPU time ... Action SM66 Stop and start W P Debugging / Trace ...
SM50
. . .
Application Server x
Dispatcher D D D D B B
SM50
SAP AG
Transactions SM50 and SM66 provide an overview of the work processes on the application server you are currently logged on to, or the whole R/3 system. Within these screens, the type of work process, its status, time consumption, current user and client are displayed.
2-357
BC360
System Monitoring
Monitoring: R/3 Users
Application Server 1
SM04/AL08
Information User
SM04
Info / Location Sessions AL08 ... Action Delete user Trace ...
. . .
Application Server x
SM04
SAP AG
You can also get an overview of users on a specific server, or of all the users in the R/3 System.
2-358
BC360
System Monitoring
Update Processing (I)

Dialog server Dispatcher Enqueue server Dispatcher
...
D-WP 1
M essage server
V-W P
E-W P
...
Lock table in m ain m em ory
VB*
SAP AG
DB
Locking mechanisms on relational database systems cannot be used for complicated business objects, such as delivery orders located in several tables. To coordinate parallel access to this business object data in an R/3 System, the enqueue work process is used. The locks (=enqueues) are handled by the enqueue work process in a lock table in main memory on the server where the enqueue process is running. When a lock is requested, the lock table is checked for an entry of this data set. If there is already an entry of this type, the request is rejected and the user notified. If the dialog and enqueue work process are not located on the same server, communication is enabled by the message server. For every business data object, a lock object is defined in the ABAP dictionary. The customer name range for an lock object must start with EY or EZ. A lock object can have the mode S (shared lock) for read access, or E (exclusive lock) for write access. An update in R/3 is usually executed asynchronously. This means that the update information is written into a set of tables (VBMOD, VBHDR, VBDATA...) and updated from there when the transaction has finished. The update process can be performed in several steps for V1 and V2 updates. V1 updates are time critical, V2 updates are non-time critical, as for example a statistics update.
2-359
BC360
System Monitoring
Update Processing (II)

Dialog server Dispatcher Enqueue server Dispatcher
...
D-WP
COM MIT W ORK
V-W P 6
E-W P
...
M essage Message server
Lock table in m ain m em ory
5 4
VB*
SAP AG
DB
An update is triggered at the end of an SAP transaction by a COMMIT WORK. This is done explicitly in the coding or implicitly at the end of an SAP transaction by default. The update work process reads the data from the VB* tables and executes the updates in the corresponding tables of the R/3 database. Once the update is successfully completed, the entries in the VB* tables and in the lock table are deleted. If an error occurs, the lock table entry is deleted, but the entries in the VB* tables are not deleted. The user is notified immediately by an express mail. Depending on the business data object, the entry may be reposted. Note: The asynchronous update is implemented by the ABAP key word Call function .... in update task. You can also update the database synchronously inside a dialog service, but you should use this synchronous or "hard" update for special cases only.
2-360
BC360
System Monitoring
Monitoring: R/3 Locks

Dispatcher
SM12 V-W P E-W P .... . .

Information Locked tables Lock holder Lock table in main m emory Lock type / Lock area ... Aktion Delete locks Test enqueue ...
SAP AG
To display the current database locks, call Transaction SM12. This transaction provides information about: The user that has initiated the lock The client of this user The table that has been locked The lock argument. After careful investigation and error analysis performed together with the user holding the lock, you can delete the lock entry. Before deletion, consider the following: Is the user who holds the lock really using the transaction? Has the user started an update transaction and then left the computer? Is it a long-running transaction with several locks? Has the lock not been released due to a terminated update?
2-361
BC360
System Monitoring
Monitoring: Asynchronous Update

SM13
Information Is updating active? Update modules Update data
DB
VB*
Error information Action Posting Test posting Start update
SAP AG
To display terminated updates, call Transaction SM13. SAP does NOT recommend "posting" or repeating the transaction when using Transaction SM13 for V1 updates. SAP recommends that you restart the transaction after you have solved the problem that caused the original update error. SAP recommends that you post aborted V2 updates using Transaction SM13, but only if the corresponding V1 update was successful.
2-362
BC360
System Monitoring
Monitoring: ABAP Dumps
ABAP runtime errors SYNTAX_ERROR Occurred on 16.04.1998 at 00:00:33 1 W hat happened?

The following syntax error occurred in the program SAPLSTUW : "No component exists with the name "OBJ_NAM E", but there is a component with the similar name "TAB_NAME". " The current ABAP/4 program "RSSTAT83 " had to be terminated because one of the statements could not be executed. This is probably due to an error in the ABAP/4 program.
ST22
Information W hat happened where? Termination point in code W hat to do?
2 3 4 ...
W hat can you do? Error analysis How to correct the error
SAP AG
If you receive an error message in the R/3 System log, or if you see a terminated update in the update service analysis transaction, check for dumps using the dump analysis transaction: Use Transaction ST22, or choose Tools Administration Monitoring Dump analysis This transaction lets you analyze short dumps from the current and previous day. The dump analysis function shows you What happened What you can do How to correct the error The dump analysis function also provides information you can use for searching in the OSS, as well as information about: The system environment Users and transactions You can analyze the following data: Date, time, user, client Contents of system and data fields Contents of internal tables and application tables
2-363
BC360
System Monitoring
Time Definitions for a Dialog Step

SGA
1 1 3
Task Handler Dynpro Processor ABAP Processor DB Interface

6
D-WP
DBBP
Dispatcher
Network
Network
SAPGUI
Proces8 sing Tim e
7 7
R/3 Buffer
Database Wait Time Roll Time Load Time

2 4 5
Request Q ueue
User Context
PXA Buffer
DB Request Time Response Time
SAP AG
Once you have established a connection from your SAPgui with a dispatcher, and processing has started in the system, the following steps are triggered: Data is transferred with the SAPgui protocol through TCP/IP to the dispatcher. The dispatcher classifies the request and places it in the appropriate request queue. The request is passed in order of receipt to a free dialog work process. The task handler (which, like the following processes mentioned here, is a sub process of the work process) executes the recovery of the user context. This step is called a Roll In. The user context contains, for example, data on sessions still running for this user and its authorizations. The task handler calls the dynpro processor, which converts the screen data into ABAP variables. The ABAP processor processes the code for the Process after Input module (PAI) of the preceding screens, along with the Process before Output module (PBO) of the following screen, and communicates, if necessary, with the database. The dynpro processor reconverts the ABAP variables into dynpro fields. When the dynpro processor has completed processing, the task handler is reactivated. The current user context is stored by the task handler in shared memory (Roll Out). Resulting data is passed back through the dispatcher to the front end.
2-364
BC360
System Monitoring
Monitoring: W orkload Analysis
ST03
Information Response time
Task handler Dispatcher D ynpro P rocessor A BA P Processor D B-SS
DB request time Load time

11 10 9 8 7 6 5 4
12
. . .
1 2 3
SAP AG
The Workload Monitor displays detailed information about the work processes on the different application servers. The information can be split up for different types of work processes and contains data such as: Average response time Average DB request time Number of steps Roll in and roll out time Average wait time For more detailed information, investigate the following: Transactions or reports with top times Time profile Memory profile
2-365
BC360
System Monitoring
Logon Groups
Message server
Group B
Gr. A: AS 2,3 Gr. B: AS 1,2 Action
SAP Logon
SMLG
Define logon groups
Group A Group B
Database
SAP AG
Transaction SMLG enables you to create logon groups. After you have defined the logon groups, logon load balancing can be switched on. This enables you to allocate less memory, because with logon load balancing you only need buffers for a certain group of programs and tables on each server. For example, you may only need buffers for SD data and programs.
2-366
BC360
System Monitoring
R/3 Basis System

Transaction ST02 Provides you with inform ation concerning the status of the buffers and system mem ory m anagement
View: Open alerts ( 30.03.1998 , 15:37:08 ) 5
TC1
5
pswdf694_TC1_00
4 4 4 5
OperatingSyst DatabaseClient R3Services R3BasisSystem

4 4 4
TraceSwitches MemoryManagement Buffers
4 4
R/3 ABAP R/3 Syslog
SAP AG
R/3 memory management defines the usage of main memory for the R/3 work processes. The R/3 buffers play a key role in system performance. It is essential to provide optimal settings for these buffers.
2-367
BC360
System Monitoring
W ork Process Multiplexing

1
R/3 User
2
R/3 User
3
R/3 User
4
R/3 User
Dialog W ork Process 1
Roll
Roll
Dialog W ork Process 2
Paging
Paging
Extended m em ory memory (shared)
Swap
SAP AG
In an R/3 System, the SAP front end, the SAPGUI, is connected to the dispatcher of an application server. The dispatcher sequentially distributes requests generated by user input to available work processes. A single work process normally handles the requests of several users, since there are normally more users than work processes. The work process uses data that is specific to the particular user, such as internal tables, or lists. User-specific data is called a user context. User contexts are stored in user-specific memory accessible from each work process. User-specific memory is a common resource implemented either as shared memory or as a file. After processing a request, the work process rolls out the current user context. Thus, the user context is saved and made inaccessible to that work process. This enables a different work process to roll in the same user context for a new request. A user context is uniquely related to one work process at a time. A work process dispatch is when a user context is rolled out of one work process and rolled in to another work process.
2-368
BC360
System Monitoring
Memory Management
ztta/roll_first
DIA Roll
BTC/UPD
ztta/roll_area
Roll
abap/heap_area_dia
Local memory
abap/heaplimit
Local memory
abap/heap_area_nondia
abap/heap_area_total
ztta/roll_extension
em/initial_size_MB
Extended m em ory memory (shared)
SAP AG
Different types of user-specific memory are allocated to dialog work processes in the following order: Roll area Extended memory Remaining portion of roll area Note: Once the system can no longer allocate extended memory and the roll area has been filled up, the work process allocates private memory and changes its own status to PRIV mode after the current dialog step finishes. Non-dialog work processes such as background and update work processes do not need to switch user contexts. They do not utilize mapping instead of copying, and they allocate memory in the following order: Roll area memory Private memory Extended memory
2-369
BC360
System Monitoring
Monitoring: Buffers
ST02
Information Buffer quality
Table buffer
Swaps SAP memory
. . .
Name tab
PXA buffer
...
SAP AG
Transaction ST02 displays buffer statistics of all important R/3 buffers. Statistics displayed by this transaction include, for example: Hit ratio Allocated space Remaining free space Swaps Transaction ST02 displays the following R/3 buffers: Nametab buffers Program, CUA, screen and calendar buffer Table buffers Roll and page buffers are also displayed, along with extended memory and heap memory. For more detailed information, choose Detail Analysis Menu.
2-370
BC360
System Monitoring
Buffer Synchronization
rdisp/bufrefm ode = sendon exeauto sendoff exeoff
insert
Select from DDLOG 60 s
DDLOG
SAP AG
If you have several application servers that buffer the same table, the servers must be synchronized to ensure consistency when inserts or table updates are executed. The parameter that guarantees the synchronization is rdisp/bufrefmode. It should be set to sendon/exeauto, if the system consists of more than one application server. The standard refresh time is 60 seconds. To change this to a different time period, set the parameter rdisp/bufreftime. Transports are also written into DDLOG. Therefore, even in a central system the parameter rdisp/bufrefmode should be set to sendoff/exeauto.
2-371
BC360
System Monitoring
Database Monitoring
Transaction ST04 Provides you with inform ation about the status and performance of the database.
View: Open alerts ( 30.03.1998 , 15:37:08 ) 5
TC1
5
pswdf694_TC1_00
4 5
OperatingSystem DatabaseClient
4
AbapSql
4 4 4 4
R3Services R3BasisSystem R/3 ABAP R/3 Syslog
SAP AG
The database also has a significant effect on system performance. To monitor the database, use Transaction ST04, which is the standard tool for observing database behavior.
2-372
BC360
System Monitoring
Monitoring: Database
ST04
Database server Database buffer pool Information
SGA
DBWR LGWR ARCH CKPT PMON SMON
Hit ratio Statistics / History File system - I/O Expensive selects
Shared pool
Redolog buffer
Shadow Shadow Shadow
DB Alertlog ... ...
SAP AG
Within Transaction ST04, you can display the data buffer size and quality, or hit ratio. The shared pool size and ist quality is also displayed. In Detail Analysis Menu, you can investigate in depth other issues, such as: Buffer busy waits File system requests Wait events SQL requests Exclusive lock waits Latch waits V$ values Parameter changes
2-373
BC360
System Monitoring
Operating System
Transaction ST06 Provides you with inform ation about the operating system of the hosts where the R/3 instances reside.
View: Open alerts ( 30.03.1998 , 15:37:08 ) 5
TC1
5
pswdf694_TC1_00
5
OperatingSystem
4 4 4 4 4
Filesystems CPU Paging Swap_Space OS_Collector
4 4 4 4 4
DatabaseClient R3Services R3BasisSystem R/3 ABAP R/3 Syslog
SAP AG
To investigate the operating system, use Transaction ST06. This transaction displays CPU utilization, page rates and some disk statistics. For more information about the operating system, choose Detail Analysis Menu.
2-374
BC360
System Monitoring
Monitoring: Operating System

ST06
Application server 1 Information CPU Disk Application server 2 Physical memory
. . .
SAP AG
To monitor the file systems, use the tool RSHOST10. RSHOST10 displays CPU utilization and swap space usage in the main screen. To analyze the capacity and free space in the system, choose Detail analysis menu. Then select Filesystem for Previous hours. To analyze the paging rates of the system, choose Detail analysis menu. Then select Memory for Previous hours To analyze the status, startup time and the details of the OS collector, choose OS Collector. You can also start and stop the OS collector in this screen.
2-375
BC360
System Monitoring
Problem Analysis
(Average) Performance problem ? Yes All users affected ? No Which is bad ? CPU time CPU tim e << Process time (Network tim e) time) (Continued) Wait time W ait
Check Workload on all servers
ABAP or SQL trace
Load time DB request tim e time
SAP AG
Once a problem is detected, the information provided by the workload analysis monitor must be interpreted to determine where the problem lies.
2-376
BC360
System Monitoring
Problem Analysis (Continued)

(Average) CPU tim e time CPU time << Process time (Network time) tim e) Wait time Am ount of tim e occupying the work process
I/O bottleneck Network problems
Configuration problem - Not enough work processes Long running transactions - All work processes busy Configuration problem - R/3 buffers too small Installation problem - M issing indexes DB server CPU has heavy workload More mem ory needed in DB server Too m any disk sorts - Missing indexes
Load tim e time DB request time tim e

SAP AG
Some of the more common problems are best dealt with through the statistics tables.
2-377
BC360
System Monitoring
ABAP Programs for Checks and Cleanup

RSBTCDEL RSPO0041 RSPO0043 RSBDCREO RSSNAPDL RSSTAT60 RSORA811 RSORASNP RSCOLL00
Delete background logs Delete old spool requests
C heck consistency of spool database

Reorganize BI folders and logs Delete ABAP/4 short dumps Reorganize table MONI Delete old brbackup/brarchive Reorganize the SNAP & STAT$ logs Delete OS collector logs
SAP AG
SAP recommends that you schedule these reports to run daily. This is a list of some of the ABAP cleanup programs available. For the physical reorganization of the database, you may need other programs at OS level, such as sapdba.
2-378
BC360
System Monitoring

Define an alert monitor Custom ize an alert monitor Define and assign tools Handle the alerts
SAP AG
2-379
BC360
System Monitoring
Unit Actions
Do the Exercises
Solutions for the Exercises Answer the Questions
SAP AG
2-380
BC360
No. 1 1.1
Exercise Monitoring views Go to the Alert Monitor (4.0) and open the basic monitor. Show the open alerts and display them all.
1.2 1.3 2 2.1
Show the current status and display the alerts. Complete one alert. What happened in the monitor? What happened in the system? View levels Open the monitor in two further sessions. Expand the trees. For each monitor choose a different level. Compare the trees. Note an MTE that is not visible at the operator level. Basic Monitor Show an example of each of the four different types of MTEs. Which types of MTEs are assigned to a Monitoring Tree class? Customizing Monitoring Tree classes Customize the Monitoring Tree class of the MTE of example 2.1, in such a way that it is visible at the operator view level. Check this setting. Customizing Monitoring Groups Diminish the threshold values for the answer time of dialog work processes by 0.5 seconds in each alert value. Tools Create a tool ZZTCC_SM04 with Transaction SM04 as tool, then create a tool ZZTCC_SM13 with Transaction SM13 as tool. Release the tools as analysis tools . Check the tool release. Assign the tool ZZTCC_SM13 to the update work processes and the tool ZZTCC_SM04 to the UsersLoggedIn. Create a new monitor Create a monitor for the R/3 services Update work process
3 3.1 3.2 4 4.1 4.2 5 5.1 6 6.1
6.2 6.3 6.4 7 7.1 8
2-381
BC360
8.1
Create an update error using the ABAP report VBTST300. As OPCODE enter I. Execute this twice. What does the express mail say? Where can you get more detailed information on the error?
8.2
2-382
BC360
No. 1 1.1
Solution Monitoring views Tools --> CCMS --> Alert monitor (4.0) --> Basic Monitor or RZ20 --> Basic Monitor. Select the whole tree (it is enough to select the highest node of the tree) and choose Display Alerts.
1.2 1.3 2 2.1 3 3.1 3.2 4 4.1
Choose Current Status and Display Alerts. The alert turned to green. The cause of the alert did not disappear. View levels Extras --> Display options. Basic Monitor The four types are the virtual MTE, the Monitoring Summary, the Monitoring object and the Monitoring attribute. All but the virtual MTEs. Customizing Monitoring Tree classes For example, R3DialogProblems is an MT class that is not visible at the operator view level. Choose R3Services --> Dialog --> Problems. Click the check button. Choose Customize Choose General settings and go to the change mode. Set Visible for user level to Monitoring. Access the monitor using Transaction RZ20. Double click the basic monitor, then select the view level for operators and go to the MTE. Then select another view level. Customizing Monitoring Groups Open the subtree R3Services --> Dialog --> ResponseTime. Choose Customize, then choose the change mode. Tools Select Tools --> CCMS --> Configuration --> Alert Monitor --> Sett./ Thresholds (4.0) or alternatively RZ21. Choose Tool definition and Display overview. Choose Create, enter ZZTCC_SM04 as tool name, SM04 as Call, select Transaction and save these settings. Repeat this for the other tool. Go to RZ21 and choose Tool definition and press Display overview. Choose the newly created tool, select List -> Selected entries --> Edit. Choose Tool release, choose the change mode, then select Analysis tool. Go to RZ21 and choose Tool release, then Display overview. Display the newly created tools in this list with attribute Released for as Analysis.
4.2
5 5.1
6 6.1
6.2
6.3
2-383
BC360
6.4
Go to RZ20, in the application server subtree select R3Services --> Update --> Update, choose Customizing, select Tools, choose Maintain tool assignment, select Analyze and choose Tools of the MTE class. Go to the change mode. In the definition field for Analysis tool, select Tool name, then from the pull down menu select the tool ZZTCC_SM13 and choose Enter. Save this setting. Repeat this for the subtree with the monitoring attribute UsersLoggedIn with the tool ZZTCC_SM04. Create a new monitor Select Tools -> CCMS -> Control/Monitoring -> Alert Monitor (4.0). Select any monitor. Choose Monitoring ->Create. Open the subtree of the application server and select R3Services. Save the new monitor and enter a name for it. Update work process Select Tools --> ABAP Workbench --> Development --> ABAP editor. Enter VBTST300 as Program. Once you have executed this report twice, you will be informed of the error with an express mail at your next action. It informs you about an broken update. Go to the system monitor, choose the update work process and display all alerts. Select an alert and choose Analyze. In the screen SM13 which appears now, choose Enter. Double click one of the entries shown in the list. Double click the resulting line and choose in the next screen ABAP short dump. The first line in the short dump explains that you tried to enter a record in a table where the key fields have the same values as an already existing record.
7 7.1
8 8.1
8.2
2-384
BC360
In the following, you will find excerpts from the Operation Manual, Chapter 9 System Monitoring, in the section Monitoring R/3. To perform these exercises, complete the tables in the excerpts as follows: 1 The table under Tasks. For your company, determine the activity group (person responsible), and the frequency with which each of the listed tasks should be performed for the production system <PRDSID>, the quality assurance system <QASSID>, and the development system <DEVSID>. Enter this information and the appropriate transaction for the task in the table (the first row is already completed to provide an example).
Tasks
Task Frequency <PRD <QAS <DEV SID> Using the basic monitor AR SID> AR SID> AR Tools CCMS Control/Monitoring Alert monitor(4.0) Creating your own alert monitor Tools CCMS Control/Monitoring Alert monitor(4.0) Configuring the alert monitor Remote monitoring Tools CCMS Configuration Alert monitor Sett./Threshold(4.0). Tools Administration Administration Network RFC destinations and Tools CCMS Configuration Alert monitor Sett./Thresh. (4.0) W: Weekly D: Daily <R3ADM>: System administrator M: Monthly Y: Yearly AR: As required RZ20 <R3ADM> Menu Path (NT or R/3) TransAction Activity Group
2-385
BC360
No. 1 1.1 1.2 1.3 1.3 2 2.1 2.2 2.3 2.4 3 3.1 3.2 3.3 3.4 4 4.1 4.2 4.3 4.4 5 5.1 5.2 5.3
True?
Question: Which parts of the monitoring tree can collect data? Virtual monitoring tree elements Monitoring objects Monitoring summary nodes Monitoring attributes What kind of tools do you use in the system monitoring? OnAlert tools (React to alerts) Data suppliers (Collect, average and evaluate data) Analysis tools (Analyze alert situations) Upgrade tools (Upgrade the R/3 system to a higher release) For which monitoring tree classes can thresholds be set? For monitoring tree classes of virtual monitoring tree elements For monitoring tree classes of monitoring objects For monitoring tree classes of monitoring summary nodes For monitoring tree classes of monitoring attributes Which monitoring tree classes can be customized? Monitoring tree classes of virtual monitoring tree elements Monitoring tree classes of monitoring objects Monitoring tree classes of monitoring summary nodes Monitoring tree classes of monitoring attributes When is an OnAlert tool executed? When you start the report SAPMSSY8 The next time all autoABAPs are triggered When you start the tool manually
2-386
BC360
2-387
BC360
No. 1 1.1 1.2 1.3 1.3 2 2.1 2.2 2.3 2.4 3 3.1 3.2 3.3 3.4 4 4.1 4.2 4.3 4.4 5 5.1 5.2 5.3
True?
Question: Which parts of the monitoring tree can collect data? Virtual monitoring tree elements Monitoring objects Monitoring summary nodes
Monitoring attributes What kind of tools do you use in the system monitoring?
X X X
OnAlert tools (React to alerts) Data suppliers (Collect, average and evaluate data) Analysis tools (Analyze alert situations) Upgrade tools (Upgrade the R/3 system to a higher release) For which monitoring tree classes can thresholds be set? For monitoring tree classes of virtual monitoring tree elements For monitoring tree classes of monitoring objects For monitoring tree classes of monitoring summary nodes
For monitoring tree classes of monitoring attributes Which monitoring tree classes can be customized? Monitoring tree classes of virtual monitoring tree elements
X X X
Monitoring tree classes of monitoring objects Monitoring tree classes of monitoring summary nodes Monitoring tree classes of monitoring attributes When is an OnAlert tool executed? When you start the report SAPMSSY8 The next time all autoABAPs are triggered When you start the tool manually
2-388
BC360
2-389
BC360
System Monitoring
Technical Core Competence Knowledge Product M onitoring Architecture Factsheet in SAPNet Online Documentation
SAP AG
The Factsheet Monitoring Architecture is available in the SAPNet under Information -> Media Center -> Media by Topic -> System Management -> CCMS -> Literature -> Monitoring Architecture.
2-390
BC360
Installation Check
Installation Check
SAP AG
2-391
BC360
Installation Check
Installation Check
Contents:
Operating System UNIX Installation requirements Operating system security and performance Database Oracle Installation requirements Database security and performance R/3 System Release and System name Basis parameters Directory structure Transport m anagement system Transport route configuration
SAP AG
R
2-392
BC360
Installation Check
Installation Check
Objectives:
At the end of this unit you will be able to: Check that the installation requirements are met Check that the minim um hardware requirements are met Check that the database requirements are met Analyze the profile configuration Describe the R/3 directory structure Check the transport management system configuration Configure the transport routes Back up the R/3 installation
SAP AG
Once you have completed this unit, you will be able to: Check that the installation requirements are met Check that the minimum hardware requirements are met Check that the database requirements are met Analyze the profile configuration Describe the R/3 directory structure Check the transport management system configuration Back up the R/3 installation
2-393
BC360
Installation Check
Course Roadmap
Installation Check

R
SAP AG
2-394
BC360
Installation Check
Installation Check: Part One
Operating System UNIX

UNIX
SAP AG
2-395
BC360
Installation Check
Installation Prerequisites
Requirements
Hardware
Certified hardware Num ber of processors Mem ory Disk space High availability
Software
Supported OS version OS patches C compiler make utilities Kernel configuration Additional software
Network
TCP/IP configuration Hostname Network file system (NFS) Network information system (NIS)
Frontends
Ensure the requirements in the installation checklist are met Consult hardware partners for sizing
R
SAP AG
When you plan an installation, you must ensure that the minimum requirements in the installation checklist provided by SAP are met. This installation checklist is contained in every installation package and can be ordered through the Online Service System (OSS). Installation requirements for frontends are contained in a separate installation checklist. Detailed network information is contained in the manual Integration of R/3 Servers in TCP/IP Networks and in installation checklists for supported and required network products. Detailed R/3 Release information can be obtained from the SAP Online Service System (OSS) in the component XX-SER-SWREL. The task of sizing is usually performed by SAP hardware partners, who must consider both the SAP recommendations and their own hardware specifications.
2-396
BC360
Installation Check
Check Assistance
Operating system security and performance
Disk layout Mirroring UNIX backup
Network layout
Workload Security Dedicated host for R/3 Dedicated file or print servers
UNIX
SAP AG
These operating system and network aspects must be considered during hardware sizing. There are various administration tools you can use to check the server configuration, depending on the manufacturer. To ensure that the minimum requirements are met, SAP delivers a check assistance list for each UNIX platform.
2-397
BC360
Installation Check
Installation Check: Part Two
Oracle Database
SAP AG
2-398
BC360
Installation Check
Technically Correct Installation: Database Requirements

Oracle Database Database version Database name Directory names Mirrored redo log files Disk layout
R
SAP AG
The Oracle database version must be released for the current version of the operating system. The release information can be obtained from the OSS System under component XX-SER-SWREL Release planning. This installation check list also specifies which versions of the operating system and database can be used together. The database name must be identical to the R/3 System identification (SID). The name assigned to the database at installation cannot easily be changed. The naming convention for the Oracle database also cannot be changed. Database programs and R/3 programs refer to this fixed naming convention for file directories. The redo log files (online log files) must be mirrored. Certain restrictions apply to the physical location of the Oracle file directories. For example, redo log files, archive files, and data files should not be located together on the same physical disk.
2-399
BC360
Installation Check
Technically Correct Installation: Profiles

Oracle Database Oracle profile: init<SID>.ora Oracle Net8 files: tnsnames.ora listener.ora sqlnet.ora R/3 profiles: init<SID>.dba init <SID>.sap
SAP AG
The Oracle database profile is init<SID>.ora. This profile is configured with standard values during installation. To ensure network and process communication for Oracle SQL*NET V8, the following files are required: On the database server site: listener.ora: containing configuration information for the Oracle listener thread On each database client site: tnsnames.ora: containing the connect parameters for the database client processes sqlnet.ora: containing administrative information for database client processes protocol.ora: containing the switch for tcp.nodelay (optional) The profile init<SID>.sap contains all the information needed for backing up the database. This profile also is configured with the standard values during installation. The profile init<SID>.dba is a parameter file for the R/3 program SAPDBA. This program is used for Oracle database administration. Certain parameters must be set during installation for each of these profiles. However, the profiles can be adjusted later, as required.
2-400
BC360
Installation Check
Oracle Directory Structure

Server site
sapdata1 ORACLE_HOM E origlogA dbs bin network/adm in m irrlogA saparch sapcheck mirrlogB sapbackup sapreorg ... origlogB SAPDATA_HOME sapdata<n>
Client site
ORACLE_HOME network/adm in
saptrace
Unix environm ent variables (client site) ORA_NLS: $ORACLE_HOM E/ocomm on/nls722/admin/data ORA_NLS32: $ORACLE_HOME/ocomm on/nls733/admin/data ORA_NLS33: $ORACLE_HOME/ocomm on/nls/admin/data
R
SAP AG
The Oracle database file tree structure on the database server site has 2 main branches: The Oracle binaries are located in the ORACLE_HOME directory. The environment variable ORACLE_HOME points to this directory. The ORACLE_HOME directory is also required on each server with a database client The environment variables SAPDATA_HOME and SAPDATA<n> point to the directories containing database-specific files, such as data files, online redo log files, and offline redo log files. In addition, the operating system user <SID>adm requires the following environment variables: ORACLE_SID = <SID> (on the database server site) DBS_ORA_TNSNAME: set to the database identifier <SID> from tnsnames.ora In a UNIX environment, the following environment variables are set by R/3 configuration tools: ORA_NLS: $ORACLE_HOME/ocommon/nls722/admin/data (on each client site) ORA_NLS32 $ORACLE_HOME/ocommon/nls733/admin/data (on each client site) ORA_NLS33: $ORACLE_HOME/ocommon/nls/admin/data (on each client site) TNS_ADMIN: $ORACLE_HOME/network/admin (client site, not required on newly installed R/3 4.0 Systems)
2-401
BC360
Installation Check
Example 1: Minimal Disk Layout
Disk 1 Disk 5
Paging file
Disk 2
Disk 3
Disk 6 Disk ..
OriglogA MirrlogB
OriglogB MirrlogA
SAPDATA1-N
Disk N
Non-Critical Directories Non-Critical Directories

/usr/sap/<SID> /usr/sap/<SID> /usr/sap/trans /usr/sap/trans /oracle/<SID> /oracle/<SID> /oracle/<SID>/sapreorg /oracle/<SID>/sapreorg
Disk 4
SAPARCH
SAP AG
This example shows a database disk configuration without mirrored disks. Redo log files must be mirrored. To do this, you can use either Oracle or operating system tools or by working on RAID I disk systems. Use the Oracle tools to ensure the highest level of security. This example also shows that the operating system paging file, the redo log files, the archive log files, and the Oracle data files are all located on disks that are physically separated. When dividing the Oracle file systems between the various hard disks, it is important to remember that file systems with a high I/O load (such as redo log files) should reside on disks distributed over several controllers. For further information, see the Installation Guide.
2-402
BC360
Installation Check
Example 2: High Availability RAID Disk Layout

Oracle Database
Non-Critical Directories Non-Critical Directories
Disk 1
Disk 1
Paging file
/usr/sap/<SID> /usr/sap/<SID> /usr/sap/trans /usr/sap/trans /oracle/<SID> /oracle/<SID> /oracle/<SID>/sapreorg /oracle/<SID>/sapreorg
Disk N Disk ..
Disk N
Disk ..
OriglogA
OriglogB MirrlogA MirrlogB
Disk 7 Disk 7 Disk 6 Disk 6
Disk 2
Disk 3
SAPDATA1-N
Disk 4 Disk 5 Disk 5
SAPARCH
SAP AG
This example shows a database disk configuration using mirrored disks. Every disk containing R/3 or Oracle database directories is mirrored. The mirroring is performed using: RAID I: for the OS paging file, the saparch directory, and the sapdata directories Database mirroring: for the online redo logs You can also configure the database so that each hard disk is mirrored with operating system, using a combination of RAID I and RAID V technology. For example: RAID I: for OS paging file RAID V: for saparch and sapdata directories When using RAID technology, intelligent RAID controllers should be used, such as a controller with a read/write cache. Further information about database configurations is located in: The Installation Guide BC505 Database Administration Oracle
2-403
BC360
Installation Check
Database Security
Oracle Database Database user passwords
Database backup
Archive mode
SAPDBA password
SAP AG
To ensure databases security, the following database user passwords must be changed at R/3 installation: User <SYSTEM> User <SAPR3> User <SYS> The R/3 database administration tool <SAPDBA> should be also used with a password. An R/3 System database must be backed up regularly and the database backups must be monitored. Ensure that an effective backup strategy is implemented. It is important that the Oracle database is run in ARCHIVELOG mode.
2-404
BC360
Installation Check
Database Performance
Oracle Database Location of tablespaces
Location of index and data files
DB log files vs. paging file
SAP AG
The physical location of the data files of the Oracle database can affect the performance of the database. Remember: One Oracle tablespace can be spread over one or several physical data files. Ensure there is enough free disk space to allow the tablespaces to expand. Depending on the applications and the use of your R/3 System, certain tablespaces should be allocated their own disk partitions. For further information regarding these tablespaces, see the Installation Guide. Data and index tablespaces should not be stored on the same physical unit. If there is enough disk space available, tablespace PSAPSTABD and tablespace PSAPBTABD should be located on separate physical disks. Their associated index tablespaces should also be stored on separate physical disks. Do no use RAID V for the Oracle online redo log files, the saparch directory, or the data files of tablespace PSAPROLL. Data files must not be located together with the offline redo log files, the operating system paging file, or the online redo log files.
2-405
BC360
Installation Check
Installation Check: Part Three
R/3 System
SAP AG
2-406
BC360
Installation Check
R/3 Release and System Name

R/3 Release
Released by SAP for specific operating system and database versions
R/3 System name:

M ust be unique in the system landscape M ust consist of three alphanumeric characters, the first being a letter M ust use uppercase letters M ust be identical to the database SID Cannot be any of the reserved R/3 System nam es
SAP AG
The R/3 Release must be approved and released by SAP for the specific operating system and the database versions in this combination. The R/3 Release information is available from the SAP Online Service System (OSS) in the component XX-SER-SWREL. When you assign a name to your R/3 System, you must follow the R/3 System naming conventions: The R/3 System name must be unique in the system landscape Three alphanumeric characters must be used, the first character being a letter Uppercase letters must be used The R/3 System name must be identical to the database SID You cannot assign the following names to your R/3 System, as they are reserved: ADD ALL AND ANY ASC B20 B30 BCO BIN COM DBA END EPS FOR GID INT KEY LOG MON NOT OFF OMS P30 RAW ROW SAP SET SGA SHG SID UID VAR NOTE: Choose your R/3 System name carefully. Renaming the system is complicated, and requires you to reinstall the R/3 System.
2-407
BC360
Installation Check
Checking the R/3 Basis Parameters

UNIX kernel and swap space
Check list OS dependencies Check tool m emlim its
R/3 memory management

Check tool sappfpar
R/3 profile parameters

Transaction RZ10
SAP AG
To check the UNIX kernel parameters relevant for R/3 and the swap space, you should refer to the check list OS dependencies. You can also use the R/3 tool /usr/sap/<SID>/SYS/exe/run/memlimits. This tool checks the following parameters: Maximum heap size (maximum data segment per process) Maximum mapped file size Maximum protectable size Maximum address space per process Total available swap space To check the minimal requirements for the R/3 memory management, run /usr/sap/<SID>/SYS/exe/run/sappfpar check pf=/usr/sap/<SID>/sys/profile/<instance_profile>. This is a very useful tool, especially if problems occur during R/3 System startup. To check R/3 parameters in general, use Transaction RZ10, select a profile and then choose Check.
2-408
BC360
Installation Check
R/3 Directory Structure

Global directories
trans SYS exe profile global
usr sap
<SID>
Instance directories
tmp put <Instance_name> work data log
run
dbg
opt
<sapm nt> <SID>
exe
= Symbolic link
SAP AG
profile
global
R
This graphic displays the global and instance specific R/3 file system view of a homogenous R/3 System. Global files can be managed centrally on the central instance host, using the network file system (NFS) <sapmnt>/<SID>. <sapmnt>/<SID> must be physically stored on the central instance host. It must also be exported explicitly as NFS in read/write mode to all dialog instance hosts and in read-only mode to all UNIX presentation servers. To run dialog instances with executables stored locally on the dialog instance host, activate program SAPCPE. The global transport directory /usr/sap/trans must be accessible by every R/3 instance belonging to one system landscape. This access is achieved through a soft link that points to the transport directory or through mounting the file system /usr/sap/trans using NFS. Installing a heterogeneous R/3 System requires a different file system, which is described in the installation and OS dependencies guide.
2-409
BC360
Installation Check
R/3 Instance Numbers

TCP/IP file /etc/services Required entries for R/3: Dispatcher port for instance number 00-99
sapdp<Instance_number> 32<Instance_num ber>/tcp
Gateway port for instance number 00-99

sapgw<Instance_number> 33<Instance_num ber>/tcp
M essage server port

sapms<SID> 36<Instance_num ber>/tcp
SAP AG
The assignment of the R/3 instance number is important. This number is fixed as part of the installation. The TCP/IP connection to the R/3 System(s) depends on this instance number, as does the connection from the frontend devices to the R/3 System(s). Therefore, you cannot run two R/3 Systems with different SIDs that have the same instance numbers on the same host. This is also important if an R/3 System group and/or several application servers are operating. Assigning system numbers in a structured and careful way helps to ensure a technically clear system landscape. The TCP/IP socket port entries must be the same for all R/3 instances, R/3 database servers, and all R/3 front end devices. These entries are made in the file /etc/services. Normally, these entries are made automatically as part of the installation. The following entries are reserved for R/3 service programs, and may not be used as R/3 System numbers:
sapgw97 sapgw98 sapgw99 sapdp99 3397/tcp SAP OSS 3398/tcp SAPconnect 3399/tcp SAP EPS
3299/tcp SAProuter
2-410
BC360
Installation Check
Transport Management System Set up Process
Transport routes
Configuration of tp
Transport domain & domain controller
SAP AG
Before you can work with the transport management system (TMS), it must be configured on all R/3 Systems in your system landscape. The TMS configuration includes the following steps: Configuring the transport domain You must define which R/3 Systems in the system landscape should be combined in a transport domain and which R/3 System is to be the transport domain controller Configuring the transport control program tp The transport control program requires information about the transport directory and the R/3 database for each R/3 System. This information is stored in a parameter file at the operating system level Configuring the transport routes The transport routes are used to define in which target system you want to consolidate and deliver change requests.
2-411
BC360
Installation Check
Transport Dom ain

Transport domain : DOMAIN_QAS
QAS DEV PRD
Dom ain controller Backup controller Com mon transport directory
Transport group: GROUP_DEV
SAP AG
The current status of the transport domain configuration for each R/3 System in the transport domain is displayed in the TMS System Overview. The overview also shows whether the configuration is upto-date and if any errors occurred when the configuration is distributed. To display the TMS System Overview, call Transaction STMS and choose Overview Systems. In a transport domain, the R/3 System, which is configured as the domain controller, is of special significance. If this R/3 System fails, no changes can be made to the TMS configuration. Therefore, it is recommended that you configure a backup domain controller. Once you have planned your system infrastructure, you will generally not install all planned R/3 Systems at the same time. TMS allows you to configure these R/3 Systems as virtual systems of the transport domain. Therefore, you can configure the transport routes of your entire system infrastructure.
2-412
BC360
Installation Check
Comm on Transport Directory

Directory /usr/sap/trans Global transport directory for all R/3 instances in a transport dom ain NFS m ount: /usr/sap/trans TPPARAM currently to be configured at the operating system level TPPARAM param eters can be displayed in TM S
/usr/sap/trans
bin data TPPARAM for UNIX global parameters ... system specific param eters ... olddata log actlog buffer tm p EPS sapnames cofiles
Param eter file for transport control program tp
SAP AG
Adapting the common transport directory is performed at the operating system level when the transport system is configured. The transport profile TPPARAM is the parameter file for transports. SAP delivers a sample profile TPPARAM.TPL, which must be adapted manually to meet the customer's specific needs. An R/3 System that is newly set up with the TMS is not entered automatically in the global parameter file TPPARAM. You must create this entry yourself. If the transport domain extends over several transport directories, you must adapt the parameter files in all transport directories. You must ensure that the parameter file TPPARAM is identical in all transport directories in your domain. Only the parameter TRANSDIR may be different. To check the availability of the transport control program in an R/3 System, choose R/3 System Check Transport tool. A hierarchical list is displayed that shows the status of the individual checks. If you have not selected an R/3 System, the transport control program of all R/3 Systems in the transport domain is checked. To display the tp parameters of an R/3 System, choose Goto TP parameters. The list displayed shows the parameters set in TPPARAM and the default value of all parameters used by the programs tp and R3trans.
2-413
BC360
Installation Check
Transport Routes
Transport strategy defined by transport routes Standard transport route used by all customizing change requests Additional transport routes can be established for development objects M ultilevel delivery: delivery routes can be chained
SAP AG
The configuration of the transport routes is managed in the R/3 System, which serves as the transport domain controller, and can be distributed to and activated in all other R/3 Systems connected in the transport domain. Before you can configure the transport routes, the following requirements must be met: The transport domain must be configured All R/3 Systems involved must be included in the transport domain The transport control program must be configured The transport route configuration consists of: System attributes Consolidation routes Delivery routes
2-414
BC360
Installation Check
R/3 Network Configuration

Database server dbserver Central instance DVEBMGS00 RDBMS Database C11
Application server A1
Application server A3
Application server A2 Instance D00 Instances D00 and D01 Instances D00 and D01
SAPGUI presentation server
R/3 System C11

R
SAP AG
For performance reasons, there should be no access from the frontend devices to the database host. To install the message server on a host that is different than the database host, define the following parameters in the file DEFAULT.PFL: SAPDBHOST = <database server> rdisp/mshost = <application server> For medium and large-sized R/3 installations (distributed R/3 Systems), a dedicated physical subnetwork should be installed for the communication between the R/3 servers, that is, between the database servers and application servers. This is necessary to support the high volume of data between the database and application servers with an appropriate network throughput (for example, FDDI).
2-415
BC360
Installation Check
Checking the Installation: Further Steps

Operating system dependent log files R/3 Kernel Patch Level: SM 50
Checking the installation
Installation consistency: SM 28 R/3 System log correctly installed: SM21 Buffer synchronisation: ST02 Activate Perform ance M onitor: report RADDBDIF SAP license installed: saplicense Standard passwords of sap* and ddic Remote access using SAPROUTER Im ported Hotpackages: SPAM Im ported languages: SM LT
R
SAP AG
The following steps must be performed in order to complete the installation: To check if the operating system, including the network is configured properly, use the operating system specific log files. To check if the database structure fits the R/3 kernel structure, perform the R/3 installation consistency check (Transaction SICK or SM28). Perform this check to ensure that the correct database versions and R/3 kernel versions are used, and to ensure that there are no inconsistencies in the R/3 kernel. Buffer synchronisation is important for additional application instances. Detailed information about all the steps to be performed is located in the installation guide and the online documentation.
2-416
BC360
Installation Check
Backup the R/3 Installation
O S configuration
R/3 directories
RDBMS
Database C11
R/3 CCMS Sapdba brbackup/brarchive
SAP AG
Once the installation is complete, the administrator must back up the following: The root file system, which includes the system structure and all configuration files, such as: File system size Logical volume manager configuration Database configuration data The RDBMS file systems The initial backup can also include the data file file systems. The database This can be performed with the R/3 CCMS or with backup tools, such as SAPDBA, BRBACKUP, and BRARCHIVE. External backup tools can also be used if they support the interface BACKINT. The following R/3 directories: /usr/sap/<SID> /<sapmnt>/<SID> /usr/sap/trans A backup cycle should also be defined for the various file systems. Since the file system data does not change very quickly, the backup cycles can be longer than for the database.
2-417
BC360
Installation Check

Check that the installation requirem ents are m et Check that the minimum hardware requirements are met Check that the database requirements are met Analyze the profile configuration Describe the R/3 directory structure Check the transport managem ent system configuration Configure the transport routes Back up the R/3 installation
SAP AG
2-418
BC360
Installation Check
Unit Actions
Do the exercises

R
SAP AG
Note:
There may not be sufficient time to work through all the exercises during the course. The exercises marked optional should be seen as supplementary examples that can be used, time permitting, during the course. Course participants can also use these exercises after the course, to consolidate what they have learned.
2-419
BC360
No. 1) 1.1 1.2 1.3
Exercise Perform a configuration check of disk layout of your R/3 server. Log on as user <sid>adm. Determine which volume groups belong to your system. How many disks are in each volume group? Determine which logical volumes belong to your system. Where are they mounted? Make a sketch of the distribution of these directories on the different disks. Check if origlogA and mirrlogA on separate disks. Check if origlogB and mirrlogB on separate disks. Check if directory saparch is on a disk that does not contain directory sapdata. Check if directory saparch has its own file system. Check if the swap space (volume-groups vg00) and the online redo log files are on separate disks. (Optional) Check if the database control files are located on separate disks. (Optional) Check if the files for the tablespaces PSAPBTABD and PSAPSTABD are on separate disks. (Optional) Check if the files and the index files for the tablespaces PSAPBTAB and PSAPSTAB are on separate disks.
1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11
2-420
BC360
No. 1)
Solution Perform a configuration check of your R/3 server. The answers provided here refer to a HP-UX 10.x system. For other operating systems, use the corresponding programs.
1.1 1.2 To display the following volume groups sap<SID>vg1, sap<SID>vg2, and sap<SID>vg3, enter the following command at the operating system level: vgdisplay | grep "VG Name" | grep <SID>.
Each volume group consists of one disk. To display the volume group information for volume group 1, for example, enter vgdisplay -v sap<SID>vg1. The physical volumes (disks) for each the volume groups are specified at the end of the list. There is one disk for each volume group. 1.3
To display the logical volumes in volume 1, for example, enter vgdisplay -v

sap<SID>vg1 | grep "LV Name".
The file fstab contains all mount points.

To display the mount points, enter grep <SID> /etc/fstab. 1.4 1.5 1.6 1.7 1.8 1.9 To display where the control files are located, enter find /oracle/<SID>/sap* -name cntrl<SID>.dbf, or check the parameter CONTROL_FILES in the file init<SID>.ora. To display where the corresponding files are located, enter find /oracle/<SID>/sapdata? -name \?tabd.data\*. To display where the corresponding files are located, enter find /oracle/<SID>/sapdata? -name \?tab\?.data\*
1.10
1.11
2-421
BC360
In the following, you will find excerpts from the Operation Manual, Chapter 1 Introduction, in the section Configuration Documentation. To perform these exercises, complete the tables in the excerpts as follows: 1 The table under Configuration Documentation. Look for the required data in your system and enter it in the table.
Development System <DEVSID> R/3 System: System name Database system R/3 Release Operating system Installation number <DEVSID>
2-422
BC360
No.
Question:
Tru e
1) 1.1 1.2 1.3 Part One: UNIX Which statements about the installation requirements delivered with the R/3 installation packages are correct? Considering these requirements ensures a sufficient setup and optimal performance of the R/3 System. The installation requirements define only the minimal requirements. To ensure that the R/3 System setup meets the customers needs, sizing must be performed by a hardware partner. Part Two: Database Oracle
1) 1.1 1.2 1.3 1.4 2) 2.1 2.2 3) 3.1 3-2 3.3 4) 4.1 4.2 4.3 4.4 4.5 4.6 5) 5.1 5.2 5.3 5.4 6) 6.1 6.2 6.3 6.4 6.5 7) 7.1 7.2
Normally the database is ... Automatically opened when the R/3 System is started in the standard way. Automatically closed when the R/3 System is stopped. Started and stopped separately. Started when the first attempt is made to log on to the R/3 System. If mirrored disks are used ... It is no longer necessary to perform data backups. It is still necessary to perform continual data backups. For an R/3 System with the ORACLE database ... The ARCHIVE mode must be activated. The offline redo log files do not have to be backed up. The performance of the system is greatly impaired when the ARCHIVE mode is activated. A database backup ... Can be performed either online or offline. In both cases, the offline redo log files must also be backed up. Can only be performed in online mode. Also, the offline redo log files do not have to be backed up. Can be performed online during normal R/3 operation. Should be performed both before and after each R/3 Release upgrade. Should be performed using NTBACKUP. Can only be performed in offline mode. Also, the offline redo log files do not have to be backed up. The online redo log files ... Can be mirrored using Oracle tools. Can be mirrored using operating system tools. Cannot be mirrored for R/3 operation. Can be equipped with an operating system mirror, and then they are automatically mirrored. The purpose of the file init<SID>.sap is .... To configure the database backup parameters. To parameterize the R/3 System. To set the tape size. Only to install the R/3 System and the database. To reorganize the database. The Oracle data files must ... Be located on the operating system hard disk. Follow a specific naming convention, such as sapdata<n>.
2-423
BC360
7.3 7.4 8) 8.1 8.2 8.3 9)
9.1 9.2 9.3 10) 10.1 10.2 10.3 1) 1.1 1.2 1.3 2) 2.1 2.2 2.3 3) 3.1
Be located physically separate from the online log files. Be located physically separate from the ARCHIVE log files. The file <SID>ALRT.LOG ... Has nothing to do with Oracle, but is used for recording errors in the R/3 Alert Monitor. Is constantly written to when the database is open. Does not exist for Oracle databases. Which of the following directories remains the same size, even after the installation has been completed? That is, which of the following directories requires the same amount of disk space before and after installation? /oracle/stage /oracle/<SID>/saparch /oracle/<SID>/ A status report for the database can ... Be created from R/3 using the CCMS. Be created at the operating system level using SAPDBA. Be created at the operating system level using SQLDBA.
Part Three: R/3 System The file system /<sapmnt>/<SID> ... Is only necessary if several R/3 instances will be installed. Is as NFS file system that is required to manage global files centrally on the central instance host. Is in a standard installation referred by the respective R/3 instances with symbolic links. How can an R/3 System on UNIX be checked? The UNIX kernel parameterization can be checked according to the check list OS dependencies delivered by SAP The check tool SAPPFPAR provides a sufficient possibility to change R/3 Basis parameters. R/3 profile parameter can be checked using Transaction RZ10. Which statements about the change and transport system are true? A complete setup of the transport management system includes setting up the Transport Domain and the Domain Controller, and configuring the transport program tp and the transport routes. The parameter file TPPARAM for tp can be maintained from the R/3 System. You must execute Transaction SE06 directly after the installation, regardless if the system is a new installation or a database copy. Virtual systems can be set up in order to configure the transport routes of the entire system infrastructure. What is required to backup the R/3 System? To ensure data security, in case of a hardware failure, backing up the R/3 System must include backing up the following R/3 directories: /usr/sap/<SID> /<sapmnt>/<SID> /usr/sap/trans home directory of user <sid>adm Backing up the RDBMS is not necessary, as you can easily install it directly from disk again, in case of data loss. A backup of the root file system is necessary after R/3 installation.
3.2 3.3 3.4 4) 4.1
4.2 4.3
2-424
BC360
No.
Question:
Tru e
1) 1.1 1.2 1.3 X X Part One: UNIX Which statements about the installation requirements delivered with the R/3 installation packages are correct? Considering these requirements ensures a sufficient setup and optimal performance of the R/3 System. The installation requirements define only the minimal requirements. To ensure that the R/3 System setup meets the customers needs, sizing must be performed by a hardware partner. Part Two: Database Oracle
1) 1.1 1.2 1.3 1.4 2) 2.1 2.2 3) 3.1 3-2 3.3 4) 4.1 4.2 4.3 4.4 4.5 4.6 5) 5.1 5.2 5.3 5.4 6) 6.1 6.2 6.3 6.4 6.5 7) 7.1 7.2
X X
X X
X X
X X
Normally the database is ... Automatically opened when the R/3 System is started in the standard way. Automatically closed when the R/3 System is stopped. Started and stopped separately. Started when the first attempt is made to log on to the R/3 System. If mirrored disks are used ... It is no longer necessary to perform data backups. It is still necessary to perform continual data backups. For an R/3 System with the ORACLE database ... The ARCHIVE mode must be activated. The offline redo log files do not have to be backed up. The performance of the system is greatly impaired when the ARCHIVE mode is activated. A database backup ... Can be performed either online or offline. In both cases, the offline redo log files must also be backed up. Can only be performed in online mode. Also, the offline redo log files do not have to be backed up. Can be performed online during normal R/3 operation. Should be performed both before and after each R/3 Release upgrade. Should be performed using NTBACKUP. Can only be performed in offline mode. Also, the offline redo log files do not have to be backed up. The online redo log files ... Can be mirrored using Oracle tools. Can be mirrored using operating system tools. Cannot be mirrored for R/3 operation. Can be equipped with an operating system mirror, and then they are automatically mirrored. The purpose of the file init<SID>.sap is .... To configure the database backup parameters. To parameterize the R/3 System. To set the tape size. Only to install the R/3 System and the database. To reorganize the database. The Oracle data files must ... Be located on the operating system hard disk. Follow a specific naming convention, such as sapdata<n>.
2-425
BC360
7.3 7.4 8) 8.1 8.2 8.3 9)
X X X X
9.1 9.2 9.3 10) 10.1 10.2 10.3 1) 1.1 1.2 1.3 2) 2.1 2.2 2.3 3) 3.1
X X
Be located physically separate from the online log files. Be located physically separate from the ARCHIVE log files. The file <SID>ALRT.LOG ... Has nothing to do with Oracle, but is used for recording errors in the R/3 Alert Monitor. Is constantly written to when the database is open. Does not exist for Oracle databases. Which of the following directories remains the same size, even after the installation has been completed? That is, which of the following directories requires the same amount of disk space before and after installation? /oracle/stage /oracle/<SID>/saparch /oracle/<SID>/ A status report for the database can ... Be created from R/3 using the CCMS. Be created at the operating system level using SAPDBA. Be created at the operating system level using SQLDBA.
Part Three: R/3 System The file system /<sapmnt>/<SID> ... Is only necessary if several R/3 instances will be installed. Is as NFS file system that is required to manage global files centrally on the central instance host. Is in a standard installation referred by the respective R/3 instances with symbolic links. How can an R/3 System on UNIX be checked? The UNIX kernel parameterization can be checked according to the check list OS dependencies delivered by SAP The check tool SAPPFPAR provides a sufficient possibility to change R/3 Basis parameters. R/3 profile parameter can be checked using Transaction RZ10. Which statements about the change and transport system are true? A complete setup of the transport management system includes setting up the Transport Domain and the Domain Controller, and configuring the transport program tp and the transport routes. The parameter file TPPARAM for tp can be maintained from the R/3 System. You must execute Transaction SE06 directly after the installation, regardless if the system is a new installation or a database copy. Virtual systems can be set up in order to configure the transport routes of the entire system infrastructure. What is required to backup the R/3 System? To ensure data security, in case of a hardware failure, backing up the R/3 System must include backing up the following R/3 directories: /usr/sap/<SID> /<sapmnt>/<SID> /usr/sap/trans home directory of user <sid>adm Backing up the RDBMS is not necessary, as you can easily install it directly from disk again, in case of data loss. A backup of the root file system is necessary after R/3 installation.
X X X
X X
3.2 3.3 3.4 4) 4.1
X X
4.2 4.3 X
2-426
BC360
SAP O nline Service System
SAP AG
2-427
BC360

Contents:
OSS: Overview / Functionality / Access SAPNet
TechNet
Objectives:
At the end of this unit you will be able to: Configure the OSS connection Use the SAP inform ation services OSS, SAPNet, and TechNet
SAP AG
This unit will enable you to: Connect to the Online Service System (OSS) Search the Notes database for known solutions Create and submit a problem message if a solution could not be found Monitor the progress of a problem submitted to SAP View training information Register developers and SAP objects to be modified Request and retrieve Hot Packages from the OSS This unit also discusses the network security provided by SAProuter.
2-428
BC360
Course Roadmap
SAP AG
2-429
BC360
OSS
OSS Overview
24-hour access to the Notes database Notes database provides solutions to R/3 System problems Customers can subm it problem notes
OSS Functionality Access to OSS
SAP AG
2-430
BC360
OSS Overview
OSS
24-hour access,
Custom ers
7 days a week
SAP
Customer initiates a database search
Notes database
Solution note
SAP AG
If a problem occurs in your R/3 System, you can access the OSS to find a solution. Once a connection has been established to the OSS, you can initiate a search of the Notes database. If a suitable solution is not found, you can describe the problem in a customer error message, and submit it to SAP.
2-431
BC360
Overview
OSS Overview OSS Functionality

Database search utility Problem logging SAP object change registration SAP Hot Packages Training inform ation
Access to OSS
SAP AG
2-432
BC360
OSS Functionality: Database Search Utility

Entry: R/3 Note Search
Search terms
Language
Search key words linked with the AND operator Search key words linked with the OR operator
or or
and
or Search range . . .
Search criteria
ALL
M ore term s . . . Notes for specific releases Application area of problem
SAP release Application Note num ber
to
to
... Category...
Range, or specific note num bers M ore criteria ...
Priority... Find
SAP AG
Cancel
To start a search of the Notes database: Specify your search criteria in the screen Entry: R/3 Note Search. (Choose General functions, Notes, then Find) To prevent too many notes from being selected, make your search criteria as specific as possible. Key words listed in one box only are linked with the OR operator; key words listed in two separate boxes are linked with the AND operator. To specify more key words, extend the search criteria by choosing More terms . SAP interprets the key words that you enter in terms of known SAP index words. Therefore, using words known to the SAP indexing system increases the efficiency of the search.
2-433
BC360
OSS Functionality: Problem Logging

Create: Original m essage Message Edit G oto Tools
Description Upload... Attributes
Utilities
System
?
Help
Custom er-specific data supplied
Reporter (remote available)
SAP AG DE 69190 W alldorf 29149 0120003412 M r. SAP AG 06227/7-47474
Install. OP system Database R/3 rel. Front end
0120000815 AIX O RACLE 40B
System ty. Add-on ID Add-on rel
Application area affected

LOW NEW Solutions
0120025233 0000000000 1998 Entered on 00.00.0000 00:00:00 (CET) Component XX-SER-CBT Priority Status Short Text M y message for SAP Transaction Error message .. ... Program Screen
Severity of problem Find automatic solution proposal
SAP AG
2-434
BC360
OSS Functionality: SSCR

Inbox: John Sm ith Inbox Edit G oto System Help
?
SAP m essages
SAP m essages
Gen. functions
Registration M essages
Registration
Adm inistration Registration CD
Service
Registration SSCR
Registration SSCR
Register developer Register O bjects Developers registered by m e O bjects registered by m e O verview
O bject Registration for Installation 0120000815

SAP advance correction R3TR PG MID/O bject/Nam e ? SAP release Cancel Register Delete Developer
SAP AG
To make changes to an R/3 system, you must register the developers and objects with SAP Software Change Registration (SSCR). Once you enter the user name, you receive a 20-character key that must be entered into the customer's Correction and Transport System. To avoid errors, use the cut and paste function. Any SAP object that you modify must be unlocked with a 20-character key. This allows you to keep track of modified objects, and helps make an upgrade process run more smoothly.
2-435
BC360
OSS Functionality: SSCR Overview

Customer Monitoring
List variant Edit Setting System Help
Maintain
Choose Sort Filter Delete
Inst.No
0123456789
Registration type
Developer(s)
Registered
Meier D022111 Mueller AnjaM S0000378900 Test Student Developer Schm idt Adm inistrator Chef Poirot Christie 30E R3TR PRO G RSPAR 3x R3TR DTEL GCPUC 3x R3TR DTEL GDD_G 31H R3TR PROG RSCL00 31H R3TR PROG RSCL01 31H R3TR PROG RSCL02 31H R3TR PROG RSCL03 31H R3TR PROG RSCL04 31H R3TR PROG RSCL05
Date
01.28.98 03.26.97 03.26.97 06.24.97 01.15.98 01.28.98 01.02.98 01.02.97 08.23.97 09.09.97 01.28.98 04.21.97 11.24.96 01.28.98 01.28.98 01.28.98 01.28.98 01.30.98 01.31.98 02.01.98 02.05.98 02.08.98
Registration key Advance correction

983950081865842252 981112211115842252 657940847940464055 377140494346549611 687407497900087045 654610980989046031 667446435464603046 340618704674046000 264545390132169029 981264545665842252 354098034776406603 264354501115842252 926454583615842252 264545264545264545 123445216778842343 346074940467906970 182883854676859875 654983468979135542 268713493153904158 125647141258704154 416579716113450415 465464601790870008
TADIR objects
W ith Advance corr. W ith Advance corr. W ith Advance corr.
O01(1) oss002
SAP AG
ORV
0.05
To display a list of all the developers and objects that have been registered with SSCR, choose Registration Overview and double-click the name of your system.
2-436
BC360
OSS Functionality: SAP Hot Packages

List of SAP R/3 Hot Packages
Hot Package
Expand
Edit
Goto
System
Help
?
Request Overview
M aintain
Object list Notes for Patch
Request patch
- SAP R/3 Hot Packages - Standard view + + + + + + + 30B 30C 30D 30E 30F 31G 31H 40A 1 Release 3.0B 18 Release 3.0C 46 Release 3.0D 25 Release 3.0E 33 Release 3.0F 12 Release 3.1G 18 Release 3.1H 6 Release 4.0A SPAM update fr. Hot Package 01 Hot Package 02 Hot Package 03 Hot Package 04 Hot Package 05 28 Jan 1998 for R/3 4.0A for R/3 4.0A for R/3 4.0A List of Hot Packages for R/3 4.0A currently available for R/3 4.0A for R/3 4.0A O01(1) oss002
SAP AG
SAPKD00015 SAPKH40A01 SAPKH40A02 SAPKH40A03 SAPKH40A04 SAPKH40A05
INS
0.05
If SAP identifies an error in the delivered system that could affect a large number of sites, a solution is issued in the form of a Hot Package. Hot Packages are specific to a release level and must be applied in numerical order. Customers are notified through the HotNews if a Hot Package has been issued for their system. To access HotNews, choose General functions, Notes, then HotNews.
2-437
BC360
OSS Functionality: Training Information

Training Info System
Object Edit Goto System Help
M aintain
Proceed
Restrict display by course category R/3 Services R/3 standard courses 3.0
Service selection SAP Service Event categories
Selection Application Date Country Language O01(1) oss002

SAP AG
Further display restrictions Location selection All places Free places only
OVR
0.06
The OSS also contains information about the current training courses offered by SAP, and how many places are available. You can display a list of all the courses offered, or enter search criteria to restrict the list to your specific needs.
2-438
BC360
OSS Functionality: Training Information

R/3 Standard Courses
View
Choose
Edit Filters Goto System Help
M aintain
Expand Filters Find text
R/3 standard courses 3.0
+ + + + + + + -
AC Accounting AP AS BC Basis CA Cross Application CM D4 HR Human Resources + HR050 - HR305 + 30 - 40 27.05.1998 US Oakbrook 27.05.1998 DE W alldorf + HR306
Expanded search results displayed in hypertext form at
Human Resources Configuration of Master Data (4.0 ) Release 3.0 40 22 Free places 22 Free places Configuration of Tim e Record (4.0) O01(1) oss002 OVR 0.22
SAP AG
The list of courses is displayed in hypertext format. By expanding the list, you can see when and where a particular course is being held, and how many places are available.
2-439
BC360
Overview
OSS Overview OSS Functionality Access to OSS

Custom er-controlled remote connection Network security - SAProuter
SAP AG
2-440
BC360
Access to OSS
Customer-controlled remote connection
Office Logistics oss1 Kennzeichen.. Dynamic menu
Accounting
To connect to the OSS, use Transaction OSS1
SAP AG
Once a physical connection has been set up at the operating-system level, you can connect to the OSS by using Transaction OSS1. When Transaction OSS1 is run, a new SAPGUI frontend session is automatically connected to the OSS server.
2-441
BC360
Access to OSS: Network Security - SAProuter

Customer site Firewall DEV 3200 Gateway TST 3201 SAProuter Gateway SAProuter PRD 3202 Firewall SAP - Walldorf
SAP protocol
PRD 3202
SAP AG
The application level gateway SAProuter acts as a secure gateway into and out of your SAP environment, and it is used whenever you access OSS. SAProuter only accepts incoming data if it complies with the SAP internal protocol, and if the data is received on a predefined port number from a predefined IP address. All other forms of communication directed to SAProuter are ignored.
2-442
BC360
SAPNet
SAP Public Homepage SAPNet TechNet
SAP AG
2-443
BC360
SAP Public Hom epage

Home Site Map Search W orldwide Shop W rite Us Customer Partner
http://www.sap.com
SAP AG
SAPNet is a tool that provides information and services world-wide through the Internet. As an Intranet solution promoting active communication and collaboration between SAP employees, customers and partners, SAPNet can help you broaden your knowledge and simplify your work. You can access SAPNet from the area CUSTOMER PARTNER in the SAP public homepage.
2-444
BC360
SAPNet
Public Homepage SAPNet TechNet
SAP AG
2-445
BC360
SAPNet
Assistant Information Communication Service Self Service Settings Help
http://sapnet.sap-ag.de
SAP AG
SAPNet is divided into seven different areas accessible from the tool bar.
2-446
BC360
SAPNet
Assistant
Inbox Outbox SAPNet Index Favorites
Information Communication Service Self Service Settings

SAP AG
Sites accessed from the area ASSISTANT provide user-specific information. Inbox contains: A list of all changed SAPNet articles marked by you as favorites Resubmitted documents Feedback from the SAPNet team for you Outbox contains all feedback sent by you to SAP. SAPNet Index contains all relevant key words and internet aliases relating to SAP. Favorites contains all articles bookmarked by you for future use.
2-447
BC360
SAPNet
Assistant Information
Key Topics SAP Solutions Implementation Investors Partners Events Media
Communication Service
SAP AG
For information on the R/3 System, call up the topic SAP Solutions from the area INFORMATION. Under the subtopic R/3 System you can access the following sites: R/3 Release Information Basis Technology Core Applications / Components The topic Media provides information on recent publications relating to R/3.
2-448
BC360
SAPNet
Assistant Information Communication
SAPNet Discussion Forum SAP Address Book SAP Systems SAP User Groups Forums Internal Discussion Forum s SAP TechNet R/3 Projects
Service
SAP AG
The area COMMUNICATION is divided into the following topics: SAPNet Discussion Forum, where you can exchange information on current issues, such as the EURO SAP Address Book SAP Systems SAP User Groups Forums Internal Discussion Forums SAP TechNet R/3 Projects
2-449
BC360
SAPNet
Assistant Information Communication Service
SAPNet Service Index Media Center Strategy Support Services Consulting Services Education Services
SAP AG
In the area SERVICE, Support Services has a subtopic Problems/Solutions containing: R/3 Notes Search Downloading Hot Packages Education Services provides you with a list of Current training sessions Knowledge Products Computer Based training sessions Education Services also contains information about the International Demonstration and Education System (IDES).
2-450
BC360
SAPNet
Assistant Information Communication Service Self Service
Quick Sizing Brochure Ordering Service Quote/Inform ation Helper Application
Settings
SAP AG
SELF SERVICE provides the following topics: Quick Sizing Brochures Service Quote/Information Helper Applications SETTINGS contains: Personal defaults for SAPNet
2-451
BC360
SAPNet
Public Homepage SAPNet TechNet
SAP AG
2-452
BC360
SAP TechNet
SAP AG
SAP TechNet is a technically focused online service offering expert advice and new communication channels for SAP employees, partners and customers. There are two ways to access SAP TechNet: Open SAPNet and choose the area COMMUNICATION Use the SAP TechNet internet address http://www.sap.com/technet SAP TechNet is divided into several topics, such as Software Logistics or System Management. Each topic has two parts: Knowledge base containing articles with recommendations and best practices Forum where partners and customers can ask questions about R/3, find expert opinions on specific issues, and exchange ideas and experiences with other users
2-453
BC360

Search in OSS and SAPNet for solutions to R/3 problems Create a problem message in the OSS Request user and object keys in the OSS utility SSCR Request SAP Hot Packages from OSS and SAPNet Get training information from OSS and SAPNet Access OSS Handle information in SAPNet and SAP TechNet
SAP AG
2-454
BC360
Unit Actions
Do the exercises
SAP AG
2-455
BC360
These exercises are optional
No. 1 1.1 1.2 2 2.1
Exercise OSS - Notes Log on to OSS: Enter user ID S0000315119 with password SAP, then search for the note describing the browser settings for SAPNet Test these settings in your browser if you have a browser on your PC OSS problem message Create an OSS problem message. IMPORTANT: Enter the short text: OSS TRAINING Do not process
2.2 3 3.1 4 4.1 4.2 5 5.1 6 6.1 6.2 6.3
Submit the message to SAP OSS SAP Hot Packages How many SAP Hot Packages are available for the current release? OSS SAP Software Change Request (SSCR) Register a user within the OSS SSCR How many characters does the key have? OSS Training Which basis course held in English has the most unfilled places SAPNet Conduct a search in SAPNet for the note in question 1.1 Show the list of SAP Hot Packages for the current release. Try downloading these Hot Packages.
2-456
BC360
No. 1 1.1 1.2 2 2.1 2.2 3 3.1 4 4.1 4.2 5 5.1 6 6.1 6.2 6.3
Solution
The note number is 70079
20
Choose Service --> Support Services --> Problems/Solutions --> Online Correction Support. From this page, you can enter the page with the SAP Hot Packages.
2-457
BC360
No. 1 1.1 1.2 1.3 2 2.1 2.2 2.3 3 3.1 3.2 3.3 4 4.1 4.2 4.3 5 5.1 5.2 5.3 5.4 5.5 6 6.1 6.2
True?
Question: The OSS system provides support for: SAP customers and partners SAP customers only Anyone who can dial in Problem notes in OSS can be created by: SAP staff only Anyone who can sign on to OSS OSS users with the correct authorizations OSS provides customers with bundles of fixes known as: Care Packages Electronic Parcels Hot Packages Solutions to problems raised through OSS are: Printed out and mailed back to the customer Attached to the customer's problem note and returned to the customer's inbox Faxed back to the customer. When creating problem notes, create a description that: Is clear and concise Is vague and confusing Contains known SAP index words Contains a print-out of the whole ABAP short dump, if necessary Contains a summary of the situation leading up to the error The bundled fixes referred to in Q3 are applied In any order On an ad hoc basis when the customer needs a problem fixed
2-458
BC360
6.3 7 7.1 7.2 7.3 7.4 8 8.1 8.2 8.3 9 9.1 9.2 9.3 10 10.1 10.2 10.3
As available from SAP, and in strict numerical order Preventive maintenance can be performed by: Signing on to OSS every day and downloading all the new or updated notes Signing on to OSS weekly and searching the Notes database for all new solutions created within the last 7 days Searching the database periodically for all new notes relating to a particular application area Monitoring the progress of any problem notes you have sent SAP If you want information about training course places: Use the online training course information system in OSS Call the training centre Ask a friend If you cannot find a solution in OSS to your problem: Forward a problem note to SAP Ring the hot line Post a message on CompuServe and hope for the best When SAP has solved a problem that has been forwarded to them, the customer has to: Apply the fix and close the problem Apply the fix, and if it solves the problem, confirm in the OSS that the problem is solved FTP the fix from the machine sapserv3
2-459
BC360
No. 1 1.1 1.2 1.3 2 2.1 2.2 2.3 3 3.1 3.2 3.3 4 4.1 4.2 4.3 5 5.1 5.2 5.3 5.4 5.5 6 6.1 6.2
True?
Question: The OSS system provides support for:
SAP customers and partners SAP customers only Anyone who can dial in Problem notes in OSS can be created by: SAP staff only Anyone who can sign on to OSS
OSS users with the correct authorizations OSS provides customers with bundles of fixes known as: Care Packages Electronic Parcels
Hot Packages Solutions to problems raised through OSS are: Printed out and mailed back to the customer
Attached to the customer's problem note and returned to the customer's inbox Faxed back to the customer. When creating problem notes, create a description that:
Is clear and concise Is vague and confusing
X X X
Contains known SAP index words Contains a print-out of the whole ABAP short dump, if necessary Contains a summary of the situation leading up to the error The bundled fixes referred to in Q3 are applied In any order On an ad hoc basis when the customer needs a problem fixed
2-460
BC360
6.3 7 7.1 7.2 7.3 7.4 8 8.1 8.2 8.3 9 9.1 9.2 9.3 10 10.1 10.2 10.3
As available from SAP, and in strict numerical order Preventive maintenance can be performed by: Signing on to OSS every day and downloading all the new or updated notes Signing on to OSS weekly and searching the Notes database for all new solutions created within the last 7 days
Searching the database periodically for all new notes relating to a particular application area Monitoring the progress of any problem notes you have sent SAP If you want information about training course places:
Use the online training course information system in OSS Call the training centre Ask a friend If you cannot find a solution in OSS to your problem:
Forward a problem note to SAP Ring the hot line Post a message on CompuServe and hope for the best When SAP has solved a problem that has been forwarded to them, the customer has to: Apply the fix and close the problem
Apply the fix, and if it solves the problem, confirm in the OSS that the problem is solved FTP the fix from the machine sapserv3
2-461
BC360
SAPNet: Services Support Services Access Support

SAPNet Information and C ommunication OSS
Release Notes
83458, 74079 - Info on SAPNet 32789, 26740 - Info on OSS
SAP AG
Conclusion
Conclusion
Database Ad ministration and Backu ps
Administer your R/3 System Backup your system
Introduction
CCM S Co nfiguration
DBA: Daily Check Pro cedures
Check and use the Transport SystemStarting and S to pp ing R/3 Schedule background jobs Handle the spool system Archive R/3 data M onitor and analyze your R/3 System
SAP Online S ervice S ystem Installation Ch eck
System M onitoring Background P rocessing
R/3 Authorization Data Archiving in R/3
Software Logistics Spool and P rint
SAP AG
2-462
BC360
2-463
BC360
Conclusion
Appendix
Further documentation:
Technical Core Competence Knowledge Product Online Documentation Notes in the application area BC-* SAP TechNet SAPNet Deltakiosk in the SAPNet
SAP AG
2-464

SAP Labs - SAP R3 Overview

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SAP Labs - SAP R3 Overview

Hochgeladen von

Copyright:

Verfügbare Formate

BC360

R/3 Basis R/3 Basis Administration Administration 4.0 4.0

BC360 Technical Core Competence

Database Adm inistration and Backups DBA: Daily Check Procedures

Starting and Stopping R/3

System Monitoring Background Processing

R/3 Authorization Installation Check Data Archiving in R/3

SAP Online Service System

Software Logistics Spool and Print

BC360 Technical Core Competence

BC360 Technical Core Competence

R/3 System Clients

SD Vertrieb MM M aterialMaterialwirtsch. PP Prod. planung

Client 000 Client 001 Client 066

QM Qual.m anagem ent PM Instandhaltung HR Personalwirtsch.

Customer clients for separating and isolating business data

BC360 Technical Core Competence

R/3 System Logon Steps

Ex.: IP: a.b.c.73 SAPGUI

IP: X.Y.Z.20 Dispatcher

IP: X.Y.Z.10 Dispatcher

BC360 Technical Core Competence

Defining "Instance" and "Application Server"

BC360 Technical Core Competence

System Dialog Step

Dialog work process

Taskhandler Dynpro processor

ABAP processor Database interface

BC360 Technical Core Competence

W ork Process Multiplexing

BC360 Technical Core Competence

Summary of this Unit

BC360 Technical Core Competence

Starting and Stopping R/3

R/3 Basis R/3 Basis Administration Administration 4.0 4.0

Starting and Stopping R/3

BC360 Technical Core Competence

BC360 Technical Core Competence

Starting and Stopping R/3

Starting and Stopping R/3

BC360 Technical Core Competence

Starting and Stopping R/3

Database Administration and Backups

DBA: Daily Check Procedures

Starting and Stopping R/3

System M onitoring Background Processing

R/3 Authorization SAP O nline Service System Data Archiving in R/3

Software Logistics Spool and Print

BC360 Technical Core Competence

Starting and Stopping R/3

Starting the R/3 System

<host>> startsap ( startsap_<host>_<instance no>)

BC360 Technical Core Competence

Starting and Stopping R/3

Starting the R/3 System

Instance startup sequence

BC360 Technical Core Competence

Starting and Stopping R/3

Process Overview at the Operating System Level

0:07 0:00 0:00 221:17 0:00 58:09 2:27 3:32

Dispatcher; parent process is sapstart

R/3 work process forked by the dispatcher

Collector and sender started by the dispatcher