Online-Transaction-Processing-Systeme müssen komplexe kommerzielle Vorgänge in Echtzeit verarbeiten und die Konflikte konkurrierender Zugriffe vieler Datenbankenbenutzer meistern. Um die Performance einer relationalen OLTP-Umgebung zu messen, hat sich der TP1-Benchmark als Standardtest etabliert. Oft werde er in der Praxis jedoch unsachgemäß gehandhabt, kritisiert Axel Kropp*

Die Datenverarbeitung einer modernen, marketingorientierten Bank besteht heute schon zu vierzig Prozent aus OLTP-Anwendungen (Online Transaction Processing). Die OLTP-Technik wird in den nächsten Jahren bei nahezu allen kommerziellen und industriellen Anwendungen die höchsten Wachstumsraten aufweisen. Den jährlichen Zuwachs in den nächsten fünf Jahren schätzt die Gartner Group auf mehr als zwanzig Prozent. Demnach werden die Kunden 1992 weltweit über 70 Milliarden Dollar für OLTP-Anwendungen ausgeben.

Solche Systeme müssen komplexe kommerzielle Vorgänge im Echtzeit-Verfahren verarbeiten und die Konflikte konkurrierender Zugriffe vieler Datenbank-Benutzer meistern. Eine Transaktion ist ein in sich abgeschlossener Vorgang, und hinter jeder einzelnen stehen extrem hohe CPU- und I/O-Belastungen. Gleichzeitig stellt der Anwender wachsende Anforderungen an den Durchsatz Transaktionen pro Sekunde (TpS) und an die Antwortzeit am Bildschirm. Die Erfahrungen zeigen, daß die geplanten Kapazitäten oft nicht reichen, sobald der Computer "online geht".

Die Qualität eines OLTP-Systems wird insbesondere durch Performance, Erweiterbarkeit, Datenintegrität und Verfügbarkeit (Fehlertoleranz) bestimmt. Ein Schlüsselkriterium jeder OLTP-Anwendung ist die Performance der Datenbank-Software.

Benchmarks, die die Performance einer OLTP-Umgebung testen, sind wesentlich schwieriger durchzuführen und bieten mehr Möglichkeiten der Manipulation als Tests von technischen Realtime- oder Batch-Anwendungen. Die Ergebnisse eines OLTP-Tests werden in Transaktionen pro Sekunde (TpS) angegeben. Aber was heißt Transaktion? Der Begriff variiert von Anwendung zu Anwendung.

Ein in der OLTP-Welt häufig eingesetzter Benchmark ist der sogenannte "Standard-Benchmark TP1". Dieser frei erhältliche Benchmark simuliert eine Transaktionsumgebung aus dem Bankenbereich.

Jede TP1-Transaktion besteht aus einer vorgegebenen Anzahl von Lese-, Schreib- und Update-Vorgängen und beinhaltet folgende Aktionen:

- Beginn Transaktion

- Kontostand lesen

- Saldo aktualisieren

- History-Satz einfügen

- Kassierer-Saldo aktualisieren

- Zweigstellen-Saldo aktualisieren

- Ende Transaktion; Commit-Prozedur

Der Benchmark simuliert Abbuchungen von den Konten bei einer großen Bank. Das Geldinstitut verfügt über zahlreiche Zweigstellen mit Kassierern und Kundenknoten. Der Ausgangspunkt ist, daß die Kunden 15 Prozent ihrer Abbuchungen bei einer entfernten Filiale tätigen. Das Anwendungsprogramm führt seine eigene Protokolldatei über die Kontenbewegungen. Pro Kontobewegung wird ein 50 Byte langer Protokollsatz hinzugefügt.

Die Kontoabbebung ist als atomarer Vorgang, also als Transaktion zu behandeln. Sobald der Benutzer erfährt, daß eine Aktion beendet ist, muß diese in der Datenbank gespeichert sein, Ferner bedeutet dies, daß partielle Änderungen zurückgenommen werden. Wenn aufgrund einer Störung nur das Kundenkonto und der Kassierer-Bestand aktualisiert worden sind, wird davon ausgegangen, daß das Datenbanksystem diese Buchungen rückgängig macht.

Die TP1-Spezifikation ist abgeleitet aus dem sogenannten DebitCredit-Benchmark, der im April 1985 in der Zeitschrift Datamation unter dem Titel "A Measure of Transaction Processing Power" veröffentlicht wurde (Jim Gray von Tandem Computers hatte die Grundlagen bereits 1984 definiert). Die gegenwärtigen Benchmark-Veröffentlichungen geben zwar an, daß ihre Messungen mit den im Datamation-Artikel angeführten Spezifikationen übereinstimmen, doch in vielen Fällen sind bei der Durchführung und Protokollierung der Benchmark-Tests wesentliche Abweichungen von diesem De-facto-Standard festzustellen.

