SAP Elective Course Administration of MySAP. Unit 1: Fundamentals

Transcription

1 Unit 1: Fundamentals

2 Elective Course Process of a System Logon To be able to create a connection between the front end and an instance of an SAP system, the sapgui.exe program requires various information in the form of start parameters. This parameter string is normally created by the saplogon.exe program using information about the system selected for logon. This information comes partly from the configuration files of SAP Logon, and partly from a direct request to the message server of the selected system (see steps 1 and 2 in the following figure). SAP Logon then starts the SAP GUI with these specifications. In this way, an instance with good performance is selected for logon in the case of a logon using logon groups. Page 2

3 Elective Course Process of a System Logon Page 3

4 Elective Course Process of a System Logon After the transfer of the logon screen from the dispatcher to the front end (not shown in the figure), SAP GUI sends the user.s logon data to the instance (step 3 in the above figure). After the dispatcher has determined a free work process to process the logon, it transfers the logon data to this work process (step 4). The work process, in turn, checks whether the received combination of user ID and password is known to the system using a request to the database (steps 5-8). A positive response from the database prompts the work process to return the initial screen of the system to the front end. During a logon session, the assignment of the user to the instance is unique. Only during a new logon can the user possibly be assigned to a different instance by the message server. Page 4

5 Elective Course Work Process Multiplexing The processing of a transaction that consists of multiple screens is usually executed using multiple, different dialog work processes. This distribution is called work process multiplexing. Work process multiplexing means that a system function whose content is logically connected but which consists of multiple substeps can be processed by various dialog work processes. These steps whose content is connected are described as transactions. A transaction that consists of multiple screens, such as screens 100 and 200 can also be processed by multiple dialog work processes. Page 5

6 Elective Course Work Process Multiplexing The figure shows two screens of a transaction (100 and 200), for which the input is handled by two different dialog work processes. The multiplexing procedure is used exclusively for dialog work processes. All other work process types process entire functions; that is, complete business processes. As dialog work processes may therefore process only parts of transactions that are connected from a business point of view; the update procedure with the update work process is widely used in SAP systems. Page 6

7 Elective Course Work Process Multiplexing Page 7

8 Elective Course Setting up SAP Logon The SAP Logon programprovides users with a convenient logon to an SAP system with the SAP GUI for Windows (from Windows-based front ends). SAP Logon evaluates various configuration files that are stored on the front end. These files can also be edited using SAP Logon. Page 8

9 Elective Course Setting up SAP Logon Page 9

10 Elective Course Setting up SAP Logon You can make various general settings through the SAP Logon Options (see figure above). You can, for example, set the trace level for SAP GUI connections in this way. Passwords can also be written to the the trace file generated in this way, so you should use this option only with great care; the trace files should be deleted afterwards. The settings for a connection can be changed using the Properties button, such as its name in SAP Logon, and through the Advanced button (on the Properties dialog box), you can, for example, restrict the amount of data transferred (system to front end), to take account of slow network connections. Page 10

11 Elective Course Setting up SAP Logon You can use the Groups... button (for "group selection") to create a new connection to a system. This connection uses the logon groups concept, meaning that the message server always assigns a new logon to the instance with the best performance in the selected logon group. The configuration file sapmsg.ini is evaluated to display the systems available for selection. The message server of the selected systemis queried to discover the available logon groups. So that the connection to the message server of the system specified in sapmsg.ini works, it is necessary for the Microsoft Windows file services to specify the correct message server communication port for the selected system ID. A connection is then created to the relevant host and the message server running on it using the information from sapmsg.ini and services. Page 11

12 Elective Course Setting up SAP Logon Page 12

13 Elective Course Setting up SAP Logon The Server... button allows you to create a connection to a specific instance of an SAP system. As with the Groups... button, information about the instances that are available for selection is collected from the message server. With the New... button, you can create a connection to an SAP system that need not be listed in the sapmsg.ini and services files. Therefore, you enter all of the systeminformation that is relevant for a logon here yourself. The name of the host on which you want to contact an instance, and its system or instance number is essential. The instance number specifies the last two digits of the 4 digit port address through which the dispatcher of the specified instance can be contacted. The first two digits are fixed, and are 32. his means that port numbers between 3200 and 3299 are possible. Page 13

14 Elective Course Setting up SAP Logon If you do not want to allow users to edit the system entries, you can use the SAP Logon Pad program. Which files are stored where? The following list shows the files with their possible storage locations; in the case of multiple possible locations, the search sequence is shown: saplogon.ini, sapmsg.ini, saproute.ini: SAPGUIdirectory Windows directory services: WINNT system32 drivers etc Services Page 14

