P. 1
R3_Basis_Administration_Introduction

R3_Basis_Administration_Introduction

|Views: 2,424|Likes:
Published by api-27599940
Basis_Administration
Basis_Administration

More info:

Published by: api-27599940 on Oct 15, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

06/02/2015

pdf

text

original

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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 Branchenlösungen

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.

BC360 Technical Core Competence

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

1

IP: X.Y.Z.10 Dispatcher

M
9 4

D

V

E

B

S

...
5

D
8

V

B

D

...

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.

BC360 Technical Core Competence

2-5

BC360

Introduction

Defining "Instance" and "Application Server"
Instance A
Dispatcher

Instance B
Dispatcher

S

S

...

B

...

Central Instance C
Dispatcher

D

V

E

B

S

...

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)

BC360 Technical Core Competence

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

7

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

BC360 Technical Core Competence

2-7

BC360

Introduction

W ork Process Multiplexing
...
Request queues
1

Dynpro100 Dynpro200

SAPGUI
9 10 18

Request queues

...

Dispatcher

M
8 3

2

11

Dispatcher
17 12

D

V

E

B

S

...
4

D
7

V

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.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

Starting and Stopping R/3

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

Starting and Stopping R/3
R

© SAP AG

BC360 Technical Core Competence

2-10

BC360

BC360 Technical Core Competence

2-11

BC360

Starting and Stopping R/3

Starting and Stopping R/3
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

BC360 Technical Core Competence

2-12

BC360

Starting and Stopping R/3

Course Roadmap
Introduction CCM S Configuration

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

Installation Check

Software Logistics Spool and Print
R

© SAP AG

BC360 Technical Core Competence

2-13

BC360

Starting and Stopping R/3

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

R

© 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

BC360 Technical Core Competence

2-14

BC360

Starting and Stopping R/3

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

R

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.

BC360 Technical Core Competence

2-15

BC360

Starting and Stopping R/3

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…

X

? ? ? ? ? ? ? ?

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.

BC360 Technical Core Competence

2-16

BC360

Starting and Stopping R/3

Assigning Parameter Values

3 2

Instance profile

R/3 work processes

Default profile

Param eter read sequence

1
C source

R

© 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.

BC360 Technical Core Competence

2-17

BC360

Starting and Stopping R/3

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.

BC360 Technical Core Competence

2-18

BC360

Starting and Stopping R/3

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

BC360 Technical Core Competence

2-19

BC360

Starting and Stopping R/3

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.

BC360 Technical Core Competence

2-20

BC360

Starting and Stopping R/3

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.

BC360 Technical Core Competence

2-21

BC360

Starting and Stopping R/3

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.

BC360 Technical Core Competence

2-22

BC360

Starting and Stopping R/3

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>

R

© 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

BC360 Technical Core Competence

2-23

BC360

Starting and Stopping R/3

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

R

© 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.

BC360 Technical Core Competence

2-24

BC360

Starting and Stopping R/3

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.

BC360 Technical Core Competence

2-25

BC360

Starting and Stopping R/3

Summary of this Unit
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

R

© SAP AG

BC360 Technical Core Competence

2-26

BC360

Starting and Stopping R/3

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.

BC360 Technical Core Competence

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)

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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?

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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?

X

<sid>adm guest ora<sid> The program SAPSTART is called from: The user <ora>sid.

X

The script startsap_<hostname>_<instance no.>, which is referenced with the alias startsap. The script startsap, which is executed by the user root.

X

The user <sid>adm entering startsap on a UNIX shell. The first component that is started is: The database.

X

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.

X

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.

X

The start profile. How can you check the database and R/3 logs and traces that were written during startup or shutdown?

BC360 Technical Core Competence

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

X

CCMS Configuration

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

CCMS Configuration

R

© SAP AG

BC360 Technical Core Competence

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

BC360 Technical Core Competence

2-35

BC360

CCMS Configuration

Course Roadm ap
Introduction CCM S Configuration

Database Administration and Backups

DBA: Daily Check Procedures

Starting and Stopping R/3

System M onitoring Background Processing

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

SAP Online Service System

Software Logistics Spool and Print
R

© SAP AG

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

R

© 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.

BC360 Technical Core Competence

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

R

© 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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

2-41

BC360

CCMS Configuration

Changing R/3 Profile Parameters

R/3 profile m aintenance with Transaction RZ10

In

D

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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

2-44

BC360

CCMS Configuration

Operation Modes: Concept

11 10 9 8 7

12

1 2 3 4

6

5

BTC

Dialog processing Day

Background processing Night

Tim e

8 pm

R

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

BC360 Technical Core Competence

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

D

D

D

B

B

D

D

D

D

B

B

R

© 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

BC360 Technical Core Competence

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

D

D

B

B

B

D

D

B

B

B

B

R

© 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

BC360 Technical Core Competence

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

R

