ADM315 Workload Analysis Caderno de Exercícios

ADM315 Caderno de Exercícios

ADM315ADM315 – Workload Analysis

Data

Centro de Treinamento

Instrutores

Website

Caderno de ExercíciosCourse Version: 2004 Q4Course Duration: 3 Day(s)Material Number: 50068903

An SAP Compass course - use it to learn, reference it for work

25-07-2005 © 2005 SAP Brasil. Todos os direitos reservados 1


Copyright

Copyright © 2004 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for anypurpose without the express permission of SAP AG. The information contained herein maybe changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietarysoftware components of other software vendors.

Trademarks

Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.

IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation.

ORACLE® is a registered trademark of ORACLE Corporation. INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM

are registered trademarks of Informix Software Incorporated. UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of

the Open Group. Citrix®, the Citrix logo, ICA®, Program Neighborhood®,

MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.

HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

JAVA® is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc.,

used under license for technology invented and implemented by Netscape.

SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP BusinessWorkflow,WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.

Disclaimer

THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAPEXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED,INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY ANDFITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALSAND THE SERVICE, INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHERMATERIALS AND PRODUCTS CONTAINED HEREIN. IN NO EVENT SHALL SAP BELIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL,



CONSEQUENTIAL,OR PUNITIVE DAMAGES OF ANY KIND WHATSOEVER, INCLUDING WITHOUTLIMITATION LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROM THEUSE OF THESE MATERIALS OR INCLUDED SOFTWARE COMPONENTS.



Conteúdo

Unit 2: Analysis of System …….............………............................ 04Unit 3: R/3 Memory Management …….………….......................... 08Unit 4: Hardware Capacity ........................................................... 14Unit 5: Expensive SQL Statement ………………......................... 17Unit 6: Table Buffering …….............……………........................... 22Appendix 1: Workload Analysis Transactions ………………..... 24Appendix 2: Symptom and Possible Causes …………………… 25Appendix 3: Road Maps ………………………………………..…… 26



Unit 2: Analysis of System

List of Activities in the Unit

1. Monitor R/3 Program Buffer With Workload

Monitor R/3 Program Buffer With Workload

Summary: The students will monitor the effect of a workload simulation on an ABAP Program buffer that is configured too small. The instructor will help guide the students through the analysis. The exercise can optionally be run a second time with an adequately sized ABAP Program buffer.

Activity Type: Student exercise with workload simulation

Procedure:

1. Display transaction ZWRK. Click the Create Problem pushbutton in the “R/3 Performance Monitors” box to decrease the size of the ABAP Program buffer and other R/3 buffers. This pushbutton changes (among others) the current value of the following profile parameters:

abap/buffersize (400 MB 110 MB)rsdb/ntab/ftabsize (40MB 6MB)

You will be prompted for a system restart. The system should be restarted so that the new profile parameter can take effect. The system restart will take several minutes.

2. Display transaction ZWRK. Click the Start Workload pushbutton.

This pushbutton starts a workload simulation. You can check transaction SM04 to verify the workload simulation users



(SAP_PERF) are logged on. Once about half of the workload simulation users are logged on, the students will be able to begin their analysis. Make sure that the students have sufficient time to understand the importance of each monitor as this exercise progresses. Although the instructor will lead the exercise, he should ask the students to try to guide the analysis. The instructor should keep the exercise moving in the following direction.

3. Open a 2nd user session with transaction /OSM50. After a few minutes, there will be many accesses (direct reads) to the program load tables because the program buffer is too small. You will also notice the “Load program” action because the program buffer is too small.

Additional Information: The ABAP/4 load consists of four tables in the database: D010LINF, D010L, D010Q and D010Y. D010L contains the actual ABAP/4 load; D010Q and D010Y contain the line references or the symbol table of the generated program. D010LINF contains general information about the load, such



as the last time of change and the size of the data in D010L, D010Q and D010Y.You will also see many accesses to table DDNTF, that are caused by the many buffer swaps of the description buffer (rsdb/ntab/ftabsize = 6000).

4. Open a 3rd user session with transaction /OST03N. Choose Expert mode Detailed analysis Last minute

load. Select the current application server. Display these statistical records before the simulation has finished. (The simulation lasts for about 20 minutes, but 15 minutes should be

more than sufficient for the students to evaluate the SM50 display.) Press to execute.

