oJAYo SAP training

This SAP article will guide you all about “How to validate performance improvement in SAP” step by step with screenshots.

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.

Steps to validate performance improvement in SAP

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.

Now, you must have got clear idea about “How to validate performance improvement in SAP”.

This SAP article will guide you all about “The SAP Lock Concept” with screenshots.

This article will cover the following topics

1. What is SAP lock and how is SAP lock different from database lock?


2. SAP lock/enqueue solution architecture overview


3. SAP lock operation health monitoring
   
   1. Monitoring various SAP lock fill levels
   
   
   2. Monitoring SAP lock rejected rate
   
   
   3. Current top users which is holding most of SAP locks
   
   
   4. Monitor old/stuck SM12 lock entry
   
   


4. SAP lock issue trouble-shooting
   
   1. SAP lock issue overview
   
   
   2. Delete Stuck/orphan SAPSM12 lock entries
   
   
   3. Application program lock collision – causes and fixes
   
   
   4. SAP Lock table overflow – causes and fixes
   
   

1 What is SAP lock and how is SAP lock different from database lock?

SAP lock is an application protocol to ensure that one business object is modified/changed by one user or one execution of one transaction or one job at one time. Application would place request to lock an object like sales order, the application can proceed with the change logic only lock request is granted, after changes is completed, the lock on the business object would be released. A granted SAP lock request is held in an in-memory central lock table with a configurable size via SAP transaction RZ10. A lock request can only be granted when there is no existing lock related to the business object in the central lock table.

SAP lock is different from database lock. The SAP lock is on business object level. One business object can be stored in many tables. SAP lock is an application protocols – which means an application can still change a business object which is locked by another application if its’ design is to ignore the protocols. So it is kind of “soft lock”. Database lock is at entry or table level which is a “hard lock”. No SAP application can change a table record if there is a database lock on it.

2 SAP Lock/Enqueue solution architecture overview

Understanding the SAP lock solution architecture can help us to do performance trouble shooting performance issue related to SAP lock.

A typical SAP system consists of one or more application instances/servers and Central Instance. In this case, SAP lock communication path is: the lock request from the program is sent to local dispatcher which passes it to Message server which is on the CI. Then message server engages the dispatcher of CI, which forwards the request to the Enqueue work process where SAP lock request is executed.

Figure 1 SAP enqueue/lock solution architecture

Please take note that I have not listed backup file used to keep locking entries owned by updating process. Also, Figure 1 is based on a classical SAP system which consists of a central instance and several dialog instances. SAP work processes on central instance which have direct access to lock table would bypass dispatcher, message server and lock server.

3 SAP Lock Operation Health Monitoring

SAP Lock operation – health monitoring is to make sure that there is no risk of lock table overflow and no lock entry remains in table beyond reasonable duration. You monitor those areas via SM12 built-in features – Enqueue statistics and “Top capacity usage”.

Please refer to below figure 2 for explanation of SM12 Enqueue statistics. You can click here to know how to run SAP SM12 in full details.

Figure 2 SAP SM12 Lock Statistics

3.1 Monitor various SM12 Fill levels

We need to make sure that there is enough “Idle” lock capacity defined by the gap between Maximum number of “Lock Entries”/”Lock Arguments” and Maximum Fill level, so there is no risk of lock table overflow. I would prefer a maximum 90% utilization as a threshold for further investigation. We also need to pay attention to current fill-level. If current fill-level is around maximum fill level, then it might be a time to closely monitor the lock operation. Maximum Fill level is only meaningful after system has been up and business operation has gone through a full cycle.

3.2 Monitor SAP lock Rejected rate

Rejected rate is calculated as Rejected/”Enqueue operations” X 100%. You need to be aware of normal accepted rejected rate of your system. In my system, normal rejected rate is around 1%. If rejected rate goes significant higher, this can indicate a system wide SAP lock issue. The number of enqueue operations and the number of rejected is the accumulation data since latest start of the system. To see current rejected rate – you can take two snapshots of SAP lock statistics at two different moments to calculate the rejected rate for the period.

Following chart is an example I used to verified whether SAP lock rejected rate is normal. There was an application enqueue issue which impacts several business function areas for several days. The issue was resolved but someone was questioning why rejected rate was still high. I explained that data showed in Rejected field was an accumulated data – then I produced a rejected rate for a latest period to show “current” rejected rate which was at 1.5% – that calmed concern whether we were still having lock issue.

3.3 Monitor current Top SAP lock capacity user

Any single user/program should not generate more than 5% of maximum number of “lock entries”/”lock arguments” normally. We need to check who are placing most of locks when fill level is close to quotas like Maximum number of lock entries allowed. Then we can review whether number of lock entries can be reduced via changing program code or the way which the program/job is executed. There is no one-size-fits-all approach to decide what is acceptable number of locks which can be placed by one program…The bottom-line is that program logic has been designed properly in terms of SAP lock operations – lock as late as possible and release as soon as possible to avoid lock table overflow.

3.4 Monitor old/stuck SM12 lock entry

This is to make sure that old entries should be removed promptly. This has not been significant in my experience from system/application performance point view. But it could be important f number of entries stuck are significant or old lock entry is related to a frequent access object.

4 SAP lock issue trouble-shooting

SAP lock issue can cause SAP application program/job/process termination due to failure of securing a lock. Or it can be slow down a business process due to a lot of time spent in getting lock. It can cause impact all users and business operations due to shortage of SAP work process when many SAP work processes are stuck in SAPLSENA program.

4.1 SAP lock issue overview

Based on SAP lock architecture showed in Figure 1, we can know theoretically lock performance issue can be due to ill function of following components:

1. Program


2. Dispatcher


3. Message server


4. Lock server


5. Lock table


6. Application server


7. Network

