Der Einsatz von DB2 – Wohin verschwinden die Ressourcen?

DB2 ist heute eine weit verbreitete relationale Datenbank auf dem Mainframe. Die fortlaufende Überwachung und Optimierung der Performance von DB2 ist dementsprechend eine häufige Aufgabe von DBAs, Application-Managers und Production-Managers.

Sie sind verantwortlich für das Einhalten der SLAs, müssen das Meiste aus der aktuellen IT-Infrastruktur herausholen. Es stellt sich die Frage: Wohin verschwinden die Ressourcen?
Eine Analyse ergibt, dass Ressourcen sowohl in der Anwendung, als auch im DB2 adress space verbraucht werden. Die folgende Tabelle verdeutlicht dies.

Was wurde bereits getan und was kann noch getan werden?

Das Optimieren von DB2 ist aufgeteilt zwischen DBAs und Application-Managers.
Der Fokus liegt auf der Vermeidung von I/O Operationen. Großes Einsparpotenzial bietet die Optimierung von Indizes. Durch Konformität zwischen Abfragen und Indizes kann viel I/O eingespart werden.
Bufferpools und das Zwischenspeichern von Daten findet sowohl im Adressbereich der Anwendung als auch der DB2 Datenbank statt. Dies reduziert weiter I/O. Auch andere Ressourcen werden dadurch reduziert, möglicherweise manche andere für die Verarbeitung erhöht. In der Regel finden große Einsparungen vor allem im I/O statt.
Für CPU Ressourcen sowie konkurrierend genutzte Ressourcen wird wenig getan.
Es gibt eine weitere Möglichkeit, die darauf wartet, genutzt zu werden:
Intelligentes Zwischenspeichern von Abfragen.
Worum handelt es sich dabei?
Die meisten Anwendungen nutzen unter anderem einen Satz von Tabellen, der selten verändert und häufig adressiert wird.
Abfragen auf diese Tabellen kommen sehr häufig vor.
Wesentlich dabei ist, dass das Resultat von diesen wiederholenden Abfragen stets identisch ist. Beispiele dafür sind:
Fehlermeldungen, Informationsmeldungen, Städtenamen, Namen von Staaten, Postleitzahlen, Zinssätze etc.
Das Zwischenspeichern von Abfragen („query caching“) bedingt die Lokalisierung und die eindeutige Identifikation von Abfragen, das Zwischenspeichern (“over the 64-bit BAR”) und das schnelle Auffinden und Zurückgeben des Resultats.
Bei Benchmark-Durchläufen hat sich gezeigt, dass der Effekt auf alle DB2 Ressourcen erheblich ist.

Qsel/DB2 – Das Zwischenspeichern von Abfragen bringt sehr große Einsparungen

Qsel/DB2 wendet mehrere Strategien und Technologien beim Zwischenspeichern von Abfragen an.

Qsel/DB2 fängt alle SQL Befehle ab, bevor sie an DB2 gerichtet werden.
Sollten sie nicht für das Zwischenspeichern geeignet sein, werden sie an DB2 weitergeleitet.
Bei zwischenspeicherbaren Abfragen wird überprüft, ob sie zu den Tabellen und Anwendungen gehören, von denen wiederholende Abfragen kommen. Geeignete Abfragen werden mit „Fingerabdrücken“ versehen.
Dies stellt sicher, dass jede wiederholbare Abfrage eindeutig dem Resultat zugeordnet wird.
Da der gesamte Prozess auf einem syntaktischen Level ausgeführt wird, beinhaltet er nur sehr wenig Overhead.

Es werden Selects, Cursors und Joins unterstützt. Beim Zwischenspeichern der Abfrage wird die 64–BitTechnologie genutzt. Es finden keine Änderungen an den Adressbereichen, kein SVC und keine Programmaufrufe statt – die Logik ist superschnell und gradlinig.
Um Qsel/DB2 einzusetzen, werden keine Änderungen an Ihren Programmen benötigt. Wenn beim Aufruf von DB2 die Serviceroutine dsnhli dynamisch ausgeführt wird, muss nichts weiter getan werden, um das Modul oder DBRM zu laden.

Die Funktionsweise von Qsel/DB2 ähnelt der eines Plug-Ins – einfach Einklinken. Die Standard-Version von Qsel/DB2 benötigt keine SVC und keine System-Installation.
Qsel/DB2 bietet sowohl Einsparungen der CPU-Zeit als auch im I/O, sowohl für die Anwendung, als auch für DB2.

Für die BatchUmgebung bietet Qsel/DB2 eine Shared Memory Option (SMO). SMO spart den Speicher, der zwischen wiederholtem Aktivieren von Programmen angesammelt wird.
SMO hält die zwischengespeicherten Daten in einem gemeinsam genutzten Bereich “above the Bar” und ermöglicht die konstante Verwendung des Zwischenspeichers bis zur Freigabe oder bis zum nächsten Initial Program Load (IPL).
Diese Option bringt zusätzliche Einsparungen, zieht aber die Installation von SVC und einer Sub-System Definition nach sich.

Für weiter Informationen besuchen Sie www.oak-software.de oder schreiben Sie an info@oak-software.de