Mit über neun Millionen gespeicherten Mitgliedern gehört "Adam" seit knapp zwei Jahren zu den größten Adabas-Datenbanken der Bundesrepublik. Kurz nach der Inbetriebnahme haben Norman Heydenreich und Johannes Siedersleben* in der COMPUTERWOCHE (CW Nr. 34 und 35 vom August 1988: "ADAC landet mit Adam auf dem Punkt") das Konzept dieser Großdatenbank erläutert. Nun berichten sie, wie es sich bewährt hat.
Am Beispiel der Adam-Datenbank sollen Probleme und Lösungen der Organisation und des Entwurfs dargestellt werden, die auch auf die Nutzung anderer DB-Systeme übertragbar sind. Leistungszahlen im praktischen Betrieb werden theoretischen Überlegungen gegenübergestellt.
Seit März 1988 bildet die Adam-Datenbank die Basis unserer Mitgliederverwaltung. Der Datenbestand von über neun Millionen aktiven Mitgliedern (zweimal acht Gigabyte), die Anzahl von sechs Millionen Dialogvorgängen pro Jahr mit täglich bis zu 200 000 Transaktionen, die Forderung hoher Dialog-Verfügbarkeit und die Volumina der Batch-Verarbeitungen stellten hohe Anforderungen an den technischen Entwurf der Adam-Datenbank.
Fachliche Grundlage von Adam ist der Entity-Relationschip-Ansatz. Dieses Datenmodell erwies sich zwar als hilfreich, war aber noch nicht einmal die halbe Miete: Die meisten Dateien genügen nicht einmal der ersten Normalform.
Logisches und physisches Design verfolgen völlig verschiedene Ziele. Bei ersterem geht es darum, unter Verwendung von Methoden wie Entity-Relationschip-Ansatz und Normalisierung die Struktur und die Abhängigkeiten der Daten so klar wie nur möglich herauszuarbeiten. Beim physischen Entwurf haben wir versucht, unter technischen Randbedingungen wie der Blocklänge und unter Beachtung der Zugriffshäufigkeiten und Durchsatzanforderungen die Anzahl der physischen In- und Outputs zu minimieren. Eine Verletzung der Regeln für den logischen Datenbank-Entwurf war dabei nicht zu umgehen.
Optimiert wurden Daten mit hohen Zugriffsraten
Adam-Datengruppen, die von Volumen und Zugriffshäufigkeit her wirklich eine Rolle spielen, sind Matchcode, Adresse, Vertrag und Person, Mahndaten, Konto-Posten und -Kopfdaten sowie Historie und Termin (vergleiche Tabelle 1). Ihre fachliche Bedeutung ist für die weitere Diskussion ohne Belang. Die Zugriffshäufigkeiten legen folgende Dateiauslegung nahe:
- Der Matchcode wird in einer gleichnamigen Datei untergebracht, und zwar alle Matchcodes zu einer Person hintereinander in einer Periodengruppe.
- Die Datengruppen Adresse, Vertrag, Person, Mahndaten, Kontokopfdaten und Kontoposten werden in einer Datei BESTAND zusammengefaßt. Diese Datei dient als Leitdatei für alle wichtigen Batchläufe. Sie enthält alle Kontoposten zu einer Person in einer Periodengruppe.
- Die Datengruppen Historie und Termin werden jeweils in einer eigenen Datei untergebracht. Dadurch sind im Dialog und im Batch zusätzliche Direktzugriffe erforderlich. Es wurde jedoch davon abgesehen, auch Historie und Termin in die Datei BESTAND mit aufzunehmen, weil dadurch der physische Satz und der Recordbuffer extrem lang geworden wären. Der Entwurf sieht vor, daß alle historienwürdigen und alle vordatierten Änderungen zu einer Person in jeweils einer Periodengruppe abgelegt werden.
Adam sichert auf eine Schattenbank
Zur Organisation der Datenbank gehört das Sicherungs-Recovery- und Reorganisationskonzept. Hierbei mußten wir berücksichtigen, daß für den Auskunftsdialog eine Verfügbarkeit rund um die Uhr gegeben sein muß. Außerdem sollte eine Reorganisation möglich bleiben. Auf dieser Grundlage haben wir uns für die Datensicherung für eine Schattendatenbank entschieden.
Zunächst wurde ein Konzept für das parallele Aktualisieren von Dialog- und Batch-Anwendungen verfolgt. Das Problem der Behandlung von Dialogsperren im Batch erwies sich als lösbar, die Behandlung des Fehlerfalls jedoch als außerordentlich komplex: Fehlerhafte Batch-Updates lassen sich mit Utilities nicht ohne die gleichzeitig erfolgten Dialog-Updates auf einen Sicherungsstand zurücksetzen. Der Ansatz, Batch und Dialog parallel Updates vornehmen zu lassen, wurde deshalb verworfen und durch das Konzept einer Schattenbank ersetzt. In der Folge mußte nun das gesamte Datenvolumen doppelt verfügbar gemacht werden.
Zweimal täglich wird von der Master- auf die Schattendatenbank kopiert, und zwar unter Umgehung der Adabas-Utilities (Dauer etwa 50 Minuten). Die Schattendatenbank steht dann für lesende Dialoge, lesende Batchläufe und als schnelles Back-up-Medium (Restore in 50 Minuten) zur Verfügung. Auf diese Weise ist es möglich, den Batch nachts, wenn nur lesender TP-Betrieb gefordert wird, im Single-User-Modus ohne Logging laufen zu lassen.
Reorganisationen laufen am Wochenende. Parallel dazu sind auf der Schattendatenbank lesende Zugriffe möglich. Konkret sieht der Tagesablauf von Adam folgendermaßen aus:
7.00-20.00 Uhr
Auf der Master-DB findet der Update TP-Betrieb statt. Auf der Schatten-DB erfolgt der nur lesende Dialog der Nachbarsysteme. Dort können auch lesende Batches laufen.
20.00 Uhr
Die Master-DB wird beendet und im Read-only-Modus wieder gestartet, die Schatten-DB wird heruntergefahren.
20.00-21.30 Uhr
Die Master-DB steht für Auskunftsdialog zur Verfügung. Sie wird auf die Schatten-DB gesichert. Gleichzeitig erfolgt eine Kassettensicherung der Master-DB. Die Schatten-DB steht nicht zur Verfügung.
21.30 Uhr
Die Master-DB wird heruntergefahren und steht jetzt für die Benutzung im Single-User-Modus zur Verfügung. Die Schatten-DB wird im Read-only-Modus wieder gestartet.
22.00 Uhr
Die Operateure gehen nach Hause.
21.30-5.00 Uhr
Auf der Master-DB läuft der Batch im Single-User-Modus. Die Schatten-DB steht für Auskunftsdialog und lesende Batchläufe zur Verfügung.
5.00-6.00 Uhr
Plattensicherung Master-DB - Schatten-DB.
6.00-7.00 Uhr
Auf der Master-DB läuft der Batch im Multi-User-Modus.
Bei Fehlern wird die Schatten-DB kopiert
Der Batch besteht aus einem Single-User-Teil, der die Masse der Updates erledigt, und einem Multi-User-Teil für die Erstellung von Listen. In kleinerem Umfang finden jedoch auch Updates statt. Bei einem Abbruch im Multi-User-Teil wird auf den letzten Checkpoint zurückgesetzt. Das geht aufgrund des geringen Update-Volumens schnell.
Wenn im Single-User-Teil des Batches ein Fehler auftritt, der ein Rücksetzen erforderlich macht, wird die Schatten-DB auf die Master-DB kopiert. Damit ist sichergestellt, daß morgens der Dialogbetrieb pünktlich um 7.00 Uhr beginnen kann. Ein Restore könnte erst nach Schichtbeginn um 6.00 Uhr veranlaßt werden und würde bei dem hohen Update-Volumen den Dialogbeginn um viele Stunden verzögern. Um den Umfang des Batch-Ausfalls zu begrenzen, ist geplant, daß das Jobnetz nach der Rücksicherung beim nächsten Job aufsetzt.
Bei Datenbankfehlern während des TP-Betriebs wird die Schatten-DB auf die Master-DB kopiert. Ein Regenerate fährt die Updates nach. Somit ist der alte Zustand wiederhergestellt. Während der gesamten Reparaturzeit bleibt der Lese-Zugriff auf die Schatten-DB möglich.
Auch bei Adam entscheidet am Ende die Leistung
Eine Adabas-Datei besteht aus logischen Sätzen, die durch interne Satznummern (ISNs) identifiziert werden und die in den physischen Blöcken des Adabas-Datenbereichs (DATA) untergebracht sind. In einem Block befinden sich mehrere Sätze. Um die Anzahl physischer I/Os zu minimieren, kommt es darauf an, möglichst wenige Blöcke zu lesen, um eine gegebene Anzahl logischer Sätze zu verarbeiten. Auch die Reihenfolge, in der die Blöcke gelesen werden, spielt eine Rolle für die Durchlaufzeiten.
Adabas gestattet es - wie viele andere Datenbanksysteme auch - , zu beliebig wählbaren Attributen (Deskriptoren) invertierte Listen einzurichten, die in einem separaten Adabas-Datenbereich, dem Assoziator, abgespeichert werden. Eine invertierte Liste zum Attribut A enthält zu jedem Wert von A die ISNs derjenigen Sätze, in denen A diesen Wert besitzt. Bei Adabas sind die ISNs innerhalb der invertierten Listen aufsteigend sortiert.
Neben dem direkten Zugriff über einen eindeutigen Deskriptor (invertierte Liste) bietet Adabas die Möglichkeit, besonders schnell direkt auf einen logischen Satz über dessen ISN zuzugreifen, wenn diese der Anwendung bekannt ist. Aus diesem Grund wurde in der Adam-Datenbank der logische Schlüssel eines Mitgliedersatzes (Mitgliedsnummer) als ISN vorgegeben.
Die starke Ausrichtung des Datenbankentwurfs an den häufigsten Dialog-Zugriffsanforderungen hat zu zufriedenstellenden Antwortzeiten geführt: 92 Prozent aller Transaktionen liegen unter einer Sekunde. Dabei fallen im Mittel pro Transaktion 2,6 physische I/Os auf die Datenbank an. Die CPU-Belastung liegt bei etwa einer Million Instruktionen je Transaktion. Davon entfallen knapp 15 Prozent auf die Datenbank-Nutzung. Hardwaremäßig läuft der Adam-Dialog gemeinsam mit den übrigen TP-Anwendungen auf einer IBM 3090-20E mit zweimal 16 MIPS, 64 MB Hauptspeicher und 64 MB Erweiterungsspeicher unter MVS/XA.
Ein Batchlauf hat die Aufgabe, nach vorgegebenen Selektionskriterien (zum Beispiel alle Berliner ADAC-Mitglieder) Daten zu selektieren und zu verarbeiten. Dabei erfolgt die Selektion im wesentlichen auf drei Arten:
- Das Batch-Programm liest physisch sequentiell alle Blöcke und selektiert die zu verarbeitenden Sätze nach dem Lesen durch eigene Logik.
- Alle Sätze werden in der Reihenfolge der internen Satznummer (ISN) gelesen (ISN-sequentiell). Die Selektion erfolgt durch eigene Logik.
- Das Batch-Programm wird von einer invertierten Liste gesteuert und liest nur diejenigen Blöcke, in denen sich mindestens ein zu selektierender Satz befindet (logisch-sequentiell).
Beim Laden der Adam-Datenbank wurde dafür gesorgt, daß die Reihenfolge der Adabas-internen Satznummer (ISN) und die physische Reihenfolge weitgehend übereinstimmen. Unter dieser Bedingung ist ISN-sequentielles Lesen nur geringfügig langsamer als physisch-sequentielles Lesen. Der Overhead beträgt etwa drei Prozent.
Logisch-sequentielles Lesen muß nicht langsam sein
Beim logisch-sequentiellen Lesen nach einem konstanten Deskriptorwert (zum Beispiel Fälligkeitsmonat) werden die Blöcke, in denen sich mindestens ein zu selektierender Satz befindet, genau einmal gelesen und im Falle eines Updates wieder weggeschrieben. Der Grund ist, daß die Zugriffsreihenfolge auf den DATA-Bereich durch die ISN-Liste zum Deskriptorwert vorgegeben ist.
Einige Batchjobs (zum Beispiel der "Motorweltversand") lesen physisch-sequentiell die Adabas-Datei BESTAND. Bei Update-Batches ist die physisch-sequentielle Verarbeitung nicht möglich, zumindest nicht ohne besondere Vorkehrungen, die sicherstellen, daß jeder Satz genau einmal angefaßt wird.
Die größten Update-Batches sind der Rechnungs- und Mahnungslauf. Sie lesen saisonabhängig zwischen zwei und fünfzehn Prozent der Mitgliedersätze aus der Datei BESTAND und machen Updates bei einem Teil der Sätze. Für sie kamen die Selektionsvarianten ISN-sequentiell und logisch-sequentiell in Frage. Die Anzahl bei der Selektion zu lesender Blöcke war für beide Varianten abzuschätzen. Ermittelt wurde die ungefähre Anzahl zu lesender DATA-Blöcke beim logisch-sequentiellen Lesen nach einem konstanten Deskriptorwert mit Hilfe wahrscheinlichkeitstheoretischer Methoden .
Der Vergleich mit dem ISN-sequentiellen Lesen aller 606 000 Blöcke der Adam-Datenbank zeigt, daß für die angegebenen Selektionsgrade das Lesen nach einem geeigneten Deskriptor günstiger ist.
Soweit die Theorie. Nun haben wir auf der Basis eines Bestandes von 9,5 Millionen Mitgliederstammsätzen für die genannten Batchjobs bei verschiedenen Verarbeitungsvolumina die Anzahl lesender l/Os auf den DATA-Bereich gemessen. Der Vergleich der drei Rechnungsläufe (vergleiche Tabelle 2) zeigt daß beim logisch-sequentiellen Lesen das Verhältnis von verarbeiteten Sätzen zu physischen l/Os günstiger wird, wenn die Zahl der verarbeiteten Sätze groß ist. Dieses Ergebnis bestätigt unsere vorangegangenen Überlegungen.
Der Rechnungslauf liest nach dem Deskriptor "Fälligkeitsmonat" in ununterbrochener ISN-Reihenfolge. Da die Mitgliedsnummern bei der Neuaufnahme aufsteigend vergeben werden und die Fälligkeit gleich dem Aufnahmemonat ist, stehen mit hoher Wahrscheinlichkeit in einem gelesenen Block fast nur Mitglieder gleicher Fälligkeit. Deshalb sind die gemessenen DATA-Lese-I/Os deutlich geringer als erwartet.
Die geringere Zahl von zu verarbeitenden Sätzen erklärt die wesentlich höhere Anzahl der physischen I/Os je verarbeitetem Satz beim Mahnlauf. Dieser liest nach einem Deskriptor "Mahnvorlagedatum", der bei einem Lauf verschiedene Werte (je Mahnstufe) annehmen kann. Dadurch wird mehr als nur einmal in aufsteigender ISN-Reihenfolge gelesen. Hinzu kommen Updates beziehungsweise Inserts auf die Dateien HISTORIE und TERMIN.
Dennoch liegen die DATA-read-I/Os etwas niedriger als berechnet, da die Häufung gleicher Fälligkeiten in einem Block eine Häufung gleicher Mahnvorlagetermine nach sich zieht.
Neben den Data-Read-Zugriffen haben wir auch die Gesamtzahl der physischen I/Os gemessen (vergleiche Tabelle 3). Diese Werte entscheiden letztlich über die Durchlaufzeit. Weitere Messungen erbrachten die Leistungsdaten für den CPU-Verbrauch sowie für die Durchlaufzeit der großen Batchjobs bei verschiedenen Verarbeitungsvolumina und einer Prozessorleistung von 17 MIPS (vergleiche Tabelle 4).
Der CPU-Verbrauch je 1000 verarbeitete Sätze weist bei den Update-Jobs einen beinahe konstanten Wert mit einer Leistung von 148 000 Instruktionen je verarbeitetem Satz auf. Die großen Update-Jobs laufen bei uns im Single-User-Modus ohne Logging. Das bringt nach unseren Erfahrungen um die 50 Prozent CPU-Zeitersparnis.
ISN- beziehungsweise logisch-sequentielles Lesen verursacht nur dann keine Performance-Probleme, wenn die physische und die ISN-Reihenfolge ganz oder annähernd übereinstimmen. Laden mit User-ISN stellt diese Reihenfolge her. Durch Umlagerungen bei Blocküberläufen kann sie jedoch nachhaltig durcheinandergeraten. Es ist daher vorgesehen, pro Jahr nur eine Reorganisation durchzuführen. Es stellt sich die Frage, wieviel Platz für jeden Block (Paddingfaktor) freizuhalten ist, damit nur ein möglichst kleiner Anteil aller Blöcke überläuft.
Die Sätze der Datei BESTAND hatten bei der Übernahme eine durchschnittliche komprimierte Satzlänge von 180 Bytes. Im Verlauf des ersten Jahres kommen für jedes Mitglied - abgesehen von den verschwindend wenig beitragsfreien - mindestens zwei Kontoposten hinzu, nämlich für Rechnung und Zahlung. Zusammen sind sie 70 Bytes lang, so daß sich eine durchschnittliche Satzlänge von 250 Bytes ergibt.
Geschäftsvorfälle wie neue Verträge, Umbuchungen und Auszahlungen verlängern diesen Satz. Bei uns sind das bei 250 Arbeitstagen pro Jahr zwei Millionen Erweiterungen mit einer durchschnittlichen Länge von je 70 Bytes. Bei einer Blocklänge von 4820 Bytes, einer durchschnittlichen Satzlänge von 250 Bytes und 16 Sätzen pro Block wären also noch (4800 minus 4000) 800 Bytes frei. Diese bieten Raum für elf Erweiterungen mit je 70 Bytes. Bei 16 Sätzen pro Block ist die Wahrscheinlichkeit eines Blocküberlaufes also verschwindend klein.
Adam hält zunächst für 10,5 Millionen Mitglieder Platz bereit. Bei 16 Sätzen pro Block Brauchen wir daher 656 250 Blöcke oder 3160 MB Speicherplatz. Der bereits erwähnte Assoziator von BESTAND benötigt etwa 200 MB und ist damit im Vergleich zum DATA verschwindend gering.
Bis zu 16 Suchbegriffe für jedes Mitglied
Die zweitgrößte Datei ist der MATCHCODE. Diese Datei enthält zu jedem Mitglied zwischen drei und 16 Suchbegriffe, die aus der Adresse nach komplizierten Algorithmen gebildet werden. Die Suchbegriffe stehen in einer Periodengruppe und sind Deskriptoren.
Insgesamt nehmen BESTAND und MATCHCODE etwa 76 Prozent des Gesamtvolumens ein. Der DATA benötigt zehn Laufwerke der 3380-D-Klasse, der Assoziator vier, und für WORK und PLOG haben wir ein Laufwerk 3380-E vorgesehen.
Die Schatten-DB liegt auf acht Laufwerken vom Typ 3380-E. Daraus errechnet sich ein Gesamt-Speicherbedarf von immerhin zwei mal acht Gigabyte.