An error that the application handles silently still costs time and can explain a strange result. The errors section lists the ORA- codes the trace recorded, what each one means and in which statement it appeared.
What the section shows
The Errors section appears when the trace has ERROR or PARSE ERROR lines. The text at the top explains the limit of the data: The trace keeps only the code; the full message text stays with whoever received the error. The name of the violated constraint, for example, is in the application log, not in the trace.
Each code is a card, from the most frequent to the least frequent. The title is the code with its name, such as ORA-00001 · unique constraint violated, and next to it come the occurrences, the first time the error appeared and the trace line. The card has:
- What it is, When it appears and What to do, when the code is in the console catalog. Outside it, the card says Code not in the console's catalog., and codes 20000 to 20999 appear as application-raised error, because they are the ones from
RAISE_APPLICATION_ERROR; - the Oracle documentation for ORA-NNNNN link, for the database version of the trace, from 10.2 to 23ai. In the versions that Oracle documents by chapter, from 10.2 to 18, a code without an exact link leads to the chapter of its range, and a note says to search for the code on the page;
- for ORA-00060, when the trace has the deadlock, the View the deadlock link (deadlocks).
How to read it
The Where it appeared table of each card shows the places of the error, by the first occurrence in the trace.
| Column | What it says |
|---|---|
| Call | The last call of the cursor before the error, such as EXEC or FETCH. For PARSE ERROR, PARSE. |
| Statement | The number and the beginning of the statement text, with a link to the detail. For a shape, which adds up statements that differ only in literals, the N variants badge comes before the text. For PARSE ERROR, the text of the SQL that failed, without a link. |
| Depth | The depth: 0 for the application call, 1 or more for recursive SQL. |
| Occurrences | How many times the error appeared in that place. |
| First seen | Date and time of the first occurrence or, without the time in the trace, the seconds since its start. |
| Line | The trace line of the first occurrence. |
In the statement detail, the Errors card counts the ERROR lines of its cursor.
PARSE ERROR
The PARSE ERROR line is SQL the database could not parse: a syntax error, an object that does not exist, a missing privilege. That SQL gets no cursor, so it does not become a statement in SQL statements: the place of the error is identified by the text, which the trace writes right after the line. With Report privacy turned on in My account, text with quotes appears only up to the first quote, followed by ***: in rejected SQL, there is no safe way to know where each value ends (hidden literals).
ORA-01403, no data found
ORA-01403 (no data found) is normal in read loops, such as a SELECT INTO with no row or the end of a cursor in PL/SQL. It appears in the list, but does not count toward the errors finding. When it is the only code in the trace, the Diagnosis shows the no data found info finding.
When it is a concern
- Any code other than ORA-01403 triggers the Oracle errors finding, of high severity, with the View errors link.
- Many occurrences of the same code in the same statement: the application causes the error over and over, such as inserting and handling the duplicate key. The
SQL*Net break/reset to clientwait in the profile usually comes with this pattern. - An error in a recursive statement: the problem is in the function, procedure or trigger, not in the SQL the application called.
Where to go next
The synthetic trace of the sample has no errors, and the sample report does not have this section.
- Oracle errors, for the cause and the resolution.
- No data found, for ORA-01403.
- Statement detail where the error appeared.