Should I see entries in the SAT hitlist for steps during update process?

[BaerbelWinkler]

Hi All!

I'm trying to analyze the rescheduling process (tcode V_V2) via SAT because I'd like to find out how bad (or not) a specific SELECT-statement is compared to the many others executed. The statement was flagged by a detailed performance analysis run on some of our processes known for performance issues. My idea is to use SAT-data to either suggest we change the statement or we leave things as they are dependent on how much of a difference in the overall performance it would potentially make.

The change itself wouldn't be all that involved (replacing a SELECT SINGLE * with SELECT SINGLE field-list from VBAK), it's more the testing effort this will entail due to the importance of the affected process.

The SELECT happens in some custom code triggered via NAST-logic when orders are saved during rescheduling. From watching the job's executing in SM50 I'm fairly certain that the routine gets called during the process:

However, when I execute V_V2 via SAT I never see the form routine GET_AND_PROCESS in the hit list.

Poking around SAT, I found the radiobutton under OPTIONS to Measure RFC and Update Calls. But this didn't seem to make any difference either. Sometimes, the result became too big, so it's possible that the interesting part simply ended up on the "cutting room floor", but I've now run it several times for different subsets of the available data (a couple of thousand MATNRs each) and it's weird that I never see an entry for this particular routine (or for RSM13000).

Should it be included in the hitlist or am I not getting it because updates are getting executed asychronously and potentially in another work process than the one SAT is "watching"? Is there a way to capture it at all?

We are on NW 750 EHP 8 SP19

Thanks much and cheers

Bärbel

[BaerbelWinkler]

Here is a quick update. To make sure the routine gets accessed at all, I activated SCMON in our QA system and ran V_V2 for a subset of material numbers. Checking SCMON afterwards, I did find entries showing that the routine GET_AND_PROCESS was indeed accessed:

So, my question remains: is there a way to make SAT pick it up to get a grasp on the performance?

[gasparerdelyi]

In order to trace update processing in SAT, you can go for

• either scheduling trace in SAT, then you can specify to trace update requests for the user, or even specify the update module
• or in order to trace the update among the dialog step, you need to set up and use a variant that has "Measure RFC and Update Calls" flag set on the Duration and Type tab. This requires dynamic parameter rstr/accept_remote_trace to be set to TRUE on the instance executing the update. Practically temporary set this value on all instances in RZ11 and do not forget to reset it after your tracing activities.

Let me also mention that taking the ABAP trace together with SQL trace and if needed also changing the parameter (behind the name context trace) is also possible in ST12 (user traces for task type U or * for example, but scheduling also works) as long as ST/A-PI is installed.

[BaerbelWinkler]

gasparerdelyi

Thanks for your reply, Gaspar!

I tried the transactions you suggested but don't have access to update the parameters in our systems. As this is currently more of a "nice instead of need to know" kind of issue, it's doesn't quite rise to having to bother my basis colleagues about it.

I tried the scheduling route with specifying to trace RFCs and updates and even though scheduling worked and generated output, it still didn't include the interesting form routine.

Looks as if the routine is rather elusive and just doesn't want to be watched!

Cheers

Bärbel

[gasparerdelyi]

Hello Bärbel,

Without the parameter change, the flag for tracing updates and RFCs will unfortunately not work, as the instance will reject the tracing request flag that comes with the RFC and update requests.

Do you have transaction ST12? There can be a chance that you might change the parameter from there... there is a button for expanding the parameter value for context tracing, and then the button to change is displayed. This might help depending on the roles and authorizations you have.

However the schedule approach for updates should still work -- the pitfalls there might be:

• an RFC call in between with a destination that changes the user -- with the schedule trace approach you need to know the actual user that executes the update
• schedule must be set for all instances -- update can be picked up by any instance
• no concurrent tracing activity must be there on the instance that executes the update request