Kontrolle des EA-Aufkommens ist dringend notwendig, denn:

Nutzlose Zugriffe bremsen Datenbank-Effizienz

23.10.1987

Die Akzeptanz von IMS-Online-Anwendungen hängt primär von ihrer Benutzerfreundlichkeit ab. In starkem Maße ist sie aber auch von der Antwortzeit beeinflußt. Christian Köppen* erklärt in seinem Beitrag Fehler beim DB-Design und zeigt Möglichkeiten auf, den IMS-Durchsatz zu verbessern.

Die Komponenten der Antwortzeit setzen sich aus folgenden Teilen zusammen: Übertragung der Eingabefelder über die Leitung, Warten auf Verarbeitung (Input-Queue-Zeit), Laden des Verarbeitungsprogramms, E/A-T_TIgkeit der Datenbank und Übertragung des Ausgabeschirms über die Leitung. Falls mit "Program to Program Switch" gearbeitet wird, können das Warten auf die Verarbeitung, das Laden des Verarbeitungsprogramms und die E/A-T_TIgkeit der Datenbank sogar mehrfach einfließen.

Die Leitungszeit, also die Übertragung der Eingabefelder und des Ausgabeschirms macht immer noch den Löwenanteil der Antwortzeit aus. Verbesserungen wurden bis dato nur durch Leitungsoptimierprogramme erreicht, die den unnötigen Teil der Zeichen entfernen. Diese Optimierungsroutinen können jedoch nur von einem vom Programm gegebenen Datenstrom ausgehen.

Häufig läßt sich jedoch feststellen daß ein Programm Felder auf den Bildschirm sendet, die bereits dort vorhanden sind und umgekehrt. Veränderungen der Bildschirmmasken-Gestaltung sind für die meisten Programme jedoch so einschneidend, daß hier normalerweise keine Verbesserungen mehr durchgeführt werden. Bei den meisten Installationen bleibt also nur noch der Weg, die Leitungsgeschwindigkeit zu erhöhen, was bei Postleitungen zu erhöhten Kosten führt.

Die Input-Queue-Zeit wird von fast allen Installationen überwacht. Engpässe lassen sich hier einfach durch die Erhöhung der Anzahl der Message-Regions beheben. Wirkliche Probleme existieren nur in den Installationen, die ein schlechtes Scheduling-Klassen-Konzept aufweisen.

Die Programmladezeit stellt eines der zentralen Themen in IMS dar. Es gibt zwar einige Möglichkeiten, die Ladezeiten zu minimieren (Preload, Virtual Fetch oder eine Bibliothek auf einer Solid State Disk), doch auch sie haben ihre Grenzen. Neuerdings läßt sich die Tendenz feststellen, Anwendungsprogramme zu vergrößern. So wurden bereits TP-Programme mit einem Umfang von 2MB entwickelt. Jedoch muß bei solchen Anwendungen gedacht werden, daß alleine schon das Laden bereits zwei Sekunden Antwortzeit einnimmt.

Die Ein/Ausgabe-Fähigkeit ist schwierigstes Thema

Die E/A-T_TIgkeit einer Datenbank ist wohl das schwierigste Thema, insbesondere deshalb, weil die Information en über die Ein- und Ausgaben nicht leicht zu beschaffen und zu interpretieren sind. Der Durchsatz einer Datenbank hängt allein davon ab, wie hoch die Anzahl der "nutzlosen" Zugriffe, also die Anzahl der Zugriffe, die nicht zum gewünschten Segment führen, ist. Bei DL/ 1-Datenbanken können solche "nutzlosen" Zugriffe folgendermaßen erzeugt werden:

-Index-Dctenbanken (Hisam, Index)

Der direkte Zugriff zum Rootsegment führt über Ein- und Ausgaben im Index, die selten beachtet werden;

- Hisam-Datenbanken

Der direkte Zugriff zu einem abhängigen Segment geschieht in der Form, daß seine hierarchischen "Vorgänger" überlesen werden müssen;

- Lange Datenbanksätze

Große Twin-Ketten sind in DL/1 ein Problem. Der Zugriff zu einem bestimmten Segment kann nur durch Überlesen seiner Vorgänger erfolgen.

Design-Phase wurde zu stark vernachlässigt

Die hier aufgeführten Fälle sind nur Design-Fehler. Fast immer lassen sich derartige Probleme nicht lösen, ohne wesentliche Teile der Anwendung anzupassen. Es handelt sich dabei fast immer um "alte" Programme, deren Fehler so gut wie nie behoben werden können, da die Design-Phase zu stark vernachlässigt wurde.

Eine weitere Möglichkeit, "nutzlose" Zugriffe zu produzieren, ist dadurch gegeben, Datenbanken zu desorganisieren. Reorganisationsläufe nehmen sehr viel Zeit in Anspruch und werden deshalb häufig zu spät gemacht, so daß die Antwortzeiten längst "davongelaufen" sind. An welchem Punkt eine Reorganisation erforderlich ist, bestimmen die Anwender heute eher intuitiv.

Ein wirklich dunkler Punkt der DL/ 1-Datenbanken betrifft die Batch-Verarbeitung, da hier eine große Anzahl von DL/ 1 -Calls durchgeführt wird. Häufig muß man Problemfälle im Nachhinein analysieren, was oft genug über Vermutungen nicht hinausgehen kann. Insbesondere deshalb, da die diesbezüglichen Informationen nicht ausreichen.

Sinnvollstes Mittel um den IMS-Durchsatz zu beeinflussen ist also die Senkung der E/A-T_TIgkeit. Erforderlich hierfür sind jedoch Hilfsmittel, die den Hinweis auf die richtige Stelle geben. Sonst erweist sich das Ganze als ein "Stochern im Nebel".

Wichtig sind auch die Möglichkeiten, an die Informationen über die E/A-T_TIgkeit heranzukommen. Auf der Leitungsseite ist diese Information völlig unbekannt. Die Logsatzarten 01 und 03 bieten diese Informationen nicht. Somit läßt sich nur mit VTAM-Mitteln eine entsprechende Messung durchführen, wobei dann das Problem der Zuordnung zum IMS-Programm nahezu nicht mehr zu lösen ist.

Das Problem der Programmladezeiten ist jedoch relativ einfach in den Griff zu bekommen. Die Programmgröße läßt sich leicht ermitteln. Die dabei auftretenden Ausreißer (Faustregel: Programm größer als 1OOK) können gezielt untersucht werden.

Schwer zu ermitteln ist hingegen das E/A-Aufkommen von Datenbanken; insbesondere ist die Früherkennung nicht gelöst. Es gilt also Wege zu finden, wie sich mögliche, E/A-Engpässe bereits im Vorfeld erkennen lassen.

* Christian Köppen ist Chefentwickler für den IMS Data Base Analyzer (DBC) der Projekta-Software-Organisation GmbH (Unternehmensgruppe Schumann), Köln