Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

22.06.1990 - 

Performance-Management beginnt bei der Implementierung:

DB2 : Der Anwender bestimmt die Leistung seiner Datenbank

Kaum ein Großrechner-Anwender will heute noch auf das relationale Datenbanksystem DB2 verzichten. Doch selbst das modernste Produkt nützt nur dann etwas, wenn es optimal eingesetzt wird. Udo Pfeiffer* hat sich die IBM-Datenbank gründlich angesehen und dabei ein Reihe von Möglichkeiten gefunden, Höchstleistungen aus dem System zu holen.

DB2 wird häufig wegen der niedrigen Gesamt-Performance und seines hohen Ressourcenverbrauchs kritisiert. Für den Erfolg von Produktionsanwendungen ist es daher von entscheidender Bedeutung, daß die Leistung überwacht und ein entsprechendes Tuning durchgeführt wird. Weiterhin ist es erforderlich, das Datenbanksystem sowohl unter der Perspektive der System- als auch unter der Anwendungs-Performance zu untersuchen.

Optimale Auslastung der Systemressourcen

Aus dem Blickwinkel der Systemauslastung sollen Möglichkeiten für die Optimierung der Ressourcennutzung gefunden werden. Die Untersuchung der Anwendungs-Performance beschäftigt sich mit SQL-Abfragen von Programmen sowie mit Locking-Aktivitäten .

Ein DB2-Subsystem V2.1 setzt sich aus folgenden drei Adreßbereichen zusammen:

- System Services Adress Space (SSAS),

- Database Services Address Space (DBAS) und

- IMS/VS Resource Lock Manager (IRLM).

Diese Bereiche sind voneinander abhängig, operieren aber insgesamt als ein formales MVS-Subsystem. Die Kommunikation zwischen ihnen erfolgt über die MVS-Subsystem-Schnittstelle, die Cross Memory Services und die Schedule Request Blocks von MVS.

Innerhalb von SSAS und DBAS gibt es eine Vielzahl von DB2-Subkomponenten, die unter der Bezeichnung Ressourcen-Manager bekannt sind. Wie der Name sagt, verwalten sie die spezifizierten Systemressourcen. Da jeder Ressourcen-Manager eine besondere Funktion übernimmt, kann das Management der System-Performance unter dem Blickwinkel des jeweiligen Ressoursen-Managers untersucht werden.

Nicht alle Ressoursen-Manager in DB2 liefern oder benötigen solche Tuning-Funktionen. Ein Performance-Analytiker sollte jedoch seine Aufmerksamkeit auf diejenigen Aspekte richten, die sich durch die Wirkungsweise des Subsystem-Support-Managers (und der Anschlußfunktionen), des Buffer-Managers und des Recovery-Log-Managers ergeben.

Die Anforderungen der Benutzer werden vom Datenbank-System mit Hilfe von Verbindungsprotokollen durchgeführt und verwaltet. Auf diese Weise kommunizieren Anwendungen in CICS-, IMS- und TSO-Umgebungen mit DB2-Datenbanken und greifen auf sie zu. Realisiert wird die Verbindung durch sogenannte Anschlußfunktionen, die Subsystem-Unterstützung und Agent Services.

Die Anschlußfunktionen von DB2 residieren physisch im Adreßbereich des Benutzers und laufen auch dort ab. Sie liefern die Kommunikationsschnittstelle, die von einer Anwendung benötigt wird, damit sie auf DB2-Datenbankfunktionen zugreifen kann, wobei die Art ihrer Implementierung von den unterstützten Subsystemen abhängt. Dabei besteht der Verbindungsprozeß aus den drei Operationen Identifizierung, Sign-on und Einrichtung des Threads.

Die Identifizierung bildet die erste Phase des Verbindungsaufbaus. Die Anschlußfunktion, die, - wie bereits erwähnt - in dem Adreßbereich des Benutzers läuft, setzt eine Identifizierungsanforderung ab. Diese Anforderung empfängt DB2 über die Subsystem-Schnittstelle, sie bewirkt, daß eine interne Steuerstruktur zugeordnet wird, um den Anforderer zu unterstützen

Im Gegensatz zu dem Sign-on und der Thread-Einrichtung, die nach Abschluß einer Identifizierungsanforderung wiederholt durchgeführt werden können, findet die Identifizierung dann statt, wenn eine DB2-Anschlußfunktion fordert, daß eine Verbindung hergestellt wird Auch wenn die Verbindung schon vorhanden ist, kann der Anforderer erst dann auf DB2-Ressourcen zugreifen, wenn die Phasen Sign-on und Thread-Einrichtung des Verbindungsprozesses abgeschlossen sind.

