SCHENEFELD (je) - Wichtige Funktionen, um ein IMS-System optimal zu führen, sind der Entwurf der Datenbank und Ihr Aufbau anhand eines Katalogs der Leistungskriterien. Das Monitoring als weitere wichtige Funktion aber wird allzu häufig vergessen. Diese Meinung vertritt Hans-Werner Steffen von der Schenefelder Information Systems GmbH. In Teil I seiner Ausführungen - siehe COMPUTERWOCHE Nr. 33 vom 15. August - beschäftigte sich Steffen hauptsächlich mit den Gründen eines verzögerten Transaktionsflusses durch ein System. Der daran anknüpfende zweite und abschleifende Teil kommt zu dem Ergebnis: Über richtiges Monitoring zu richtigem Tuning.

Nach dem Konzept des "Program Isolation" müssen alle Ausgabenachrichten so lange warten, bis das Anwendungsprogramm normal beendet ist. Aus diesem Grunde werden diese ' Nachrichten vorübergehend in eine Warteschlange gestellt, bis eine entsprechende Synchronisation möglich ist. Dieser Synchronisations-Zeitpunkt wird schneller erreicht, wenn für jede Transaktion der Modus "Mode=Single" definiert wird.

Daten minimal - Information maximal

Ist die Verarbeitung beendet, muß die Nachricht warten, bevor sie auf dem Benutzer-Terminal als Ausgabe erscheint. Wurde die Nachricht für die Ausgabe an einem Bildschirm ausgewählt, so erfolgt die Ausgabe durch MFS. Auch in diesem Fall ist die Größe des Formats und des I/O-Buffer-Pools die Haupteinflußgröße. Nach der Formatisierung wird das Benutzerterminal gepollt und die Ausgabenachricht schließlich übertragen.

Es wurde bereits festgestellt, daß ein ständiges Monitoring sehr wichtig ist, um bei nicht befriedigenden Antwortzeiten die Problemgebiete zu erkennen. Weiterhin ist ein ständiges Monitoring jedoch von Nutzen, um das Management mit Informationen über den derzeitigen Performance-Level und die Transaktionsrate zu beliefern sowie mit einer Projektion des Trends des gegenwärtigen System-Load im Hinblick auf zukünftige Erfordernisse bezüglich einer Speichererweiterung, eines Ausbaues der CPU oder zusätzlicher Plattenspeicher. Dieselben Informationen können dafür benutzt werden, Kriterien über vorsorgliche Tuning-Maßnahmen zu entwickeln.

Da es möglich ist, vom IMS und vom Betriebssystem sehr umfangreiches Statistikmaterial zu erlangen, ist es erforderlich, eine entsprechende Auswahl zu treffen, die es ermöglicht, aus einem Minimum an Daten ein Maximum an Informationen zu gewinnen. Es sollten daher drei Informationsebenen beachtet werden.

Am einfachsten sind Daten der ersten beiden Informationsebenen zu gewinnen. Sie enthalten alle erforderlichen Informationen für Management-Reports sowie zur Feststellung von Performance-Verlusten und deren Ursachen. Die dritte Informationsebene ist erforderlich, um alle Probleme, die durch die vorhergehenden Ebenen verursacht wurden, zu lösen. Weiterhin ist diese Ebene wichtig für die Kriterien und die Durchführung von Tuning-Aktivitäten.

Drei Informationsebenen

Alle Daten der ersten Ebene sollten in einem Log-Buch erfaßt werden. Sie enthalten Hinweise über jegliche Änderungen, die im IMS sowie seinen Randbedingungen durchgeführt wurden. Hierunter fallen auch Änderungen in den Benutzerabteilungen. Beispiele dieser Änderungen können Online-Transaktionen, Datenbankreorganisation, Programmänderungen, fehlerhafte Plattenlaufwerke oder PTF-Änderungen sein.

