HOW TO VALIDATE SQL PERFORMANCE TUNING VIA SAP ST04 SQL CACHE

Sometimes, you have to tune SQL to improve SAP program performance. After SAP SQL tuning is done, is new SQL statement having better performance than original SQL statement? This post would show you an example on how to verify this via SAP ST04 SQL cache. 1 The background ST04 SQL cache showed that one SQL was a top expensive SQL statement based on CPU utilization. 2 Tuning on the SQL in SAP ABAP program To improve the performance, SQL is tuned in the way that source table was swapped from /SAPAPO/MATKEY to /SAPAPO/MATMAP since primary key of /SAPAPO/MATKEY matches existing selection criteria and new table returns same result under the same selection criteria. Please refer to Figure 1 to know the new code and old code— Figure 1 Old code and new code The change is quite simple and done in SAP SCM system. So would the new SQL have better performance than the old SQL? 3 Performance validation on the tuned SQL via ST04 SQL cache Since all executed SQL statements would be kept SQL cache with many performance metrics like response time, CPU time etc. So both old SQL and new SQL execution history data is available in the system. That data is pulled and showed in Figure 2. Figure 2 ST04 SQL Cache Figure 2 shows that each execution of new SQL accessing /SAPAPO/MATMAP table is spending about 13,006,591 microseconds against 21,495,315+ microseconds spent by old SQL statements accessing /SAPAPO/MATKEY. That is at least 39% performance improvement on CPU time consumption per SQL execution. Total CPU time consumed by a SQL is the times of two numbers – CPU time per SQL execution and number of times which the SQL is executed. Improvement on individual SQL execution is not a guarantee for overall improvement if number of SQL execution is increased. In this particular case, Figure 1 shows the change is just replacing the old table with a new table without logic changes. So number of times which the SQL should be executed would not be changed after tuning. Also Figure 2 shows number of rows retrieved (column Rows/Exec) per SQL execution has no big difference between new SQL and old SQL and it also shows 43+% improvement on SQL elapsed time/execution. So the SQL/ABAP performance tuning is successful based on ST04 SQL cache performance analysis. So far, ST04 SQL cache performance analysis helped us to achieve our goal – whether the SQL/ABAP tuning is good/bad for performance. You might wonder why it helped to improve performance by a simple table swap? The developer replaced the old table with the new table since EXT_MATNR is a primary key of /SAPAPO/MATMAP (Figure 5). Reading a table via primary key is faster – is this the reason for the performance improvement? If you would like to know more, continue readingJ. 4 Why changes make a performance improvement A tuned SQL can make performance improvement due to many reasons – execution plan, table size etc. 4.1 Execution plan comparison Figure 3 is the SQL execution plan with original table before the change. Figure 4 is the SQL execution plan with the new table. Figure 3 SQL Execution plan before change Figure 4 SQL execution plan after change From the above execution plan, we can see that primary key is not used to read the new table. It is using the “Full table scan”. Index /SAPAPO/MATKEY~MAT has only “MATNR” field. Comparing cost of SQL execution plan between old table and new table, you can see “Estimated Costs” with the new table is 788 against 1,223 with old table. Figure 5 Table structure Based on the code and new table structure, the primary key could be used to read the table normally. Why not? We need table size information to understand this. 4.2 Review table size Using ST04 SQL command editor, We can enter SQL and execute it to get following information from Oracle table DBA_TABLES . Figure 6 – Number of table records So number of rows is similar but average row length is different – this is approved by the table size from DB02 transaction (Figure 4) Figure 7 – Table storage size So the new table is almost 1/3 of old table in size. 4.3 Performance improvement When an index is used to access a table data record, Oracle would need to read index block to get address for the data block and then it would fetch data block. When number of records needed reaches a threshold, it would be more efficient to bypass index and read data block directly. In this particular case, whenever the sql is executed, it would fetch 247K record out of 250K records. So the full table access is used by Oracle with the new table. So the performance improvement is coming from a much smaller table and full table access not due to primary index with the new table. 5 Other methods for validating a SQL performance tuning There are other ways to determine whether a SQL tuning in SAP program is good to performance. Based on program runtime difference – Get program runtime before and after changes against same testing data. Based on analysis of program execution statistics – statistics for program execution before changes and statistics for program execution after changes. Based on performance trace analysis – Do a before and after trace. Based on technical analysis like where-clause and table index. Each of above method has their own pros and cons. You need to choose the best one fit for your case. For example, when you measure the performance by program/job runtime or execution statistics, you need to be sure that runtime is not impacted by many factors like volume, application lock and database lock, resource contention etc. If you changed many SQL statements in a program to tune performance, it might be a tedious work to find out how each change is performing. Someone might notice that the cost in the execution plan with a new table is lower. You cannot say for sure that lower cost means faster access when different table are involved. Even with the same table, an execution plan with a “lower” cost can be a bad plan – that is why Oracle provides Oracle hints for program to influence execution plan. So using cost is not an error-proof method to measure performance of two different SQL statements. In this post, I have used ST04 SQL cache to validate performance improvement from SQL tuning. You can click How to run ST04 for more information. HOW TO VALIDATE SQL PERFORMANCE TUNING VIA SAP ST04 SQL CACHEVALIDATE SQL PERFORMANCE TUNING;SQL CHANGE PERFORMANCE ANALYSIS;SQL TUNING PERFORMANCE MEASUREMENT; ST04 SQL CACHE Post navigation PREVIOUS POST
Posted by 1 comment:

SAP PARALLEL PROCESSING INTRODUCTION

