Time gaps between calls

Gaps between calls are time that no line of the trace covers. Most of the time, the fault is in the measurement: a trace without waits, turned on in the middle of the operation or with a file missing.

Symptoms

In the Diagnosis, the finding Time gaps between calls (NAO_CONTABILIZADO_ENTRE) appears. The text says that there is time between level-0 calls with no recorded wait, suggests a trace turned on and off in the middle of the session or a process stalled outside the database, and ends with View in profile.

The finding appears when the unaccounted-for time between calls component takes up a large part of the total time. The severity is always medium. When it also holds most of the time, the finding unaccounted-for time between calls dominates response time appears along with it (dominant component).

Cause

R runs from the start of the first call or wait to the end of the last one. Between one level-0 call and the next, the trace usually records the SQL*Net message from client wait. This component is the part of R that is neither in a level-0 call nor in a wait between them. It grows when:

• The trace has no waits. At 10046 levels 1 and 4 there are no WAIT lines, and all the time between calls, including the application time, falls here.
• The trace was turned off and on again. The interval without a trace stays inside the total time, with no line to explain it.
• The trace ends in the middle of an application call. The line of a call only goes to the file when the call ends. If tracing stopped while a PL/SQL block called by the application was still running, its EXEC is not in the file, and the time of the block outside the SQL statements falls here. The warning about recursive calls without a matching level-0 call, at the top of the report, shows this case (case 1).
• A file of the collection is missing. The application splits the session across several files (by changing tracefile_identifier) and only some of them were uploaded, or they were analyzed separately.
• The process stalled outside the database. The server process was left without CPU (saturated server), or the application took its time without the client wait showing up.

Resolution

1. Check whether the trace has waits: Waits equal to 0 in the Summary indicates a trace without waits. Generate it again at level 8 or 12 (10046 levels).
2. Check that the Period in the Summary matches the operation and that tracing stayed on the whole time. Turn it on once, before the start, and turn it off once, after the end (turn on tracing with DBMS_MONITOR).
3. Look in the trace for the lines *** TRACE CONTINUES IN FILE and *** TRACE CONTINUED FROM FILE: they mark a file switch. If they appear, upload all the files together, as a collection (analyze together), and check the list of files and sessions in the report (Collection).
4. If none of this explains it, check the CPU load on the server during the period, as in unaccounted-for time within calls, and what the application was doing between calls.

How to confirm

Generate a new trace of the same operation, with waits and turned on from start to end, or upload the complete collection. The component should become small, the time it was hiding shows up in SQL*Net message from client or in another wait, and the finding disappears.

In the report

In the sample report, this component adds up to 4.1% of the total time, without a finding. The case 1 report, from a real trace, has this finding (case 1 Diagnosis). The links below open the sections of the example:

• Diagnosis: the finding and the View in profile link.
• Profile, unaccounted-for time between calls row. Click the name to open the card with Where to look.
• Summary: Period and Waits, which shows the wait time between calls in the same panel.
• Longest depth-0 calls: the Start (+s) column shows at which point of the trace each call started.
• Collection: the panel with the files and the sessions appears in the Summary only when the analysis merges several traces, so it is not in the example.