You can use SM12 diagnosis function to validate whether a SAP lock problem is due to dispatcher, message server, lock server, application server or network:

1. SAP SM12 -> Goto/Extra -> Diagnosis/Diagnosis in Update and


2. SAP SM12 -> “test” in OK/command window -> Error Handling -> Diagnosis Environment.

You can use SAP transaction SM21 to review system log for SAP lock issue or use ST22 to review core-dump of a program due to lock failure.

In reality, most of performance issues related to SAP locking operation are due to application logic, slowness of SAP lock release, stuck/old SAP lock entries and lock table overflow.

4.2 Delete stuck/old SAP SM12 lock entries

It often happens that SAP lock entries can be left in the lock table due to malfunction of SAP system operations. So what is a big deal if this happens? How critical and how urgent should we deal with such stuck SAP lock entries? This really depends on particular situation:

• Volume of stuck entries :– If a huge number of lock entries are stuck can lead to SAP lock able overflow. If a huge number of lock entries from many different users, this can indicates Malfunction of SAP system.

• Lock attribute of stuck entries – share lock, exclusive lock, lock at table level and lock at single entry level has totally different meaning to follow SAP lock operation on the object. For example, lock on the entry level only impact subsequent SAP lock request which need to lock the same entry. Lock at table level would impact any subsequent SAP lock request which requests a lock on any entry of that table.


• Business nature which lock object represents – a lock on infrequent access object and a lock on a frequent access object would have different impact to normal business operation which needs the lock.


• Nature of business operation – a lock entry for a single business document related to archiving process is left in system. Since normal business application has no need to change the business document again, the impact to business operation in the system is “zero”. However if a lock entry is related to open customer rush order which is subject to change in subsequent business process, then a stuck entry would stop subsequent activities which needs to update the order. In case, this is an urgent/rush customer order, then it is time critical to address the stuck entry.

A stuck SAP SM12 entry can cause subsequent SAP lock request failure if the subsequent lock request needs to lock the same object. So it should be removed to avoid business process fallout/delay. But how do we know a SAP lock entry can be safely deleted? How old is old enough? Following is my tips to safely delete a stuck SAP SM12 lock entry:

• SM12 Lock entry is not owned by updating task( backup flag is not checked)
  
  • Orphan SAP lock entry can be deleted – Orphan means owner of this lock is not active in the SAP system. You can find owner information from SAP lock entry detail – especially, SAP host name, user name, SAP work process#. SAP work process# has a process type (background, Dialog etc.).
    
    • If the lock is issued from a background work process on a server but that “BGD” work process is handling request from different user now or that “BGD” work process is in idle status, then the lock is an “orphan” lock and can be deleted. So on.
    
    
    • If the lock is issued from a dialog work process on a server and the related SAP user is not logon in SAP system( SAP SM04 and AL08 to check logon users). Then the lock is an orphan entry. Please pay attention that a SAP “DIA” work process is designed to be shared among online users which might execute different SAP transactions/programs – an user task would be rolled out of a SAP dialog work process during the online user’s “think”/”pause” time. For that reason, it is normal that an online user have locked a sales order, but you do not see any work processing running under that user in SAP SM50 and the process from which the lock is issued is in “waiting” status. So you cannot say since the work process is idle now, then the sap lock entry is “orphan”. But you properly can use “date time ” of lock entry details to say whether a sap lock entry is orphan if your system has a timeout setting for inactive online user and process.
    
    
  
  


• SM12 Lock entry is owned by updating task( backup flag is checked or shadow/blue entry)

In General, you do not delete an SM12 lock entry whose backup flag is checked. The SAP lock entry will be removed automatically after related updating task is completed. However in following situation, a lock entry can be deleted safely.

• Any SAP SM12 lock entry older than updating task retention period can be removed


• A SAP SM12 lock entry can be deleted if no outstanding updating task exists in SAP updating task monitor SM13. For example, SAP SM12 lock entry is under user A, but SAP SM13 update backlog contains no entry from user A. In this case, this SM12 entry can be deleted.

Improper deleting SM12 lock entry might cause data integrity issue for related table or business object. Make sure that you have checked SAP system, job and user to reach a conclusion that it is safe to delete a SAP lock entry.

4.3 Do trouble-shooting on SAP lock/enqueue collision – SAPLSENA

4.3.1 THE SAPLSENA ISSUE DESCRIPTION

SAP lock/Enqueue issue related to program SAPLSENA is the most often-seen and tricky SAP locking issue. When this issue happens, one or many Sap work processes are continuously running with report SAPLSENA in SAP work process monitor SM50 screen( refer to Figure 3 to see sample screen) and SM66 screen( refer to Figure 4 to see sample screen ). In worst case, all SAP work processes are occupied by report SALSENA program for a period. Those SAPLSENA work processes are keeping requesting to get a SAP lock. So in nature, this issue would impact program/process which needs to change business object when SAP system still have enough “idle” work processes.

This issue itself is an application issue since SAP lock is an application protocols implemented in business application/program. In some cases, the issue can disappear by itself without any human interaction if you wait “enough” time. It could be normal that some of SAP work processes are running with program SAPLSENA for a brief moment. It becomes an issue when a SAP process is seeing running with SAPLSENA for a significant time and it has a material impact on runtime of a business transaction.

Figure 3 SM50 – many processes are showing SAPLSENA under report

Figure 4 SM66 – Many work process with a ENQ status and SAPLSENA program

4.3.2 WHY DOES THIS ISSUE HAPPEN?

In online transaction, if you are going to use SAP transaction va02 to modify a customer order which someone else is changing it via the same transaction or other standard SAP transaction, your transaction would be aborted by SAP and telling you that another user else is changing it. Then you can only change the order again after the user’s change on the order is completed. In situation like this, what you have seen in figure 3 or figure 4 would never happen since lock request duration is under a few milliseconds, you normally do not see program SAPLSENA displayed in SM50/SM66 screen.