Einige Datenbank-Anbieter haben in letzter Zeit mit der Veröffentlichung von Pseudo-TP1-Benchmarks den Markt dermaßen verwirrt, daß leicht Zweifel an der Gültigkeit und Genauigkeit der genannten DBMS-Leistungsdaten aufkommen können.

Zudem sind Verfächerungen möglich. Mit einer Datenbank, die kleiner ist als für den Test vorgeschrieben, können irreführend hohe Leistungsergebnisse erzielt werden. Der TP1-Test sieht vor, daß die Konten-, Zweigstellen- und Kassierer-Tabellen nach der zu erwartenden Transaktionsrate skaliert werden: 1 000 000 Konten (Datensätze) sind für ein 10-TpS-System erforderlich, 10 000 000 für ein 100-TpS-System. Viele Anbieter haben sogenannte TP1-Benchmark-Tests mit nur 100 000 Datensätzen durchgeführt. Diese Reduzierung ermöglicht es ihnen, einen unrealistisch hohen Datendurchsatz vorzutäuschen, da die gesamte Datenbank in den Hauptspeicher paßt. Fazit: Ein Benchmark, der reicht entsprechend skaliert ist, kann nicht als TP1-Benchmark bezeichnet werden.

Die History-Datei erweist sich als besonders kritischer Punkt für die Performance, wenn immer nur ein Benutzer Datensätze in diese Datei einfügen darf. Die Anwender sollten sich durch Pseudo-TP1-Benchmarks, bei denen die Einzeltabelle mit den historischen Transaktions-Datensätzen in mehrere Tabellen aufgespalten wird, nicht irreführen lassen. Durch diesen Trick wird jenes Nadelöhr vermieden, das bei manchen Systemen unvermeidlich auftritt, sobald mehrere Anwender versuchen, Datensätze in die gleiche Tabelle einzufügen.

Durch die Aufspaltung einer historischen Tabelle in mehrere Tabellen umgehen diese Systeme den Engpaß. Dies führt selbstverständlich zu unrealistisch hohen TP1-Transaktionsraten. Im TP1-Benchmark wird bei jeder Transaktion ein Datensatz in eine historische Tabelle eingefügt. Dies setzt voraus, daß ein Block mit verfügbarem Speicherplatz gefunden, der neue Datensatz gespeichert und die Speicherzuordnungs-Information aktualisiert wird.

Manche Datenbanksysteme fügen die neuen Datensätze immer der letzten zugeordneten Seite einer Tabelle hinzu. Wenn solche Systeme mit "page level locking" arbeiten, führt das Einfügen von Datensätzen in die historische Tabelle zu ernsthaften Engpässen: Die Datensätze lassen sich nur nacheinander in die Tabelle einfügen. Auch wenn eine andere Methode angewendet wird, führt der hochgradige Konkurrenzbetrieb bei Transaktionen, die gleichzeitig auf eine historische Tabelle zuzugreifen und Datensätze einzufügen versuchen, bei manchen Datenbanksystemen zu wesentlichen Leistungseinbußen.

Diese Technik verschleiert die Ergebnisse

Manche DBMS-Anbieter haben diesen Konkurrenzbetrieb künstlich reduziert, indem sie die einzelne historische Tabelle durch mehrere ersetzen. Dadurch verringert sich die Anzahl der Anwender, die Datensätze in ein- und dieselbe Tabelle einfügen wollen, und der Datendurchsatz bei Transaktionen wird erhöht. Diese Technik verschleiert die Ergebnisse besonders bei Systemen, die zu einem bestimmten Zeitpunkt nur eine Transaktion zulassen.

In dem Datamation-Artikel über TP1-Benchmarks wird nicht gefordert, daß zur Durchführung des Tests die Standard-Datensprache SQL verwendet werden muß. Die meisten Käufer von relationalen Datenbanksystemen fordern jedoch SQL. Sie richten sich dabei nach dem heutigen, auf Standards ausgerichteten Markt. Die Leser von aktuellen DBMS-Benchmark-Berichten sollten den Aussagen der Anbieter, die vorgeben, ihre Tests nach Standard ANSI-SQL-Methoden durchgeführt zu haben, erst nach gründlicher Überprüfung Glauben schenken.

Muß der Anbieter zum Erreichen einer bestimmten Leistung eigene, anbieterspezifische Methoden verwenden, die dem Industriestandard nicht entsprechen, so geschieht dies auf Kosten der Anwendungsportabilität und der Herstellerunabhängigkeit. Wenn die Leistung diskutiert wird, sollte man also gleichzeitig auch auf das Niveau der DBMS-Schnittstelle achten.

