Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

21.08.1992

Mögliche Ursachen für Performance-Probleme

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.