Kürzere Antwortzeiten waren nur ein Effekt:

Datenbankmaschine trägt zur Integration bei

02.09.1988

Mehr als drei Minuten mußten die Ciba-Geigy-Wissenschaftler üblicherweise auf eine Datenbankabfrage warten - im Einzelfall konnten es auch 20 Minuten sein. Sergio Pellegrini* ging auf die Suche nach Alternativen. Fündig wurde er bei Newcomer Teradata.

Das Hauptproblem in den Forschungsarbeiten, vor allem bei den zwei biologischen Ressorts, lag in dem sehr großen Aufkommen an Informationsmengen, die in einer chemischen Datenbank gespeichert sind. Sie enthält die chemischen Substanzen und Formeln, die wir ständig für Tests und Forschungsrecherchen benötigen. Alle Ergebnisse dieser Vorgänge werden jeweils ergänzend zu den vorhandenen Informationen gesichert und niemals überschrieben.

Ebenso halten wir alle Ergebnisse von Tests in einer Langzeitforschung verfügbar. Bei einer einzigen Abfrage wurden also oft mehr als 10 000 Datenelemente angesprochen und dann durch zusätzliche Abfragen eingekreist und vermindert. Dieses Verfahren verbrauchte im Online-Betrieb sehr viele System-Ressourcen und beeinträchtigte die Gesamt-Performance des Systems.

Online-Zugriff nur noch als Batch-Job

Die übliche Wartezeit auf eine Anfrage in der chemischen Datenbank lag im 3-Minuten-Bereich, konnte aber auch bis zu 10 und 20 Minuten betragen.

Das führte zur generellen Anweisung der RZ-Leitung an den Forschungsbereich, die Abfragen mit mehreren Online-Zugriffen nicht

mehr als Online-Queries, sondern als Batch-Job zu definieren. Diese Arbeitsweise aber war wenig sinnvoll bei den im Forschungsbetrieb notwendigen schrittweisen Abfragezyklen, da eine gegebene Antwort sofort wieder zu neuen Fragen führte.

Der durch die Batchverarbeitung bedingte Engpaß störte bei der Handhabung der im Forschungsbetrieb verwendeten Art von Daten und war auf Dauer nicht tragbar.

Deshalb wurde die Forderung nach einem speziell für die Belange des wissenschaftlichen Bereiches ausgerichteten Datenbanksystem schließlich auch von der Leitung des kommerziellen Rechenzentrums unterstützt.

Es wurde erkannt, daß diese Art der Datenbankbelastungen, wie sie aus dem wissenschaftlich notwendigen Vorgehen bei Abfragen entstehen, nur mit einem eigenen Datenbanksystem abzudecken sind.

Zentrale Datenbank für alle Bereiche

Gleichzeitig entstand dabei die Forderung nach einer zentralen chemischen Datenbank für alle Forschungsbereiche.

Damit sollte erreicht werden, daß alle Forschungsbereiche auf denselben aktuellen Daten- und Informationsstand zugreifen können und keine differenzierten Pflegestände auftreten. Außerdem war zu gewährleisten, daß tatsächlich alle wissenschaftlichen Mitarbeiter von der Beseitigung des bestehenden Engpasses bei komplexen Abfragen profitieren konnten. Die für den Arbeitsablauf eines Forschers noch erträgliche Antwortzeit im Dialogbetrieb sollte unter eine Minute gedrückt werden. Darüber, wie das am besten zu lösen sei, gab es seit einigen Jahren längere Diskussionen.

Die Frage war, ob man die jeweils neue Generation von Softwarelösungen nach wie vor auf den Mainframesystemen ablaufen lassen oder aber dafür dedizierte Rechnersysteme einsetzen sollte. Weiterhin müßte geprüft werden, ob der einzige bis dahin bekannte SQL-Standort bei Query-Abfragen weiter verwendet werden konnte. Diese Forderung war erhoben worden, um sicher zu gehen, daß vorhandene umfangreiche Anwendungsprogramme möglichst leicht kompatibel gehalten werden können. Auf keinen Fall aber sollte wieder ein Konzept mit verteilten Datenbanken installiert werden.

Daraus entwickelten wir ein Pflichtenheft mit der Auflistung der Merkmale, die erfüllt werden mußten. Aus den anwendungsbezogenen Anforderungen wurden etwa 600 Anfragen zu Benchmarktests zusammengestellt und auf die 20 wichtigsten Anfragen konzentriert. Dieser Satz von Benchmarkfragen verfügte über einen Umfang von 500 Megabytes und stellte die Basis für den Test mit verschiedensten Datenbanksystemen, Datenbank-Computern und dedizierten Systemen.

Großer Wert auf die Reorganisationsfreiheit