15 Elective Course Using Logon Groups SAP systems sometimes have significantly more than just one or two assigned instances. Each of these instances provides buffer areas for various objects,such as for programs, dictionary objects, screen structures, and table contents. These buffers are filled with data and continuously updated during the runtime of an instance; that is, the system attempts, using various algorithms, to organize the contents of the buffer so that the frequently queried data is in the buffer. Data that is used frequently but changes only very rarely is buffered. This means that a cross-section of all programs called on this instance is collected, especially in the program buffer. Page 15

16 Elective Course Using Logon Groups If a large number of different applications are run, old buffer contents may be replaced with newly requested contents. This means that the next time the older contents are called, they must be requested from the database again. This reduces the response time behavior of the system, in some circumstances to an appreciable extent. A solution would be to create a program buffer that was sufficiently large to contain all requested programs. Page 16

17 Elective Course Programm Buffer Without the Use of Logon Groups Page 17

18 Elective Course Using Logon Groups An alternative solution is the logon group concept explained in the following text. Using logon groups, you can group instances with transaction SMLG (Tools CCMS Configuration Logon Groups). In our example, four instances are assigned to the logon group SD, and three instances to the logon group FI. The message server of the system also has these details within five minutes after the new group definitions are saved. From now on, you can access these groups using group selection in SAP Logon. Page 18

19 Elective Course Programm Buffer with the Use of Logon Groups Page 19

20 Elective Course Effects of Logon Groups In our example: With a logon using a logon group, the SAP Logon program connects to the message server of the system, and receives from it the name of the currently best performing instance of the selected logon group. SAP Logon then starts the SAP GUI program with the connection parameters for the selected dispatcher. Within a logon group, end users are, for example, only using a particular application. In the example, these are the FI and SD applications. Therefore, the buffers on the instances of each of the logon groups are filled with contents from these applications. Page 20

21 Elective Course Effects of Logon Groups This means that the program buffer of each of the instances shown contains fewer different programs than they would without the use of logon groups. This has two possible advantages as a consequence: 1. The program buffers can be set up more economically (smaller). 2. Less swapping is performed for the program buffers, and they therefore perform better. If it is possible to set up very large program buffers (>1GB), setting up logon groups for the purpose described above would no longer provide any relevant advantages. This means that a single logon group (with the possible exception of the central instance, as implicitly assumed above) is the most useful. This has, for example, the name PUBLIC. By default, every instance is assigned to the logon group SPACE. Page 21

22 Elective Course Practical Exercises I Clear Existing SAP Logon Entries As there could already be entries in your local SAP Logon from other lessons. Set up SAP Logon Using the Groups Button Choose the Groups... button and create a new entry. Use the data that your instructor gives you (system ID, host name) for this entry. Page 22

23 Elective Course Practical Exercises II Using Logon Groups through Group Selection in SAP Logon In SAP Logon, choose the Groups... button again to add a new entry. Log on to your system using the new entry in your SAP Logon. Page 23

24 Unit 2: Starting and Stopping

25 Elective Course Starting SAP / Database The starting of an SAP system is the basic prerequisite for being able to work with the system. Restarts of SAP systems are also required after maintenancework on the hardware in use and changes to the SAP system.s profile. Starting an SAP system is an initial process with which every administrator should be familiar. Starting an SAP System is performed in a number of steps and is the task of the operating system user <sid>adm. Page 25

26 Elective Course Starting SAP / Database Page 26

27 Elective Course Starting Database Start the database: The underlying element of the entire SAP system is the database. Before the SAP instances are started, this must have operational status. The database is therefore always started as the first step. Page 27

28 Elective Course Starting Database When an Oracle database is started, it goes through three phases: NOMOUNT In the NOMOUNT phase, the parameter file is opened and evaluated, and the database instance is started. Operating system resources are allocated using configuration information stored in the parameter file. MOUNT In the MOUNT phase, the control files of the database are opened (using the value of parameter CONTROL_FILES from the parameter file) and evaluated. The system reads the information about the physical structure of the database. Although data files and logs are not yet opened, parts of the data dictionary are loaded, so V$views are available. - If one or more of the files specified by the CONTROL_FILES initialization parameter does not exist or cannot be opened when you attempt to Page 28 mount a database, Oracle returns a warning message and does not mount the database.

29 Elective Course Starting Database When an Oracle database is started, it goes through three phases: OPEN In the OPEN phase, all remaining files of the database system are opened. If required, an instance recovery is performed during opening the database. Only when the database is open, valid database users can connect to the database. - If one or more of the data files or redo log files is not available or cannot be opened when attempting to open a database, Oracle returns a warning message and does not open the database. Page 29

30 Elective Course Starting Database Page 30

31 Elective Course Starting SAP Start the central instance: Next, the operating system collector SAPOSCOL is started, if it is not already active. This is a standalone program that runs in the operating system background, independently of SAP instances. It collects data about operating system resources and makes this data available through the shared memory of all SAP instances. The central instance with the message server and the dispatcher and ist work processes is then started. Only once the message and enqueue servers are active can other instances be started, if desired Page 31

