With this blog I’d like to share my point of view on definition and usage of checkpoint-groups. I won’t focus on configuration of checkpoints groups nor using with break-points, log-points and assertions, because these topics are widely discussed in SCN.
This is the reporting of what we (my colleague 
sergio.ferrari2/blog and myself ) found in a productive system of a customer.
Once you read the official documentation and surfed thru’ the various blogs and wiki pages, you would realize the advantage of the adoption of this tool: improvements in the quality of ABAP codes and correctness of programs, etc ...
This is truth, however…with some gaps. Do you want to know why?
The issue…
I have to be honest; until I had a challenging problem with a standard program, I never used checkpoint groups even for self written ABAP applications.
During the last project I had to fix a bad behavior in a very complex standard transaction and this experience made me aware that everything would be much easier if I activated a checkpoint-group.
The problem I had was strange and had all the characteristics of a program’s bug, but instead of requesting the support of the OSS, I made sure that the origin of that issue was due to any customization as an enhancement implementation, an exit routine or even a repair to the standard.
A voice in mind start repeating: “Ok Andrea ... no problem. Just starting from the transaction, get the custom code, activate a break point then check, using the debugger, if the custom code is the cause of the problem …”
It wasn’t so easy!
We mixed data coming from different trace tools generating an accurate list of the custom routines called during the transaction processing ; using this list we activated a lot of break-points (1 break for each custom routine) in order to check that the custom code didn’t influence the normal flow of the standard transaction...
Well, if I set a checkpoint group and added a BREAKPOINT ID statement in all the custom routines, my analysis would be very easy!
Lesson Learned
I spent a lot of time in reading ABAP code and debugging applications and I can assure, that SAP standard code makes a wide use of the checkpoints groups.
In my opinion this is one key to good, robust and efficient programming; very often we are tempted to quickly code a new functionality without looking forward…
Although we wrote one of the most beautiful ABAP program in the world, what could we use in order to analyze the program in case of problems?
Checkpoint group as a standard of custom developments 😉
Try to look forward and imagine that maybe someone else will have to solve an issue of an application written by us.…
Why don’t we start using the checkpoint groups as a standard?
Beware of the LOG-POINTS
As we already know, the LOG-POINTs can be used to collect the values of some variables in order to allow the developers to analyze their content and solve the problems but… once activated do not forget to turn them off!!!
It can happen that, for any reason, the value of the profile parameter abap/aab_log_field_size_limit has been set to 0 (no restriction) by system administrators (see docu), checkpoints have been activated and an huge amount of collected log records was never cleaned-up.
Once LOG-POINTs are activated, log data are collected in tables SRTM_SUB and SRTM_DATAX; over time, these two tables contain so many records that transactions /nSAAB and /nSRTM became no more useful; any query on checkpoint group logs takes very long runtime and even worst they never end so that it is not possible to delete the logs.
Generally a checkpoint wouldn’t be active for such a long time and create so many entries, but this can happen; we discovered at one customer more than 40 millions of records in table SRTM_SUB.
Unfortunately SAP doesn’t provide a report which would delete such large numbers of entries in batch and the easiest solution would be that the DBA team truncates the two mentioned database tables (SRTM_DATAX and SRTM_SUB).
These tables are used only for checkpoints (trx SAAB) and won't lose any productive data when truncating these tables.
Is everything under control?
One thing that I don’t like in this tool is that once you activate a checkpoint group you must also remember to deactivate it.
Yes it’s real; SAP doesn’t provide a mechanism for automatically deactivate a checkpoint group nor a concept of time validity, especially for the LOG-POINTS.
1. How could I check how many checkpoints groups are active in my system?
The first method is absolutely standard; you can get a list of all the active checkpoints groups directly from the SAAB transaction by selecting the menu: Activation> Display> ALL
However, if you need to perform this simple but useful check as a scheduled background job , I implemented a simple report and the code snippet can be found here.
2. How could I delete the active checkpoints groups?
All the checkpoint activation can be deleted from the SAAB transaction by selecting the menu: Activation> Delete> ALL
3. How could I delete the records in the log tables?
The easiest solution would be that the DBA team truncates the SRTM_DATAX and SRTM_SUB tables , but we love abap programming so the following snippet could be useful
Hope this helps 😉
- SAP Managed Tags:
5 Comments
| User | Count |
|---|---|
| 6 | |
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
