A company which develops its own programs would like to assess the system load generated by those programs.
Task 1: Architecture and System Overview
This exercise involves collecting information about the training system.
1. What is the system name (SID) of the present training system, what database is used and what operating system does the database run on?
2. How many instances does the system have? What instance are you logged on to?
3. How many work processes of the dialog type are there on your instance?
Which dialog work processes show the greatest CPU time? (the CPU time allocated to the WP)
Task 2: Workload Analysis
The object of this exercise is to identify programs and transactions that place the greatest strain on the system.
1. What is the average response time for dialog work processes (D-WPs) today?
2. Compare this time with the average DB and CPU times. How do you assess the results?
3. Which programs and transactions that ran today used the most resources in terms of total runtime? Which ones show the highest database access times?
Are any user-defined “Z programs” among the ten most expensive?
4. In the transaction profile, select a user-defined program (Z program) and re-analyze the response time for it and its components. What do you notice?
Continued on next page
Task 3: Database Performance Monitor
The object of this task is to analyze details about the database, such as the cursor cache.
1. How large is the database buffer of your database (database cache)? How many buffer and disk accesses have occurred since the database was started?
Task 4:
The object of the following task is to write your own program and then identify it in the cursor cache.
1. Write a new program named Z_##_DB_ACCESS that accesses the table of your choice. Do not read too much data. If the table is a very big one, restrict the volume using a suitable WHERE clause or limit the amount of data using an UP TO 10000 ROWS.
2. Start your program and then try to identify it in the cursor cache. Trace the program from the cursor cache back to the calling ABAP program.
Solution 1: Architecture and System Overview
Task 1: Architecture and System Overview
This exercise involves collecting information about the training system.
1. What is the system name (SID) of the present training system, what database is used and what operating system does the database run on?
a) The system ID can be found in the status bar. You can also navigate to System -> Status. At bottom left you will find information about the application server you are logged on to and the operating system you are using; adjacent to that is information on the database.
2. How many instances does the system have? What instance are you logged on to?
a) SM51 lists the instances in the system (that is, the active ones!
Instances that have been closed are not displayed).
The instance name is comprised of the computer name (host), the system ID (the DB name) and the two digit instance number. The system status tells you which instance you are currently logged on to (in the Servername field).
3. How many work processes of the dialog type are there on your instance?
Which dialog work processes show the greatest CPU time? (the CPU time allocated to the WP)
a) Navigate to SM50 (work process overview). It displays all work processes on your instance. The dialog work processes (D-WP) are indicated by the identifier DIA. If you click the CPU icon (clock icon), the system displays the CPU time allocated to the work processes. You will notice that the time decreases as you go down.
The dispatcher distributes the user requests from top to bottom. The D-WP with number 0 is therefore always the first to receive work from the dispatcher. Your request will thus be distributed across the work processes from top to bottom in the list in SM50. If a D-WP is currently occupied, the request is redirected. The requests of a particular user are thus not necessarily tied to a particular D-WP. This behavior is known in SAP architecture lingo as work process multiplexing.
Continued on next page
Task 2: Workload Analysis
The object of this exercise is to identify programs and transactions that place the greatest strain on the system.
1. What is the average response time for dialog work processes (D-WPs) today?
a) Navigate to the workload monitor (ST03). By clicking Workload in the tree display at left, you can select you instance and the current day.
The average response time in ms is displayed on the right half of the screen under Task type - dialog.
2. Compare this time with the average DB and CPU times. How do you assess the results?
a) You will find the times you are searching for to the right of the average response time. The rule of thumb says both should be under 40% of the response time.
3. Which programs and transactions that ran today used the most resources in terms of total runtime? Which ones show the highest database access times?
Are any user-defined “Z programs” among the ten most expensive?
a) In ST03 under Analysis View, switch to Transaction Profile - Standard.
All executed programs and transactions are displayed on the right side of the screen. You can select columns and sort them according to various criteria.
4. In the transaction profile, select a user-defined program (Z program) and re-analyze the response time for it and its components. What do you notice?
a) The DB and CPU times should be under 40% here too. If the database portion is substantially above 40%, you should take a closer look at the code for database accesses. This will be addressed later in the course.
Task 3: Database Performance Monitor
The object of this task is to analyze details about the database, such as the cursor cache.
1. How large is the database buffer of your database (database cache)? How many buffer and disk accesses have occurred since the database was started?
a) Navigate to ST04 (or ST04OLD since SAP NW 7.0 SP12) There, under Overview, you will find information about Logical Reads and Physical Reads. You can get more information about these fields via the F1 key.
Continued on next page
Task 4:
The object of the following task is to write your own program and then identify it in the cursor cache.
1. Write a new program named Z_##_DB_ACCESS that accesses the table of your choice. Do not read too much data. If the table is a very big one, restrict the volume using a suitable WHERE clause or limit the amount of data using an UP TO 10000 ROWS.
a) Proceed as usual in programming selects. You can use the instructor's demo programs for orientation.
2. Start your program and then try to identify it in the cursor cache. Trace the program from the cursor cache back to the calling ABAP program.
a) You navigate to the database cursor cache via ST04 and SQL Statement Analysis –> Shared Cursor Cache.
In releases prior to 7.0 , you navigate via ST04 -> Detail Analysis ->
SQL Requests. You can also use this classical DB Performance Monitor interface in releases under 7.0 via transaction code ST04OLD.
Then you have to select the time period you wish to display. Also filter the tables in the SQL commands field with *<table>*. In the button or toolbar there is a function for going to the calling ABAP program.