Parallel processing is to use “divide and conquer” strategy to increase business process throughput and cut processing time by engaging more system resources. This post would take about SAP parallel processing and cover: What is parallel processing? What is pros and cons of parallel processing? What are driving factors to implement parallel processing? What influence performance of parallel process? Technical overview of SAP parallel process implementation. Parallel process solution implemented via background job. Parallel process solution implemented via SAP dialog work process. What are steps to implement a parallel process? Some standard SAP parallel solution. 1 What is parallel processing? Let’s begin with an example, 10 customer orders are to create online in SAP system and each order would take 1 minute. There are two ways to get 10 orders created in the system: You can give 10 orders to a single user and the user then create two orders one by one sequentially. You can divide 10 orders into two packages equally and ask two users to work on one of two packages to create order one by one at the same time. The former is called sequential/serial processing and the latter is called parallel processing. In case of parallel processing, we divide the workload ( to create 10 sales orders) on hand and we engaged more resources(2 SAP work processes through 2 users ) to do the same action( to create sales order) at the same time, This is what parallel processing normally mean in a SAP context – a SAP parent program would automatically divide the workload into smaller packages based on packet size which can be predefined or calculated dynamically, then start a number of child processes to process those packages concurrently, each child process would process one package at one time, when one child process finishes processing the package and there are un-processed packages, the program would launch new child process to pick up next package until all packages are processed. Child process engaged in parallel processing can be SAP dialog or background work process in a SAP system. Let’s continue our example. When 10 orders are created via one process sequentially, it would take at least 10 minutes but this does not meet performance requirement – 10 orders should be created in 5 minutes. So 10 orders are created via two parallel processes and that cuts runtime to 5 minutes. What we should do if 10 orders have to be created in 2 minutes in this case? 10 orders needs to be divided into 5 packages equally and use 5 concurrent child processes to create order and that would finish creating orders in 2 minutes. Let’s assume that creating one order via 1 work process would consume 1 resources, then relation between the runtime and resource needed to create 10 orders and number of users (Number of child process) is showed in table – 1. Table 1 – how runtime is related to number of parallel child process Case 1 Case 2 Case 3 Case 5 # of child process 1 2 5 10 Run Time 10 minutes 5 minutes 2 minutes 1 minute Resource usage/minute 1 2 5 10 Total resource( resource used/minute x duration) 1 x 10 2 x 5 5 x 2 10 x 1 From table 1, you can see that when number of parallel child process is increased, the runtime is decreased but resource usage per time unit is creased even total resource usage to create 10 orders remains the same. This is a simplified version to help you understand basic concept of parallel processing. You can ask two users to do two different things at the same time – one is to create a sales order, the other is to create an invoice – Even these two tasks are done in parallel but this not what SAP parallel processing is referring to since different tasks (such as different business logic/operation/program) are executed. 2 What is pros and cons of parallel processing? What is pros and cons of parallel processing? You can refer to table -1 to understand this. Parallel processing is to increase throughput and cut processing time – this is critical in many cases. To pay for that gain, more system resource is needed or used and order of processing of each package is random. For example, using 2 child processes, it takes 5 minutes to create 10 orders in our case. That is half of the time needed to create 10 orders one by one. The cons is that system resources usage in parallel processing period is doubled what used in serial processing period in a per minute basis. In serial processing, 10 orders can be created in a fashion of “First-in-First-out” in the same time sequence they arrive. This is impossible for parallel processing. 3 What are driving factors to implement parallel processing? The business need and technical need -The business need is that business needs to get job done sooner than later. The technical need is might be due to load contention – for example, system has more idle resource during 1st half the processing and 2nd half processing. system is overloaded in 2nd half processing. If we use parallel process and can cut time to half, this would relieve the contention on the 2nd half processing. Most of parallel solutions are developed to meet business process need. The fitness – The business process is suitable for parallel processing – degree of independence, dividable and type of resources engaged. Parallel process benefit would be very limited for a business process whose transactions have a lot of dependence/sequence. You cannot ask several people to create one order at the same time no matter how big the order is and how long it takes to create it since a single order cannot be further divided. A process which is doing a lot of calculations is more suitable than the one which involves a lot of database access even database management system has its setting/configuration/techniques which control parallel processing at database level. The capabilities – The system has needed resources/configuration to support parallel processing. If your system consists of single server with single CPU, parallel processing might help little on the performance. 4 What influence performance of parallel process solution? Assuming that a business process is fit for parallel processing, following factors can influence performance of parallel solutions from SAP parallel solution design point view The way which workload is divided. When total workload can be “evenly” in a way that each package can be processed in same amount of time, then the time is needed to process the total workload would be reduced. If total workload is divided into 2 packages, you use two parallel processes. If one package takes 10 minutes and the other package takes 1 hour, the system would use two work processes and take 1 hour to process the total workload. But one process would run for 10 minutes and the other process would run for 1 hour – this is an uneven situation. It would be ideal that total workload can be divided into two packages but each of two packages takes 35 minutes so the whole workload can be processed via two parallel work processes in 35 minutes. Size of package can influence performance depends on business situation. In some special situation, you need to consider resource usage of each package under a specific size to make sure that overall resource usage by all parallel processes is what the system can afford. Parallel solution can engage SAP background process or SAP dialog process. When SAP dialog process is used, you need to make sure that size of package would not cause timeout of child process due to hitting system limit. Parallelizing degree or the number of parallel processes allowed. Parallelizing degree – This is number of SAP work processes which can be engaged at the same time to handle workload. Higher degree means more SAP work processes for parallel processing – so more package can be processed at the same time, so the workload can be processed faster – this is what table-1 tells us. How many parallel processes a parallel solution should use? This depends on available system capacity and business performance requirement normally. The typical system resource used in parallel processing is CPU power. Each parallel process would need to use a CPU. Number of parallel processes used in a solution should not be more than number of CPU which a system has assuming that parallel process is the only program running in the system. In a SAP ERP system, there are normally many activities going on at the same time, this would reduce available CPU power for parallel processing. In a SAP ERP system, all business transactions would involve database/IO operation, during database/IO operation, it would not use CPU power of application server, this would allow you to use more parallel processes than number of CPUs which your application servers have. Business performance requirement is important to determine how many parallel processes you need. If a system resource is not enough to support the parallel processing, then resource has to be added. If system has more resources than what is needed to meet business performance requirement. Should we design the solution to use all available resource and let the parallel solution to finish as soon as possible? This depends. I normally prefer to give just enough resources to meet business performance requirement. In addition to CPU, if your solution is using a lot of memory, then you need to consider whether server memory can be a limit factor for parallel solution. In reality, database operation is a significant portion of many SAP transactions/programs runtime, more parallel processes would have a higher chance of creating “wait” situation in database operation. Performance benefit with increased parallelizing degree would go down and while cost would go up after a certain number of parallel processes. Parallel solution is going to amplify risk which a non-parallel solution might have. Running one copy of bad code might be ok to the system but running 10 copies of the same bad code might bring a system down. Order in which packages are processed. This is important when number of packages for processing is bigger than number of SAP parallel work processes allowed and processing time of each package varies a lot, the overall processing would be shorter if packages which take more time are processed first. For example, every package needs 1 minute and 2 parallel processes, then it would take 50 minutes for 2 parallel processes to process 100 packages. Now, imagine one specific package out of 100 packages would need 100 minutes, if this package is processed as 1st package or last package, what difference would the order difference make to the time needed to process 100 packages? It is 149 minutes against 100 minutes. There are other factors which can influence performance of parallel processing like type of server, IO system and database etc. but these are not unique to parallel processing. Last not least, characteristics of business solution itself can impact performance of parallel solution. But we cannot go around itself if we need to use parallel solution to increase the performance. 5 Technical overview of SAP parallel process implementation All works in SAP system are executed via various SAP work processes. An execution of a SAP business transaction/program always starts with a SAP dialog or background process and engages other types of SAP work process whenever needs arise dependent on the nature of underlying SAP program. All business logic of a SAP program is executed via SAP dialog or SAP background work process. So SAP parallel solution is implemented via SAP dialog work processes and/or SAP background work processes. If there is no free dialog/background SAP work process, no user can execute any program online and no background job can start. 5.1 Parallel process solution implemented via background job Every package of workload is processed by one SAP job/SAP background process. But more than one job which is running the same SAP program is processing packages at the same time. The total workload to be processed is divided into smaller packages which are represented by program variants in SAP. Then more than one copy of the program is executed concurrently in background – each works on one package via one of aforementioned variants. It is the parent program logic to divide the workload into smaller packages based on predefined criteria, then loop through those packages, keep launching child job to process those packages while SAP background process is available and there are unprocessed packages. The standard SAP Function modules like “Job_submit” etc. in SAP function group “BTCH” are used to create, schedule and monitor child jobs. If you are interested in how to program this, please check SAP document – SAP programming with background processing system. How many SAP background processes can be used to process those packages? This can be controlled by program and system setting A predefine number of parallel SAP job/background process which a business process is allowed. A SAP server or a SAP job server group for your parallel solution – then all available SAP background processes in the SAP server or SAP job server group can be used for parallel processing. If the server group contains all servers in the SAP system, then parallel solution can use all available SAP background processes from the SAP system. SAP transaction SM61 can be used to maintain SAP job server group Whole SAP system – if you do not use a predefined number, a server or a server group, then it can use all available SAP background processes. When you design this, please bear in mind the points discussed related to parallel degree. So how many SAP background processes would be actually engaged when a parallel solution is running. This depends on how many packages and smaller of two values: allowed parallel degree and number of free background processes. A work process is free mean it is not engaged in any work and ready for new task. For example, assuming allowed parallel degree is 10 background processes, if number of packages is 2, you can see up to 2 active SAP jobs at the same time in SAP job monitor transaction SM37 or up to 2 running background processes in SAP process monitor transaction SM50/SM66. If number of packages is 100, you can see up to 10 active SAP jobs or SAP background processes at the same time via SAP SM37 or SAP SM50/SM66. In ideal situation, the parent program should launch 10 jobs then launch next job whenever one of 10 job finishes and there are outstanding packages. In SAP IDOC processing or SAP interface, background processes can be launched by SAP automatically due to “volume” or “communication” failure or shortage of SAP dialog work process. When this happens, this is normally related to system or interface setting which is control via SAP transaction WE20 and SAP transaction SM59. 5.2 Parallel process solution implemented via SAP dialog work process Every package of workload is processed by one SAP dialog work process. But more than one SAP dialog process which is executing the same SAP program is running to process packages at the same time. Even though the idea is similar to parallel processing via background job through SAP background work process, but there are technical difference – Each package is passed to child process via program internal tables/variables instead of program variants which can be maintained via SAP transaction SE38. Child process is started via SAP asynchronous RFC (Remote Function Call) instead of SAP background job scheduling system. Please note term “Remote” – not mean that Function module called (executed in child process) is always executed in different server/system. In parallel solution, The function module is always executed in the same server/system where the parent program/process is running Each Package is processed via a SAP dialog work process instead of a background work process. SAP dialog work process is subjected to “timeout” setting which is specified via SAP system parameter rdisp/max_wprun_time while SAP background work process has no such limit. From SAP programming point view, parallel process is implemented via CALL FUNCTION statement similar to what you seen in figure 1 Figure 1 – Asynchronous RFC call for parallel processing Figure 1 is a piece of standard SAP code. It is from standard inbound IDOC processing program RBDAPP01. The key words for asynchronous RFC are “CALL FUNCTION“, “starting new task” and “DESTINATION“. So if you see three key words in a SAP ABAP statement, you know the program is using asynchronous RFC call for parallel processing. If you are interested in how to program this, please check SAP document – Implement Parallel Processing. How many SAP dialog work processes can be used to process those packages? This depends on specification of “DESTINATION” and configuration of destination as well as free dialog work processes of the destination. If the ABAP program specifies a destination “NONE” – this means that the program would use free dialog work process on the server where the program is executed. So Number of dialog processes can be used is up to the free dialog process in the server. If the system has only one server, then it is whole system. If the ABAP program uses “group” destination like figure 1 – then number of dialog processes can be used is determined by RFC server group configuration (determined by SAP program parameter P_rfcGR in figure 1). SAP RFC server group controls which server of a system can be used for parallel processing and how many processes can be engaged from each server of the sever group. This is the typical parallel solution setting. RFC server group is maintained via SAP transaction RZ12. So how many SAP dialog processes would be actually engaged when a parallel solution is running. This depends on how many packages and smaller of two values: allowed parallel degree and number of free dialog work processes. You can review parallel process via SM50/SM66. But you could not review them via SAP transaction SM37 which is for background job. However how many parallel processes you can actually see in SM50/SM66 might be different from what are actually active since SAP dialog work process are shared and a program can be rolled out of a dialog work process during waiting. In SAP IDOC processing or SAP interface, EDI/ALE partner profile setting can have an actual effect of parallel processing. When the partner profile setting for a message has a real-time or “immediate” processing setting for an inbound IDOC processing, when many IDOCs are arrived at the system in the same/short time, each IDOC would be processed via one dialog processes subject to availability of free dialog process in the whole system, this kind of “parallel processing” can bring down system when volume is high. SAP has provided utility to execute current SAP program in parallel with minor configuration. This is enabled via SAP transaction WLCPAR and WLCPARC. This might be handy when needs arise. 5.3 What are steps to implement a parallel process? With above knowledge on parallel processing, it is time to discuss what are the steps to implement a parallel process: Figure 2 – Parallel process implementation steps Quantified performance requirement includes what volume should be processed and duration which the volume should be processed. Design or code for a program which used in parallel processing should be well tuned before a parallel solution is considered. Parallel solution is going to run the program in more than one copies. Any expensive operation would be amplified in parallel solution. Sometime, a solution can meet performance requirement without engaging parallel solution by using alternative design or coding, Design of parallel solution includes implementation technique (should we use SAP background work process via job scheduling or should we use SAP dialog work processes via asynchronous RFC or both ), criteria of divided workload or the total volume (should we based on date-time, SAP organization unit, number range, number of business objects etc), packet size determination (fixed packet size or dynamic calculation of packet size), package process order (if this matters), parallel process degree ( how many child processes is enough), server group ( should server group be used or not). RFC server group or Job group itself is not within program design scope – it is a joint decision among business owner, solution technical owner and performance capacity guy. Parallel degree should consider “available system capacity” when the parallel solution hits the system. One factor to influence whether we should use the SAP background process or SAP dialog process is how long the child process would run. Dialog work process is subject to timeout setting. Since business and system is very dynamic – it is good that packet size and server group etc. parameters should be flexible and easy to be maintained whenever there is a need instead of hard-coded somewhere. Validate parallel solution is to check parallel solution works well, meets business performance requirement, verifies resource usage and confirms there is no negative impact on the system which it is executed. 6 Some standard SAP parallel solution Following is a list of SAP functions which I encountered with parallel function. Inbound IDOC processing – SAP inbound program RBDAPP01, RBDMANI2. SD delivery creation – SAP transaction VL10A etc. SD billing creation – SAP program RV60SBAT. SAP workflow processing – SAP transaction SWEQADM_1. TRFC/QRFC processing – SAP transaction SMQS or SMQR. SAP MRP function – SAP program RMMPS000 and RMMRP000. SCM model integration – SAP program RIMODINI, RIMODAC2 etc. SCM CIF comparison/Reconciliation processes. BW data load and activation and reporting GATP Backorder processing. Except SAP program RV60SBAT and GATP backorder processing, all other functions use “dialog work process” for parallel solution. 7 Further information In this post, SAP transaction RZ12 and RZ61 are mentioned. I plan to write a post on how to define RFC server group via RZ12 in the future. You can click link SMQS and SMQR for more information on how to use those transaction for performance analysis and tuning in this website. If you would like to know how do we analyze/verify performance of an existing parallel process. I would cover this in my future post.
Posted by No comments:

HOW TO RUN SAP TRANSACTION RZ12 TO CONFIGURE RFC SERVER GROUP

1. How to start SAP RZ12 transaction You can type “/nRZ12” in the SAP command/OK window to start the technical process of creating RFC server group. After you enter the code “/nRZ12” and press return key, you would see initial RZ12 screen similar to Figure 1. Figure 1 SAP RZ12 initial screen From RZ12 initial screen, you can do following Create a new SAP RFC server group, Add a SAP instance to a SAP RFC server group, Change a SAP instance’s RFC quotas/resources on the fly Remove a SAP instance from a SAP RFC server group and Remove a SAP RFC server group and a SAP instance from all SAP RFC server groups. 2. How to create a new SAP RFC server group A new parallel solution is developed and a new server group is needed. Before you run SAP RZ12 transaction, the server group details like which and how many instance the server group should contain, how many dialog processes is needed etc. should be decided together with server group name. How to understand those RZ12 screen fields/RFC quota parameters is discussed in subsequent section of this post. Here I would create a new server group “1_order” which would engage two instances/servers. 2.1 Start to create RFC server group You can click the “create” Icon to create a new server group as showed in figure 1. You would get a pop-up screen similar to figure 2 for you to enter sever group details Figure 2 Blank RZ12 Server group data screen 2.2 Enter RZ12 RFC server group detail Based on your parallel solution need and your SAP environment, input to all fields in figure 2 should be decided. Let’s assume following inputs are entered. Figure 3 SAP RZ12 server group input Click “copy” button, you would see initial screen of RZ12 again but with the new server group “1_order” as showed in figure 4. Figure 4 SAP RZ12 new server group creation 1 Now the above process is repeated to add another instance to this server group “1_order”. So the RZ12 sever group “1_order” is as showed in Figure 5. Figure 5 SAP RZ12 new server group creation 2 If you are satisfied with your changes, you can click the “save” button in Figure 5 to save your changes. Make sure that SAP system message “Changes saved” is appeared after you clicked “Save” button. If you exit RZ12 transaction without save, your changes would be lost. Please take note, you can only need to enter “sever group name” and “instance”, you can use instance default setting for remaining fields. To do this, you can click “copy” button in Figure 3 without entering “RFC resource parameters”, then click “Yes” on pop-up window similar to Figure 6. If you click “No”, then those RFC parameters would be left “blank”. Figure 6 SAP RZ12 server group – copy default data It might be efficient to copy instance default value for RZ12 fields and make additional changes on top of that. If you are using different value from what specified in instance parameters, then the parameter in the instance profile should be updated accordingly in another time. Otherwise your RZ12 value would be overwritten by instance parameters upon SAP instance/server reboot. Your changes to SAP RZ12 parameters become effective upon save. Those RFC resource parameters in RZ12 can be changed dynamically. 3 How to run SAP RZ12 transaction to change existing RFC server group. 3.1 Add new SAP instance to an existing RFC server group This is similar to creation of new server group. You just need to click expected server group once then click the “creation” icon in the RZ12 initial screen. 3.2 Remove a SAP instance from an existing server group To remove an instance from a server group, you can click the instance of a group which you would like to remove, then click the “Delete Assignment” button in figure 1. Here, I clicked server “b*10” entry in “1_order” group first, then I click the “Delete Assignment” button, then following screen showed up Figure 7 RZ12 server group – remove instance Click the “delete” button in Figure 7, you would back to RZ12 initial screen reflecting your changes, which actually gave me the same screen I had in Figure 4. If you are ok with your changes, you can save your changes now by clicking the “save” button before you exit. All RZ12 changes are not automatically saved by the system. 3.3 Change SAP RFC resources/quotas dynamically RFC resources change is at instance level. All server groups would share the same RFC resources/quotas for the same server/instance. All RZ12 resources/quota changes are dynamic changes and it can be lost upon system reboot. If your changes are going to be permanent, you need to update the corresponding RFC parameter in the instance profile to reflect RZ12 change. To change a resource, you can double click on any entry which contains the expected instance. Here I double clicked “B*04” instance in the initial screen, Figure 8 screen appeared Figure 8 RZ12 Server group – change RFC resources You can make expected changes in Figure 8. The typical change is to increase or reduce data showed in “Max. Number of WPs Used (%)” and “Minimum Number of Free WPs” fields. After you changes, you can click “copy” button in Figure 8, that brings you back to initial screen where you can save your changes. 3.4 Remove a SAP RFC server group and remove a SAP instance from all RFC server groups To remove a server group, you can click any entry of the server group in the initial screen, then click “Delete Group” button, then the entire group is removed from RZ12. Sometimes, an instance might be removed from the system. so this instance needs to be removed from all existing server groups in the system, to do that, you need to click “Remove Instance” button , provide instance name in following window , then click “delete” button Figure 9 RZ12 server group – remove instance As usual, your changes would only come into effect after you click “Save” button. 4 Understand SAP RFC Server group quota/resource parameters Up to now, we have gone through the process of maintaining RFC server group. Here I would like to help you to understand what those parameters mean. Please refer to following chart to understand RFC parameters Table 1 SAP RZ12 RFC quotas/parameter explanation Screen Field Explanation Associated Profile Parameter Example Activated (0 or 1) 0: Routine for resource determination is deactivated 1: Routine for resource determination is activated. You should always use 1. Rdisp/rfc_use_quotas Default value: 1 Max. Requests in Queue (%) The maximum number of waiting requests in the dialog queue of the dispatcher based on number specified by rdisp/elem_per_queue. This is to ensure that system is not overloaded further when queue has been built up. When number of waiting requests hits this quota, then No more parallel process can be started. Current queue length can be checked via menu Goto ->Server name -> information-> queue information in SAP transaction SM51. rdisp/rfc_max_queue default value: 5 5 means 5%. Assume rdisp/elem_per_queue = 2,000 (SAP default) and rdis/rfc_max_queue = 5 , then no more parallel process can be started if number of waiting request is 100 (2,000 X 5%) or more. Max. No. of Logons (%) The maximum percentage of logons to this instance (maximum total number rdisp/tm_max_no) that can be due to asynchronous RFCs. The remaining % is the reserved for non-RFC users like dialog and HTTP users. So those operations are not impacted by RFC. Every RFC is linked to a logon in the targeted instance/server. When number of active logons hits this quota, then No more parallel process can be started. SAP transaction SM04 can be used to display logon – one entry in SM04 screen is counted one logon in this view. rdisp/rfc_max_loginDefault value: 90 90 means 90% Assume rdisp/tm_max_no = 200(SAP default) and rdisp/rfc_max_login = 90, then no more parallel process can be started if number of RFC logon showed in SAP SM04 transaction is 180 or more for this instance. Maximum No. Separate Logons(%) The maximum percentage of logons to this instance (maximum total number rdisp/tm_max_no) that can be due to the asynchronous RFCs of one user. User is referring to USERID. If you are sharing same logon with different people, all logons are counted under one user. When number of active logons for a user hits this quota, then user cannot start RFC process anymore. SAP transaction SM04 can check active logons. Rdisp/rfc_max_own_loginDefault value: 25 Assume rdisp/tm_max_no = 200 and rdisp/rfc_max_own_login = 25, the no more parallel process can be started for a particular user after # of logon under the user is 50 or more. Max. Number of WPs Used (%) The maximum percentage of the dialog work processes that can be occupied by one RFC user session or a single job. SAP transaction SM50 can be used to check active SAP work process. SAP parameter rdisp/wp_no_dia shows # of dialog work process in an instance. rdisp/rfc_max_own_used_wp Default value: 75 Assume rdisp/wp_no_dia = 50 and rdisp/rfc_max_own_used_wp = 75. Then no more parallel process can be started if # of concurrent dialog process used by the parallel session has reached 37 ( 50 X 75% = 37.5 ). Minimum Number of Free WPs Number of dialog work processes that cannot be occupied by RFCs. At least this number of dialog work processes is therefore reserved for dialog users to avoid RFC processing impact online user activities. When number of free dialog work process is equal or less than this number, no more RFC call can be started in the instance/server. SAP transaction SM50 can be used to check number of free dialog process in an instance. Total number of available dialog work process for RFC = rdisp/wp_no_dia – rdisp/rfc_min_wait_dia_wp. Number of available dialog work process for RFC in the instance should be bigger than quota specified by rdisp/rfc_max_own_used_wp. rdisp/rfc_min_wait_dia_wp Default value: 1 Assume rdisp/wp_no_dia = 50 and rdisp/rfc_min_wait_dia_wp = 10. Then no more parallel process can be started if number of free dialog work process showed in SM50 is equal or less than 10. Total number of work processes which can be used by RFC call is 40 (50 -10 = 40). Max. No. of Comm. Entries (%) the maximum percentage of communication entries of an instance (rdisp/max_comm_entries) may be occupied by parallel RFCs. You can review current active # of communication entry via menu path “Goto ->Server name -> information-> Communication Table” in SAP transaction SM51. This is to ensure that there is enough free communication entries in the instance. When Number of entry in communication table is bigger than the quota specified by this parameter, then No more parallel process can be started. rdisp/rfc_max_comm_entries Default value: 90 Assume rdisp/max_comm_entries = 500 and ridsp_max_comm_entries = 90, then no more parallel process(RFC call) can be started if number of entries in the communication table reaches 450( 500 X 90%). Max. wait time The maximum period of time in seconds which system waits for subsequent check when resource is not available after load check in the system. The wait time is calculated dynamically using following formula – wait = min (max(1,count-quota), max_wait). The count is number of used resources which are specified in above parameters like dialog process, communication entries, and quota is the resource requirement specified by the RFC parameters. Few resources that are available, the longer the wait time up to Max_wait. You can increase the wait time to accept a longer wait time when there is a resource bottleneck. rdisp/rfc_max_wait_time Default value: 10 Assume the same quota as above and rdisp/rfc_max_wait_time is 10 seconds. If there are 455 communication entries, then the wait time would be 5 seconds. Wait = min( max( 1, 455 – 450), 10). For 458 entries, wait would be 8 seconds, if active entry is above 460 seconds, then the wait time would be 10 seconds. In table 1, all fields with % are percentage number. For most of SAP RFC quotas, we normally use SAP default data. The often changed fields are rdisp/rfc_max_own_used_wp and rdisp/rfc_min_wait_dia_wp. Rdisp/rfc_max_own_used_wp specifies how many concurrent dialog processes a single job/user-session can engage at the same time. This should be determined based on actual performance of the business transaction/process, projected volume growth and the business performance goal for the transaction/process. I would suggest that we do not give more parallel processes than what business really needs. More parallel processes means more risk – any bug(now and future) in the solution would be amplified. In most cases, there is no linear performance improvement with added parallel processes. A parent job can launch child process which can launch it’s own RFC call some times. So higher degree of parallel process can create higher risk where resource lock( work process level lock) among RFC calls due to resource shortage can occurs. a higher value for parameter rdisp/rfc_min_wait_dia_wp instead of SAP default value 1 should be selected so online user’s experience are not impacted by possible activities. Of course, this is not an issue, if your RFC solution and online users activities happened in different hours… In Summary, RFC quota parameters specify quotas in Caps on how many ARFC logons in an instance – no more aRFC is allowed in the instance if the caps is reached. Caps on how many ARFC logons by a single SAP user – no more aRFC allowed in the instance if this cap is reached. Caps on how many requests in a dispatcher queue in an instance – no more aRFC is allowed in the instance if this caps is reached. Caps on how many communication entries should be exist in an instance – no more aRFC is allowed in the instance if this caps is reached. Caps on how many parallel work processes a single execution of program/transaction can engaged – no more aRFC is allowed if this caps is reached. Caps on how many dialog work process should be kept free for online activities at least– no more aRFC is allowed if this caps is reached. If a SAP instance of a SAP RFC server group is “passive”, then the instance would not be engaged in parallel solution. However, MRP job can still engaged “passive” SAP instance for parallel processing as long as the passive server is set up in SAP transaction OMIQ in the SAP version I am working with. SAP transaction SM51 can be used to check SAP server/instances status. Again, those parameters are at instance/server level not at RZ12 RFC server group level. If you are using different value other than what specified in SAP instance profile. Please remember to update the SAP instance profile before the instance is rebooted so your changes are not lost. 5 Verify RZ12 RFC server group resource change You can use SPBT to verify your SAP server group RFC resource quota configuration. To do this, you can run SAP transaction SPBT, then do following Enter SAP RFC server group you would like to check Click on “Init PBT Env.” Button Review the result to see whether it is what you expected in terms of instance engagement and number of concurrent dialog processes can be engaged by a single job/user session. Figure 10 SPBT validate RFC resources In Figure 10: Max. WPs = rdisp/wp_no_dia – rdisp/rfc_min_wait_dia_wp. SAP Instance level Free wps = rdisp/rfc_max_own_used_wp * rdisp/wp_no_dia / 100 Total Wps = Sum of Max. WPS from all instance. SAP RFC Server group name is “case sensitive” so make sure that you use the server group name exactly as what showed in RZ12. 6 Further clarification SAP IDOC inbound program, CIF model activation program, SAP inbound and outbound scheduler etc. are using server group in their parallel solution. Some parallel solutions are not using server group, for example MRP program is using transaction OMIQ to configure the RFC resources quota. Even RFC server group is configured but there is no guarantee that resource configured is available since quotas configured is shared by all RFC calls at SAP instance/server and resource picture of a SAP instance/server is very dynamic. You can use SAP transaction RZ11 to review and change SAP parameters like SAP RFC resource parameters. There is another RFC parameter rdisp/RFC_CHECK. This parameter determines level of details of check on whether enough free dialog work processes are available for aRFC calls. SAP recommends that you do not change default value for this parameter. There are parallel solutions which depend on SAP job server group. SAP job server group can be configured via SAP transaction SM61. I can cover how to use SM61 this in separate post. HOW TO CHANGE A SAP RFC SERVER GROUPHOW TO CREATE A SAP RFC SERVER GROUPHOW TO RUN SAP TRANSACTION RZ12HOW TO VALIDATE SAP RFC SERVER GROUP CHANGESSAP RFC PARAMETERSSAP RFC RESOURCE QUOTASSAP TRANSACTION RZ12 Post navigation PREVIOUS POST How to validate SQL performance tuning via SAP ST04 SQL cache NEXT POST SAP program performance tuning – Suboptimal SQL execution plan part 1 of 2
Posted by No comments:

ST12 Trace – Step by step instruction on how to use it for analysis

Analysis using ST12 Trace Illustration The ST12 trace analysis will follow the below mentioned steps, Selection of Trace Parameters Start and Collect Trace Analyzing the Collected Trace Trace Parameters The Trace parameters can be categorized as below, · Trace For · Type of Trace Trace For · ST12 trace can be captured for “User/Tasks”, “Work Process”, “Current Mode” and “For a Schedule” · The User/Tasks allows the developer to select a User for whom the trace is to be captured and a task for which the trace is to be captured. Task can vary from Dialog, batch etc. Selecting * in Tasks indicate all the tasks will be captured. /wp-content/uploads/2013/07/1_247239.png · The Workprocess allows to select the server for which the trace is to be captured. In general all the servers will be captured when not specified. /wp-content/uploads/2013/07/2_247240.png · The Current Mode option is used trace the flow of a Transaction or a Program /wp-content/uploads/2013/07/3_247241.png · The Schedule option is used to run the trace for a batch job for a varied selection criterion as Job name, User name, Program associated with the Job. /wp-content/uploads/2013/07/4_247242.png Type of Trace ST12 trace can be initiated as an ABAP Trace or Performance trace or both. Setting the Size&Duration Parameter to MAX as highlighted will ensure that the whole trace is captured in case the trace extends to a long duration. /wp-content/uploads/2013/07/5_247243.png Start and Collect of Trace Let us assume that the trace is to be taken for flow associated with checking the Info type 0001 data of a user through PA20. · First set the required Trace parameters. Let us select User/Task option by giving the Comment, User Name, and Task type as *. And select Start Trace /wp-content/uploads/2013/07/6_247244.png · Now open the transaction PA20 and give in the Person number and the Info type and select on Overview button highlighted below, /wp-content/uploads/2013/07/7_247245.png · Now Select End Trace in the ST12 trace screen, this will take us to the collect trace screen. Click on the execute button to collect the trace details. Make sure the highlighted check box is unchecked if the trace is to be used for future analysis. /wp-content/uploads/2013/07/8_247246.png Analyzing the collected trace Once the trace is collected the trace is ready for analysis. In the bottom pane as highlighted, select the Trace which is of concern to us. /wp-content/uploads/2013/07/9_247251.png Then select either one of the 4 highlighted options for the analysis ABAP Trace · The ABAP trace is one of the most useful analysis options available in ST12 trace. It provides a Top Down flow of any Hotspot/Program/Transaction and provides a Functional Time Distribution of a flow. It displays the hierarchical order in which the call statements are executed. So it can be used to identify the issues in the flow hierarchy. /wp-content/uploads/2013/07/1_247239.png · The above screenshot is a Per Call View of the ST12 trace. The view can be changed into a Modularized by selecting the Per Mod Unit button as highlighted above. This will give a modularized flow of the Code called inside a particular module. /wp-content/uploads/2013/07/2_247240.png · The “Top Down Call Tree”(as highlighted below) option clicked when the cursor placed on a Modularization Unit Call(Method/Performs) displays all calls to the selected unit labeled as ‘0’,’1′ are statements inside this modularization units, ‘2’ the statements in modularization units one level below, and then iteratively down up to 30 levels. Letters are used to designate lower levels. /wp-content/uploads/2013/07/3_247241.png · Double clicking on any of the line navigates us to the source code. This can be used to identify the impact point. · ST12 trace captures the minute details of the flow such as the Loop statements performance, which can be used for a detailed analysis of the flow. /wp-content/uploads/2013/07/4_247242.png · As the ABAP trace captures the complete flow, this can be used as an effective tool to identify the Customer Modifications or User Exit. Note: The call hierarchy considers the call on Forms, Methods, Functions, SQL statements, Loops, Call Screen to PBO, PAI Modules. Comparison of ST12 with ST05 trace ST12 ST05 Traces only a specific user context or a transaction Traces every action of a user on a server ST12 trace automatically turns off with a transaction ST05 trace has to be manually turned off Stores the trace into database and is permanent Stores the trace into local files and overwritten regularly Provides a Top-Down flow used to find performance hotspot, issues identified by which are usually solved by code changes. Provides a bottom-up flow which is suitable for identifying DB bound performance issues, which are usually solved by Performance Tuning. Performance Trace Performance trace of ST12 is equivalent to the ST05 trace. It displays performance parameters of all the database statements executed in the flow. /wp-content/uploads/2013/07/5_247243.png SQL Summary SQL summary provides the details like Execution time, No. of records selected, Total duration, server details, etc. on a query on a database table. Double clicking on any record takes the flow to a screen which displays the list of programs which has queried on the table and the SELECT query as such. /wp-content/uploads/2013/07/6_247244.png Statistical Records The statistical records display the time related parameter of a particular transaction flow. /wp-content/uploads/2013/07/7_247245.png
Posted by No comments:

Workload Analysis and Response times



Response Time
The following SAP Notes provide information about how response time is measured and contains information about the term in general.  8963 - Definition of SAP response time/processing time/CPU time  1063061 - Information about response time in STAD/ST03 Guideline values when analyzing Average response time/Dialog step are outlined below.  
  • Wait Time < 10% of total response time (<50ms)
  • Roll In/Out < 20ms
  • Roll Wait time < 200ms
  • Load and Generate < 50ms
  • Processing time < 2 * CPU
  • Enqueue time <5ms
  • DB Time < 40% (Response time – Wait time)
  • GUI time <200ms
Please be aware these are only guideline figures, and are NOT a definitive indication of a performance issue.
The following section contains an introduction to the key components of response time and the general guide of troubleshooting.
High Wait time
The dispatcher of the SAP instance receives the incoming request and stores it in the request queue of the appropriate work process type. While the dispatcher is looking for a free work process, wait time is accumulated. Wait time ends, when the request is being forwarded to a free work process of the required type. Wait time is the first component of the overall dialog response time.
  • Check the number of Dialog work processes in SM50 or TU02 ‘rdisp/wp_no_dia’
  • Check for long running processes consuming a high number of Work Processes
  • Check for Work processes in PRIV Mode, this can indicate insufficient extended memory
  • Is high wait time the Root cause of the poor performance or a symptom of another issue
  • Activate the /SDF/MON to analyze the running status of work processes

 High Roll Wait time