In der zweiten Phase wird ein individueller CICS- oder IMS-Benutzer für DB2 identifiziert. Da DB2 mehrere Benutzer aus einer CICS-Region (Einzelidentifizierung) und mehrere IMS-Regionen bedienen kann, muß der individuelle Benutzer während des Verbindungsprozesses in diesen Umgebungen überprüft werden. Die Sign-on-Phase ist also ein Überprüfungsprozeß, mit dem ermittelt wird, ob der Anforderer auf DB2-Ressourcen zugreifen darf. Das Sign-on gilt nicht für TSO-Benutzer, da es in einem TSO-Adreßbereich jeweils nur einen Benutzer gibt.

Leistungs-Management durch Thread-Begrenzung

Die Thread-Einrichtung ist die letzte Phase, die erforderlich ist, um Zugang zu DB2-Ressourcen zu erhalten. Ein DB2-Thread fungiert als Pfad zwischen der anfordernden Transaktion und spezifischen DB2-Ressourcen. Die Thread-Einrichtung führt dazu, daß eine weitere interne Struktur zugeordnet wird. Diese Struktur verwendet DB2, um alle Anforderungen und Ressourcen, die zu einem DB2-Benutzer gehören, zusammenzufassen.

Der Performance-Analytiker kann nun die DB2-Auslastung sowie die Inanspruchnahme der Systemressourcen verwalten, indem er die Anzahl der gleichzeitig aktiven Verbindungen und Threads begrenzt. Diese Festlegung geschieht mit Hilfe der Installationsoptionen, bei der auch die Anzahl gleichzeitig vorhandener Vordergrund und Hintergrund-Verbindungen definiert wird.

Im Falle eines ClCS-Anschlusses liefert die "Resource Control Table" (RCT) Optionen zur Steuerung der DB2-Auslastung. Damit kann der Analytiker DB2-Threads definieren, die für eine CICS-Region verfügbar sind, sowie die zugehörigen Transaktionen, die diese Threads benutzen. Das Modul wird, wenn CICS mit DB2 zu verbinden ist, von der ClCS-Anschlußfunktion geladen und genutzt. Beim Anschluß können zwei Thread-Typen, nämlich Entry-Threads und Pool-Threadse definiert werden.

Die Entry-Threads sind ausschließlich ausgewählten DB2-Ressourcen zugeordnet und können eine oder mehrere ClCS-Transaktionen bedienen. Pool-Threads dagegen verwenden alle Transaktionen, die keine ausschließlich zugeordneten Threads haben, gemeinsam. Sie können auch als Overflow-Bereich für Entry-Threads verwendet werden, um Warteperioden, bis ein Entry-Thread verfügbar ist, zu eliminieren.

Die Anzahl der DB2-Threads, die in IMS ihren Ursprung haben, läßt sich verwalten, indem die Anzahl der abhängigen Regionen begrenzt wird, die mit DB2 verbunden sind. Mit dem IMS-Anschluß hat jede abhängige Region, die an DB2 angeschlossen ist, einen einzelnen DB2-Thread. Die DB2-Verbindungen zwischen Steuerregionen und abhängigen Regionen von IMS werden im Subsystem Member (SSM) definiert, das in IMS Proclib residiert. Im Gegensatz zu CICS kann IMS Verbindungen zu mehreren DB2-Subsystemen definieren. Die IMS Verbindungen zu DB2 werden durch die Optionen gesteuert, die in dem SSM definiert worden sind. Beim Tuning des DB2 Verbindungsprozesses bildet die Optimierung der Thread-Wiederverwendung ein weiteres Performance-Ziel. Für DB2-Anforderungen, die nur einen minimalen Datenzugriff benötigen, sind die Kosten einer Thread-Einrichtung möglicherweise beträchtlich. Daher sollte die Wiederverwendung von Threads in erster Linie für Transaktionen mit großen Datenmengen in Erwägung gezogen werden.

In einer ClCS-Umgebung lassen sich Threads wiederverwenden, wenn sie als Entry-Threads definiert worden sind. Falls der System-Spezialist Transaktionen mit umfangreichen Datenbeständen dafür bestimmt, können die Threads wiederverwendet werden und die Gemeinkosten für die Thread-Einrichtung entfallen.

