Использование временных таблиц

1. Сохранение промежуточных этапов расчетов (DWH, DSS), которые нужны только внутри сеанса/транзакции.
2. Реализация нетривиальной логики зависящей от времени хранения данных (например, пользовательская нумерация транзакций).
3. Передача данных между приложением и БД.
4. Кэширование данных на время сеанса/транзакции.

Есть некоторые особенности в части оптимизации запросов с использованием GTT.
После вставки данных в GTT оптимизатор не обладает актуальной статистикой по количеству строк в неё. “На лету” собирать статистику - не вариант по разным причинам.
На помощь приходит хинт cardinality, который подсказывает оптимизатору порядок строк хранящихся в GTT.

Пример:

select /*+ cardinality(t2 1000) */
   from table t1
   join gtt_tab t2 on …

В Oracle18c появились Private Temporary Table, немного другая концепция. Если вам интересно, могу как-нибудь запилить видос по ним.

В целом, GTT очень полезные таблицы - их нужно знать и применять.

#временныетаблицы #cardinality

Всем привет!
Немного задержался с решением задачки. Постановку см. в посте 05.10.

Пройдемся по плану:
▫️ строка collection iterator говорит, о том что на шаге происходит работа с коллекцией.
▫️ pickler fetch - работа с “обработанной”/“форматированной”/”подготовленной” коллекцией, полученной из табличной функции.
▫️ num2tbl - табличная функция.
▫️ 8168 - предполагаемое количество элементов коллекции.

Код для воспроизведения:

create or replace type t_numbers is table of number(38);
/

create or replace function num2tbl return t_numbers
is
begin
  return t_numbers(1, 2, 3, 4, 5);
end;
/

select * from table(num2tbl());

Если же в запросе не используется табличная функция, а выборка идет из коллекции, описание шага в плане будет:
collection iterator constructor fetch

Пример:

select * from t_numbers(1, 2, 3, 4, 5);

Насчет числа 8168
Это предполагаемое количество и оно, чаще всего, не совпадает с реальным значением. Ну и что с того? А то что, оптимизатор может построить неверный план. И вместо, скажем nested loops join, будет выбран hash join. Что приведет к деградации времени выполнения запроса.

Как с этим бороться?
Например, дать подсказку оптимизатору, хотя бы о порядке элементов коллекции.
Хинт cardinality может помочь. Например, так:

select /*+ cardinality(t 5) */ * from table(num2tbl()) t;

Более подробно об этом и других хинтах, я расскажу в своем курсе по оптимизации.
Он пока в разработке. Если интересно поучаствовать в пилотной группе - пишите в личку.

Хорошую статью закинул @alexeionin. Посмотрите на досуге.

Всем хорошей трудовой недели! 👍💻

#решениезадачи #cardinality #оптимизация