Die meisten Organisationen benoetigen Online- Transaktionsverarbeitung (OLTP) und Daten-Server, die dafuer ausgelegt sind. Doch OLTP-orientierte Datenbank-Management-Systeme sind, so Frank Wolniak*, fuer die Einbindung von Desktop- Anwendungen zu eng fokussiert. Erweiterte Server-Funktionalitaet biete hingegen der Ansatz des Online Complex Processing (OLCP).

Der geschaeftliche Erfolg vieler Unternehmen haengt zunehmend von ihrer Faehigkeit ab, sehr schnell auf Veraenderungen des Marktes zu reagieren. Dies verlangt eine rasche und komfortable Manipulation grosser und komplex strukturierter Datenmengen, waehrend gleichzeitig der normale Online-Update-Betrieb ungestoert weitergehen muss. Die Verarbeitung komplexer Abfragen sowie Reportgenerierung, Batch-Verarbeitung und Realtime- Mengendatenerfassung lassen sich nicht mehr von Online Transaction Processing trennen.

OLTP-Anwendungen sind jedoch nur eine, wenn auch historisch gesehen schwierige Untermenge der Beduerfnisse, die ein relationales Datenbank-Management-System (RDBMS) zu erfuellen hat. Datenbanken, die entwickelt wurden, um OLTP zu unterstuetzen, werden im allgemeinen nicht den komplexen Anforderungen moderner Anwendungen gerecht.

Die zunehmende Popularitaet von Client-Server-Architekturen fuehrt dazu, dass mehr und mehr PC-basierte Desktops an unternehmensweite Client-Server-Netze angebunden werden - und dies sogar fuer Produktions- und strategische Anwendungsbereiche. Die traditionellen Desktop-Anwendungen arbeiten meist jedoch voellig anders als die grossen Multiuser-Systeme, wie wir sie in der Host- Verarbeitung kennen. Wir koennen die Gewohnheiten der Desktop-User nicht aendern und brauchen daher Daten-Server, die nicht eingrenzen, sondern unterschiedliche Verarbeitungstypen unterstuetzen und den daraus entstehenden Belastungen Rechnung tragen.

Die ersten kommerziell verfuegbaren RDBMS-Produkte wurden entwickelt, um Ad-hoc-Abfragen, Entscheidungsunterstuetzung und Berichterstattung zu ermoeglichen.

Mitte der 80er Jahre hoerten die RDBMS-Hersteller immer haeufiger Klagen ueber die Begrenzungen der Datenbankgroesse, die beschraenkte Anzahl der Benutzer, die das System versorgen konnte, und die schlechten Transaktions-Verarbeitungsraten. Dies fuehrte zu einer einseitigen Fokussierung auf OLTP als Loesung aller Probleme und als Mittel, um die Verkaufszahlen bei Grossunternehmen zu steigern. Viele Hersteller fuehrten Performance-steigernde Loesungen ein, was jedoch zu Lasten der relationalen Funktionalitaet und der Unterstuetzung komplexer Datenbanken ging.

OLTP-Umgebungen sind relativ einfach. Performance wird oft im Bereich von fuenf bis 1000 Transaktionen pro Sekunde gemessen. Die Transaktionen bestehen ueberwiegend aus wenigen, unkomplizierten Statements, die sich auf eine geringe Anzahl von Tabellen beziehen, wobei nur einige wenige Spalten veraendert werden. Updates wie Queries beziehen sich oft nur auf einen Datensatz. Auch die Tabellen bestehen im Regelfall aus wenigen "engen" Spalten, und die meisten Tabellen sind weder volatil noch enthalten sie besonders grosse Datenmengen. Datenintegritaetsregeln gestalten sich meist unkompliziert, und das Datenmodell bleibt ueber laengere Zeiten unveraendert. Auch die Client-Server- Implementierungen weisen eine einfache Struktur auf und bieten wenig Unterstuetzung fuer verteilte Datenhaltung. Ein Muss sind hingegen anspruchsvolle Mechanismen fuer die Datensicherheit und Verfuegbarkeit.

