Temporäre Tabellen in Db2 for i – effizient, flexibel, aber bitte mit Plan

Was sind temporäre Tabellen?

Auf IBM i arbeitest Du mit DECLARE GLOBAL TEMPORARY TABLE (kurz: DGTT). Die Tabelle ist nicht persistent, erscheint nicht im normalen Systemkatalog und kann nicht mit anderen Anwendungskontexten geteilt werden. Jede Verbindung bzw. jeder relevante Job-Kontext erhält seine eigene Instanz.

DECLARE GLOBAL TEMPORARY TABLE SESSION.TEMP_EMP (
    EMPNO CHAR(6) NOT NULL,
    SALARY DECIMAL(10, 2),
    DEPTNO CHAR(3)
)
WITH REPLACE
ON COMMIT PRESERVE ROWS
NOT LOGGED;

WITH REPLACE ersetzt eine bereits vorhandene gleichnamige temporäre Tabelle im selben Anwendungskontext und löscht dabei deren bisherige Zeilen. ON COMMIT PRESERVE ROWS bewahrt die Zeilen nach einem Commit. Ohne diese Option gilt der Standard ON COMMIT DELETE ROWS – die Zeilen können beim Commit also verschwinden, sofern kein abhängiger WITH HOLD-Cursor offen ist. NOT LOGGED reduziert den Logging-Overhead, bedeutet aber auch: Änderungen an dieser Tabelle werden bei einem Rollback nicht wie normale Tabellenänderungen zurückgenommen.

DGTT auf IBM i: SESSION und QTEMP

Ein häufiges Missverständnis: Weil die Tabelle technisch in QTEMP landet, deklariert man sie schnell auch so. Das ist bei DECLARE GLOBAL TEMPORARY TABLE auf IBM i jedoch nicht der richtige Weg. Der Qualifier ist SESSION. Wird kein Qualifier angegeben, nimmt Db2 for i implizit SESSION an.

Optional: FOR SYSTEM NAME

Wenn Du mit langen SQL-Namen arbeitest, kannst Du bei Bedarf zusätzlich einen IBM-i-Systemnamen vergeben. Dieser Systemname ist auf zehn Zeichen begrenzt und kann in sehr systemnahen Szenarien hilfreich sein. Für normale SQL-Nutzung ist die Option aber meist nicht nötig.

DECLARE GLOBAL TEMPORARY TABLE SESSION.TEMP_EMPLOYEE_REPORT (
    EMPNO CHAR(6),
    DEPTNO CHAR(3),
    TOTAL_SALARY DECIMAL(15,2)
)
FOR SYSTEM NAME TEMPEMP01
WITH REPLACE
ON COMMIT PRESERVE ROWS
NOT LOGGED;

SQL-Beispiele zum Nachbauen

1. Struktur aus einer bestehenden Tabelle ableiten

Du kannst die Struktur einer DGTT aus einer Abfrage ableiten oder direkt von einer bestehenden Tabelle übernehmen:

-- Variante A: Mit SELECT
DECLARE GLOBAL TEMPORARY TABLE SESSION.TEMP_EMP AS (
  SELECT EMPNO, SALARY, DEPTNO
  FROM MYLIB.EMPLOYEES
)
WITH NO DATA
ON COMMIT PRESERVE ROWS
NOT LOGGED;

-- Variante B: Mit LIKE (sehr sauber)
DECLARE GLOBAL TEMPORARY TABLE SESSION.TEMP_EMP 
LIKE MYLIB.EMPLOYEES
WITH REPLACE
ON COMMIT PRESERVE ROWS
NOT LOGGED;

2. CTE für ein einmaliges Zwischenergebnis

Wenn Du ein Zwischenergebnis nur innerhalb einer einzelnen SQL-Anweisung brauchst, ist eine CTE oft eleganter:

WITH TempSales AS (
  SELECT ORDERID, SUM(AMOUNT) AS TOTAL
  FROM MYLIB.SALES
  GROUP BY ORDERID
)
SELECT *
FROM TempSales
WHERE TOTAL > 1000;

3. CTE und temporäre Tabelle kombinieren

Für mehrstufige Verarbeitung kann eine DGTT sinnvoll sein: Einmal befüllen, mehrfach auswerten, optional indizieren.

DECLARE GLOBAL TEMPORARY TABLE SESSION.TEMP_AVGSAL (
  DEPTNO CHAR(3),
  AVG_SAL DECIMAL(11,2)
)
WITH REPLACE
ON COMMIT PRESERVE ROWS
NOT LOGGED;

INSERT INTO SESSION.TEMP_AVGSAL
WITH Aggregated AS (
  SELECT DEPTNO, DECIMAL(AVG(SALARY), 11, 2) AS AVG_SAL
  FROM MYLIB.EMPLOYEES
  GROUP BY DEPTNO
)
SELECT DEPTNO, AVG_SAL
FROM Aggregated;

TRUNCATE TABLE vs. WITH REPLACE