For the students, note the Average Response Time, Average Load Time and Average DB Request Time (These numbers can be used for a comparison later.). The high DB Request Time is due to the frequent accesses to the program load tables, which also cause high Load Time. Both of these statistics are significantly impacted by the small size of the Program buffer.

5. Open a 4th user session with transaction /OST02.



Point out the fields “Allocated” and “Swaps” for the Program buffer.

These fields show the current size to the Program buffer and that it has a significant number of object swaps. Double click on the field “Program” in the “Buffer” section. Click the Current parameters pushbutton

and note for the students the parameter name and value:

abap/buffersize (110 MB)rsdb/ntab/ftabsize (6MB)

These are the profile parameters that have been changed for this exercise. The object swaps occur because the buffers are not large enough to hold all of the necessary objects. They must be displaced to make room for others and then reloaded as needed. Discuss the results of this exercise with the students to make sure that they have a clear understanding.

6. Display transaction ZWRK. Click the Solve Problem pushbutton in the “R/3 Performance Monitors” box.

This pushbutton changes the current value of the following profile parameter:

abap/buffersize (110 MB 400MB)rsdb/ntab/ftabsize (6MB 40MB)

You will be prompted for a system restart. The system should be restarted so that the new profile parameter can take effect. The system restart will take several minutes. The first part of the exercise is complete.

7. Depending on the available time, you can optionally run the workload simulation again. Follow the same process of analysis as during the first half of the exercise. The points of difference are that Average DB Request Time and Average Load Time are decreased and there are no object swaps in the program buffer. The program buffer is adequate for this workload simulation. The discussion of a larger Program buffer solution can also be done using the slides for this exercise that represent the larger Program buffer configuration.

Unit 3: R/3 Memory ManagementList of Activities in the Unit



1. Monitor R/3 Memory Usage

2. Monitor R/3 Memory Usage With Workload

Monitor R/3 Memory Usage

Summary: The instructor will demonstrate monitoring the current usage of R/3 Extended Memory and R/3 Heap Memory.

Activity Type: Instructor demonstration

Procedure:

1. Display transaction ZWRK. Click the Create Problem pushbutton in the “R/3 Memory Management” box.

This pushbutton changes the current values of the following profile parameters:

em/initial_size_MB (648 MB 250 MB)ztta/roll_extension (2 GB 180 MB)abap/heap_area_dia (2 GB 150 MB)em/max_size_MB (2 GB 250 MB)

You will be prompted for a system restart. The system should be restarted so that the new profile parameters can take effect. The system restart will take several minutes.

2. Display transaction ST02. Double click on the field “Extended Memory” in the “SAP

Memory” section. Click the Current parameters pushbutton and note for the students the parameter values:

em/initial_size_MB (250 MB)ztta/roll_extension (180 MB)abap/heap_area_dia (150 MB)

These are the memory management parameters that are most relevant for this demonstration.

3. Open a 2nd user session with transaction /OSM50. Show the students that there are currently no work

processes in PRIV mode.



4. Open a 3rd user session with transaction /OSE38. Execute the program ZADM315_USE_MEM with a value of 50 in the field “MB”. This value in the field will cause the program to use approximately 50 MB of R/3 Extended Memory.

5. Switch to the ST02 session opened earlier and click the Back arrow icon in the icon bar to exit the “Current

parameters” display. Click the Mode list pushbutton (ST02 → Detail analysis menu → SAP Memory → Mode list). This screen displays the memory usage of each user that is logged on the system. Point out the user “Trainer” that is using approximately 50 MB of R/3 Extended Memory (column “Ext Mem”).

6. Open a 4th user session with transaction /OSE38 to run the program ZADM315_USE_MEM again with a value of 200 in the field “MB”.

7. Switch to the Mode list session opened earlier and refresh the display. Point out the user “Trainer” that is using approximately 175 MB of R/3 Extended Memory (column “Ext Mem”) and approximately 25 MB of

R/3 Heap Memory (column “Heap”). Explain that there is approximately 25 MB of R/3 Heap Memory usage because the profile parameter ztta/roll_extension (180 MB) limits the amount of R/3 Extended Memory that a work process can use. The remainder of the memory requirement is fulfilled from R/3 Heap Memory.

8. Switch to the SM50 session opened earlier and refresh the display. Point out that a work process has now gone into PRIV mode because it is using R/3 Heap Memory.



9. Open a 5th user session with transaction /OSE38 to run the program ZADM315_USE_MEM again with a value of 100 in the field “MB”.

10. Switch to the Mode list session opened earlier and refresh the display.