© 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.

BC360 Technical Core Competence

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

R

© 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.

BC360 Technical Core Competence

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

R

© 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).

BC360 Technical Core Competence

2-50

BC360

CCMS Configuration

Operation Mode Switch: Concept
Shutdown
NIGHT_OPERATION

DAY_OPERATION

Shutdown
Server 2

Server 1

Dispatcher

Dispatcher

D

D

D/B

B

B

D

D

D/B

D/B

B

B

R

© 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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

2-52

BC360

CCMS Configuration

Switching Operation Modes Manually

Control panel (Transaction RZ03)

B

A

C

B

00.00

08.00

21.00

23.59

R

© 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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

2-55

BC360

CCMS Configuration

Summary of this Unit
Now you are able to:
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

R

© SAP AG

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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).

2

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.

BC360 Technical Core Competence

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>

BC360 Technical Core Competence

2-63

BC360

<DEVSID> <DEVSID>

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

2-67

BC360

16.3 16.4

The instances profiles are changed R/3 buffers are not refreshed

BC360 Technical Core Competence

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:

X

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

X

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

X

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:

X

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

X

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

BC360 Technical Core Competence

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:

X

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

2-71

BC360

16.3 16.4 X

The instances profiles are changed R/3 buffers are not refreshed

BC360 Technical Core Competence

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

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

Database Administration and Backups

R

© SAP AG

BC360 Technical Core Competence

2-73

BC360

BC360 Technical Core Competence

2-74

BC360

Database Adm inistration

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

BC360 Technical Core Competence

2-75

BC360

Database Adm inistration

Course Roadmap
Introduction CCM S Configuration

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

Installation Check

Software Logistics Spool and Print
R

© SAP AG

BC360 Technical Core Competence

2-76

BC360

Database Adm inistration

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.

BC360 Technical Core Competence

2-77

BC360

Database Adm inistration

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

Online redo log files

Redo log buffer

Offline redo log files
© 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.

BC360 Technical Core Competence

CKPT

Nom ount

LGWR

2-78

BC360

Database Adm inistration

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.

BC360 Technical Core Competence

2-79

BC360

Database Adm inistration

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.

BC360 Technical Core Competence

2-80

BC360

Database Adm inistration

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.

BC360 Technical Core Competence

2-81

BC360

Database Adm inistration

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

BC360 Technical Core Competence

2-82

BC360

Database Adm inistration

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.

BC360 Technical Core Competence

2-83

BC360

Database Adm inistration

Database and Offline Redo Log File Backups
Data files

Online redo log files
Database backup Database backup

Control file Profiles Offline redo log files

O ffline redo log O ffline redo log file backup file backup

R

© 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.

BC360 Technical Core Competence

2-84

BC360

Database Adm inistration

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

Database backup Database backup
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.

BC360 Technical Core Competence

2-85

BC360

Database Adm inistration

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

Online redo log files
d
O ffline backup

Database buffer pool t

N

o

st

a

e rt

Control file Profiles
SGA

Shared pool

Offline redo log files
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.

BC360 Technical Core Competence

2-86

BC360

Database Adm inistration

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

Online redo log files
k ed up

O nline backup
Database buffer pool SGA

Control file Profiles Offline redo log files
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.

BC360 Technical Core Competence

2-87

BC360

Database Adm inistration

Offline Redo Log File Backups
Online redo log files

.../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.

BC360 Technical Core Competence

2-88

BC360

Database Adm inistration

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)

R

© 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.

BC360 Technical Core Competence

2-89

BC360

Database Adm inistration

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

Online redo log files

BRBACKUP
Database backup Database backup

Control file Profiles Offline redo log files
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.

BC360 Technical Core Competence

2-90

BC360

Database Adm inistration

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.

BC360 Technical Core Competence

2-91

BC360

Database Adm inistration

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, ...)

R

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

BC360 Technical Core Competence

2-92

BC360

Database Adm inistration

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.

BC360 Technical Core Competence

2-93

BC360

Database Adm inistration

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

R

© 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).

BC360 Technical Core Competence

2-94

BC360

Database Adm inistration

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

R

To edit init<SID>.sap, use a standard text editor init<SID>.sap,
© 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.

BC360 Technical Core Competence

2-95

BC360

Database Adm inistration

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

To edit init<SID>.sap, use a standard text editor init<SID>.sap,
© 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.

BC360 Technical Core Competence

2-96

BC360

Database Adm inistration

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

Offline redo log files
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.

BC360 Technical Core Competence

2-97

BC360

Database Adm inistration

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
CCMS Planning Calendar
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

R

© 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.

BC360 Technical Core Competence

2-98

BC360

Database Adm inistration

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

R

© 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

BC360 Technical Core Competence

2-99

BC360

Database Adm inistration

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>
Online redo log files

• • • •