In einer IMS-Umgebung sind Threads wiederzuverwenden, wenn die Transaktion mit dem Attribut "Wait for input" (WFl) versehen ist. Die Thread-ID wird dann von der ersten SQL-Anforderung erzeugt und gelöscht, sobald die IMS-Verbindung endet. Die Performance-Analytiker können Threads auch dadurch wiederverwendbar machen, daß sie ein IMS-Class-Scheduling implementieren oder indem sie den Proclim-Count auf einen Wert größer als eins setzen. Die Fastpath-Regionen von IMS verwenden Threads immer wieder.

In- und Output als Flaschenhals

Das Volumen und die Antwortzeiten bei In- und Output-Operationen liefern wahrscheinlich in jedem Datenbanksystem die wichtigsten Performance-Werte. Zuständig ist hier der Buffer-Manager. Er soll die Anwendungsanforderungen bei einer minimalen Zahl von I/Os bedienen .

Zu den Benutzeroptionen für die Verwaltung von Datenbank-Bufferpools zählen die Angabe, wieviel Pools verwendet werden sollen, die Einstellung der Minimal- und Maximalgröße jedes Pools und die Definition, welche physischen Dateien dem Pool zuzuordnen sind. Um ein Tuning des Buffer-Managers durchführen zu können, müssen die Anforderungen an den Buffer-Manager, die physischen Lese- und Schreiboperationen die Erweiterungen und die Schwellwertvorkommen analysiert werden.

Bei den Leseoperationen des Buffer-Managers unterscheidet man zwischen synchronen Leseoperationen und sequentiellen Vorauslese-Operationen (Prefetches).

Die sequentielle Vorauslese-Operation findet in der Regel statt, wenn eine SQL-Anforderung zu einer Tabellenabfrage führt und das Volumen der abgerufenen Daten ihre Verwendung rechtfertigt.

Welche Leseoperation für die Verarbeitung von Benutzeranforderungen verwendet wird legt DB2 und nicht der Benutzer fest.

Die Schreiboperationen sind normalerweise nicht mit Benutzeranforderungen synchronisiert. Da der Log-Manager die Datenintegrität sicherstellt, kann der Buffer-Manager Ausgabeoperationen verzögern. Die aktualisierten Buffer-Seiten werden vor dem zugehörigen Tabellenbereich in eine Warteschlange gestellt, bis sie physisch geschrieben sind.

Zentrale Bedeutung hat die Größe des Bufferpools

Die Steuerung der physischen Lese- und Schreiboperationen unterstützen interne Schwellwerte im Buffer-Manager. Diese Schwellwerte basieren intern auf den nicht verfügbaren Buffer-Seiten und werden dazu verwendet, die Anzahl der physischen I/Os zu minimieren.

Die Größe des Bufferpools ist ein zentraler Leistungsfaktor. Die tatsächliche Leistung kann durch die Zuordnung großer Bufferpools verbessert werden.

Ein Ziel beim Tuning des Log-Managers besteht darin, die Wartezeiten der Anwendungen - verursacht durch das Fehlen von verfügbaren Log-Ausgabe-puffern - - zu begrenzen. Ein weiteres Ziel richtet sich darauf, die Wartezeit der Anwendungen während der Commit-Verarbeitung zu minimieren, wenn Log-Datensätze physisch geschrieben werden müssen, um die Wiederherstellbarkeit und die Integrität der Daten zu gewährleisten.

Die physische Plazierung der Logdateien ist von entscheidender Bedeutung; Situationen, in denen es zu Konkurrenz um eine Einheit kommt, sollten auf ein Minimum reduziert werden.

Die Spezifizierung des Log-Schreibschwellwertes ermöglicht eine Steuerung der asynchronen Aktivitäten durch den Log-Manager. Auf diese Weise läßt sich die Wartezeit einer Anwendung während der Commit-Verarbeitung für diese Anwendung, wenn alle Log-

Datensätze physisch in das Recovery-Log geschrieben werden müssen, reduzieren.

Leistungssteigerung im Produktionseinsatz

Eine DB2-Arbeitseinheit oder -Transaktion startet, sobald eine Anwendung die erste SQL-Anfrage empfängt. Die Transaktion wird durchgeführt und nach dem erfolgreichen Abschluß einer Commit- oder Abort-Anforderung beendet. Das Tuning auf der Anwendungsebene konzentriert sich auf die Analyse der aktiven Threads, die innerhalb DB2 laufen. Die Durchschnittsdauer einer Transaktion kann als Grundlage verwendet werden, um "störende" Transaktionen zu ermitteln und anschließend zu untersuchen.

