Case 1: time between calls and row-by-row SQL. Sample report, generated by WaitScope from an anonymized excerpt of a real trace. View case 2 Back to the WaitScope page

WaitScope

caso-1.trc

Analyzed on 2026-10-29 10:19:46 · 174.0 MiB · 1,997,223 lines · up to 10 statements per list

718792 recursive calls without a matching level-0 call (trace started or cut in the middle of a call)
Total time
50.833 s
50.8 s
Period
2015-01-16 19:36:52
to 19:37:43
Database calls
719,114
6 at depth 0
Waits
20,320
0.166 s between calls
Distinct statements
1,977
2 commits · 0 rollbacks

Session and environment

Database
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
Instance
INST_01
Server
MAQ_01 · Linux · x86_64
Session
151.464 · pid 79628
Service
SYS$USERS
Module
MOD_01
Action
Time unit
microseconds
File on server
caso1.trc

Diagnosis

Patterns that often explain what the trace shows, in order of severity. They are leads for the analysis, not conclusions.

medium unaccounted-for time between calls dominates response time 73.6% of total time

73.6% of the total time (37.419 s) comes from a single component. That is where the analysis starts. View in profile

medium Time gaps between calls 73.6% of total time

Time between level-0 calls with no recorded wait. The trace may have been turned on and off mid-session, or the process was stalled outside the database. View in profile

medium Statement #1 executed 89,112 times 9.7% of total time

Recursive SQL executed once per row, typical of a PL/SQL loop. Set-based processing (a single SQL or FORALL) usually cuts the time a lot. View statement #1

medium Statement #2 executed 89,112 times 9.5% of total time

Recursive SQL executed once per row, typical of a PL/SQL loop. Set-based processing (a single SQL or FORALL) usually cuts the time a lot. View statement #2

low Statement #1: plan operation 2 accounts for 100.0% of logical reads 9.7% of total time

Operation TABLE ACCESS FULL TAB_0005. Reads the whole object: check whether the filter is selective and has an index. The operations are highlighted in the plan, in the statement detail. View in the plan of statement #1

low Statement #2: plan operation 2 accounts for 100.0% of logical reads 9.5% of total time

Operation TABLE ACCESS FULL TAB_0005. Reads the whole object: check whether the filter is selective and has an index. The operations are highlighted in the plan, in the statement detail. View in the plan of statement #2

low Statement #1: one PARSE per execution (89,112 PARSE, 89,112 EXEC) 3.1% of total time

The cursor is opened and closed on every use. Keeping the cursor open in the application (driver statement cache) or session_cached_cursors avoids the repeated PARSE. View statement #1

low Statement #2: one PARSE per execution (89,112 PARSE, 89,112 EXEC) 3.1% of total time

The cursor is opened and closed on every use. Keeping the cursor open in the application (driver statement cache) or session_cached_cursors avoids the repeated PARSE. View statement #2

low Statement #3: 1,217 variants of the same SQL, differing only in literals 2.5% of total time

The application writes the values into the SQL text instead of using bind variables, so each different value becomes a new statement for the database. The variants' 1,217 PARSE calls, 1,217 of them hard parses, took 1.295 s (2.5% of the total time); with all 3,651 calls and the recursive SQL, the variants add up to 1.451 s. The fix is to use bind variables in the application. CURSOR_SHARING=FORCE in the database reduces hard parses while the application does not change, but it is only a stopgap. View statement #3

Response time profile

Each row is a share of the total time; added up, they make 100%. Click a component or class name to see what that time means, when it is normal, when it points to a problem and where to check in the report. Unaccounted-for time is what the trace does not explain by CPU or by waits: inside calls, it is usually CPU queueing or code without instrumentation; a negative value comes from the granularity of the CPU measurement.