Determ ines the tapes required Determ the tapes Backs up the database Backs up the Calls BRARCHIVE Calls

Volume_backup

brarchive <options>
Control file Profiles Offline redo log files
Backs up the offline redo log files

Log file
.... .... ....

R

© 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

BC360 Technical Core Competence

2-100

BC360

Database Adm inistration

Summary of this Unit
Now you are able to:
Define an effective backup strategy Perform database backups Perform offline redo log file backups Verify the database backups

R

© 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.

BC360 Technical Core Competence

2-101

BC360

Database Adm inistration

Unit Actions

Do the exercises

?

Answer the questions Fill in the blanks

Solutions for the exercises Answer the questions
R

© SAP AG

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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).

2

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

Configuration Documentation
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.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

X

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

X

1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12

X

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”).

X

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.

X

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.

BC360 Technical Core Competence

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

X

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

X

1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12

X

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”).

X

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.

X

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.

BC360 Technical Core Competence

2-109

BC360

Database Adm inistration

Further Docum entation

SAP System Management CD Oracle Database Administration CD SAP Online Documentation:
Database Administration Oracle

BC505 Oracle Database Administration

R

© 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

BC360 Technical Core Competence

2-110

BC360

Database Adm inistration

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

DB Administration: Daily Check Procedures

R

© SAP AG

BC360 Technical Core Competence

2-111

BC360

Database Adm inistration

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

BC360 Technical Core Competence

2-112

BC360

Database Adm inistration

Course Roadmap
Introduction CCM S Configuration

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

Installation Check

Software Logistics Spool and Print
R

© SAP AG

BC360 Technical Core Competence

2-113

BC360

Database Adm inistration

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

R

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

BC360 Technical Core Competence

2-114

BC360

Database Adm inistration

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

R

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.

BC360 Technical Core Competence

2-115

BC360

Database Adm inistration

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

x

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

BC360 Technical Core Competence

2-116

BC360

Database Adm inistration

Updating Oracle Optimizer Statistics
CCM S Planning Calendar

x
FRI S AT 10:00 Checkopt Checko pt SUN S UN 5:00 Analyzetab

P lanning Goto Listing Help System

-

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

SUN S UN 5:00 Analyzetab

FRI

S AT 10:00 Checkopt

SUN S UN 5:00 Analyzetab

-

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.

BC360 Technical Core Competence

2-117

BC360

Database Adm inistration

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-ID´s 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 07 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.

BC360 Technical Core Competence

2-118

BC360

Database Adm inistration

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


R

© 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).

BC360 Technical Core Competence

2-119

BC360

Database Adm inistration

Database System Check: sapdba -check
CCMS Planning Calendar

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

x

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.

BC360 Technical Core Competence

2-120

BC360

Database Adm inistration

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

x

d - Reorganization Alter storage param eters
R

x

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.

BC360 Technical Core Competence

2-121

BC360

Database Adm inistration

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

x

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.

BC360 Technical Core Competence

2-122

BC360

Database Adm inistration

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

CCMS Planning Calendar
TUE Full O ffline Offline TUE WE D W ED THU FRI S AT S UN

x

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

CCM S Planning Calendar
TUE Full Offline O ffline TUE WED WE THU FRI SAT SUN S UN

x

P lanning G oto N M O Listing Help System TUE WE D MO W ED Recovery report Recovery report Refresh Refresh

P lanning Goto Listing Help System

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

R

© 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.

BC360 Technical Core Competence

2-123

BC360

Database Adm inistration

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
Online redo log files

• Archiver is not running • Archive directory is full Backup Logs: Overview

Archiver stuck when:

BRARCHIVE
< SID> A01 <SID>A01 < SID> A01

x

SAPDBA

x

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.

BC360 Technical Core Competence

2-124

BC360

Database Adm inistration

Summary of this Unit
Now you are able to:
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

R

© 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

BC360 Technical Core Competence

2-125

BC360

Database Adm inistration

Unit Actions

Do the exercises

?

Answer the questions Fill in the blanks

Solutions for the exercises Answers to the questions
R

© SAP AG

BC360 Technical Core Competence

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

BC360 Technical Core Competence

2-127

BC360

No. 1) 1.1

Solution

Open the DBA Planning Calendar (Transaction DB13). Double-click today’s 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 today’s 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

BC360 Technical Core Competence

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:

1

The tables under Configuration Documentation. In your system, check when optimizer statistics functions are scheduled and enter this information in the appropriate tables.

Configuration Documentation
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.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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.
Database Adm inistration

Further Docum entation

Oracle Database Administration CD SAPNet:
TechNet

R/3 Online Documentation:
SAP Database Administration: Oracle C CMS Database Administration

BC505 Oracle Database Administration

R

© SAP AG

BC360 Technical Core Competence

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

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

Background Processing

© SAP AG

BC360 Technical Core Competence

2-132

BC360

Background Processing

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