In background processing, SAP application can have a logic of keeping trying until lock is secured assuming whoever holds the lock would release the lock quickly. This type of design is to avoid interruption of background process execution.

If the program who holds the lock cannot release the lock quickly for some reasons or there are huge number of requests to lock the same object, so the lock request keeps retrying, that makes program SAPLSENA visible in SM50/SM66 like figure 3 or figure 4 would be observed in SM50/SM66 and many business transactions/processes would be put on hold due to this.

Figure 5 is a standard SAP code, Program would execute the DO-ENDDO loop until the lock request is successfully placed.

Figure 5 DO-ENDDO loop for lock requests

Please note that I am explaining the technical reason why lock requestor is seen

4.3.3 HOW TO DO TROUBLE-SHOOTING WHEN SUCH ISSUE HAPPENED?

When this issue happens, it is important to understand what business object is involved and who is holding the lock. To find out such information, you have two ways

Log enqueue operation via SAP transaction SM12 – you can find out business object (lock object) involved in collision based on SM12 log. Please remember to switch off logging after you are done to avoid disc space issue. Several minutes log should be enough. Please refer to SAP Note 125041 to know SAP enqueue log format.

Do an enqueue trace via SAP transaction

ST05/ST12 – This is my normal way to verify what is collision and who is holding the lock which block the process being traced. You can base on collision owner to find out server/instance and work process related to lock holder process. Collision object is a lock object – you can use SAP SE11 transaction to check lock object “description” to find related application area. You can contact the SAP user to find out more about the application related to the lock holder. Based on those information, you might identify the offender, review possible solution or next step. Please refer to Figure 6. Figure 6 is an enqueue trace related to one SAPLSENA performance issue where all SAP transactions which related to order creation and order changes were stuck. Based on the trace, I was able to identify and later confirmed that SAP CIF model activation job was the root cause.

Figure 6 – Enqueue trace statement details

In our production box, our users were complaining slowness of deleting workflow item via SAP transaction SBWP. In SM50, many processes are stuck with program SAPLSENA. This was caused by an application setting which was causing lock contention. You can refer to my post “SAP SBWP workflow item deletion performance issue“.

4.4 SAP lock table overflow

4.4.1 WHAT IS SAP LOCK TABLE OVERFLOW?

In what is a SAP lock section, it is stated that a granted SAP lock is held in an in-memory table whose size is specified via SAP parameter enque/table_size. So there is a limit on how many lock requests can be hold in the lock table. When that limit is reached and a program is making a new lock request, the SAP system would send “lock table overflow” error message to the program.

SAP lock table overflow is really a message that SAP lock table has been full and cannot accept new lock request anymore.

4.4.2 WHAT ARE POSSIBLE REASONS FOR LOCK TABLE OVERFLOW AND HOW TO FIX SAP LOCK TABLE OVERFLOW ISSUE?

When SAP lock table is overflow, then no lock can be granted since no empty slot in the lock table to hold the lock entry. All programs/jobs who need to place the table would fail. Apparently this happens rarely to a well-tune SAP system.

Lock table overflow can happen due to one or more of following reasons:

Small SAP Lock table is too small – due to increasing of business volume and activities, the lock table size might need to increase. SAP lock table size is controlled by SAP parameter enque/table_size.

Slow release of SAP lock – SAP lock entries are not released timely due to system/application performance issue. For example, if SAP updating function is slow or stopped, all entries which belong to updating tasks would remain in SAP lock table until corresponding updating tasks are completed. In this case, increasing lock table size is just addressing the symptom not root cause.

Improper application design on SAP lock – Application design of top SAP lock capacity user should be carefully reviewed especially if it is using high % of SAP lock capacity like 20%. When I worked on an archive project, a program used over 50% of SAP lock capacity due to faulty design and caused overflow. Please refer to my post – SAP job cancelled on error “The document cannot be blocked” to know more on this case.

Improper job/application schedule/deployment – If two jobs which would place a lot of locks and run at the same time can create lock table overflow, then these two jobs should run separate time windows if business logic allows.

Inappropriate execution – This is referring to the situation where a user is executing a transaction with abnormal volume due to accidental operation or process a huge volume in a time-window which is not allowed.

Program performance – If a program is not coded/design properly, it could hold a lock unnecessary longer. When the program is holding a lock on a common accessed business object, this would create lock issue. Solution in this case is to tune the program performance.
4.4.3 HOW TO KNOW WHICH ONE IS TRUE CAUSE?

You need to use information provided by SAP SM12 SAP top capacity used – history screen which captures top offender when overflow happens. And start to do investigation with that. Please refer to Figure 7 for the history screen.

Figure 7 SAP SM12 Top capacity used – History

Being familiar with your system and the normal fill-level and high-water mark for various fill levels, this would help you to do trouble-shooting as well. If NR_of_locks held by top offender is reasonable, then your lock table size might be too small. You need to increase it. If your system is really slow or overloaded when the lock table overflow happens, then you have to focus on system performance issue first – in my experience, this has not been a case so far.

Further clarification

Typical SAP lock performance issue described in this post is based on my performance experience. Situation in your system might be difference. I would like to highlight again that you should take caution to delete an SAP lock entry and switch off SAP enqueue logging. My personal preference is to use SAP ST12/ST05 enqueue trace, I found myself often lost in the huge number of enqueue log entries and cannot find lock holder.

When SAP updating is slow for whatever reason, an end business user cannot change a document which they have changed “not long ago”, you cannot delete a SAP lock entry to make business “happy” – this create data integrity issue. Right direction is to understand why updating is delayed and wait for completion of updating.

When you have a “system wide” lock issue with many SAP work processes running with report SAPLSENA and your SAP system is not overloaded, this “system wide” lock issue is caused by application/program/job instead of system.