32 Elective Course Starting SAP Start other instances: If the dialog instance is not running on the same host as the central instance, the SAPOSCOL operating system collector is first started on this host. The dispatcher is then started with its work processes Page 32

33 Elective Course Starting SAP Page 33

34 Elective Course Starting SAP To start the central instance call the shell script startsap_<host>_<instance no> in the home directory of the <sid>adm user. If there is only one instance for each application server, the alias startup points to the script startsap_<host>_<instance no>. The script startsap first starts the saposcol process, which collects statistical data for the operating system and provides it to the SAP system. The next step is a check to see if the database is running. If not, the script startdb is called to start the database. The final step starts all of the processes for the instance (message server, dispatcher, work processes, and so on). After the central instance is started, you can optionally start other instances. Page 34

35 Elective Course Starting SAP The startsap script can be called with the following options: DB: Starts the database system R3: Starts the instances and associated processes for the instance ALL: Starts the database system and the instance (default setting, can be omitted) To start the SAP system, the startsap script calls the sapstart process with the start profile specified in the script in the variable START_FILES. Page 35

36 Elective Course Logging the Start Process of SAP Logs about the start process of the SAP system are stored in the file system. If there are problems during the start, these logs can provide useful information such as error messages or problem descriptions. These files are stored in the home directory (DIR_HOME) of the relevant instance. The log files STDERR<n> are created by the SAP service during the start process. The starting processes write to the individual files, depending on the sequence in which they are listed in the start profile. The contents of these log files therefore depends on the individual system setup, and could, for example, be as follows: STDERR1: Information about the start process of the database system. STDERR2: Information about the start process of the message server. Page 36 STDERR3: Information about the start process of

37 Elective Course Logging the Start Process of SAP You can set the granularity of the logged information to four levels using the profile parameter rdisp/trace. The possible values for this parameter are: 0:Errorsonly 1: Error messages and warnings (Default) 2: Error messages and a short trace 3: Error messages and a complete trace The higher the trace level, the larger the amount of logged information, and therefore the larger the size of the files. You should therefore only increase the default value for short periods for problem analysis. The trace level can be set separately for individual work processes in the process overview (transaction SM50). Page 37

38 Elective Course Logging the Start Process of SAP If the SAP system does not start correctly, this can have a variety of causes. To analyze the problem, proceed as follows: Check the status of the respective database system using the error log files. Check the error files stderr<n> that were created Check the trace files of the individual SAP work processes: dev_ms : Developer trace for the message server dev_disp : Developer trace for the dispatcher dev_w<m> (m is the work process number): Developer trace for the work process If you can still log on to the SAP system, check the system log of the SAP system using transaction SM21. Page 38

39 Elective Course Logging the Start Process of SAP Page 39

40 Elective Course Logging the Start/Stop Process of Database (Oracle) The Oracle database logs all significant events such as starting and stopping the database and error messages in the file <Drive>:\oracle\<SID>\saptrace\background\<SID >ALRT.LOG. Detailed information about errors is logged in the Oracle Trace File: <Drive>:\oracle\<SID>\saptrace\usertrace\Ora<no >.trc. If the system administrator administers the database with sapdba, this writes its own log files in the following directories: <Drive>:\oracle\<SID>\sapreorg <Drive>:\oracle\<SID>\sapcheck <Drive>:\oracle\<SID>\sapbackup Page 40

41 Elective Course Logging the Start/Stop Process of Database (Oracle) Page 41

42 Elective Course Stopping SAP / Database It can be necessary to stop an SAP system for a variety of reasons, such as to restart after permanently changing profile parameters, before installing kernel patches, or to allow hardware upgrades to be carried out. Page 42

43 Elective Course Stopping SAP Page 43

44 Elective Course Stopping SAP Before you stop the system, you should check the status of the system. This involves, among other things: ActiveUsers: Check which users are logged on using the User List (SM04). Background Processing : Check which jobs are active using the Job Overview (SM37). If jobs are terminated by the system stop, these must be rescheduled. Jobs that are scheduled for the time in which the system is stopped run automatically once the system is restarted. BatchInput: The transaction Batch Input: Session Overview (SM35) displays running batch input jobs. Page 44

45 Elective Course Stopping SAP Before you stop the system, you should check the status of the system. This involves, among other things: Update: Use the Update Overview (SM13) to check whether update processes are terminated by the system stop. These update records are rolled back during the stop, and these are set to the status init. These records are then updated again during the restart. Before you stop your system, you should inform users using a system message (SM02). Page 45

