Als leistungsfähiger Datenbankserver für alle Einsatzbereiche ist SESAM/SQL in der Lage, unterschiedliche Auftragstypen ohne gegenseitige Behinderung auszuführen. Prinzipiell lassen sich zwei Auftragstypen unterscheiden:
OLTP-Anwendungen
In OLTP-Anwendungen greift eine hohe Anzahl von Benutzern auf die gleichen Datenbanken und Anwendungen zu. Beispiele sind Auftrags-Abwicklungssysteme, Buchungssysteme und Lagerhaltungssysteme. Man spricht hier oft von „Produktivbetrieb“..
Die OLTP-Transaktionen bestehen in der Regel aus wenigen Lese- und Schreibanweisungen. Dabei wird eine kleine Anzahl unterschiedlicher Transaktionen sehr oft wiederholt..
Das Thema OLTP ist auf "Online Transaction Processing (OLTP)" genauer beschrieben.Individuelle Datenverarbeitung (IDV)
In der individuellen Datenverarbeitung werden häufig sehr komplexe Anfragen an das Datenbanksystem gestellt, bei denen oft ganze Datenbanken gelesen und umfangreiche Berechnungen durchgeführt werden. Als typisches Beispiel sind statistische Auswertungen zu nennen.
Mit modernsten Technologien realisiert SESAM/SQL zusammen mit dem Transaktionsmonitor openUTM einen performanten OLTP-Betrieb mit kurzen Antwortzeiten. Gleichzeitig sorgen Parallelisierungsfunktionen und ein leistungsfähiger Optimizer dafür, dass die IDV den OLTP-Betrieb nicht behindert. Dies ist eine wichtige Voraussetzung für Client/ServerArchitekturen, in denen z.B. PC-Anwendungen (Tabellenkalkulation, Textverarbeitung usw.) umfangreiche Anfragen starten, um Daten aufzubereiten und weiterzuverarbeiten (siehe auch "SESAM/SQL im Client-Server-Umfeld"). Die folgenden Abschnitte beschreiben die wichtigsten Technologien und Funktionen.
Multithreading
Mit der Multithreading-Architektur kann der SESAM/SQL-Data Base Handler (DBH) Aufträge parallel verarbeiten und so die Zeit nutzen, in der Aufträge z.B. auf den Abschluss von Ein- und Ausgabevorgängen warten. Für die Dauer des Ein- und Ausgabevorgangs aktiviert SESAM/SQL dann die Bearbeitung eines anderen durchführbaren Auftrags. Der Durchsatz steigt dadurch erheblich. Ebenso werden langlaufende und komplexe Datenbankabfragen portionsweise abgearbeitet, ohne den OLTP-Betrieb zu behindern. Der DBH nutzt die Anzahl der Threads lastabhängig; nicht alle Threads sind also ständig belegt.
Multitasking
SESAM/SQL-Server gibt es als Standard Edition mit Singletask-Betrieb und als Enterprise Edition, die den Multitask-Betrieb unterstützt.
Mit der Multitasking-Architektur kann der SESAM/SQL-Data Base Handler (DBH) bei höheren Performance-Anforderungen auch mit mehreren Tasks geladen werden. Dadurch lässt sich bei Multiprozessor-Anlagen die DBH-Last auf mehrere Prozessoren verteilen.
Auslagerung CPU-intensiver Aktionen
SESAM/SQL lagert CPU-intensive Aktionen auf sogenannte Service-Tasks aus, wo sie parallel zum eigentlichen DBH-Betrieb ablaufen. Service-Tasks stehen zum Beispiel für CPUintensive Funktionen der Datenbankverwaltung und für das Sortieren von Zwischenergebnissen zur Verfügung.
Cost Based Optimizer
Wenn ein Anwenderprogramm eine SQL-Anweisung absetzt, erstellt SESAM/SQL einen Zugriffsplan. Dieser beschreibt die Art und die Reihenfolge der einzelnen Auswertungsschritte der SQL-Anweisung. Der Cost Based Optimizer sorgt dafür, dass ein besonders effizienter Zugriffsplan erstellt wird, bei dem möglichst wenig Systemressourcen beansprucht werden (CPU-Zeit, I/O-Zugriffe).
Shared SQL
Der optimierte Zugriffsplan wird im Arbeitsspeicher gehalten und kann von mehreren Benutzern verwendet werden. Besonders bei OLTP-Anwendungen, in denen bestimmte Verarbeitungsschritte häufig wiederholt werden, erhöht sich durch Shared SQL die Leistung entscheidend.
Shared Record Lock
Wenn ein Datensatz gelesen wird, so wird dieser normalerweise für andere Transaktionen gesperrt. Durch den „Shared Record Lock“ ist es möglich, dass andere Transaktionen diesen Satz lesen können. Dadurch sinkt die Zahl der Blockierungen, und es können mehr Transaktionen parallel durchgeführt werden. Die Transaktionsleistung erhöht sich. Das erweiterte Sperrkonzept beeinträchtigt die Transaktionssicherheit nicht, da Shared Record Locks immer nur dann möglich sind, wenn keine Daten verändert werden.
Datenkomprimierung
SESAM/SQL komprimiert die Daten bei der Speicherung automatisch. Sie beanspruchen somit weniger Speicherplatz.
Es werden nur signifikante Werte abgespeichert, nicht signifikante Werte belegen keinen Speicherplatz.
Die Datentypen NUMERIC und DECIMAL werden nur in der signifikanten Länge ohne die führenden Nullen abgespeichert.
Der Datentyp CHARACTER wird nur in der signifikanten Länge abgespeichert, wobei die nachfolgenden Leerzeichen entfallen.
Durch die Komprimierung der Daten auf signifikante Werte kann die Datenbank auf maximale Erfordernisse ausgelegt werden. Damit ist Folgendes problemlos möglich:
Spalten definieren, für die es nur in wenigen Datensätzen Werte gibt
bereits beim Einrichten der Datenbank Spalten definieren, die erst für zukünftige Anwendungen infrage kommen
Spaltendefinitionen beibehalten, auch wenn es keine Werte mehr dafür gibt.
Da die Datensätze wegen der Komprimierung kürzer sind und sich deshalb über weniger Speicherblöcke erstrecken, beschleunigt sich der Zugriff auf die Daten. Zudem können mehr Datensätze im Arbeitsspeicher gehalten werden, wodurch die Anzahl der Plattenzugriffe reduziert wird.
SESAM/SQL-LINK - die Linked-in-Variante von SESAM/SQL
Die Linked-in-Variante ist für die besonders effiziente Verarbeitung eines einzelnen Anwenderprogramms gedacht. Der linked-in DBH wird dabei fest in das Anwenderprogramm eingebunden. Die angeschlossenen Datenbanken sind dem Anwenderprogramm exklusiv zugeordnet. Gegenüber dem Betrieb mit dem independent DBH entfällt bei der linked-in Variante die Zeit für die Kommunikation zwischen Anwenderprogramm und DBH sowie der Aufwand für die Verwaltung von Sperren.
Der Einsatzbereich von SESAM/SQL-LINK liegt in der Abarbeitung von Batchprogrammen mit exklusivem Datenbankzugriff.
Funktionale Abweichungen oder Hinweise, die beim Einsatz des linked-in DBH zu beachten sind, sind innerhalb der SESAM/SQL-Handbücher an der Stelle beschrieben, wo sie für den Anwender wichtig sind.
SESAM/SQL-LINK ist für SX-Server nicht verfügbar.
Global Storage
Die Performance eines Datenbanksystems wird nicht nur von der Prozessorleistung beeinflusst. Gerade bei Datenbanksystemen erfolgen viele Lese- und Schreibzugriffe auf Festplatten, die im Vergleich zu Zugriffen auf den Hauptspeicher relativ langsam sind. Für die BS2000-Systeme wurden deshalb besonders schnelle Speichermedien entwickelt. So bietet zum Beispiel der Global Storage - ein batteriegepufferter Halbleiterspeicher - eine 2000mal schnellere Zugriffszeit als Magnetplatten. SESAM/SQL kann den Global Storage als Datencache benutzen, wodurch Schreib- und Lesezugriffe auf Platten drastisch beschleunigt werden. Die Gesamtleistung verbessert sich deutlich.
Schubmodus (Block Mode)
Ein Cursor kann mit sogenanntem Schubmodus definiert werden. Im Schubmodus veranlasst die erste Ausführung der FETCH NEXT-Anweisung, dass mehrere Sätze in einen Zwischenpuffer gelesen werden. Der Anwender erhält mit der ersten Ausführung der FETCH-Anweisung nur den ersten übertragenen Satz. Die nachfolgenden Ausführungen der FETCH-Anweisung übertragen jeweils einen Satz aus dem Zwischenpuffer (ohne erneute Task-Task-Kommunikation), bis der Zwischenpuffer leer ist. Eine weitere Ausführung der FETCH-Anweisung führt dann wieder zur Übertragung mehrerer Sätze. Durch diesen Schubmodus kann die Bearbeitung eines Cursors wesentlich beschleunigt werden.
64-Bit-Ladevariante des SESAM/SQL-DBH
Die 64-Bit-Ladevariante des SESAM/SQL-DBH wird mit SESAM/SQL automatisch auf allen aktuellen BS2000-Servern geladen.
Zu erkennen ist dies in der DBH-Startmeldung am Insert „(64-Bit VERSION)“ für /390-Server und „(X86-64-VERSION)“ für x86-Server.
Erweiterte Pufferoptionen
Die 64-Bit-Ladevariante erlaubt eine performantere Abwicklung der Ein-/Ausgabelast durch einen größeren Maximalwert des Puffers für Systemzugriffsdaten (DBH-Option SYSTEM-DATA-BUFFER) und des Puffers für Anwenderdaten (DBH-Option USER-DATA-BUFFER), siehe Handbuch „ Datenbankbetrieb“.
Gleichzeitig belasten die Puffer in diesem Fall nicht den normalen Adressraum der Task (2 GB), so dass für die anderen Optionen größere Werte möglich sind.