Объявить глобальную временную таблицу Vs создать глобальную временную таблицу в DB2

создавал GLOBAL TEMPORARY TABLE в DB2. и когда я занимаюсь серфингом, у меня есть два способа творить. 1. Заявлять 2. Создавать.

1. DECLARE GLOBAL TEMPORARY TABLE SESSION.TEMP_EMP
      (EMPNO  CHAR(6) NOT NULL,
       SALARY DECIMAL(9, 2),
       BONUS  DECIMAL(9, 2),
       COMM   DECIMAL(9, 2)) WITH REPLACE ON COMMIT PRESERVE ROWS ;

2. CREATE GLOBAL TEMPORARY TABLE TMPDEPT
      (TMPDEPTNO   CHAR(3)      NOT NULL,
       TMPDEPTNAME VARCHAR(36)  NOT NULL,
       TMPMGRNO    CHAR(6),
       TMPLOCATION CHAR(16) ) ON COMMIT PRESERVE ROWS ;

и с сайта IBM я получил информацию, которая create является лучшей, поскольку она является постоянной, позволяя всем сеансам пользователей получать доступ к одному и тому же определению таблицы без необходимости объявлять его при запуске и многих других преимуществ.

ссылка : http://www.ibm.com/developerworks/data/library/techarticle/dm-0912globaltemptable/

и у меня было несколько запросов при использовании create over declare:

  1. Я не мог найти Replace ключевое слово при использовании CREATE GLOBAL TEMPORARY TABLE .

  2. рассмотрим один сценарий, я открываю соединение и выполняю хранимую процедуру,
    в этой хранимой процедуре я создаю глобальную временную таблицу и с помощью этой хранимой процедуры я вызываю другую хранимую процедуру которые опять имеют same создать инструкцию Temp table .. что будет в этом случае.. сделать его бросьте любую ошибку, так как обе таблицы naes одинаковы и находятся в одном соединении?

  3. объявить сеанс и создать не имеет?? связано ли это с persistant??

  4. в performace мудрый, что лучше? Объявить temp или создать temp?

  5. предложите некоторые сценарии для лучшего использования declare / create !!

7
db2 performance stored-procedures temp-tables

2 ответов

есть хорошая статья от Крейга С. Маллинса это охватывает основные различия между ними. Для большинства целей они работают одинаково.

созданные временные таблицы создаются в DSNDB07, который является рабочей базой данных файлов (та же область хранения, используемая во время операторов SQL, которые нуждаются в рабочем хранилище). Объявленные временные таблицы хранятся во временном табличном пространстве, которое необходимо создать.

есть некоторые минусы для CTT:

  • поскольку они не являются постоянными, некоторые типичные операции с базой данных включая блокировку, ведение журнала и восстановление, не применяются к созданным временная таблица.

  • индексы не могут быть созданы на созданных временных таблицах, поэтому весь доступ является полным сканированием таблицы.

  • ограничения не могут быть созданы для созданных временных таблиц.

  • null-единственное значение по умолчанию, разрешенное для столбцы создаются временная таблица.

  • на созданные временные таблицы не могут ссылаться утилиты DB2.

  • созданные временные таблицы не могут быть указаны в качестве объекта инструкция update.

  • при удалении из созданной временной таблицы, все строки должны быть удаленный.

  • хотя представления могут быть созданы на созданных временных таблицах, с Проверить опцию can не уточняется.

DTT обычно гораздо гибче:

  • объявленные временные таблицы могут иметь индексы и ограничения проверки определили по ним.

  • вы можете выдавать инструкции UPDATE и расположенные инструкции DELETE против объявленной временной таблицы.

  • можно неявно определить столбцы объявленной временной таблицы и использовать результат таблица из выборки.

теперь для ваших нумерованных вопросов:

1. & 2. Нет. Я верю (и я не уверен на 100%, если это точно, наш магазин в значительной степени использует DTTs во всех случаях), что CTT объявляется один раз (по в дБА), а затем программисты могут использовать его в любой сессии. Каждое соединение будет иметь свою собственную копию, и как только приложение отключится, данные, хранящиеся в этом CTT в этом сеансе, пойдут прочь.

3. SESSION - это просто идентификатор схемы для DTTs. Это показывает, что это временно таблица, которая не сохраняется.

4. Думаю, у обоих будет примерно одинаковое выступление. Они будут быстрее чем обычные таблицы, потому что блокировка, ведение журнала, восстановление и т. д. не будут применяться.

5. В общем, я бы сказал, что DTTs-это путь, но CTTs полезно (как говорит Крейг в своей статье):

(CTTs) следует учитывать в первую очередь при отсутствии обновления временных данных необходим и доступ к временным данным является чисто последовательным.

8
  1. мы обнаружили, что созданные временные таблицы-в нашем случае-выполнены намного лучше, чем DTTs. Это может быть исключением (это зависит), но толчком к изменению было количество инкрементных Привязок, которые выполнялись с DTTs. Для каждой транзакции требовалось 23 временных таблицы. Мы провели параллельный тест и обнаружили, что CTTs приводит к огромным падениям как cpu, так и In_DB2. Мы также видели падения в ожидании блокировки/защелки и обнаружили, что с CTTs наш процессор ZIIP начал превышать наш процессор GP, который делает всех счастливыми.

нам не нужны индексы DTT или доступ к обновлению и не нужны никакие RI.

0