46 Elective Course Stopping SAP When you stop the SAP system, you should first stop all dialog instances and then stop the central instance. You have two options for doing this: Log on under UNIX as the SAP administrator (<sid>adm) at operating system level and enter the command stopsap from your home directory. The stopsap script can be called with the following options: DB: Stops the database system with the help of the stopdb script R3: Stops the instances of the SAP system ALL: Stops the database system and the instance (default setting, can be omitted) The database can be stopped separately with database tools. Page 46

47 Elective Course Stopping SAP Page 47

48 Elective Course Practical Excersises Because of only 1 Testserver, these Excersise will be defined from your teacher. Page 48

49 Unit 3: Systemconfiguration

50 Elective Course Parameters in SAP The configuration of the individual instances and therefore of the SAP system is performed using system parameters. The default values for theseparameters are defined in the program code of the kernel. You can change these default values using the profile files, which are read when an instance is started. These profile files are created during the installation of the system and can also be edited later. As the profile files are only read when the system is started, you must restart the instance or the entire system after changing parameters. Dynamic switching; that is, while the system is running, is only possible for a small number of system parameters. Page 50

51 Elective Course Parameters in SAP Page 51

52 Elective Course Parameters in SAP The profile files are automatically created during installation. After installation is complete, the profile files are stored at operating system level in the directory: \usr\sap\<sid>\sys\profile. This directory can be read by all instances of an SAP system using the share or mount technique. The SAP system has three system profiles. These are: Start profile Defaultprofile Instance profile In principle, you can change these files with operating system resources (editors). In doing so, the user must ensure himself or herself that the changes are performed correctly. Incorrectly set parameters can lead to the system not starting. It is far more convenient and safer to change the profile parameters using the resources in the SAP system. Page 52

53 Elective Course Parameters in SAP Page 53

54 Elective Course Parameters in SAP The instance-specific start profile (START<instance><instance number>_<hostname>), specifies for each instance which processes are to be started. These are, for example, the message server and the dispatcher. There is only one default profile (DEFAULT.PFL) for each SAP system, and it is read by all instances. It contains system-wide settings, such as the system name, the name of the database server, the name of the enqueue server, or also the default logon client. The instance profile (<SID>_<instance><instance number>_<host name>) defines parameters that apply for one instance, such as the number and type of work processes, or the definition of the size and allocation of the main memory area used by the SAP system, and is therefore instance-specific. Page 54

55 Elective Course Parameters in SAP Page 55

56 Elective Course Parameters in SAP There are two ways to do this. These are: report RSPFPAR and transaction RZ11. Both functions display the system parameters for the instance to which the user is currently logged on. Report RSPFPAR displays a list of all instance-specific system parameters, along with the parameters that apply system-wide. You can restrict this list to specific parameters. A table displays the system default value for the individual parameters, as it is defined in the program code of the kernel, and, if the default value has been overridden by a profile parameter, the userdefined value. A short description and, if required, documentation for the parameters can also be displayed. Transaction RZ11 displays information and documentation for individual profile parameters. It also displays whether the parameter can be changed while the system is running with the Dynamically Switchable indicator. Page 56

57 Elective Course Parameters in SAP Page 57

58 Elective Course Practical Excersises Determine Values of System Parameters Determine the values of a number of system parameters. Determine the values of the following system parameters: Name of the application server, number of work processes on the central instance (dialog, background, enqueue, update, spool) maximum number of sessions permitted per logon Page 58

59 Elective Course Configuring SAP System Parameters If you want to change profile parameters, you can make these changes using operating system-specific editors. However, this procedure has certain dangers, as the user must ensure himself or herself that the changes are performed, and also documented, correctly. Incorrectly set parameters can prevent an instance starting. The SAP system therefore provides integrated profile administration and parameter maintenance. Page 59

60 Elective Course Configuring SAP System Parameters Page 60

61 Elective Course Configuring SAP System Parameters Profile administration in the SAP system offers the following advantages to the user: Centraladministration and maintenance of the instances Changes in profiles are checked for consistency Administration of multiple versions of a profile Comparison of the actively used profile and the profile stored in the database Immediate activation of selected parameters Page 61

62 Elective Course Configuring SAP System Parameters After installation, the profile parameters are, at first, only present at file level. To be able to use the profile administration of the SAP system, the profiles must be imported into the database. During this import, the system performsa consistency check and a check of the way in which the parameters interact. Changes to profile parameters can then be performed in the SAP system, with the previously mentioned advantages. These are then stored in the database, and written back to file level. These changes only take effect when they are read by the system; that is, at a restart of the system. Page 62

63 Elective Course Configuring SAP System Parameters You perform the administration and maintenance of profiles in transaction RZ10. In the first step, you import the profiles into the database by choosing Utilities Import Profiles Of active servers. After selecting the profile to edit, you can change individual profile parameters. There are three different levels for maintaining the profiles. The administration data contains the type of profile (start, default, or instance profile), a short description, the path of the file, the name of the instance, and the time of the last activation. Page 63