WITH REPLACE ist praktisch, wenn Du eine temporäre Tabelle robust neu deklarieren möchtest. Für wiederholte Verarbeitungsschritte mit gleicher Struktur ist es jedoch meist sauberer, die Tabelle einmal zu erstellen und danach mit TRUNCATE TABLE zu leeren.

DECLARE GLOBAL TEMPORARY TABLE SESSION.MONTHLY_SALES (
    MONTH_ID INT,
    TOTAL_SALES DECIMAL(15,2)
)
WITH REPLACE
ON COMMIT PRESERVE ROWS
NOT LOGGED;

-- Januar laden
INSERT INTO SESSION.MONTHLY_SALES
SELECT 1, SUM(AMOUNT)
FROM MYLIB.SALES
WHERE ORDER_DATE BETWEEN DATE('2026-01-01') AND DATE('2026-01-31');

SELECT * FROM SESSION.MONTHLY_SALES;

-- Tabelle für den nächsten Schritt leeren
TRUNCATE TABLE SESSION.MONTHLY_SALES REUSE STORAGE;

-- Februar laden
INSERT INTO SESSION.MONTHLY_SALES
SELECT 2, SUM(AMOUNT)
FROM MYLIB.SALES
WHERE ORDER_DATE BETWEEN DATE('2026-02-01') AND DATE('2026-02-28');

Indizes auf temporären Tabellen

Temporäre Tabellen sind nicht automatisch gut optimiert. Wenn Du größere Zwischenergebnisse mehrfach filterst, joinst oder sortierst, kann ein Index auf der DGTT helfen.

CREATE INDEX SESSION.IDX_TEMP_EMP_DEPT
ON SESSION.TEMP_EMP (DEPTNO, EMPNO);

Wann solltest Du temporäre Tabellen einsetzen?

Praxisbeispiel: Monatsbericht für Verkaufsdaten

Szenario: Ein Unternehmen auf IBM i erstellt monatlich einen Bericht über Umsätze pro Abteilung. Die Rohdaten liegen in MYLIB.SALES. Statt dieselbe Aggregation mehrfach auszuführen, wird das verdichtete Ergebnis in einer temporären Tabelle gespeichert.

DECLARE GLOBAL TEMPORARY TABLE SESSION.TEMP_SALES_REPORT (
    DEPTNO CHAR(3),
    TOTAL_SALES DECIMAL(15,2)
)
WITH REPLACE
ON COMMIT PRESERVE ROWS
NOT LOGGED;

INSERT INTO SESSION.TEMP_SALES_REPORT
SELECT DEPTNO, SUM(AMOUNT) AS TOTAL_SALES
FROM MYLIB.SALES
WHERE ORDER_DATE BETWEEN DATE('2026-05-01') AND DATE('2026-05-31')
GROUP BY DEPTNO;

CREATE INDEX SESSION.IDX_TEMP_SALES_DEPT
ON SESSION.TEMP_SALES_REPORT (DEPTNO);

SELECT *
FROM SESSION.TEMP_SALES_REPORT
ORDER BY TOTAL_SALES DESC;

Vorteile in diesem Szenario

• Lesbarkeit: Die Aggregation ist klar von der Ausgabe getrennt.
• Wiederverwendung: Dasselbe Zwischenergebnis kann für mehrere Auswertungen genutzt werden.
• Isolation: Jeder Job arbeitet mit seiner eigenen temporären Tabelle.
• Optionales Tuning: Bei Bedarf kann ein Index auf der temporären Tabelle erstellt werden.

Nachteile und Grenzen

• Zusätzlicher Schritt: Die Tabelle muss befüllt werden. Das lohnt sich nicht für jedes kleine SELECT.
• Planung nötig: Ohne Index oder mit falschem Index kann eine DGTT langsam bleiben.
• Flüchtigkeit: Nach Ende des Anwendungskontexts ist alles weg. Für Audit, Debugging oder Wiederanlauf brauchst Du andere Mechanismen.
• Commit-Verhalten: Ohne ON COMMIT PRESERVE ROWS kann ein Commit Deine Zeilen löschen.

Vergleich: DGTT, CTE, View, persistente Tabelle

Die folgende Tabelle ist bewusst qualitativ gehalten. Feste Millisekundenwerte sind ohne konkrete Hardware, Datenmenge, PTF-Stand, Jobkonfiguration und SQL-Plan schnell irreführend.

Db2 ist nicht gleich Db2: IBM i, LUW, z/OS

Bei temporären Tabellen ist die Plattform wichtig. Db2 for i, Db2 LUW und Db2 for z/OS verwenden teilweise ähnliche Begriffe, aber nicht immer dieselbe Syntax. Für IBM i ist DECLARE GLOBAL TEMPORARY TABLE der zentrale Weg. Syntax und Verhalten aus LUW/z/OS-Artikeln solltest Du nicht ungeprüft auf IBM i übertragen.

Best Practices für IBM i Developer

DROP TABLE SESSION.TEMP_SALES_REPORT;

Fazit

Quellen