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:

  1. Call transaction SAT. The screen appears as shown:
    How to do it...
  2. Enter a suitable name for the variant (in our case, YPERF_VARIANT) and click the CreateHow to do it... button below it. This will take you to the Variant creation screen.
    How to do it...
  3. On the Duration and Type tab, switch on Aggregation by choosing the Per Call Position radio-button.
  4. 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.
    How to do it...
  5. Save your variant. Come back to the main screen of SAT.
  6. Make sure that within Data Formatting on the initial screen of SAT, the checkbox for Determine Names of Internal Tables is selected.
  7. 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 How to do it... button.
  8. The screen of the program appears as shown. We will enter an order number range and execute the program.
  9. Once the program output is generated, click on the Back key to come back to program selection screen.
  10. 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.

How it works...

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.

How it works...

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.

How it works...

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.139.103.204