BC360 Technical Core Competence

2-133

BC360

Background Processing

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

BC360 Technical Core Competence

2-134

BC360

Background Processing

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

BC360 Technical Core Competence

2-135

BC360

Background Processing

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

BC360 Technical Core Competence

2-136

BC360

Background Processing

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

BC360 Technical Core Competence

2-137

BC360

Background Processing

Background Processing Features (2)
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

BC360 Technical Core Competence

2-138

BC360

Background Processing

Background Processing Features (3)
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

BC360 Technical Core Competence

2-139

BC360

Background Processing

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.

BC360 Technical Core Competence

2-140

BC360

Background Processing

Jobs Selected for Execution
Dialog and background server
System Clock

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

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.

BC360 Technical Core Competence

2-141

BC360

Background Processing

W orkload Balancing
Dialog and Background Server1
System clock Message server The message server maintains a table of available servers with BTC work processes

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 Server1 09:10 10:20 10:20 14:50 14:50

Dialog and Background Server2
System clock

W Ps Dia Dia Dia Btc Btc
© 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.

BC360 Technical Core Competence

2-142

BC360

Background Processing

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.

BC360 Technical Core Competence

2-143

BC360

Background Processing

Scheduling Priorities
Dialog and Background Server 1
System clock Message server The message server maintains a table of available servers with BTC work processes

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 C 08:00 Server1 08:00 08:00 08:00 08:00 08:00

Dialog and Background Server2
System clock

W Ps Dia Dia Dia Btc Btc
© 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

BC360 Technical Core Competence

2-144

BC360

Background Processing

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.

BC360 Technical Core Competence

2-145

BC360

Background Processing

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

2

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.

2

© 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.

BC360 Technical Core Competence

2-146

BC360

Background Processing

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

BC360 Technical Core Competence

2-147

BC360

Background Processing

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.

BC360 Technical Core Competence

2-148

BC360

Background Processing

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.

BC360 Technical Core Competence

2-149

BC360

Background Processing

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.

BC360 Technical Core Competence

2-150

BC360

Background Processing

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.

BC360 Technical Core Competence

2-151

BC360

Background Processing

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.

BC360 Technical Core Competence

2-152

BC360

Background Processing

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

2

At operation mode

After event

3

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.

BC360 Technical Core Competence

2-153

BC360

Background Processing

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

Scheduled Released Ready Active Finished Cancelled X

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

2

22.06.1998 22.06.1998 22.06.1998

3

© 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.

BC360 Technical Core Competence

2-154

BC360

Background Processing

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

Scheduled Released Ready Active Finished Cancelled X

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.

2

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

3

Active instance pswdf694_TC1_00 1

Number of active users 2 2 users

4

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.

BC360 Technical Core Competence

2-155

BC360

Background Processing

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.

BC360 Technical Core Competence

2-156

BC360

Background Processing

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.

BC360 Technical Core Competence

2-157

BC360

Background Processing

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.

BC360 Technical Core Competence

2-158

BC360

Background Processing

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.

BC360 Technical Core Competence

2-159

BC360

Background Processing

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

7

6

5

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.

BC360 Technical Core Competence

2-160

BC360

Background Processing

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.

BC360 Technical Core Competence

2-161

BC360

Background Processing

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

BC360 Technical Core Competence

2-162

BC360

Background Processing

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

Not Authorized Authorized
© 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.

BC360 Technical Core Competence

2-163

BC360

Background Processing

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

5

XMI logging: Company name of e * XMI logging: Program name of e * Interface ID (for example, XBP * Manual Authorization for external management interf.

Not Authorized Authorized
© 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

BC360 Technical Core Competence

2-164

BC360

Background Processing

Summary of this Unit
Now you are able to:
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

BC360 Technical Core Competence

2-165

BC360

Background Processing

Unit Actions
Do the exercises

?

Answer the questions Fill in the blanks

Solutions for the exercises Answer the questions

© SAP AG

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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)

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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. ABAP Choose 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 -->

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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).

2

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

W: Weekly D: Daily <R3ADM>: System administrator

M: Monthly

Y: Yearly

AR: As required

Configuration Documentation
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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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?

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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…

X

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?

X

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

BC360 Technical Core Competence

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?

BC360 Technical Core Competence

2-182

BC360

13.1 13.2 14 14.1 14.2 14.3

X

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 ?

X

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.

BC360 Technical Core Competence

2-183

BC360

Background Processing

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

BC360 Technical Core Competence

2-184

BC360

Background Processing

R/3 Online Docum entation

R/3 Online Documentation Com puter Center M anagement System

© SAP AG

Software Logistics

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

Software Logistics

R

© SAP AG

BC360 Technical Core Competence

2-185

BC360

BC360 Technical Core Competence

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

R

© SAP AG

BC360 Technical Core Competence

2-187

BC360

Software Logistics

