The call types table adds up the session's calls by type, like the tkprof total: how many there were, how long they took, how much they read and how many rows they returned.
What the section shows
The Call types section has one row for each call type in the trace: PARSE, EXEC, FETCH, CLOSE and, when they appear, UNMAP, SORT UNMAP and LOB calls, such as LOBREAD. Each row adds up all calls of that type, those of the application and those of recursive SQL. Rows are sorted by duration, from longest to shortest.
How to read it
| Column | What it says |
|---|---|
| Call | The call type. |
| Count | How many calls of that type the trace has. |
| CPU (s) | The sum of c=. |
| Duration (s) | The sum of e=. |
| Disk (PIO) | Blocks read from disk (p=). |
| Consistent (CR) | Logical reads in consistent mode (cr=), those of queries. |
| Current (CU) | Logical reads in current mode (cu=), typical of DML. |
| Rows | Rows returned or processed (r=). |
| Misses | Library cache misses (mis=). In PARSE, each miss is a hard parse. |
The duration of a call that triggered recursive SQL already contains that of the child calls, which also count in their own row. With recursive SQL, the sum of Duration (s) counts that time twice and can exceed total time. To split the time without double counting, use the profile.
In the sample report, the FETCH row has 2 calls, one from statement #1 and one from recursive #2, with 2 blocks read from disk, 13 consistent reads and 2 rows. The PARSE row has 1 call with 1 miss: a hard parse.
When it is a concern
- PARSE with Misses close to Count: almost every PARSE is a hard parse. When hard parses weigh on the session, the Diagnosis shows many hard parses, with the View call types link or, if there are statements that differ only in literals, View shareable SQL.
- FETCH with Rows barely above Count: each call returns few rows. The many FETCH calls with few rows finding looks only at level-0 FETCH calls, those of the application; this table also adds those of recursive SQL.
- PARSE with Count close to that of EXEC: the cursor is opened on every execution. The detail of each statement shows which one (one PARSE per execution).
- High FETCH CPU, with Consistent (CR) far above Rows: too many logical reads, usually a plan that reads blocks it does not need.
Where to go next
- Call types in the sample report.
- Latency distribution, with the duration table of each call type, such as FETCH (call duration e).
- Statement detail, with the same columns for a single statement.