Point out the user “Trainer” that is using approximately 100 MB of R/3 Heap Memory (column “Heap”). Explain that there is approximately 100 MB of R/3 Heap Memory usage because the profile parameter em/initial_size_MB (250 MB) has now been exhausted with the three executions of the program ZADM315_USE_MEM (50 MB, 200 MB, and 100

MB).

11. Switch to the SM50 session opened earlier and refresh the display. Point out that two work processes are now in PRIV mode because both are using R/3 Heap Memory.

12. Cancel the three SE38 sessions opened earlier to run the program ZADM315_USE_MEM to release the R/3 Extended Memory and R/3 Heap Memory that they consumed.

13. Open a user session with transaction /OSE38 to run the program ZADM315_USE_MEM again with a value of 400 in the field “MB”. After a few seconds, there will be an ABAP program dump (TSV_TNEW_PAGE_ALLOC_FAILED) because all R/3 Memory available for Dialog work processes has been exhausted and no more can be allocated for the program. The profile parameter ztta/roll_extension (180 MB) plus the profile parameter abap/heap_area_dia (150 MB) equals 330 MB, which is less than the 400 MB that the program requires. A program aborts when it requires more memory than is available. The demonstration is complete. The user session executing the program ZADM315_USE_MEM should be canceled.

Additional Information: In this demonstration, the profile parameters em/initial_size_MB and em/max_size_MB are equal, which simulates a UNIX environment. In the current UNIX environment, the parameter em/initial_size_MB limits the total size of R/3 Extended Memory. In the NT environment, R/3 Extended Memory may increase dynamically up to the value of the profile parameter em/max_size_MB.



Monitor R/3 Memory Usage With Workload

Summary: The students will monitor the current usage of R/3 Extended Memory and R/3 Heap Memory with a workload simulation on the system. The first run of the workload simulation will use the memory management parameters that have been set in the previous demonstration. The second run of the workload simulation, which is optional, will use more optimal memory management parameters.


Procedure:

1. Open a session with /OZWRK. Click the Start Workload pushbutton.

2. Use transaction SM04 to verify all of the workload simulation users are logged on.

There should be approximately 10 workload simulation users. Once all of these users are logged on, the students will be able to begin their analysis. Make sure that the students have sufficient time to understand the importance of each monitor as this exercise progresses. Although the instructor will lead the exercise, he should ask the students to try to guide the analysis. The instructor should keep the exercise moving in the following direction.

3. Open a 2nd session with transaction /OSM50.

You will notice a program named SAPLSAL2 accumulating clock time. The students should be able to determine that this program (together with report ZADM315_USE_MEM) is consuming R/3 Extended Memory by



examining the Mode list (ST02 double click “Extended Memory” Mode list pushbutton). This program helps create the environment for the workload by consuming R/3 Extended Memory. After about two minutes, workload simulation users (SAP_PERF) should appear in the SM50 display. After about five minutes, some of these workload simulation users should have work processes with a status of PRIV. The PRIV status is what is important to observe in this monitor. After about seven to nine minutes, there should be a significant number of the work processes with a PRIV status. Remind the students that when a work process has a status of PRIV, it is consuming R/3 Heap Memory and is locked by a particular user.

4. Open a 3rd user session with transaction /OSM66. Show the students that this monitor displays similar information as transaction SM50 for active work processes across the entire system.

5. Open a 4th user session with transaction /OST02.

Point out the “Current use” fields for Extended Memory. The “Current use” should be at 100%, which shows that the R/3 Extended Memory is completely consumed and some work processes are forced to use R/3 Heap Memory. This situation can be further analyzed in the Mode list.

6. Double click on the “Extended Memory” field in transaction ST02. Click the Mode list pushbutton

. It is easy to see the users on the system and the amount of R/3 Extended Memory (column ‘Ext Mem’) and R/3 Heap Memory (column ‘Heap’) that they are using

. Each user displayed in this monitor that is consuming R/3 Heap Memory causes a work process to have a status of PRIV. The instructor should have a discussion with the students to make sure they understand how to perform this memory monitoring.

7. Display transaction ZWRK. Click the Solve Problem pushbutton in the “R/3 Memory Management” box. This pushbutton changes the current values of the following profile parameters:

em/initial_size_MB (250 MB 648 MB)ztta/roll_extension (180 MB 2 GB)abap/heap_area_dia (150 MB 2 GB)em/max_size_MB (250 MB 2 GB)