Now, you must have got clear idea about “The SAP Lock Concept”.

This SAP article will guide you all about “How to identify parent job of update work process in SAP” step by step with screenshots.

You spot a long running SAP update work process via work process monitor (SAP SM50 or SM66) or /SDF/MON utilities in a SAP system, you would like to know the parent job/program which is generating the update process. So you can work with corresponding owner to tune the corresponding job/program to make updating more efficient. This can be straightforward when update process is belonged to a SAP user and the user executes only one transaction. Or this can be a little tricking when an updating process is belonged to a SAP user which is shared by many concurrent SAP jobs. This post would show you how to use STAD to identify the parent of an update work process via an example.

Steps to identify parent job of update work process in SAP

1 long running updating process showed in /SDF/MON

I found a long updating processes under SAP user BGOMUSER which is common background user-id used by hundreds of SAP background jobs in our system. The updating started after 03:16 and finished before 03:33 using work process 209 based on /SDF/MON snapshots which were take every minute in our system. The duration of updating lasted about 17 minutes ( 1,080 seconds) Who is the parents job of this long running update process?

Figure 1 a long running SAP update process in /SDF/MON

2. How to use STAD to identify the parent job/program of an updating process?

Identify transaction steps, then you can use “client record” of the transaction step to identify the parent job/program. If no client record is available, then change STAD display mode from default mode to display “business transaction total/summary” to find parent transaction step and the parent job.

2.1 Identify associated SAP STAD statistics record

I ran STAD to pull out SAP statistics records related to update tasks for the interested period from the server where update work process ran. Following is a small part of the STAD result screen.

Figure 2 STAD records for SAP update tasks

Each line is for statistics from a transaction step. The 1st line on Figure 2 is the transaction step related to long updating process showed in Figure 1 based on time when the transaction step was started, WP( *9 ), duration(1,007 seconds), and useriD(BGOMUSR). Here, WP “*9″ is displayed instead of 209. this is due to the fact that length of WP field length is 2 – in old version a SAP system is assuming that work process number is between 0- 99. But in our system, our work process number is already over 100, so there is overflow in STAD for work process number when a system has over 100 SAP work processes configured.

2.2 Identify a parent of an update work process via client info of a transaction step statistics

Here, I would find out the parent of 2nd update transaction step QA11 under user “*9120″ in Figure 2 first. I double clicked 2nd line and I got statistics details screen for the 2nd step. Figure 3 is a part of STAD details screen

Figure 3 STAD details screen – Client Info button

Figure 3 shows a button “Client Info”. I clicked it once then I got Figure 4 screen which shows the parent job in field “Initial action” among other information.

Figure 4 STAD details screen – client info details

Figure 4 tells us that the parent of the updating process is program “RQEEAM10″ which was executed by an SAP user online. So when client record of STAD is available, we can identify the parent of a transaction step.

Following the same approach, I double clicked the 1st line of Figure 2, I got figure 5 screen which has no “client info”, so where can I find its’ parent in this case?

Figure 5 STAD details screen – NO client info

2.3 Identify parent of an update process via STAD display mode – business transaction total/sums

Since the details record has no “client info” for me to identify the parent program, I changed STAD display mode from the default mode “Show all Stats records, Sorted by time” to “Show Business transaction Total”, then I loop through the record to identify the parent which contains the updating record, Please see the figure 6.

Figure 6 STAD Business transaction total screen – long update process

Now, we know that the parent of this long update process is a SAP background job and the job name is “Invoice_140320*”.

If you do not see the job name or program name displayed, you can try to use “client-info” of the parent line as showed in Figure 7 and Figure 8

Figure 7 STAD business transaction total – no parent job showed

Figure 8 Client info of a parent line for long update process

3. Further information

Here I talked on how to find parent of a completed updating process. If you are sure that an user id is used exclusively to execute a job, then you can be sure that update process under that user should be related to the batch job and you can use SM37 to find the job and so on.

RFC call is normally handled via SAP Dialog Work process. It is normal that those RFC are under a common user which can be used by many concurrent processes. RFC call can be from the program/job which is running in the same system or remote system. The same system means RFC client and RFC server are in the same system. Remote means that RFC call is from different system. You might wonder how to find a parent of RFC process in those cases. In this context, parent is actually the client which is making the RFC call. In short, you can use STAD client info to find a parent process of RFC call as well.

Now, you must have got clear idea about “How to identify parent job of update work process in SAP”.

How to identify parent job of update work process in SAP

This SAP article will guide you all about How to fix “Values of Variant is Saved for specified screens only” step by step with screenshots.

There is a business need to update one of SAP program RBDAPP01 variants to enable parallel solution to cut job runtime. When we tried to “save” our changes – packet size, server group etc., a window was popped up saying “Values of variant … saved for specified screens only”. Reviewing the variant again, our changes were partially saved- Changes on Idoc selection screen were saved but changes on screen of “Parallel Proc.” were not.

What does the message “Values of variant … is saved for specified screens only” means ? How to fix this?

If you are seeing a similar message during program variant change, this means the program has several selection screens, and you are entering data into at least one of selection screens which has NOT been selected for the variant. So data for the un-specified screen is not saved. To fix this, you need to

1. Find out screen number of the specific screen ,


2. Change the variant attribute to select the needed screen using the screen number and


3. Then you can go ahead to update the data in the screen and your data would be saved.

If you would like to know the details, please continue reading.

Steps to fix “Values of Variant is Saved for specified screens only”

1 The message – Vales of variant saved for specified screens only

Changes were made in IDOC selection screen and “Parallel Proc.” Screen, following information pop-up window was showed when I tried to save the changes.

Figure 1 ABAP variant – Values of variant saved for specified screens only