Course Roadmap
Introduction CCM S Configuration

DBA: Backup and Restore

DBA: Daily Check

System M onitoring Start and Stop Background Processing

User Administration Installation Check Archiving

SAP Online Service System

Software Logistics Spooling and Printing
R

© SAP AG

BC360 Technical Core Competence

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?

R

© 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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

R

© 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.

BC360 Technical Core Competence

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

R

© 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.

BC360 Technical Core Competence

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

X

R

© 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.

BC360 Technical Core Competence

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

R

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.

BC360 Technical Core Competence

2-195

BC360

Software Logistics

System Change Options
System Change Option

X

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

R

© 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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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
Client-independent Custom izing R/3 Repository

Custom izing

R

© 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.

BC360 Technical Core Competence

2-199

BC360

Software Logistics

Local Client Copy

User

User

User

Custom izing

C ustom izing

Custom izing

Client-independent Custom izing R/3 Repository

R

© 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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

R

© 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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

...

R

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

X

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.

BC360 Technical Core Competence

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

X

You can display:
Order and names of transport requests User and short text Object list Documentation Transport logs

R

© 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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

R

© 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.

BC360 Technical Core Competence

2-212

BC360

Software Logistics

Summary of this Unit
Now you are able to:
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

R

© SAP AG

BC360 Technical Core Competence

2-213

BC360

Software Logistics

Unit Actions

Do the Exercises

?

Answer the Questions Fill in the Blanks

Solutions for the Exercises Answers to the Questions
R

© SAP AG

BC360 Technical Core Competence

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

BC360 Technical Core Competence

2-215

BC360

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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).

2

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

BC360 Technical Core Competence

2-219

BC360

option Checking and changing client settings Tools → Administration → Administration → Client admin. → Client maintenance

W: Weekly D: Daily <R3ADM>: System administrator

M: Monthly

Y: Yearly

AR: As required

Configuration Documentation
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.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

2-226

BC360

No. 1 1.1 1.2

True?

Question: Which of the following statements concerning an R/3 System is / are correct?

X

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

X

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.

BC360 Technical Core Competence

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

X

...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.

X

...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.

X

...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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

2-231

BC360

Software Logistics

Further Docum entation

Basis Knowledge Product: Software Logistics Online Documentation BC-Basis: Change and Transport System SAP TechNet: Software Logistics

R

© SAP AG

Users and Authorizations

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

Users and Authorizations in the R/3 System

© SAP AG

BC360 Technical Core Competence

2-232

BC360

BC360 Technical Core Competence

2-233

BC360

Users and Authorizations

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

BC360 Technical Core Competence

2-234

BC360

Users and Authorizations

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

BC360 Technical Core Competence

2-235

BC360

Users and Authorizations

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

D

B

V

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.

BC360 Technical Core Competence

2-236

BC360

Users and Authorizations

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.

BC360 Technical Core Competence

2-237

BC360

Users and Authorizations

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.

BC360 Technical Core Competence

2-238

BC360

Users and Authorizations

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)

BC360 Technical Core Competence

2-239

BC360

Users and Authorizations

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.

BC360 Technical Core Competence

2-240

BC360

Users and Authorizations

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.

BC360 Technical Core Competence

2-241

BC360

Users and Authorizations

Profile Generator: Overview (2)

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.

BC360 Technical Core Competence

2-242

BC360

Users and Authorizations

Profile Generator: Overview (3)

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.

BC360 Technical Core Competence

2-243

BC360

Users and Authorizations

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.

BC360 Technical Core Competence

2-244

BC360

Users and Authorizations

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 Prüfung 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...

BC360 Technical Core Competence

2-245

BC360

Users and Authorizations

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.

BC360 Technical Core Competence

2-246

BC360

Users and Authorizations

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

BC360 Technical Core Competence

2-247

BC360

Users and Authorizations

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*.

BC360 Technical Core Competence

2-248

BC360

Users and Authorizations

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.

BC360 Technical Core Competence

2-249

BC360

Users and Authorizations

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.

BC360 Technical Core Competence

2-250

BC360

Users and Authorizations

Summary

Now you are able to:
Maintain activity groups using the Profile Generator Assign R/3 users to these activity groups Create and maintain user m aster records

© SAP AG

BC360 Technical Core Competence

2-251

BC360

Users and Authorizations

Unit Actions
Do the Exercises

?

Answer the Questions Fill in the Blanks

Solutions for the Exercises Answer the Questions

© SAP AG

BC360 Technical Core Competence

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.

3

Check the user ADMIN1.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

X

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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

2-263

BC360

Users and Authorizations

Further Documentation
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

BC360 Technical Core Competence

2-264

BC360

Users and Authorizations

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.

BC360 Technical Core Competence

2-265

BC360

Users and Authorizations

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

5

© 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.

BC360 Technical Core Competence

2-266

BC360

Users and Authorizations

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,...

