Die schönste relationale Datenbasis nutzt nichts, wenn die darauf laufende Anwendung keine akzeptable Antwortzeit hat. Es gibt vielfältige Möglichkeiten, schon in der Entwicklungsphase DB2-Anwendungen mit hoher Leistungsfähigkeit zu produzieren. Daneben kann es notwendig sein, laufende Applikation zu "tunen". Wo setzt man an und was ist zu beachten?

Die Leistungsfähigkeit eines Informationssystems hängt unter anderem von folgenden Faktoren ab:

- Hardware-Umgebung,

- Auswahl und Auslegung der Systemsoftware,

- Anwendungsprogrammdesign,

- logisches Datenbankdesign,

- physisches Datenbank-Design,

- durchschnittliche Auslastung des Systems,

- Lastspitzen des Systems,

- Datenübertragungsraten,

Zwei dieser Stellgrößen sollen unter Gesichtspunkten des Tunings betrachtet werden:

- Physisches Datenbankdesign

und

- Anwendungsprogramm-Design (in Ausnahmefällen).

Bei einem Umfeld eines Outsourcing-Anbieters wie der Alldata -560 produktive DB2-Tabellen, wovon die größte 20 Millionen Reihen hat; jeden Tag durchschnittlich 500 000 Transaktionen - ist es weder möglich, Betrachtungen des Gesamtsystems anzustellen, noch einzelne Transaktionen ohne vorherige Auswahl zu optimieren.

Man benötigt ein schlüssiges Konzept, eine Kombination aufeinander abgestimmter Werkzeuge und passender Analysemethoden, um mit minimalem Aufwand in kürzester Zeit meßbare Ergebnisse zu erzielen.

Das Leistungsspektrum des Outsourcing-Anbieters und Softwareherstellers beinhaltet ein dreistufiges Phasenkonzept für Tuning-Projekte in der CICS/DB2-Umgebung.

Als wichtigstes Werkzeug wird die Average-ResponseTime-Statistik des CICS eingesetzt Diese Statistik erfaßt die Anzahl der Aufrufe einer Transaktion, die verbrauchte, summierte CPU-Zeit sowie die durchschnittliche Verweildauer einer Transaktion im System.

Als weiteres Werkzeug zur Bestimmung und Auswahl von Tuning-Kandidaten dient der DB2Command 'EXPLAIN'. Aufgrund des physischen Datenbankdesigns, des Zustands der Datenbank, des gegebenen Mengengerüsts und der Formulierung der SQL-Befehle gibt der 'EXPLAIN'-Command Aufschluß über die vom DB2-Optimizer gewählte Zugriffsstrategie. Unterstützung bietet der Platinum Plan-Analyzer.

Mit diesem Werkzeug ist es auch möglich, Performance-relevante Datenbankzustände (fehlender, falscher oder überflüssiger Index, falsche oder schlechte Partitionierung etc.) anzuzeigen .

Die Tabellen SYSINDEXES, SYSTABLESPACE und SYSTABLES geben Aufschluß über den Zustand der Datenbank sowie über die Relevanz und Aussagekräftigkeit von Indizes. Entscheidend kann hier zum Beispiel die Reihenfolge der Benennung von Indexspalten sein. Der Einsatz einer Workbench zur Analyse des DB2-Kataloges, wie etwa Platinum Catalog Facility, kann dabei sehr hilfreich sein und hat sich im Einsatz bewährt. Mit der Einbeziehung des DB2-Katalogs, der reichhaltig Informationen über den Status der Datenbank enthält, vermeidet man, daß durch einseitige Performance-Verbesserungen im Umfeld nachteilige Effekte entstehen. So kann zum Beispiel ein zusätzlicher Index, der eine Abfragetransaktion optimiert, von Nachteil für eine ebenso wichtige Einfügetransaktion sein (siehe Abbildung).

Um in schwierigen Fällen weitere Informationen über mögliche Ursachen für schlechte Leistung zu gewinnen, kann noch der CICS-Joblog herangezogen werden. Mögliche Diskrepanzen zwischen der Anzahl der Transaktionen und der Anzahl der aufgerufenen Unter- und Hauptprogramme werden auf diese Weise aufgedeckt.

Das kann ein guter Hinweis auf ungünstige Programmierung sein, wenn alle DB2-Zugriffe in Unterprogrammen abgelegt sind.