When you created a variant, you can specify selection screens needed for a variant. To fix the issue, you need to change variant attribute to include the needed screen. In this case, it is “Parallel Proc.” screen.

2 Find out screen number of selection screen

We need to verify screen number first. You can find screen number of your current sap screen via menu System -> status in the SAP window. Following screen shows that screen number is “1200″ for “Parallel Proc.” Screen.

Figure 2 ABAP variant – find out screen number of a SAP screen

3 Change attribute of program variant to include/select the needed screen

You can change program variant via S38 or directly from job step list screen of SM37. Figure 3 shows that the screen 1200 is not selected. That is why data on this screen cannot be saved.

Figure 3 ABAP Variant – specify selection screens for a variant

Click the check-button prior to 1200 and save your screen attribute changes

4 Update the program variant in the new enabled selection screen

Since the Parallel Proc. Screen of RBDAPP01 is now included as part of the variant, we can enter and save our changes without any issue now. The pop-up window is gone and status message is saying “vales of variant * saved”- Issue resolved!

Figure 4 ABAP variant – change variant

If your ABAP report program has only one selection screen, you would not run into the message when you are trying to change an existing variant. This post assumes that you are familiar with program variant creation. If not, you can refer to SAP training document.

Now, you must have got clear idea about How to fix “Values of Variant is Saved for specified screens only”.

This SAP article will guide you all about “SAP Performance”.

Here, we will cover the following :-

1. Definition


2. Why performance matters


3. What influences performance


4. How can we achieve good performance


5. Performance issue classification

Definition

When we think of performance of application or system, the first thing which comes to our mind is time � the time which a business transaction or system take to complete business work. Time is money. So there is no doubt that time is a critical measure or characteristics of performance. If a business transaction cannot finish in business expected time, the performance is not good for sure. Would it be true that performance is good if a business transaction can always finish in time? Is time the only measurement or characteristics of performance?

My answer to both questions would be �NO�.

A transaction can finish in expected time does not necessary mean the performance is good. An individual transaction can complete it works in time but at expense of system resources or other programs performance. It can use more CPU, memory, network etc resources than what it is really need for the job. By doing so, it could take resources away which otherwise is available for other functions and create extra demand on resources which might need more investment. By taking away resources, it can impact other transactions which are running at the same time. In a SAP system, there are many resources � you can use different resource combination to get the same work done. I see it often that cutting down resource usage can reduce time which a transaction takes. It is not a surprise � resource usage is always associated with time. Resource usage is transparent to business users. It is a technical concern which would ultimately impact business.

Performance is also concerning about �citizenship� in its� operating environment. Many business functions and processes share the same operating environment. Running one function or process should not impact following �colleagues� in the operating environment. A transaction which has a good performance should leave footprint in the system as less as possible w/o impacting its� follow transactions in the system.

So performance of a business process or transaction or function should have following characteristics in my review:

� Time – Its� abilities to meet or beat quantified business performance requirement in a �normal� system status.

� Resources – Its� abilities to use system or application resources as much as it needs, as when as it is necessary and in a balanced way.

� Citizenship – Its� abilities to be transparent to other existing/future processes/functions in the operating environment.

Now, it is obvious that good performance in my position is that a program can meet quantified business performance requirement, use as much resource as it needs, user resource as when as it is necessary and have no impact to others functions in the SAP operating environment which it is run.

Have a good understanding of performance is the basis for performance analysis and performance measurement. Having SAP project management and business stake holders to have a good understanding on performance is the key to get needed support.

Why performance matters

Good performance helps to maintain company reputation which is valueless. Imagining what damage would be done to a company if the company cannot produce financial report in time due to system performance.

Good performance makes everything predictable, this helps business to do planning and coordination. Order management process owner can know how long it takes to get order loaded and how long it takes to send order to warehouse for picking, when everything can be ready for shipping etc.

Good performance normally means more work can be done in the same time. So employee can become more efficient and this can increase their job satisfaction.

Good performance can also help to lower solution TCO. It allows more to be done using existing resources. It helps to avoid un-necessary hardware upgrading. It lowers operation support/maintenance cost. It helps to give employee positive job experience and job satisfaction.

Good performance also can help to improve customer�s satisfaction and help to retain customers. Customers might go to different supplier if you cannot ship their orders in a timely fashion.

What influences performance

I review performance as a product of system which has many components. In my view, a given SAP performance system has following key components

o System � SAP System here is referring to IT infrastructure and configuration of IT infrastructure where application and program is operating in. This includes but not limits to server, network, storage etc. It is obvious that we would not have good performance if related IT infrastructure is not enough or it is not appropriate. Some components of IT infrastructure like network are shared within with other applications. When we talk performance, we need to remember status of IT infrastructure is important to performance as well.

• Application :- This is referred to SAP application package and its� architecture which is delivered by SAP company.


• SAP configuration :- This includes SAP system resource allocation, database configuration and SAP basis configuration etc.


• Business solution :- This includes solution architecture, all development/program or configuration made in SAP for a business solution and the deployment of the business solution.


• User – I am mainly referring to end business user who would executes/owns a SAP business transaction in the system. Business user is ultimate driver for the system, application and programs. It is based on their input that a system is built and measured. I am not referring to the IT professional who design, build, deliver and maintain such system, application and programs.

Performance issues can root from each component of a SAP performance system in general. But Most of performance issues are attributed to business solutions. Based on my experience, I rank them in following order based on frequency where performance issue happens.

1. Business solution :- Majority of performance issue is related to local development. In my experience, 70% of performance issue is related to business solution.


2. SAP configuration :- SAP configuration can cause a performance like no enough memory, no enough work-process etc.


3. Users :- Users can cause performance issue in the way on how a transaction is executed. Performance of a transaction can varies based on user input to the program.