Im Gegensatz dazu steht Online Complex Processing. Dieser Begriff entstand Ende der 80er Jahre bei Interbase (heute Borland). Der Begriff "Complex" weist auf den bedeutsamen Unterschied zu OLTP hin.

OLCP-Anwendungen muessen eine Mischung von komplexen Operationen oft gleichzeitig unterstuetzen. OLCP benoetigt eine hohe Performance - mehr gemessen an Antwortszeitverhalten und Gesamtdurchsatzrate als allein an der Transaktionsrate. Typische OLCP-Transaktionen enthalten viele komplexe Statements, die eine Entscheidungsunterstuetzung, interaktive Ad-hoc-Abfragen, OLTP sowie operative und benutzerspezifische Batch-Verarbeitungen miteinander kombinieren.

Online-Entscheidungsunterstuetzungen durch aktive Datenbankfunktionen sind dabei ebenso notwendig wie Datensicherheit und Verfuegbarkeit, letztere vielleicht noch in groesserem Umfang als bei OLTP-Anwendungen. Ein OLCP-Datenbankdesign ist haeufig Veraenderungen ausgesetzt, es kann sogar dynamisch veraenderbar sein oder verschiedene Tabellenversionen handhaben. Hier werden grosse Datenvolumina und veraenderliche Daten sowie neue Datentypen verarbeiten, die oft viel Speicherplatz benoetigen ("breite Spalten"). Entsprechend komplex koennen die Integritaetsregeln sein. Hinzu kommt die Notwendigkeit, verteilte Datenhaltung in komplexen Multiserver-Netzstrukturen zu ermoeglichen, was ueber eine einfache Client-Server-Struktur hinausgeht.

OLTP-Daten-Server weisen in einem komplexen Umfeld eine typische Schwaeche auf, naemlich dann, wenn es um die simultane Verarbeitung von sogenannten langen Transaktionen (Queries, Batch-Laeufe etc.) und "kurzen" Online-Update-Transaktionen geht, wie sie in operativen Systemen anfallen.

Ein Beispiel dafuer ist die statistische Analyse oder das Suchen im Lagerbestand, waehrend gleichzeitig die Lagerbestaende durch Fertigung und Lieferungen online veraendert werden. Um verfaelschte Ergebnisse zu vermeiden, muessen hier typischerweise die Online- Transaktionen zeitweilig gestoppt werden (durch "read locks"), solange frueher gestartete Queries dieser Art ablaufen. Diese Locking-Mechanismen, die zu empfindlichen Performance-Verlusten fuehren, finden wir in allen gaengigen RDBMS-Produkten, die nicht OLCP unterstuetzen.

Im OLCP-Betrieb muessen beide Verarbeitungsweisen parallel bei guter Performance bedient werden. Die Loesung ergibt sich durch einen auf "Versioning" ausgelegten Daten-Server, der online Veraenderungen ("Deltas") der Datenbank in der Datenbank selbst mitfuehrt. Auf diese Weise koennen Transaktionen, nach deren Start der Datensatz veraendert wurde, diese Deltas aus Konsistenzgruenden fuer sich rueckgaengig machen. Read locks sind dann ueberfluessig.

Ein weiterer Vorteil des OLCP ist, dass Backups im laufenden Betrieb gefahren werden koennen und die Datenbank nach einem Crash sofort wieder verfuegbar ist. Ein langwieriger Wiederaufbau der Datenbank durch Backup und Log Files ist naemlich unnoetig, da die Datenbank schon die typischen Log-file-Informationen enthaelt.

Immer mehr Benutzer verlangen nach Speichermoeglichkeiten von Datentypen, die sie von der Desktop-Seite her gewohnt sind. Dies koennen laengere Texte sein, Grafiken, Fotos und vielleicht die Kombination aller drei Typen in Form von Layouts, dazu komplexe Zeichnungen aus Computer-Aided Design (CAD) oder Engineering wie Roentgenbilder oder Fieberkurven sowie Musikstuecke und sogar ganze Videoclips.