Eine weitere mögliche Informationsquelle stellt der DB2-Performance-Monitor dar. Hiermit kann ein Trace der DB2-Aktivitäten erstellt werden. Der DB2-Performance-Monitor ermöglicht zwar eine sehr detaillierte Untersuchung, sollte aber wegen seiner immensen Informationsmenge und der hohen Maschinenbelastung nur punktuell und zeitlich auf wenige Minuten begrenzt eingesetzt werden. Er eignet sich mehr zur Untersuchung als zur Bestimmung von Tuning-Kandidaten.

In Phase 1: Auswahl der Tuning Kandidaten

In der ersten Phase gilt es, mittels geeigneter Werkzeuge die Tuning-Kandidaten zu bestimmen. Als Grundsatz dient die "ganzheitliche Untersuchung" der CICS/DB2-Transaktionen. Also keine Optimierung einzelner SQL-Befehle im Quelltext, sondern Betrachtung der CICS-Transaktionen im produktiven Umfeld.

Die Average-Response-Time-Statistik des CICS liefert alle Informationen, um anhand der Kriterien

- hoher CPU-Zeit-Verbrauch,

- große Anzahl der Aufrufe,

- hohe durchschnittliche Verweildauer im System

fünf bis maximal zehn Tuning-Kandidaten für die nächste Stufe der Untersuchung auswählen zu können.

Um im Sinne einer ABC-AnaIyse den Aufwand für Tuning-Maßnahmen zu begrenzen, ihren Nutzeffekt jedoch gleichzeitig zu optimieren, ist ein Kriterienkatalog entwickelt worden, mit dem sich die Transaktionen bewerten lassen. Die Erfahrung zeigt, daß das Systemverhalten bereits dann signifikant verbessert wird, wenn man sich auf die "aufwendigsten" Transaktionen konzentriert. Also auf Transaktionen mit vergleichsweise hoher durchschnittlicher Verweildauer und hohem CPU-Zeit-Verbrauch. Betrachtet man mehr als zehn Transaktionen in einem Durchlauf, besteht die Gefahr, daß die wechselseitigen Abhängigkeiten zu komplex werden.

In Phase 2: Analyse der Tuning Kandidaten

Aus der Phase 1 gehen nur solche Transaktionen in die zweite Phase, deren Verhalten nicht schon durch erste Analyseschritte signifikant verbessert wird. Für die Ermittlung des möglichen Optimierungspotentials eines Kandidaten hat sich mittlerweile die Methode des Soll- und Ist-Zugriffsprofils eingebürgert.

Zur Bestimmung eines Soll-Zugriffsprofils gehören die Einzelschritte:

1. Ermittlung der Zugriffshäufigkeit pro Verarbeitungseinheit,

2. Definition des Soll-Zugriffspfades, das heißt, in welcher Reihenfolge erfolgt der

Zugriff, insbesondere bei Joins,

3. Bestimmen der Anzahl zu lesender Daten-Pages, unter Berücksichtigung der

Indexnutzung und des Clustering,

4. Bestimmung der zu erwartenden Treffermenge, also der Anzahl der zu lesenden

Reihen.

Aus den oben erarbeiteten Informationen kann ein Näherungswert für durchschnittliche Systemantwortzeiten errechnet werden. Als Faustregel dient die Formel:

Summe über ((Anzahl Aufrufe) x (Anzahl Pages) x 25 msec).

Weicht die Average-Response-Time in der CICS-Statistik erheblich vom theoretischen Wert ab, lohnt es sich, ein Ist-Zugriffsprofil zu erstellen, um die Ursache für den Performance-Verlust zu klären.

Der Ermittlung des Ist-Zugriffsprofils dienen die Informationen:

1. Programmablaufanalyse,

2. Festlegung und Interpretation des Ist-Zugriffspfades laut EXPLAIN,

3. Trace zur Ermittlung der gelesenen Pages,

4. tatsächliche Treffermenge in Reihen pro SQL-Aufruf.

Phase 3: Behebung der Performance-Probleme

Die Phasen 1 und 2 liefern genügend Informationen über die Tuning-Kandidaten, um Ursachen für Performance-Probleme zu benennen und Maßnahmen abwägen und durchführen zu können.

Im einzelnen werden folgende Schritte vollzogen:

1) EXPLAIN-Analyse. Sie gibt Aufschluß, ob unvorhergesehene Tablespace-Scans durchgeführt werden, ob also der Datenbereich sequentiell durchsucht wird, wo Index-Scans notwendig sind (zum Beispiel durch unnötige Sortierung verursacht), ob und welche Indizes genutzt werden und welche Index-Spalten für den Zugriffspfad herangezogen werden.

2) SQL-Statement-Analyse.

Hier muß untersucht werden, ob SQL-Befehle verwendet werden, die eine Indexnutzung verhindern, zum Beispiel 'NOT <' anstatt ' > '. Performance-relevant ist auch, wenn mehr Spalten selektiert als tatsächlich gebraucht werden. Sollten die Zugriffe nicht qualifiziert genug sein, beispielsweise dann, wenn eine Join-Bedingung vergessen worden ist, kann das genauso negative Auswirkungen haben wie die Formulierung von SubQueries anstelle von Join-Bedingungen.

3) Umfeld-Analyse. Im Umfeld eines SQL-Statements gibt es noch weitere Aspekte, die Performance-relevant sind. Hier eine Aufzählung ohne Wertung: - Die Aufteilung eines Clustering-Index, also die physische Verteilung von Daten über Wertebereichsintervalle, kann für ein bestimmtes SQL-Statement ungünstig sein. Vor Änderung eines solchen Indexes sollten aber Abhängigkeiten zu anderen SQL-Statements und Transaktionen geklärt werden.

- Ist eine Tabelle sehr klein oder wird der Index vom Optimizer nicht verwendet, ist er überflüssig und sollte gelöscht werden.

- Tabellen und Indizes können einen Status haben, der verbesserungsfähig ist - durch eine Reorganisation mit anschließendem Statistiklauf und erneutem Planbind, also Ermittlung der Zugriffsstrategie und Anbinden der Zugriffsmodule an die Datenbank.

- Ist der Freiplatz für die Menge der Einfügungen zu klein gewählt, wirkt sich das negativ auf die Laufzeit aus, wenn der Freiplatz erschöpft ist (PCTFREE).

- Die Größe des Bufferpools, des DB2-internen Hauptspeicherbereichs, hat entscheidende Auswirkungen auf die Performance. Hier kann sich eine Umverteilung der Systemressourcen oder eine Erweiterung der Hardware bezahlt machen.

- Überprüfung von Deadlock und Timeout-Situationen. Bei ungünstiger Partitionierung und häufiger Frequentierung von Daten-Pages kommt es oft zu Deadlock- und/oder Timeout-Situationen, die durch sinnvollere Aufteilung zu vermeiden sind.

Sollte trotz dieser Tuning-Maßnahmen kein zufriedenstellender Erfolg eintreten, muß an den verbleibenden Faktoren, zum Beispiel Hardware-Konfiguration, Auswahl und Auslegung der Systemsoftware, oder aber an der fachlichen Anforderung gearbeitet werden.

Um ständig Informationen über den aktuellen Status zu bekommen und zeitnah in das DB2-System eingreifen zu können, wurde das Tool DBKIS entwickelt. Es besteht aus den Hauptkomponenten Berichtswesen und Frühwarnsystem.

Der Datenbankadministrator erhält damit täglich Informationen, Basiswerte und Kennzahlen für Tuning-Maßnahmen:

- ungültige Pläne,

- Tabellenräume in Copy-Pending-Status,

- Überwachung des Plattenplatzes,

- aufwendige SQL-Statements,

- ungünstig parametrisierte Tabellen,

- überflüssige Tabellen,

- überflüssige Indizes,

- Sicherheitsschwachstellen.

Mit diesem System wurde ein wesentlicher Schritt getan, die Produktionssicherheit und die Qualität der Anwendungen zu verbessern. An Weiterentwicklungen wird kontinuierlich gearbeitet.

Die Erfahrungen mit diesem Vorgehen in Tuning-Projekten im Hause und bei Kunden sind sehr positiv. Hier ging es um die nachträgliche Optimierung von Anwendungssystemen. Daneben besteht natürlich die dringende Notwendigkeit, bereits bei der Entwicklung von Anwendungssystemen auf einen hohen Qualitätsstandard und ein leistungsfähiges Design zu achten. Dabei spielten die Ausbildung- und der Wissensstand der Mitarbeiter eine wesentliche Rolle.

*Dipl. Inform. Rainer Görg ist Berater der Alldata Unternehmensberatung GmbH, München; Dipl. Math.Jürgen Glag ist Leitender Berater der Alldata SDV GmbH, Düsseldorf