DB2-Ressourcen werden typischerweise auf der Basis einer Arbeitseinheit in Anspruch genommen und freigegeben. Daher muß die Anwendung eine adäquate Commit-Logik enthalten, um Engpässe bei den Ressourcen zu verhindern. Zu den wichtigsten Bereichen, die die Anwendungs-Performance beeinflussen, zählen SQL- und Locking-Aktivitäten sowie Aktivitäten des Buffer-Managers.

Statistiken über SQL-Aktivitäten

Eine Analyse der anwendungsbezogenen SQL-Aktivitäten kann dazu beitragen, störende Transaktionen zu ermitteln. Die Überwachung der SQL-Aktivitäten erfordert die Führung von Statistiken für die verschiedenen SQL-Anforderungen, die von einer Anwendung abgesetzt werden.

Diese Übersichten sollten angeben, wieviel Anforderungen für Open-Cursors, Fetches, Selects, Updates, Inserts, Deletes, Prepares, Commits und Aborts abgesetzt werden.

Von besonderer Bedeutung sind Commit- und Abort-Aktivitäten mittels SQL. Anwendungen, die DB2-Tabellen ändern, müssen alle Änderungen periodisch festschreiben oder abbrechen. Ressoursen werden normalerweise während der Commit-Verarbeitung freigegeben. Eine schlechte Anwendungsstruktur mit nicht adäquater Commit-Logik kann daher DB2-Ressoursen vollständig verbrauchen und den Systemdurchsatz senken.

Zu viele Locks belasten die CPU

Das Anwendungs-Locking ist einer der Hauptbereiche, die im Rahmen einer Performance-Analyse untersucht werden müssen. DB2 verwendet Locks (Verriegelungen), um den Datenzugriff zu steuern und die Datenintegrität sicherzustellen.

Für das Locking stehen zwei Strategien zur Verfügung, nämlich das Locking von Tabellenbereichen und von Pages. Welche Art für einen Tabellenbereich zum Einsatz kommt, wird bei der Erstellung dieses Bereiches festgelegt. Die Zuordnung der Locks von Tabellenbereichen geschieht auf der Ebene dieser Bereiche; die Page-Locks dagegen werden auf der Ebene der Datapage gesetzt. Auf Sub-Pages läßt sich ein Locking der Indexbereichsseite implementieren. DB2 liefert eine Systemeinrichtung, um Page-Locks auf Tabellenbereichs-Locks anzuheben, wenn die Anzahl der Page-Locks, die zu der Anwendung gehören, diese Ausdehnung rechtfertigt.

Zur Verbesserung der Performance sollten Analytiker die Art und Anzahl der Locks untersuchen, die aufgrund von Anwendungsanforderungen notwendig sind. Eine übermäßige Zahl an Locks erhöht den DB2-Bedarf in bezug auf CPU und Hauptspeicher. Lock Suspensions und Deadlock-Situationen müssen ermittelt und untersucht werden, um eine schlechte System-Performance zu vermeiden.

SQL vereinfacht die DB2-Nutzung

Als Antwort auf eine einzelne SQL-Anforderung können viele Datensätze gelesen oder geändert werden. SQL vereinfacht die DB2-Nutzung und isoliert den Benutzer vor den Aspekten des Datenzugriffs und der Datenhaltung. Die SQL-Benutzer brauchen nur anzugeben, welche Daten sie benötigen, und müssen nicht wissen, wie diese Daten abgerufen werden.

Den Zugriffspfad für den Abruf der Daten legt intern der DB2-Optimiser fest. In der Regel kennen die Benutzer die internen Zugriffsmethoden nicht, mit denen ihre Anforderungen erfüllt werden. SQL-Anfragen, die ein sequentielles Lesen von DB2-Tabellen bewirken, können die System-Performance jedoch schwerwiegend beeinträchtigen .

DB2-Datenbankadministratoren können den Zugriffspfad für den Abruf der Daten beeinflussen, in dem sie Tabellenindizes erstellen. Da der Zugriffspfad, der für den Datenabruf verwendet wird, in der Regel transparent ist, sollte der Performance-Analytiker die Application-Buffer und die I/O-Aktivitäten überwachen. Anwendungen, die übermäßig viel Aktivitäten erzeugen, sollten unter die Lupe genommen werden. Zu den Informationen, die erforderlich sind, um die Aktivitäten des Application-Buffer-Managers zu überwachen und zu tunen, gehören Zählungen von Getpage, sequentielle Prefetches, synchrone Leseoperationen und Änderungsanforderungen.