Es ist sicher sinnvoll, auch hier die Vorteile eines relationalen DBMS mit Datenmanipulationsmoeglichkeiten, Integritaets- und Konsistenzregeln sowie Datensicherheit nutzen zu koennen. Leider verarbeiten OLTP-Datenbanken nur oder hauptsaechlich die traditionellen alphanumerischen Datentypen.

OLCP verlangt jedoch die volle Unterstuetzung solcher Multimedia- Funktionen durch ein effizientes Handling von "Binary Large Objects" (Blobs). Wichtige Punkte sind hier die Moeglichkeit, sehr grosse Datenmengen (breite Spalten) performant zu verarbeiten, die Netzbelastung beim Transfer dieser Datenmengen so gering wie moeglich zu halten und die automatische Konvertierung von verschiedenen Formattypen, die sich im heterogenen Netz ergeben koennen, fuer den Benutzer transparent zu halten.

Die Netzbelastung ist moeglichst gering zu halten

Es gibt eine ganze Reihe von Anwendungen, die einfach strukturierte, aber in enormen Mengen anfallende Daten verarbeiten muessen. Beispiele hierfuer sind Aktienkurse von Wertpapieren ueber einen laengeren Zeitraum hinweg, oder Messdaten, die in Forschung und Qualitaetskontrollen anfallen. Die Verwaltung dieser Millionendaten in traditionellen OLTP-Datenbanken ist aus Performance-Gruenden einfach nicht realisierbar - besonders wenn die Daten haeufig analysiert werden.

Datentypen dieser Art koennen in Form von "Arrays" ebenfalls als breite Spalten in einem OLCP-Daten-Server verarbeitet werden. Wie die Blobs unterliegen dann die Arrays der Kontrolle einer relationalen Datenbank. Auch hier erlaubt das Versioning die parallele Verarbeitung von Datenanalyse und "High Speed Online Updates", wie sie durch den Anschluss an Satellitensysteme und "Realtime Feeds" notwendig werden.

Zentrale Daten-Server sind die Anlaufstelle nicht nur fuer die verschiedensten Desktops mit ihren spezifischen Anwendungsaufgaben, sondern moeglicherweise auch fuer Messgeraete oder andere Einheiten, die Informationen sammeln und in der Datenbank speichern. Um auf wichtige Veraenderungen reagieren zu koennen, gibt es traditionell nur die Moeglichkeit des wiederholten Lesens gewisser Datenbestaende ("Polling") - eine enorme Belastung fuer CPU und Netzressourcen. Zudem ist es damit nicht immer moeglich, auf Events zeitgerecht zu reagieren.

Im OLCP-Betrieb sollte der Daten-Server auch ohne Polling in der Lage sein, von sich aus auf Events zu reagieren, sobald sie eintreten, und entsprechende Anwendungen anzustossen oder Endbenutzer im Netz zu alarmieren. Dies verlangt eine anspruchsvolle Kombination von Event-Registrierung und -Management sowie die Moeglichkeit, komplexe und vielfaeltige Trigger zu implementieren und durch benutzerdefinierte Funktionen zu erweitern. Die Server-Funktionalitaet wird dadurch wesentlich ergaenzt ("Intelligent Server").

Ueber verteilte Datenhaltung ist in den letzten Jahren viel geredet worden, geschehen ist jedoch wenig. Durch die Proliferation von Client-Server-Implementierungen und das zwangslaeufige Zusammenwachsen von Netzbereichen ergibt sich die Notwendigkeit, tatsaechlich mit mehreren Servern zu arbeiten oder auch zentrale Server mit lokalen zu kombinieren.