Die Daten der zweiten Ebene zeigen den Umfang der durch das System vollzogenen Arbeiten die durchschnittliche Antwortzeit einer ausgewählten repräsentativen Gruppe von Transaktionen sowie die Gesamtausnutzung der Hauptressourcen wie CPU-Zeit, Hauptspeicher und E/A-Geräte.

Die Daten der dritten Ebene sollten es ermöglichen, die Hauptbenutzer der kritischen Ressourcen zu definieren. Sie sollten es weiterhin ermöglichen, so viele Informationen wie irgend möglich über die durchschnittliche Zeit zu gewinnen, die die Transaktionen benötigen, um durch das System zu gelangen.

Betrachten wir nun die Monitoring-Tools, so ist die Hauptforderung an sie, daß sie die gewünschte Informationsebene erzeugen. Jede Monitoring-Funktion sollte auf ihre Fähigkeit hin überprüft werden, ein ganz bestimmtes Gebiet des Gesamtsystems prüfen zu können. Sie sollte aber auch "benutzbar" sein das heißt sie muß einfach zu installieren und zu warten sein.

Empfohlene IMS-Utilities

Es erscheint sinnvoll, die Funktionen zu verwenden, die mit dem IMS geliefert und daher auch gewartet werden. Es stehen Utilities zur Verfügung, die die grundsätzlichen Anforderungen erfüllen. Wenn der Anwender diese Utilities umschreibt, kann er eine wesentliche Verbesserung erzielen. Im einzelnen handelt es sich bei diesen Utilities um das - - IMS-Statistics-Utility,

- IMS-Log-Transaction-Analysis-Utility,

- IMS-Log-Tape-Print-Utility,

- IMS-Monitor-Utility.

Die ersten drei dieser Utilities belasten das Online-System nicht durch zusätzliche Loads, da sie ihre Informationen aus dem IMS-Log-Tape gewinnen.

Obwohl das DC-Monitor-Utility nur interne IMS-Start- und -Endzeiten aufzeichnet und demzufolge nicht in der Lage ist, die einzelnen Transaktionen durch das gesamte System zu verfolgen und folglich auch keine Transaktionsantwortzeit messen kann, ist es doch in der Lage, sehr gute Informationen über die Anzahl der Belegung und genaue Zeiten interner Geschehnisse zu geben. Das Ausgabe-Log-Tape des DC-Monitors kann von dem Standard-Modul DFSUTR 10/20 verarbeitet werden und erzeugt somit viele der für die Ebene drei erforderlichen Daten.

Darüber hinaus kann dieses Band durch das feldentwickelte Programm "Imsasap" verarbeitet werden. Dieses Programm hat den Vorteil, daß es die numerischen Daten in der Form von Verhältniszahlen, Durchschnitszahlen und Prozentsätzen erzeugt. Dadurch ist es sehr viel einfacher, die Ergebnisse verschieden langer Testperioden miteinander zu vergleichen.

Das Log-Tape sollte grundsätzlich jeden Tag verarbeitet werden und die Statistiken der durchschnittlich belasteten und der stark belasteten Stunden gemäß den Anforderungen der Informationsebene erstellt werden. Unter diesen Bedingungen können Grafiken erstellt werden, die die Tagesleistung des Systems darstellen. Nach mehreren Wochen sollte es dann möglich sein, die normalen Charakteristiken des bestehenden Systems in seiner Umgebung zu definieren.

Die Statistiken des DC-Monitors für die dritte Informationsebene sollten wöchentlich unter Ausnutzung eines oder zweier Läufe von je rund zwei Stunden erstellt werden, um detaillierte Informationen über die IMS-Region und die Programmbenutzung zu erhalten. Diese Statistiken werden auch immer dann benötigt, wenn Probleme auftauchen, die die zweite Informationsebene betreffen.