4. SAP Application :- I have seen it again and again that performance issue can originated from standard SAP solution due to special scenario of your processes such as high volume etc.


5. System :- System can creates performance issue � especially when network is busy, file-system is out of space, or there is an IO hotspot etc.

What we can do to have good performance

Good performance of a SAP application is a result of total application performance control in SAP development/project or/and proactive SAP performance management in operation.

In SAP development/project, we need to have an end-to-end performance control approach – which build different performance control activities into each phase of SAP project/development supported by performance tools and performance processes. There are different ways to check and verify performance at different stage of the project. Different ways complement each other and work together to ensure that project solution has a good performance. It focuses performance issue prevention, earlier detection and earlier resolution. This helps solution to meet performance objective and help project to deliver on schedule.

Proactive performance management in operation is to proactively monitor health of system and application, find trends of resources usage and detect potential performance threat earlier using existing SAP performance tools/transactions.

Performance issue classification

There are different ways to classify performance issues. I would cover some of them which I think important.

Performance issue can be divided into run-time issue or non-runtime issue. Runtime issue means that user has to wait longer than normal to get system�s response. Non-runtime issue is referring to the situation like program abortion on resource contention like lack of memory, out of disc space etc.

Base on impact scope, performance issue can be classified into:

1. System level – System level performance issue would impact every function and every user in the SAP system.


2. Instance level – A system can have more than one instance. Instance level issue would impact every function and every user in that instance.


3. Site-level – Site level performance issue would impact every users on one particular site and office.


4. Business function area level – Function level issue is refer to performance issue


5. Process/transaction level – This is the most common performance issue reported by user. This issue is normally on individual


6. User level – only single user is reporting performance issue – like performance issue at presentation level or local pc level.

Based on technical nature, performance issue can be classified into:

1. Program/code issue :- Performance issue is rooted from the program itself including design and code.


2. Local system resource issue :- Performance issue is rooted from shortage of system resources like CPU, Memory and Disc-space. Memory includes SAP memory and database memory.


3. Local system issue :- Performance issue is rooted from system/database status like system and database bug etc


4. Remote system/client issue :- Performance issue is rooted from external system/client like remote system/client is not available or too busy.


5. Network issue :- Performance issue is rooted from network issue � like sudden increased network traffic etc. SAP server and non-SAP server are working as normal.

Understanding scope of performance issue is important to assess priority of the issue and possible cause of the issue.

Further, we need to clarify a performance issue: whether it is one time issue or it is a consistent issue. The former might be a treated an incident, normally have quick solution can be related to random system status or wrong operation of user, improper input etc. The latter is a problem which might be rooted from design, program code or consistent business pattern change etc and need more effort to address this.

Now, you must have got clear idea about “SAP Performance”.

This SAP article will guide you all about “Buffering Database Tables in SAP”.

In a SAP system, there are many layers of data buffering – IO subsystem, database system, application and program. All buffering is to make data available in memory so request for the same data can be fulfilled via memory. This helps data retrieval performance and underlying business transaction or program performance. In this post, I would talk about SAP table buffering at SAP application level.

1 SAP table buffering introduction

1.1 SAP buffering concept

SAP table buffering is to store data of a table in an application server memory. After data is in memory and no data change, any request for data in the buffered table by any program or business application executed in the server would be fulfilled from the memory of local application server without involvement of database server. ABAP trace in my SAP environment shows that getting data from buffer can be up to about several hundred times faster than getting data from database server.

Figure 1 SAP buffering Overview

SAP buffering pros and cons

Figure 3 SAP Table buffering pros and cons

1.2 SAP buffering types

SAP allows three type of buffering choices – single record buffering, generic records buffering and full table buffering. All those types of buffering are referring to size of “data entry” which would be managed by the SAP buffering mechanism in buffer loading, swap, data change management.

Figure 4 SAP table buffering types

In following section, I would talk about how to select right buffering type for a table.

1.3 SAP buffer for table buffering

The application server memory used for SAP buffering is called SAP buffer. There are two types of SAP buffer used in table buffering – Generic Key buffer and single record buffer. Generic buffered table and fully buffered table would share the same SAP buffer – Generic Area Buffer. Size of SAP buffer is configured by two parameters: one is to specify size of buffer,the other is to specify number of the directory entries in the table buffering.

Figure 5 SAP tabe buffer parameters

1.4 SAP buffer synchronization

After a SAP table is buffered, the buffered data can be changed, this data changes need to be reflected in generic area buffer or single record buffer of all SAP servers in the system.

Any change by a sap program/user is always initiated from an application server. On the server where change is initiated, the table/data is marked “changed”/”invalid” (Actual state is “pending” in ST10) as when buffered data is changed (Whether change is committed or not makes no difference based on my testing). When buffer table is marked as “changed”/”invalid” ( “pending” status in ST10 ) in a server, the data request from the server would be fulfilled by database until certain number of read operations on the table occurs from the application server. After that number, buffer would be refreshed and marked “valid”. This mechanism is to reduce load from pre-mature buffer reloading or buffered being refreshed too often un-necessary. For example, a program can update a table hundreds or thousands of time in a seconds, if the system is going to reload the data into buffer for each update, this could bring down the systems.

Now what are footsteps used by other servers for buffer synchronization? When a buffered table is changed, a change entry is logged into SAP table DDLOG. SAP buffer has a mechanism to read DDLOG table “PERIODICALLY” to know what buffered table is changed and from which server, based on that information, it would mark the buffered table as “invalid”/”changed” in all remaining SAP application servers. So there is a delay between data is changed in one server and corresponding data in memory is marked as “invalid”/”changed” in remaining instances of the system. Extent of delay is determined by parameter RDISP/BufRefTime, timing of a data change, volume of buffer table changes and instance/server performance. After a table is in “pending” status, data needed by a program from a server would be from database table. The table would be loaded into buffer again after a certain number of read operations on the server. Please click the post how ST10 buffer state is change for details. So remember when table is in “valid” status, the data would be read from buffer for the server even it is already changed in another server!