BC360 Technical Core Competence

2-267

BC360

Users and Authorizations

Appendix: User Adm in. Authorizations II
Authorization Objects Authorization Objects
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.

BC360 Technical Core Competence

2-268

BC360

Users and Authorizations

Appendix: User Adm in. Authorizations III
Authorization Objects Authorization Objects
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.

BC360 Technical Core Competence

2-269

BC360

R/3 Spool and Print

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

R/3 Spool and Print

© SAP AG

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

2-272

BC360

R/3 Spool and Print

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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

Operating system spool

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.

BC360 Technical Core Competence

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

Operating system spool

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

U

TCP/IP network S
SAPLPD

U

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

Access m ethod to host spool M odel Location M essage

Atlanta Training Center - 23rd floor

Lock printer in R/3 System SAP title page

© 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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

Access m ethod to host spool M odel Location M essage

Printing on front end computer

Frontend Printer

Lock printer in R/3 System SAP title page

© 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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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).

BC360 Technical Core Competence

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

Logical spool server

Logical spool server

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

2-298

BC360

R/3 Spool and Print

Summary of this Unit
Now you are able to:
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

BC360 Technical Core Competence

2-299

BC360

R/3 Spool and Print

Unit Actions
Do the exercises

?

Answer the questions Fill in the blanks

Solutions for the exercises Answers to for the questions

© SAP AG

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

3

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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).

2

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

Configuration Documentation
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

BC360 Technical Core Competence

2-308

BC360

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

2-312

BC360

No. 1 1.1

True?

Question: Which of the following statements is true?

X

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

2-314

BC360

9.2 9.3 9.4 10 10.1 10.2 10.3 10.4

X

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.

X

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

X

S_SPO_PAGE

BC360 Technical Core Competence

2-315

BC360

R/3 Spool and Print

Further Documentation

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

BC360 Technical Core Competence

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)

BC360 Technical Core Competence

2-317

BC360

Data Archiving in R/3

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

Data Archiving in R/3
R

© SAP AG

BC360 Technical Core Competence

2-318

BC360

Data Archiving in R/3

Data Archiving in R/3
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.

BC360 Technical Core Competence

2-319

BC360

Data Archiving in R/3

Course Roadmap
Introduction CCM S Configuration

Database Administration and Backups

DBA: Daily Check Procedures

Starting and Stopping R/3

System M onitoring Background Processing

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

SAP Online Service System

Software Logistics Spool and Print
R

© SAP AG

BC360 Technical Core Competence

2-320

BC360

Data Archiving in R/3

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

R

© 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.

BC360 Technical Core Competence

2-321

BC360

Data Archiving in R/3

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

BC360 Technical Core Competence

2-322

BC360

Data Archiving in R/3

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.

BC360 Technical Core Competence

2-323

BC360

Data Archiving in R/3

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.

BC360 Technical Core Competence

2-324

BC360

Data Archiving in R/3

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

R

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.

BC360 Technical Core Competence

2-325

BC360

Data Archiving in R/3

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.

BC360 Technical Core Competence

2-326

BC360

Data Archiving in R/3

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

R

© 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.

BC360 Technical Core Competence

2-327

BC360

Data Archiving in R/3

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.

BC360 Technical Core Competence

2-328

BC360

Data Archiving in R/3

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

R

© 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.

BC360 Technical Core Competence

2-329

BC360

Data Archiving in R/3

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

R

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.

BC360 Technical Core Competence

2-330

BC360

Data Archiving in R/3

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

R

© 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.

BC360 Technical Core Competence

2-331

BC360

Data Archiving in R/3

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.

BC360 Technical Core Competence

2-332

BC360

Data Archiving in R/3

Summary of this Unit

Now you are able to:
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

R

© 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

BC360 Technical Core Competence

2-333

BC360

Data Archiving in R/3

Unit Actions

?

Do the exercises

Solutions for the exercises

R

© SAP AG

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

2-336

BC360

Data Archiving in R/3

Further Docum entation
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

BC360 Technical Core Competence

2-337

BC360

Data Archiving in R/3

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.

BC360 Technical Core Competence

2-338

BC360

Data Archiving in R/3

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.

BC360 Technical Core Competence

2-339

BC360

System Monitoring

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

System Monitoring

© SAP AG

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

2-341

BC360

System Monitoring

Course Roadmap
Introduction CCMS Configuration

DBA Backup

DBA - Daily Check

Start and Stop

System M onitoring
Background Processing

User Adm inistration Installation Check Archiving

SAP Online Service System

Software Logistics Spooling and Printing

© SAP AG

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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 MTE´s, you can customize the following: Description Level of visibility (operator, administrator,…) Alert priority These settings then become valid for all MTE´s assigned to this class. By grouping MTE´s 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.

BC360 Technical Core Competence

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 MTE´s. 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 MTE´s 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 MTE´s 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.

