von Birgitta Hauser

Wenn in RPG und Cobol mit (embedded) SQL Informationen aus einer Tabelle/physichen Datei oder View gelesen werden, wird oft SELECT * verwendet. Egal aus welchem Grund, sei es aus alter Gewohnheit (weil mit native I/O immer der komplette Satz gelesen wird), oder weil man sich zukünftige Änderungen sparen möchte (falls eine weitere Spalte benötigt) oder der Einfachheit halber (weil man lediglich eine externe Datenstruktur der Datei definieren muss), für die SQL Performance ist SELECT * nicht die erste Wahl.

Bei der Verwendung von SQL können gezielt genau die Informationen/Spalten ausgewählt werden, die benötigt werden und das bringt einige Vorteile mit sich.

• Reduzierter/optimierter Datentransfer zwischen Datenbank und Anwendung
• Index Only Access möglich
• Einfachere Wartung bei Tabellen-Änderungen

SQL: geblockte Verarbeitung

Bei SQL werden angeforderten Daten geblockt, d.h. es wird nicht wie bei native I/O immer nur ein Datensatz/Zeile aus der Datenbank angefordert. Stattdessen werden die angeforderten Daten in Blöcken (von per Default 32KB) zusammengefasst und dann der ganze Block ausgegeben. Je weniger Blöcke gefüllt und ausgegeben werden müssen, desto weniger Transfer zwischen der Datenbank und der Anwendung ist erforderlich und umso schneller ist die Abfrage.

Wenn wir also davon ausgehen, dass eine Tabelle 100 Spalten hat, jedoch nur die Informationen aus 3 Spalten benötigt werden, werden beim SELECT * ca. 97% der Daten (abh. von der Definition und Größe der Spalten) unnötigerweise aus der Datenbank gelesen. Werden nur genau die 3 gewünschten Spalten ausgewählt werden weniger Datenblöcke genötigt und die Abfrage schneller (auch wenn sich dies nur im Nanosekunden-Bereich abspielt).

Wenn einzelne Datensätze nacheinander angefordert werden (SELECT … INTO oder klassische RPG CHAINs = Einzelzugriffe), sind die Datenblöcke nur zum Teil gefüllt, für jeden Satz jedoch erfolgt ein Transfer aus der Datenbank. In solchen Fällen ist native I/O oft sogar Schneller als SQL, weil kein Optimierungsaufwand entsteht.

Die geblockte Verarbeitung ist der Bereich, in dem SQL seinen echten Vorteil ausspielt.

Dies ist auch ein Grund, weswegen man prüfen sollte ob und wie die Tabellen/physische Dateien oder Views vrknüpft werden können, um die benötigten Informationen möglichst in einer einzigen Abfrage zu ermitteln.

Der Optimizer kann das komplette Statement analysieren, ggf. umschreiben und optimieren.

Index-Only-Access ermöglichen

Werden nur die benötigten Spalten ausgewählt, könnte es sein, dass der Optimizer einen Zugriffsweg findet, bei dem sich alle angeforderten Informationen in Schlüssel-Spalten hinterlegt sind. Damit genügt es die Schlüssel-Werte zu lesen. Ein Zugriff auf den eigentlichen Datensatz, ist nicht mehr notwendig.

Diese Art des Zugriffes nennt man Index Only Access (IOA). Index Only Access ist die schnellste Methode die gewünschten Daten zu ermitteln. Index Only Access ist sowohl für (normale) Binary Radix Tree Indices als auch Encoded Vector Indices (EVIs) mit oder ohne INCLUDE-Anweisungen möglich. Bei Encoded Vector Indices spricht man dann von EOA = Encoded Vector Index Only Access.

Verwendet man SELECT  * anstatt die Spalten auszuwählen, nimmt man dem Optimizer jede Möglichkeit einen Index Only Access auszuführen.

Einfachere Wartung bei Tabellenänderungen

Die Auswahl nur der benötigten Spalten erleichtert auch die langfristige Wartung. Wird eine neue Spalte zur Tabelle hinzugefügt, müssen lediglich die Programme oder Prozeduren angepasst werden, die diese neue Spalte tatsächlich verwenden. Alle anderen Quellen müssen nicht einmal neu kompiliert werden.

Im Gegensatz dazu müssen die Programme/Quellen in denen mit native I/O auf die Datei /Tabelle zugegriffen wird, wegen der internen Ein-/Ausgabe-Strukturen nach der Erweiterung immer neukompiliert werden.

Damit werden Dateierweiterungen bei der Verwendung von embedded SQL und gezielter Auflistung der Spalten, wesentlich vereinfacht.

Praktische Empfehlungen für Db2-for-i-Entwickler

• Listen Sie stets nur die tatsächlich benötigten Spalten auf.
• Ermöglichen Sie (embedded) SQL soweit möglich in Blöcken zu arbeiten.
• Reduzieren Sie die Anzahl an SQL-Statements. Ermitteln Sie die benötigten Daten in möglichst wenigen SQL Statements, in dem Sie Tabellen, physische Dateien und Views verknüpfen und verdichten.
• Halten Sie die Tür für Index-Only-Zugriffe offen.
• Machen Sie zukünftige Tabellenänderungen für den Rest der Anwendung weniger aufwendig.

Das führt im Endeffek tzu einer besseren Performance und saubererem wartbaren Code.

Überlegen Sie sich beim nächsten Mal, wenn sie versucht sind SELECT * zu verwende, ob wirklich alle Spalten benötigt werden. In den meisten Fällen lautet die Antwort nein. Es lohnt sich also auf ein bisschen Bequemlichkeit zugunsten einer besseren Performance und zukünftigen Wartbarkei zu verzichten.

Besuchen Sie unsere Kurse von Birgitta Hauser.

EDU004 SQL Abgragen für Beginner 19.10.26 – 21.10.26
EDU023 Erstellen und Verarbeiten von JSON mit SQL 12.10.26 – 13.10.26
EDU029 Db2 und IBM i Services 02.11.2026 – 03.11.2026
EDU028 Data Centric 16.11.2026 – 18.11.2026
EDU026 Programmier-Sprache SQL 30.11.2026 – 02.11.2026
EDU025 DB2 – Performance Überwachung und Analyse 07.12.2026 – 09.12.2026