What's the meaning of "DB: Fetch" versus "Fetch" in SAT? (also: Open)

[Sandra_Rossi]

I did an ABAP trace with SAT, and I see different lines for the same ABAP SELECT statement, I can't explain the differences e.g.:

• DB: Fetch FMIT and Fetch FMIT
• DB: Open ZXXXX_OP_HISTO and Open SQL ZXXXX_OP_HISTO

NB: my question is NOT about the difference between "Open" and "Fetch", my question is about why there are two lines for the apparently same operation, or differently said, what's the meaning of "DB" in front of one of the two lines.

Does it simply mean that the request is sent to the database? (tables not buffered or buffer bypassed)

In my case, I don't need this information, it's a little bit polluting the interpretation of the trace. The flag "database-related operations" in the SAT variant is always selected (see below; I'm not sure if this option is about the "DB" lines). Is there a way to remove these "DB" lines? Only by using the ALV filter?

Thank you.

Sandra

My system: ABAP 7.40 SP 23; Kernel 753 PL 1300.

[Ryan-Crosby]

Buffering vs. not would be my only guess here with the difference. Are either of those tables buffered in your case?

[Sandra_Rossi]

No, these two tables are not buffered, and I think that's why we see these "DB" lines. But I guess it can happen to buffered tables if their content is updated, or after the restart of the application server, or after the buffers are manually emptied (/$sync).

[BiberM]

Hi. My guess: this is the differentiation between DB execution and transport back to the ABAP layer.

[RaymondGiuseppi]

For the DB statements, the gross and net time are identical, but not for the single fetch. So I assume that the non-DB statements are relevant to the ABAP statement. Look at the first 2 lines: Abap Gross 30s / Net 10s, followed by DB for 20s / 20s, so basically the fetch statement required 30s, 20s are related to the exchange with the database server and 10s are related to data processing in the application server?

[Sandra_Rossi]

Thank you. Yes, it must be the right explanation. NB: I see that the checkbox "database-related operations" in the SAT variant is always selected also in ABAP 7.58. I guess that the only solution is to use the ALV filter to filter out these DB lines from the ALV of the trace display.

[BiberM]

That depends on your use case. If you are sure that DB execution time is no problem you can filter them out. But if you initially have no clue where the performance bottleneck is you better leave it in. This example also shows that you better restrict the query to what you need as transport back to ABAP layer takes twice as much time as the DB execution. --> Code pushdown

[Sandra_Rossi]

@BiberM I'm okay to trace everything, but first I want to have a global view of what is consuming time, i.e. I want to sort by the net time and I don't want the DB information. But after this quick overview, I agree with what you say.

[HermannGahm · Accepted solution]

Hi Sandra,

if you execute the trace without aggregation you can see the relationship in the call hierarchy:

The DB FETCH Operations are children of the FETCH Operation.
In my case the FETCH Operation took 22249 µs and the DB Fetch Operations 21743 µs (19294 µs + 2449 µs).
I think the difference is different measurement points and code path lengths since 1 FECTH Operation contains multiple DB FETCH Operations.
SAT:

ADT:

Why we can not switch off Database-level operations is a different question that i can't answer at the moment.
I'll check if i can find an answer. (In ST12 you can switch it off 😉 )

Kind regards,

Hermann

[Sandra_Rossi · Accepted solution]

Thanks. Interesting view via Call Hierarchy, it makes it clear what "DB" is (ADT view being much better!).