BC360 Technical Core Competence

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 MTE´s. The tools predefined by SAP have the prefix CCMS. Customers should use Y and Z as name range for own created tools.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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 MTE´s 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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

2-353

BC360

System Monitoring

R/3 Syslog: Details
Local log file message 1 Local log file message 2

Application server 1

rslgsend

rslgsend

Application server 2

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.

BC360 Technical Core Competence

2-354

BC360

System Monitoring

R/3 Services
Basis Development ( Basic monitor ) Current status Display alerts Complete alerts

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

BC360 Technical Core Competence

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 1

. . .
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

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

2

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.

BC360 Technical Core Competence

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

...

3

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.

BC360 Technical Core Competence

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?

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

9

9

9

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.

BC360 Technical Core Competence

2-364

BC360

System Monitoring

Monitoring: W orkload Analysis

Application server 1

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

Application server 2

12

. . .
Application server x

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

BC360 Technical Core Competence

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

Application server 1

Application server 2

Application server 3

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.

BC360 Technical Core Competence

2-366

BC360

System Monitoring

R/3 Basis System
Basis Development ( Basic monitor ) Current status Display alerts Complete alerts

• 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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

2-369

BC360

System Monitoring

Monitoring: Buffers

Application server 1

ST02
Information Buffer quality
Table buffer

Application server 2

Swaps SAP memory

. . .
Application server x

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

2-371

BC360

System Monitoring

Database Monitoring
Basis Development ( Basic monitor ) Current status Display alerts Complete alerts

• 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.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

2-373

BC360

System Monitoring

Operating System
Basis Development ( Basic monitor ) Current status Display alerts Complete alerts

• 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.

BC360 Technical Core Competence

2-374

BC360

System Monitoring

Monitoring: Operating System
ST06
Application server 1 Information CPU Disk Application server 2 Physical memory … …

. . .

Application server x

© 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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

Check 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.

BC360 Technical Core Competence

2-378

BC360

System Monitoring

Summary of this Unit
Now you are able to:
Define an alert monitor Custom ize an alert monitor Define and assign tools Handle the alerts

© SAP AG

BC360 Technical Core Competence

2-379

BC360

System Monitoring

Unit Actions
Do the Exercises

?

Answer the Questions Fill in the Blanks

Solutions for the Exercises Answer the Questions

© SAP AG

BC360 Technical Core Competence

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 MTE’s. Which types of MTE’s 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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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 MTE’s. 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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

2-386

BC360

BC360 Technical Core Competence

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

X

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

X

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

BC360 Technical Core Competence

2-388

BC360

BC360 Technical Core Competence

2-389

BC360

System Monitoring

Further Documentation

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.

BC360 Technical Core Competence

2-390

BC360

Installation Check

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

Installation Check

R

© SAP AG

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

R

© 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

BC360 Technical Core Competence

2-393

BC360

Installation Check

Course Roadmap
Introduction CCM S Configuration

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

Installation Check

Software Logistics Spool and Print
R

© SAP AG

BC360 Technical Core Competence

2-394

BC360

Installation Check

Installation Check: Part One

Operating System UNIX
UNIX

R

© SAP AG

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

R

© 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.

BC360 Technical Core Competence

2-397

BC360

Installation Check

Installation Check: Part Two

Oracle Database

R

© SAP AG

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

R

© 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.

BC360 Technical Core Competence

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)

BC360 Technical Core Competence

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

R

© 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.

BC360 Technical Core Competence

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

R

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

BC360 Technical Core Competence

2-403

BC360

Installation Check

Database Security

Oracle Database Database user passwords

Database backup

Archive mode

SAPDBA password

R

© 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.

BC360 Technical Core Competence

2-404

BC360

Installation Check

Database Performance

Oracle Database Location of tablespaces

Location of index and data files

DB log files vs. paging file

R

© 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.

BC360 Technical Core Competence

2-405

BC360

Installation Check

Installation Check: Part Three

R/3 System

R

© SAP AG

BC360 Technical Core Competence

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

R

© 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.

BC360 Technical Core Competence

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

R

© 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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

R

© 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

BC360 Technical Core Competence

2-410

BC360

Installation Check

Transport Management System Set up Process

Transport routes

Configuration of tp

Transport domain & domain controller

R

© 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.

BC360 Technical Core Competence

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

R

© 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.

BC360 Technical Core Competence

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

R

© 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.

BC360 Technical Core Competence

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

R

© 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

BC360 Technical Core Competence

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).

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

R

© 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.

BC360 Technical Core Competence

2-417

BC360

Installation Check

Summary of this Unit
Now you are able to:
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

R

© SAP AG

BC360 Technical Core Competence

2-418

BC360

Installation Check

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. Course participants can also use these exercises after the course, to consolidate what they have learned.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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.