ComponentDuration (s)% of totalchartOccurrencesAvg (s)Min (s)Max (s)
unaccounted-for 37.419211 73.6
cpu 5.125233 10.1 180,117 0.000028 0.000000 0.008999
cpu 4.550304 9.0 178,460 0.000025 0.000000 0.008999
cpu 2.189671 4.3 180,269 0.000012 0.000000 0.124981
User I/O 1.047610 2.1 1,962 0.000534 0.000005 0.035303
cpu 0.255954 0.5 180,268 0.000001 0.000000 0.001999
User I/O 0.165164 0.3 18,337 0.000009 0.000003 0.018484
unaccounted-for 0.055133 0.1 719,114 0.000000
Application 0.014392 0.0 1 0.014392 0.014392 0.014392
User I/O 0.008094 0.0 3 0.002698 0.001960 0.003773
Idle 0.001212 0.0 2 0.000606 0.000489 0.000723
Other 0.000616 0.0 3 0.000205 0.000005 0.000385
User I/O 0.000524 0.0 10 0.000052 0.000023 0.000082
Network 0.000007 0.0 2 0.000003 0.000003 0.000004
Total50.833125100.0

By wait class

The same components grouped by Oracle wait class (wait_class), with CPU and unaccounted-for time shown separately. The sum is also the total time.

ClassDuration (s)% of totalchartOccurrencesTop components
37.474344 73.7 unaccounted-for time between calls · unaccounted-for time within calls
12.121162 23.8 719,114 CPU: PARSE dbcalls · CPU: FETCH dbcalls · CPU: EXEC dbcalls · CPU: CLOSE dbcalls
1.221392 2.4 20,312 db file sequential read · direct path read · local write wait · Disk file operations I/O
0.014392 0.0 1 enq: RO - fast object reuse
0.001212 0.0 2 SQL*Net message from client
0.000616 0.0 3 reliable message
0.000007 0.0 2 SQL*Net message to client

Top statements by component and by class

How much each statement spent in each profile component and each wait class, based on the statement's exclusive profile (without the recursive SQL it triggers). Up to 10 statements per list: change it at the top of the page.

By profile component

CPU: PARSE dbcalls cpu5.125 s · 10.1% of total time · 10 statements
CPU: FETCH dbcalls cpu4.550 s · 9.0% of total time · 10 of 12 statements

2 more statements spent time here; raise the number at the top of the page to see them.

CPU: EXEC dbcalls cpu2.190 s · 4.3% of total time · 10 of 29 statements

19 more statements spent time here; raise the number at the top of the page to see them.

db file sequential read wait1.048 s · 2.1% of total time · 10 of 23 statements

13 more statements spent time here; raise the number at the top of the page to see them.

CPU: CLOSE dbcalls cpu0.256 s · 0.5% of total time · 3 statements
direct path read wait0.165 s · 0.3% of total time · 1 statement
#Time (s)% of totalchartSQL IDText
40.06639540.29sxjs1fk1qc9gBEGIN ROT_0001('***',*** ); END;
unaccounted-for time within calls unaccounted-for0.055 s · 0.1% of total time · 10 of 41 statements

31 more statements spent time here; raise the number at the top of the page to see them.

enq: RO - fast object reuse wait0.014 s · 0.0% of total time · 1 statement
#Time (s)% of totalchartSQL IDText
100.014392100.09y5d9x2wwc9nnTRUNCATE TABLE TAB_0005
local write wait wait0.008 s · 0.0% of total time · 1 statement
#Time (s)% of totalchartSQL IDText
100.008094100.09y5d9x2wwc9nnTRUNCATE TABLE TAB_0005
SQL*Net message from client wait0.001 s · 0.0% of total time · 2 statements
#Time (s)% of totalchartSQL IDText
60.00072359.7#140548883950424
50.00048940.368ngguy15jsj7alter session set events='***'

By wait class

Unaccounted-for37.474 s · 73.7% of total time · 10 of 41 statements

31 more statements spent time here; raise the number at the top of the page to see them.

CPU12.121 s · 23.8% of total time · 10 of 38 statements

28 more statements spent time here; raise the number at the top of the page to see them.

User I/O1.221 s · 2.4% of total time · 10 of 24 statements

