Чтобы увидеть преобразованный запрос, используемый оптимизатором, вы должны использовать трассировку 10053. Но план выполнения более удобен и обычно достаточно хорош.
Пример схемы
Для быстрого примера эта схема содержит две простые таблицы, и каждая строка во второй таблице должна существовать в первом таблица.
--drop table test2;
--drop table test1;
create table test1(a number primary key);
create table test2(a number primary key references test1(a));
Мы хотим создать простой запрос, в котором преобразованный запрос будет отличаться от исходного. Для этого в приведенном ниже запросе есть ненужное объединение. Поскольку существует внутреннее соединение, и каждая строка в TEST2 должна существовать один раз и только один раз в TEST1, Oracle не требуется выполнять соединение. Вместо этого Oracle нужно только читать из одной таблицы или индекса из TEST2.
select count(*) new_name_for_hard_parse_01
from test1
join test2 on test1.a = test2.a;
10053 Trace
Чтобы найти точный запрос, используемый оптимизатором, вам нужно сгенерировать 10053 след. Например:
alter session set events '10053 trace name context forever, level 1';
select count(*) new_name_for_hard_parse_02
from test1
join test2 on test1.a = test2.a;
alter session set events '10053 trace name context off';
(Обратите внимание, как я использовал другое имя для столбца. Вам нужно изменить запрос и принудительно выполнить анализ. В противном случае Oracle может просто повторно использовать существующий план выполнения. и не будет генерировать трассировку.)
Подождите минуту, и файл появится где-то в каталоге трассировки. В зависимости от версии и конфигурации файл может находиться в USER_DUMP_DEST или в подкаталоге DIAGNOSTIC_DEST. Например, на моем P C это был файл D: \ app \ jon \ virtual \ diag \ rdbms \ orcl12 \ orcl12 \ trace \ orcl12_ora_22576.tr c
Откройте файл и найдите следующий раздел:
...
Final query after transformations:******* UNPARSED QUERY IS *******
SELECT COUNT(*) "NEW_NAME_FOR_HARD_PARSE_02" FROM "JHELLER"."TEST2" "TEST2"
....
Файл трассировки объясняет различные преобразования и показывает окончательный запрос.
Но вы почти никогда не хотите использовать Oracle файлы трассировки. Файлы трассировки неудобны, команды недокументированы и не работают должным образом, и у вас не всегда будет доступ к файловой системе сервера. Для 99,9% Oracle настройки производительности трассировка - это пустая трата времени.
План выполнения
План выполнения - это более быстрый способ определить, как выполняется запрос, что, вероятно, вам Вы заинтересованы.
explain plan for
select count(*) new_name_for_hard_parse_01
from test1
join test2 on test1.a = test2.a;
select * from table(dbms_xplan.display);
Результаты:
Plan hash value: 4187894267
------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 0 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | INDEX FULL SCAN| SYS_C009744 | 1 | 0 (0)| 00:00:01 |
------------------------------------------------------------------------
План выполнения показывает, как использовался только один объект. Это не объясняет, что использовалось исключение объединения, вы должны сделать это.