In general roll wait time measures external communications and this could be GUI communication or RFC communication.
A way to check if the problem is in GUI communication or if is RFC communication is checking the GUI time and frontend network time. If you find high times then the problem is most likely to be related with GUI communication.                                                  
If not then RFC communication should be investigated.                                                                                       
Review SAP note 364625 that explains you GUI time and fronted time, and also provides details of how to review these times on a system.
Related SAP Notes:
  •  2426336 - Performance analysis of external RFC server programs (registered program)
  • 2418936 - High RFC time - Performance troubleshooting 
Please see the detail information about GUI time analysis in the following section ‘ High GUI Time ‘.

High load and generate time
Load and Generate time is the amount of the time taken by work process to copy and generate or to load and generate abap code and screens for the User request. The load and generator time is high the problem is the buffer sizes is too small (TP program or buffers and CUA buffers).
  • Check in ST02, verify if the program buffer is sized sufficiently
  • Up to 10,000 swaps per day is acceptable for the Program Buffer.
  • HitRatio% and % Freespace should always be considered when analysing Buffer Size
  • Always ensure sufficient main memory is available before making buffer increases and that all changes are tested before promoting to a production environment.
Related SAP Note:
  • 1230076 - Generation of ABAP loads: Tips for the analysis
High Enqueue time
Enqueue time is used to request and set SAP locks by making use of the enqueue
work process. Typically, this component of the dialog response time is rather small, usually less than 5 ms.
Related SAP Notes
  • 97760 - Enqueue: Performance and resource consumption
  • 2252679 - How to analyze an enqueue lock problem.
  • 2126913 - ENQU: The enqueue log
  • 2013043 - Performance Problems with Enqueue Work Process
  • 2019532 - Performance of integrated enqueue server
  Wiki Page:
  Enqueue Performance : Analysis   https://wiki.scn.sap.com/wiki/x/ihfRGg

 High Processing time
