query

Former Member · ‎11-21-2007

what is the Sql trace and code inspector

Former Member · ‎11-21-2007

hI

SQL Trace transaction ST05: The trace list has many lines that are not related to the SELECT statement in the ABAP program. This is because the execution of any ABAP program requires additional administrative SQL calls. To restrict the list output, use the filter introducing the trace list.

The trace list contains different SQL statements simultaneously related to the one SELECT statement in the ABAP program. This is because the R/3 Database Interface - a sophisticated component of the R/3 Application Server - maps every Open SQL statement to one or a series of physical database calls and brings it to execution. This mapping, crucial to R/3s performance, depends on the particular call and database system. For example, the SELECT-ENDSELECT loop on a particular database table of the ABAP program would be mapped to a sequence PREPARE-OPEN-FETCH of physical calls in an Oracle environment.

The WHERE clause in the trace list's SQL statement is different from the WHERE clause in the ABAP statement. This is because in an R/3 system, a client is a self-contained unit with separate master records and its own set of table data (in commercial, organizational, and technical terms). With ABAP, every Open SQL statement automatically executes within the correct client environment. For this reason, a condition with the actual client code is added to every WHERE clause if a client field is a component of the searched table.

To see a statement's execution plan, just position the cursor on the PREPARE statement and choose Explain SQL. A detailed explanation of the execution plan depends on the database system in use.

Starting the Trace:

To analyze a trace file, do the following:

...

Choose the menu path Test  Performance Trace in the ABAP Workbench or go to Transaction ST05. The initial screen of the test tool appears. In the lower part of the screen, the status of the Performance Trace is displayed. This provides you with information as to whether any of the Performance Traces are switched on and the users for which they are enabled. It also tells you which user has switched the trace on.

Using the selection buttons provided, set which trace functions you wish to have switched on (SWL trace, enqueue trace, RFC trace, table buffer trace).

If you want to switch on the trace under your user name, choose Trace on. If you want to pass on values for one or several filter criteria, choose Trace with Filter. Typical filter criteria are: the name of the user, transaction name, process name, and program name.

Now run the program to be analyzed.

Stopping the Trace:

To deactivate the trace:

...

Choose Test Performance Trace in the ABAP Workbench. The initial screen of the test tool appears. It contains a status line displaying the traces that are active, the users for whom they are active, and the user who activated them.

Select the trace functions that you want to switch off.

Choose Deactivate Trace. If you started the trace yourself, you can now switch it off immediately. If the performance trace was started by a different user, a confirmation prompt appears before deactivation-

Analyzing a Sample trace data:

PREPARE: Prepares the OPEN statement for use and determines the access method.

OPEN: Opens the cursor and specifies the selection result by filling the selection fields with concrete values.

FETCH: Moves the cursor through the dataset created by the OPEN operation. The array size displayed beside the fetch data means that the system can transfer a maximum package size of 392 records at one time into the buffered area.

Code Inspector (SCI)

You can call the Code Inspector from the ABAP Editor (SE38), the Function Builder (SE37), the Class Builder (SE24), or as a separate transaction (SCI).

The Code Inspector indicates possible problems. However, note that, especially with performance issues: There is no rule without exception. If a program passes an inspection, it does not necessarily mean that this program will have no performance problems.

Former Member · ‎11-21-2007

SQL Trace

Use
The SQL Trace function is an on-demand log of selected SQL statements that are issued against the database through the Open SQL Engine. The SQL Trace can be switched on or off dynamically. The log format is database independent. Besides the SQL statement text, each log record contains information about the point in time when the statement was executed, its duration, its input parameters and results (where applicable) as well as context information.

Features
The SQL Trace is especially useful for:

· Development

SQL Trace can help JDO, enterprise beans, servlet and JSP developers to learn which kind of database accesses their code produces.

· Performance analysis

Typically, performance issues are caused by inefficient database accesses. In this case SQL Trace can be used to show the issued SQL statements and their duration, thus helping to identify inefficient SQL statements.

SQL Trace Analysis

The SQL Trace part of the Performance Trace tool allows you to see how the OPEN SQL statements that you use in ABAP programs are converted to standard SQL statements (see Embedded SQL) and the parameters with which the embedded SQL statements are passed to the database system.

Overview

While the trace is switched on, the SQL Trace function records all database activity by a particular user or group of users. The R/3 System takes OPEN SQL statements and converts them in to embedded SQL statements that it passes to the database. It is the embedded SQL statements, their parameters, return codes, and the number of entries retrieved, inserted, or deleted that are recorded in the SQL Trace file. The log file also contains the runtime of the statement and the place in the application program from which it was called.

The SQL trace tells you:

The SQL statements executed by your program.
The values that the system uses for particular database access and changes.
How the system converts ABAP Open SQL statements (such as SELECT) into Standard SQL statements.
Where your application executes COMMITs.
Where your application repeats the same database access.
The database accesses and changes that occur in the update part of your application.

Code Inspector

The Code Inspector is a tool for checking Repository objects regarding performance, security, syntax, and adherence to name conventions.

also check the below document.

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/695918cd-0d01-0010-2091-d7862084...

Regards,

Maha