(For more resources related to this topic, see here.)
Using transaction SAT to find problem areas
In this recipe, we will see the steps required to analyze the execution of any report, transaction, or function module using the transaction SAT.
Getting ready
For this recipe, we will analyze the runtime of a standard program RIBELF00 (Display Document Flow Program). The program selection screen contains a number of fields. We will execute the program on the order number (aufnr) and see the behavior.
How to do it…
For carrying out runtime analysis using transaction SAT, proceed as follows:
-
Call transaction SAT. The screen appears as shown:
-
Enter a suitable name for the variant (in our case, YPERF_VARIANT) and click the Create
button below it. This will take you to the Variant creation screen.
-
On the Duration and Type tab, switch on Aggregation by choosing the Per Call Position radio-button.
-
Then, click on the Statements tab. On the Statements tab, make sure Internal Tables, the Read Operations checkbox and the Change Operations checkbox, and the Open SQL checkbox under Database Access are checked.
-
Save your variant. Come back to the main screen of SAT.
-
Make sure that within Data Formatting on the initial screen of SAT, the checkbox for Determine Names of Internal Tables is selected.
-
Next, enter the name of the program that is to be traced in the field provided (in our case, it is RIBELF00). Then click the
button. -
The screen of the program appears as shown. We will enter an order number range and execute the program.
-
Once the program output is generated, click on the Back key to come back to program selection screen.
-
Click on the Back key once again to generate the evaluation results.
How it works…
We carried out the execution of the program through the transaction SAT and the evaluation results were generated. On the left are the Trace Results (in tree form) listing the statements/ events with the most runtime. These are like a summary report of the entire measurement of the program. They are listed in descending order of the Net time in microseconds and the percentage of the total time. For example, in our case, the OPEN CURSOR event takes 68 percent of the total runtime of the program.
Selecting the Hit List tab will show the top time consumer components of the program. In this example, the access of database tables AFRU and VBAK takes most of the time.
Double-clicking any item in the Trace Results window on the left-hand side will display (in the Hit List area on the right-hand pane) details of contained items along with execution time of each item. From the Hit List window, double-clicking a particular item will take us to the relevant line in the program code. For example, when we double-click the Open Cursor VBAK line, it will take us to the corresponding program code.
We have carried out analysis with Aggregation switched on. The switching on of Aggregation shows one single entry for a multiple calls of a particular line of code. Because of this, the results are less detailed and easier to read, since the hit list and the call hierarchy in the results are much more simplified.
Also within the results, by default, the names of the internal table used are not shown. In order for the internal table names to appear in the evaluation result, the Determine Names checkbox of Internal tables indicator is checked.
As a general recommendation, the runtime analysis should be carried out several times for best results. The reason being that the DB-measurement time could be dependent on a variety of factors, such as system load, network performance, and so on.
Creation of secondary indexes in database tables
Very often, the cause of a long running report is full-scan of a database table specified within the code, mainly because no suitable index exists. In this recipe, we will see the steps required in creating a new secondary index in database table for performance improvement. Creating indexes lets you optimize standard reports as well as your own reports. In this recipe, we will create a secondary index on a test table ZST9_VBAK (that is simply a copy of VBAK).
How to do it…
For creating a secondary index, proceed as follows:
-
Call transaction SE11. Enter the name of the table in the field provided, in our case, ZST9_VBAK. Then click the Display button. This will take you to the Display Table screen.
-
Next, choose the menu path Goto | Indexes. This will display all indexes that currently exist for the table.
-
Click the Create button
and then choose the option Create Extension Index
-
The dialog box appears. Enter a three-digit name for the index. Then, press Enter.
-
This will take you to the extension index maintenance screen. On the top part, enter the short description in the Short Description field provided.
-
We will create a non-unique index so the Non-unique index radio button is selected (on the middle part of the screen).
-
On the lower part of the screen, specify the field names to be used in the index. In our case, we use MANDT and AUFNR .
-
Then, activate your index using keys Ctrl + F3. The index will be created in the database with appropriate message of creation shown below Status.
How it works…
This will create the index on the database. Since we created an extension index, the index will not be overwritten by SAP during an upgrade. Now any report that accesses ZST9_VBAK table specifying MANDT and AUFNR in the WHERE clause, will take advantage of index scan using our new secondary index.
There’s more…
It is recommended by SAP that the index be first created in development system and then transport to quality, and to the production system. Secondary indexes are not automatically generated on target systems after being transported. We should check the status on the Activation Log in the target systems, and use the Database Utility to manually activate the index in question.
A secondary index, preferably, must have fields that are not common (or as much as uncommon as possible) with other indexes. Too many redundant secondary indexes (that is, too many common fields across several indexes) on a table has a negative impact on performance. For instance, a table with 10 secondary indexes is sharing more than three fields. In addition, tables that are rarely modified (and very often read) are the ideal candidates for secondary indexes.