Check Operating System Monitor for a CPU Bottleneck
  • 994025 - Virtualized OS environments in the operating system monitor
  • 1084019 - OS07N: New operating system monitor  
High Database time
If data is read from the database server or changed in the database, these actions are indicated as database time (Av. DB Time). Database time is measured from the moment the database request is sent to the database server and runs until the moment the data is returned to the application server.
  • Check for expensive SQL causing high load on the system
  • Check I/O performance stats
  • Consult the SAP Notes outlined under the DBACOCKPIT section, depending on the Database Release and Version

High GUI Time
Analysis should focus on Front End: Front-End Ping (Network Check), Front-End Hardware, High Volume of Data Transferred, Many Roundtrips. If you discover that the GUI time is high despite a relatively small volume of data, this can be for two reasons: there may be a hardware bottleneck
on the presentation server or a network bottleneck. Often, the simplest way to analyze this further is to filter out the users who typically experience these problems from the single-record statistics.
High GUI Time, can sometimes be the result of a non-optimally configured SAP Easy Access Menu. Check for high GUI Times associated with the transaction SESSION_MANAGER, if high times are identified it is a good idea to run the report ‘EASY_ACCESS_NUMBER_OF_NODES’ via SE38. This report identifies the number of menu nodes configured per user. A high number of menu nodes increases GUI time and reduces performance.
When using SAP Easy Access Menu:
Menu should not contain more than 1000 entries (For comparison: The complete SAP menu contains 70,000 entries). The Tree is loaded to the user context at a glance. A high number of menu entries leads to high memory consumption on the application server and to long response times for the menu.
Related SAP Notes
  •  2428353 - How to analyze high GUI time on SAP systems
  •  851012 - SAPGUI: Performance trace - technical details
  •  305363 - Create frontend trace file 
  •  500235 - Network Diagnosis with NIPING
  •  203617 - ‘High memory consumption with Easy Access menu’
  • 357693 - ‘Redundancy avoidance in Easy Access’