Configuration Documentation
Development System <DEVSID> R/3 System: System name Database system R/3 Release Operating system Installation number <DEVSID>

BC360 Technical Core Competence

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>.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

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>.

BC360 Technical Core Competence

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 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

X

4.2 4.3 X

BC360 Technical Core Competence

2-426

BC360

SAP O nline Service System

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

SAP Online Service System

© SAP AG

BC360 Technical Core Competence

2-427

BC360

SAP O nline Service System

SAP Online Service System
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.

BC360 Technical Core Competence

2-428

BC360

SAP O nline Service System

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

BC360 Technical Core Competence

2-429

BC360

SAP O nline Service System

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

BC360 Technical Core Competence

2-430

BC360

SAP O nline Service System

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.

BC360 Technical Core Competence

2-431

BC360

SAP O nline Service System

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

BC360 Technical Core Competence

2-432

BC360

SAP O nline Service System

OSS Functionality: Database Search Utility
Entry: R/3 Note Search
Search terms

Language

E

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.

BC360 Technical Core Competence

2-433

BC360

SAP O nline Service System

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

P

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

BC360 Technical Core Competence

2-434

BC360

SAP O nline Service System

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.

BC360 Technical Core Competence

2-435

BC360

SAP O nline Service System

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.

BC360 Technical Core Competence

2-436

BC360

SAP O nline Service System

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.

BC360 Technical Core Competence

2-437

BC360

SAP O nline Service System

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.

BC360 Technical Core Competence

2-438

BC360

SAP O nline Service System

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.

BC360 Technical Core Competence

2-439

BC360

SAP O nline Service System

Overview

OSS Overview OSS Functionality Access to OSS
Custom er-controlled remote connection Network security - SAProuter

© SAP AG

BC360 Technical Core Competence

2-440

BC360

SAP O nline Service System

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.

BC360 Technical Core Competence

2-441

BC360

SAP O nline Service System

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.

BC360 Technical Core Competence

2-442

BC360

SAP O nline Service System

SAPNet

SAP Public Homepage SAPNet TechNet

© SAP AG

BC360 Technical Core Competence

2-443

BC360

SAP O nline Service System

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.

BC360 Technical Core Competence

2-444

BC360

SAP O nline Service System

SAPNet

Public Homepage SAPNet TechNet

© SAP AG

BC360 Technical Core Competence

2-445

BC360

SAP O nline Service System

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.

BC360 Technical Core Competence

2-446

BC360

SAP O nline Service System

SAPNet
Assistant
Inbox Outbox SAPNet Index Favorites

http://sapnet.sap-ag.de

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.

BC360 Technical Core Competence

2-447

BC360

SAP O nline Service System

SAPNet
Assistant Information
Key Topics SAP Solutions Implementation Investors Partners Events Media

http://sapnet.sap-ag.de

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.

BC360 Technical Core Competence

2-448

BC360

SAP O nline Service System

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

http://sapnet.sap-ag.de

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

BC360 Technical Core Competence

2-449

BC360

SAP O nline Service System

SAPNet
Assistant Information Communication Service
SAPNet Service Index Media Center Strategy Support Services Consulting Services Education Services

http://sapnet.sap-ag.de

© 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).

BC360 Technical Core Competence

2-450

BC360

SAP O nline Service System

SAPNet
Assistant Information Communication Service Self Service
Quick Sizing Brochure Ordering Service Quote/Inform ation Helper Application

http://sapnet.sap-ag.de

Settings
© SAP AG

SELF SERVICE provides the following topics: Quick Sizing Brochures Service Quote/Information Helper Applications SETTINGS contains: Personal defaults for SAPNet

BC360 Technical Core Competence

2-451

BC360

SAP O nline Service System

SAPNet

Public Homepage SAPNet TechNet

© SAP AG

BC360 Technical Core Competence

2-452

BC360

SAP O nline Service System

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

BC360 Technical Core Competence

2-453

BC360

SAP O nline Service System

Summary of this Unit

Now you are able to:
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

BC360 Technical Core Competence

2-454

BC360

SAP O nline Service System

Unit Actions
Do the exercises

?

Answer the questions Fill in the blanks

Solutions for the exercises Answer the questions

© SAP AG

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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.

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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

BC360 Technical Core Competence

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:

X

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

X

OSS users with the correct authorizations OSS provides customers with bundles of fixes known as: Care Packages Electronic Parcels

X

Hot Packages Solutions to problems raised through OSS are: Printed out and mailed back to the customer

X

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:

X

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

BC360 Technical Core Competence

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

X

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

X

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:

X

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:

X

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

X

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

BC360 Technical Core Competence

2-461

BC360

SAP O nline Service System

Further Documentation

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
Now you are able to:
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

R

© SAP AG

BC360 Technical Core Competence

2-462

BC360

BC360 Technical Core Competence

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

R

© SAP AG

BC360 Technical Core Competence

2-464

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->