2017-02-22
Page 1/9
755977 - ST12 "ABAP Trace for SAP EarlyWatch/GoingLive" Version
6
Type
SAP Note
Language
English
Master Language
English
Priority
Recommendations / Additional Info
Category
Special development
Release Status
Released for Customer
Released On
02/28/2006
Component
SV-SMG-SDD (S (Service Da Data Do Download)
Please find the original document at https://launchpad.support.sap.com/#/notes/755977
Symptom Documentation for transaction ST12
Other Terms ST12 "Single transaction analysis" for SAP EarlyWatch/GoingLive, EarlyWatch/GoingLive, Addon ST-A/PI, ABAP trace, context trace
Reason and Prerequisites Transaction ST12 "Single transaction analysis" for SAP EarlyWatch/GoingLive Note that the ST12 ABAP trace transaction is not officially documented documented and only available in English language. It is mainly intended for use by SAP or certified Service consultants during SAP Service Sessions (for example SAP GoingLive Check or Solution Management Optimization Services).
Solution Contents
I. Introduction II. Basics of ABAP trace (for beginners) III. ST12 in comparison to SE30 (delta course) IV. How to use ST12 V. Trouble-shooting Trouble-shooting
I. Introduction 1. Motivation ST12 was developed to promote the usage of ABAP trace, to integrate ABAP and performance traces (SQL Enqueue RFC, transaction ST05) and to make the tracing and analysis process faster and more convenient. ABAP trace with ST12 is the central entry point for performance analysis. It should be used to detect top-down any performance hotspot, for functional time distribution analysis, and to optimize ABAP/CPU bound issues. SQL trace should be used for DB bound issues. ST12 is similar to a combination of the standard ABAP and SQL trace transactions SE30 and ST05. 2. Overview ST12 combines ABAP and performance (SQL) trace into one transaction, with major functional enhancements enhancements especially for the ABAP trace part. In a joint switch
© 2017 SAP SE or an SAP affiliate company. All rights reserved
2017-02-22
Page 2/9
on/off with the performance trace, ST12 allows to activate the ABAP trace for another user. Like this an SAP Service Engineer can trace a dialog transaction that is executed by a business user of the customer and does not need own sample data. ABAP and performance traces can be activated on another server or even on all servers to catch e.g. incoming RFCs. ST12 makes it easy to keep valuable trace results and pass them on e.g. to SAP backoffice. The ABAP trace results are completely collected to database. For Performance trace ST12 remembers timeframe&server, and one click navigates directly into the ST05 trace display on the proper server. Selected results form performance trace and other findings can be saved as annotation texts into a trace analysis. The ST12 ABAP Trace Summary quickly shows the contribution of known expensive functionalities. It is also able to estimate the time contribution of certain programs, esp. user exits and customer coding. With ST12 the program hierarchies can be analyzed in the aggregated ABAP trace 'per call'. Therefore the non-aggregated ABAP trace with its large trace file sizes is not needed and was omitted from ST12. ST12 allows to switch on/off and display ABAP traces like SE30 but without the non-aggregated ABAP trace with new possibilities to activate the trace for a username & task type on all servers to catch e.g. an incoming RFC trace BSP pages or many incoming RFCs with new evaluation possibilities for the aggregated trace top-down call tree buttom-up call hierarchy last changed by & on short texts for functional analysis traces are stored centrally and permanently to DB with better support for 'Context trace' accross RFCs 3. Availibility Transaction ST12 is available as of basis release 4.6B. It is delivered via the addon ST-A/PI (Application servicetools for EarlyWatch/GoingLive, see note 69455). The ST-A/PI version should be 01F* or higher. The feature to switch on the ABAP trace for another user requires -> on basis 4.6*: Addon ST-A/PI >= 01F*, Kernel 46D patchlevel >= 1805 -> on basis 6.x: Addon ST-A/PI >= 01G*, Kernel 640 patchlevel >= 83 -> on basis 7.0 or higher: Addon ST-A/PI 01G* 4. Outlook: "Single transaction analysis" It is planned for the future to include SQL/performance trace handling, statistical records and the SQLR transaction functionality into ST12.
II. Basics of ABAP trace (for beginners) 1. General ABAP traces measures two different things. The first are certain simple and possibly expensive ABAP statements like database accesses and statements on
© 2017 SAP SE or an SAP affiliate company. All rights reserved
2017-02-22
Page 3/9
internal tables. These are easy to understand. The second are calls to modularization units like perform, call function/method, call screen or PAI PBO modules. These are complex because they are hierarchical containers and resemble nested russian puppets. Their hierarchies can branch and also merge again. 2. Gross time vs. Net time For modularization unit calls, there exists a difference between gross and net time. Gross time is the summarized time over all call executions. Net time is the gross time minus the time when this mod.unit calls other mod.units minus the durations of simple statements that occur within this modularization unit AND that are explicitely measured. The addition 'explicitely measured' implies that net time can depend on the measurement scope. E.g. with trace scope 'with internal tables' the net times of mod.units can be lower because durations of statements on internal tables are also deducted. Like this the total sum of net time percentages always remains 100%. Gross times are used to get a top-down overview. Mod.unit names often give a good indication what happens below them, so that their gross time can be attributed to a certain functionality. Sorting by net times shows single expensive statements or mod.units that themselves consume much execution time. 3. Aggregation levels The non-aggregated ABAP trace, which is not offered in ST12, would contain one line per statement/call execution. 'Per calling position' is the default in ST12. It aggregates the trace per sourcecode position of a statement or mod.unit call. A coding line 150 PERFORM A. line 151 DO 100 TIMES. line 152 PERFORM A. line 153 ENDDO. would lead to two 'PERFORM A' lines in the trace with 1 and 100 executions and aggregated execution time. This aggregation still allows to analyze hierarchy relations. 'Full' aggregation is per statement and program. It is comparable to the statement summary for the SQL trace in transaction ST05. For the aggregation 'Per modularization unit' see next chapter. 4. ABAP trace options The flag 'with internal tables' extends the trace scope to statements on internal tables like read table, loop at or sort. The flag 'Particular units' can be set in the 'Current mode' scenario in order to trace only one dialog step of a transaction. When the transaction is started from ST12, the ABAP trace does not yet start. It is activated before and deactivated after the dialog step using 'System->Utilities->Runtime analysis-> Switch on/off'. The 'Filter for program part' restricts the ABAP trace to the processing inside and below one specific modularization unit. 5. Comparison to the SQL trace with transaction ST05 SQL trace is written without aggregation. ST05 traces every action of a user on a server, ABAP trace only one user context or transaction. SQL trace needs to be switched off, ABAP trace ends with the traced transaction. ST05 writes trace files into the local filesystem and overwrites them circularily, ST12 stores its analyses centrally and permanently to database. SQL trace gives a buttom-up glimpse what the transaction is doing and is suitable for DB bound performance issues, ABAP trace provides a top-down overview and can detect any performance hotspot. For the issues detected with SQL trace often an easy technical tuning is possible, whereas ABAP issues often involve customer messages and coding changes.
© 2017 SAP SE or an SAP affiliate company. All rights reserved
2017-02-22
Page 4/9
III. ST12 in comparison to SE30 (delta course) 1. Simplifications in ABAP trace options The non-aggregated ABAP trace is not offered in ST12. One reason is that for most business transactions it grows too large, another that the new hierarchy analysis features in ST12 make it largely superfluous. The start options are much simpler than in SE30. Per default one has aggregation 'per calling position' and a trace scope like in the DEFAULT variant in SE30, i.e. tracing modularization units and DB operations. For the flags 'With internal tables' and 'Particular units' see chapter above. Restriction to one modularization unit is possible. Some more rarely used options are available as a popup. 2. Trace start possibilities Three scenarios are offered: The 'User' scenario allows to activate the ABAP trace for the next action under a certain user name and tasktype (DIA BTC RFC UPD) on any application server or systemwide. In slight difference to the SQL trace it does not trace everything under the username, but the trace is switched on for only one user context that does the next roll-in and that has the proper user &tasktype. The trace then lasts until this user context/transaction is finished. Choose '< All Servers >' in the server field in order to trace the next such action systemwide. The trace request is then distributed to all servers. On each refresh, ST12 checks whether a trace has started to run on any server. If yes, then '< All Servers >' is replaced by the explicit server name and trace requests on other servers are cleared. This enables e.g. to catch an incoming RFC or a batch job that starts on any server. Prerequisite for the whole 'User' scenario is a kernel patch. See 'Availibility' above. The 'Tasks&HTTP' scenario is available as of SAP basis 6.10. It alloes to specify a max. number of ABAP trace activations=ABAP trace files, and is therfore suitable to trace many incoming RFCs or BSP pages, where every screen element makes an own call to the R/3 system. 'Workprocess', like 'Parallel mode' of SE30, is used to trace parts of longrunning processing, esp. batch jobs, from an SM50 like process list. In the 'Current mode' scenario the transaction to be analyzed has to be started from ST12, so sample data are required like in SE30. 3. Trace collection and administration of saved traces ST12 'collects' the ABAP trace from the local filesystem and stores it to database as a 'trace analysis'. This makes the trace centrally and permanently available, which is a great advantage when passing on the trace to other levels for further analysis. In the 'User' or 'Workprocess' scenario the asynchronous trace collection is triggered by pressing the 'End & collect trace' button. Convenient search features are included. 4. Evaluation Evaluate -> ABAP Trace shows the aggregated hitlist. New features in comparison to SE30 are: a) Toggle between three aggregation levels The entry display shows the trace 'Per calling position'. Using the first two buttons or the menu, one can switch to other aggregations. The second level is 'Full'. The new aggregation 'Per modularization unit' is a kind of mixture of both. On an upper level it shows only one line for every modularization unit. When such a line is expanded, the statements and calls inside this mod.unit are shown in
© 2017 SAP SE or an SAP affiliate company. All rights reserved
2017-02-22
Page 5/9
aggregation 'per calling position'. Statements and calls outside of mod.units are grouped below dummy lines '
[outside of mod.units]'. The net times of simple statements are added to the net time of their upper level mod.unit. This aggregation is suitable to detect localized issues in single mod.units. b) Top down call tree and Buttom-up call hierarchy Use the aggregation 'Per calling position' to analyze call hierarchy relations: -> 'Buttom-up call hierarchy' works like a multi-level where-used search. The hierarchy above an entry is displayed in form of a swimming lane diagram. The empty diamond symbols show where a call is issued, the filled up/down triangles where it arrives. The small arrows between them are pure cosmetics, illustrating the call direction. The exact meaning is: "Out of modularization unit a call to modularization unit is issued.'. ->'Top down time split hierarchy' shows the ~30 most important below an entry in a swimming lane diagram. Importance is measured in terms of how much aggregated time flow they receive from the original entry. The subordinate modularization units are grouped into distinct branches, it is shown how they are linked to the original entry and where the time flow splits up (several emtpy diamonds in the line). This is very helpful for time distribution and for time-lost analysis. -> For the ' Top down call tree', put the cursor on a modularization unit call (perform or call method/function/screen) and press the tree button. The hierarchy below is then displayed in a new column. All calls to this mod.unit are labeled '0', including the one where you put your cursor. '1' are statements inside this mod.unit, '2' the statements in mod.units one level below, and then iteratively down up to 30 levels. Letters are used to designate lower levels. In both cases the trace lines in the hierarchy are marked with color. The 'Only call tree/call hierarchy filter' button sets an ALV list filter so that only trace entries in the hierarchy are displayed. 'Off' buttons make the hierarchy columns disappear. Remarks: The hierarchy only considers calls to forms, methods, functions and call screen to PBO PAI modules. It does not go across submits or ABAP events. The second restriction reflects that technically only the hierarchy relations one level up/down are known for sure. An example to illustrate: Assume an ABAP program has form routines A1 and A2 that both call a form B with a different input parameter. When called by A1, B calls a form C1. When called by A2, B calls a form C2. Now when you put the cursor on 'Perform A1', the top-down call tree will contain not only B and C1 but also C2, which is called by B but in reality not when B was called by A1. Likewise when you put the cursor on a 'Perform C1', a button-up call hierarchy will contain forms B and A1 but also A2. It can also happen that although form B is called by form A1, B still appears higher in the list sorted by gross time because B is also called by A2. c) last changed by & on 'Show/hide->Last changed by' retrieves 'Last changed by' usernames and change dates from the ABAP respository. For simple statements it displays the change info of the surrounding sourcecode include. For mod.unit calls the info relates to the target include that contains the called mod.unit. This makes it easy to detect any user exit or customer modification. Even customer claims that something would go slower since a certain date can be verified here. d) short texts for functional analysis 'Show/hide->Short texts' from the menu retrieves titles of functions, methods, function groups, reports, classes, dynpros or tables from the ABAP repository and displays them. Together with the techical names of forms functions etc. they provide the basis for a functional time distribution analysis. If English titles are not available, German or others are displayed. e) internal table names resolved, select statements compressed Internal table names are shown as in the sourcecode. Open+Fetch+Close are aggregated to one line 'Select' etc. f) Other features The header area in the evaluation screen can be collapsed. The 'Show/hide' menu
© 2017 SAP SE or an SAP affiliate company. All rights reserved
2017-02-22
Page 6/9
allows to display the 2nd part of long call texts or the calling program and provides a convenient way to organize the columns. A 'Top500 calls filter' provides a faster trace display. Sourcecode display and the usual ALV features like sorting, filtering and sums are available like in SE30. 5. 'Context trace' across RFCs and remote trace collection ABAP trace can be inherited via RFC, so that remote activities also get traced. As precondition, both origin and remote system need to have a basis release as of 6.10. The parameter rstr/accept_remote_trace has to be set to 'true' in the remote system. On basis releases 6.10 and 6.20 this parameter has to be changed in the profile maintenance RZ10, and the application server needs to be restarted to make it effective. From basis 6.40 it can be switched dynamically to 'true' using transaction RZ11. Note that it should not be set to 'true' permanently, since this might cause unwanted trace inheritance e.g. by certain external interfaces. Especially the permanent change in RZ10 should be changed back to 'false' after tracing is finished. Start the trace from ST12 with the flag 'Context trace' on. When the original transaction makes RFCs, these RFCs then write own ABAP tracefiles into their server filesystems. To collect them, press 'Collect external traces' in the first line of ST12. Enter an RFC destination to the remote system. Enter a timeframe, or clear it to find all files. Then press 'Start' to search for suitable tracefiles on all servers of the remote system. Select the proper file and press 'Collect'. The tracefile is then fetched remotely and stored as a new trace analysis. 6. ABAP trace summary It is planned to provide a summary for the ABAP trace as the SQLR does for the SQL trace, showing the percentages of logistics functions like pricing or availability check with the same function texts as in SQLR.
IV. When and how to use ST12 ABAP trace
Transaction optimization in EarlyWatch/GoingLive used to rely heavily on the SQL trace. ABAP trace was recommended only to analyze gaps in the SQL trace or pure CPU issues. This is no longer valid already since SAP release 4.6B. Especially for for detection and analysis of performance issues, ABAP trace is far more suitable than SQL trace or SQLR. ABAP trace with ST12 can and should be used to identify top-down any performance hotspot and get an exact functional time distribution find customer modifications and user exits detect issues in the call hierarchy search for localized technical tuning potential, e.g. CPU-expensive ABAP statements 1. Top-down gross time analysis Sort by gross time. Concentrate on modularization units that take long enough to be worth for optimization (min. 5 % gross time) but are small enough to correspond to just one specific functionality. Use the top-down time split hierarchy or buttom-up call hierarchy buttons to find out which of these interesting entries are hierarchically related, in order to group them into distinct functional branches. Then look at the form/method/function names and use 'Show/hide->Short texts' to get an idea what these distinct functional branches are doing. E.g. in sales order entry VA01 everything below function PRICING is pricing, function AVAILIBILITY_CHECK does the ATP check, function RV_TEXT_COPY is text
© 2017 SAP SE or an SAP affiliate company. All rights reserved
2017-02-22
Page 7/9
detemination etc. Their gross percentages give you exactly the functional time distribution. Now ask yourself whether one of them looks too expensive or strange. 50% gross time for function PRICING ? 95% for a form DYNAMIC_CREDIT_CHECK ? 91% for the DDIC function module DDIF_TABL GET in a PS transaction ? Those are optimization candidates. On the other hand if time is well split over only the expected functions and nothing pops out, then there is no optimization potential. 2. Userexit and modification check 'Show/Hide->Last changed by' shows the change info for the (target) sourcecode include. Look for 'Last changed by user' <> 'SAP' and gross time > 5%. If you find an entry, jump into the coding and make sure that the customer changes are in the relevant parts of the code. Also verify that it was not a manual implementation of a SAP note. Userexits and custom code are responsible for their whole gross time. Optimization is usually done by the customer. 3. Net times analysis Sort by net time to search for localized technical tuning potential. The aggregation 'per modularization unit' can show forms/functions/methods that consume a long net time. A trace with scope 'with internal tables' can reveal single expensive ABAP statements like e.g. a slow 'read table' statement on a large internal table without 'binary search'. The recommendation would be to keep the table sorted and add the 'binary search' option. The ABAP trace provides also a convenient aggregated view on accesses to database or buffered tables and on RFCs, except frontend RFCs. 4. Optimization possibilities In case you find high times on standard functionality like function PRICING, perform a functional optimization using ST14 and the GoingLive Optimization session checks. You can search for performance-relevant SAP notes using names of modularization units in the hierarchy of the conspicuous functionalities that you noticed during your top-down gross time analysis. Also consult the functional experts. If they also judge it strange that so much time is spent on such a functionality, open a customer message. E.g. in the case with 95% for DYNAMIC_CREDIT_CHECK, this led to a quick reply from SAP development just to take out one flag in customizing. If you have ABAP knowledge, look at the numbers of execution and jump into ABAP at different hierarchy levels. Coding parts that are processed very often should be reviewed. Check e.g. whether it would be better to centralize certain processing steps and do them once on a higher level. Another important strategy is to remember results in a buffer. In ABAP a buffer in the user contaxt is usually implemented using global internal tables in the top include of function groups. They are persistent throughout the user context and can be accessed from all function modules of the group. The logic is: a) Check if buffer filled. b) If yes, return results from buffer. c) If no, select or calculate results and store to buffer. Optimization often involves code changes.
V. Trouble-shooting Symptom: Negative or excessively long times in the ABAP trace ? This can occur on certain operating systems with multiprocessors. Push the 'Further options' button in the ABAP trace options and select 'Low resolution'. Then repeat the trace. Symptom: Too long runtimes for the first few entries ? Sometimes the first entries have incorrect gross/net times, even longer than the total execution time. Often these entries are screen modules (PAI PBO). However the gross times for the other entries below like forms, methods or functions are
© 2017 SAP SE or an SAP affiliate company. All rights reserved
2017-02-22
Page 8/9
usually still correct and reliable. Just ignore these leading entries. Symptom: Tracefile overflow ? Some rare programming techniques can cause additional trace file flushes and thus lead to an overflow even with the aggregated trace. Push the 'Further options' button in the ABAP trace options and increase the ABAP trace file size from 2 to max 50 MB.
Software Components Software Component
Release
SAP_BASIS
46B - 46D
SAP_BASIS
610 - 640
Other Components Component
Description
BC-CCM-MON-TUN
Workload Monitoring Tool
This document refers to SAP Note/KBA
Title
1634757
Guided Self Service 'Performance Optimization'
1597364
FAQ: BW-BCT: Extraction performance in source system
This document is referenced by SAP Note/KBA
Title
1634757
Guided Self Service 'Performance Optimization'
1758890
SAP HANA: Information needed by Product/Development Support
1597364
FAQ: BW-BCT: Extraction performance in source system
© 2017 SAP SE or an SAP affiliate company. All rights reserved
2017-02-22
Page 9/9 Terms of use | Copyright | Trademark | Legal Disclosure | Privacy
© 2017 SAP SE or an SAP affiliate company. All rights reserved