14 more statements spent time here; raise the number at the top of the page to see them.

Application0.014 s · 0.0% of total time · 1 statement
#Time (s)% of totalchartSQL IDText
100.014392100.09y5d9x2wwc9nnTRUNCATE TABLE TAB_0005
Idle0.001 s · 0.0% of total time · 2 statements
#Time (s)% of totalchartSQL IDText
60.00072359.7#140548883950424
50.00048940.368ngguy15jsj7alter session set events='***'
Other0.001 s · 0.0% of total time · 1 statement
#Time (s)% of totalchartSQL IDText
100.000616100.09y5d9x2wwc9nnTRUNCATE TABLE TAB_0005
Network0.000 s · 0.0% of total time · 2 statements
#Time (s)% of totalchartSQL IDText
60.00000457.1#140548883950424
50.00000342.968ngguy15jsj7alter session set events='***'

SQL statements by contribution

Contribution: duration of the statement's depth-0 calls plus the waits between calls on its cursor. Inclusive: sum of all the statement's calls, at any depth.

#Contribution (s)% of totalInclusive (s)TypeDepthExecFetchRowsLIOPIOSQL IDText
1 1.415 2.8 4.941 SELECT 1 89,112 89,112 89,112 445,560 0 49 variants SELECT (SELECT COL_0073 FROM TAB_0005 WHERE COL_0074 = :n AND ROWNUM <=:n) AS COL_0073 FROM DUAL
2 1.405 2.8 4.842 SELECT 1 89,112 89,112 89,112 445,560 0 49 variants SELECT (SELECT COL_0075 FROM TAB_0005 WHERE COL_0074 = :n AND ROWNUM <=:n) AS COL_0075 FROM DUAL
3 0.623 1.2 1.451 INSERT 1 1,217 0 1,217 8,761 32 1,217 variants INSERT INTO TAB_0001 (COL_0076,COL_0077, … NULL,NULL,:s,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:s,NULL,NULL,NULL,NULL…
4 0.137 0.3 0.070 PL/SQL 0 0 0 0 24 8 9sxjs1fk1qc9g BEGIN ROT_0001('***',*** ); END;
5 0.040 0.1 0.040 ALTER SESSION 0 1 0 0 0 0 68ngguy15jsj7 alter session set events='***'
6 0.027 0.1 0.026 ? 0 1 0 0 0 0 #140548883950424
7 0.000 0.0 1.023 DELETE 1 2 0 0 3,740 1,870 42q0kx6suxhw2 DELETE FROM TAB_0001
8 0.000 0.0 0.417 INSERT 1 350 0 350 2,590 18 350 variants INSERT INTO TAB_0001 (COL_0076,COL_0077, … :s,:s,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL…
9 0.000 0.0 0.288 INSERT 1 251 0 251 1,800 5 251 variants INSERT INTO TAB_0001 (COL_0076,COL_0077, … NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,…
10 0.000 0.0 0.082 TRUNCATE TABLE 1 1 0 0 110 17 9y5d9x2wwc9nn TRUNCATE TABLE TAB_0005

Rows marked with variants add up statements that differ only in literals; in the text, :s and :n take the place of the literals.

Showing 10 of 65 statements; raise the number at the top of the page to see more.

Time not attributed to any statement: 47.186 s.

Call types

CallCountCPU (s)Duration (s)Disk (PIO)Consistent (CR)Current (CU)RowsMisses
PARSE180,1175.1405.15619126101,920
FETCH178,4604.5504.72628893,2970178,4320
EXEC180,2692.2123.2451,9405,70311,3631,8781
CLOSE180,2680.2560.25000000

Longest depth-0 calls

CallDuration (s)CPU (s)Start (+s)LineLIOPIORowsStatement
PARSE 0.070229 0.010998 0.068 101 24 8 0 #4 BEGIN ROT_0001('***',*** ); END;
EXEC 0.039483 0.002000 0.028 36 0 0 0 #5 alter session set events='***'
EXEC 0.025924 0.001000 0.000 27 0 0 0 #6 #140548883950424
PARSE 0.000157 0.000000 0.027 35 0 0 0 #5 alter session set events='***'
CLOSE 0.000014 0.000000 0.068 39 0 0 0 #5 alter session set events='***'
CLOSE 0.000010 0.000000 0.027 30 0 0 0 #6 #140548883950424

Latency distribution

Buckets in powers of 10, by wait event and by call type. Shows whether the time comes from many fast occurrences or a few slow ones.

db file sequential read1,962 occurrences · 1.048 s
Duration bucketOccurrences% occ.Duration (s)% duration
0 ≤ e < 1 µs00.00.0000000.0
1 µs ≤ e < 10 µs92146.90.0073730.7
10 µs ≤ e < 100 µs79240.40.0134591.3
100 µs ≤ e < 1 ms1387.00.0630206.0
1 ms ≤ e < 10 ms814.10.49272747.0
10 ms ≤ e < 100 ms301.50.47103145.0
100 ms ≤ e < 1 s00.00.0000000.0
1 s ≤ e < 10 s00.00.0000000.0
10 s ≤ e < 100 s00.00.0000000.0
100 s ≤ e < 1.000 s00.00.0000000.0
1.000 s ≤ e < ∞00.00.0000000.0
direct path read18,337 occurrences · 0.165 s
Duration bucketOccurrences% occ.Duration (s)% duration
0 ≤ e < 1 µs00.00.0000000.0
1 µs ≤ e < 10 µs15,93186.90.08889453.8
10 µs ≤ e < 100 µs2,39913.10.03152419.1
100 µs ≤ e < 1 ms30.00.0008710.5
1 ms ≤ e < 10 ms20.00.0121987.4
10 ms ≤ e < 100 ms20.00.03167719.2
100 ms ≤ e < 1 s00.00.0000000.0
1 s ≤ e < 10 s00.00.0000000.0
10 s ≤ e < 100 s00.00.0000000.0
100 s ≤ e < 1.000 s00.00.0000000.0
1.000 s ≤ e < ∞00.00.0000000.0
enq: RO - fast object reuse1 occurrences · 0.014 s
Duration bucketOccurrences% occ.Duration (s)% duration
0 ≤ e < 1 µs00.00.0000000.0
1 µs ≤ e < 10 µs00.00.0000000.0
10 µs ≤ e < 100 µs00.00.0000000.0
100 µs ≤ e < 1 ms00.00.0000000.0
1 ms ≤ e < 10 ms00.00.0000000.0
10 ms ≤ e < 100 ms1100.00.014392100.0
100 ms ≤ e < 1 s00.00.0000000.0
1 s ≤ e < 10 s00.00.0000000.0
10 s ≤ e < 100 s00.00.0000000.0
100 s ≤ e < 1.000 s00.00.0000000.0
1.000 s ≤ e < ∞00.00.0000000.0
local write wait3 occurrences · 0.008 s
Duration bucketOccurrences% occ.Duration (s)% duration
0 ≤ e < 1 µs00.00.0000000.0
1 µs ≤ e < 10 µs00.00.0000000.0
10 µs ≤ e < 100 µs00.00.0000000.0
100 µs ≤ e < 1 ms00.00.0000000.0
1 ms ≤ e < 10 ms3100.00.008094100.0
10 ms ≤ e < 100 ms00.00.0000000.0
100 ms ≤ e < 1 s00.00.0000000.0
1 s ≤ e < 10 s00.00.0000000.0
10 s ≤ e < 100 s00.00.0000000.0
100 s ≤ e < 1.000 s00.00.0000000.0
1.000 s ≤ e < ∞00.00.0000000.0
SQL*Net message from client2 occurrences · 0.001 s
Duration bucketOccurrences% occ.Duration (s)% duration
0 ≤ e < 1 µs00.00.0000000.0
1 µs ≤ e < 10 µs00.00.0000000.0
10 µs ≤ e < 100 µs00.00.0000000.0
100 µs ≤ e < 1 ms2100.00.001212100.0
1 ms ≤ e < 10 ms00.00.0000000.0
10 ms ≤ e < 100 ms00.00.0000000.0
100 ms ≤ e < 1 s00.00.0000000.0
1 s ≤ e < 10 s00.00.0000000.0
10 s ≤ e < 100 s00.00.0000000.0
100 s ≤ e < 1.000 s00.00.0000000.0
1.000 s ≤ e < ∞00.00.0000000.0
reliable message3 occurrences · 0.001 s
Duration bucketOccurrences% occ.Duration (s)% duration
0 ≤ e < 1 µs00.00.0000000.0
1 µs ≤ e < 10 µs133.30.0000050.8
10 µs ≤ e < 100 µs00.00.0000000.0
100 µs ≤ e < 1 ms266.70.00061199.2
1 ms ≤ e < 10 ms00.00.0000000.0
10 ms ≤ e < 100 ms00.00.0000000.0
100 ms ≤ e < 1 s00.00.0000000.0
1 s ≤ e < 10 s00.00.0000000.0
10 s ≤ e < 100 s00.00.0000000.0
100 s ≤ e < 1.000 s00.00.0000000.0
1.000 s ≤ e < ∞00.00.0000000.0
Disk file operations I/O10 occurrences · 0.001 s
Duration bucketOccurrences% occ.Duration (s)% duration
0 ≤ e < 1 µs00.00.0000000.0
1 µs ≤ e < 10 µs00.00.0000000.0
10 µs ≤ e < 100 µs10100.00.000524100.0
100 µs ≤ e < 1 ms00.00.0000000.0
1 ms ≤ e < 10 ms00.00.0000000.0
10 ms ≤ e < 100 ms00.00.0000000.0
100 ms ≤ e < 1 s00.00.0000000.0
1 s ≤ e < 10 s00.00.0000000.0
10 s ≤ e < 100 s00.00.0000000.0
100 s ≤ e < 1.000 s00.00.0000000.0
1.000 s ≤ e < ∞00.00.0000000.0
SQL*Net message to client2 occurrences · 0.000 s
Duration bucketOccurrences% occ.Duration (s)% duration
0 ≤ e < 1 µs00.00.0000000.0
1 µs ≤ e < 10 µs2100.00.000007100.0
10 µs ≤ e < 100 µs00.00.0000000.0
100 µs ≤ e < 1 ms00.00.0000000.0
1 ms ≤ e < 10 ms00.00.0000000.0
10 ms ≤ e < 100 ms00.00.0000000.0
100 ms ≤ e < 1 s00.00.0000000.0
1 s ≤ e < 10 s00.00.0000000.0
10 s ≤ e < 100 s00.00.0000000.0
100 s ≤ e < 1.000 s00.00.0000000.0
1.000 s ≤ e < ∞00.00.0000000.0
PARSE (call duration e)180,117 occurrences · 5.156 s
Duration bucketOccurrences% occ.Duration (s)% duration
0 ≤ e < 1 µs00.00.0000000.0
1 µs ≤ e < 10 µs50.00.0000350.0
10 µs ≤ e < 100 µs178,11198.93.00097858.2
100 µs ≤ e < 1 ms1,2750.71.12522621.8
1 ms ≤ e < 10 ms7220.40.91069917.7
10 ms ≤ e < 100 ms40.00.1188772.3
100 ms ≤ e < 1 s00.00.0000000.0
1 s ≤ e < 10 s00.00.0000000.0
10 s ≤ e < 100 s00.00.0000000.0
100 s ≤ e < 1.000 s00.00.0000000.0
1.000 s ≤ e < ∞00.00.0000000.0
FETCH (call duration e)178,460 occurrences · 4.726 s
Duration bucketOccurrences% occ.Duration (s)% duration
0 ≤ e < 1 µs00.00.0000000.0
1 µs ≤ e < 10 µs780.00.0004380.0
10 µs ≤ e < 100 µs178,05999.84.51408695.5
100 µs ≤ e < 1 ms3030.20.0484631.0
1 ms ≤ e < 10 ms140.00.0622551.3
10 ms ≤ e < 100 ms60.00.1003072.1
100 ms ≤ e < 1 s00.00.0000000.0
1 s ≤ e < 10 s00.00.0000000.0
10 s ≤ e < 100 s00.00.0000000.0
100 s ≤ e < 1.000 s00.00.0000000.0
1.000 s ≤ e < ∞00.00.0000000.0
EXEC (call duration e)180,269 occurrences · 3.245 s
Duration bucketOccurrences% occ.Duration (s)% duration
0 ≤ e < 1 µs00.00.0000000.0
1 µs ≤ e < 10 µs118,35065.70.97725330.1
10 µs ≤ e < 100 µs59,90733.20.78554824.2
100 µs ≤ e < 1 ms1,9911.10.2626698.1
1 ms ≤ e < 10 ms160.00.0466731.4
10 ms ≤ e < 100 ms40.00.1558444.8
100 ms ≤ e < 1 s00.00.0000000.0
1 s ≤ e < 10 s10.01.01711531.3
10 s ≤ e < 100 s00.00.0000000.0
100 s ≤ e < 1.000 s00.00.0000000.0
1.000 s ≤ e < ∞00.00.0000000.0
CLOSE (call duration e)180,268 occurrences · 0.250 s
Duration bucketOccurrences% occ.Duration (s)% duration
0 ≤ e < 1 µs00.00.0000000.0
1 µs ≤ e < 10 µs179,92699.80.24024496.0
10 µs ≤ e < 100 µs3380.20.0087393.5
100 µs ≤ e < 1 ms40.00.0012270.5
1 ms ≤ e < 10 ms00.00.0000000.0
10 ms ≤ e < 100 ms00.00.0000000.0
100 ms ≤ e < 1 s00.00.0000000.0
1 s ≤ e < 10 s00.00.0000000.0
10 s ≤ e < 100 s00.00.0000000.0
100 s ≤ e < 1.000 s00.00.0000000.0
1.000 s ≤ e < ∞00.00.0000000.0

Reads

reads (disk buckets)20,299 occurrences · 1.213 s
Duration bucketOccurrences% occ.Duration (s)% duration
0 ≤ e < 5 ms20,20899.60.26974822.2
5 ms ≤ e < 10 ms590.30.44031836.3
10 ms ≤ e < 15 ms170.10.20055416.5
15 ms ≤ e < 20 ms100.00.17148414.1
20 ms ≤ e < 25 ms30.00.0676895.6
25 ms ≤ e < 50 ms20.00.0629815.2
50 ms ≤ e < 100 ms00.00.0000000.0
100 ms ≤ e < 1 s00.00.0000000.0
1 s ≤ e < ∞00.00.0000000.0
reads (SSD buckets)20,299 occurrences · 1.213 s
Duration bucketOccurrences% occ.Duration (s)% duration
0 ≤ e < 15 µs19,49696.00.12606210.4
15 µs ≤ e < 25 µs2951.50.0054640.5
25 µs ≤ e < 50 µs2091.00.0068390.6
50 µs ≤ e < 100 µs430.20.0028850.2
100 µs ≤ e < 500 µs930.50.0317632.6
500 µs ≤ e < 1 ms480.20.0321282.6
1 ms ≤ e < 10 ms830.40.50492541.6
10 ms ≤ e < ∞320.20.50270841.5

First read and reread of the same block

Frequent rereads of the same block point to a small cache or repeated access to the same data.

EventDistinct blocks1st read1st read (s)RereadsRereads (s)
db file sequential read1,9561,9561.04860.000
local write wait000.00030.008

Objects with the most wait time

By the obj# of the waits. The name comes from the STAT lines in the trace itself, when present.

obj#NameWait (s)OccurrencesTop events
188047IDX_00010.9311,877db file sequential read · Disk file operations I/O
1877500.16518,336direct path read
1008999TAB_00050.02317enq: RO - fast object reuse · local write wait · reliable message
226IDL_CHAR$0.0171db file sequential read
107I_DEPENDENCY20.0161db file sequential read
227IDL_UB2$0.0161db file sequential read
427IDX_00120.0101db file sequential read
228IDL_SB4$0.0091db file sequential read
31CDEF$0.0082db file sequential read
19IND$0.0083db file sequential read
237I_IDL_CHAR10.0071db file sequential read
236I_IDL_UB110.0071db file sequential read
1876940.00649db file sequential read
40I_OBJ50.0051db file sequential read
225IDL_UB1$0.0041db file sequential read
464IDX_00080.0031db file sequential read
3840.0014SQL*Net message from client · SQL*Net message to client
6505980.0002db file sequential read · Disk file operations I/O
187749TAB_00020.0002db file sequential read
239I_IDL_SB410.0001db file sequential read
3I_OBJ#0.0001db file sequential read
54I_CDEF20.0002db file sequential read
18OBJ$0.0002db file sequential read
1877510.0002db file sequential read · direct path read
462IDX_00070.0001db file sequential read
188088IDX_00020.0001db file sequential read
39I_OBJ40.0001db file sequential read
238I_IDL_UB210.0001db file sequential read
9I_FILE#_BLOCK#0.0001db file sequential read
57I_CCOL10.0001db file sequential read

Shareable texts

Statements that differ only in literals. With bind variables, a single cursor would serve them all and hard-parse PARSE calls would drop.

Unaccounted-for time between calls

unaccounted-for time between calls

Time between the end of one level-0 call and the start of the next with no recorded wait. It is the difference between the total time and the sum of the calls and the waits between them.

Normal when
Small: fractions of a millisecond per call.
A concern when
It adds up a lot: the trace was turned on or off midway, the process was kept off the CPU (saturated server), the application took long without the client wait showing up, or a collection file is missing.
Where to look

CPU in PARSE calls

CPU: PARSE dbcalls

The session's CPU time parsing the SQL. High: hard parses from SQL without binds, or repeated parsing of the same cursor (opened and closed on every execution).

Normal when
It is part of the database's normal work.
A concern when
It dominates the total time: start with the statements that use the most CPU and with their logical reads.
Where to look

CPU in FETCH calls

CPU: FETCH dbcalls

The session's CPU time fetching rows. High: too many logical reads (LIO), usually a plan that reads far more blocks than the rows returned call for.

Normal when
It is part of the database's normal work.
A concern when
It dominates the total time: start with the statements that use the most CPU and with their logical reads.
Where to look

CPU in EXEC calls

CPU: EXEC dbcalls

The session's CPU time executing: DML, cursor opening and the body of PL/SQL blocks. High in PL/SQL: heavy logic or SQL inside a loop.

Normal when
It is part of the database's normal work.
A concern when
It dominates the total time: start with the statements that use the most CPU and with their logical reads.
Where to look

Single-block read

db file sequential read

Reads one block from disk into the buffer cache: index access, table access by ROWID, undo or segment header.

Normal when
Index access to a few blocks, averaging 0.1 to 1 ms on SSD or flash and 5 to 10 ms on disk.
A concern when
Many reads: the plan reads too many blocks (unselective index, NESTED LOOPS with many rows). High average: slow or contended storage.
Where to look

CPU in CLOSE calls

CPU: CLOSE dbcalls

The session's CPU time closing the cursor. Almost always small.

Normal when
It is part of the database's normal work.
A concern when
It dominates the total time: start with the statements that use the most CPU and with their logical reads.
Where to look

Direct read into the PGA

direct path read

Reads blocks from disk straight into session memory, bypassing the buffer cache: large serial full scan or parallel query.

Normal when
Full read of a large table in a batch process.
A concern when
It shows up in a user screen or inside a loop: a large full scan repeated, a whole table read to return a few rows.
Where to look

Unaccounted-for time within calls

unaccounted-for time within calls

The part of the call's duration (e=) that is neither CPU (c=) nor a wait recorded inside it.

Normal when
Small. A negative value comes from the granularity of the CPU measurement, not from a problem.
A concern when
It adds up a lot: CPU queueing (more runnable processes than cores), memory paging (swap) or code without wait instrumentation.
Where to look

Buffer cleanup (TRUNCATE or DROP)

enq: RO - fast object reuse

TRUNCATE or DROP waiting for the database to discard the object's blocks held in the buffer cache.

Normal when
It adds up to little time.
A concern when
TRUNCATE inside a loop, or a buffer cache too large to sweep.
Where to look

User I/O (data reads and writes)

User I/O

Data reads and writes done by the session itself.

Normal when
There is always some I/O, with a low average per read.
A concern when
Too many blocks (the plan reads more than it needs) or high average time per read (slow storage).
Where to look

Waiting for the application

SQL*Net message from client

The session finished the previous call and is waiting for the application's next request. It is application, network and user time, not database time.

Normal when
It shows up between every call. Long, isolated waits are the user thinking or the application busy with something else.
A concern when
It dominates the total time with many short waits: the application talks to the database too much (one row per call, SQL inside a loop). With a few long waits, the delay is in the application, and SQL tuning will not fix it.
Where to look

Inter-process message

reliable message

The session sent a message to background processes or to other instances and waits for the acknowledgement.

Normal when
It adds up to little time.
A concern when
It adds up a lot: TRUNCATE, result cache or a parameter change in RAC.
Where to look

Opening or closing files

Disk file operations I/O

File operations (open, close, size lookup), not data reads.

Normal when
It adds up to little time.
A concern when
It adds up a lot: many files opened and closed, or a slow file system.
Where to look

Sending the response

SQL*Net message to client

Time to hand a response packet to the operating system. It does not measure the network to the client, only the handoff to the OS.

Normal when
Microseconds per occurrence, one per call.
A concern when
The average rises to milliseconds: the server's network buffer is full or the network is saturated.
Where to look

Unaccounted-for

Unaccounted-for

Time the trace does not explain by CPU or wait: within calls and between them.

Normal when
Small.
A concern when
CPU queue, paging, gaps in the trace or a file missing from the collection.
Where to look

CPU

CPU

CPU time of the database calls (the c= of PARSE, EXEC and FETCH).

Normal when
This is the database's work.
A concern when
It adds up a lot: too many logical reads (plan), too much parsing or heavy PL/SQL.
Where to look

Application

Application

Waits caused by how the application uses the database: rows and tables locked by another session, application locks, returned errors.

Normal when
It adds up to little time.
A concern when
Session stalled waiting for another: long transactions, same row updated by several sessions, unindexed foreign key.
Where to look

Idle

Idle

The session is waiting for work. In a session trace it is almost always SQL*Net message from client: application, network and user time.

Normal when
It shows up between calls.
A concern when
Dominates the total time and the user complains about slowness: the delay is outside the database (application, network, too many round trips).
Where to look

Other

Other

Internal events with no more specific class.

Normal when
It adds up to little time.
A concern when
It adds up a lot: the event itself points to the cause.
Where to look

Network

Network

Sending and receiving data over SQL*Net, with the application or with another database over dblink.

Normal when
It adds up to little time.
A concern when
Large results, low arraysize or slow dblink.
Where to look

Recursive SQL (child statements)

Recursive SQL (child statements)

Time of the calls this statement triggered: SQL inside PL/SQL functions and procedures, triggers and dictionary queries.

Normal when
PL/SQL statement that runs other SQL.
A concern when
It adds up a lot in a plain SELECT or DML: a PL/SQL function called per row, or a heavy trigger.
Where to look
  • Which child statements and what each one costs: statement detail, Recursive SQL

WaitScope 1.7.0 · analyzed on the server · report exported on 2026-10-29 10:19:57