Wer Performance-Probleme bei SQL-Statements auf IBM i analysieren möchte, kommt am SQL Planning Cache kaum vorbei. Er liefert wichtige Informationen über ausgeführte SQL-Statements und deren Optimierungspläne. Diese Daten helfen dabei, Performance-Probleme gezielt zu erkennen und zu beheben.
In diesem Beitrag zeige ich, wie du den Planning Cache mit QSYS2.DUMP_PLAN_CACHE exportierst und effizient auswertest, ohne unnötig große Dateien zu erzeugen.
Warum du den Dump des Planning Cache einschränken solltest
Der Planning Cache enthält oft sehr viele Einträge.
Wenn du QSYS2.DUMP_PLAN_CACHE ohne Parameter ausführst, erzeugst du schnell eine extrem große Datei.
Deshalb solltest du den Befehl niemals ohne Filterparameter ausführen.
Beispiel 1: Alle Einträge einer Bibliothek exportieren
Angenommen, wir möchten alle SQL-Statements aus der Bibliothek DBDAT analysieren.
CALL QSYS2.DUMP_PLAN_CACHE(
FILESCHEMA => 'DBDAT',
FILENAME => 'UBRTEST',
SQL_STATEMENT_TEXT_FILTER => 'DBDAT'
);
Voraussetzungen
-
Das Schema
UBRTESTmuss vorher angelegt werden. -
Der Filter sorgt dafür, dass nur relevante Statements exportiert werden.
Auswertung der Daten
Nach dem Dump kann die erzeugte Tabelle direkt abgefragt werden:
SELECT *
FROM UBRTEST.DBDAT;
So lassen sich Optimierungspläne, Laufzeiten und andere relevante Informationen analysieren.
Beispiel 2: Ein konkretes Statement über den QRO_HASH finden
Wenn man ein bestimmtes SQL-Statement identifizieren möchte, kann man den QRO_HASH-Wert verwenden:
CALL QSYS2.DUMP_PLAN_CACHE(
FILESCHEMA => 'SNAPSHOTS',
FILENAME => 'SALES',
QRO_HASH => '1AED7DC9'
);
Vorteil: Es wird nur genau das gewünschte Statement exportiert ideal für gezielte Analysen.
Was ist der QRO_HASH-Wert und wozu dient er?
Der QRO_HASH-Wert ist ein eindeutiger Hash-Wert, den IBM i für jedes SQL-Statement erzeugt.
Mit diesem Wert identifizierst du ein Statement eindeutig – unabhängig davon, wie oft oder von welchem Job es ausgeführt wird.
Der QRO_HASH hilft dir besonders, wenn:
-
viele ähnliche SQL-Statements im Planning Cache existieren,
-
du ein bestimmtes Statement gezielt analysieren möchtest,
-
du Performance-Probleme auf ein konkretes SQL zurückführen willst.
QRO_HASH-Wert ermitteln
Du kannst den QRO_HASH direkt aus dem SQL Planning Cache auslesen, zum Beispiel über die Systemsicht QSYS2.PLAN_CACHE:
So erhältst du eine Liste relevanter SQL-Statements inklusive des QRO_HASH-Werts.
Diesen Hash-Wert nutzt du anschließend in QSYS2.DUMP_PLAN_CACHE, um genau dieses Statement zu exportieren und detailliert zu analysieren.
Vorteil: Statt den gesamten Planning Cache zu dumpen, analysierst du gezielt einzelne Statements.
Format der Ausgabedatei
Das Format der erzeugten SQL-Tabelle ist in der IBM-Dokumentation beschrieben:
-
Tabellenformat:
https://www.ibm.com/docs/en/i/7.5.0?topic=formats-sql-table -
Beschreibung der Procedure:
https://www.ibm.com/docs/en/i/7.5.0?topic=services-dump-plan-cache-procedure
Fazit
Mit QSYS2.DUMP_PLAN_CACHE analysierst du den SQL Planning Cache auf IBM i gezielt und effizient.
Wenn du Filterparameter sinnvoll einsetzt, begrenzt du Datenmengen, findest relevante Statements schneller und optimierst SQL-Performance systematisch.
Ich hoffe, diese Vorgehensweise hilft euch bei der Analyse eurer SQL-Statements weiter.
Du suchst nach mehr Wissen zur SQL-Performance: Der Lehrgang EDU025 vermittelt praxisnah, wie der SQL Planning Cache auf IBM i analysiert, QSYS2.DUMP_PLAN_CACHE effizient genutzt und SQL-Statements gezielt optimiert werden.

