DB2-Anwendungen: Maßnahmen zur Verbesserung der Performance

Qualitätssicherung sorgt für die Einhaltung der Standards

21.08.1992

*Dieter Koenen ist Wirtschaftsinformatiker und Consultant bei Origin Information Technology GmbH, Hamburg.

Die Ursachen für Performance-Probleme mit DB2-Anwendungen sind vielfältig: suboptimale SQL-Statements, unvorteilhaftes Anwendungsdesign, nicht optimiertes Datenbankdesign etc. Ein probates Mittel dagegen ist ein konsequent praktiziertes Qualitätssicherungs-Konzept. Dieter Koenen* stellt ein solches geschlossenes Konzept vor, das sich mit relativ geringem Aufwand realisieren läßt.

Wenn DV eingeführt- oder eine bestehende Anwendung modifiziert beziehungsweise ersetzt wird, sind Probleme im wahrsten Sinne des Wortes programiert. Die Performance von DB2-Anwendungen ist ein solches Problem. So kann es beispielsweise vorkommen, daß Benutzer zwischen Dialogschritten der neukonzipierten High-Tech-Anwendung zum Kaffeetrinken gehen können oder Mitarbeiter aus der Produktionssteuerung das Rechenzentrum statt um Mitternacht um 4 Uhr morgens verlassen, weil neu eingesetzte Batch-Programme einfach nicht enden wollen.

Diese und andere Probleme (siehe Kasten) betreffen alle involvierten Funktionen bei der Erstellung einer DB2-Anwendung wie:

- Datenadministration,

- Datenbankadministration,

- Anwendungsentwicklung,

aber auch alle Ebenen, in deren sich eine Anwendung -befinden kann:

- User-Ebene,

- Projektebene,

- Systemtest,

- Produktion,

- Wartungsebene.

Ein probates Mittel zur Eindämmung der Probleme ist ein konsequent praktiziertes Qualitätssicherungs-Konzept.

Ein Mix aus organisatorischen und technischen Komponenten kann bei der Realisierung eines solchen Konzeptes helfen. Das Konzept ist funktional übergreifend (Daten- und Datenbankadministration, Anwendungsentwicklung), partiell und sukzessive realisierbar. Einzelne der verwendeten Bausteine werden von Softwareherstellern angeboten.

Das Konzept basiert auf folgenden Rahmenbedingungen:

- im Data-Dictionary dokumentiertes Entity-Relationship-Modell der DB2-Projekte,

- zentrale Qualitätssicherung des dezentral erstellten Entity-Relationship-Modells durch die

Datenadministration,

- zentrales Datenbankdesign durch die Datenbankadministration,

- flexibel erweiterbares Ebenenkonzept, das mindestens aus Projekt-, Systemtest- und Produktionsebene besteht,

- eine für alle Anwendungsentwickler verbindliche und ausschließliche Software-Produktionsumgebung.

Jedes Ziel erfordert bestimmte Maßnahmen. Zum leichteren Verständnis sind die im folgenden aufgeführten Ziele mit Buchstaben, die Maßnahmen mit Ziffern gekennzeichnet.

Die Ziele-Maßnahmen-Matrix (siehe Abbildung) ermöglicht so eine schnelle Zuordnung der einzelnen Komponenten. Folgende Ziele werden mit dem Qualitätssicherungskonzept erreicht:

A) Verknüpfung der logischen Ebene (Entity-Relationship-Modell) mit der Physik (DB2-Strukturen),

B) keine Veränderung von Tabellenstrukturen außerhalb der Datenbankadministration,

C) technisch gutes Design von, DB2-Anwendungen,

D) Minimierung von Performance-ungünstigen SQL-Statements, die in die Produktion übergeben werden,

E) strikte Einhaltung der hausspezifischen Normen und Standards.

Das Erreichen des einen oder anderen Zieles erfordert mehrere Maßnahmen. Die Numerierung des Maßnahmenkatalogs drückt also weder eine Hierarchie noch eine Abfolge aus, sondern wurde, wie schon gesagt, nur zur leichteren Zuordnung in der Matrix vorgenommen.

1. Zentrale Generierung von Datenbankstrukturen durch die Datenbankadministration:

Die Erstellung von Datenbankstrukturen (Database, Tablespaces, Tables, Views, Indizes, Synonyme) mit der Database Definiton Language (DDL) erfordert spezielles DB2-Know-how, etwa für Parameter bei CREATE TABLESPACE.

Der Aufwand läßt sich durch die Generierung der DDL aus dem logischen Datenmodell im Data-Dictionary minimieren. Gleichzeitig wird eine Verknüpfung zwischen dem logischen Modell im Data-Dictionary und der physischen Abbildung im DB2 hergestellt.

2. Definition der Systemtestebene als Master-Ebene:

Software-Unternehmen arbeiten in der Regel bei der Erstellung von Anwendungssystemen in verschiedenen Ebenen, zum Beispiel der Systemtest-, der Projekt-, der Teilprojekt- und der User-Ebene. Die Ebenen gelten analog für die DB2-Objekte der Projekte.

Die Systemtestebene bildet die Master-Ebene und liegt für DB2-Strukturen im alleinigen Verantwortungsbereich der Datenbankadministration. Somit können die Projektmitarbeiter in der Systemtestebene, die vor der Produktionsübergabe durchlaufen werden muß, keine DDL-Änderungen vornehmen.

3. Zentrale Generierung von Copy-Strecken (Declaration Generator DCLGEN) für alle Ebenen durch die Datenbankadministration:

Der DCLGEN schreibt Cobol-, PL1- oder C-Definitionen für Tables oder Views in eine Bibliothek. DB2 benutzt die Definitionen als I/O-Bereich zum Einlesen oder zur Ausgabe von Daten in Anwendungsprogrammen.

Der einmalige DCLGEN durch die Datenbankadministration in eine zentrale Bibliothek und eine einheitliche Software-Produktionsumgebung, in der nur diese eine Bibliothek allokiert wird, verhindern die unabgestimmte Modifikation von Tables oder Views durch Anwendungsentwickler. Die zentralen Copy-Strecken gelten für alle Ebenen; von Projektmitarbeitern modifizierte Tables würden nicht mehr zu den Copy-Strecken passen.

4. Betreuung von, DB2-Projekten durch einen Projektberater aus der Datenbankadministration:

Der Projektberater aus der Datenbankadministration hat eine beratende und unterstützende Funktion im Projekt. Er transferiert sein Know-how an die DB2-Anwendungsentwickler, die besonders nach der Einführungsphase von DB2 über kein ausgeprägtes DB2-Wissen verfügen.

Er betreibt "präventive" Qualitätssicherung durch

- Beratung beim DB2-Anwendungsdesign,

- Unterstützung beim Codieren von Performance-optimierten SQL-Statements sowie

- Abstimmung und Durchführung von DDL-Anderungen.

Der Einsatz eines Projektberaters kostet Zeit und somit Geld. Aber Kosten-Leistungs-Aspekte rechtfertigen dieses Engagement durchaus. Das Unternehmen erhält qualitativ höherwertige DB2-Anwendungen und besser ausgebildete DB2-Anwendungsentwickler.

5. Aufbereiteter Explain nach jedem Bind mit Returncode:

Alle SQL-Statements eines Programms werden bei DB2-Precompile in ein Database Request Module (DBRM) extrahiert und zu einem -Plan gebunden, der zum Ablaufzeitpunkt des Programms aktiviert wird. DB2 legt beim Plan-Bind die internen Zugriffswege fest, zum Beispiel, welcher Index einer Tabelle benutzt wird.

Der optionale Bind-Parameter EXPLAIN(YES) veranlaßt das DB2, diese Informationen in eine DB2-Tabelle, der Plan-Tabelle, abzulegen. Die Interpretation der Plan-Tabelle gestaltet sich für den ungeübten DB2-Programmierer schwierig und umständlich.

Qualitätssicherungs-Ansatz:

Ein Dienstprogramm, das bei jedem Bind mit EXPLAIN(YES) ängestoßen wird, liest die Plan-Tabelle und stellt den Inhalt dem Programmierer in einer einfach zu lesenden und zu interpretierenden Form zur Verfügung. Ein DB2-Programm enthält unter Umständen eine Vielzahl von SQL-Statements. Um dem Programmierer die Prüfung des Explains für alle SQL-Statements zu ersparen, wird jeder interpretierte Zugriff mit einem Returncode versehen:

RC = 0 - keine Probleme (zum Beispiel Index-Zugriff)

RC = 4 - Warning (zum Beispiel Sort Order By)

RC = 6 - kritischer Zugriff (zum Beispiel Tablespace-Scan).

Außerdem wird der höchste Returncode ausgegeben. Das Dienstprogramm hat keine Informationen über die Art des Anwendungsprogramms. So kann beispielsweise ein Tablespace-Scan in einem Batch-Programm oder auch in einem Online-Programm (wenn die betreffende Table nur wenige Einträge hat) durchaus Sinn machen. Hier ist die Interpretation des Programmierers gefordert.

6. Simulation der Produktionsumgebung im Test-DB2:

Wie zuvor beschrieben, legt DB2 beim Bind die internen Zugriffswege fest. Ein internes DB2-Dienstprogramm, der Optimizer, erarbeitet die Zugriffsalgorithmen und schreibt sie in DB2-internen Tabellen (Catalog-Tabellen) fest. Wichtige Kriterien dabei sind das Mengengerüst und die Verteilung der Daten in den Tabellen und Indizes. DB2 verwaltet diese Werte ebenfalls in Catalog-Tabellen.