Dadurch ergeben sich gewisse Schwierigkeiten. Zum einen muss die Anwendung wissen, wo sich die Daten tatsaechlich befinden. Zum anderen kann es im Update-Betrieb von Server-ueberspannenden Transaktionen zu Konsistenzproblemen kommen, wenn nur gewisse, aber nicht alle Server die Transaktion erfolgreich ausfuehren. Two- Phase-Commit ist die allgemein gueltige Vorgehensweise, um solche Konsistenzprobleme zu loesen.

Die Hersteller von OLTP-Datenbanksystemen bieten meist jedoch nur unvollstaendige Loesungen fuer verteilte Datenhaltung. Oft wird nicht einmal ein Two-Phase-Commit unterstuetzt, oder wenn doch, dann unter Kontrolle der Anwendung, die diesen Prozess steuern muss. Wenn ein Automatismus vorhanden ist, erfolgt dies meist ueber einen zentralen Server, der dann jede Transaktion steuern muss. Dies geht auf Kosten von Server und Netzressourcen - ganz abgesehen von Sicherheits- und operativen Aspekten, wenn der zentrale Server nicht verfuegbar ist.

OLTP wird langfristig durch OLCP ersetzt

OLCP verlangt eine voellige Automatisierung der verteilten Datenhaltung und die Losloesung von den Anwendungen. Fuer den Anwender soll weitestgehend transparent sein, wo die Daten physisch liegen, denn Umstrukturierungen der Datenbanken werden in komplexen Netzen haeufig vorkommen. Die Server muessen sich untereinander konsistent halten, miteinander kommunizieren und je nach Anforderung als Server oder als Client fungieren koennen. Der Ausfall eines Servers darf nicht das ganze Netz zum Stillstand bringen.

Da OLTP zu eng fokussiert ist, wird es in den kommenden Jahren mit Sicherheit durch OLCP ersetzt werden beziehungsweise in den umfassenderen Begriff OLCP aufgehen. Dafuer gibt es vor allem drei Gruende.

- Der verstaerkte Einsatz des Client-Server-Modells in seinen unterschiedlichen Auslegungen (Down-, Right- und Upsizing) fuehrt zu einer fortschreitenden Vernetzung der Unternehmen, zur Verknuepfung von verschiedensten Abteilungssystemen mit Zugriff auf gemeinsame Daten wie auch auf spezielle Daten, also zu einer Multiserver-Umgebung. Neue Anwendungstypen werden vermehrt eingesetzt. Dadurch ergeben sich die unterschiedlichsten Anforderungen einschliesslicher neuer Datentypen wie Text, Grafik und Video, komplexere Zugriffsmechanismen und Integritaetsbeduerfnisse. Aktivitaeten an einer Stelle haben einen Effekt auf andere Bereiche des unternehmensweiten Netzes; die Daten-Server als zentrale Anlaufpunkte muessen die gewuenschten Effekte aktiv anstossen, also mehr sein als reine Daten- Repositories.

- Aus dem obigen Szenario ergeben sich automatisch unterschiedliche Verarbeitungstypen, besonders wenn die klassische DV die Forderungen von Ingenieuren, Forschern und dem Heer der typischen PC-Benutzer aufnimmt. Dieser gemischte Betrieb von langen Transaktionen mit kurzen OLTP-Transaktionen kann von den heute gaengigen OLTP-Servern nicht performant bewaeltigt werden.

- Bestimmte Anwendungen fordern dies dringender als andere und sind somit automatisch Kandidaten fuer OLCP. Dazu zaehlen Maklersysteme im Finanzbereich, dynamische Steuersysteme oder CAD/CAM-Anwendungen, aber auch Telekommunikations-Applikationen oder solche der Versicherungsbranche. Obwohl diese Programmtypen heute eine Vorreiterrolle spielen, werden durch die fortschreitende Client-Server-Vernetzung auch traditionelle DV- Anwendungen von den OLCP-typischen Anforderungen zunehmend betroffen.

Wolniak: OLTP-Umgebungen sind relativ unkompliziert

* Frank Wolniak ist Geschaeftsfuehrer der Softnet GmbH Meerbusch bei Duesseldorf.