Running ABAP Traces in the New Debugger

Recommend This Post!Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

ABAPAnthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 20 years of experience in SAP business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.

Running Traces in the ABAP Debugger

I was recently on a Skype learning session at a client where the topic was “Advanced Debugging Techniques”. The developer delivering the live training was showing examples of using Debugger Scripting. For those that need a refresher on what that is, check out our blog post, Fast, and Easy SAP ABAP Debugger Scripting.

While explaining how to execute a statement trace for an SAP ABAP Program using the delivered script “RSTPDA_SCRIPT_STATEMENT_TRACE”, one of our new ABAP developers asked if there was a way to trace SQL, similar to running ST05. And this Blog post was born…

The Answer is a resounding YES! Not only can you trace SQL, but you can trace buffers, RFC’s, Enqueues, and the Classic SE30 ABAP Trace.

Lets run an example using the ST05 Performace trace. If you need a refresher on what this trace is, and how to interpret it take a look at our blog post ABAP Database SQL Analysis Using The Performance Trace parts one and two. Please note you also require ECC SAP_ABA release 702.

Running ST05 in the ABAP Debugger

First, we need to be debugging something with SQL. So for this blog post I am going to use a liitle program ztony_demo_traces. Here is the code below:

REPORT ztony_demo_traces.

TABLES: vbak.

SELECT *
FROM vbak
INTO vbak.
ENDSELECT.

BREAK-POINT.

SELECT SINGLE *
FROM vbak
INTO vbak
WHERE vbeln = '0000004969'.

BREAK-POINT.

OK, let’s put a BREAK_POINT on the first select and run the program. The debugger should pop up and land you in the Standard Tab.

ABAP Break-Point on Select

Let’s Switch over to the Desktop 1 Tab. and delete any open tools other than the Source Code Tool. Your Desktop should look like this:

Desktop 1 Tab

OK great —  now look way over to the upper right corner. You should see the New Tool Icon New Tool. Click this and you should see the following pop-up.

New Tool

Expand the Special Tools Node and you will see Trace (SE30/ST05) as an option you can double-click and add to your current Desktop 1.

Special Tools

Please double-click. Your Desktop should now look something like this…

Debugger Desktop 1 with Trace Tool

OK, let us stop here for a minute. On the right-hand side is the “New” tool we just added. You can see we have many other traces we can use besides the ST05 Trace. We have the Classic ABAP Trace (SE30), we have a Buffer Trace, an RFC Trace, and even an Enqueue Trace for locking issues. We will use the ST05 Trace in this post.

Turning the ST05 Trace on While Debugging

We turn the trace on or off by using the Activate Icon ABAP Trace Activate. OK, please double-click and activate the ST05 performance Trace. Then go ahead and execute the OPEN SQL to SELECT VBAK. Please make note that this SELECT DOES NOT HAVE A WHERE CLAUSE! This was done purposefully as to force the Optimizer to select an execution path of a FULL TABLESPACE SCAN. OK, when the SELECT VBAK is finished and hits our Hard BREAK-POINT, double-click to deactivate the trace and your Desktop should look like this:

Debugger Desktop 1 Tab with Trace Results

Viewing the ST05 Trace Results

You should now see an ST05 Trace Results icon in the column TraceFile of the Trace Management Tool. This is the result of tracing the SELECT VBAK. Please double-click this icon and you will immediately recognize the ST05 Tool and its screens. We want to use the EXPLAIN capability of ST05 to see the EXECUTION PATH chosen by the Optimizer. So, position your cursor on the OPEN line of the log and hit the EXPLAIN button at the top on the Application ToolBar.

ST05 Performance Trace

You will see the results of the EXPLAIN, and most importantly you will see the Optimizer has chosen an Execution path of TABLE ACCESS FULL, which is a complete scan of the table. very inefficient, and something we as developers should never do.

ST05 Explain

We still have one more SELECT VBAK OPEN SQL Statement we could trace. This shoud be very efficnet as we are using the primary key in a WHERE Clause. I’ll skip most of the steps, but when you view the EXPLAIN, it should look like this:

ST05 Explain using an INDEX

A couple of points — first you can see we are using the INDEX VBAK~0. because we are using this index, we can do a UNIQUE scan based on the VBELN we passed in the WHERE clause. Also note, the cost has significantly decreased from 424 to 2, and this was for only around 5K of rows.

Summary

You already know how easy it is to customize your debugger desktops by adding (or removing) any of the Tools, and how easy it is to arrange them on the desktops from viewing our Debugger Post The New ABAP Debugger – Part 2 . Well, now you can add the Trace Tool to your debugging arsenal!

ITP logo

If you enjoyed this blog, Running ABAP Traces in the New Debugger, please fill out the form below to sign up for our newsletter. We deliver SAP Technical tips & tricks, SAP news, and the current month’s BLOG right to your inbox!

Recommend This Post!Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

Related Posts

Pin It on Pinterest

Share This

If you enjoyed this post, why not share it with your friends!