You will be prompted for a system restart. The system should be restarted so that the new profile parameters can take effect. The system restart will take several minutes. The first part of the exercise is complete.

8. Depending on the available time, you can optionally run the workload simulation again. Follow the same process of analysis as during the first half of the exercise. The primay point of difference is that there are no work processes with a status of PRIV during this workload simulation because the parameters have a more optimal configuration.



Unit 4: Hardware CapacityList of Activities in the Unit

1. Detect External Processes

Monitor R/3 Hardware Capacity (External Processes)

Summary: The students will analyze the system because of a significant performance problem. The students should analyze this problem with little help from the instructor. The reason for the problem is that external operating system processes are consuming CPU resources.


Procedure:

1. Explain to the students that you will create a performance problem on the system. Ask them to monitor the system for a few minutes before you create the problem. This will allow them to have an idea how the system looks with no problems. Instruct them to use the monitors already discussed to identify the problem after you have created it.

2. Display transaction ZWRK. Click the Create Problem pushbutton in the “Hardware Capacity” box to start the external operating system processes.

Two external processes will consume all of the available CPU resources. Additionally, click the Start Workload pushbutton to create a workload simulation that will provide statistical records for analysis.

3. Display transaction ST06. Point out that CPU Idle Time is 0% and CPU User Utilization is 100%.

Click the Refresh display pushbutton several times. The



situation does not change. There is a problem related to CPU utilization. Further analysis about CPU utilization is necessary. Click the Detail analysis menu pushbutton. Click the Top CPU processes pushbutton. Point out the two processes at the top of the process list that are consuming almost all of the

CPU resources. Prove that these two processes are external to the R/3 System by demonstrating that they are not R/3 work processes.

4. Open a 2nd user session with transaction /OSM50. Point out that the PIDs (process ID numbers) of the two processes from “Top CPU processes” do not appear in the SM50 display.

This proves that they are not R/3 work processes. It is also evident that these two processes are not database related because the database is represented as a single operating system process (“ORACLE80” in our example) in the “Top CPU processes” display for this operating

system. The correct analysis of this exercise is processes that are external to the R/3 system can degrade R/3 performance. The solution is to eliminate the external processes.

5. After the workload has been running for 10 to 12 minutes, open a 3rd user session with transaction code



ST03N to take a look at the statistical records for this workload simulation. Choose ‘Expert mode’

Detailed analysis ’last minute load’, then choose the current application server. Analyze the last 8 or 10 minutes. Point out that the Processing Time (Dispatch time - Average roll time - Average database request time - Average enqueue time - Average roll time) is significantly larger than the Average CPU time.

Processing Time (PT) must be larger than CPU Time (CPUT): PT > 2 * CPUT. In this sample: (PT = 4.691 – 1.559 – 1.683 – 12 – 235 – 95 = 1122). This indicates a resource bottleneck (PT > 2 * CPUT): 1122 > 2 * 501. In this example, it is a CPU bottleneck due to external processes consuming CPU. The Average wait time and the Average database request time is also high as a result of the CPU bottleneck.

6. Display transaction ZWRK. Click the Solve Problem pushbutton in the “Hardware Capacity” box to kill the external operating system processes. Switch to the first screen of the ST06 session opened earlier. Point out that the CPU utilization is normal again. Also display the “Top CPU process” again. Point out that the two external process are now gone. The exercise is complete. Discuss the exercise with the student to make sure they understand the methodology.

Unit 5: Expensive SQL StatementsList of Activities in the Unit

1. Database Lock Demonstration

2. Expensive SQL

3. Expensive SQL With Workload

Monitor Database Locks

Summary: The instructor will demonstrate a database lock situation (Exclusive lock wait situation). This demonstration is independent of the SAP Enqueue/Dequeue (logical locking) process that can be monitored with transaction SM12.

Activity Type: Instructor demonstration

Procedure:

1. Display transaction DB01. Show the students that there are no current database lock situations.

2. Open a 2nd user session with transaction /OSE38. Display the program ZADM315_LOCK and explain that a database lock situation is created because the "select single for update" is coded in the program. This program holds a lock on the table NRIV because the "break-point" occurs before the program is finished and the database lock can be released. Execute the program.



3. Open a 3rd user session with transaction /OSM50. Show the students that a Dialog work process is now in DEBUG mode because of the "break-point" in the program. This is the work process that is used by the program ZADM315_LOCK. There is now a database lock on the table NRIV. This is not really a problem until another program wants to access the table NRIV.