64 Elective Course Configuring SAP System Parameters You can perform the maintenance of the parameters of the individual profiles through either basic maintenance or extended maintenance. Basic maintenance allows you to adjust themost important parameters and supports the user through the use of logical descriptions. Extended maintenance displays the unformatted content of the profile; that is, the technical names of the profile parameters. In extended maintenance, you can not only change the values of individual parameters, but also add new parameters and delete existing parameters. The changes are stored in two steps. In the first step, the changes are temporarily copied when you choose Copy. The values are permanently saved to the database in a second step when you choose Save. The changes are therefore successfully saved to the database and must now be written at operating system level. This is done either automatically during saving by confirming the relevant query or manually from the menu by choosing Page 64

65 Elective Course Configuring SAP System Parameters Page 65

66 Elective Course Configuring SAP System Parameters Changes to instance-specific profiles take effect after a restart of the corresponding instance. Changes to the default profile take effect only after a restart of all instances in the entire system. Changes to these files are, however, the exception rather than the rule. Page 66

67 Elective Course Practical Exercises I Import and Maintain Profiles Use transaction RZ10 (Tools CCMS Configuration Profile Maintenance) to perform the following tasks. Import all profiles into your SAP system. Change the values of the following parameters: Set the value for the maximum number of permitted sessions to 7. Increase the number of dialog work processes for the dialog instance by 2. Consider which profiles you are performing changes in. Save and activate your changes. Check your changes in the system. To do this, log on to the system again and check the number of work processes in the process overview. Page 67

68 Elective Course Practical Exercises II Import and Maintain Profiles Use transaction RZ10 (Tools CCMS Configuration Profile Maintenance) to perform the following tasks. Check your changes in the profile files at operating system level. What must you still do, so that your changes take effect in the system? Activating the Changed Profile Parameters Check the changed system parameters after a system restart. Restart the system so that your changes become active. Check your changes in the system again. Page 68

69 Elective Course Parameters in Oracle (Database-Parameters) The instance for an Oracle database is started using an initialization parameter file. Parameters contained in this file configure especially the System Global Area and Oracle background processes. Oracle has traditionally stored initialization parameters in a text initialization parameter file, usually called init<dbsid>.ora. Starting with Oracle9i, you can choose to maintain initialization parameters in a binary server parameter file (logically called SPFILE, the physical name being spfile<dbsid>.ora or spfile.ora). This is a server-side initialization parameter file, maintained on the machine where the Oracle database server executes. Page 69

70 Elective Course Parameters in Oracle (Database-Parameters) Oracle allows you to set, change, or delete (restore to default) values of some initialization parameters dynamically. However, if you use the traditional initialization parameter file, such a change affects only the currently running instance, since there is no mechanism for automaticallyupdating initialization parameters on disk. They must be manually updated in order to be used by the instance after a shutdown and restart. Using a server parameter file overcomes this limitation because initialization parameters stored in a server parameter file are persistent, in that any changes made to the parameters while an instance is running can persist across instance shutdown and startup. Page 70

71 Elective Course Parameters in Oracle (Database-Parameters) Page 71

72 Elective Course Parameters in Oracle (Database-Parameters) When an Oracle instance is started without the specification of a special profile (parameter file), it searches the default location for a file with one of the following names (in this order): spfile<dbsid>.ora spfile.ora init<dbsid>.ora init.ora The search is finished as soon as one of the files is found, and the instance is started using that profile, which is normally an SPFILE. But if no SPFILE exists in the default directory, the instance is started with the standard initialization file. This means, you can use the init file as a kind of backup for your SPFILE. Onemore reason for keeping the init file consistent with the SPFILE. Page 72

73 Elective Course Configuring Oracle Parameters Those Oracle parameters that can be immediately modified in memory are called dynamic. Changes of static parameters need a restart of the Oracle instance. The classification of Oracle parameters into static and dynamic is independent on whether server parameter file is used or not. As alreadymentioned, usage of a server parameter file just simplifies maintenance of dynamic parameters. To modify an Oracle parameter, start BRTOOLS or BRGUI and select Instance management Alter database parameters. If you already knowthe parameter to change, enter it in Database parameter (parameter) and continue. If you want to select the parameter from a list, do not change anything and just press c to continue and select Alter database parameter and enter the position number of the Page 73 parameter (not the name) you want to change from the

74 Elective Course Configuring Oracle Parameters Page 74

75 Elective Course Practical Excersises First a server parameter file for Oracle is created from init<dbsid>.ora, then a parameter is changed. Create the server parameter file from init<dbsid>.ora Change parameter open_cursors to value 600. Is it possible to perform this dynamically? Check the setting before and after restarting the database. Page 75

76 Unit 4: Background Tasks

