Sunday, August 24, 2014
Friday, August 22, 2014
Thursday, August 21, 2014
Wednesday, August 20, 2014
Tuesday, August 19, 2014
Monday, August 18, 2014
Sunday, August 17, 2014
Saturday, August 16, 2014
How to validate performance improvement in SAP
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”.
How to validate performance improvement in SAP
The SAP Lock Concept
This SAP article will guide you all about “The SAP Lock Concept” with screenshots.
This article will cover the following topics
- What is SAP lock and how is SAP lock different from database lock?
- SAP lock/enqueue solution architecture overview
- SAP lock operation health monitoring
- Monitoring various SAP lock fill levels
- Monitoring SAP lock rejected rate
- Current top users which is holding most of SAP locks
- Monitor old/stuck SM12 lock entry
- SAP lock issue trouble-shooting
- SAP lock issue overview
- Delete Stuck/orphan SAPSM12 lock entries
- Application program lock collision – causes and fixes
- 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.
| 12:26:00(EST) | 10:52AM(EST) | Period defined by two time | |
| Enqueue operations | 698,445,905 | 697,164,953 | 1,280,952 |
| Rejected | 255,946,432 | 255,927,063 | 19,369 |
| Rejected rate | 36.6% | 36.7% | 1.5% |
How to identify parent job of update work process in SAP
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 fix "Values of Variant is Saved for specified screens only"
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
- Find out screen number of the specific screen ,
- Change the variant attribute to select the needed screen using the screen number and
- 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”.
How to fix "Values of Variant is Saved for specified screens only"
An introduction to SAP Performance
This SAP article will guide you all about “SAP Performance”.
Here, we will cover the following :-
- Definition
- Why performance matters
- What influences performance
- How can we achieve good performance
- 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.
- Business solution :- Majority of performance issue is related to local development. In my experience, 70% of performance issue is related to business solution.
- SAP configuration :- SAP configuration can cause a performance like no enough memory, no enough work-process etc.
- 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.
- 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.
- 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:
- System level – System level performance issue would impact every function and every user in the SAP system.
- Instance level – A system can have more than one instance. Instance level issue would impact every function and every user in that instance.
- Site-level – Site level performance issue would impact every users on one particular site and office.
- Business function area level – Function level issue is refer to performance issue
- Process/transaction level – This is the most common performance issue reported by user. This issue is normally on individual
- 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:
- Program/code issue :- Performance issue is rooted from the program itself including design and code.
- 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.
- Local system issue :- Performance issue is rooted from system/database status like system and database bug etc
- Remote system/client issue :- Performance issue is rooted from external system/client like remote system/client is not available or too busy.
- 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”.
An introduction to SAP Performance
Buffering Database Tables in SAP
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
| Pros | Further clarification | Cons | Further clarification | |
| Speed up data retrieval process | This can speed up corresponding related program and transaction. | The same data would store on memory of all application server – redundancy. | Memory demand would be higher | |
| Reduce database load | Database server is a Central Instance | Change synchronization delay. | Data retrieved by program can be out of date | |
| Reduce network traffic | Buffer bypassing can happen. | Buffer is not utilized | ||
| Reduce process residency time in a SAP work process | Reducing possible contention on work process resources |
| Buffer load during read when data is not in buffer | Buffer change/invalidation | Buffer swap | ||
| Single record buffered | Load one record into application buffer at one read. A record would not be in application buffer if it is never read since start of the instance | One record at one time. | Swap would be done at record level. | |
| Generic area buffered | Load all records which share the same partial primary keys. No read means not in buffer | All records which share the same partial primary key of the changed records are invalidated at the same time. | All records shared the same partial keys are either swapped or in memory as a whole. | |
| Full table buffered | Full table is loaded into buffer at 1st read | Whole table are invalidated upon any change on the table. | Whole table would be swapped. |
| Buffer size parameter | Further info | Number of entry parameters | Further info | |
| Generic area buffer | zcsa/table_buffer_area | Buffer Memory size | zcsa/db_max_buftab | Maximum number of buffer that can be buffered |
| Single record buffer | rtbb/buffer_length | Size of single record table buffer | rtbb/max_tables | Max. number of buffered tables |
| Table name | Buffer status | Total # of read | Total time(micro seconds) | Time per read(rounded) |
| TVTA | buffered | 58 | 826 | 14 |
| USR05 | buffered | 1,474 | 26,201 | 17 |
| VBAK | No | 2,342 | 8,260,148 | 3,526 |
| VBUK | NO | 2,342 | 6,769,828 | 2,890 |
| /VSO/M_VSO_SETUP | Buffered | 2,342 | 23,370 | 10 |
Subscribe to:
Posts (Atom)