4. Open a 4th user session with transaction /OSE38. Execute the program ZADM315_LOCK a second time. The program will display an hourglass because it is waiting for a database lock on table NRIV.

5. Switch to the SM50 session opened earlier (refresh the display if necessary) and show the students that two Dialog work processes are now consumed because of this database lock problem. Two Dialog work processes are accumulating clock time and are not able to service other user requests. Also click on the CPU pushbutton to demonstrate that the two Dialog work processes are not getting CPU time.

6. Switch to the DB01 session and show the students the "lock holder" and the "lock waiter" for table NRIV. The PIDs for the "lock holder" and "lock waiter" correspond to the PIDs of the Dialog work processes that are accumulating clock time in the SM50 monitor. You can also double click on the lock object (NRIV) in the DB01 display to get more detailed information about the locked object.

7. Press the F8 key on the screen of the first program so that it can continue past the "break-point" and finish. The database lock situation is now gone because both programs are no longer trying to get a lock on the table NRIV. Show the display of DB01 to prove the database lock problem is gone. Press the F8 key on the screen of the second program so that it can go past the "break-point" and finish. The demonstration is complete.

Additional Information: The instructor can also show the database wait situation created by the database lock in this demonstration if desired.

1. While both programs are running, open a user session for transaction ST04 Detail analysis menu Wait events. This display will demonstrate how to get additional database lock information (expressed in clock time and as a percentage of database resources). Click the Reset pushbutton and wait a few seconds. Click the Since Reset pushbutton. You can continually click the Since Reset pushbutton to show that the "enqueue" event is accumulating clock time and is near the top of the event list.

2. When both programs are finished, again display transaction ST04 Detail analysis menu Wait events. Click the Reset pushbutton and wait a few seconds. Click the Since Reset pushbutton. You can continually click the Since Reset pushbutton to show that the "enqueue" event is no longer so near the top of the event list and is not rapidly accumulating clock time.

Expensive SQL Statements

Summary: The instructor will create an SQL trace involving two expensive SQL statements. The instructor will analyze the first expensive SQL statement and create a secondary index as the solution. The students will analyze the second expensive SQL statement and discuss how to solve the problem on their own. The instructor will moderate the discussion.

Activity Type: Instructor demonstration/Student exercise

Procedure:

1. Open a user session with transaction /OSE38. Execute program ZADM315_SELECT_ZMARA. A program should be executed once before the SQL trace is activated to populate any local SAP table buffers. Alternately, the program can be run from transaction ZWRK by clicking the Select from ZMARA

pushbutton.

2. Open a user session with transaction /OST05. Click the Trace on pushbutton.

3. Switch to the SE38 session opened earlier and execute the program ZADM315_SELECT_ZMARA. Note the run time of SQL statements 1 and 2 (they will be referenced later).



4. Switch to the ST05 session opened earlier and click the Trace off pushbutton.

Click the List trace pushbutton. Click the Execute (check mark) pushbutton on the next screen to get the trace list. The students should also list the trace after you have it on your screen.

5. The SQL trace list displays two statements with very high duration times in the database. Both statements involve the table ZMARA. Place the cursor on the first line of the list that has a database operation of REOPEN for the object ZMARA and click the Explain SQL pushbutton. The SQL statement is making a selection against table ZMARA using the fields MANDT and BISMT. The execution plan involves an index range scan. The index should be investigated to see if is appropriate.

6. Double click on the name of the index (ZMARA~T) to determine what fields it is using. The display shows that this index uses fields MANDT and MATKL. The index does not contain the field BISMT that is in the WHERE clause of the SQL statement. The existing index is not appropriate for the SQL statement. The solution is to create a secondary index for table ZMARA that contains the fields MANDT and BISMT.

7. Open a user session with transaction /OSE12. Enter ZMARA in the field "Object name" and click the Display pushbutton. Click the Indexes… pushbutton. Click the Create pushbutton. Enter Y in the field "Index ID". Click the Continue (check mark) pushbutton. Enter an index description in the field "Short description". Enter MANDT and BISMT in the column "Field name" to specify the fields of the new index (MANDT is not generally a good field for and index, but is used here to be consistent with the existing secondary index.). Click the Activate pushbutton to activate the new index in the SAP data dictionary and in the database.

8. Switch to the SE38 session opened earlier and execute the program ZADM315_SELECT_ZMARA. Note the run time of SQL statement 1 again. The run time has decreased dramatically because there is now an appropriate secondary index for SQL statement 1. The demonstration is complete.