77 Elective Course Background Tasks Dialog work processes should be able to respond to end users. Requests quickly. Dialog resources should therefore not be burdened with long-running programs. This can lead to bottlenecks in the dialog response time. The system profile parameter rdisp/max_wprun_time exists for this reason. It limits the maximum runtime of a dialog step within a dialog work process. This should ensure that dialog work processes are not blocked by long-running programs, interfering with online operation. After the maximum runtime has elapsed, the program is terminated. Page 77

78 Elective Course Background Tasks You can use the background work processes for longrunning tasks. These are sometimes also called batch work processes. Normally, background processing is used not only for long-running, but also for recurrent tasks. Examples of this type of task are the daily database backup or the month end work for financial accounting. Page 78

79 Elective Course Background Tasks Page 79

80 Elective Course What is a background job? A background job consists of one or more steps (job steps). A step can be: An ABAP program An external command An external program Every job is processed without interruption by one single background work process. Background jobs can be scheduled with different priorities: Class A (highest priority) Class B (medium priority) Class C (normal priority) If a job should be executed on a particular server or server group, it is handled preferentially compared to other jobs with the same class. This preference only applies if multiple jobs of various priorities request background processing at the same time, for example, because they are scheduled for the same time. Page 80

81 Elective Course What is a background job? Page 81

82 Elective Course What can be performde in the background? Page 82

83 Elective Course Start criteria of a background job A job can be triggered: By scheduling it on a particular date at a particular time (this includes the start time immediately, if there are no free background work processes available when the job is scheduled). By the occurrence of a particular event defined in the SAP system (this includes jobs that are to start after other jobs or at operation mode changes, or jobs with immediate start if there are free background work processes available when the job is scheduled). Page 83

84 Elective Course Start criteria of a background job Page 84

85 Elective Course Defining a job Required specifications when defining a job are: General specifications such as job name, job priority (Default: C ) and (optionally) target server (group) Definition of one or more job steps Definition of start conditions (time- or eventcontrolled) The JobWizard supports you when defining jobs, by leading your through the individual steps listed above. However, with the Job Wizard - unlike with classical scheduling you cannot perform individual steps with different users. Page 85

86 Elective Course Defining a job Page 86

87 Elective Course Job Monitoring You can select jobs using various criteria on the initial screen of this transaction. In this way, you can display all jobs that contain a particular job step, that have a particular status, or that react to a defined event (for this, you must select a particular event or * ). You can navigate to other job-specific views from the job overview shown above: The spool list contains the output lists for ABAP programs (if they exist). The job details contain, among other information, the job definition, duration of the processing of the job, and the start time of the job. You can adjust the layout of the displayed list to your requirements by adding or removing additional fields. All messages output by a background program are stored in the job log. You can display this log to obtain information about a program that terminated with errors or Page 87 to perform a detailed investigation about a background

88 Elective Course Job Monitoring Page 88

89 Elective Course Job Status A job can have the following statuses: Scheduled The steps of which the job consists have already been defined, however the start condition must still be defined. Released The job has been completed defined including its start condition. A job cannot be released without a start condition. Only an administrator or a user with the relevant authorizations for background processing can release a job. This ensures that unauthorized users cannot execute jobs without approval. Ready The start condition of a released job has been fulfilled. A job scheduler has placed the job in the wait queue for a free background work process. Page 89

90 Elective Course Job Status A job can have the following statuses: Active The job is currently being executed and cannot be deleted or changed. If an active job does not seem to be running correctly (that is, for example, it is running for an exceptionally long time), you can terminate it in a background work process in debugging mode, analyze it, and then either release it again or completely terminate it. To do this, in transaction SM37, choose Job Capture: active job. To capture a background job, you must be logged on to the SAP server on which the job is running. Page 90

91 Elective Course Job Status A job can have the following statuses: Finished All steps of this job were successfully completed. Canceled The job terminated. This can happen in two ways: An administrator deliberately terminates the job in transaction SM37 by choosing Job Cancel active job. A job step is terminated with an error. Page 91

92 Elective Course Job Status Page 92

93 Elective Course Job Status You can still change a job as long as the job still has the status Scheduled or Released. If the execution of the job has already begun, you can monitor the processing in the job log. If the job contains ABAP programs that create output lists, these are stored in spool lists. You can create a new job by copying an existing job by choosing Job Copy. Page 93

94 Elective Course Practical Exercises Check the configuration of your SAP system with regard to background processing 1. How many background processes are configured in your SAP system? 2. What determines the number of available background work processes? 3. How many background jobs can be processed simultaneously? 4. Find out if background work processes are reserved for class A jobs in your system. 5. Assume that all background work processes in your system are currently processing and there are therefore no free resources for other jobs. Can you set up additional background work processes without restarting the SAP system? Page 94

