The list of the longest calls shows the application calls that took the longest, one by one, with the moment each one started and its line in the trace.
What the section shows
The Longest depth-0 calls section (in the index, Longest calls) lists the longest level-0 calls, the ones the application made, from longest to shortest. Recursive SQL calls are left out: their time is already in the level-0 call that triggered them. With no level-0 call, the section shows No depth-0 calls.
Calls of the same shape, from statements that differ only in literals, become a single row, that of the longest call, with the N variants badge before the statement text. This way, a shape with many similar calls does not take up the whole list. The other calls of the shape do not appear here; the time of all of them is in the shape's row in SQL statements (variants in the lists).
How to read it
| Column | What it says |
|---|---|
| Call | The type: PARSE, EXEC, FETCH and the others. |
| Duration (s) | The duration of the call (e=). |
| CPU (s) | The CPU of the call (c=), including that of the recursive SQL it triggered. |
| Start (+s) | How many seconds after the start of the trace the call began. |
| Line | The line of the call in the trace file. Open the file you uploaded at that line to see the waits that came before it. In a collection, it is the line of the assembled trace, not that of the original file. |
| LIO | The logical reads of the call (cr= plus cu=). |
| PIO | The blocks read from disk (p=). |
| Rows | The rows of the call (r=). |
| Statement | The number and the beginning of the statement text, with a link to the detail. For a shape, the text shows :s and :n in place of the literals, and the N variants badge comes before it. |
A duration well above the CPU means the call spent the rest of the time waiting, or in time the trace does not explain. The statement profile tells which of the two.
In the sample report, the longest call is the FETCH on line 31 of the trace, with a duration of 0.001600 s and 0.000200 s of CPU, 10 logical reads and 1 block read from disk.
When it is a concern
- One or a few calls concentrate the time: the problem is in their statement. Go to the detail and to the plan.
- Many long calls from the same statement: the statement is always slow, not by chance.
- Duration far above CPU plus waits: unaccounted-for time within the call, which is usually CPU queueing on the server (unaccounted-for time within calls).
- Large intervals between the Start (+s) of consecutive calls, with no wait to explain them: the trace has gaps (gaps between calls).
When there are slow level-0 calls, the Diagnosis shows the slow calls info finding, with how many there were and the View longest calls link.
Where to go next
- Longest calls in the sample report.
- Latency distribution, to see whether the long calls are the exception or the rule.
- Statement detail of the call.