What WaitScope does not do

WaitScope reads the trace file you upload and builds the report only from what is in it. This page gathers what is left out: what the service does not do, the files it rejects and what a trace cannot show.

What WaitScope does not do

• It does not connect to the database. There is no agent, connector, user or schema in your environment. WaitScope sees only the files you choose to upload.
• It does not monitor. It does not stay attached to the database or collect anything continuously: each analysis is the trace of one operation you decided to trace. To follow the database throughout the day, use a monitoring tool.
• It does not change anything in the database. The ready-made queries on the object page and the statistics blocks run only if you copy them and execute them in your database.
• It does not read bind values. The BINDS block of the trace is ignored, and the report does not show which values the SQL ran with.
• It does not keep the trace. The file leaves the server when the analysis finishes. There is no trace download and no reprocessing: to analyze it again, upload the file again. The retention periods are in Data retention, deletion and privacy.
• It does not decide for you. The diagnosis points to patterns that often explain the profile. As the report itself says, they are leads for the analysis, not conclusions: the decisions about the SQL, the database and the application are yours.

The report sees only what is in the trace

The 10046 trace records the traced session: the database calls, the waits and, when Oracle writes them, the plan rows. Everything the report shows comes from there.

• What other sessions were doing at the same time does not appear. In a lock wait, the trace shows how long the session waited, but not who held the resource. The exception is the deadlock: the DEADLOCK DETECTED block lists the sessions involved.
• The execution plan comes from the STAT lines of the trace itself. A statement without these lines has no plan: WaitScope does not query the database to fetch it.
• The time the session spends waiting for the application appears as the SQL*Net message from client wait, with no detail of what the application was doing in that interval.

Rejected files

WaitScope analyzes event 10046 traces and deadlock traces (ORA-00060). When the file has no 10046 line and no deadlock block, the analysis ends with the status error, and the message says which kind of file WaitScope recognized.

In the first five cases, the message goes on like this: “without the event 10046 lines (PARSE, EXEC, FETCH, WAIT) that the profile uses. To analyze a session, generate the trace with DBMS_MONITOR.SESSION_TRACE_ENABLE(waits => TRUE) or, in the session itself, ALTER SESSION SET EVENTS '10046 trace name context forever, level 8'”.

Rejection happens only when the 10046 lines are missing. A 10046 trace that also contains, for example, an ORA-00600 section is analyzed normally. WaitScope reads the trace that Oracle writes (.trc), not reports made from it: TKPROF output and AWR reports are also rejected.

The .trm files, which Oracle writes next to the .trc, are not traces: the console and the app leave them out of the upload. In a collection, a file that is not a trace is left out with the warning “file does not look like an Oracle trace and was left out of the collection”; if none is a trace, the analysis ends with “no file in the collection looks like an Oracle trace”.

Limits of what the trace shows

Trace without waits

At levels 1 and 4 of event 10046, or with waits => FALSE in DBMS_MONITOR, Oracle does not write the WAIT lines. The report is produced, but the profile has only CPU and unaccounted-for time: disk reads inside the calls become unaccounted-for time within calls, and waiting for the application becomes unaccounted-for time between calls. In the Summary, Waits equal to 0 shows this case.

In this case, the findings about unaccounted-for time do not mean CPU queueing or a gap in the trace: the information is missing. Generate the trace again with waits, at level 8 or 12 (event 10046 levels).

Truncated trace

• Turned on after the operation started. A cursor opened before the trace has no PARSING IN CURSOR line, and the statement detail shows “Text not available: the cursor was opened before the trace started.” A recursive call whose level-0 call started before the trace produces the warning “N recursive calls without a matching level-0 call (trace started or cut in the middle of a call)”.
• Turned off before the end. What the session did after the last line does not count in the total time. The same applies to a file that stopped at the trace size limit (the MAX_DUMP_FILE_SIZE parameter). A statement whose STAT lines were never written has no plan.
• Operation in several files. An application that changes tracefile_identifier splits the session into several traces. Analyzed alone, each file loses the cursors opened in the others: upload them all together, as a collection (analyze several traces together). A missing file shows up as unaccounted-for time between calls.

Unaccounted-for time

The profile always adds up to the total time. What the trace does not explain by CPU or by wait goes into two rows: unaccounted-for time within calls, the part of each call's duration that is neither CPU nor a recorded wait, and unaccounted-for time between calls, the interval between one level-0 call and the next with no recorded wait.

WaitScope measures how much it is, but the trace does not say what it was. The common causes are in unaccounted-for time within calls and unaccounted-for time between calls. A negative value within calls comes from the granularity of the CPU measurement (CPU above elapsed time).

Warnings at the top of the report

When the reading finds something unusual, the report shows highlighted warnings before the summary. The most common:

• “N waits without tim (old trace): splitting waits inside and outside calls relies on the event name”.
• “N overly long lines were truncated”.
• The analysis limits, which only a very large trace or one with many distinct statements reaches. The warning says which limit was reached and what was added into a group or left out of the detail. For statements, the estimated counts appear as about N: see trace with many statements.

Very long statement text appears truncated, with the note “Text truncated: the trace declares N characters.”

Where to go next

• Event 10046 levels: which level writes the waits the profile needs.
• 10046 trace lines that WaitScope reads: the fields of each line and where they appear in the report.
• Data retention, deletion and privacy: what is stored and for how long.
• Method for finding the root cause: how to read the profile, from the largest component to the smallest.