95 Elective Course Time-based Job Scheduling A job can be started in a time- or event-dependent manner. In the case of a time-dependent start of a job, you can choose between the following options: The job should be executed immediately The job should be executed at a particular date/time The job should be executed on a particular work day You can choose to make all time-based start conditions for jobs recurrent. This means that the job is executed again after a defined period of time has elapsed. You can specify exceptions (such as postponement to the following work day in the case of holidays in the factory calendar). The job is started at the specified date and time, in accordance with the job priority and availability of background work processes. Page 95

96 Elective Course Time-based Job Scheduling You can also specify a time period during which the job should be executed. To do this, you specify a time after which the job should no longer be executed. With this function, you prevent periodic jobs being executed at an undesirable time, among other things. For example, a reorganization job that should only be executed at night is delayed. With a start time window, you can avoid this job being executed during the day, when the dialog users are active and there are fewer system resources available. Page 96

97 Elective Course Time-based Job Scheduling Page 97

98 Elective Course Job Load Balancing The profile parameter rdisp/bctime specifies the time period in which thetime-dependent job scheduler is active (see the next figure). The execution of jobs with the start condition immediate usually avoids the time-based scheduler. In this case, the dialog work process of the scheduling user performs the job scheduling. Only if no free resources are found, is the job concerned scheduled in a time-based way. The scheduled start time then corresponds to the time point at which it should have started. Background work processes can be configured on every instance of the SAP system using the profile parameter rdisp/wp_no_btc. Page 98

99 Elective Course Job Load Balancing The number of background work processes required in the SAP system depends on the number of tasks to be performed in the background. The combination of job ID and job name define the job uniquely in the system. On every SAP instance on which background work processes are defined, the time-dependent job scheduler runs every rdisp/btctime seconds. The time-dependent job scheduler checks the job scheduling table in the database for jobs that are waiting for processing. These jobs are transferred to free background work processes in the SAP instance, in accordance with their priority and execution target. Page 99

100 Elective Course Job Load Balancing Jobs that are not assigned any particular execution target can be executed with any free background work process. This means that the workload is automatically distributed between the SAP instances. If a job is explicitly assigned an execution target (such as a selected instance or a group of instances), the special properties of the execution target can be used (for example, you can ensure that a job is performed on a particular operating system, or that the job is executed by a background work process that is running on the same host as the database). This means, however, that you do not have the advantages of automatic load balancing. Page 100

101 Elective Course Job Load Balancing Page 101

102 Elective Course Standard Jobs Standard jobs are background jobs that should run regularly in a production SAP system. These jobs mainly perform certain.clean up jobs. in the system, such as the deletion of obsolete spool requests. In the job definition transaction (SM36), you can access a selection of important standard jobs that you can schedule, monitor and edit by choosing Standard Jobs. If you want to schedule all standard jobs, choose Default Scheduling. All standard jobs that are defined in table REORGJOBS are scheduled with the specified variant and period. If other jobs exist that execute one of the programs of the standard jobs, the system informs you of this. To schedule individual jobs, choose the selected job with the input help and specify an execution period. To define an additional standard job that is not yet available in the selection (table REORGJOBS), choose Predefine new job. Page 102

103 Elective Course Standard Jobs Page 103

104 Elective Course Practical Exercises I Check Profile Parameter Check the frequency with which the time-dependent job scheduler runs. Page 104

105 Elective Course Practical Exercises II Schedule jobs and monitor their execution. Check the job results. 1. Run report RSUSR000 in dialog (transaction SA38).). 2. Run report RSUSR000 using transaction SA38 in the background (start time Execute immediately). 3. In transaction SM36, define the job SIMPLE_##, where ## is your group number. The job should have the following properties: Job class C Consists of the ABAP program RSUSR000 as the only step Immediate start 4. Check whether your job SIMPLE_##has run successfully. Find data that gives details about the start time, steps, and job details (such as client and user name). Is the spool list automatically printed? 5. Determine the execution time of your job SIMPLE_## Page 105 and find out whether it was executed with a delay.

106 Elective Course Practical Exercises III Schedule an ABAP program with a variant. Define the job DISP_PARA_##, where ## is your group number. The job should have the following properties: Job class C Execution of the report RSPFPAR with the variant DISPATCHER as its only step. Start in 2 minutes (referring to system time) Check whether the job was successfully processed. Page 106

107 Elective Course Event-based Job Scheduling An event is a signal to the background processing system that a particular status has been achieved in the SAP system. The background processing system receives events and then starts all jobs that are linked to this event. An application server is specified for the processing of events that are triggered within the SAP system in profile parameter rdisp/btcname. An event-dependent job scheduler is started on this server (unlike the time-dependent job scheduler, which runs periodically on all background servers). This scheduler checks whether a job is waiting for the event that has been received. It is therefore important that the parameter rdisp/btcname contains the name of an active background server Page 107