Die auf diese Art und Weise gespeicherten Daten sollten weiterhin wöchentlich untersucht werden hinsichtlich außergewöhnlicher Vorkommnisse und monatlich, damit sichergestellt werden kann, daß die festgestellten Trends den vorgegebenen Kriterien entsprechen. Soweit es erforderlich erscheint, kann aus diesen Ergebnissen eine detaillierte Performance- und Tuning-Überprüfung erfolgen.

Um nun ein IMS-System zu tunen, werden die Komponenten der fünf interaktivsten Areas untersucht, die alle die Transaktions-Antwortzeit beeinflussen.

Es ist verständlich, daß die Voraussetzungen für das Tuning des IMS eine genaue Kenntnis und ein tiefes Verständnis der Installation und der IMS-Internals ist. Die Listen und Grafiken, die durch ein ständiges Monitoring erstellt werden, sind ein ausgezeichnetes Hilfsmittel, um diese Kenntnisse zu erwerben.

Das Tuning kann sich erstrecken auf

1.) Hardware

- Shared DASD

- Kanäle

- TP-Steuereinheiten

- Leitungen

- Hauptspeicher

- Bandlaufwerke

2.) Betriebssystem

- Lage der Datasets

- Anzahl der Batch Initiators

- System-Task/Problem-Task

- OS-Konsol-Puffer

- TP-Zugriffsmethode

- Dispatching-Priorität

- Paging

3.) Anwendungsprogramm-Design

- PCB

- MFS

- DL/1 Call-Begrenzungen

- DL/1 Call-Muster

- Anzahl Puffer

- BISAM oder QISAM

- Sprache

- Segmentgröße

- Dialog (conversational-)Verarbeitung

4.) Datenbank

- Anzahl Datenbanken/Dataset-Gruppen

- Wahl der Zugriffsmethode - Blockgröße

- Folge abhängiger Segmente

- Reorganisationszeit

- Indices

- Lage der Datasets

- Integrität

5.) IMS System-Optionen

- Pools

- Formate

- Message Region-Klassen

- Long-Message-Größe

- MAXIO

- Checkpoint-Frequenz

- DBLLOG Puffer

- Enq/Deq-Platz für PI

- Page-Fixing

- Maximale Anzahl der Dependent Regions

- Transaktionsmodus

Bei jeglicher Tuning-Aktivität sollte eine Regel nicht vergessen werden: "Sie müssen wissen, wann Sie mit dem Tuning aufhören müssen!"

Darüber hinaus müssen die Kosten der Problemlösung bestimmt werden. Um die wirkungsvollsten Lösungsmöglichkeiten zu bestimmen, kann es erforderlich werden, eine Simulation oder einen Benchmark durchzuführen. In allen Fällen jedoch wird der Systemprogrammierer zunächst einmal die verschiedenen Optionen innerhalb des IMS gegeneinander abwägen müssen.

Über-tunen vorhindern

Die Vorteile eines ständigen Monitoring-Systems wachsen um so mehr, je mehr der Systemprogrammierer m der Lage ist, für jeden Parameter das Optimum zu definieren. Dabei ist es sehr einfach, das IMS zu "ver-tunen" . Bei dem Versuch, zwei oder mehr Parameter zu optimieren, darf nie vergessen werden, daß Abhängigkeiten zwischen den Parametern bestehen und sich eine reduzierte Performance ergeben kann. Die ständige Beobachtung der Daten eines Monitorlaufes ist die sicherste Möglichkeit, ein Über-tunen zu verhindern.

Die Einführung und Wartung eines laufenden Monitoring-Systems innerhalb einer großen Installation wird sicherlich die volle Arbeitszeit eines Mitarbeiters beanspruchen. Seine Kenntnis und sein Verständnis des Systems jedoch führt - nicht nur für den Datenbankadministrator - zu einem nicht bewertbaren Vorteil.

Im Falle eines ernsthaften Systemzusammenbruchs wird der Monitoring-Experte des Anwenders schnell in der Lage sein, den Fehler zu analysieren und weiterhin eine große Unterstützung für den Berater sein, der für die Lösung des Problems möglicherweise herangezogen wird.