Apparently, the delay of buffer synchronization only matters for the SAP system with more than one application server/instance.

What are SAP buffer synchronization parameters? They are:

1. RDISP/BufRefMode – when there is more than SAP application server/instance, this parameter should have value of “Sendon, ExeAuto” – this enables buffer synchronization. Value of “sendoff, exeauto” means no buffer synchronization – applicable for sap system with only one SAP application server/instance.


2. Rdisp/bufRefTime – this specify interval between two adjacent buffer synchronization so buffer can be synchronized periodically. It has a default setting “60″ seconds.

You can use SAP program RSDBBUFF

to know when latest buffer synchronization is done for an instance/server and how far away the server/instance is from next buffer synchronization. However if you would like to know what table buffered entries are changed in the past, SAP program RSTUNE60 can help.

1.5 how to activate SAP table buffering

You might be wondering how to enable buffering for a selected table? Table buffering is a technical setting of a SAP table. SAP transaction SE13 allows you to display or change technical settings of SAP table directly. On the technical setting screen, you just need to switch on the buffering and check the right buffering type as showed in the following screen. You know you need to save the changes – after that, you are done – your table is buffered as per your instruction.

Figure 6 SAP table buffering setting

When you select buffering type – Generic Area buffered, you need to specify how many key fields should be used according to your buffering design. Of course, number if key fields specified should be less than number of fields which the primary index has… otherwise, it is a single records buff.

You can use SAP SE11 transaction to display and change technical settings using menu option of SE11 screen( 2nd screen) as well

1.6 SAP buffering monitoring

SAP transaction ST02 can be used to monitor SAP buffer and memory at instance level to see whether there is enough buffer space. SAP transaction ST10 can be used to monitor access status of both buffered SAP tables and not-buffered SAP tables.

1.7 Table buffering makes a performance difference – an example

Following is result of a ST12 ABAP trace on a business transaction execution. TABLE USR05, TVTA and /VSO/M-VSO_SETUP are buffered configuration tables. VBAK and VBUK are transaction table which has no buffering. Select statements are using full primary keys of those tables.

Above table shows a significant SQL runtime difference between reading buffered table and non-buffered table when primary keys are used.

2 How do we determine whether a SAP table should be buffered or not?

2.1 What should we consider to buffer a table?

Bye now, you know how SAP table buffering is working now and significant runtime improvement for table access through buffering. So you might wonder how we can reach a decision on whether a SAP table should be buffered or not.

To reach decision, you need to consider following factors/guidelines

Figure 7 SAP table buffering – influencing factors

Following are further prints to help you to understand above points better:

1. Table size – In general we should not buffer a big table since memory is normally limited. We should be extra diligent when you buffer a table which is bigger than 1% of defined buffer space.


2. Data change habit – This refers to when, how often, volume of change related to table. In general, we should not buffer a table which is changed frequently. A table with a change/read ratio > 0.5 should not be buffered normally.


3. Data access habit – This refers to access frequency, access time pattern, access volume pattern (associated selection criteria) and load generated by the SQL. we should not buffer a table which is seldom accessed/queried by SAP programs/transactions. How table is access or access pattern is important as well. Buffer a table with higher database load can be good for database performance. Common wisdom is what is good to database would be good to SAP application. Your option to buy into thisJ. Certain SQL SELECT statement would bypass buffer. If majority of SQL statements being used for a table would bypass buffer, then buffering the table makes no sense.


4. Buffer synchronization delay impact – We should not buffer a table when buffer synchronization delay results in obsoleted data being read by other SAP programs/transactions. This is not a concern for a SAP system with only one application server. If business insert/update data in a quiet window (Data change habit), then this is not a concerns any more.


5. Business performance requirement – If buffering a table can improve a business process performance significantly, then we should consider buffering seriously.


6. Buffer and memory status – If buffer space is not enough and cannot be increased due to physical memory limitation, buffering new table might create more displacements or swaps. If there are heavy swaps in table buffer area, you would make the things worse to buffer additional table, I think you can agree with me on this. It is better to maintain 10% of free buffer space – do not forgot to check free directory as well.


7. Database server and application server load status – this would help us from load distribution point view – where is the best place to keep the load based on specific case. The general wisdom is to remove load from database server to application servers. but if your application server is already overloaded and database server has a lot of idle power, it would not makes sense to buffer a table before application server load can be mitigated. The normal recommendation is that SAP server/instance should maintain at least 20% free CPU power for peak processing – this is especially important to DB server.

Standard SAP table has a predefined setting on table buffering attributes. You should not change the setting for a standard SAP table in general. A SAP tables which stores business transaction data cannot buffered. SAP tables for master data are not buffered. SAP tables for configuration table are normally buffered. However, buffering setting on standard SAP setting can be changed suited to your specific business needs.

Consultants from SAP recommend that table over 5 MB should not buffered. But if this table is frequent accessed, very expensive, very stable, there are enough free buffer space and buffering the table can help program to meet business performance goal, then buffering the table might be a wise choice even it is 10 MB in size. If a table is small and seldom changed, but there is a high chance that delay of synchronization can create data inconsistency and impact accuracy of business result when there is a change, this table cannot be buffered.

Table buffering type is a fine setting mainly dependent on table size, table change habit and access habit. The setting would impact size of data which would be marked “changed”/”Invalid”, If each time, only one record is changed:

• Fully buffered -> all records of the table would be invalidated and reloaded to buffer by the system. One change would result in loading of whole table.


