caso-1.trc
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.
73.6% of the total time (37.419 s) comes from a single component. That is where the analysis starts. View in profile
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
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
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
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
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
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
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
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.
| Component | Duration (s) | % of total | chart | Occurrences | Avg (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 | |
| Total | 50.833125 | 100.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.
| Class | Duration (s) | % of total | chart | Occurrences | Top 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
| # | Time (s) | % of total | chart | SQL ID | Text |
|---|---|---|---|---|---|
| 2 | 0.130972 | 51.2 | 49 variants SELECT (SELECT COL_0075 FROM TAB_0005 WHERE COL_0074 = :n AND ROWNUM <=:n) AS COL_0075 FROM DUAL | ||
| 1 | 0.123982 | 48.4 | 49 variants SELECT (SELECT COL_0073 FROM TAB_0005 WHERE COL_0074 = :n AND ROWNUM <=:n) AS COL_0073 FROM DUAL | ||
| 8 | 0.001000 | 0.4 | 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… |
direct path read wait0.165 s · 0.3% of total time · 1 statement
| # | Time (s) | % of total | chart | SQL ID | Text |
|---|---|---|---|---|---|
| 4 | 0.066395 | 40.2 | 9sxjs1fk1qc9g | BEGIN 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 total | chart | SQL ID | Text |
|---|---|---|---|---|---|
| 10 | 0.014392 | 100.0 | 9y5d9x2wwc9nn | TRUNCATE TABLE TAB_0005 |
local write wait wait0.008 s · 0.0% of total time · 1 statement
| # | Time (s) | % of total | chart | SQL ID | Text |
|---|---|---|---|---|---|
| 10 | 0.008094 | 100.0 | 9y5d9x2wwc9nn | TRUNCATE TABLE TAB_0005 |
SQL*Net message from client wait0.001 s · 0.0% of total time · 2 statements
| # | Time (s) | % of total | chart | SQL ID | Text |
|---|---|---|---|---|---|
| 6 | 0.000723 | 59.7 | #140548883950424 | ||
| 5 | 0.000489 | 40.3 | 68ngguy15jsj7 | alter 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 total | chart | SQL ID | Text |
|---|---|---|---|---|---|
| 10 | 0.014392 | 100.0 | 9y5d9x2wwc9nn | TRUNCATE TABLE TAB_0005 |
Idle0.001 s · 0.0% of total time · 2 statements
| # | Time (s) | % of total | chart | SQL ID | Text |
|---|---|---|---|---|---|
| 6 | 0.000723 | 59.7 | #140548883950424 | ||
| 5 | 0.000489 | 40.3 | 68ngguy15jsj7 | alter session set events='***' |
Other0.001 s · 0.0% of total time · 1 statement
| # | Time (s) | % of total | chart | SQL ID | Text |
|---|---|---|---|---|---|
| 10 | 0.000616 | 100.0 | 9y5d9x2wwc9nn | TRUNCATE TABLE TAB_0005 |
Network0.000 s · 0.0% of total time · 2 statements
| # | Time (s) | % of total | chart | SQL ID | Text |
|---|---|---|---|---|---|
| 6 | 0.000004 | 57.1 | #140548883950424 | ||
| 5 | 0.000003 | 42.9 | 68ngguy15jsj7 | alter 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.
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
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 180,117 | 5.140 | 5.156 | 19 | 126 | 1 | 0 | 1,920 |
| FETCH | 178,460 | 4.550 | 4.726 | 28 | 893,297 | 0 | 178,432 | 0 |
| EXEC | 180,269 | 2.212 | 3.245 | 1,940 | 5,703 | 11,363 | 1,878 | 1 |
| CLOSE | 180,268 | 0.256 | 0.250 | 0 | 0 | 0 | 0 | 0 |
Longest depth-0 calls
| Call | Duration (s) | CPU (s) | Start (+s) | Line | LIO | PIO | Rows | Statement |
|---|---|---|---|---|---|---|---|---|
| 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 bucket | Occurrences | % occ. | Duration (s) | % duration | |
|---|---|---|---|---|---|
| 0 ≤ e < 1 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 µs ≤ e < 10 µs | 921 | 46.9 | 0.007373 | 0.7 | |
| 10 µs ≤ e < 100 µs | 792 | 40.4 | 0.013459 | 1.3 | |
| 100 µs ≤ e < 1 ms | 138 | 7.0 | 0.063020 | 6.0 | |
| 1 ms ≤ e < 10 ms | 81 | 4.1 | 0.492727 | 47.0 | |
| 10 ms ≤ e < 100 ms | 30 | 1.5 | 0.471031 | 45.0 | |
| 100 ms ≤ e < 1 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 s ≤ e < 10 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 s ≤ e < 100 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 s ≤ e < 1.000 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1.000 s ≤ e < ∞ | 0 | 0.0 | 0.000000 | 0.0 |
direct path read18,337 occurrences · 0.165 s
| Duration bucket | Occurrences | % occ. | Duration (s) | % duration | |
|---|---|---|---|---|---|
| 0 ≤ e < 1 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 µs ≤ e < 10 µs | 15,931 | 86.9 | 0.088894 | 53.8 | |
| 10 µs ≤ e < 100 µs | 2,399 | 13.1 | 0.031524 | 19.1 | |
| 100 µs ≤ e < 1 ms | 3 | 0.0 | 0.000871 | 0.5 | |
| 1 ms ≤ e < 10 ms | 2 | 0.0 | 0.012198 | 7.4 | |
| 10 ms ≤ e < 100 ms | 2 | 0.0 | 0.031677 | 19.2 | |
| 100 ms ≤ e < 1 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 s ≤ e < 10 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 s ≤ e < 100 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 s ≤ e < 1.000 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1.000 s ≤ e < ∞ | 0 | 0.0 | 0.000000 | 0.0 |
enq: RO - fast object reuse1 occurrences · 0.014 s
| Duration bucket | Occurrences | % occ. | Duration (s) | % duration | |
|---|---|---|---|---|---|
| 0 ≤ e < 1 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 µs ≤ e < 10 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 µs ≤ e < 100 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 µs ≤ e < 1 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 ms ≤ e < 10 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 ms ≤ e < 100 ms | 1 | 100.0 | 0.014392 | 100.0 | |
| 100 ms ≤ e < 1 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 s ≤ e < 10 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 s ≤ e < 100 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 s ≤ e < 1.000 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1.000 s ≤ e < ∞ | 0 | 0.0 | 0.000000 | 0.0 |
local write wait3 occurrences · 0.008 s
| Duration bucket | Occurrences | % occ. | Duration (s) | % duration | |
|---|---|---|---|---|---|
| 0 ≤ e < 1 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 µs ≤ e < 10 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 µs ≤ e < 100 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 µs ≤ e < 1 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 ms ≤ e < 10 ms | 3 | 100.0 | 0.008094 | 100.0 | |
| 10 ms ≤ e < 100 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 ms ≤ e < 1 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 s ≤ e < 10 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 s ≤ e < 100 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 s ≤ e < 1.000 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1.000 s ≤ e < ∞ | 0 | 0.0 | 0.000000 | 0.0 |
SQL*Net message from client2 occurrences · 0.001 s
| Duration bucket | Occurrences | % occ. | Duration (s) | % duration | |
|---|---|---|---|---|---|
| 0 ≤ e < 1 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 µs ≤ e < 10 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 µs ≤ e < 100 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 µs ≤ e < 1 ms | 2 | 100.0 | 0.001212 | 100.0 | |
| 1 ms ≤ e < 10 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 ms ≤ e < 100 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 ms ≤ e < 1 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 s ≤ e < 10 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 s ≤ e < 100 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 s ≤ e < 1.000 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1.000 s ≤ e < ∞ | 0 | 0.0 | 0.000000 | 0.0 |
reliable message3 occurrences · 0.001 s
| Duration bucket | Occurrences | % occ. | Duration (s) | % duration | |
|---|---|---|---|---|---|
| 0 ≤ e < 1 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 µs ≤ e < 10 µs | 1 | 33.3 | 0.000005 | 0.8 | |
| 10 µs ≤ e < 100 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 µs ≤ e < 1 ms | 2 | 66.7 | 0.000611 | 99.2 | |
| 1 ms ≤ e < 10 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 ms ≤ e < 100 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 ms ≤ e < 1 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 s ≤ e < 10 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 s ≤ e < 100 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 s ≤ e < 1.000 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1.000 s ≤ e < ∞ | 0 | 0.0 | 0.000000 | 0.0 |
Disk file operations I/O10 occurrences · 0.001 s
| Duration bucket | Occurrences | % occ. | Duration (s) | % duration | |
|---|---|---|---|---|---|
| 0 ≤ e < 1 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 µs ≤ e < 10 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 µs ≤ e < 100 µs | 10 | 100.0 | 0.000524 | 100.0 | |
| 100 µs ≤ e < 1 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 ms ≤ e < 10 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 ms ≤ e < 100 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 ms ≤ e < 1 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 s ≤ e < 10 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 s ≤ e < 100 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 s ≤ e < 1.000 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1.000 s ≤ e < ∞ | 0 | 0.0 | 0.000000 | 0.0 |
SQL*Net message to client2 occurrences · 0.000 s
| Duration bucket | Occurrences | % occ. | Duration (s) | % duration | |
|---|---|---|---|---|---|
| 0 ≤ e < 1 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 µs ≤ e < 10 µs | 2 | 100.0 | 0.000007 | 100.0 | |
| 10 µs ≤ e < 100 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 µs ≤ e < 1 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 ms ≤ e < 10 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 ms ≤ e < 100 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 ms ≤ e < 1 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 s ≤ e < 10 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 s ≤ e < 100 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 s ≤ e < 1.000 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1.000 s ≤ e < ∞ | 0 | 0.0 | 0.000000 | 0.0 |
PARSE (call duration e)180,117 occurrences · 5.156 s
| Duration bucket | Occurrences | % occ. | Duration (s) | % duration | |
|---|---|---|---|---|---|
| 0 ≤ e < 1 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 µs ≤ e < 10 µs | 5 | 0.0 | 0.000035 | 0.0 | |
| 10 µs ≤ e < 100 µs | 178,111 | 98.9 | 3.000978 | 58.2 | |
| 100 µs ≤ e < 1 ms | 1,275 | 0.7 | 1.125226 | 21.8 | |
| 1 ms ≤ e < 10 ms | 722 | 0.4 | 0.910699 | 17.7 | |
| 10 ms ≤ e < 100 ms | 4 | 0.0 | 0.118877 | 2.3 | |
| 100 ms ≤ e < 1 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 s ≤ e < 10 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 s ≤ e < 100 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 s ≤ e < 1.000 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1.000 s ≤ e < ∞ | 0 | 0.0 | 0.000000 | 0.0 |
FETCH (call duration e)178,460 occurrences · 4.726 s
| Duration bucket | Occurrences | % occ. | Duration (s) | % duration | |
|---|---|---|---|---|---|
| 0 ≤ e < 1 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 µs ≤ e < 10 µs | 78 | 0.0 | 0.000438 | 0.0 | |
| 10 µs ≤ e < 100 µs | 178,059 | 99.8 | 4.514086 | 95.5 | |
| 100 µs ≤ e < 1 ms | 303 | 0.2 | 0.048463 | 1.0 | |
| 1 ms ≤ e < 10 ms | 14 | 0.0 | 0.062255 | 1.3 | |
| 10 ms ≤ e < 100 ms | 6 | 0.0 | 0.100307 | 2.1 | |
| 100 ms ≤ e < 1 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 s ≤ e < 10 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 s ≤ e < 100 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 s ≤ e < 1.000 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1.000 s ≤ e < ∞ | 0 | 0.0 | 0.000000 | 0.0 |
EXEC (call duration e)180,269 occurrences · 3.245 s
| Duration bucket | Occurrences | % occ. | Duration (s) | % duration | |
|---|---|---|---|---|---|
| 0 ≤ e < 1 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 µs ≤ e < 10 µs | 118,350 | 65.7 | 0.977253 | 30.1 | |
| 10 µs ≤ e < 100 µs | 59,907 | 33.2 | 0.785548 | 24.2 | |
| 100 µs ≤ e < 1 ms | 1,991 | 1.1 | 0.262669 | 8.1 | |
| 1 ms ≤ e < 10 ms | 16 | 0.0 | 0.046673 | 1.4 | |
| 10 ms ≤ e < 100 ms | 4 | 0.0 | 0.155844 | 4.8 | |
| 100 ms ≤ e < 1 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 s ≤ e < 10 s | 1 | 0.0 | 1.017115 | 31.3 | |
| 10 s ≤ e < 100 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 s ≤ e < 1.000 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1.000 s ≤ e < ∞ | 0 | 0.0 | 0.000000 | 0.0 |
CLOSE (call duration e)180,268 occurrences · 0.250 s
| Duration bucket | Occurrences | % occ. | Duration (s) | % duration | |
|---|---|---|---|---|---|
| 0 ≤ e < 1 µs | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 µs ≤ e < 10 µs | 179,926 | 99.8 | 0.240244 | 96.0 | |
| 10 µs ≤ e < 100 µs | 338 | 0.2 | 0.008739 | 3.5 | |
| 100 µs ≤ e < 1 ms | 4 | 0.0 | 0.001227 | 0.5 | |
| 1 ms ≤ e < 10 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 ms ≤ e < 100 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 ms ≤ e < 1 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 s ≤ e < 10 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 10 s ≤ e < 100 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 s ≤ e < 1.000 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1.000 s ≤ e < ∞ | 0 | 0.0 | 0.000000 | 0.0 |
Reads
reads (disk buckets)20,299 occurrences · 1.213 s
| Duration bucket | Occurrences | % occ. | Duration (s) | % duration | |
|---|---|---|---|---|---|
| 0 ≤ e < 5 ms | 20,208 | 99.6 | 0.269748 | 22.2 | |
| 5 ms ≤ e < 10 ms | 59 | 0.3 | 0.440318 | 36.3 | |
| 10 ms ≤ e < 15 ms | 17 | 0.1 | 0.200554 | 16.5 | |
| 15 ms ≤ e < 20 ms | 10 | 0.0 | 0.171484 | 14.1 | |
| 20 ms ≤ e < 25 ms | 3 | 0.0 | 0.067689 | 5.6 | |
| 25 ms ≤ e < 50 ms | 2 | 0.0 | 0.062981 | 5.2 | |
| 50 ms ≤ e < 100 ms | 0 | 0.0 | 0.000000 | 0.0 | |
| 100 ms ≤ e < 1 s | 0 | 0.0 | 0.000000 | 0.0 | |
| 1 s ≤ e < ∞ | 0 | 0.0 | 0.000000 | 0.0 |
reads (SSD buckets)20,299 occurrences · 1.213 s
| Duration bucket | Occurrences | % occ. | Duration (s) | % duration | |
|---|---|---|---|---|---|
| 0 ≤ e < 15 µs | 19,496 | 96.0 | 0.126062 | 10.4 | |
| 15 µs ≤ e < 25 µs | 295 | 1.5 | 0.005464 | 0.5 | |
| 25 µs ≤ e < 50 µs | 209 | 1.0 | 0.006839 | 0.6 | |
| 50 µs ≤ e < 100 µs | 43 | 0.2 | 0.002885 | 0.2 | |
| 100 µs ≤ e < 500 µs | 93 | 0.5 | 0.031763 | 2.6 | |
| 500 µs ≤ e < 1 ms | 48 | 0.2 | 0.032128 | 2.6 | |
| 1 ms ≤ e < 10 ms | 83 | 0.4 | 0.504925 | 41.6 | |
| 10 ms ≤ e < ∞ | 32 | 0.2 | 0.502708 | 41.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.
| Event | Distinct blocks | 1st read | 1st read (s) | Rereads | Rereads (s) |
|---|---|---|---|---|---|
| db file sequential read | 1,956 | 1,956 | 1.048 | 6 | 0.000 |
| local write wait | 0 | 0 | 0.000 | 3 | 0.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# | Name | Wait (s) | Occurrences | Top events |
|---|---|---|---|---|
| 188047 | IDX_0001 | 0.931 | 1,877 | db file sequential read · Disk file operations I/O |
| 187750 | 0.165 | 18,336 | direct path read | |
| 1008999 | TAB_0005 | 0.023 | 17 | enq: RO - fast object reuse · local write wait · reliable message |
| 226 | IDL_CHAR$ | 0.017 | 1 | db file sequential read |
| 107 | I_DEPENDENCY2 | 0.016 | 1 | db file sequential read |
| 227 | IDL_UB2$ | 0.016 | 1 | db file sequential read |
| 427 | IDX_0012 | 0.010 | 1 | db file sequential read |
| 228 | IDL_SB4$ | 0.009 | 1 | db file sequential read |
| 31 | CDEF$ | 0.008 | 2 | db file sequential read |
| 19 | IND$ | 0.008 | 3 | db file sequential read |
| 237 | I_IDL_CHAR1 | 0.007 | 1 | db file sequential read |
| 236 | I_IDL_UB11 | 0.007 | 1 | db file sequential read |
| 187694 | 0.006 | 49 | db file sequential read | |
| 40 | I_OBJ5 | 0.005 | 1 | db file sequential read |
| 225 | IDL_UB1$ | 0.004 | 1 | db file sequential read |
| 464 | IDX_0008 | 0.003 | 1 | db file sequential read |
| 384 | 0.001 | 4 | SQL*Net message from client · SQL*Net message to client | |
| 650598 | 0.000 | 2 | db file sequential read · Disk file operations I/O | |
| 187749 | TAB_0002 | 0.000 | 2 | db file sequential read |
| 239 | I_IDL_SB41 | 0.000 | 1 | db file sequential read |
| 3 | I_OBJ# | 0.000 | 1 | db file sequential read |
| 54 | I_CDEF2 | 0.000 | 2 | db file sequential read |
| 18 | OBJ$ | 0.000 | 2 | db file sequential read |
| 187751 | 0.000 | 2 | db file sequential read · direct path read | |
| 462 | IDX_0007 | 0.000 | 1 | db file sequential read |
| 188088 | IDX_0002 | 0.000 | 1 | db file sequential read |
| 39 | I_OBJ4 | 0.000 | 1 | db file sequential read |
| 238 | I_IDL_UB21 | 0.000 | 1 | db file sequential read |
| 9 | I_FILE#_BLOCK# | 0.000 | 1 | db file sequential read |
| 57 | I_CCOL1 | 0.000 | 1 | db 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.
| Texts | PARSE | PARSE (s) | Total (s) | SQL IDs | Example |
|---|---|---|---|---|---|
| 49 | 89,112 | 1.568 | 4.941 | hidden by the mask | #1 SELECT (SELECT COL_0073 FROM TAB_0005 WHERE COL_0074 = :n AND ROWNUM <=:n) AS COL_0073 FROM DUAL |
| 49 | 89,112 | 1.573 | 4.842 | hidden by the mask | #2 SELECT (SELECT COL_0075 FROM TAB_0005 WHERE COL_0074 = :n AND ROWNUM <=:n) AS COL_0075 FROM DUAL |
| 1,217 | 1,217 | 1.295 | 1.451 | hidden by the mask | #3 INSERT INTO TAB_0001 (COL_0076,COL_0077, … NULL,NULL,:s,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:s,NULL,NULL,NULL,NULL… |
| 350 | 350 | 0.373 | 0.417 | hidden by the mask | #8 INSERT INTO TAB_0001 (COL_0076,COL_0077, … :s,:s,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL… |
| 251 | 251 | 0.256 | 0.288 | hidden by the mask | #9 INSERT INTO TAB_0001 (COL_0076,COL_0077, … NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,… |
| 2 | 3 | 0.000 | 0.000 | hidden by the mask | #60 select SYS_CONTEXT(:s,:s) from dual |
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
- Trace period and large time gaps: Summary, Period
- In a collection, whether all files arrived: Collection, files and sessions
- Calls separated by gaps: Longest depth-0 calls
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
- Hard parses: Call types, PARSE row: Count and Misses
- Statements that differ only in literals: Shareable texts
- A PARSE for every EXEC: statement detail, Calls: PARSE against EXEC
- Statements that used the most CPU in this call: Top statements by component, this call's group
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 by call type: Call types
- Statements with the most logical reads: SQL statements, LIO and Rows columns
- Statements that used the most CPU in this call: Top statements by component, this call's group
- Plan operations with a high self LIO: statement detail, Execution plan: highlighted operations
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
- CPU by call type: Call types
- Statements with the most logical reads: SQL statements, LIO and Rows columns
- Statements that used the most CPU in this call: Top statements by component, this call's group
- Child statements of the PL/SQL blocks: statement detail, Recursive SQL
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
- How many reads and how long each one lasts: Profile, this component's row: Occurrences and Avg (s) columns
- Slow reads, or many fast reads: Latency distribution, this event's table
- Most-read objects: Objects with the most wait time
- Rereads of the same blocks: Reads, first read and reread of the same block
- Statements that read the most: Top statements by component, this event's group
- Plan operations that read too many blocks: statement detail, Execution plan: highlighted operations
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
- CPU by call type: Call types
- Statements with the most logical reads: SQL statements, LIO and Rows columns
- Statements that used the most CPU in this call: Top statements by component, this call's group
- Child statements of the PL/SQL blocks: statement detail, Recursive SQL
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
- Statements that read the most: Top statements by component, this event's group
- TABLE ACCESS FULL operations and how many times they ran: statement detail, Execution plan: Exec column
- Most-read objects: Objects with the most wait time
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
- Calls where time goes missing (duration well above CPU plus waits): Longest depth-0 calls
- Statements that carry the most of this time: Top statements by component, this event's group
- Server CPU load and free memory over the period, outside the report
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
- How many occurrences: Profile, this component's row: Occurrences column
- Statements that waited the most: Top statements by component, this event's group
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
- Which I/O events weigh: By wait class, this class's row: Top components column
- Slow reads, or many fast reads: Latency distribution
- Most-read objects: Objects with the most wait time
- Statements that read the most: Top statements by class, this class's group
- Plan operations that read too many blocks: statement detail, Execution plan: highlighted operations
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
- How many round trips there were and how long each one lasts: Profile, this component's row: Occurrences and Avg (s) columns
- Many short waits or a few long ones: Latency distribution, this event's table
- FETCH calls that bring few rows each: Call types, FETCH row: Count and Rows
- Statements that waited the most for the application: Top statements by component, this event's group
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
- Statements that waited the most: Top statements by component, this event's group
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
- How many occurrences and how long each one lasts: Profile, this component's row: Occurrences and Avg (s) columns
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
- Average and maximum per wait: Profile, this component's row: Avg (s) and Max (s) columns
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
- The two unaccounted-for time components and the card of each one: Response time profile
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
- CPU by call type: Call types
- Statements with the most logical reads: SQL statements, LIO and Rows columns
- Statements that used the most CPU: Top statements by class, this class's group
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
- Which events weigh: By wait class, this class's row: Top components column
- Contended objects: Objects with the most wait time
- Statements that were blocked: Top statements by class, this class's group
- Who holds the lock: v$session.blocking_session, in the database
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
- How many round trips there were: Summary, Database calls and Waits
- FETCH calls that bring few rows each: Call types, FETCH row: Count and Rows
- Statements that waited the most for the application: Top statements by class, this class's group
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
- Which event weighs: By wait class, this class's row: Top components column
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
- Which events of the class weigh (more data, dblink): By wait class, this class's row: Top components column
- Rows per FETCH: Call types, FETCH row: Count and Rows
- Statements that used the network the most: Top statements by class, this class's group
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
#1 · SELECT
49 variantsText
SELECT (SELECT COL_0073 FROM TAB_00051 WHERE COL_0074 = :n AND ROWNUM <=:n) AS COL_0073 FROM DUAL
- 1 TAB_0005: plan operation 2
Shape text: the literals became :s (text) and :n (number).
Variants that cost the most
| Calls | Inclusive (s) | Literals |
|---|---|---|
| 7,276 | 0.144 | ***, *** |
| 7,272 | 0.120 | ***, *** |
| 7,276 | 0.110 | ***, *** |
| 7,272 | 0.107 | ***, *** |
| 7,276 | 0.107 | ***, *** |
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 2.239668 | 45.3 | 89,112 | |
| cpu | 1.558749 | 31.5 | 89,112 | |
| cpu | 0.903868 | 18.3 | 89,112 | |
| cpu | 0.123982 | 2.5 | 89,112 | |
| unaccounted-for | 0.114630 | 2.3 | 356,448 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 89,112 | 1.558749 | 1.567573 | 0 | 0 | 0 | 0 | 49 |
| EXEC | 89,112 | 0.903868 | 0.922604 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 89,112 | 2.239668 | 2.327062 | 0 | 445,560 | 0 | 89,112 | 0 |
| CLOSE | 89,112 | 0.123982 | 0.123658 | 0 | 0 | 0 | 0 | 0 |
Execution plan 3212480556
From the STAT lines in the trace; plan written 89115 times, showing the slowest recording.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · TABLE ACCESS FULL TAB_0005 86.5% of time · 100.0% of logical reads
Reads the whole object: check whether the filter is selective and has an index.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 0.000004 | 10.8 | 0 | 0.0 | 0 | 0 | 0.000036 | 5 | ||||||
| 2 | 1 | 1 | 1 | 0.000032 | 86.5 | 5 | 100.0 | 0 | 0 | 0.000032 | 5 | 3 | 1008999 | ||
| 3 | FAST DUAL | 1 | 1 | 0.000001 | 2.7 | 0 | 0.0 | 0 | 0 | 0.000001 | 0 | 2 |
Stop after N rows
COUNT STOPKEY
Stops reading after N rows (ROWNUM <= N or FETCH FIRST).
- Good when
- Stops work early when rows already arrive in the right order.
- Bad when
- When there is a full sort below: everything is read before the cutoff.
- In the plan, check
- Rows from the operations below.
Full table scan
TABLE ACCESS FULL
Reads every block of the segment up to the high water mark (HWM), with multiblock reads (db file scattered read, or direct path read for direct reads).
- Good when
- The query needs a large share of the rows, the table is small, or the read is a batch one. On Exadata (STORAGE FULL) the filter runs in the storage cells (smart scan).
- Bad when
- The predicate is selective and few rows remain: the cost grows with the segment size, not with the result. Worse as the inner of a NESTED LOOPS: the full scan repeats for every outer row.
- In the plan, check
- High self LIO with few Rows returned: selective predicate without a useful index. Exec above 1: repeated full scan.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#2 · SELECT
49 variantsText
SELECT (SELECT COL_0075 FROM TAB_00051 WHERE COL_0074 = :n AND ROWNUM <=:n) AS COL_0075 FROM DUAL
- 1 TAB_0005: plan operation 2
Shape text: the literals became :s (text) and :n (number).
Variants that cost the most
| Calls | Inclusive (s) | Literals |
|---|---|---|
| 7,272 | 0.109 | ***, *** |
| 7,276 | 0.106 | ***, *** |
| 7,276 | 0.103 | ***, *** |
| 7,272 | 0.103 | ***, *** |
| 7,276 | 0.102 | ***, *** |
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 2.287639 | 47.2 | 89,112 | |
| cpu | 1.626753 | 33.6 | 89,112 | |
| cpu | 0.864872 | 17.9 | 89,112 | |
| cpu | 0.130972 | 2.7 | 89,112 | |
| unaccounted-for | -0.067789 | -1.4 | 356,448 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 89,112 | 1.626753 | 1.573453 | 0 | 0 | 0 | 0 | 49 |
| EXEC | 89,112 | 0.864872 | 0.878362 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 89,112 | 2.287639 | 2.267754 | 0 | 445,560 | 0 | 89,112 | 0 |
| CLOSE | 89,112 | 0.130972 | 0.122878 | 0 | 0 | 0 | 0 | 0 |
Execution plan 3212480556
From the STAT lines in the trace; plan written 89114 times, showing the slowest recording.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · TABLE ACCESS FULL TAB_0005 90.4% of time · 100.0% of logical reads
Reads the whole object: check whether the filter is selective and has an index.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 0.000003 | 5.8 | 0 | 0.0 | 0 | 0 | 0.000050 | 5 | ||||||
| 2 | 1 | 1 | 1 | 0.000047 | 90.4 | 5 | 100.0 | 0 | 0 | 0.000047 | 5 | 3 | 1008999 | ||
| 3 | FAST DUAL | 1 | 1 | 0.000002 | 3.8 | 0 | 0.0 | 0 | 0 | 0.000002 | 0 | 2 |
Stop after N rows
COUNT STOPKEY
Stops reading after N rows (ROWNUM <= N or FETCH FIRST).
- Good when
- Stops work early when rows already arrive in the right order.
- Bad when
- When there is a full sort below: everything is read before the cutoff.
- In the plan, check
- Rows from the operations below.
Full table scan
TABLE ACCESS FULL
Reads every block of the segment up to the high water mark (HWM), with multiblock reads (db file scattered read, or direct path read for direct reads).
- Good when
- The query needs a large share of the rows, the table is small, or the read is a batch one. On Exadata (STORAGE FULL) the filter runs in the storage cells (smart scan).
- Bad when
- The predicate is selective and few rows remain: the cost grows with the segment size, not with the result. Worse as the inner of a NESTED LOOPS: the full scan repeats for every outer row.
- In the plan, check
- High self LIO with few Rows returned: selective predicate without a useful index. Exec above 1: repeated full scan.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#3 · INSERT
1,217 variantsText
INSERT INTO TAB_0001 (COL_0076,COL_0077,COL_0078,COL_0079,COL_0080,COL_0081,COL_0082,COL_0083,COL_0084,COL_0085,COL_0086,COL_0087,COL_0088,COL_0089,COL_0090,COL_0091,COL_0092,COL_0093,COL_0094,COL_0095,COL_0096,COL_0097,COL_0098,COL_0099,COL_0100,COL_0101,COL_0102,COL_0103,COL_0104,COL_0105,COL_0106,COL_0107,COL_0108,COL_0109,COL_0110,COL_0111,COL_0112,COL_0113,COL_0114,COL_0115,COL_0116,COL_0117,COL_0118,COL_0119,COL_0003,COL_0120,COL_0121,COL_0122,COL_0123) VALUES (:s,:s,:s,:s,:s,:s,:s,:s,NULL,:s,:s,NULL,:s,NULL,NULL,NULL,:s,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:s,NULL,NULL,NULL,NULL,NULL,NULL,:s,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:s,:s,:n ,NULL,:s,:s,:n ,:s,:s,:s)
- 1 operation 1 (LOAD TABLE CONVENTIONAL) has no object of its own in the text
Shape text: the literals became :s (text) and :n (number).
Variants that cost the most
| Calls | Inclusive (s) | Literals |
|---|---|---|
| 3 | 0.006 | '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***',… |
| 3 | 0.006 | '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***',… |
| 3 | 0.005 | '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***',… |
| 3 | 0.004 | '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***',… |
| 3 | 0.004 | '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***',… |
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 1.314810 | 90.6 | 1,217 | |
| cpu | 0.152976 | 10.5 | 1,217 | |
| wait | 0.002378 | 0.2 | 32 | |
| cpu | 0.000000 | 0.0 | 1,217 | |
| unaccounted-for | -0.018753 | -1.3 | 3,651 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1,217 | 1.314810 | 1.295202 | 0 | 0 | 0 | 0 | 1,217 |
| EXEC | 1,217 | 0.152976 | 0.154230 | 32 | 1,249 | 7,512 | 1,217 | 0 |
| CLOSE | 1,217 | 0.000000 | 0.001979 | 0 | 0 | 0 | 0 | 0 |
Execution plan 3212480556
From the STAT lines in the trace; plan written 1217 times, showing the slowest recording.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 0 | 0.003105 | 100.0 | 1 | 100.0 | 0 | 0 | 0.003105 | 1 |
Conventional insert
LOAD TABLE CONVENTIONAL
Inserts the rows into the table through the regular INSERT path.
- Good when
- Everyday inserts.
- Bad when
- The table's triggers, indexes and constraints add cost here; for large loads, direct-path mode (APPEND) writes faster.
- In the plan, check
- Self time (s) and the statement's waits.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#4 · PL/SQL
sql_id 9sxjs1fk1qc9ghv 2753245487Text
BEGIN ROT_0001('***',*** ); END;
Text truncated: the trace declares 42 characters.
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| wait | 0.066395 | 48.6 | 5,333 | |
| recursive | 0.063234 | 46.3 | ||
| cpu | 0.004999 | 3.7 | 1 | |
| unaccounted-for | 0.001996 | 1.5 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.010998 | 0.070229 | 8 | 24 | 0 | 0 | 1 |
Recursive SQL executed by this statement
#5 · ALTER SESSION
sql_id 68ngguy15jsj7hv 2186863143Text
alter session set events='***'
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.037654 | 93.8 | 3 | |
| cpu | 0.002000 | 5.0 | 1 | |
| wait | 0.000489 | 1.2 | 1 | |
| wait | 0.000003 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000157 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.002000 | 0.039483 | 0 | 0 | 0 | 0 | 0 |
| CLOSE | 1 | 0.000000 | 0.000014 | 0 | 0 | 0 | 0 | 0 |
#6 · ?
Text
Text not available: the cursor was opened before the trace started.
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.024934 | 93.5 | 2 | |
| cpu | 0.001000 | 3.8 | 1 | |
| wait | 0.000723 | 2.7 | 1 | |
| wait | 0.000004 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| EXEC | 1 | 0.001000 | 0.025924 | 0 | 0 | 0 | 0 | 0 |
| CLOSE | 1 | 0.000000 | 0.000010 | 0 | 0 | 0 | 0 | 0 |
#7 · DELETE
sql_id 42q0kx6suxhw2hv 2981020546Text
DELETE FROM TAB_0001
- 1 IDX_0001 does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 2)
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| wait | 0.930878 | 91.0 | 1,870 | |
| cpu | 0.130980 | 12.8 | 2 | |
| wait | 0.000354 | 0.0 | 7 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| unaccounted-for | -0.039494 | -3.9 | 6 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 2 | 0.000000 | 0.000138 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 2 | 0.130980 | 1.022574 | 1,870 | 3,740 | 0 | 0 | 0 |
| CLOSE | 2 | 0.000000 | 0.000006 | 0 | 0 | 0 | 0 | 0 |
Execution plan 2124198792
From the STAT lines in the trace; plan written 2 times, showing the last one.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · INDEX FULL SCAN IDX_0001 99.1% of time · 100.0% of logical reads
Reads the whole object: check whether the filter is selective and has an index.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 0 | 0.000050 | 0.9 | 0 | 0.0 | 0 | 0 | 0.005432 | 1,870 | ||||||
| 2 | 1 | 0 | 1 | 0.005382 | 99.1 | 1,870 | 100.0 | 0 | 0 | 0.005382 | 1,870 | 2 | 188047 |
Delete
DELETE
Deletes the rows returned by the row source below.
- Good when
- Few rows, found through an index.
- Bad when
- Too many rows; an unindexed foreign key on the child table locks the whole table.
- In the plan, check
- Rows of the row source below.
Index full scan, in order
INDEX FULL SCAN
Reads the whole index in key order, walking the leaf blocks one by one with single block reads (db file sequential read).
- Good when
- Avoids a sort: the ORDER BY or GROUP BY is on the index key.
- Bad when
- A large index read in full, block by block, when a multiblock read (INDEX FAST FULL SCAN) or selective access would be possible.
- In the plan, check
- Self LIO and Self time (s).
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#8 · INSERT
350 variantsText
INSERT INTO TAB_0001 (COL_0076,COL_0077,COL_0078,COL_0079,COL_0080,COL_0081,COL_0082,COL_0083,COL_0084,COL_0085,COL_0086,COL_0087,COL_0088,COL_0089,COL_0090,COL_0091,COL_0092,COL_0093,COL_0094,COL_0095,COL_0096,COL_0097,COL_0098,COL_0099,COL_0100,COL_0101,COL_0102,COL_0103,COL_0104,COL_0105,COL_0106,COL_0107,COL_0108,COL_0109,COL_0110,COL_0111,COL_0112,COL_0113,COL_0114,COL_0115,COL_0116,COL_0117,COL_0118,COL_0119,COL_0003,COL_0120,COL_0121,COL_0122,COL_0123) VALUES (:s,:s,:s,:s,:s,:s,:s,:s,NULL,:s,:s,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:s,:s,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:s,:s,:n ,NULL,:s,:s,:n ,:s,:s,:s)
- 1 operation 1 (LOAD TABLE CONVENTIONAL) has no object of its own in the text
Shape text: the literals became :s (text) and :n (number).
Variants that cost the most
| Calls | Inclusive (s) | Literals |
|---|---|---|
| 3 | 0.024 | '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', ***,… |
| 3 | 0.002 | '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', ***, … |
| 3 | 0.002 | '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', ***,… |
| 3 | 0.002 | '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', ***, … |
| 3 | 0.002 | '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', ***,… |
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.352953 | 84.7 | 350 | |
| cpu | 0.040994 | 9.8 | 350 | |
| recursive | 0.018535 | 4.4 | ||
| wait | 0.002529 | 0.6 | 12 | |
| cpu | 0.001000 | 0.2 | 350 | |
| unaccounted-for | 0.000606 | 0.1 | 1,050 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 350 | 0.355953 | 0.372854 | 6 | 78 | 0 | 0 | 350 |
| EXEC | 350 | 0.040994 | 0.043200 | 12 | 358 | 2,154 | 350 | 0 |
| CLOSE | 350 | 0.001000 | 0.000563 | 0 | 0 | 0 | 0 | 0 |
Execution plan 3212480556
From the STAT lines in the trace; plan written 350 times, showing the slowest recording.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 0 | 0.000904 | 100.0 | 1 | 100.0 | 4 | 0 | 0.000904 | 1 |
Conventional insert
LOAD TABLE CONVENTIONAL
Inserts the rows into the table through the regular INSERT path.
- Good when
- Everyday inserts.
- Bad when
- The table's triggers, indexes and constraints add cost here; for large loads, direct-path mode (APPEND) writes faster.
- In the plan, check
- Self time (s) and the statement's waits.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
Recursive SQL executed by this statement
#9 · INSERT
251 variantsText
INSERT INTO TAB_0001 (COL_0076,COL_0077,COL_0078,COL_0079,COL_0080,COL_0081,COL_0082,COL_0083,COL_0084,COL_0085,COL_0086,COL_0087,COL_0088,COL_0089,COL_0090,COL_0091,COL_0092,COL_0093,COL_0094,COL_0095,COL_0096,COL_0097,COL_0098,COL_0099,COL_0100,COL_0101,COL_0102,COL_0103,COL_0104,COL_0105,COL_0106,COL_0107,COL_0108,COL_0109,COL_0110,COL_0111,COL_0112,COL_0113,COL_0114,COL_0115,COL_0116,COL_0117,COL_0118,COL_0119,COL_0003,COL_0120,COL_0121,COL_0122,COL_0123) VALUES (:s,:s,:s,:s,:s,:s,:s,:s,NULL,:s,:s,NULL,:s,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:s,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:s,:s,:n ,NULL,:s,:s,:n ,:s,:s,:s)
- 1 operation 1 (LOAD TABLE CONVENTIONAL) has no object of its own in the text
Shape text: the literals became :s (text) and :n (number).
Variants that cost the most
| Calls | Inclusive (s) | Literals |
|---|---|---|
| 3 | 0.003 | '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***'… |
| 3 | 0.003 | '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***'… |
| 3 | 0.002 | '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***'… |
| 3 | 0.002 | '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***'… |
| 3 | 0.002 | '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***', '***'… |
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.253971 | 88.3 | 251 | |
| cpu | 0.034992 | 12.2 | 251 | |
| wait | 0.000954 | 0.3 | 5 | |
| cpu | 0.000000 | 0.0 | 251 | |
| unaccounted-for | -0.002291 | -0.8 | 753 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 251 | 0.253971 | 0.256408 | 0 | 0 | 0 | 0 | 251 |
| EXEC | 251 | 0.034992 | 0.030809 | 5 | 256 | 1,544 | 251 | 0 |
| CLOSE | 251 | 0.000000 | 0.000409 | 0 | 0 | 0 | 0 | 0 |
Execution plan 3212480556
From the STAT lines in the trace; plan written 251 times, showing the slowest recording.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 0 | 0.000646 | 100.0 | 2 | 100.0 | 1 | 0 | 0.000646 | 2 |
Conventional insert
LOAD TABLE CONVENTIONAL
Inserts the rows into the table through the regular INSERT path.
- Good when
- Everyday inserts.
- Bad when
- The table's triggers, indexes and constraints add cost here; for large loads, direct-path mode (APPEND) writes faster.
- In the plan, check
- Self time (s) and the statement's waits.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#10 · TRUNCATE TABLE
sql_id 9y5d9x2wwc9nnhv 3116770964Text
TRUNCATE TABLE TAB_0005
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| recursive | 0.040612 | 49.5 | ||
| wait | 0.014392 | 17.6 | 1 | |
| cpu | 0.008999 | 11.0 | 1 | |
| cpu | 0.008998 | 11.0 | 1 | |
| wait | 0.008094 | 9.9 | 3 | |
| wait | 0.000616 | 0.8 | 3 | |
| wait | 0.000162 | 0.2 | 7 | |
| wait | 0.000082 | 0.1 | 1 | |
| unaccounted-for | 0.000023 | 0.0 | 3 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.013998 | 0.013202 | 3 | 18 | 1 | 0 | 1 |
| EXEC | 1 | 0.024996 | 0.068773 | 14 | 44 | 47 | 0 | 0 |
| CLOSE | 1 | 0.000000 | 0.000003 | 0 | 0 | 0 | 0 | 0 |
Recursive SQL executed by this statement
#11 · SELECT
sql_id 2vb5a3dnk45pjhv 1763841713Text
SELECT COL_0066 FROM ALL_TAB_COLUMNS WHERE OWNER = '***' AND COL_0063 = :B2 AND COL_0067 = :B1
- 1 IDX_0012 does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 28)
- 2 OBJ$ (table of index I_OBJ5) does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 22)
- 3 COLTYPE$ does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 25)
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| wait | 0.015414 | 50.8 | 4 | |
| cpu | 0.010998 | 36.2 | 50 | |
| cpu | 0.009998 | 32.9 | 50 | |
| cpu | 0.000000 | 0.0 | 50 | |
| cpu | 0.000000 | 0.0 | 1 | |
| unaccounted-for | -0.006045 | -19.9 | 151 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000019 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 50 | 0.010998 | 0.007154 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 50 | 0.009998 | 0.023110 | 4 | 1,000 | 0 | 50 | 0 |
| CLOSE | 50 | 0.000000 | 0.000082 | 0 | 0 | 0 | 0 | 0 |
Execution plan 2802916940
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 28 · INDEX RANGE SCAN IDX_0012 63.4% of time · 10.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 2 Id 22 · INDEX RANGE SCAN I_OBJ5 34.3% of time · 15.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 3 Id 25 · TABLE ACCESS CLUSTER COLTYPE$ 0.1% of time · 15.0% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | 18 | |||
| 2 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 2 | 36 | |||
| 3 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | 18 | |||
| 4 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 2 | 36 | |||
| 5 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | 18 | |||
| 6 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 2 | 36 | |||
| 7 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | 18 | |||
| 8 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 2 | 36 | |||
| 9 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | 18 | |||
| 10 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 2 | 36 | |||
| 11 | 1 | 0.000061 | 0.4 | 0 | 0.0 | 4 | 0 | 0.015885 | 20 | ||||||
| 12 | 1 | 1 | 0.000006 | 0.0 | 0 | 0.0 | 4 | 0 | 0.015802 | 16 | 11 | ||||
| 13 | 1 | 1 | 0.000003 | 0.0 | 0 | 0.0 | 4 | 0 | 0.015783 | 15 | 10 | ||||
| 14 | 1 | 1 | 0.000005 | 0.0 | 0 | 0.0 | 4 | 0 | 0.015776 | 15 | 9 | ||||
| 15 | 1 | 1 | 0.000003 | 0.0 | 0 | 0.0 | 3 | 0 | 0.005692 | 13 | 8 | ||||
| 16 | 1 | 1 | 0.000004 | 0.0 | 0 | 0.0 | 3 | 0 | 0.005685 | 13 | 6 | ||||
| 17 | 1 | 1 | 0.000005 | 0.0 | 0 | 0.0 | 3 | 0 | 0.005668 | 10 | 5 | ||||
| 18 | 1 | 1 | 0.000002 | 0.0 | 0 | 0.0 | 2 | 0 | 0.005589 | 6 | 4 | ||||
| 19 | 1 | 1 | 0.000005 | 0.0 | 1 | 5.0 | 0 | 0 | 0.000012 | 2 | 1 | 22 | |||
| 20 | 1 | 1 | 0.000007 | 0.0 | 1 | 5.0 | 0 | 0 | 0.000007 | 1 | 0 | 46 | |||
| 21 | 1 | 1 | 0.000119 | 0.7 | 1 | 5.0 | 2 | 0 | 0.005575 | 4 | 3 | 18 | |||
| 22 | 2 | 1 | 1 | 0.005456 | 34.3 | 3 | 15.0 | 1 | 0 | 0.005456 | 3 | 2 | 40 | ||
| 23 | 1 | 1 | 0.000065 | 0.4 | 2 | 10.0 | 1 | 0 | 0.000074 | 4 | 1 | 21 | |||
| 24 | 1 | 1 | 0.000009 | 0.1 | 2 | 10.0 | 0 | 0 | 0.000009 | 2 | 0 | 3 | |||
| 25 | 3 | 0 | 1 | 0.000013 | 0.1 | 3 | 15.0 | 0 | 0 | 0.000013 | 3 | 1 | 83 | ||
| 26 | 0 | 1 | 0.000001 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000004 | 0 | 2 | 18 | |||
| 27 | 0 | 1 | 0.000003 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000003 | 0 | 1 | 38 | |||
| 28 | 1 | 1 | 1 | 0.010079 | 63.4 | 2 | 10.0 | 1 | 0 | 0.010079 | 2 | 1 | 427 | ||
| 29 | 0 | 1 | 0.000004 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000004 | 0 | 1 | 47 | |||
| 30 | 1 | 1 | 0.000013 | 0.1 | 1 | 5.0 | 0 | 0 | 0.000013 | 1 | 1 | 47 | |||
| 31 | 0 | 1 | 0.000014 | 0.1 | 2 | 10.0 | 0 | 0 | 0.000022 | 4 | 2 | 4 | |||
| 32 | 1 | 1 | 0.000008 | 0.1 | 2 | 10.0 | 0 | 0 | 0.000008 | 2 | 1 | 3 | |||
| 33 | 0 | 2 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | ||||
| 34 | 0 | 10 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | 62 | |||
| 35 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 0 | ||||
| 36 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 0 | ||||
| 37 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | ||||
| 38 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 1 | 47 | |||
| 39 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 2 | 39 |
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Filter
FILTER
Applies a predicate to the rows of the row source below. With two row sources, executes the second (a subquery that was not unnested) for each row of the first.
- Good when
- A single row source, or a subquery executed only a few times (FILTER caches the results already computed).
- Bad when
- Subquery executed row by row (high Exec on the second row source): allowing unnesting or rewriting it as a join usually solves it.
- In the plan, check
- Exec of the second row source.
Nested loops join
NESTED LOOPS
For each row of the outer (driving) row source, executes the inner row source.
- Good when
- Few rows in the outer and selective index access in the inner. Returns the first rows quickly (good for FIRST_ROWS).
- Bad when
- Many rows in the outer: the inner runs thousands of times. It usually comes from an underestimated cardinality in the outer; a HASH JOIN would read each side only once.
- In the plan, check
- Exec of the inner operations and, in the outer, Estimated compared with Rows/exec.
Unique key lookup
INDEX UNIQUE SCAN
Looks up a single key in a unique index (PK or UNIQUE): goes down from the root block through the branch blocks to the key's leaf block.
- Good when
- Almost always: it reads only the index height (BLEVEL + 1 blocks).
- Bad when
- As the inner of a NESTED LOOPS with millions of outer rows: cheap per execution, expensive in total.
- In the plan, check
- Exec: thousands of executions add up even with a low self LIO in each one.
Table access by cluster
TABLE ACCESS CLUSTER
Reads a table stored in a cluster, by the cluster key.
- Good when
- Tables that are always read together by the same key.
- Bad when
- Poorly sized cluster, with chained blocks.
Oracle internal table (X$)
FIXED TABLE
Reads an Oracle memory structure behind the V$ views.
- Good when
- Occasional queries.
- Bad when
- Frequent queries on large V$ views (V$SQL, V$SESSION) by monitoring jobs.
Index skip scan
INDEX SKIP SCAN
Uses a composite index without the leading column in the filter: scans the index once for each distinct value of the leading column.
- Good when
- The leading index column has few distinct values.
- Bad when
- The leading column has many values: it becomes almost a full index read. An index that starts with the filtered column usually solves it.
- In the plan, check
- Self LIO compared with the Rows returned.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#12 · SELECT
sql_id 5tp7ar1mxbgphhv 1742061232Text
select /*+ index(idl_char$12 i_idl_char1) +*/ piece#,length,piece from idl_char$12 where obj#=:1 and part=:2 and version=:3 order by piece#
- 1 IDL_CHAR$: plan operation 1
- 2 IDL_CHAR$, table of index I_IDL_CHAR1: plan operation 2
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| wait | 0.023874 | 97.1 | 2 | |
| cpu | 0.001000 | 4.1 | 2 | |
| cpu | 0.000999 | 4.1 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| unaccounted-for | -0.001279 | -5.2 | 5 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000061 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000999 | 0.000318 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 2 | 0.001000 | 0.024202 | 2 | 4 | 0 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000013 | 0 | 0 | 0 | 0 | 0 |
Execution plan 1319326155
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 1 · TABLE ACCESS BY INDEX ROWID IDL_CHAR$ 71.1% of time · 33.3% of logical reads
Visits the table row by row from the index: unselective index or missing the columns the filter uses. - 2 Id 2 · INDEX RANGE SCAN I_IDL_CHAR1 28.9% of time · 66.7% of logical reads
Scans a wide range of the index: check the selectivity and the column order.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 1 | 1 | 0.017191 | 71.1 | 1 | 33.3 | 2 | 0 | 0.024172 | 3 | 3 | 226 | ||
| 2 | 2 | 1 | 1 | 0.006981 | 28.9 | 2 | 66.7 | 1 | 0 | 0.006981 | 2 | 2 | 237 |
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#13 · SELECT
sql_id 6q9x9bmh733r2hv 3765538530Text
select i.obj#,i.ts#,i.file#,i.block#,i.intcols,i.type#,i.flags,i.property,i.pctfree$,i.initrans,i.maxtrans,i.blevel,i.leafcnt,i.distkey,i.lblkkey,i.dblkkey,i.clufac,i.cols,i.analyzetime,i.samplesize,i.dataobj#,nvl(i.degree,***),nvl(i.instances,***),i.rowcnt,mod(i.pctthres$,***),i.COL_0011,i.trunccnt,nvl(c.unicols,***),nvl(c.COL_0012+c.COL_0013,***),nvl(i.spare1,i.intcols),i.spare4,i.spare2,i.spare6,decode(i.pctthres$,null,null,mod(trunc(i.pctthres$/***),***)),ist.cachedblk,ist.cachehit,ist.logicalread from ind$23 i, ind_stats$ ist, (select enabled, min(cols) unicols,min(to_number(bitand(defer,***))) COL_0012,min(to_number(bitand(defer,***))) COL_0013 from cdef$1 where obj#=:1 and enabled > *** group by enabled) c where i.obj#=c.enabled(+) and i.obj# = ist.obj#(+) and i.bo#=:1 order by i.obj#
- 1 CDEF$: plan operation 10
- 2 IND$: plan operation 4
- 3 IND$, table of index I_OBJ#: plan operation 5
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| wait | 0.015645 | 87.9 | 7 | |
| cpu | 0.002000 | 11.2 | 3 | |
| cpu | 0.001000 | 5.6 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| unaccounted-for | -0.000843 | -4.7 | 9 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 2 | 0.000000 | 0.000122 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 2 | 0.001000 | 0.000487 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 3 | 0.002000 | 0.017187 | 7 | 12 | 0 | 1 | 0 |
| CLOSE | 2 | 0.000000 | 0.000006 | 0 | 0 | 0 | 0 | 0 |
Execution plan 3992920156
From the STAT lines in the trace; plan written 2 times, showing the last one.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 10 · TABLE ACCESS BY INDEX ROWID CDEF$ 48.3% of time · 22.2% of logical reads
Visits the table row by row from the index: unselective index or missing the columns the filter uses. - 2 Id 4 · TABLE ACCESS CLUSTER IND$ 47.3% of time · 22.2% of logical reads
- 3 Id 5 · INDEX UNIQUE SCAN I_OBJ# 0.1% of time · 22.2% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 2 | 0.000033 | 0.2 | 0 | 0.0 | 5 | 0 | 0.016567 | 9 | 7 | ||||
| 2 | 1 | 2 | 0.000571 | 3.4 | 0 | 0.0 | 5 | 0 | 0.016534 | 9 | 6 | ||||
| 3 | 1 | 2 | 0.000007 | 0.0 | 0 | 0.0 | 2 | 0 | 0.007862 | 5 | 2 | ||||
| 4 | 2 | 1 | 2 | 0.007832 | 47.3 | 2 | 22.2 | 2 | 0 | 0.007846 | 4 | 2 | 19 | ||
| 5 | 3 | 1 | 1 | 0.000014 | 0.1 | 2 | 22.2 | 0 | 0 | 0.000014 | 2 | 1 | 3 | ||
| 6 | 0 | 1 | 0.000002 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000009 | 1 | 0 | 432 | |||
| 7 | 0 | 1 | 0.000007 | 0.0 | 1 | 11.1 | 0 | 0 | 0.000007 | 1 | 0 | 433 | |||
| 8 | 1 | 1 | 0.000004 | 0.0 | 0 | 0.0 | 3 | 0 | 0.008101 | 4 | 3 | ||||
| 9 | 1 | 1 | 0.000044 | 0.3 | 0 | 0.0 | 3 | 0 | 0.008097 | 4 | 3 | ||||
| 10 | 1 | 1 | 1 | 0.008001 | 48.3 | 2 | 22.2 | 3 | 0 | 0.008053 | 4 | 2 | 31 | ||
| 11 | 5 | 4 | 0.000052 | 0.3 | 2 | 22.2 | 1 | 0 | 0.000052 | 2 | 1 | 54 |
Sort (ORDER BY)
SORT ORDER BY
Sorts the rows for the ORDER BY.
- Good when
- Few rows, in-memory sort.
- Bad when
- Many rows: the sort does not fit in the workarea and writes to TEMP. An index in the requested order can avoid the SORT, especially with ROWNUM or FETCH FIRST.
- In the plan, check
- PW above zero and Self time (s).
Hash join
HASH JOIN
Builds a hash table in the PGA from the first row source (build input, the smaller one) and reads the second (probe input) looking for matches.
- Good when
- Joining many rows with no useful index: each side is read only once.
- Bad when
- The build input is large and does not fit in the PGA workarea: the join goes one-pass or multipass and writes to TEMP. Or a few rows would be enough and a NESTED LOOPS with an index would be cheaper.
- In the plan, check
- PW above zero (writes to TEMP), Self time (s) and the Rows of the build input.
Nested loops join
NESTED LOOPS
For each row of the outer (driving) row source, executes the inner row source.
- Good when
- Few rows in the outer and selective index access in the inner. Returns the first rows quickly (good for FIRST_ROWS).
- Bad when
- Many rows in the outer: the inner runs thousands of times. It usually comes from an underestimated cardinality in the outer; a HASH JOIN would read each side only once.
- In the plan, check
- Exec of the inner operations and, in the outer, Estimated compared with Rows/exec.
Table access by cluster
TABLE ACCESS CLUSTER
Reads a table stored in a cluster, by the cluster key.
- Good when
- Tables that are always read together by the same key.
- Bad when
- Poorly sized cluster, with chained blocks.
Unique key lookup
INDEX UNIQUE SCAN
Looks up a single key in a unique index (PK or UNIQUE): goes down from the root block through the branch blocks to the key's leaf block.
- Good when
- Almost always: it reads only the index height (BLEVEL + 1 blocks).
- Bad when
- As the inner of a NESTED LOOPS with millions of outer rows: cheap per execution, expensive in total.
- In the plan, check
- Exec: thousands of executions add up even with a low self LIO in each one.
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
View or subquery
VIEW
Result of a view or subquery used as a row source by the operation above.
- Good when
- No cost of its own: the work is in the operations below.
- Bad when
- When it keeps the outer filter from being pushed into the view and the whole view is read.
- In the plan, check
- The operations below.
Sort grouping
SORT GROUP BY
Groups the rows for GROUP BY by sorting on the group key.
- Good when
- Few rows, or the result must come out sorted.
- Bad when
- Many rows, writing to TEMP.
- In the plan, check
- PW and Self time (s).
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#14 · SELECT
sql_id 7d78xc7z6vr4fhv 4268612750Text
select o.owner#, o.name, o.namespace, o.obj#, d.COL_0051, nvl(d.property,***), o.type#, o.subname, d.d_attrs from dependency$1 d, obj$ o where d.COL_0052=:1 and (d.p_timestamp=nvl(:2,d.p_timestamp) or d.property=***) and o.owner#=nvl(:3,o.owner#) and d.COL_0053=o.obj# order by o.obj#
- 1 DEPENDENCY$, table of index I_DEPENDENCY2: plan operation 7
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| wait | 0.016134 | 96.4 | 1 | |
| unaccounted-for | 0.000609 | 3.6 | 8 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 2 | 0.000000 | 0.000054 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 2 | 0.000000 | 0.000403 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 2 | 0.000000 | 0.016270 | 1 | 6 | 0 | 0 | 0 |
| CLOSE | 2 | 0.000000 | 0.000016 | 0 | 0 | 0 | 0 | 0 |
Execution plan 3014793611
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 7 · INDEX RANGE SCAN I_DEPENDENCY2 99.7% of time · 100.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 0 | 2 | 0.000017 | 0.1 | 0 | 0.0 | 1 | 0 | 0.016258 | 3 | 17 | ||||
| 2 | 0 | 0.000009 | 0.1 | 0 | 0.0 | 1 | 0 | 0.016241 | 3 | ||||||
| 3 | 0 | 0.000006 | 0.0 | 0 | 0.0 | 1 | 0 | 0.016230 | 3 | ||||||
| 4 | 0 | 0.000002 | 0.0 | 0 | 0.0 | 1 | 0 | 0.016224 | 3 | ||||||
| 5 | 0 | 1 | 0.000002 | 0.0 | 0 | 0.0 | 1 | 0 | 0.016222 | 3 | 8 | ||||
| 6 | 0 | 1 | 0.000003 | 0.0 | 0 | 0.0 | 1 | 0 | 0.016220 | 3 | 6 | 104 | |||
| 7 | 1 | 0 | 5 | 0.016217 | 99.7 | 3 | 100.0 | 1 | 0 | 0.016217 | 3 | 3 | 107 | ||
| 8 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 1 | 36 | |||
| 9 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 2 | 18 | |||
| 10 | 0 | 0.000002 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000002 | 0 | ||||||
| 11 | 0 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | ||||||
| 12 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 8 | ||||
| 13 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 6 | 104 | |||
| 14 | 0 | 5 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | 107 | |||
| 15 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 1 | 36 | |||
| 16 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 2 | 18 |
Sort (ORDER BY)
SORT ORDER BY
Sorts the rows for the ORDER BY.
- Good when
- Few rows, in-memory sort.
- Bad when
- Many rows: the sort does not fit in the workarea and writes to TEMP. An index in the requested order can avoid the SORT, especially with ROWNUM or FETCH FIRST.
- In the plan, check
- PW above zero and Self time (s).
OR expansion
CONCATENATION
Each part of an OR condition became a branch, and the results are combined.
- Good when
- Each branch uses a different, selective index.
- Bad when
- Many branches repeating the same work.
- In the plan, check
- Each branch below.
Filter
FILTER
Applies a predicate to the rows of the row source below. With two row sources, executes the second (a subquery that was not unnested) for each row of the first.
- Good when
- A single row source, or a subquery executed only a few times (FILTER caches the results already computed).
- Bad when
- Subquery executed row by row (high Exec on the second row source): allowing unnesting or rewriting it as a join usually solves it.
- In the plan, check
- Exec of the second row source.
Nested loops join
NESTED LOOPS
For each row of the outer (driving) row source, executes the inner row source.
- Good when
- Few rows in the outer and selective index access in the inner. Returns the first rows quickly (good for FIRST_ROWS).
- Bad when
- Many rows in the outer: the inner runs thousands of times. It usually comes from an underestimated cardinality in the outer; a HASH JOIN would read each side only once.
- In the plan, check
- Exec of the inner operations and, in the outer, Estimated compared with Rows/exec.
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#15 · SELECT
sql_id 0myxy09ts0my0hv 1937788864Text
select /*+ index(idl_ub2$12 i_idl_ub21) +*/ piece#,length,piece from idl_ub2$12 where obj#=:1 and part=:2 and version=:3 order by piece#
- 1 IDL_UB2$: plan operation 1
- 2 IDL_UB2$, table of index I_IDL_UB21: plan operation 2
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| wait | 0.015738 | 95.5 | 2 | |
| cpu | 0.001000 | 6.1 | 2 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| unaccounted-for | -0.000262 | -1.6 | 5 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000069 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000000 | 0.000313 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 2 | 0.001000 | 0.015992 | 2 | 7 | 0 | 2 | 0 |
| CLOSE | 1 | 0.000000 | 0.000102 | 0 | 0 | 0 | 0 | 0 |
Execution plan 2317816222
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 1 · TABLE ACCESS BY INDEX ROWID IDL_UB2$ 99.3% of time · 40.0% of logical reads
Visits the table row by row from the index: unselective index or missing the columns the filter uses. - 2 Id 2 · INDEX RANGE SCAN I_IDL_UB21 0.7% of time · 60.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 2 | 1 | 0.015835 | 99.3 | 2 | 40.0 | 2 | 0 | 0.015948 | 5 | 3 | 227 | ||
| 2 | 2 | 2 | 1 | 0.000113 | 0.7 | 3 | 60.0 | 1 | 0 | 0.000113 | 3 | 2 | 238 |
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#16 · INSERT
sql_id 0uhffuxsqpvcnhv 1902833044Text
INSERT INTO TAB_0005 VALUES (:COL_0069, :COL_0070, :COL_0071, :COL_0072)
- 1 operation 1 (LOAD TABLE CONVENTIONAL) has no object of its own in the text
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.007998 | 54.9 | 50 | |
| unaccounted-for | 0.006013 | 41.2 | 101 | |
| recursive | 0.000547 | 3.8 | ||
| wait | 0.000019 | 0.1 | 2 | |
| cpu | 0.000000 | 0.0 | 50 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000236 | 0 | 0 | 0 | 0 | 1 |
| EXEC | 50 | 0.008998 | 0.014271 | 2 | 13 | 82 | 50 | 1 |
| CLOSE | 50 | 0.000000 | 0.000070 | 0 | 0 | 0 | 0 | 0 |
Execution plan 0
From the STAT lines in the trace.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 0 | 0.000489 | 100.0 | 4 | 100.0 | 2 | 0 | 0.000489 | 4 |
Conventional insert
LOAD TABLE CONVENTIONAL
Inserts the rows into the table through the regular INSERT path.
- Good when
- Everyday inserts.
- Bad when
- The table's triggers, indexes and constraints add cost here; for large loads, direct-path mode (APPEND) writes faster.
- In the plan, check
- Self time (s) and the statement's waits.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
Recursive SQL executed by this statement
#17 · SELECT
sql_id c1wyt1vcbz2vvhv 3636431739Text
SELECT COL_0068 FROM ALL_TAB_COLUMNS WHERE OWNER = '***' AND COL_0063 = :B2 AND COL_0067 = :B1
- 1 COL$ does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 13)
- 2 OBJ$ (table of index I_OBJ5) does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 12)
- 3 COLTYPE$ does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 15)
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.006999 | 50.5 | 50 | |
| cpu | 0.003999 | 28.9 | 50 | |
| unaccounted-for | 0.002849 | 20.6 | 151 | |
| cpu | 0.000000 | 0.0 | 50 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000032 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 50 | 0.006999 | 0.007635 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 50 | 0.003999 | 0.006109 | 0 | 1,000 | 0 | 50 | 0 |
| CLOSE | 50 | 0.000000 | 0.000071 | 0 | 0 | 0 | 0 | 0 |
Execution plan 2399995316
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 13 · TABLE ACCESS CLUSTER COL$ 16.9% of time · 10.0% of logical reads
- 2 Id 12 · INDEX RANGE SCAN I_OBJ5 8.1% of time · 15.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 3 Id 15 · TABLE ACCESS CLUSTER COLTYPE$ 4.7% of time · 15.0% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 0.000018 | 12.2 | 0 | 0.0 | 0 | 0 | 0.000148 | 20 | ||||||
| 2 | 1 | 1 | 0.000001 | 0.7 | 0 | 0.0 | 0 | 0 | 0.000117 | 16 | 11 | ||||
| 3 | 1 | 1 | 0.000002 | 1.4 | 0 | 0.0 | 0 | 0 | 0.000109 | 15 | 10 | ||||
| 4 | 1 | 1 | 0.000004 | 2.7 | 0 | 0.0 | 0 | 0 | 0.000105 | 15 | 9 | ||||
| 5 | 1 | 1 | 0.000001 | 0.7 | 0 | 0.0 | 0 | 0 | 0.000093 | 13 | 8 | ||||
| 6 | 1 | 1 | 0.000003 | 2.0 | 0 | 0.0 | 0 | 0 | 0.000089 | 13 | 6 | ||||
| 7 | 1 | 1 | 0.000004 | 2.7 | 0 | 0.0 | 0 | 0 | 0.000079 | 10 | 5 | ||||
| 8 | 1 | 1 | 0.000001 | 0.7 | 0 | 0.0 | 0 | 0 | 0.000045 | 6 | 4 | ||||
| 9 | 1 | 1 | 0.000005 | 3.4 | 1 | 5.0 | 0 | 0 | 0.000012 | 2 | 1 | 22 | |||
| 10 | 1 | 1 | 0.000007 | 4.7 | 1 | 5.0 | 0 | 0 | 0.000007 | 1 | 0 | 46 | |||
| 11 | 1 | 1 | 0.000020 | 13.5 | 1 | 5.0 | 0 | 0 | 0.000032 | 4 | 3 | 18 | |||
| 12 | 2 | 1 | 1 | 0.000012 | 8.1 | 3 | 15.0 | 0 | 0 | 0.000012 | 3 | 2 | 40 | ||
| 13 | 1 | 1 | 1 | 0.000025 | 16.9 | 2 | 10.0 | 0 | 0 | 0.000030 | 4 | 1 | 21 | ||
| 14 | 1 | 1 | 0.000005 | 3.4 | 2 | 10.0 | 0 | 0 | 0.000005 | 2 | 0 | 3 | |||
| 15 | 3 | 0 | 1 | 0.000007 | 4.7 | 3 | 15.0 | 0 | 0 | 0.000007 | 3 | 1 | 83 | ||
| 16 | 0 | 1 | 0.000002 | 1.4 | 0 | 0.0 | 0 | 0 | 0.000003 | 0 | 2 | 18 | |||
| 17 | 0 | 1 | 0.000001 | 0.7 | 0 | 0.0 | 0 | 0 | 0.000001 | 0 | 1 | 38 | |||
| 18 | 1 | 1 | 0.000008 | 5.4 | 2 | 10.0 | 0 | 0 | 0.000008 | 2 | 1 | 427 | |||
| 19 | 0 | 1 | 0.000002 | 1.4 | 0 | 0.0 | 0 | 0 | 0.000002 | 0 | 1 | 47 | |||
| 20 | 1 | 1 | 0.000007 | 4.7 | 1 | 5.0 | 0 | 0 | 0.000007 | 1 | 1 | 47 | |||
| 21 | 0 | 1 | 0.000010 | 6.8 | 2 | 10.0 | 0 | 0 | 0.000013 | 4 | 2 | 4 | |||
| 22 | 1 | 1 | 0.000003 | 2.0 | 2 | 10.0 | 0 | 0 | 0.000003 | 2 | 1 | 3 | |||
| 23 | 0 | 2 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | ||||
| 24 | 0 | 10 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | 62 | |||
| 25 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 0 | ||||
| 26 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 0 | ||||
| 27 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | ||||
| 28 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 1 | 47 | |||
| 29 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 2 | 39 |
Filter
FILTER
Applies a predicate to the rows of the row source below. With two row sources, executes the second (a subquery that was not unnested) for each row of the first.
- Good when
- A single row source, or a subquery executed only a few times (FILTER caches the results already computed).
- Bad when
- Subquery executed row by row (high Exec on the second row source): allowing unnesting or rewriting it as a join usually solves it.
- In the plan, check
- Exec of the second row source.
Nested loops join
NESTED LOOPS
For each row of the outer (driving) row source, executes the inner row source.
- Good when
- Few rows in the outer and selective index access in the inner. Returns the first rows quickly (good for FIRST_ROWS).
- Bad when
- Many rows in the outer: the inner runs thousands of times. It usually comes from an underestimated cardinality in the outer; a HASH JOIN would read each side only once.
- In the plan, check
- Exec of the inner operations and, in the outer, Estimated compared with Rows/exec.
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Unique key lookup
INDEX UNIQUE SCAN
Looks up a single key in a unique index (PK or UNIQUE): goes down from the root block through the branch blocks to the key's leaf block.
- Good when
- Almost always: it reads only the index height (BLEVEL + 1 blocks).
- Bad when
- As the inner of a NESTED LOOPS with millions of outer rows: cheap per execution, expensive in total.
- In the plan, check
- Exec: thousands of executions add up even with a low self LIO in each one.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Table access by cluster
TABLE ACCESS CLUSTER
Reads a table stored in a cluster, by the cluster key.
- Good when
- Tables that are always read together by the same key.
- Bad when
- Poorly sized cluster, with chained blocks.
Oracle internal table (X$)
FIXED TABLE
Reads an Oracle memory structure behind the V$ views.
- Good when
- Occasional queries.
- Bad when
- Frequent queries on large V$ views (V$SQL, V$SESSION) by monitoring jobs.
Index skip scan
INDEX SKIP SCAN
Uses a composite index without the leading column in the filter: scans the index once for each distinct value of the leading column.
- Good when
- The leading index column has few distinct values.
- Bad when
- The leading column has many values: it becomes almost a full index read. An index that starts with the filtered column usually solves it.
- In the plan, check
- Self LIO compared with the Rows returned.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#18 · SELECT
sql_id 1vybmzupqw75hhv 2876120240Text
select /*+ index(idl_ub1$12 i_idl_ub11) +*/ piece#,length,piece from idl_ub1$12 where obj#=:1 and part=:2 and version=:3 order by piece#
- 1 IDL_UB1$, table of index I_IDL_UB11: plan operation 2
- 2 IDL_UB1$: plan operation 1
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| wait | 0.011204 | 93.8 | 2 | |
| cpu | 0.001000 | 8.4 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 1 | |
| unaccounted-for | -0.000264 | -2.2 | 5 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000075 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.001000 | 0.000388 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 2 | 0.000000 | 0.011466 | 2 | 5 | 0 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000011 | 0 | 0 | 0 | 0 | 0 |
Execution plan 3246118364
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · INDEX RANGE SCAN I_IDL_UB11 59.6% of time · 75.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 2 Id 1 · TABLE ACCESS BY INDEX ROWID IDL_UB1$ 40.4% of time · 25.0% of logical reads
Visits the table row by row from the index: unselective index or missing the columns the filter uses.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 1 | 1 | 0.004617 | 40.4 | 1 | 25.0 | 2 | 0 | 0.011438 | 4 | 3 | 225 | ||
| 2 | 1 | 1 | 1 | 0.006821 | 59.6 | 3 | 75.0 | 1 | 0 | 0.006821 | 3 | 2 | 236 |
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#19 · SELECT
sql_id 7hbqw62s604unhv 2959086420Text
select /*+ index(idl_sb4$12 i_idl_sb41) +*/ piece#,length,piece from idl_sb4$12 where obj#=:1 and part=:2 and version=:3 order by piece#
- 1 IDL_SB4$: plan operation 1
- 2 IDL_SB4$, table of index I_IDL_SB41: plan operation 2
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| wait | 0.009431 | 92.2 | 2 | |
| cpu | 0.001000 | 9.8 | 1 | |
| cpu | 0.001000 | 9.8 | 3 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| unaccounted-for | -0.001207 | -11.8 | 6 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000071 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.001000 | 0.000428 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 3 | 0.001000 | 0.009712 | 2 | 8 | 0 | 2 | 0 |
| CLOSE | 1 | 0.000000 | 0.000013 | 0 | 0 | 0 | 0 | 0 |
Execution plan 1697022209
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 1 · TABLE ACCESS BY INDEX ROWID IDL_SB4$ 98.7% of time · 33.3% of logical reads
Visits the table row by row from the index: unselective index or missing the columns the filter uses. - 2 Id 2 · INDEX RANGE SCAN I_IDL_SB41 1.3% of time · 66.7% of logical reads
Scans a wide range of the index: check the selectivity and the column order.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 2 | 1 | 0.009537 | 98.7 | 2 | 33.3 | 2 | 0 | 0.009658 | 6 | 3 | 228 | ||
| 2 | 2 | 2 | 1 | 0.000121 | 1.3 | 4 | 66.7 | 1 | 0 | 0.000121 | 4 | 2 | 239 |
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#20 · SELECT
sql_id 45zgfwwy872t3hv 1015253795Text
SELECT COUNT(COL_0001) FROM TAB_0002 WHERE COL_0002 = :B2 AND TO_NUMBER(COL_0003) = :B1 AND COL_0001 <> ***
- 1 IDX_0002 does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 2)
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.005163 | 83.6 | 4 | |
| cpu | 0.001000 | 16.2 | 1 | |
| wait | 0.000013 | 0.2 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000060 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.001000 | 0.005899 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 1 | 0.000000 | 0.000214 | 1 | 2 | 0 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000003 | 0 | 0 | 0 | 0 | 0 |
Execution plan 4045997523
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · INDEX RANGE SCAN IDX_0002 100.0% of time · 100.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 1 | 0 | 0.000248 | 2 | ||||||
| 2 | 1 | 58 | 1 | 0.000348 | 100.0 | 2 | 100.0 | 1 | 0 | 0.000348 | 2 | 2 | 188088 |
Aggregation (COUNT, SUM, MAX...)
SORT AGGREGATE
Computes the aggregate functions and returns one row.
- Good when
- Cheap in itself: the cost is in the operations below.
- Bad when
- Almost never.
- In the plan, check
- The operations below it.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#21 · PL/SQL
sql_id 3u48u68wwjg3vhv 969456763Text
declare
TYPE COL_0021 IS REF CURSOR;
COL_0022 COL_0021;
COL_0023 varchar2(***);
COL_0024 varchar2(***);
COL_0025 varchar2(***);
COL_0026 varchar2(***);
COL_0027 varchar2(***);
COL_0028 varchar2(***);
COL_0029 varchar2(***);
COL_0030 varchar2(***);
COL_0031 NUMBER;
COL_0032 varchar2(***);
COL_0033 varchar2(***);
COL_0034 VARCHAR2(***);
PRAGMA AUTONOMOUS_TRANSACTION;
begin
COL_0028:='***';
execute immediate COL_0028 into COL_0027;
if(not (COL_0027='***' or COL_0027='***' or COL_0027='***' or COL_0027='***'))
then
return;
end if;
COL_0028:='***';
execute immediate COL_0028 into COL_0023;
COL_0028:='***';
execute immediate COL_0028 into COL_0024;
COL_0028:='***';
execute immediate COL_0028 into COL_0026;
COL_0028:='***';
execute immediate COL_0028 into COL_0025;
COL_0028:='***';
execute immediate COL_0028 into COL_0029;
COL_0028:='***';
execute immediate COL_0028 into COL_0034;
if (COL_0025!='***' and COL_0025!='***' and COL_0027='***' and COL_0023='***')
then
COL_0028:='***';
open COL_0022 for COL_0028 using COL_0025,COL_0029;
loop
fetch COL_0022 into COL_0030;
exit when COL_0022%NOTFOUND;
COL_0028:='***';
execute immediate COL_0028 into COL_0032 using SYS.DBMS_ASSERT.SIMPLE_SQL_NAME(COL_0030);
if (trim(COL_0032)='***')
then
COL_0028:='***';
execute immediate COL_0028 using SYS.DBMS_ASSERT.SCHEMA_NAME(COL_0025),SYS.DBMS_ASSERT.SIMPLE_SQL_NAME(COL_0029),SYS.DBMS_ASSERT.SIMPLE_SQL_NAME(COL_0030);
end if;
end loop;
end if;
if ((COL_0023='***' and COL_0027='***') or (COL_0023='***' and COL_0027='***'))
then
COL_0028:='***';
EXECUTE IMMEDIATE COL_0028;
commit;
end if;
if (COL_0023='***' and COL_0027='***')
then
COL_0028:='***';
EXECUTE IMMEDIATE COL_0028 into COL_0031 using COL_0025,COL_0029;
if(COL_0031!=***)
then
COL_0028:='***';
EXECUTE IMMEDIATE COL_0028 into COL_0031;
if((COL_0031=***)and (COL_0024!='***' and COL_0024!='***' and COL_0024!='***'and COL_0025!='***' and COL_0025!='***'))
then
COL_0028:='***';
execute immediate COL_0028;
end if;
end if;
COL_0028:='***';
EXECUTE IMMEDIATE COL_0028;
commit;
end if;
if(COL_0024='***' or COL_0024='***' or COL_0024='***'
or COL_0025='***' or COL_0025='***')
then
return;
end if;
if (COL_0023='***' and COL_0027='***')
then
COL_0028:='***';
EXECUTE IMMEDIATE COL_0028 into COL_0031 using COL_0025,COL_0029;
if(COL_0031!=***)
then
COL_0028:='***';
EXECUTE IMMEDIATE COL_0028 into COL_0031;
if(COL_0031=***)
then
COL_0028:='***';
execute immediate COL_0028;
end if;
end if;
end if;
if (COL_0027='***' and COL_0023='***')
then
COL_0028:='***';
EXECUTE IMMEDIATE COL_0028 into COL_0033 using COL_0029;
if(COL_0033 is null)
then
return;
end if;
COL_0028:='***';
EXECUTE IMMEDIATE COL_0028 into COL_0031;
if(COL_0031=***)
then
COL_0028:='***';
execute immediate COL_0028;
end if;
end if;
if (COL_0027='***' and COL_0023='***')
then
COL_0034:=upper(trim(COL_0034));
if(instr(COL_0034,'***')>*** or instr(COL_0034,'***')>***
or substr(COL_0034,length(COL_0034)-***,***)='***' or substr(COL_0034,length(COL_0034)-***,***)='***' )
then
return;
end if;
COL_0028:='***';
EXECUTE IMMEDIATE COL_0028 into COL_0033 using COL_0029;
if(COL_0033 is null)
then
return;
end if;
COL_0028:='***';
EXECUTE IMMEDIATE COL_0028 into COL_0031;
if(COL_0031=***)
then
COL_0028:='***';
execute immediate COL_0028;
end if;
end if;
if (COL_0027='***' and COL_0023='***')
then
COL_0028:='***';
EXECUTE IMMEDIATE COL_0028 into COL_0033 using COL_0029;
if(COL_0033 is null)
then
return;
end if;
COL_0028:='***';
EXECUTE IMMEDIATE COL_0028 into COL_0031;
if(COL_0031=***)
then
COL_0028:='***';
execute immediate COL_0028;
end if;
end if;
Exception
when others then
if(sqlcode=-***)
then
COL_0028:=sqlerrm;
COL_0028:=substr(COL_0028,***);
COL_0028:='***'||COL_0028||'***';
execute immediate COL_0028;
end if;
end;
Text truncated: the trace declares 5977 characters.
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.002000 | 51.8 | 1 | |
| recursive | 0.001438 | 37.2 | ||
| unaccounted-for | 0.000425 | 11.0 | 3 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000132 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.002999 | 0.003718 | 0 | 0 | 0 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000013 | 0 | 0 | 0 | 0 | 0 |
Recursive SQL executed by this statement
#22 · LOCK TABLE
sql_id dsn1ksdx81jd4hv 2055259556Text
LOCK TABLE "TAB_0005" IN EXCLUSIVE MODE NOWAIT
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.002000 | 55.2 | 1 | |
| recursive | 0.001435 | 39.6 | ||
| unaccounted-for | 0.000190 | 5.2 | 3 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.003000 | 0.003593 | 2 | 6 | 0 | 0 | 1 |
| EXEC | 1 | 0.000000 | 0.000024 | 0 | 0 | 0 | 0 | 0 |
| CLOSE | 1 | 0.000000 | 0.000008 | 0 | 0 | 0 | 0 | 0 |
Recursive SQL executed by this statement
#23 · SELECT
sql_id 0w81pyhzu3vfjhv 1067576785Text
select COL_0042, COL_0043 from sys.mon_mods_all$1 where obj# = :COL_0044
- 1 MON_MODS_ALL$, table of index IDX_0008: plan operation 2
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| wait | 0.002974 | 92.8 | 1 | |
| unaccounted-for | 0.000232 | 7.2 | 4 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000061 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000000 | 0.000076 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 1 | 0.000000 | 0.003061 | 1 | 2 | 0 | 0 | 0 |
| CLOSE | 1 | 0.000000 | 0.000008 | 0 | 0 | 0 | 0 | 0 |
Execution plan 1245710492
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · INDEX UNIQUE SCAN IDX_0008 99.9% of time · 100.0% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 0 | 1 | 0.000002 | 0.1 | 0 | 0.0 | 1 | 0 | 0.003060 | 2 | 2 | 463 | |||
| 2 | 1 | 0 | 1 | 0.003058 | 99.9 | 2 | 100.0 | 1 | 0 | 0.003058 | 2 | 1 | 464 |
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Unique key lookup
INDEX UNIQUE SCAN
Looks up a single key in a unique index (PK or UNIQUE): goes down from the root block through the branch blocks to the key's leaf block.
- Good when
- Almost always: it reads only the index height (BLEVEL + 1 blocks).
- Bad when
- As the inner of a NESTED LOOPS with millions of outer rows: cheap per execution, expensive in total.
- In the plan, check
- Exec: thousands of executions add up even with a low self LIO in each one.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#24 · PL/SQL
sql_id 6tamjm552vthshv 1244522008Text
declare
TYPE COL_0021 IS REF CURSOR;
COL_0022 COL_0021;
COL_0023 varchar2(***);
COL_0024 varchar2(***);
COL_0025 varchar2(***);
COL_0026 varchar2(***);
COL_0027 varchar2(***);
COL_0029 varchar2(***);
COL_0030 varchar2(***);
COL_0031 NUMBER;
COL_0028 varchar2(***);
COL_0059 varchar2(***);
COL_0060 varchar2(***);
COL_0034 VARCHAR2(***);
begin
COL_0028:='***';
execute immediate COL_0028 into COL_0027;
if(not (COL_0027='***' or COL_0027='***' or COL_0027='***' or COL_0027='***'))
then
return;
end if;
COL_0028:='***';
execute immediate COL_0028 into COL_0023;
COL_0028:='***';
execute immediate COL_0028 into COL_0024;
COL_0028:='***';
execute immediate COL_0028 into COL_0026;
COL_0028:='***';
execute immediate COL_0028 into COL_0025;
COL_0028:='***';
execute immediate COL_0028 into COL_0029;
if((instr(upper(COL_0029),'***')>***) and COL_0023='***')
then
return;
end if;
if (COL_0025!='***' and COL_0025!='***' and COL_0027='***' and COL_0023='***')
then
COL_0028:='***';
execute immediate COL_0028 into COL_0059 using SYS.DBMS_ASSERT.SCHEMA_NAME(COL_0025),SYS.DBMS_ASSERT.SIMPLE_SQL_NAME(COL_0029);
COL_0059:=trim(COL_0059);
while (length(COL_0059)!=***) loop
if (instr(COL_0059,'***')!=***)
then
COL_0060:=trim(substr(COL_0059,***,instr(COL_0059,'***')-***));
COL_0059:=trim(substr(COL_0059,instr(COL_0059,'***')+***));
else
COL_0060:=trim(COL_0059);
COL_0059:='***';
end if;
COL_0028:='***';
execute immediate COL_0028 using COL_0025||'***'||COL_0029,SYS.DBMS_ASSERT.QUALIFIED_SQL_NAME(COL_0060);
end loop;
return;
end if;
if (COL_0029!='***' and COL_0027='***' and COL_0023='***')
then
COL_0028:='***';
execute immediate COL_0028;
end if;
if (COL_0025!='***' and COL_0025!='***' and COL_0027='***' and COL_0023='***')
then
COL_0028:='***';
execute immediate COL_0028;
end if;
if (COL_0025!='***' and COL_0025!='***' and COL_0027='***' and COL_0023='***')
then
COL_0028:='***';
execute immediate COL_0028;
end if;
if (COL_0025!='***' and COL_0025!='***' and COL_0027='***' and COL_0023='***')
then
COL_0028:='***';
execute immediate COL_0028;
end if;
if (COL_0025!='***' and COL_0025!='***' and COL_0027='***' and COL_0023='***')
then
COL_0028:='***';
execute immediate COL_0028;
end if;
if (COL_0023='***' and COL_0027='***')
then
COL_0028:='***';
EXECUTE IMMEDIATE COL_0028;
end if;
if ((COL_0027='***' and COL_0023='***') or (COL_0027='***' and COL_0023='***'))
then
COL_0028:='***';
EXECUTE IMMEDIATE COL_0028;
end if;
Exception
when others then
if(sqlcode=-***)
then
COL_0028:=sqlerrm;
COL_0028:=substr(COL_0028,***);
COL_0028:='***'||COL_0028||'***';
execute immediate COL_0028;
end if;
end;
Text truncated: the trace declares 3698 characters.
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| recursive | 0.002070 | 67.7 | ||
| unaccounted-for | 0.000989 | 32.3 | 3 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000038 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.003000 | 0.003001 | 0 | 6 | 0 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000020 | 0 | 0 | 0 | 0 | 0 |
Recursive SQL executed by this statement
#25 · PL/SQL
sql_id 0b87xumrqfr04hv 4016528388Text
BEGIN
BEGIN
IF (sys.ROT_0002(sys.COL_0016, sys.COL_0017, xdb.DBMS_XDBZ.IS_ENABLED_CONTENTS)) THEN
xdb.PKG_0001.ROT_0003(sys.COL_0016, sys.COL_0017);
ELSIF (sys.ROT_0002(sys.COL_0016, sys.COL_0017, xdb.DBMS_XDBZ.IS_ENABLED_RESMETADATA)) THEN
xdb.PKG_0001.ROT_0004(sys.COL_0016, sys.COL_0017);
END IF;
EXCEPTION
WHEN OTHERS THEN
null;
END;
END;
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.003000 | 137.6 | 1 | |
| recursive | 0.000762 | 34.9 | ||
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| unaccounted-for | -0.001581 | -72.5 | 3 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000052 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.003000 | 0.002110 | 0 | 12 | 0 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000019 | 0 | 0 | 0 | 0 | 0 |
Recursive SQL executed by this statement
#26 · UPDATE
sql_id 0ya7u8w97wkvahv 310266730Text
update tab$23 set ts#=:2,file#=:3,block#=:4,COL_0055=decode(:5,***,null,:5),tab#=decode(:6,***,null,:6),intcols=:7,kernelcols=:8,clucols=decode(:9,***,null,:9),audit$=:10,flags=:11,pctfree$=:12,pctused$=:13,initrans=:14,maxtrans=:15,rowcnt=:16,blkcnt=:17,empcnt=:18,avgspc=:19,chncnt=:20,avgrln=:21,analyzetime=:22,samplesize=:23,cols=:24,property=:25,degree=decode(:26,***,null,:26),instances=decode(:27,***,null,:27),dataobj#=:28,avgspc_flb=:29,flbcnt=:30,trigflag=:31,spare1=:32,spare2=decode(:33,***,null,:33),spare4=:34,spare6=:35 where obj#=:1
- 1 operation 1 (UPDATE TAB$) has no object of its own in the text
- 2 TAB$, table of index I_OBJ#: plan operation 3
- 3 TAB$: plan operation 2
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.002000 | 97.4 | 1 | |
| unaccounted-for | 0.000053 | 2.6 | 3 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000033 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.002000 | 0.002018 | 0 | 3 | 1 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000002 | 0 | 0 | 0 | 0 | 0 |
Execution plan 2918346288
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 1 · UPDATE TAB$ 86.1% of time · 0.0% of logical reads
- 2 Id 3 · INDEX UNIQUE SCAN I_OBJ# 7.3% of time · 66.7% of logical reads
- 3 Id 2 · TABLE ACCESS CLUSTER TAB$ 6.6% of time · 33.3% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 0 | 0.000118 | 86.1 | 0 | 0.0 | 0 | 0 | 0.000137 | 3 | |||||
| 2 | 3 | 1 | 1 | 0.000009 | 6.6 | 1 | 33.3 | 0 | 0 | 0.000019 | 3 | 2 | 4 | ||
| 3 | 2 | 1 | 1 | 0.000010 | 7.3 | 2 | 66.7 | 0 | 0 | 0.000010 | 2 | 1 | 3 |
Update
UPDATE
Updates the rows returned by the row source below.
- Good when
- Few rows, found through an index.
- Bad when
- Too many rows from the row source below; the table's indexes and triggers add up.
- In the plan, check
- Rows of the row source below.
Table access by cluster
TABLE ACCESS CLUSTER
Reads a table stored in a cluster, by the cluster key.
- Good when
- Tables that are always read together by the same key.
- Bad when
- Poorly sized cluster, with chained blocks.
Unique key lookup
INDEX UNIQUE SCAN
Looks up a single key in a unique index (PK or UNIQUE): goes down from the root block through the branch blocks to the key's leaf block.
- Good when
- Almost always: it reads only the index height (BLEVEL + 1 blocks).
- Bad when
- As the inner of a NESTED LOOPS with millions of outer rows: cheap per execution, expensive in total.
- In the plan, check
- Exec: thousands of executions add up even with a low self LIO in each one.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#27 · CALL
sql_id 6tn90anbghha4hv 385368388Text
call COL_0035.ROT_0006()
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.001000 | 63.3 | 1 | |
| recursive | 0.000521 | 33.0 | ||
| unaccounted-for | 0.000060 | 3.8 | 3 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000022 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.002000 | 0.001557 | 0 | 6 | 0 | 0 | 0 |
| CLOSE | 1 | 0.000000 | 0.000002 | 0 | 0 | 0 | 0 | 0 |
Recursive SQL executed by this statement
#28 · UPDATE
sql_id cr1bq73d78ckphv 3665048149Text
update seg$13 set type#=:4,blocks=:5,extents=:6,minexts=:7,maxexts=:8,extsize=:9,extpct=:10,user#=:11,iniexts=:12,lists=decode(:13, ***, NULL, :13),groups=decode(:14, ***, NULL, :14), cachehint=:15, hwmincr=:16, spare1=DECODE(:17,***,NULL,:17),scanhint=:18, bitmapranges=:19 where ts#=:1 and file#=:2 and block#=:3
- 1 SEG$, table of index I_FILE#_BLOCK#: plan operation 3
- 2 operation 1 (UPDATE SEG$) has no object of its own in the text
- 3 SEG$: plan operation 2
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.001000 | 80.5 | 1 | |
| unaccounted-for | 0.000231 | 18.6 | 3 | |
| wait | 0.000011 | 0.9 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000069 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.001000 | 0.001171 | 1 | 3 | 1 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000002 | 0 | 0 | 0 | 0 | 0 |
Execution plan 2170058777
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 3 · INDEX UNIQUE SCAN I_FILE#_BLOCK# 30.3% of time · 66.7% of logical reads
- 2 Id 1 · UPDATE SEG$ 63.4% of time · 0.0% of logical reads
- 3 Id 2 · TABLE ACCESS CLUSTER SEG$ 6.3% of time · 33.3% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 0 | 0.000111 | 63.4 | 0 | 0.0 | 1 | 0 | 0.000175 | 3 | |||||
| 2 | 3 | 1 | 1 | 0.000011 | 6.3 | 1 | 33.3 | 1 | 0 | 0.000064 | 3 | 2 | 14 | ||
| 3 | 1 | 1 | 1 | 0.000053 | 30.3 | 2 | 66.7 | 1 | 0 | 0.000053 | 2 | 1 | 9 |
Update
UPDATE
Updates the rows returned by the row source below.
- Good when
- Few rows, found through an index.
- Bad when
- Too many rows from the row source below; the table's indexes and triggers add up.
- In the plan, check
- Rows of the row source below.
Table access by cluster
TABLE ACCESS CLUSTER
Reads a table stored in a cluster, by the cluster key.
- Good when
- Tables that are always read together by the same key.
- Bad when
- Poorly sized cluster, with chained blocks.
Unique key lookup
INDEX UNIQUE SCAN
Looks up a single key in a unique index (PK or UNIQUE): goes down from the root block through the branch blocks to the key's leaf block.
- Good when
- Almost always: it reads only the index height (BLEVEL + 1 blocks).
- Bad when
- As the inner of a NESTED LOOPS with millions of outer rows: cheap per execution, expensive in total.
- In the plan, check
- Exec: thousands of executions add up even with a low self LIO in each one.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#29 · UPDATE
sql_id 6j5xzzhqr2067hv 762380487Text
update obj$ set obj#=:4, type#=:5,ctime=:6,mtime=:7,stime=:8,status=:9,dataobj#=:10,flags=:11,oid$=:12,spare1=:13, spare2=:14 where owner#=:1 and name=:2 and namespace=:3 and remoteowner is null and linkname is null and subname is null
- 1 I_OBJ2 does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 2)
- 2 operation 1 (UPDATE OBJ$) has no object of its own in the text
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.001999 | 161.1 | 1 | |
| wait | 0.000020 | 1.6 | 2 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| unaccounted-for | -0.000778 | -62.7 | 3 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000039 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.001999 | 0.001200 | 2 | 3 | 7 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000002 | 0 | 0 | 0 | 0 | 0 |
Execution plan 2683643009
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · INDEX RANGE SCAN I_OBJ2 3.8% of time · 100.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 2 Id 1 · UPDATE OBJ$ 96.2% of time · 0.0% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 0 | 0.000482 | 96.2 | 0 | 0.0 | 2 | 0 | 0.000501 | 3 | |||||
| 2 | 1 | 1 | 1 | 0.000019 | 3.8 | 3 | 100.0 | 0 | 0 | 0.000019 | 3 | 3 | 37 |
Update
UPDATE
Updates the rows returned by the row source below.
- Good when
- Few rows, found through an index.
- Bad when
- Too many rows from the row source below; the table's indexes and triggers add up.
- In the plan, check
- Rows of the row source below.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#31 · SELECT
sql_id 1yjwr52wkx13whv 3106833532Text
select name,intcol#,segcol#,type#,length,nvl(COL_0014,***),decode(type#,***,nvl(scale,-***/*MAXSB1MINAL*/),***,scale,***,scale,***,scale,***,scale,***,scale,***,scale,***,scale,***),null$,fixedstorage,nvl(deflength,***),default$,rowid,col#,property, nvl(charsetid,***),nvl(charsetform,***),spare1,spare2,nvl(spare3,***) from col$12 where obj#=:1 order by intcol#
- 1 COL$: plan operation 2
- 2 COL$, table of index I_OBJ#: plan operation 3
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000829 | 100.0 | 62 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 56 | |
| cpu | 0.000000 | 0.0 | 2 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 2 | 0.000000 | 0.000093 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 2 | 0.000000 | 0.000221 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 56 | 0.000000 | 0.000510 | 0 | 7 | 0 | 54 | 0 |
| CLOSE | 2 | 0.000000 | 0.000005 | 0 | 0 | 0 | 0 | 0 |
Execution plan 3765558045
From the STAT lines in the trace; plan written 2 times, showing the last one.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · TABLE ACCESS CLUSTER COL$ 92.2% of time · 50.0% of logical reads
- 2 Id 3 · INDEX UNIQUE SCAN I_OBJ# 7.8% of time · 50.0% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 50 | 13 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000114 | 4 | 3 | ||||
| 2 | 1 | 50 | 13 | 0.000107 | 92.2 | 2 | 50.0 | 0 | 0 | 0.000116 | 4 | 2 | 21 | ||
| 3 | 2 | 1 | 1 | 0.000009 | 7.8 | 2 | 50.0 | 0 | 0 | 0.000009 | 2 | 1 | 3 |
Sort (ORDER BY)
SORT ORDER BY
Sorts the rows for the ORDER BY.
- Good when
- Few rows, in-memory sort.
- Bad when
- Many rows: the sort does not fit in the workarea and writes to TEMP. An index in the requested order can avoid the SORT, especially with ROWNUM or FETCH FIRST.
- In the plan, check
- PW above zero and Self time (s).
Table access by cluster
TABLE ACCESS CLUSTER
Reads a table stored in a cluster, by the cluster key.
- Good when
- Tables that are always read together by the same key.
- Bad when
- Poorly sized cluster, with chained blocks.
Unique key lookup
INDEX UNIQUE SCAN
Looks up a single key in a unique index (PK or UNIQUE): goes down from the root block through the branch blocks to the key's leaf block.
- Good when
- Almost always: it reads only the index height (BLEVEL + 1 blocks).
- Bad when
- As the inner of a NESTED LOOPS with millions of outer rows: cheap per execution, expensive in total.
- In the plan, check
- Exec: thousands of executions add up even with a low self LIO in each one.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#32 · SELECT
sql_id bgv44n2yyz7yqhv 3186597846Text
SELECT /*+ ALL_ROWS */ COUNT(*) FROM DBA_POLICIES V WHERE V.COL_0018 = :B3 AND V.COL_0019 = :B2 AND (V.COL_0020 LIKE '***' OR V.COL_0020 LIKE '***') AND V.FUNCTION = :B1
- 1 I_OBJ5 does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 8)
- 2 USER$ does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 6)
- 3 USER$ (table of index I_USER1) does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 7)
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000762 | 100.0 | 7 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000067 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 2 | 0.000000 | 0.000550 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 2 | 0.000000 | 0.000138 | 0 | 12 | 0 | 2 | 0 |
| CLOSE | 2 | 0.000000 | 0.000007 | 0 | 0 | 0 | 0 | 0 |
Execution plan 3085502541
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 8 · INDEX RANGE SCAN I_OBJ5 28.7% of time · 50.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 2 Id 6 · TABLE ACCESS BY INDEX ROWID USER$ 12.8% of time · 16.7% of logical reads
Visits the table row by row from the index: unselective index or missing the columns the filter uses. - 3 Id 7 · INDEX UNIQUE SCAN I_USER1 13.8% of time · 16.7% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 0.000011 | 11.7 | 0 | 0.0 | 0 | 0 | 0.000094 | 6 | ||||||
| 2 | 0 | 0.000006 | 6.4 | 0 | 0.0 | 0 | 0 | 0.000083 | 6 | ||||||
| 3 | 0 | 1 | 0.000003 | 3.2 | 0 | 0.0 | 0 | 0 | 0.000077 | 6 | 4 | ||||
| 4 | 0 | 1 | 0.000006 | 6.4 | 0 | 0.0 | 0 | 0 | 0.000074 | 6 | 3 | ||||
| 5 | 1 | 1 | 0.000006 | 6.4 | 0 | 0.0 | 0 | 0 | 0.000058 | 5 | 3 | ||||
| 6 | 2 | 1 | 1 | 0.000012 | 12.8 | 1 | 16.7 | 0 | 0 | 0.000025 | 2 | 1 | 22 | ||
| 7 | 3 | 1 | 1 | 0.000013 | 13.8 | 1 | 16.7 | 0 | 0 | 0.000013 | 1 | 0 | 46 | ||
| 8 | 1 | 1 | 1 | 0.000027 | 28.7 | 3 | 50.0 | 0 | 0 | 0.000027 | 3 | 2 | 40 | ||
| 9 | 0 | 1 | 0.000002 | 2.1 | 0 | 0.0 | 0 | 0 | 0.000010 | 1 | 0 | 375 | |||
| 10 | 0 | 1 | 0.000008 | 8.5 | 1 | 16.7 | 0 | 0 | 0.000008 | 1 | 0 | 377 | |||
| 11 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 1 | 47 | |||
| 12 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | ||||
| 13 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 1 | 47 | |||
| 14 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 2 | 39 |
Aggregation (COUNT, SUM, MAX...)
SORT AGGREGATE
Computes the aggregate functions and returns one row.
- Good when
- Cheap in itself: the cost is in the operations below.
- Bad when
- Almost never.
- In the plan, check
- The operations below it.
Filter
FILTER
Applies a predicate to the rows of the row source below. With two row sources, executes the second (a subquery that was not unnested) for each row of the first.
- Good when
- A single row source, or a subquery executed only a few times (FILTER caches the results already computed).
- Bad when
- Subquery executed row by row (high Exec on the second row source): allowing unnesting or rewriting it as a join usually solves it.
- In the plan, check
- Exec of the second row source.
Nested loops join
NESTED LOOPS
For each row of the outer (driving) row source, executes the inner row source.
- Good when
- Few rows in the outer and selective index access in the inner. Returns the first rows quickly (good for FIRST_ROWS).
- Bad when
- Many rows in the outer: the inner runs thousands of times. It usually comes from an underestimated cardinality in the outer; a HASH JOIN would read each side only once.
- In the plan, check
- Exec of the inner operations and, in the outer, Estimated compared with Rows/exec.
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Unique key lookup
INDEX UNIQUE SCAN
Looks up a single key in a unique index (PK or UNIQUE): goes down from the root block through the branch blocks to the key's leaf block.
- Good when
- Almost always: it reads only the index height (BLEVEL + 1 blocks).
- Bad when
- As the inner of a NESTED LOOPS with millions of outer rows: cheap per execution, expensive in total.
- In the plan, check
- Exec: thousands of executions add up even with a low self LIO in each one.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Index skip scan
INDEX SKIP SCAN
Uses a composite index without the leading column in the filter: scans the index once for each distinct value of the leading column.
- Good when
- The leading index column has few distinct values.
- Bad when
- The leading column has many values: it becomes almost a full index read. An index that starts with the filtered column usually solves it.
- In the plan, check
- Self LIO compared with the Rows returned.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#33 · UPDATE
sql_id fncf618xnzg7ghv 995081455Text
update sys.mon_mods$ set COL_0042 = COL_0042 + :COL_0045, COL_0046 = COL_0046 + :COL_0047, COL_0043 = COL_0043 + :COL_0048, flags = (decode(bitand(flags, :COL_0040), :COL_0040, flags, flags + :COL_0040)), COL_0049 = COL_0049 + :COL_0050, timestamp = :time where obj# = :COL_0044
- 1 IDX_0007 does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 2)
- 2 operation 1 (UPDATE MON_MODS$) has no object of its own in the text
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.001000 | 150.4 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| unaccounted-for | -0.000335 | -50.4 | 3 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000042 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.001000 | 0.000618 | 0 | 2 | 3 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000005 | 0 | 0 | 0 | 0 | 0 |
Execution plan 315182377
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · INDEX UNIQUE SCAN IDX_0007 3.9% of time · 100.0% of logical reads
- 2 Id 1 · UPDATE MON_MODS$ 96.1% of time · 0.0% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 0 | 0.000171 | 96.1 | 0 | 0.0 | 0 | 0 | 0.000178 | 2 | |||||
| 2 | 1 | 1 | 1 | 0.000007 | 3.9 | 2 | 100.0 | 0 | 0 | 0.000007 | 2 | 1 | 462 |
Update
UPDATE
Updates the rows returned by the row source below.
- Good when
- Few rows, found through an index.
- Bad when
- Too many rows from the row source below; the table's indexes and triggers add up.
- In the plan, check
- Rows of the row source below.
Unique key lookup
INDEX UNIQUE SCAN
Looks up a single key in a unique index (PK or UNIQUE): goes down from the root block through the branch blocks to the key's leaf block.
- Good when
- Almost always: it reads only the index height (BLEVEL + 1 blocks).
- Bad when
- As the inner of a NESTED LOOPS with millions of outer rows: cheap per execution, expensive in total.
- In the plan, check
- Exec: thousands of executions add up even with a low self LIO in each one.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#34 · SELECT
sql_id 22a8nb2z3h5cthv 3191346585Text
select intcol#,nvl(pos#,***),col#,nvl(spare1,***) from ccol$12 where con#=:1
- 1 CCOL$, table of index I_CCOL1: plan operation 2
- 2 CCOL$: plan operation 1
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000472 | 97.9 | 25 | |
| wait | 0.000010 | 2.1 | 1 | |
| cpu | 0.000000 | 0.0 | 5 | |
| cpu | 0.000000 | 0.0 | 5 | |
| cpu | 0.000000 | 0.0 | 14 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000018 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 5 | 0.000000 | 0.000332 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 14 | 0.000000 | 0.000125 | 1 | 28 | 0 | 9 | 0 |
| CLOSE | 5 | 0.000000 | 0.000007 | 0 | 0 | 0 | 0 | 0 |
Execution plan 3954488388
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · INDEX RANGE SCAN I_CCOL1 95.3% of time · 75.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 2 Id 1 · TABLE ACCESS BY INDEX ROWID CCOL$ 4.7% of time · 25.0% of logical reads
Visits the table row by row from the index: unselective index or missing the columns the filter uses.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 1 | 1 | 0.000002 | 4.7 | 1 | 25.0 | 1 | 0 | 0.000043 | 4 | 3 | 32 | ||
| 2 | 1 | 1 | 1 | 0.000041 | 95.3 | 3 | 75.0 | 1 | 0 | 0.000041 | 3 | 2 | 57 |
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#35 · SELECT
sql_id cnhr7ugzaazkdhv 4272258637Text
select con#,type#,condlength,intcols,robj#,rcon#,COL_0015,refact,nvl(enabled,***),rowid,cols,nvl(defer,***),mtime,nvl(spare1,***),spare2,spare3 from cdef$12 where obj#=:1
- 1 CDEF$, table of index I_CDEF2: plan operation 2
- 2 CDEF$: plan operation 1
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.001999 | 414.7 | 2 | |
| wait | 0.000014 | 2.9 | 1 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 7 | |
| cpu | 0.000000 | 0.0 | 2 | |
| unaccounted-for | -0.001531 | -317.6 | 13 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 2 | 0.000000 | 0.000056 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 2 | 0.001999 | 0.000225 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 7 | 0.000000 | 0.000197 | 1 | 14 | 0 | 5 | 0 |
| CLOSE | 2 | 0.000000 | 0.000004 | 0 | 0 | 0 | 0 | 0 |
Execution plan 1932954096
From the STAT lines in the trace; plan written 2 times, showing the last one.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · INDEX RANGE SCAN I_CDEF2 100.0% of time · 58.3% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 2 Id 1 · TABLE ACCESS BY INDEX ROWID CDEF$ 0.0% of time · 41.7% of logical reads
Visits the table row by row from the index: unselective index or missing the columns the filter uses.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 5 | 4 | 0.000000 | 0.0 | 5 | 41.7 | 0 | 0 | 0.000010 | 12 | 2 | 31 | ||
| 2 | 1 | 5 | 4 | 0.000015 | 100.0 | 7 | 58.3 | 0 | 0 | 0.000015 | 7 | 1 | 54 |
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#36 · SELECT
sql_id 9mrt35hfcpg50hv 483048608Text
select COL_0035.COL_0036 from dual
- 1 operation 1 (FAST DUAL) has no object of its own in the text
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000481 | 100.0 | 4 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000030 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000000 | 0.000020 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 1 | 0.000000 | 0.000428 | 0 | 0 | 0 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000003 | 0 | 0 | 0 | 0 | 0 |
Execution plan 1388734953
From the STAT lines in the trace.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 FAST DUAL | 1 | 1 | 0.000002 | 100.0 | 0 | 0.0 | 0 | 0 | 0.000002 | 0 | 2 |
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#37 · SELECT
sql_id 5mw52nkh2kxhrhv 2687071767Text
select decode(u.type#, ***, u.ext_username, u.name), o.name, t.update$, t.insert$, t.delete$, t.enabled, decode(bitand(t.property, ***),***, ***, ***), decode(bitand(t.property, ***), ***, ***, ***), decode(bitand(t.property, ***), ***, ***, ***), (select o.name from obj$ o where o.obj# = u.spare2 and o.type# =***) from sys.obj$ o, sys.user$ u, sys.trigger$23 t, sys.obj$ bo where t.baseobject=bo.obj# and bo.name = :1 and bo.spare3 = :2 and bo.namespace = *** and t.obj#=o.obj# and o.owner#=u.user# and o.type# = *** and bitand(property,***)=*** and bitand(property,***)=*** order by o.obj#
- 1 I_OBJ5 does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 7)
- 2 TRIGGER$, table of index I_TRIGGER1: plan operation 9
- 3 TRIGGER$: plan operation 8
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000441 | 100.0 | 8 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 2 | 0.000000 | 0.000071 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 2 | 0.000000 | 0.000261 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 2 | 0.000000 | 0.000087 | 0 | 10 | 0 | 0 | 0 |
| CLOSE | 2 | 0.000000 | 0.000022 | 0 | 0 | 0 | 0 | 0 |
Execution plan 515562855
From the STAT lines in the trace; plan written 2 times, showing the last one.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 7 · INDEX RANGE SCAN I_OBJ5 38.5% of time · 60.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 2 Id 9 · INDEX RANGE SCAN I_TRIGGER1 13.5% of time · 40.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 3 Id 8 · TABLE ACCESS BY INDEX ROWID TRIGGER$ 17.3% of time · 0.0% of logical reads
Visits the table row by row from the index: unselective index or missing the columns the filter uses.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | 18 | |||
| 2 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 2 | 36 | |||
| 3 | 0 | 1 | 0.000008 | 15.4 | 0 | 0.0 | 0 | 0 | 0.000052 | 5 | 9 | ||||
| 4 | 0 | 1 | 0.000005 | 9.6 | 0 | 0.0 | 0 | 0 | 0.000044 | 5 | 8 | ||||
| 5 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000039 | 5 | 7 | ||||
| 6 | 0 | 1 | 0.000003 | 5.8 | 0 | 0.0 | 0 | 0 | 0.000039 | 5 | 5 | ||||
| 7 | 1 | 1 | 1 | 0.000020 | 38.5 | 3 | 60.0 | 0 | 0 | 0.000020 | 3 | 3 | 40 | ||
| 8 | 3 | 0 | 1 | 0.000009 | 17.3 | 0 | 0.0 | 0 | 0 | 0.000016 | 2 | 2 | 160 | ||
| 9 | 2 | 0 | 2 | 0.000007 | 13.5 | 2 | 40.0 | 0 | 0 | 0.000007 | 2 | 1 | 162 | ||
| 10 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 2 | 18 | |||
| 11 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 1 | 36 | |||
| 12 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 1 | 22 | |||
| 13 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 0 | 11 |
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Sort (ORDER BY)
SORT ORDER BY
Sorts the rows for the ORDER BY.
- Good when
- Few rows, in-memory sort.
- Bad when
- Many rows: the sort does not fit in the workarea and writes to TEMP. An index in the requested order can avoid the SORT, especially with ROWNUM or FETCH FIRST.
- In the plan, check
- PW above zero and Self time (s).
Nested loops join
NESTED LOOPS
For each row of the outer (driving) row source, executes the inner row source.
- Good when
- Few rows in the outer and selective index access in the inner. Returns the first rows quickly (good for FIRST_ROWS).
- Bad when
- Many rows in the outer: the inner runs thousands of times. It usually comes from an underestimated cardinality in the outer; a HASH JOIN would read each side only once.
- In the plan, check
- Exec of the inner operations and, in the outer, Estimated compared with Rows/exec.
Table access by cluster
TABLE ACCESS CLUSTER
Reads a table stored in a cluster, by the cluster key.
- Good when
- Tables that are always read together by the same key.
- Bad when
- Poorly sized cluster, with chained blocks.
Unique key lookup
INDEX UNIQUE SCAN
Looks up a single key in a unique index (PK or UNIQUE): goes down from the root block through the branch blocks to the key's leaf block.
- Good when
- Almost always: it reads only the index height (BLEVEL + 1 blocks).
- Bad when
- As the inner of a NESTED LOOPS with millions of outer rows: cheap per execution, expensive in total.
- In the plan, check
- Exec: thousands of executions add up even with a low self LIO in each one.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#38 · SELECT
sql_id 67mfz4c9y7qk4hv 333699652Text
select sys.dbms_standard.dictionary_obj_type from dual
- 1 operation 1 (FAST DUAL) has no object of its own in the text
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000438 | 100.0 | 8 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 2 | 0.000000 | 0.000040 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 2 | 0.000000 | 0.000037 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 2 | 0.000000 | 0.000358 | 0 | 0 | 0 | 2 | 0 |
| CLOSE | 2 | 0.000000 | 0.000003 | 0 | 0 | 0 | 0 | 0 |
Execution plan 1388734953
From the STAT lines in the trace.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 FAST DUAL | 1 | 1 | 0.000002 | 100.0 | 0 | 0.0 | 0 | 0 | 0.000002 | 0 | 2 |
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#39 · SELECT
sql_id da3h6n1cgu01bhv 1492975659Text
SELECT COL_0065 FROM TAB_000212 WHERE COL_0002 = :B3 AND TO_NUMBER(COL_0003) = :B2 AND COL_0001 = :B1
- 1 TAB_0002: plan operation 1
- 2 TAB_0002, table of index IDX_0002: plan operation 2
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.001000 | 258.4 | 1 | |
| wait | 0.000034 | 8.8 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| unaccounted-for | -0.000647 | -167.2 | 4 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000031 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000000 | 0.000190 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 1 | 0.001000 | 0.000165 | 1 | 3 | 0 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000001 | 0 | 0 | 0 | 0 | 0 |
Execution plan 3237010533
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 1 · TABLE ACCESS BY INDEX ROWID TAB_0002 77.8% of time · 33.3% of logical reads
Visits the table row by row from the index: unselective index or missing the columns the filter uses. - 2 Id 2 · INDEX RANGE SCAN IDX_0002 22.2% of time · 66.7% of logical reads
Scans a wide range of the index: check the selectivity and the column order.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 1 | 1 | 0.000091 | 77.8 | 1 | 33.3 | 1 | 0 | 0.000117 | 3 | 3 | 187749 | ||
| 2 | 2 | 1 | 1 | 0.000026 | 22.2 | 2 | 66.7 | 0 | 0 | 0.000026 | 2 | 2 | 188088 |
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#42 · SELECT
sql_id 9n37vajy2tqa0hv 2083313984Text
select col#, grantee#, privilege#,max(mod(nvl(option$,***),***)) from objauth$1 where obj#=:1 and col# is not null group by privilege#, col#, grantee# order by col#, grantee#
- 1 OBJAUTH$, table of index I_OBJAUTH1: plan operation 3
- 2 operation 1 (SORT GROUP BY) has no object of its own in the text
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000344 | 100.0 | 8 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 2 | 0.000000 | 0.000079 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 2 | 0.000000 | 0.000215 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 2 | 0.000000 | 0.000045 | 0 | 6 | 0 | 0 | 0 |
| CLOSE | 2 | 0.000000 | 0.000005 | 0 | 0 | 0 | 0 | 0 |
Execution plan 2874733959
From the STAT lines in the trace; plan written 2 times, showing the last one.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 3 · INDEX RANGE SCAN I_OBJAUTH1 31.0% of time · 100.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 2 Id 1 · SORT GROUP BY 62.1% of time · 0.0% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 0 | 1 | 0.000018 | 62.1 | 0 | 0.0 | 0 | 0 | 0.000029 | 3 | 5 | |||
| 2 | 0 | 1 | 0.000002 | 6.9 | 0 | 0.0 | 0 | 0 | 0.000011 | 3 | 4 | 61 | |||
| 3 | 1 | 0 | 1 | 0.000009 | 31.0 | 3 | 100.0 | 0 | 0 | 0.000009 | 3 | 3 | 62 |
Sort grouping
SORT GROUP BY
Groups the rows for GROUP BY by sorting on the group key.
- Good when
- Few rows, or the result must come out sorted.
- Bad when
- Many rows, writing to TEMP.
- In the plan, check
- PW and Self time (s).
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#43 · SELECT
sql_id 88y5z3gq72cmqhv 3966841462Text
SELECT REPLACE(TO_CHAR(COL_0065), :B3 , '***') FROM TAB_000212 WHERE COL_0002 = :B2 AND TO_NUMBER(COL_0003) = :B1 AND COL_0001 = *** AND COL_0004 = ***
- 1 TAB_0002: plan operation 1
- 2 TAB_0002, table of index IDX_0002: plan operation 2
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.001000 | 297.6 | 1 | |
| wait | 0.000010 | 3.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| unaccounted-for | -0.000674 | -200.6 | 4 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000020 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000000 | 0.000179 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 1 | 0.001000 | 0.000135 | 1 | 3 | 0 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000002 | 0 | 0 | 0 | 0 | 0 |
Execution plan 3237010533
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 1 · TABLE ACCESS BY INDEX ROWID TAB_0002 75.0% of time · 33.3% of logical reads
Visits the table row by row from the index: unselective index or missing the columns the filter uses. - 2 Id 2 · INDEX RANGE SCAN IDX_0002 25.0% of time · 66.7% of logical reads
Scans a wide range of the index: check the selectivity and the column order.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 1 | 1 | 0.000084 | 75.0 | 1 | 33.3 | 1 | 0 | 0.000112 | 3 | 3 | 187749 | ||
| 2 | 2 | 1 | 1 | 0.000028 | 25.0 | 2 | 66.7 | 0 | 0 | 0.000028 | 2 | 2 | 188088 |
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#45 · SELECT
sql_id 7pfdb04jkh8qqhv 589832918Text
select log, sysdate, sysdate+***/***, COL_0040 from sys.mlog$1 where COL_0041 = :1 and master = :2 for update
- 1 MLOG$, table of index I_MLOG#: plan operation 4
- 2 operation 2 (BUFFER SORT) has no object of its own in the text
- 3 operation 1 (FOR UPDATE) has no object of its own in the text
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000333 | 100.0 | 4 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000035 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000000 | 0.000279 | 0 | 1 | 0 | 0 | 0 |
| FETCH | 1 | 0.000000 | 0.000011 | 0 | 0 | 0 | 0 | 0 |
| CLOSE | 1 | 0.000000 | 0.000008 | 0 | 0 | 0 | 0 | 0 |
Execution plan 1551139906
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 4 · INDEX UNIQUE SCAN I_MLOG# 17.6% of time · 100.0% of logical reads
- 2 Id 2 · BUFFER SORT 51.0% of time · 0.0% of logical reads
- 3 Id 1 · FOR UPDATE 25.5% of time · 0.0% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 3 FOR UPDATE | 0 | 0.000013 | 25.5 | 0 | 0.0 | 0 | 0 | 0.000051 | 1 | |||||
| 2 | 2 | 0 | 0.000026 | 51.0 | 0 | 0.0 | 0 | 0 | 0.000038 | 1 | |||||
| 3 | 0 | 1 | 0.000003 | 5.9 | 0 | 0.0 | 0 | 0 | 0.000012 | 1 | 0 | 627 | |||
| 4 | 1 | 0 | 1 | 0.000009 | 17.6 | 1 | 100.0 | 0 | 0 | 0.000009 | 1 | 0 | 626 |
Input buffered for reuse
BUFFER SORT
Keeps the rows of the row source below in the PGA to reuse them; common with MERGE JOIN CARTESIAN.
- Good when
- Small input reused several times.
- Bad when
- Large row source, writing to TEMP.
- In the plan, check
- PW: blocks written to TEMP.
Table access by cluster
TABLE ACCESS CLUSTER
Reads a table stored in a cluster, by the cluster key.
- Good when
- Tables that are always read together by the same key.
- Bad when
- Poorly sized cluster, with chained blocks.
Unique key lookup
INDEX UNIQUE SCAN
Looks up a single key in a unique index (PK or UNIQUE): goes down from the root block through the branch blocks to the key's leaf block.
- Good when
- Almost always: it reads only the index height (BLEVEL + 1 blocks).
- Bad when
- As the inner of a NESTED LOOPS with millions of outer rows: cheap per execution, expensive in total.
- In the plan, check
- Exec: thousands of executions add up even with a low self LIO in each one.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#46 · SELECT
sql_id by7z8wgv9mw3dhv 4137283693Text
select con#,obj#,rcon#,enabled,nvl(defer,***),spare2,spare3 from cdef$1 where robj#=:1
- 1 CDEF$, table of index I_CDEF3: plan operation 2
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.001000 | 310.6 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| unaccounted-for | -0.000678 | -210.6 | 8 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 2 | 0.000000 | 0.000077 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 2 | 0.000000 | 0.000193 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 2 | 0.001000 | 0.000048 | 0 | 4 | 0 | 0 | 0 |
| CLOSE | 2 | 0.000000 | 0.000004 | 0 | 0 | 0 | 0 | 0 |
Execution plan 1224215794
From the STAT lines in the trace; plan written 2 times, showing the last one.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · INDEX RANGE SCAN I_CDEF3 90.9% of time · 100.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 0 | 4 | 0.000003 | 9.1 | 0 | 0.0 | 0 | 0 | 0.000033 | 2 | 2 | 31 | |||
| 2 | 1 | 0 | 1 | 0.000030 | 90.9 | 2 | 100.0 | 0 | 0 | 0.000030 | 2 | 1 | 55 |
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#47 · SELECT
sql_id 3f4zmq2bz64aphv 2549289301Text
select grantee#,privilege#,nvl(col#,***),max(mod(nvl(option$,***),***))from objauth$1 where obj#=:1 group by grantee#,privilege#,nvl(col#,***) order by grantee#
- 1 OBJAUTH$, table of index I_OBJAUTH1: plan operation 3
- 2 operation 1 (SORT GROUP BY) has no object of its own in the text
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000317 | 100.0 | 8 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 2 | 0.000000 | 0.000063 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 2 | 0.000000 | 0.000221 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 2 | 0.000000 | 0.000028 | 0 | 6 | 0 | 0 | 0 |
| CLOSE | 2 | 0.000000 | 0.000005 | 0 | 0 | 0 | 0 | 0 |
Execution plan 2874733959
From the STAT lines in the trace; plan written 2 times, showing the last one.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 3 · INDEX RANGE SCAN I_OBJAUTH1 42.9% of time · 100.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 2 Id 1 · SORT GROUP BY 50.0% of time · 0.0% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 0 | 11 | 0.000007 | 50.0 | 0 | 0.0 | 0 | 0 | 0.000014 | 3 | 7 | |||
| 2 | 0 | 11 | 0.000001 | 7.1 | 0 | 0.0 | 0 | 0 | 0.000007 | 3 | 6 | 61 | |||
| 3 | 1 | 0 | 11 | 0.000006 | 42.9 | 3 | 100.0 | 0 | 0 | 0.000006 | 3 | 3 | 62 |
Sort grouping
SORT GROUP BY
Groups the rows for GROUP BY by sorting on the group key.
- Good when
- Few rows, or the result must come out sorted.
- Bad when
- Many rows, writing to TEMP.
- In the plan, check
- PW and Self time (s).
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#48 · SELECT
sql_id bfqbtz6bkwrpfhv 2536398510Text
select obj#,type#,ctime,mtime,stime, status, dataobj#, flags, oid$, spare1, spare2 from obj$12 where owner#=:1 and name=:2 and namespace=:3 and remoteowner is null and linkname is null and subname is null
- 1 OBJ$, table of index I_OBJ2: plan operation 2
- 2 OBJ$: plan operation 1
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.001000 | 318.5 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| unaccounted-for | -0.000686 | -218.5 | 4 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000038 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.001000 | 0.000206 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 1 | 0.000000 | 0.000021 | 0 | 4 | 0 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000049 | 0 | 0 | 0 | 0 | 0 |
Execution plan 2853959010
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · INDEX RANGE SCAN I_OBJ2 71.4% of time · 75.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 2 Id 1 · TABLE ACCESS BY INDEX ROWID OBJ$ 28.6% of time · 25.0% of logical reads
Visits the table row by row from the index: unselective index or missing the columns the filter uses.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 1 | 1 | 0.000006 | 28.6 | 1 | 25.0 | 0 | 0 | 0.000021 | 4 | 4 | 18 | ||
| 2 | 1 | 1 | 1 | 0.000015 | 71.4 | 3 | 75.0 | 0 | 0 | 0.000015 | 3 | 3 | 37 |
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#49 · SELECT
sql_id bfth5k6ryjz9vhv 2951281979Text
select *** from sys.cdc_change_tables$1 where COL_0037 = :1 and COL_0038 = :2 and bitand(COL_0039, ***)=***
- 1 CDC_CHANGE_TABLES$: plan operation 1
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000276 | 100.0 | 4 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000037 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000000 | 0.000184 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 1 | 0.000000 | 0.000046 | 0 | 1 | 0 | 0 | 0 |
| CLOSE | 1 | 0.000000 | 0.000009 | 0 | 0 | 0 | 0 | 0 |
Execution plan 626680409
From the STAT lines in the trace.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 0 | 1 | 0.000045 | 100.0 | 1 | 100.0 | 0 | 0 | 0.000045 | 1 | 2 | 669 |
Full table scan
TABLE ACCESS FULL
Reads every block of the segment up to the high water mark (HWM), with multiblock reads (db file scattered read, or direct path read for direct reads).
- Good when
- The query needs a large share of the rows, the table is small, or the read is a batch one. On Exadata (STORAGE FULL) the filter runs in the storage cells (smart scan).
- Bad when
- The predicate is selective and few rows remain: the cost grows with the segment size, not with the result. Worse as the inner of a NESTED LOOPS: the full scan repeats for every outer row.
- In the plan, check
- High self LIO with few Rows returned: selective predicate without a useful index. Exec above 1: repeated full scan.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#50 · SELECT
sql_id gpynzftxc4j44hv 2059551876Text
select sys.dbms_standard.dictionary_obj_owner from dual
- 1 operation 1 (FAST DUAL) has no object of its own in the text
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.000999 | 362.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| unaccounted-for | -0.000723 | -262.0 | 8 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 2 | 0.000999 | 0.000092 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 2 | 0.000000 | 0.000030 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 2 | 0.000000 | 0.000150 | 0 | 0 | 0 | 2 | 0 |
| CLOSE | 2 | 0.000000 | 0.000004 | 0 | 0 | 0 | 0 | 0 |
Execution plan 1388734953
From the STAT lines in the trace.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 FAST DUAL | 1 | 1 | 0.000001 | 100.0 | 0 | 0.0 | 0 | 0 | 0.000001 | 0 | 2 |
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#51 · SELECT
sql_id c16vprkufws0zhv 3035521055Text
select COL_0042, COL_0043 from sys.mon_mods$12 where obj# = :COL_0044
- 1 MON_MODS$, table of index IDX_0007: plan operation 2
- 2 MON_MODS$: plan operation 1
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000253 | 92.3 | 4 | |
| wait | 0.000021 | 7.7 | 2 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000060 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000000 | 0.000096 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 1 | 0.000000 | 0.000111 | 2 | 3 | 0 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000007 | 0 | 0 | 0 | 0 | 0 |
Execution plan 3381929193
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · INDEX UNIQUE SCAN IDX_0007 58.2% of time · 66.7% of logical reads
- 2 Id 1 · TABLE ACCESS BY INDEX ROWID MON_MODS$ 41.8% of time · 33.3% of logical reads
Visits the table row by row from the index: unselective index or missing the columns the filter uses.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 1 | 1 | 0.000046 | 41.8 | 1 | 33.3 | 2 | 0 | 0.000110 | 3 | 1 | 461 | ||
| 2 | 1 | 1 | 1 | 0.000064 | 58.2 | 2 | 66.7 | 1 | 0 | 0.000064 | 2 | 1 | 462 |
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Unique key lookup
INDEX UNIQUE SCAN
Looks up a single key in a unique index (PK or UNIQUE): goes down from the root block through the branch blocks to the key's leaf block.
- Good when
- Almost always: it reads only the index height (BLEVEL + 1 blocks).
- Bad when
- As the inner of a NESTED LOOPS with millions of outer rows: cheap per execution, expensive in total.
- In the plan, check
- Exec: thousands of executions add up even with a low self LIO in each one.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#52 · SELECT
sql_id 19u4kfhhtg8m2hv 563585634Text
select count(COL_0010) from SYS_FBA_TRACKEDTABLES1 where OBJ# = *** and bitand(FLAGS, ***)=***
- 1 SYS_FBA_TRACKEDTABLES, table of index SYS_C001489: plan operation 3
- 2 operation 1 (SORT AGGREGATE) has no object of its own in the text
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000266 | 100.0 | 7 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 2 | 0.000000 | 0.000134 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 2 | 0.000000 | 0.000082 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 2 | 0.000000 | 0.000041 | 0 | 2 | 0 | 2 | 0 |
| CLOSE | 1 | 0.000000 | 0.000009 | 0 | 0 | 0 | 0 | 0 |
Execution plan 977911507
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 3 · INDEX UNIQUE SCAN SYS_C001489 41.7% of time · 100.0% of logical reads
- 2 Id 1 · SORT AGGREGATE 50.0% of time · 0.0% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 1 | 0.000018 | 50.0 | 0 | 0.0 | 0 | 0 | 0.000036 | 1 | |||||
| 2 | 0 | 1 | 0.000003 | 8.3 | 0 | 0.0 | 0 | 0 | 0.000018 | 1 | 1 | 1271 | |||
| 3 | 1 | 0 | 1 | 0.000015 | 41.7 | 1 | 100.0 | 0 | 0 | 0.000015 | 1 | 0 | 1272 |
Aggregation (COUNT, SUM, MAX...)
SORT AGGREGATE
Computes the aggregate functions and returns one row.
- Good when
- Cheap in itself: the cost is in the operations below.
- Bad when
- Almost never.
- In the plan, check
- The operations below it.
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Unique key lookup
INDEX UNIQUE SCAN
Looks up a single key in a unique index (PK or UNIQUE): goes down from the root block through the branch blocks to the key's leaf block.
- Good when
- Almost always: it reads only the index height (BLEVEL + 1 blocks).
- Bad when
- As the inner of a NESTED LOOPS with millions of outer rows: cheap per execution, expensive in total.
- In the plan, check
- Exec: thousands of executions add up even with a low self LIO in each one.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#53 · SELECT
sql_id 959uydc7rvscghv 259907983Text
SELECT COUNT(*) FROM TAB_00061 WHERE COL_0061 = :1 AND COL_0062 = :2
- 1 TAB_0006, table of index IDX_0010: plan operation 3
- 2 operation 1 (SORT AGGREGATE) has no object of its own in the text
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.001000 | 420.2 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| unaccounted-for | -0.000762 | -320.2 | 4 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000022 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.001000 | 0.000197 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 1 | 0.000000 | 0.000017 | 0 | 1 | 0 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000002 | 0 | 0 | 0 | 0 | 0 |
Execution plan 3216348639
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 3 · INDEX RANGE SCAN IDX_0010 38.5% of time · 100.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 2 Id 1 · SORT AGGREGATE 50.0% of time · 0.0% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 1 | 0.000013 | 50.0 | 0 | 0.0 | 0 | 0 | 0.000026 | 1 | |||||
| 2 | 0 | 1 | 0.000003 | 11.5 | 0 | 0.0 | 0 | 0 | 0.000013 | 1 | 0 | 68054 | |||
| 3 | 1 | 0 | 1 | 0.000010 | 38.5 | 1 | 100.0 | 0 | 0 | 0.000010 | 1 | 0 | 68057 |
Aggregation (COUNT, SUM, MAX...)
SORT AGGREGATE
Computes the aggregate functions and returns one row.
- Good when
- Cheap in itself: the cost is in the operations below.
- Bad when
- Almost never.
- In the plan, check
- The operations below it.
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#54 · PL/SQL
sql_id 7umwgdhcjkfaphv 421083477Text
BEGIN ROT_0005(COL_0056, COL_0057, COL_0058); END;
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.001000 | 434.8 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| unaccounted-for | -0.000770 | -334.8 | 3 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.001000 | 0.000060 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000000 | 0.000155 | 0 | 0 | 0 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000015 | 0 | 0 | 0 | 0 | 0 |
#55 · SELECT
sql_id abk1nyq2wk8v2hv 2244551522Text
select sys.dbms_standard.sysevent from dual
- 1 operation 1 (FAST DUAL) has no object of its own in the text
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000227 | 100.0 | 8 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 2 | 0.000000 | 0.000035 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 2 | 0.000000 | 0.000029 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 2 | 0.000000 | 0.000159 | 0 | 0 | 0 | 2 | 0 |
| CLOSE | 2 | 0.000000 | 0.000004 | 0 | 0 | 0 | 0 | 0 |
Execution plan 1388734953
From the STAT lines in the trace.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 FAST DUAL | 1 | 1 | 0.000001 | 100.0 | 0 | 0.0 | 0 | 0 | 0.000001 | 0 | 2 |
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#56 · SELECT
sql_id d6bv6ggpfz7qjhv 3941572305Text
select sys.dbms_standard.dictionary_obj_name from dual
- 1 operation 1 (FAST DUAL) has no object of its own in the text
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000210 | 100.0 | 8 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 | |
| cpu | 0.000000 | 0.0 | 2 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 2 | 0.000000 | 0.000035 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 2 | 0.000000 | 0.000029 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 2 | 0.000000 | 0.000141 | 0 | 0 | 0 | 2 | 0 |
| CLOSE | 2 | 0.000000 | 0.000005 | 0 | 0 | 0 | 0 | 0 |
Execution plan 1388734953
From the STAT lines in the trace.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 FAST DUAL | 1 | 1 | 0.000002 | 100.0 | 0 | 0.0 | 0 | 0 | 0.000002 | 0 | 2 |
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#58 · SELECT
sql_id 710z58sn2nkt9hv 673860393Text
SELECT COUNT(*) FROM MDSYS.TAB_0007 WHERE COL_0061 = :1 AND COL_0063 = :2
- 1 IDX_0011 does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 2)
- 2 operation 1 (SORT AGGREGATE) has no object of its own in the text
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000178 | 100.0 | 4 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000020 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000000 | 0.000149 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 1 | 0.000000 | 0.000007 | 0 | 0 | 0 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000002 | 0 | 0 | 0 | 0 | 0 |
Execution plan 144376333
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · INDEX RANGE SCAN IDX_0011 57.1% of time · 0.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 2 Id 1 · SORT AGGREGATE 42.9% of time · 0.0% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 1 | 0.000015 | 42.9 | 0 | 0.0 | 0 | 0 | 0.000035 | 0 | |||||
| 2 | 1 | 0 | 1 | 0.000020 | 57.1 | 0 | 0.0 | 0 | 0 | 0.000020 | 0 | 0 | 68536 |
Aggregation (COUNT, SUM, MAX...)
SORT AGGREGATE
Computes the aggregate functions and returns one row.
- Good when
- Cheap in itself: the cost is in the operations below.
- Bad when
- Almost never.
- In the plan, check
- The operations below it.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#59 · SELECT
sql_id b5sr13avtw1wahv 3080587146Text
select pos#,intcol#,col#,spare1,bo#,spare2,spare3 from icol$12 where obj#=:1
- 1 ICOL$, table of index I_ICOL1: plan operation 2
- 2 ICOL$: plan operation 1
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000175 | 100.0 | 9 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 6 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000047 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000000 | 0.000080 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 6 | 0.000000 | 0.000046 | 0 | 12 | 0 | 5 | 0 |
| CLOSE | 1 | 0.000000 | 0.000002 | 0 | 0 | 0 | 0 | 0 |
Execution plan 299250003
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · INDEX RANGE SCAN I_ICOL1 100.0% of time · 58.3% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 2 Id 1 · TABLE ACCESS BY INDEX ROWID ICOL$ 0.0% of time · 41.7% of logical reads
Visits the table row by row from the index: unselective index or missing the columns the filter uses.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 5 | 2 | 0.000000 | 0.0 | 5 | 41.7 | 0 | 0 | 0.000017 | 12 | 2 | 20 | ||
| 2 | 1 | 5 | 2 | 0.000024 | 100.0 | 7 | 58.3 | 0 | 0 | 0.000024 | 7 | 1 | 42 |
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#60 · SELECT
2 variantsText
select SYS_CONTEXT(:s,:s) from dual
- 1 operation 1 (FAST DUAL) has no object of its own in the text
Shape text: the literals became :s (text) and :n (number).
Variants that cost the most
| Calls | Inclusive (s) | Literals |
|---|---|---|
| 8 | 0.000 | '***', '***' |
| 4 | 0.000 | '***', '***' |
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000168 | 100.0 | 12 | |
| cpu | 0.000000 | 0.0 | 3 | |
| cpu | 0.000000 | 0.0 | 3 | |
| cpu | 0.000000 | 0.0 | 3 | |
| cpu | 0.000000 | 0.0 | 3 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 3 | 0.000000 | 0.000067 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 3 | 0.000000 | 0.000040 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 3 | 0.000000 | 0.000054 | 0 | 0 | 0 | 3 | 0 |
| CLOSE | 3 | 0.000000 | 0.000007 | 0 | 0 | 0 | 0 | 0 |
Execution plan 1388734953
From the STAT lines in the trace; plan written 2 times, showing the slowest recording.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 FAST DUAL | 1 | 1 | 0.000002 | 100.0 | 0 | 0.0 | 0 | 0 | 0.000002 | 0 | 2 |
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#61 · DELETE
sql_id 0wcdzux2jrnaahv 1159450954Text
delete from superobj$ where COL_0054 = :1
- 1 I_SUPEROBJ1 does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 2)
- 2 operation 1 (DELETE SUPEROBJ$) has no object of its own in the text
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000160 | 100.0 | 3 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000052 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000000 | 0.000103 | 0 | 1 | 0 | 0 | 0 |
| CLOSE | 1 | 0.000000 | 0.000005 | 0 | 0 | 0 | 0 | 0 |
Execution plan 2453887050
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · INDEX UNIQUE SCAN I_SUPEROBJ1 75.0% of time · 100.0% of logical reads
- 2 Id 1 · DELETE SUPEROBJ$ 25.0% of time · 0.0% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 0 | 0.000002 | 25.0 | 0 | 0.0 | 0 | 0 | 0.000008 | 1 | |||||
| 2 | 1 | 0 | 1 | 0.000006 | 75.0 | 1 | 100.0 | 0 | 0 | 0.000006 | 1 | 0 | 72 |
Delete
DELETE
Deletes the rows returned by the row source below.
- Good when
- Few rows, found through an index.
- Bad when
- Too many rows; an unindexed foreign key on the child table locks the whole table.
- In the plan, check
- Rows of the row source below.
Unique key lookup
INDEX UNIQUE SCAN
Looks up a single key in a unique index (PK or UNIQUE): goes down from the root block through the branch blocks to the key's leaf block.
- Good when
- Almost always: it reads only the index height (BLEVEL + 1 blocks).
- Bad when
- As the inner of a NESTED LOOPS with millions of outer rows: cheap per execution, expensive in total.
- In the plan, check
- Exec: thousands of executions add up even with a low self LIO in each one.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#62 · DELETE
sql_id 75x8vfbd29wathv 3659854169Text
delete from tab_stats$ where obj#=:1
- 1 IDX_0009 does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 2)
- 2 operation 1 (DELETE TAB_STATS$) has no object of its own in the text
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000132 | 100.0 | 3 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000028 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000000 | 0.000095 | 0 | 1 | 0 | 0 | 0 |
| CLOSE | 1 | 0.000000 | 0.000009 | 0 | 0 | 0 | 0 | 0 |
Execution plan 2667651180
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 2 · INDEX UNIQUE SCAN IDX_0009 71.4% of time · 100.0% of logical reads
- 2 Id 1 · DELETE TAB_STATS$ 28.6% of time · 0.0% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 0 | 0.000002 | 28.6 | 0 | 0.0 | 0 | 0 | 0.000007 | 1 | |||||
| 2 | 1 | 0 | 1 | 0.000005 | 71.4 | 1 | 100.0 | 0 | 0 | 0.000005 | 1 | 0 | 431 |
Delete
DELETE
Deletes the rows returned by the row source below.
- Good when
- Few rows, found through an index.
- Bad when
- Too many rows; an unindexed foreign key on the child table locks the whole table.
- In the plan, check
- Rows of the row source below.
Unique key lookup
INDEX UNIQUE SCAN
Looks up a single key in a unique index (PK or UNIQUE): goes down from the root block through the branch blocks to the key's leaf block.
- Good when
- Almost always: it reads only the index height (BLEVEL + 1 blocks).
- Bad when
- As the inner of a NESTED LOOPS with millions of outer rows: cheap per execution, expensive in total.
- In the plan, check
- Exec: thousands of executions add up even with a low self LIO in each one.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#63 · SELECT
sql_id 0jgs3t6330f5bhv 2251307179Text
select sys.dbms_standard.login_user from dual
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| cpu | 0.001000 | 787.4 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| unaccounted-for | -0.000873 | -687.4 | 4 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000021 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000000 | 0.000010 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 1 | 0.001000 | 0.000094 | 0 | 0 | 0 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000002 | 0 | 0 | 0 | 0 | 0 |
Execution plan 1388734953
From the STAT lines in the trace.
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | FAST DUAL | 1 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 2 |
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#64 · SELECT
sql_id gxm90qnbtvr9thv 396221753Text
SELECT COUNT(*) FROM ALL_VIEWS WHERE OWNER = '***' AND COL_0064 = '***'
- 1 I_OBJ5 does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 8)
- 2 USER$ does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 6)
- 3 USER$ (table of index I_USER1) does not appear in the text; it comes from a view, a synonym or recursive SQL (operation 7)
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000105 | 100.0 | 4 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000020 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000000 | 0.000048 | 0 | 0 | 0 | 0 | 0 |
| FETCH | 1 | 0.000000 | 0.000036 | 0 | 5 | 0 | 1 | 0 |
| CLOSE | 1 | 0.000000 | 0.000001 | 0 | 0 | 0 | 0 | 0 |
Execution plan 1166547797
From the STAT lines in the trace.
Where the plan spends time by each operation's own value, without that of the operations below it
- 1 Id 8 · INDEX RANGE SCAN I_OBJ5 34.9% of time · 60.0% of logical reads
Scans a wide range of the index: check the selectivity and the column order. - 2 Id 6 · TABLE ACCESS BY INDEX ROWID USER$ 11.6% of time · 20.0% of logical reads
Visits the table row by row from the index: unselective index or missing the columns the filter uses. - 3 Id 7 · INDEX UNIQUE SCAN I_USER1 18.6% of time · 20.0% of logical reads
| Id | Operation | Exec. | Rows | Rows/exec | Estimated | Self time (s) | % time | Self LIO | % LIO | PR | PW | Time (s) | CR | Cost | obj |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 0.000008 | 18.6 | 0 | 0.0 | 0 | 0 | 0.000043 | 5 | ||||||
| 2 | 0 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000035 | 5 | ||||||
| 3 | 0 | 1 | 0.000002 | 4.7 | 0 | 0.0 | 0 | 0 | 0.000035 | 5 | 4 | ||||
| 4 | 0 | 1 | 0.000003 | 7.0 | 0 | 0.0 | 0 | 0 | 0.000033 | 5 | 3 | ||||
| 5 | 0 | 1 | 0.000002 | 4.7 | 0 | 0.0 | 0 | 0 | 0.000030 | 5 | 3 | ||||
| 6 | 2 | 1 | 1 | 0.000005 | 11.6 | 1 | 20.0 | 0 | 0 | 0.000013 | 2 | 1 | 22 | ||
| 7 | 3 | 1 | 1 | 0.000008 | 18.6 | 1 | 20.0 | 0 | 0 | 0.000008 | 1 | 0 | 46 | ||
| 8 | 1 | 0 | 1 | 0.000015 | 34.9 | 3 | 60.0 | 0 | 0 | 0.000015 | 3 | 2 | 40 | ||
| 9 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 0 | 75 | |||
| 10 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 1 | 47 | |||
| 11 | 0 | 2 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | ||||
| 12 | 0 | 10 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | 62 | |||
| 13 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 0 | ||||
| 14 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 0 | ||||
| 15 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 3 | ||||
| 16 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 1 | 47 | |||
| 17 | 0 | 1 | 0.000000 | 0.0 | 0 | 0.0 | 0 | 0 | 0.000000 | 0 | 2 | 39 |
Aggregation (COUNT, SUM, MAX...)
SORT AGGREGATE
Computes the aggregate functions and returns one row.
- Good when
- Cheap in itself: the cost is in the operations below.
- Bad when
- Almost never.
- In the plan, check
- The operations below it.
Filter
FILTER
Applies a predicate to the rows of the row source below. With two row sources, executes the second (a subquery that was not unnested) for each row of the first.
- Good when
- A single row source, or a subquery executed only a few times (FILTER caches the results already computed).
- Bad when
- Subquery executed row by row (high Exec on the second row source): allowing unnesting or rewriting it as a join usually solves it.
- In the plan, check
- Exec of the second row source.
Nested loops join
NESTED LOOPS
For each row of the outer (driving) row source, executes the inner row source.
- Good when
- Few rows in the outer and selective index access in the inner. Returns the first rows quickly (good for FIRST_ROWS).
- Bad when
- Many rows in the outer: the inner runs thousands of times. It usually comes from an underestimated cardinality in the outer; a HASH JOIN would read each side only once.
- In the plan, check
- Exec of the inner operations and, in the outer, Estimated compared with Rows/exec.
Table access by index ROWID
TABLE ACCESS BY INDEX ROWID
Accesses the table one row at a time by the ROWIDs returned by the index scan right below.
- Good when
- Few rows, or rows stored close together in the table (low clustering factor).
- Bad when
- Many scattered rows (high clustering factor): almost one block read per row. Or a filter predicate applied only here that discards most of what the index returned: the index is missing that predicate's column.
- In the plan, check
- Rows of this operation compared with those of the index scan right below: if far fewer remain here, the filter is on the table, not in the index.
Unique key lookup
INDEX UNIQUE SCAN
Looks up a single key in a unique index (PK or UNIQUE): goes down from the root block through the branch blocks to the key's leaf block.
- Good when
- Almost always: it reads only the index height (BLEVEL + 1 blocks).
- Bad when
- As the inner of a NESTED LOOPS with millions of outer rows: cheap per execution, expensive in total.
- In the plan, check
- Exec: thousands of executions add up even with a low self LIO in each one.
Index range scan
INDEX RANGE SCAN
Goes down to the first leaf block of the range and walks, in order, the leaf blocks within the range set by the access predicate.
- Good when
- Narrow range: the access predicate uses the leading index columns with equality and few keys remain.
- Bad when
- Wide range (many leaf blocks), a predicate that does not use the leading index column (it becomes a filter predicate inside the index), or many executions as the inner of a NESTED LOOPS. If the TABLE ACCESS above discards almost everything, the index is missing the filter's column.
- In the plan, check
- Rows returned and self LIO, compared with those of the table operation right above.
Oracle internal table (X$)
FIXED TABLE
Reads an Oracle memory structure behind the V$ views.
- Good when
- Occasional queries.
- Bad when
- Frequent queries on large V$ views (V$SQL, V$SESSION) by monitoring jobs.
Index skip scan
INDEX SKIP SCAN
Uses a composite index without the leading column in the filter: scans the index once for each distinct value of the leading column.
- Good when
- The leading index column has few distinct values.
- Bad when
- The leading column has many values: it becomes almost a full index read. An index that starts with the filtered column usually solves it.
- In the plan, check
- Self LIO compared with the Rows returned.
Click an operation to see what it does, when it is good, when it is bad and which plan columns to check. Time (s) and CR are cumulative: they include the operations below each one (the input row sources); the self values discount those operations. Oracle measures time per operation by sampling, so it may not add up between an operation and the ones below it; logical reads are always counted. Rows/exec and Estimated in red: the optimizer missed the cardinality by 10 times or more.
#65 · LOCK TABLE
sql_id 427fd0f4ay3ryhv 2293174014Text
lock table sys.mon_mods$ in exclusive mode nowait
Statement profile
| Component | Duration (s) | % | Occurrences | |
|---|---|---|---|---|
| unaccounted-for | 0.000072 | 100.0 | 3 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 | |
| cpu | 0.000000 | 0.0 | 1 |
Calls
| Call | Count | CPU (s) | Duration (s) | Disk (PIO) | Consistent (CR) | Current (CU) | Rows | Misses |
|---|---|---|---|---|---|---|---|---|
| PARSE | 1 | 0.000000 | 0.000054 | 0 | 0 | 0 | 0 | 0 |
| EXEC | 1 | 0.000000 | 0.000015 | 0 | 0 | 0 | 0 | 0 |
| CLOSE | 1 | 0.000000 | 0.000003 | 0 | 0 | 0 | 0 | 0 |
Object 188047 · IDX_0001
index- Wait (s)
- 0.931
- Occurrences
- 1,877
- Top events
- db file sequential read · Disk file operations I/O
Where it appears in the trace
- Statement #7, operation 2 INDEX FULL SCAN IDX_0001
The ready-to-run database queries are on the object page, in the console.
Object 187750
- Wait (s)
- 0.165
- Occurrences
- 18,336
- Top events
- direct path read
The ready-to-run database queries are on the object page, in the console.
Object 1008999 · TAB_0005
table- Wait (s)
- 0.023
- Occurrences
- 17
- Top events
- enq: RO - fast object reuse · local write wait · reliable message
Where it appears in the trace
- Statement #1, operation 2 TABLE ACCESS FULL TAB_0005
- Statement #2, operation 2 TABLE ACCESS FULL TAB_0005
The ready-to-run database queries are on the object page, in the console.
Object 226 · IDL_CHAR$
table- Wait (s)
- 0.017
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #12, operation 1 TABLE ACCESS BY INDEX ROWID IDL_CHAR$
The ready-to-run database queries are on the object page, in the console.
Object 107 · I_DEPENDENCY2
index- Wait (s)
- 0.016
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #14, operation 7 INDEX RANGE SCAN I_DEPENDENCY2
- Statement #14, operation 14 INDEX RANGE SCAN I_DEPENDENCY2
The ready-to-run database queries are on the object page, in the console.
Object 227 · IDL_UB2$
table- Wait (s)
- 0.016
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #15, operation 1 TABLE ACCESS BY INDEX ROWID IDL_UB2$
The ready-to-run database queries are on the object page, in the console.
Object 427 · IDX_0012
index- Wait (s)
- 0.010
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #11, operation 28 INDEX RANGE SCAN IDX_0012
- Statement #17, operation 18 INDEX RANGE SCAN IDX_0012
The ready-to-run database queries are on the object page, in the console.
Object 228 · IDL_SB4$
table- Wait (s)
- 0.009
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #19, operation 1 TABLE ACCESS BY INDEX ROWID IDL_SB4$
The ready-to-run database queries are on the object page, in the console.
Object 31 · CDEF$
table- Wait (s)
- 0.008
- Occurrences
- 2
- Top events
- db file sequential read
Where it appears in the trace
- Statement #13, operation 10 TABLE ACCESS BY INDEX ROWID CDEF$
- Statement #35, operation 1 TABLE ACCESS BY INDEX ROWID CDEF$
- Statement #46, operation 1 TABLE ACCESS BY INDEX ROWID CDEF$
The ready-to-run database queries are on the object page, in the console.
Object 19 · IND$
table- Wait (s)
- 0.008
- Occurrences
- 3
- Top events
- db file sequential read
Where it appears in the trace
- Statement #13, operation 4 TABLE ACCESS CLUSTER IND$
The ready-to-run database queries are on the object page, in the console.
Object 237 · I_IDL_CHAR1
index- Wait (s)
- 0.007
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #12, operation 2 INDEX RANGE SCAN I_IDL_CHAR1
The ready-to-run database queries are on the object page, in the console.
Object 236 · I_IDL_UB11
index- Wait (s)
- 0.007
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #18, operation 2 INDEX RANGE SCAN I_IDL_UB11
The ready-to-run database queries are on the object page, in the console.
Object 187694
- Wait (s)
- 0.006
- Occurrences
- 49
- Top events
- db file sequential read
The ready-to-run database queries are on the object page, in the console.
Object 40 · I_OBJ5
index- Wait (s)
- 0.005
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #11, operation 22 INDEX RANGE SCAN I_OBJ5
- Statement #17, operation 12 INDEX RANGE SCAN I_OBJ5
- Statement #32, operation 8 INDEX RANGE SCAN I_OBJ5
- Statement #37, operation 7 INDEX RANGE SCAN I_OBJ5
- Statement #64, operation 8 INDEX RANGE SCAN I_OBJ5
The ready-to-run database queries are on the object page, in the console.
Object 225 · IDL_UB1$
table- Wait (s)
- 0.004
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #18, operation 1 TABLE ACCESS BY INDEX ROWID IDL_UB1$
The ready-to-run database queries are on the object page, in the console.
Object 464 · IDX_0008
index- Wait (s)
- 0.003
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #23, operation 2 INDEX UNIQUE SCAN IDX_0008
The ready-to-run database queries are on the object page, in the console.
Object 384
- Wait (s)
- 0.001
- Occurrences
- 4
- Top events
- SQL*Net message from client · SQL*Net message to client
The ready-to-run database queries are on the object page, in the console.
Object 650598
- Wait (s)
- 0.000
- Occurrences
- 2
- Top events
- db file sequential read · Disk file operations I/O
The ready-to-run database queries are on the object page, in the console.
Object 187749 · TAB_0002
table- Wait (s)
- 0.000
- Occurrences
- 2
- Top events
- db file sequential read
Where it appears in the trace
- Statement #39, operation 1 TABLE ACCESS BY INDEX ROWID TAB_0002
- Statement #43, operation 1 TABLE ACCESS BY INDEX ROWID TAB_0002
The ready-to-run database queries are on the object page, in the console.
Object 239 · I_IDL_SB41
index- Wait (s)
- 0.000
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #19, operation 2 INDEX RANGE SCAN I_IDL_SB41
The ready-to-run database queries are on the object page, in the console.
Object 3 · I_OBJ#
index- Wait (s)
- 0.000
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #11, operation 24 INDEX UNIQUE SCAN I_OBJ#
- Statement #11, operation 32 INDEX UNIQUE SCAN I_OBJ#
- Statement #13, operation 5 INDEX UNIQUE SCAN I_OBJ#
- Statement #17, operation 14 INDEX UNIQUE SCAN I_OBJ#
- Statement #17, operation 22 INDEX UNIQUE SCAN I_OBJ#
- Statement #26, operation 3 INDEX UNIQUE SCAN I_OBJ#
- Statement #31, operation 3 INDEX UNIQUE SCAN I_OBJ#
The ready-to-run database queries are on the object page, in the console.
Object 54 · I_CDEF2
index- Wait (s)
- 0.000
- Occurrences
- 2
- Top events
- db file sequential read
Where it appears in the trace
- Statement #13, operation 11 INDEX RANGE SCAN I_CDEF2
- Statement #35, operation 2 INDEX RANGE SCAN I_CDEF2
The ready-to-run database queries are on the object page, in the console.
Object 18 · OBJ$
table- Wait (s)
- 0.000
- Occurrences
- 2
- Top events
- db file sequential read
Where it appears in the trace
- Statement #11, operation 1 TABLE ACCESS BY INDEX ROWID OBJ$
- Statement #11, operation 3 TABLE ACCESS BY INDEX ROWID OBJ$
- Statement #11, operation 5 TABLE ACCESS BY INDEX ROWID OBJ$
- Statement #11, operation 7 TABLE ACCESS BY INDEX ROWID OBJ$
- Statement #11, operation 9 TABLE ACCESS BY INDEX ROWID OBJ$
- Statement #11, operation 21 TABLE ACCESS BY INDEX ROWID OBJ$
- Statement #11, operation 26 TABLE ACCESS BY INDEX ROWID OBJ$
- Statement #14, operation 9 TABLE ACCESS BY INDEX ROWID OBJ$
- Statement #14, operation 16 TABLE ACCESS BY INDEX ROWID OBJ$
- Statement #17, operation 11 TABLE ACCESS BY INDEX ROWID OBJ$
- Statement #17, operation 16 TABLE ACCESS BY INDEX ROWID OBJ$
- Statement #37, operation 1 TABLE ACCESS BY INDEX ROWID OBJ$
- Statement #37, operation 10 TABLE ACCESS BY INDEX ROWID OBJ$
- Statement #48, operation 1 TABLE ACCESS BY INDEX ROWID OBJ$
The ready-to-run database queries are on the object page, in the console.
Object 187751
- Wait (s)
- 0.000
- Occurrences
- 2
- Top events
- db file sequential read · direct path read
The ready-to-run database queries are on the object page, in the console.
Object 462 · IDX_0007
index- Wait (s)
- 0.000
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #33, operation 2 INDEX UNIQUE SCAN IDX_0007
- Statement #51, operation 2 INDEX UNIQUE SCAN IDX_0007
The ready-to-run database queries are on the object page, in the console.
Object 188088 · IDX_0002
index- Wait (s)
- 0.000
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #20, operation 2 INDEX RANGE SCAN IDX_0002
- Statement #39, operation 2 INDEX RANGE SCAN IDX_0002
- Statement #41, operation 2 (no details in this file) INDEX RANGE SCAN IDX_0002
- Statement #43, operation 2 INDEX RANGE SCAN IDX_0002
- Statement #44, operation 2 (no details in this file) INDEX RANGE SCAN IDX_0002
The ready-to-run database queries are on the object page, in the console.
Object 39 · I_OBJ4
index- Wait (s)
- 0.000
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #11, operation 39 INDEX RANGE SCAN I_OBJ4
- Statement #17, operation 29 INDEX RANGE SCAN I_OBJ4
- Statement #32, operation 14 INDEX RANGE SCAN I_OBJ4
- Statement #64, operation 17 INDEX RANGE SCAN I_OBJ4
The ready-to-run database queries are on the object page, in the console.
Object 238 · I_IDL_UB21
index- Wait (s)
- 0.000
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #15, operation 2 INDEX RANGE SCAN I_IDL_UB21
The ready-to-run database queries are on the object page, in the console.
Object 9 · I_FILE#_BLOCK#
index- Wait (s)
- 0.000
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #28, operation 3 INDEX UNIQUE SCAN I_FILE#_BLOCK#
The ready-to-run database queries are on the object page, in the console.
Object 57 · I_CCOL1
index- Wait (s)
- 0.000
- Occurrences
- 1
- Top events
- db file sequential read
Where it appears in the trace
- Statement #34, operation 2 INDEX RANGE SCAN I_CCOL1
The ready-to-run database queries are on the object page, in the console.
Object 36 · I_OBJ1
indexWhere it appears in the trace
- Statement #11, operation 2 INDEX RANGE SCAN I_OBJ1
- Statement #11, operation 4 INDEX RANGE SCAN I_OBJ1
- Statement #11, operation 6 INDEX RANGE SCAN I_OBJ1
- Statement #11, operation 8 INDEX RANGE SCAN I_OBJ1
- Statement #11, operation 10 INDEX RANGE SCAN I_OBJ1
- Statement #14, operation 8 INDEX RANGE SCAN I_OBJ1
- Statement #14, operation 15 INDEX RANGE SCAN I_OBJ1
- Statement #37, operation 2 INDEX RANGE SCAN I_OBJ1
- Statement #37, operation 11 INDEX RANGE SCAN I_OBJ1
The ready-to-run database queries are on the object page, in the console.
Object 22 · USER$
tableWhere it appears in the trace
- Statement #11, operation 19 TABLE ACCESS BY INDEX ROWID USER$
- Statement #17, operation 9 TABLE ACCESS BY INDEX ROWID USER$
- Statement #32, operation 6 TABLE ACCESS BY INDEX ROWID USER$
- Statement #37, operation 12 TABLE ACCESS CLUSTER USER$
- Statement #64, operation 6 TABLE ACCESS BY INDEX ROWID USER$
The ready-to-run database queries are on the object page, in the console.
Object 46 · I_USER1
indexWhere it appears in the trace
- Statement #11, operation 20 INDEX UNIQUE SCAN I_USER1
- Statement #17, operation 10 INDEX UNIQUE SCAN I_USER1
- Statement #32, operation 7 INDEX UNIQUE SCAN I_USER1
- Statement #64, operation 7 INDEX UNIQUE SCAN I_USER1
The ready-to-run database queries are on the object page, in the console.
Object 21 · COL$
tableWhere it appears in the trace
- Statement #11, operation 23 TABLE ACCESS CLUSTER COL$
- Statement #17, operation 13 TABLE ACCESS CLUSTER COL$
- Statement #31, operation 2 TABLE ACCESS CLUSTER COL$
The ready-to-run database queries are on the object page, in the console.
Object 83 · COLTYPE$
tableWhere it appears in the trace
- Statement #11, operation 25 TABLE ACCESS CLUSTER COLTYPE$
- Statement #17, operation 15 TABLE ACCESS CLUSTER COLTYPE$
The ready-to-run database queries are on the object page, in the console.
Object 38 · I_OBJ3
indexWhere it appears in the trace
- Statement #11, operation 27 INDEX RANGE SCAN I_OBJ3
- Statement #17, operation 17 INDEX RANGE SCAN I_OBJ3
The ready-to-run database queries are on the object page, in the console.
Object 47 · I_USER2
indexWhere it appears in the trace
- Statement #11, operation 29 INDEX RANGE SCAN I_USER2
- Statement #11, operation 30 INDEX RANGE SCAN I_USER2
- Statement #11, operation 38 INDEX SKIP SCAN I_USER2
- Statement #17, operation 19 INDEX RANGE SCAN I_USER2
- Statement #17, operation 20 INDEX RANGE SCAN I_USER2
- Statement #17, operation 28 INDEX SKIP SCAN I_USER2
- Statement #32, operation 11 INDEX RANGE SCAN I_USER2
- Statement #32, operation 13 INDEX SKIP SCAN I_USER2
- Statement #64, operation 10 INDEX RANGE SCAN I_USER2
- Statement #64, operation 16 INDEX SKIP SCAN I_USER2
The ready-to-run database queries are on the object page, in the console.
Object 4 · TAB$
tableWhere it appears in the trace
- Statement #11, operation 31 TABLE ACCESS CLUSTER TAB$
- Statement #17, operation 21 TABLE ACCESS CLUSTER TAB$
- Statement #26, operation 2 TABLE ACCESS CLUSTER TAB$
The ready-to-run database queries are on the object page, in the console.
Object 62 · I_OBJAUTH1
indexWhere it appears in the trace
- Statement #11, operation 34 INDEX RANGE SCAN I_OBJAUTH1
- Statement #17, operation 24 INDEX RANGE SCAN I_OBJAUTH1
- Statement #42, operation 3 INDEX RANGE SCAN I_OBJAUTH1
- Statement #47, operation 3 INDEX RANGE SCAN I_OBJAUTH1
- Statement #64, operation 12 INDEX RANGE SCAN I_OBJAUTH1
The ready-to-run database queries are on the object page, in the console.
Object 432 · IND_STATS$
tableWhere it appears in the trace
- Statement #13, operation 6 TABLE ACCESS BY INDEX ROWID IND_STATS$
The ready-to-run database queries are on the object page, in the console.
Object 433 · IDX_0005
indexWhere it appears in the trace
- Statement #13, operation 7 INDEX UNIQUE SCAN IDX_0005
The ready-to-run database queries are on the object page, in the console.
Object 104 · DEPENDENCY$
tableWhere it appears in the trace
- Statement #14, operation 6 TABLE ACCESS BY INDEX ROWID DEPENDENCY$
- Statement #14, operation 13 TABLE ACCESS BY INDEX ROWID DEPENDENCY$
The ready-to-run database queries are on the object page, in the console.
Object 463 · MON_MODS_ALL$
tableWhere it appears in the trace
- Statement #23, operation 1 TABLE ACCESS BY INDEX ROWID MON_MODS_ALL$
The ready-to-run database queries are on the object page, in the console.
Object 14 · SEG$
tableWhere it appears in the trace
- Statement #28, operation 2 TABLE ACCESS CLUSTER SEG$
The ready-to-run database queries are on the object page, in the console.
Object 37 · I_OBJ2
indexWhere it appears in the trace
- Statement #29, operation 2 INDEX RANGE SCAN I_OBJ2
- Statement #48, operation 2 INDEX RANGE SCAN I_OBJ2
The ready-to-run database queries are on the object page, in the console.
Object 375 · RLS$
tableWhere it appears in the trace
- Statement #32, operation 9 TABLE ACCESS BY INDEX ROWID RLS$
The ready-to-run database queries are on the object page, in the console.
Object 377 · IDX_0006
indexWhere it appears in the trace
- Statement #32, operation 10 INDEX RANGE SCAN IDX_0006
The ready-to-run database queries are on the object page, in the console.
Object 32 · CCOL$
tableWhere it appears in the trace
- Statement #34, operation 1 TABLE ACCESS BY INDEX ROWID CCOL$
The ready-to-run database queries are on the object page, in the console.
Object 160 · TRIGGER$
tableWhere it appears in the trace
- Statement #37, operation 8 TABLE ACCESS BY INDEX ROWID TRIGGER$
The ready-to-run database queries are on the object page, in the console.
Object 162 · I_TRIGGER1
indexWhere it appears in the trace
- Statement #37, operation 9 INDEX RANGE SCAN I_TRIGGER1
The ready-to-run database queries are on the object page, in the console.
Object 11 · I_USER#
indexWhere it appears in the trace
- Statement #37, operation 13 INDEX UNIQUE SCAN I_USER#
The ready-to-run database queries are on the object page, in the console.
Object 61 · OBJAUTH$
tableWhere it appears in the trace
- Statement #42, operation 2 TABLE ACCESS BY INDEX ROWID OBJAUTH$
- Statement #47, operation 2 TABLE ACCESS BY INDEX ROWID OBJAUTH$
The ready-to-run database queries are on the object page, in the console.
Object 627 · MLOG$
tableWhere it appears in the trace
- Statement #45, operation 3 TABLE ACCESS CLUSTER MLOG$
The ready-to-run database queries are on the object page, in the console.
Object 626 · I_MLOG#
indexWhere it appears in the trace
- Statement #45, operation 4 INDEX UNIQUE SCAN I_MLOG#
The ready-to-run database queries are on the object page, in the console.
Object 55 · I_CDEF3
indexWhere it appears in the trace
- Statement #46, operation 2 INDEX RANGE SCAN I_CDEF3
The ready-to-run database queries are on the object page, in the console.
Object 669 · CDC_CHANGE_TABLES$
tableWhere it appears in the trace
- Statement #49, operation 1 TABLE ACCESS FULL CDC_CHANGE_TABLES$
The ready-to-run database queries are on the object page, in the console.
Object 461 · MON_MODS$
tableWhere it appears in the trace
- Statement #51, operation 1 TABLE ACCESS BY INDEX ROWID MON_MODS$
The ready-to-run database queries are on the object page, in the console.
Object 1271 · SYS_FBA_TRACKEDTABLES
tableWhere it appears in the trace
- Statement #52, operation 2 TABLE ACCESS BY INDEX ROWID SYS_FBA_TRACKEDTABLES
The ready-to-run database queries are on the object page, in the console.
Object 1272 · SYS_C001489
indexWhere it appears in the trace
- Statement #52, operation 3 INDEX UNIQUE SCAN SYS_C001489
The ready-to-run database queries are on the object page, in the console.
Object 68054 · TAB_0006
tableWhere it appears in the trace
- Statement #53, operation 2 TABLE ACCESS BY INDEX ROWID TAB_0006
The ready-to-run database queries are on the object page, in the console.
Object 68057 · IDX_0010
indexWhere it appears in the trace
- Statement #53, operation 3 INDEX RANGE SCAN IDX_0010
The ready-to-run database queries are on the object page, in the console.
Object 68536 · IDX_0011
indexWhere it appears in the trace
- Statement #58, operation 2 INDEX RANGE SCAN IDX_0011
The ready-to-run database queries are on the object page, in the console.
Object 20 · ICOL$
tableWhere it appears in the trace
- Statement #59, operation 1 TABLE ACCESS BY INDEX ROWID ICOL$
The ready-to-run database queries are on the object page, in the console.
Object 42 · I_ICOL1
indexWhere it appears in the trace
- Statement #59, operation 2 INDEX RANGE SCAN I_ICOL1
The ready-to-run database queries are on the object page, in the console.
Object 72 · I_SUPEROBJ1
indexWhere it appears in the trace
- Statement #61, operation 2 INDEX UNIQUE SCAN I_SUPEROBJ1
The ready-to-run database queries are on the object page, in the console.
Object 431 · IDX_0009
indexWhere it appears in the trace
- Statement #62, operation 2 INDEX UNIQUE SCAN IDX_0009
The ready-to-run database queries are on the object page, in the console.
Object 75 · I_VIEW1
indexWhere it appears in the trace
- Statement #64, operation 9 INDEX UNIQUE SCAN I_VIEW1
The ready-to-run database queries are on the object page, in the console.
WaitScope 1.7.0 · analyzed on the server · report exported on 2026-10-29 10:19:57