In einigen Benchmark-Berichten sind Ergebnisse angeführt, die mit den für die Transaktionsverarbeitung erforderlichen Antwortzeiten nicht übereinstimmen. Gemäß dem TP1-Standard müssen 95 Prozent aller Transaktionen innerhalb einer Sekunde ausgeführt werden. Viele Anbieter haben diese Richtwerte jedoch ignoriert oder abgeändert, um die Transaktionsraten künstlich anzuheben.

Der TP1-Benchmark zielt darauf, den maximalen Datendurchsatz zu messen, den ein System bei der Transaktionsverarbeitung erreichen kann, wenn die Antwortzeit für jeden Benutzer des Systems weniger als eine Sekunde betragen soll. Obwohl der Datendurchsatz in Transaktionen pro Sekunde angegeben wird, ist es auch wichtig, die Antwortzeiten für jede einzelne Transaktion jedes Benutzers zu kennen.

Löst eine ausreichende Anzahl von Benutzern gleichzeitig Transaktionen aus, kann der erreichte Systemdurchsatz beeindruckend scheinen, selbst wenn die für jeden einzelnen Benutzer erreichten Antwortzeiten eine Sekunde weit überschreiten; wenn bei 100 Benutzern Antwortzeiten von vier Sekunden pro Benutzer erreicht werden, ergibt das einen Durchsatz von 25 TpS.

Kurze Antwortzeiten und hoher Datendurchsatz sind also gleichermaßen eine Notwendigkeit bei OLTP-Systemen. Der echte TP1-Benchmark-Test verlangt, daß 95 Prozent aller Transaktionen in weniger als einer Sekunde abgeschlossen werden.

Einige Anbieter haben für ihre Pseudo-TP1-Benchmarks irreführende Ergebnisse veröffentlicht. Manche Berichte enthalten lediglich die durchschnittliche Antwortzeit und nicht den Prozentsatz der in weniger als einer Sekunde abgeschlossenen Transaktionen. In einigen Berichten versuchen die Autoren, die Leistung eines langsamen Systems dadurch zu kaschieren, daß sie nur den Prozentsatz jener Transaktionen angeben, die in weniger als zwei Sekunden (anstelle von einer Sekunde) ausgeführt wurden. In anderen Berichten sind Durchsatzraten angegeben, bei denen weniger als 95 Prozent aller Transaktionen Antwortzeiten unter einer Sekunde erreichten. Jeder dieser Tricks führt zu unrealistisch hohen Durchsatzraten.

In einigen Benchmark-Berichten wird die für den Test verwendete Hardware-Konfiguration ungenau angegeben. Wenn die Angaben zur verwendeten Hardware unvollständig sind, ist ein Vergleich der Produkte verschiedener Anbieter nicht möglich.

Tests sollten reicht nur auf einer Hardware laufen

Zu einem korrekten TP1-Benchmark gehört auch die genaue Angabe der gesamten für den Test verwendeten Hardware. Dies gibt den Anwendern die Möglichkeit, die von verschiedenen Anbietern angegebenen Leistungsdaten unter gleichen Hardware-Voraussetzungen miteinander zu vergleichen.

Vor allen Dingen sollte der Anwender darauf achten, daß die Tests auf verschiedenen Maschinen durchgeführt wurden und nicht nur auf einer Hardware, die der Software sehr entgegen kommt. Und last, but not least: Die von den Anbietern angegebenen Leistungsdaten sind vollkommen wertlos - unabhängig von den angewandten Methoden oder von der Genauigkeit der Benchmark-Reports wenn sie mit einer Software erzielt wurden, die auf dem Markt nicht verfügbar ist.

Wie weit auch immer sich Standards und Kriterien für Benchmarks definieren lassen, es wird immer zuviel Raum für Manipulationen und Interpretationen bleiben. Letztendlich ist der tatsächliche Durchsatz nicht im "Labor-Test", sondern nur in der wirklichen Anwendung nachzuweisen.

Obwohl die Bereitstellung von Performance der vielleicht wichtigste Aspekt eines Datenbanksystems in einer OLTP-Anwendung ist, sollte man jedoch nicht andere wichtige Eigenschaften bei der DBMS-Auswahl unterbewerten - zum Beispiel Kommunikationsschnittstellen, Verteilbarkeit, Sicherheit, Entwicklungs-Tools, Hardware-/Betriebssystem-Unabhängigkeit, Multiprozessor-Support, offene Architekturen und Standard-Schnittstellen.

Noch einiges zur RDBMS-Performance. Immer noch hört man: "Relational ist gut in abfrageintensiven Anwendungen, aber nichts für OLTP-Systeme." Solche Aussagen basieren auf unangemessenen Gegenüberstellungen. Man vergleicht den Durchsatz eines relationalen Systems, das einen reorganisationsfreien Datenbestand anbietet und komplexe Vorgänge im Echtzeit-Verfahren komplett bearbeitet mit einem nicht-relationalen System, das einfachere Transaktionen durchfuhrt, die Nachfolgeläufe notwendig machen.