Database Reference
In-Depth Information
SQL> set autotrace traceonly explain
SQL> select 1 from dual;
Execution Plan
----------------------------------------------------------
Plan hash value: 1388734953
-----------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-----------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 2 (0)| 00:00:01 |
| 1 | FAST DUAL | | 1 | 2 (0)| 00:00:01 |
-----------------------------------------------------------------
SQL> set autotrace traceonly explain statistics
SQL> select 1 from dual;
Execution Plan
----------------------------------------------------------
Plan hash value: 1388734953
-----------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-----------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 2 (0)| 00:00:01 |
| 1 | FAST DUAL | | 1 | 2 (0)| 00:00:01 |
-----------------------------------------------------------------
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
415 bytes sent via SQL*Net to client
419 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
L.: „
Die Einstellung ‚set autotrace traceonly explain' bereitet bei Selects noch eine Überra-
schung. Bei dieser Einstellung wird ein Parse Call ohne Ausführung für ein Select-Kommando
gemacht. Dieser Parse Call erzeugt aber einen Cursor in der SQL-Area.
“
P.: „
Kann es ein Problem sein?
“
L.: „
Stelle Dir vor, dass Du im Nachhinein die jeweilige SQL-Anweisung ausführst. In
diesem Fall nimmt Oracle den bereits vorhandenen Cursor aus der SQL-Area, was Dich u. U.
überraschen kann. Das kann sogar die Performanz Deiner Anwendung beeinträchtigen,
wenn diese SQL-Anweisung dort ausgeführt wird. Ich zeige das an dem folgenden Beispiel.
“