The remaining portion of the exercise is a lab for the students. They should apply what they have learned to try to solve the problem with the second expensive SQL statement. The solution involves updating the database optimizer statistics. The students have not been shown how to do this and should not be able to solve the problem. This is an important point because current statistics for the database optimizer are critical. The



instructor will demonstrate and discuss the results of the lab with the students after they have had sufficient time to discuss it.

1. The instructor should now create another SQL trace of the program ZADM315_SELECT_ZMARA. The list of this trace will contain only one expensive SQL statement because the other expensive SQL statement has now been addressed. The students should list the trace after the instructor has created it. The students should begin their own analysis of the problem starting with the list of the trace.

2. After the students have had sufficient time to discuss the exercise (15-20 minutes should be enough time), the instructor should demonstrate and explain the solution.

NOTES for the discussion and solution for expensive SQL statement 2:

1. The secondary index that is selected by the optimizer is not appropriate. The SQL statement uses the fields MANDT, BISMT, and MATKL in its WHERE clause. However, the secondary index uses the fields MANDT and MATKL The secondary index does not match the WHERE clause of the SQL statement. This demonstrates that an appropriate secondary index should exist in order to improve database request time.

2. Create a new secondary index (ZMARA~Z) using only the field BISMT and run the program again. The field BISMT is used for the secondary index because it is the most selective field (This index is essentially the same as the ZMARA~Y index and demonstrates that either could be used.). Execute the program again. It is expected that response time should improve. However, the response time does not improve. There is no improvement because the database optimizer statistics do not exist for this new index (important!). The database optimizer statistics must be updated.

3. Execute transaction DB20 to get to the Maintain Statistics screen. Alternately, click the Create ZMARA Stats pushbutton from the transaction ZWRK. Enter ZMARA in the field "Table" and click Create statistics. Execute the program again and notice that the response time is greatly improved. This improvement is because the database optimizer statistics now exist and the appropriate secondary index is used.

4. Create a SQL trace of the program and show the students that the new secondary index (ZMARA~Z) is used.

5. Show the students that a full table scan can be better than using an inappropriate secondary index. Delete both secondary indexes that were created in this exercise (ZMARA~Y and ZMARA~Z). Execute the program again. Response time is still better than the original response time when the exercise was started, though both additional indexes have been deleted. The reason for this is because the database optimizer has current statistics and knows that a full table scan is more efficient than using the only remaining secondary index (ZMARA~T).

6. Create a SQL trace of the program to show the students that a full table scan is used rather an index.

Expensive SQL Statement With Workload

Summary: The instructor will start a workload simulation involving an expensive SQL statement and help the students analyze the problem and develop a solution. The instructor can help lead the students through the analysis.


Procedure:

1. Display transaction SM50 (Process Overview Monitor). Show the students that there are currently no long running work processes.

2. Open a 2nd user session with transaction /OSM66 (Systemwide Process Overview Monitor). Show the students that there are currently no long running work processes. Remind the students that the analysis of the workload simulation will start with transactions SM50/SM66.

3. Open a 3rd user session with transaction /OZWRK. Click the Create problem pushbutton in the Expensive SQL Statements box (This pushbutton deletes the index that is the solution for this exercise.). Click the Start Workload pushbutton. This pushbutton starts a workload simulation with SD users. The SD users execute transaction VA01, which makes user exits that call the program ZZSELECT. The program ZZSELECT accesses the table ZLIPS.



4. You can check transaction SM04 to verify that the workload simulation users are logged on. Once these users are logged on, the students will be able to begin their analysis. Make sure that the students have sufficient time to understand the importance of each monitor as this exercise progresses. Ask them to try to lead you through the analysis.

5. Instruct the students to monitor transactions SM50/SM66 and to identify the PROGRAM, TABLE and TRANSACTION that are associated with the problem. With transaction SM50, the program name (ZZSELECT) can be found in the column "Program" and the table name (ZLIPS) can be found in the column "Table". With transaction SM66, the program name (ZZSELECT) can be found in the column "Report". Click the Next view icon in the icon bar of the SM66 display. The transaction name (VA01) can be found in the column "Tcode" and the table name (ZLIPS) can be found in the column "Table". Emphasize that the expensive SQL statement can be found ‘real-time’ with transactions SM50 and ST04 (Database Monitor) or ‘historically’ with transactions ST03N (Workload Monitor) and ST05 (SQL Trace). The Shared Cursor Cache (ST04 Detail analysis menu SQL request) can also be analyzed to help find expensive SQL statements.