108 Elective Course Event-based Job Scheduling Event-dependent jobs can be scheduled with one of the following three start conditions: After event The job starts after a defined event is received by the SAP system. At operation mode With this option, you can link a job to the activation of an operation mode when scheduling the job. After job In this way, you can create simple job chains in which the execution of the successor job can be made dependent on the status of the predecessor job. Page 108

109 Elective Course Event-based Job Scheduling Page 109

110 Elective Course Event-based Job Scheduling New events are defined by the system administrator in CCMS (transaction SM62). When doing so, the administrator differentiates between system events and user events. System events are events predefined by SAP that you can neither modify nor trigger. Events can be triggered in various ways: Manually in CCMS for test purposes (transaction SM64) Within an ABAP program (through use of the function module BP_EVENT_RAISE) Outside the SAP system at operating system level using the program sapevt. A parameter can also be transferred when an event is triggered. In this way, you can define jobs that wait for the occurrence of the event together with the specified parameter. Page 110

111 Elective Course Event-based Job Scheduling Page 111

112 Elective Course Practical Exercises I Define a user-defined event and then schedule a job that starts after this event occurs. Trigger the event in the Computing Center Management System (CCMS) and from operating system level. 1. Define the user-defined event MYEVENT_## in the CCMS. 2. Define a job EVENT_##. The job should have the following properties: Job class C Step 1 Execution of ABAP program RSUSR000 Starts after the event MYEVENT_## (eventperiodic) Display your job in the job overview. 3. Trigger the event MYEVENT_## in the CCMS in another session and refresh the job overview. 4. Trigger the event MYEVENT_## at operating system level and refresh the job overview. Page 112

113 Elective Course Practical Exercises II Defining Job Chains Define a job that depends on the job in exercise Define the job SUCCESSOR_## (where ## is your group number), with the following properties: Job class C Execution of ABAP program RSUSR000 Start after the job from exercise 1 has been successfully completed Check the job status in the job overview. 2. What must you do so that the job SUCCESSOR_## is executed? Page 113

114 Unit 5: Database Administration

115 Elective Course Tablespace Administration Creation of a new tablespace, for example as a preparation to move certain tables out of the standard tablespace PSAP<SCHEMA-ID> into a special tablespace Deletion of a tablespace, for example after an upgrade Extending tablespaces by adding a datafile or tempfile or by resizing existing data files Moving datafiles, for example because after adding a new disk a data file which was created on another disk needs to be moved to the new disk This lesson describes the actions of BRTOOLS or BRGUI under the main menu item Space management. Page 115

116 Elective Course Create Tablespace Page 116

117 Elective Course Create Tablespace The creation of a new tablespace is necessary for example in preparation for the upgrade: During the upgrade, the old ABAP programs in PSAP<SCHEMA- ID><Old-Rel> are deleted and the new ABAP programs are imported into the new tablespace PSAP<SCHEMA-ID><New-Rel>. in preparation for an online reorganization of a tablespace, for example to switch from a dictionary managed to a locally managed tablespace. To create a new tablespace use BRTOOLS or BRGUI and select Space management Create tablespace. To enter the main menu mode of BRSPACE, select continue in the next screen and select Create tablespace from the BRSPACE menu. As an alternative, you can start brspace f tscreate and press continue.. Now fill in the necessary information by selecting the appropriate menu items. Page 117

118 Elective Course Create Tablespace The main options and their possible entries are: tablespace Enter the name of the tablespace to be created. According to the SAP conventions, the tablespace name should start with the letters PSAP, followed by the SCHEMA-ID, plus a unique name. contents data for normal tablespaces containing tables and/or indexes temp for a temporary tablespace undo for an undo tablespace space You can select either auto for automatic segment space management (default) or manual for manual segment space management. Page 118

119 Elective Course Create Tablespace The main options and their possible entries are: owner Changing this is only possible if you have multiple components in one database. The owner is SAP<SCHEMA-ID> of the database schema you create the tablespace for. data In the old tablespace layout a tablespace contained either tables (table) or indexes (index). In the new MCOD tablespace layout, tablespaces contain tables and indexes (both). join If in the data field you entered either table or index, you can enter here the corresponding index or table tablespace. In the first case, BRSPACE will create both tablespaces. In the second case, BRSPACE creates only a index tablespace on joins it with Page 119 already existing table tablespace. When you entered

120 Elective Course Create Tablespace After continuing, the menu for the data file properties is shown. file The name of the new data file for the tablespace. The default path and file name follows the SAP naming conventions for data files. autoextend If set to yes, the new data file is created autoextensible. In this case, incrsize and maxsize must be specified. If set to no, incrsize and maxsize cannot be specified and their entries are locked. incrsize For autoextensible data files, this parameter specifies the size in MB, by which the data file is automatically increased when necessary maxsize Page 120 For autoextensible data files, this parameter specifies the