Auch andere Zugriffspfade als im Testsystem

Das normalerweise signifikant geringere Datenvolumen im Testsystem führt zur berechtigten Kritik am EXPLAIN im Test-DB2:

Im Produktions-DB2 kann sich der Optimizer aufgrund des größeren Datenvolumens für andere Zugriffspfade als im Testsystem entscheiden. Der EXPLAIN im Test-DB2 ist daher für die Performance von SQL-Statements in der produktiven Umgebung nicht aussagekräftig.

Das Problem ist lösbar, wenn ein Dienstprogramm regelmäßig die entsprechenden Werte aus dem Produktionskatalog liest und damit den Catalog im Test-DB2 manipuliert. Außerdem können für noch nicht produktive Tabellen angenommenne Produktionswerte über eine Online-Oberfläche vorgegeben werden.

7. Überwachung der in die Systemtestebene und Produktion übergebenen Pläne:

Zur Kontrolle der Systemtestebene und der Produktion erhält der Datenbankadministrator jeden Morgen eine Liste aller übergebener Pläne mit Returncode (im aufbereiteten EXPLAIN nach jedem -Bind). Der Bind eines Plans in der Systemtestebene oder in der Produktion erfordert in diesem Verfahren zwingend den Parameter EXPLAIN(YES). Die Auswertung der Plan-Tabelle erfolgt durch ein Dienstprogramm, das obige Liste erstellt und für jedes Programm zusätzlich einen aufbereiteten EXPLAIN in ein Dataset ablegt.

Die Datenbankadministration erkennt somit schon bei der Übergabe in die Systemtestebene kritische Pläne (RC = 6), der Projektberater kann mit dem betroffenen Programmierer die SQL-Statements optimieren.

Porformance-ungünstige SQL-Statements minimiert

Die präventive Qualitätssicherung in der Systemtestebene reduziert die Anzahl der in die Produktion übergebenen Performance-ungünstigen SQL-Statements auf ein Minimum. Potentielle Produktionsprobleme werden durch die Produktionsliste frühzeitig erkannt und können vor Beginn der Haupt-Online-Zeit oder der abendlichen Batch-Verarbeitung behoben werden.

8. Automatischer Check der Programm-Source auf Einhaltung von Standards:

Folgende Standards sind für DB2-Anwendungen empfehlenswert:

- Zugriffe ausschließlich auf Views (und nicht auf Tabellen),

- keine Verwendung der AUTH-ID, sie qualifiziert-Objekte gleichen Namens im selben DB2-System,

- keine Verwendung von Dynamic SQL,

- keine Zugriffe auf Catalog-Tabellen,

- kein SELECT,

- keine Verwendung von DDL-Statements und

- Verwendung einer Standardabendroutine.

Die Prüfung auf Einhaltung der Standards erfolgt in einer für alle Anwendungsentwickler verbindlichen und ausschließlichen Software-Produktionsumgebung durch ein Dienstprogramm vor der Compilierung durch Scanning des Precompile-Outputs. Bei Verletzung von Standards wird die Compilierung nicht durchgeführt. Eine Exception-Tabelle verwaltet begründete Ausnahmen.

Qualitätssicherung mit Spin-off-Effekt

Um die Qualitätssicherungs-Ziele zu erreichen, müssen folgende technische Realisierungen einmalig durchgeführt werden:

- Konzeption und Codierung der Dienstprogramme für EXPLAIN-Aufbereitungs- und Auswert-Programm, Catalog-Transfer- und Manipulationsprogramme, List-Programm promoteter Pläne und Standard-Check-Programm sowie,

- Konzeption und Realisierung einer Generierungsfunktion aus dem Data-Dictionary.

Kontinuierlich durchzuführen sind.

- zentrale Generierung von DDL und Copy-Strecken,

- Prüfung der Liste promoteter Pläne und

- Kontrolle der Systemtestebene.

Spin-off-Effekte, etwa Produktivitätssteigerung der Arbeit in der DBA und der Anwendungsentwicklung, Transfer von DB2-Know-how an die Anwendungsentwicklung, bessere Kommunikation zwischen Anwendungsentwicklung und Datenbankadministration, rechtfertigen diesen Aufwand.

Es gibt kein generelles Qualitätssicherungs-Konzept für DB2-Anwendungen. Softwarebetriebe haben unterschiedliche Aufbau- und Ablauforganisationen sowie Plattformen und differieren bei der Gewichtung von Qualitätssicherungs-Aspekten. Viele Bausteine können durch den Einsatz von Werkzeugen realisiert werden. Besonders manche CASE-Tools dekken viele Anforderungen ab. Unabhängig davon wie viele Bausteine installiert werden, gilt: Qualitätssicherung lohnt sich und ist mit relativ geringem Aufwand zu realisieren.