6. Identify the expensive SQL statement (the ‘real-time’ way) by matching the PID number of one of the long running Dialog work processes accessing table ZLIPS (the work process must be running for this to work) in SM50 with its corresponding Client Process number in the Database Process Monitor (ST04 Detail analysis menu Oracle session). Double click on the line with the corresponding Client Process number and the SQL statement should be displayed. Timing is critical for this to work. It may be necessary to try this several times. You can click the Explain pushbutton to get further information (including the full statement and any index that is used).

7. To get the average response time of VA01 during the simulation (it is mostly database request time), call the Workload Monitor (ST03N), switch to "expert mode" and choose "Detailed analysis" "Last minute load" "<instance name>". This can be used as a comparison for later in the exercise. Enter the figure for the duration of the workload simulation run. Click Continue. From the analysis views, choose "Transaction profile" "Standard". Sort the transactions by "Average Response Time". Transaction VA01 should be at the top of the list and have a high average response time and a high database request time. The workload simulation last for about 15 minutes, but you do not have to wait for it to complete before taking a look at these statistical records.

8. Once the expensive SQL statement has been displayed using the Database Process Monitor, click the Explain pushbutton to see the execution plan for the statement.

SELECT *FROM "ZLIPS"WHERE "MANDT" = :A0 AND "MATNR" = :A1 AND "WERKS" = :A2 AND "LGORT" = :A3

Execution Plan

SELECT STATEMENT ( Estimated Costs = 257 )

TABLE ACCESS FULL ZLIPS

Point out to the students the relevant fields that are used in the WHERE clause of the SQL statement (MATNR, WERKS, and LGORT) and that there is a full table access of table ZLIPS.

9. Create a SQL trace of transaction VA01 for the purpose of comparison with the solution to the exercise (the



interest here is database request time for table ZLIPS). Remember to run the transaction once before turning on the trace. Open a user session with transaction /OVA01. Type SO in the "Order type" field and press the Enter key. Type SDD00000 in the "Customer" field and press the Enter key and turn the SQL Trace off (this is a very short trace involving entry of only two fields). List the trace and point out the high database request time for access to table ZLIPS. Use the Explain pushbutton to see the detail for the statement accessing table ZLIPS. Once the trace is listed, you can use the compress feature to make it more readable (Goto Summary Summarize).

10. The data dictionary should be checked next to see what indexes exist for the table ZLIPS. Open a user session with transaction /OSE12 (Data Dictionary) and display the existing secondary indexes for table ZLIPS. There are no existing secondary indexes for table ZLIPS. Create and activate a secondary index on the field MATNR because it is the most selective field of those that are used in the WHERE clause of the SQL statement. The secondary index can also be created by using transaction ZWRK, and then clicking the Solve Problem pushbutton in the box "Expensive SQL Statements".

11. Create another SQL Trace (ST05) of transaction VA01 just like the earlier one. List the trace and point out that the access time for table ZLIPS has been greatly reduced because of the new secondary index on the field MATNR. This basically completes the exercise. Also show the students that similar information can be obtained from the Shared Cursor Cache.

12. Display the Shared Cursor Cache (ST04 Detail analysis menu SQL request). The selection criteria fields should be blank, except for the field "SQL statements template", which should have a value of ZLIPS. Click Execute. This will display SQL statements that access the table ZLIPS. Double click on the statement with the most executions and then click on the Explain pushbutton. The explain function always shows the execution plan that the optimizer would choose – here, this plan should involve the index on MATNR created in step 10. The Solve Problem pushbutton in the "Expensive SQL Statements" box in transaction ZWRK must be clicked when this exercise is complete.

Unit 6: Table BufferingList of Activities in the Unit

1. Buffering database accesses

Monitor R/3 Table Buffering

Summary: The students have to analyze program ZADM315_SELECT_BUFFER to find out for each SQL statement if the data are retrieved from the buffer or the database.

Activity Type: Student exercise

Procedure:

The trainer has to perform a SQL trace of program ZADM315_SELECT_BUFFER.

Display the SQL trace and the source code.

The students have to analyze each SQL statement and should determine if the data are retrieved from the buffer or the database. If the data are retrieved from the buffer, the students should determine the buffering type



(transaction SE13).

To display the primary key and the technical settings of a table use transaction SE12 or SE11.

Unit 7: Interface Monitoring Activities in this Unit