• Generic buffered ->all records which share the same common keys fields would be invalidated and reloaded to buffer by the system. Access other records in the affected group needs to get from database after they are marked “changed” until they are reloaded. Risk of getting obsoleted data if data is accessed after change and before synchronization.


• Single record buffered -> only the change record is invalidated. Other records would be valid in buffer. But single record buffered needs more round trips between database and application server to buffer a table.

Under fully buffered and generic buffered, I would like to highlight that change one record would cause more than one record being reloaded to buffer from database. When table size is big, volume of change and access is high in the same time window, this can create serious system performance issue due to frequent buffer reloading- I have seen this in my work.

If many records are changed each time, “full” or “generic” table buffering might be working better to avoid too many round trips between application server and database server related to buffer synchronization. Number of key fields should be decided based on fields reference in SQL where-clause.

So what tables can be buffered or cannot be buffered – you need to review all those factors and understanding what is your key driving factors based on your business need. There is no hard line here. Bottom line is that you need to know the context surrounding the table buffering – the system, the business application and the table.

2.2 How do we know whether a SAP table should be buffered in SAP development/project?

Here, we only consider “new” local table developed in a SAP development. Designing a new local table involves many areas – like table structure, primary key and index, data retention, data management etc. Among them, it is buffering attribute. If you do not specify buffering attribute explicitly, the table would not be buffered by SAP. Many developers overlook technical settings of SAP table. In the end, it creates performance issue and more effort to correct this later.

Transactional table cannot be buffered normally. We only need to consider local table like mapping, reference and set up tables by collecting needed information related to previous stated table buffering guidelines:

1. Who would populate data? Then when/how frequent is the data inserted to the table? How many entries would be inserted to the table? Who can be a person, a SAP job, a SAP program and an interface.


2. Who would use the data? Then when/how frequent is the data accessed? What selection criteria would be used to access data? How many records would be accessed by each user.


3. Who would modify the data? Then then when/how frequent is the data modified? What are selection criteria for data, how many records would be updated at one time window.


4. How long would data stay in the table? This is data retention period.


5. Business performance requirement. If program performance is critical, spends notable time on this table and there is no way to optimize the access, then buffering might be important.


6. Production server status – buffer/memory status and Database server/application capacity status.

Based on table definition, you know table record size already, then based on above information you collected, you can get a good indication about table size. With change frequency and access frequency, you can get a good indication about change ratio – # of changes/# of reads.

With above information, you can reach decision on buffering. For example:

1. Small table and seldom changed can be buffered if servers status(buffer and CPU) has no issue.


2. Table is not small but it is access a lot – table in general should be buffered if change habit is not a concern.


3. Table is small but change habit is a concern – then this table cannot be buffered generally.


4. Table cannot be buffered if change habit would cause data inconsistency which business cannot afford. If data is changed well before they are being used, then buffer synchronization delay is not concern anymore.

Changes here include data population, data modification and data deletion. If data is changed well before they are being used, then buffer synchronization delay is not a concern anymore.

In SAP project/development, you might need to buffer an existing local table as well, this is mentioned in following section.

2.3 How do we know whether a SAP table should be buffered in SAP production/support?

In SAP development, most information for table buffering is from business requestor who requests the development. In production box, we have different SAP tools to record table related information. We can get a lot of information related to table size, access habit, change habit and system status information.

The best starting point to analyze table buffering is to use SAP transaction ST10 – table call statistics. ST10 analysis can provide a list of table which should be reviewed here further. Click here to know how to run SAP ST10 to do sap table buffering analysis.

If SAP ST10 states that a table can be buffered, then you need to do more investigation to confirm whether it can be buffered.

• Get table size – normally refer to disc space but can be refer to number of entries. SAP transaction DB02 can tell you disc space and history. SAP transaction DB20/DB20ORA and SE15 can show you number of entry in a table. DB20/DB20ora report number of table entries from oracle statistics table while SAP SE16 transaction tell you accurate number of entry in a table by accessing each record of the table.


• Understand how the table is accessed by analyzing table SQL statements Cache via SAP transaction ST04. SQL cache can tell how many seconds the SQL has spent so far, type of SQL operation and total of number of operation. For select/update statement, it can show you the where-clause which you can get clear picture on select-conditions.


• Run ST02 and ST06 – check table buffer status to see whether there is any contention here. Using ST06 to check CPU status on database server and application server as well as main memory to see whether there is potential concern related to buffering.


• You need to talk with business owners to understand remaining details of access habit and change habit as well as possible impact from delay of buffer synchronization.


• You also need to understand the performance requirement – based on current status and time spent on that table, you can know what runtime improvement you would get by buffering the table.

With above information, you can make an informed decision on table buffering. Following the similar process, you can confirm whether you should stop buffering on a table or change buffering type of the tables. Again, ST10 information like number of invalidation and number of database records have several contributors – like se16 transaction would bypass buffer and increased number of rows. It is not safe to make a decision to remove buffering on a table just based on ST10 number of invalidations and number of rows impacted.

3. Further clarification

SAP table buffering does not support secondary index. If a buffered table is big and reading the table is not using primary index, then read a record from such table is consuming more application server CPU and benefit of runtime improvement might not be that significant than read it from database using secondary index. You might need to test to see the improvement before buffer and after buffer to make sure that runtime improvement worth the consumption of CPU and memory in application server side.

SAP application buffering also include number range buffering. Number range buffering is important for application performance. However this is not covered here. I might cover this in future posting.

There are other types of SAP buffer like program buffer etc., those are important to SAP application performance as well. They are configured by SAP basis team. I have covered them in my post – how to run SAP ST02 and use ST02 to do performance analysis on SAP memory and buffer.

We should not confuse SAP buffering with program level data buffering. Data in SAP buffer is available to all SAP programs while program level buffering is only available to a specific program while the program is running normally.

Now, you must have got clear idea about “Buffering Database Tables in SAP”.