Die Performance-Probleme bei DB2-Anwendungen können zahlreiche Ursachen haben. Dieter Koenen hat einige häufig anzutreffende zusammengestellt und gleichzeitig Vorschläge zur Beseitigung gemacht.
Suboptimale SQL-Statements: Aus der Table TKUNDE sollen alle Kunden mit dem Bonitätskennzeichen A oder B gelesen werden (mögliche Werte: A, B, C). Auf der Spalte BON_KZ liegt ein Index .
Die Query
SELECT - FROM TKUNDE WHERE BON_KZ < > 'C' ist wesentlich langsamer als SELECT - FROM TKUNDE WHERE BON_KZ = 'A' OR BON _KZ = 'B'
weil DB2 in der ersten Variante 1 den Index nicht benutzt.
Unvorteilhaftes Anwendungsdesign: Aus der Tabelle TUMSATZ (Volumen: 12 Mllionen Rows) sollen Umsätze einer vergangenen Periode (< = DEL-DAT) gelöscht werden (Löschvolumen: zirka 1 Million Rows). Auf der Spalte KD-NR (Wertebereich 1 - 999 999) liegt ein Index.
Die Query
DELETE FROM TUMSATZ WHERE UMS_DAT <= :DEL-DAT
würde einwandfrei laufen, aber die gesamte Tabelle für alle anderen Programme sperren (Lock Escalation).
Richtiger Ansatz (in Cobol):
PERORM TI -DELETE UNTIL KD-NR < 999999.
TI-DELETE.
ADD KD-NR + 1000 ... DELETE FROM TUMSATZ WHERE UMS_DAT < = :DEL-DAT AND KD_NR < = :KD-NR
Die Schleife wird tausendmal durchlaufen. Die Laufzeit ist geringfügig länger. Aber es wird nur ein Tausendstel der Ressoursen blockiert. Die Lock Escalation wird vermieden.
Nieht optimiertes Datenbankdesign: In der Tabelle TKUNDE werden in aufsteigender Reihenfolge Kunden erfaßt (Schlüssel: KD_NR).
Normaler Tablespase-Parameter für PCTFREE (gibt an, wieviel Prozent einer Page nach dem LOAD oder REORG freigelassen wird):
PCTFREE 5
Aus Performance-Gründen ist es günstiger, die Kundendaten auch in physisch sequentieller Reihenfolge in der Tablespace abzuspeichern.
Optimaler Parameter daher:
PCTFREE 0
(Alle Rows werden am Ende eingefügt.)
Ein weiteres Ärgernis: Die hausspezifischen Standards für DB2-Anwendungsprogramme (zum Beispiel kein SELECT -) stehen sorgfältig formuliert in einem Dokument, werden aber permanent verletzt, weil niemand die Einhaltung konsequent überwacht.
Probleme für den Daten-Manager:
Die DB2-Strukturen spiegeln nicht das im Data-Dietionary dokumentierte Entity-Relationship-Modell wieder, weil im Data-Distionary
a) keine Verknüpfung zwischen Physik (DB2-Strukturen) und Logik (Entity-Relationship-Modell) implementiert wurde oder
b) Änderungen in der Physik nicht im Data-Dictionary nachdokumentiert wurden.