In erster Linie galten die Untersuchungen der Prüfung, ob die geforderte Performance gewährleistet ist. Die Untersuchungen wurden mit einem und mehreren Benutzern (Single/Multi-User-Mode) durchgeführt. Dabei testeten wir unter anderem, ob die Abfragen mit AND- und OR-Verknüpfungen in der gewünschten Antwortzeit bei großen Datenmengen abgearbeitet werden können. Außerdem legten unsere Mitarbeiter großen Wert auf Reorganisationsfreiheit, Zuverlässigkeit und Wartbarkeit.

Bereits vor über drei Jahren, Anfang 1985, wurde untersucht, ob eine Adabas-Datenbanklösung der Software AG von der Performanceseite für die typischen Online-Abfragen von Wissenschaftlern geeignet ist. Die angebotene Datenbanklösung ist ein investiertes Konzept, das dem relationalen Modell entsprechen soll.

Adabas verfügte damals jedoch noch nicht über SQL als Abfragesprache, wenn auch die Performance positiv zu beurteilen war. Neuerliche Tests mit den bereits vorhandenen Benchmarkdaten ergaben, daß die in der Zwischenzeit ergänzte Querysprache ADA/SQL nicht im vollen geforderten Umfang den SQL-Standard abdeckt.

In der nachfolgenden Zeit wurden alle Datenbanksysteme auf dem Markt mit einem SQL-Angebot auf die gewünschte Leistungsfähigkeit getestet. Es handelte sich dabei im Einzelnen, um das Datenbanksystem Oracle auf der VAX 8700 von DEC, dann DB2 Version 2 für das System 3090/200 von IBM, ferner um die reine Datenbank von Britton Lee (im Vertrieb von GEI) und weiterhin um das Nonstop-Computersystem von Tandem.

Der Zufall wollte es, daß ein Fachartikel in der technisch-orientierten Zeitschrift IEEE-Computer über das Systemkonzept des Newcomers Teradata unsere Aufmerksamkeit erregte. Dieses Modell eines speziellen Datenbank-Computers versprach, den Forderungen unseres Pflichtenheftes weitgehend nahezukommen: Das Produkt verfügte über den SQL-Standard, ein schnelles Antwortzeitverhalten auch bei schwach selektiven Abfragen mit AND- und/oder OR-Verknüpfungen und sollte eine parallele Verarbeitung der Abfragen ermöglichen. Deshalb liefen im Februar 1986 umfangreiche Benchmarktests auch auf diesem System. Die Leistungsdaten erwiesen sich zum überwiegenden Teil deutlich besser als die der getesteten Alternativsysteme. Teilweise erfolgten die Antworten mit einem Zeitvorteil im Verhältnis 1:50, einige Konstellationen führten jedoch auch zu längeren Antwortzeiten.

Unix-Workstations in der Peripherie

Im Laufe des Jahres 1987 konnten die Test- und Systemerfahrungen zu einem abschließenden Bericht an den Ciba-Geigy-Vorstand zusammengefaßt und mit einer Empfehlung für die Datenbank-Maschine versehen werden. Der Vorschlag entwickelte sich zu einem umfassenden Dezentralisierungsprojekt, das Unix-Workstations in der Peripherie vorsieht. Im Zentrum werden die Teradata DBC/1012, mehrere VAX-Rechner und eine IBM 9370 als Kommunikationsrechner eingesetzt.

Das Konzept erlaubt eine Vielzahl von Host-, Abteilungs-(Mini-) oder Workstation-Systemen von verschiedenen Herstellern mit inkompatiblen Betriebssystemen. Die neue Konfiguration steht als gemeinsames Datenbank-Verarbeitungssystem zur Verfügung und sorgt damit für eine komplette Integration. Die Peripherie wird über ein Netzwerk unter der Protokollsteuerung von TCP/IP an alle zentralen Systeme angebunden. Weitere unterhaltene Netze sind beispielsweise DECnet und SNA.

Das Unternehmen

Die Ciba-Geigy AG mit Hauptsitz in Basel beschäftigt rund 86000 Mitarbeiter in mehr als 60 Ländern. 1987 wurde ein Gesamtumsatz von 15,8 Milliarden Schweizer Franken erwirtschaftet. Die Hauptaktivitäten bestehen in der Forschung, Entwicklung, Produktion und Vermarktung von Farbstoffen, Chemikalien, Pharmaerzeugnissen und Kunststoffen.

Struktur des wissenschaftlichen RZ

Bis 1987 wurden die Datenbanken für die Bereiche Forschung, kommerzielle Daten und Fertigungssteuerung mit jeweils einem Modell IBM 3090/200 und 3090/400 sowie kleineren Front-end-Rechnern betrieben. Im Forschungsbereich wurde das Datenbanksystem Inquire eingesetzt.

Das 1987 neugeschaffene wissenschaftliche Rechenzentrum ist mit einem IBM 9370-System als Kommunikationsrechner ausgestattet. Teradata lieferte dazu zwei Interface-Prozessoren für die IBM-Verbindung, zwei Kommunikations-Prozessoren für den Zugriff der Workstations und PCs auf die Datenbankmaschine und vier Zugriffsmodule mit je einem 512-MB-Magnetplattenlaufwerk.