1. Parallel RFCs Exercise

Interface Monitoring

Summary: The students will analyze the system because of a significant performance problem. The reason for the problem is that asynchronous RFCs are started in parallel and use nearly all resources. .

Activity Type: Student exercise

Procedure:

1. Call transaction ZWRK. Click the Create Problem pushbutton in the ‘Parallel RFCs’ box. This pushbutton calls the report RSARFCLD, which changes the current value of the profile parameter rdisp/rfc_min_wait_dia_wp from 8 to 2. This parameter specifies the number of dialog work processes that should remain free for the other users. Apart from the parameter change the report displays the current settings of the RFC resource management.

2. Go back to transaction ZWRK and push the ‘Start Workload’ button, which starts the benchmark users and the report ZADM315_START_RFC_BATCH2, that triggers asynchronous RFCs for about 20 minutes. If you want to stop this report, use the ‘Stop Transaction’ by clicking the SAPGUI icon in the upper left corner of the corresponding GUI window.

3. Open a 2nd screen with transaction SM50. There you will see many processes that are running under your user (trainer). In the process overview you will see the programs SAPLZADM315 and SAPLARFC



respectively SAPLERFC, that are caused by the activity of the asynchronous RFCs. These programs have many accesses to tables ARFCRSTATE and ARFCDATAOnly about two workprocesses are kept free for the online dialog users, i.e. benchmark users and students.

4. In a 3rd screen you should open transaction SM04, where you can monitor the logged on users. Apart from the students and the SAP_PERF users you will see many users that are logged on with your name and type RFC.

5. After 15-20 minutes you should call transaction ‘ST03 -> This application server-> Last minute load->Goto->Profiles->RFC profile->Servers’There you will find the function modules that have been called via RFC. The function modules ARFC_DEST_CONFIRM, ARFC_DEST_SHIP, ARFC_RUN_NOWAIT, RFC_PING and TRFC_SYSLOAD_BP are called by the framework of the tRFC processing. The function module Z_ADM315_START_TRFC is called by the report ZADM315_START_RFC_BATCH2, which is the reason for the high RFC load.

6. Go to transaction ZWRK and click the ‘Solve Problem’ pushbutton. This will submit the report RSARFCLD again and reset the parameter rdisp/rfc_-min_wait_wp to 8. After that press the pushbutton ‘Start Workload’ and let the students analyse the situation again. The number of workprocesses, that is occupied by the asynchronous RFCs is now restricted to 2 and the benchmark runs without problems.



Appendix 1: Workload Analysis Transactions


Dialog response time in detail

DIA

Paging

Roll

DW

DIA

PMON SMON

DBWR CKPT LGWR ARCH

S

DIA S

BTC S

ENQ S

UPD S

SPO S

ST02

ST02SAP

Buffers

SAPMemor

y

ST04

DB02DB05SM50

SM66

ST03NST03GRZ20DB13STAD

ST05

DB01

DB20

ST06saposcol.exe

ST10

STATTRACE

SE30ST07ST14


Appendix 2: Symptoms and Possible Causes

■ High wait time: Insufficient number of free work processes

■ High roll-wait time: Communication problem with GUI, external system, or large amount of data requested

■ High load and generation time: SAP buffers (Program, CUA or Screen) too small

■ High database request time: CPU/memory bottleneck on database server; communication problem with database server, expensive SQL statements, database locks, missing indexes, missing statistics or small database buffer(s)

■ High CPU time: Expensive ABAP processing, for example, processing large tables; inefficient programming

■ Processing time more than twice CPU time: CPU bottlenecks


Average Response Time (RT)Dialog: approx. 1 secondUpdate: < 1 second

Average Wait Time (WT)< 1 % of Average RTUsually < 10 % Average RT

Average Roll-in Time (RINT)< 20 ms

Average Load Time (LT)< 10 % Average RT< 50 ms

The Operating System can affect these values by about 10 %

Average Processing Time (PT = RT – WT – RINT – LT – DBT)

< 40 % Average Dispatch Time (DT = RT – WT)

< (2 * CPUT)Average DB Request Time (DBT)

Approx. 40 % of Average DTDirect reads: < 10 msSequential reads: < 40 msChanges: > 25 ms

Average CPU Time (CPUT)Approx. 40 % of Average DT> (PT / 2)


Appendix 3: Road Maps


ADM315 Workload Analysis Caderno de Exercícios

Documents

Transcript of ADM315 Workload Analysis Caderno de Exercícios