Posted by No comments:

SAP liveCache Transactions

SAP liveCache Transactions

This page provides information about SAP liveCache/SCM transactions.

LC10

liveCache assistent (transaction LC10) is the central tool to administrate and monitor the SAP liveCache (liveCache (SAP liveCache Technology), liveCache Assistant).
The permission concept for the usage of LC10 is described in note 452745.
If you have a problem with LC10, please check note 415376.
If you have problems with starting or stopping liveCache in batch, please check note 821200.
Where transaction LC10 gets the information from, which is displayed in menu DBA History, is described here.
The system tables evaluated in some other LC10 applications (like e.g. OMS Monitor and Heap Usage) are explained here.

/SAPAPO/OM01

Using transaction /SAPAPO/OM01 you can view the LCA trace.

/SAPAPO/OM02

Using transaction /SAPAPO/OM02 the LCA trace can be activated.

/SAPAPO/OM04

Transaction /SAPAPO/OM04 shows information about the used LCA build. However, more information is displayed in transaction /SAPAPO/OM13.
Example:
Modulname  Release  Patch Build-Info                Opsys      Changelist
libCOMBase 3.0-b040 001   APO 3.0A: 040-001-305-306 AIX RS6000 305306
libSAPAPO  3.0-b040 001   APO 3.0A: 040-001-305-306 AIX RS6000 305306
libSAPATP  3.0-b040 001   APO 3.0A: 040-001-305-306 AIX RS6000 305306
libSAPTS   3.0-b040 001   APO 3.0A: 040-001-305-306 AIX RS6000 305306
libSAPRPM  3.0-b040 001   APO 3.0A: 040-001-305-306 AIX RS6000 305306

/SAPAPO/OM11

Transaction /SAPAPO/OM11 is the "logging log". Here you can see e.g.
  • if transaction /SAPAPO/OM17 was used to perform a consistency check,
  • if the liveCache has been initialized,
  • if report /SAPAPO/OM_DELETE_OLD_SIMSESS is scheduled,
  • if report /SAPAPO/OM_REORG_DAILY is scheduled.

/SAPAPO/OM13

Using transaction /SAPAPO/OM13 you
  • get an overview of the versions of the used components (e.g. SCM SP, DBSL, precompiler),
  • can check the network,
  • get an overview of the liveCache state (e.g. display of knldiag, display of cache information).
Prerequisite of the network check is the installation of tool NIPING on the liveCache server. Detail information about this can be found in notes 458221 and 500235.
As of SCM 4.1 also the different system times are displayed. This is helpful when liveCache, LCA routines and the application server work with different times and you need to analyze data from different traces.

/SAPAPO/OM16

Transaction /SAPAPO/OM16 is the liveCache data browser. Using this transaction you can view e.g. the size of planning versions. Only the current client is considered. The planning version specified as current planning version needs to fit into the data cache.
Using the following SQL statement you can get the size (in pages) of all planning versions:
select sum (pagecount) from classcontainers group by schema order by 2 desc
As of SCM 4.1 transaction /SAPAPO/OM19 is available which will replace transaction /SAPAPO/OM16.

/SAPAPO/OM17

Using transaction /SAPAPO/OM17 you can check and establish the consistency between liveCache and SCM system.

/SAPAPO/OM19

Transaction /SAPAPO/OM19 is the liveCache data browser. This transaction is available as of SCM 4.1.
Posted by No comments:
Subscribe to: Posts (Atom)