I've lost track of how often transaction SAT has come in handy when I needed to either better understand what a program was doing or why a transaction was causing issues where troubleshooting wasn't easy. Because of my many positive experiences with SAT, I'm surprised that this very helpful transaction doesn't yet appear to be in everybody's troubleshooting arsenal as some kind of "first responder tool". I'm trying to change this with this blog post listing some examples of how I've been using SAT over the years.
SAT is the "Runtime Analysis" providing tons of information for an executed process like database tables accessed, programs called, routines accessed, time spent on the different activities and a lot more which can make the provided results somewhat daunting to look through. Even the initial screen offers many options of how to run the transaction:
If you are completely new to SAT, please check out the blog posts published by olga.dolinskaja about 10 years ago when this transaction became available as a successor for SE30:
Next Generation ABAP Runtime Analysis (SAT) Introduction
Next Generation ABAP Runtime Analysis (SAT) – How to analyze performance
Next Generation ABAP Runtime Analysis (SAT) – How to analyze memory consumption
Next Generation ABAP Runtime Analysis (SAT) – How to analyze program flow
Given that I'm getting asked to troubleshoot issues across the whole SAP ERP system, I don't know the inner workings of each module in a lot of detail. Some processes I'm fairly familiar with, while I've never had much contact with many others. Especially in the latter case, SAT has proven to be a real timesaver as it helps to for example quickly see which tables are used during a process (in the DB tables tab) and - with some more digging - which of them get for example updated. It's also possible to filter the hit list for occurrences of Z-code like finding typical customer exits in FI or MM by restricting the output to lines where the Statement/Event contains "EXIT_":
Imagine how long it would take to step through a large transaction like MD04 to happen upon those if you didn't know where to start looking? With the help of SAT you can narrow down the proverbial haystack in which to search for the also proverbial needle quite a bit. Double-clicking the statement will take you to the ABAP-code where you can - possibly after taking a look around to see if it's actually interesting - set a breakpoint right away so that the process will stop there when you execute the process again.
Is it a given that something interesting will turn up? No, obviously not, but chances are pretty good that you'll find "something" at least somewhat helpful.
Whenever colleagues ask for help to identify a performance issue, I ask for the steps to re-run the program or transaction and suitable test cases in one of our test systems. A prerequisite is that the process runs comparably long as it does in production to have a chance to jump into SAT while the process is running on the server. I then start the program and identify the server via SM51/SM50 the corresponding process is running on (we have more than one instance and I found that it helps to be on the correct one before jumping into SAT).
As soon as I see "my" process in SM50 I use /nSAT to start the runtime analysis where I then make use of the option to execute SAT in a parallel session:
I get a comparable view to SM50 but restricted to actually running processes where I can then place the cursor on "my" process and click the "activate measurement" icon:
Depending on what the process I'm interested in does, it's often enough to have the measurement active for 10 to 20 seconds or at most 1 or 2 minutes. That should ensure that the output doesn't get too large (if it does: no worries, just try again for a shorter time frame). Switch off the measurement and leave the screen with F3.
The measurement output will be created which can take a moment or two but will eventually finish - hopefully without a pop-up warning about too large an output file! The output for the Hit List will look something like this with lots of stuff to look at after sorting it descending on for example gross percentage:
I then check the high-hitters by double-clicking on the Statement/Event to see the actual ABAP-code executed. Chances are pretty good that one of the first 2 to 3 hits will be the cause for the performance issue, hopefully in some Z-code where we can easily apply a quick fix ourselves. With this method I managed to quickly find at least two READ TEXT statements in old code earlier this year which were just missing the "BINARY SEARCH" addition. Once added, the program - without any other changes - ran a lot quicker than before and the performance issues were gone (at least for now!). Oh, and in case you are wondering why changing the internal table definition was not an option, the reason in these instances was that the Z-code is part of enhancement/exit logic and the table definition is in SAP-code.
As we have quite a few fairly old and often changed programs, I sometimes want to better understand what a program in need of changes does before actually tackling them. This is where the "no aggregation" option in a variant comes in handy:
You get the same output as with "Per Call Position" but in addition you'll see a big list of which activities were done in the program in which sequence. For this option, it therefore makes sense to narrow down the processed data to as few cases as possible, ideally just one. Otherwise, the output will more likely than not become way too big and unwieldy. Once the results are displayed, I go to tab "Call Hierarchy" and add the "Program called" to the displayed output via the "Additional Information" icon (where you can only pick one of the many offerings).
Many of the lines will not be of interest to learn anything about the Z-program I'm interested in, so I also set a filter on "Program Called" and restrict that to e.g. anything starting with "Z*". This gives me a much more to the point output where it's then easier to see where a routine gets entered (e.g. lines 164 and 178 where the statement starts with ">...") and left (e.g. line 177 where the statement starts with "<..."):
Just like in the hit list mentioned above, double-clicking any of these lines jumps to the relevant ABAP code in order to take a closer look and/or set a breakpoint for later debugging.
So, that's some of the cases where I'm using SAT and where I've found it to be a big time saver more often than not. How about you? Are you regularly using SAT, perhaps in more creative ways than I do? I'm eager to pick up some more tricks of the trade to make good use of this very versatile transaction!
Cheers
Bärbel
What is SAT?
SAT is the "Runtime Analysis" providing tons of information for an executed process like database tables accessed, programs called, routines accessed, time spent on the different activities and a lot more which can make the provided results somewhat daunting to look through. Even the initial screen offers many options of how to run the transaction:
If you are completely new to SAT, please check out the blog posts published by olga.dolinskaja about 10 years ago when this transaction became available as a successor for SE30:
Next Generation ABAP Runtime Analysis (SAT) Introduction
Next Generation ABAP Runtime Analysis (SAT) – How to analyze performance
Next Generation ABAP Runtime Analysis (SAT) – How to analyze memory consumption
Next Generation ABAP Runtime Analysis (SAT) – How to analyze program flow
My use cases
Is any Z-code executed within SAP-programs?
Given that I'm getting asked to troubleshoot issues across the whole SAP ERP system, I don't know the inner workings of each module in a lot of detail. Some processes I'm fairly familiar with, while I've never had much contact with many others. Especially in the latter case, SAT has proven to be a real timesaver as it helps to for example quickly see which tables are used during a process (in the DB tables tab) and - with some more digging - which of them get for example updated. It's also possible to filter the hit list for occurrences of Z-code like finding typical customer exits in FI or MM by restricting the output to lines where the Statement/Event contains "EXIT_":
Imagine how long it would take to step through a large transaction like MD04 to happen upon those if you didn't know where to start looking? With the help of SAT you can narrow down the proverbial haystack in which to search for the also proverbial needle quite a bit. Double-clicking the statement will take you to the ABAP-code where you can - possibly after taking a look around to see if it's actually interesting - set a breakpoint right away so that the process will stop there when you execute the process again.
Is it a given that something interesting will turn up? No, obviously not, but chances are pretty good that you'll find "something" at least somewhat helpful.
Pinpointing performance issues
Whenever colleagues ask for help to identify a performance issue, I ask for the steps to re-run the program or transaction and suitable test cases in one of our test systems. A prerequisite is that the process runs comparably long as it does in production to have a chance to jump into SAT while the process is running on the server. I then start the program and identify the server via SM51/SM50 the corresponding process is running on (we have more than one instance and I found that it helps to be on the correct one before jumping into SAT).
As soon as I see "my" process in SM50 I use /nSAT to start the runtime analysis where I then make use of the option to execute SAT in a parallel session:
I get a comparable view to SM50 but restricted to actually running processes where I can then place the cursor on "my" process and click the "activate measurement" icon:
Depending on what the process I'm interested in does, it's often enough to have the measurement active for 10 to 20 seconds or at most 1 or 2 minutes. That should ensure that the output doesn't get too large (if it does: no worries, just try again for a shorter time frame). Switch off the measurement and leave the screen with F3.
The measurement output will be created which can take a moment or two but will eventually finish - hopefully without a pop-up warning about too large an output file! The output for the Hit List will look something like this with lots of stuff to look at after sorting it descending on for example gross percentage:
I then check the high-hitters by double-clicking on the Statement/Event to see the actual ABAP-code executed. Chances are pretty good that one of the first 2 to 3 hits will be the cause for the performance issue, hopefully in some Z-code where we can easily apply a quick fix ourselves. With this method I managed to quickly find at least two READ TEXT statements in old code earlier this year which were just missing the "BINARY SEARCH" addition. Once added, the program - without any other changes - ran a lot quicker than before and the performance issues were gone (at least for now!). Oh, and in case you are wondering why changing the internal table definition was not an option, the reason in these instances was that the Z-code is part of enhancement/exit logic and the table definition is in SAP-code.
Disentangling a program's process flow
As we have quite a few fairly old and often changed programs, I sometimes want to better understand what a program in need of changes does before actually tackling them. This is where the "no aggregation" option in a variant comes in handy:
You get the same output as with "Per Call Position" but in addition you'll see a big list of which activities were done in the program in which sequence. For this option, it therefore makes sense to narrow down the processed data to as few cases as possible, ideally just one. Otherwise, the output will more likely than not become way too big and unwieldy. Once the results are displayed, I go to tab "Call Hierarchy" and add the "Program called" to the displayed output via the "Additional Information" icon (where you can only pick one of the many offerings).
Many of the lines will not be of interest to learn anything about the Z-program I'm interested in, so I also set a filter on "Program Called" and restrict that to e.g. anything starting with "Z*". This gives me a much more to the point output where it's then easier to see where a routine gets entered (e.g. lines 164 and 178 where the statement starts with ">...") and left (e.g. line 177 where the statement starts with "<..."):
Just like in the hit list mentioned above, double-clicking any of these lines jumps to the relevant ABAP code in order to take a closer look and/or set a breakpoint for later debugging.
So, that's some of the cases where I'm using SAT and where I've found it to be a big time saver more often than not. How about you? Are you regularly using SAT, perhaps in more creative ways than I do? I'm eager to pick up some more tricks of the trade to make good use of this very versatile transaction!
Cheers
Bärbel
- SAP Managed Tags:
3 Comments
| User | Count |
|---|---|
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
