DB2 für zOS bzw. OS/390 auf zSeries Nutzung des Parallel Sysplex

Inhalt Data Sharing Konzepte Share Group Sysplex im Übeblick Global Locking Group Buffer Pool Update Beispiel Castout Global Logging und Recovery

Data-Sharing Konzepte Partitioned or Shared-Nothing (SN) Technologie Kopplung mehrere getrennter Systeme zu einem Rechnerverbund Jeder Knoten mit eigenem I/O System 2 Zugriffsmethoden: - Function Shipping Methode Funktionen wird auf entfernten Knoten Aufgerufen und das Ergebnis übertragen. - I/O Shipping Methode Starten entfernter I/O Operation Daten werden transportiert Locking übernimmt entfernter Knoten SN: -2pc Protokoll stellt sicher, dass bei gleichzeitiger Transaktion auf zwei DB‘s erfolgreiches Commit - 1:1 Beziehung zwischen DBMSs und Datenbank

Data-Sharing Konzepte Shared-Disk (SDi) Technologie Rechnerverbund mit gemeinsam genutztem I/O System - dafür notwendig: Global Locking und Synchronisationsprotokolle - Lock Manager verwaltet Locks auf einem Knoten - Knoten der Seite Anfordert verwaltet Lock - Buffer Invalidation !!!  Shared Data (SDa) SDi: - Daten für alle zugänglich - Vorteile: - Redundanzfreie Abspeicherung von Daten, die auf mehreren System genutzt werden - Änderungen sofort für alle sichtbar Low Level Version im Buffer SDa: - bessere Perfomance, Weiterentwicklung des SDi

Anspruch - Skalierbarkeit des Systems  aufteilen der Arbeitslast auf zwei CPC (central prozess complexes) - gleiche Lese- und Schreibzugriffsrecht für alle DBMS - Aufnahme neuer Subsysteme ohne weiteres möglich - capacity when you need it Multisystemüberwachung wird nur aktiviert, wenn wirklich gleichzeitiger Zugriff erfolgt Data Sharing auf jedem Granulat unterstützten (table space, table, page, row) vollen Zugriff auf: - den OS/390 Nutzerkatalog - gemeinsam genutzte Datenbanken/ICF (integrated catalog facility) Nutzerkatalog - DB2 Katalog und Systemkatalog - Recovery Log’s und Bootstrap Data Sets (BSDSs) jedes Mitgliedes sicherer paralleler Zugriff auf Daten der DASD‘s ohne „lange Wartezeiten“ für Transaktionen Skalierbarkeit ohne Kopien der Datenbankkataloge und Daten anzufertigen Sysplex query paralism: ermöglicht die gesamte Leistung für eine Anfrage zu verwenden

Share Gruppen DB2 Subsysteme, die auf das DASD (direct access storage device) zugreiffen werden zu einer data sharing group gefasst DB2 Systeme Arbeiten auf einzelnen MVS (multiple virtual storage)/OS390 Systemen in jeder Gruppe können mehrere OS/390 Systeme vorkommen Nutzung eines Datenbankkatalogs in einer Sysplex können mehrere Gruppen definiert werden z.B. Entwicklergruppe und Testgruppe o.ä. ohne Daten doppelt zu Speichern

Parallel Sysplex - Überblick - GBP Group Buffer Pool - SCA Shared Communication Area - Sysplex Timer für Logging DASD Direct Access Shared Disk BSDS Bootstrap Data Set SCA: Shared Communication area: Zeichnet den Exception Status der Datenbank auf und wird für Optimierungsprozesse verwendet - einzelnen MVS bzw. dessen Prozessoren (CPCs-central processing complexes) sind mit der Coupling Facility über CF channels und high-speed fiber optic links Verbunden, die es den MVS erlauben gleichzeitig/CPU Synchron mit der CF zu interagieren - Jedes Mitglied hat seine eigenen Log’s sowie BSDS in der DASD Somit können alle anderen Benutzer bei einem auftretenden Fehler erfolgreiches Recovery durch die Einsicht in die Logs der anderen durchführen. Dazu benötigt DB2 noch einen so genannten sysplex timer der eine interne Systemzeit darstellt um den Zeitpunkt eines Fehlers und die zu diesem Zeitpunkt laufenden Transaktionen,… zu rekonstruieren.

Global Locking IRLM kommuniziert über die XES (system extended services) mit der CF lock struktur Konfliktbehebung erfolgt über direkte CTC (channel to channel) Verbindung mit Hilfe der XCF (cross-system coupling facility) Wesentlichen Bestandteile der CF Lock Struktur : - Lock Table - Record List eine CF Lock Struktur für n OS/390 Systeme Auf jedem der Systeme läuft ein DB2 Subsystem Jedes DB2 Subsystem ist mit einem IRLM – sozusagen der LLM lokale lock manager – verbunden für das intra-DB2 locking IRLM kommuniziert über XES system extended services mit der CF lock struktur = GLM global lock manager Tritt ein Konflikt zwischen den LLM auf wird die XCF cros-system coupling facility komponente benutzt um den Fehler über die CTC channel to channel Verbindung zu beheben Zwei wesentlich Bestandteile: Lock Table: dient dem schnellen Erkennen von inter-DB2 Lock Konflikten Record List: dient dem schnellen Erkennen von modify locks und retained locks modify locks und retained locks wenn ein System während einer Transakion ausfällt können alle anderen DBMS auf die evtl. inkonsistenten Daten zugreifen modify lock wird bei einem Update durch einen Member erstellt tritt fehler auf, dann wird aus modify lock ein retined lock bis das fehlerhafte System ein Recovery zurück zu einem konsistenten Zustand durchführt oder eine gewisse Zeit verstrichen ist Retained locks stehen in der Record list und im IRLM Redundanz für schnelleren Zugriff auf Ressourcen Modify locks und nonmodify locks

Nutzung der Lock Table Lockzustände SHR Besitzer EXC Besitzer Exklusiv (EXC) Shared (SHR) Frei SHR Besitzer Bitmap für 32 Systeme EXC Besitzer n j i . 2 1 DB2A 0000000000000000… 01100011… Hashklassen Real Contention: Realer Wettbewerb um dasselbe Betriebsmittel False Contention: System mit Hasheintrag hält anderes Lock

DB2 ULWO Buffer Konzept Cachen von Seiten 50 buffer pools mit 4k großen Seiten  4k table space oder index space 10 buffer pools mit 32k großen Seiten Local Buffer Pool Virtual buffer pool Hiperpool - Direkter zugriff über - optional Adressraum - Auslagerungsspeicher des Virtual - R/W Operationen Pool - Abdeckung durch Hauptspeicher, - Expanded Storage Expanded Storage und Auxilary Storage - bis zu 8GB - bis zu 1,6GB „no force at commit“ Strategie (außer logs) Auxilary: zusätzlichen Zusammenfassen größerer Mengen von Daten um auf Disk zu schreiben (Performance)

DB2 OS/390 Buffer Konzept Problem: zweites DBMS kann down level version kurz nach Transaktion in seinen eigenen Puffer laden Cache Coherence Idee: force-at-commit (SDi) - veränderte Seiten werden sofort auf Platte geschrieben - Seiten in anderen buffer pools müssen als ungültig deklariert werden Bessere Lösung (SDa): group buffer pools in der Coupling Facility - nutzung der high speed channels und fiber optic links d.h. neue Seite muß durch I/O Protokoll auf Disk, Seiten der anderen als ungültig, andere DBMS müssen sich neue Seite von Disk holen = SCHLECHT Unter Cache Coherence versteht man das Problem des Updates von gecacheten Objekten. Man muß Verfahren entwickeln, um zu erkennen man ein Objekt veraltet ist, d.h. daß das Quelldokument geändert wurde, der Cache aber noch die alte Fassung des Dokuments besitzt. Das sicherste wäre es, bei jeder Anfrage an den Cache beim Original Server nachzufragen, ob die angeforderte Seite geändert wurde. Dies würde aber die Idee des Caches zum größten Teil zunichte machen

Group Buffer Pool Seiten werden Group Buffer Pool gespeichert Aktuellste Version immer im Puffer Xled Signals werden durch CF verwaltet ohne dabei Prozessorleistung zu beanspruchen Refresh vom GBP Kein direkter Zugriff auf GBP-BM regelt das DB2 erkennt dynamisch ob Daten zur Zeit global verwendet werden

Nutzung des Coherency Protocol zum Lesen einer Seite SDa Page Lock ist im SDa bereich immer Global Gültigkeitsprüfung durch BM erfolgt auf einem array in der Hardwar storage area

SDa Update Beispiel BP4 BP4 BP4 GBP4 UPDATE Angest SET Gehalt = ‚10000‘ WHERE name = ‚Hans‘ DB2A DB2B DB2C BP4 BP4 BP4 GBP4 Shared Disk Coupling Facility

SDa Update Beispiel BP4 BP4 BP4 GBP4 GBP4 UPDATE Angest SET Beruf = ‚Siebenschläfer‘ WHERE name = ‚Hans‘ DB2A DB2B DB2C BP4 BP4 BP4 GBP4 GBP4 Secondary GBP4 Shared Disk Coupling Facility Coupling Facility

SDa Update Beispiel X BP4 BP4 BP4 GBP4 GBP4 COMMIT Secondary GBP4 DB2A DB2B DB2C BP4 BP4 BP4 X GBP4 GBP4 Secondary GBP4 Shared Disk Coupling Facility Coupling Facility

SDa Update Beispiel X BP4 BP4 BP4 GBP4 GBP4 SELECT * FROM Angest THERE name = ‚Hans‘ DB2A DB2B DB2C BP4 BP4 BP4 X GBP4 GBP4 Secondary GBP4 Shared Disk Coupling Facility Coupling Facility

Castout BP4 BP4 BP4 GBP4 GBP4 Interest Flags Changed Cached Castout Status etc. DB2A 1 Yes Yes Yes DB2B 0 … DB2A DB2B DB2C Wann wird gecastet? - Directory Eintrag für jede verwendete Seite Speicherung im GBP Wann Castout?  Castout Threshold Castout class threshold Existiert eine castout class queue in der alle tabellen einer Partition vermerkt sind Überschreitet die Anzahl der Tabellen (z.B. 10% der Gesamtkapazität der Queue) eine gewisse Schranke werden diese auf Platte geschrieben Feste Anzahl von Cast Out Class Queues in Group Buffer Pool Überschreitet die Anzahl der Partitionen die Anzahl der Class Queues werden mehrere Partitionen in eine Class Queue gefasst Group Bufferpool Threshold Bildet Schranke für die Gesamtanzahl der geänderten gepufferten Seiten in einem GBP (50%) Gleiches Konzept in ULWO, außer dass hier nicht mehrere Partitionen in eine Queue können Nach Castout Löschen der Daten im secondary GBP DB2 verwendet beide Konzepte gleichzeitig BP4 BP4 BP4 GBP4 GBP4 Secondary GBP4 Shared Disk Coupling Facility Coupling Facility

Logging und Data Recovery LRSN log record sequential number für die ganze Gruppe (6byte) erzeugt durch Sysplex Timer diese ersten 6 Stellen des Time Stamp werden alle 16microsec. um eins erhöht  Problem: Zwei Updates auf die selbe Seite innerhalb der 16microsec.  Log Manager kontrolliert LRSN BSDS (Boot Strap Data Set): - Übersicht über alle active Log‘s und archive Log‘s - enthält LRSN der Logs - Checkpoints… Was passiert bei einem Fehler der CF ? Sicherheitsmaßnahmen: mind. 2 CF paralell laufen lassen prim. und sec. GBP - dazu noch SFM (Sysplex Failure Manager) BSDS: Informationen über die Logs wichtigster Ansprechpartner für Rollback usw. doppelte Speicherung des BSDS

Fakten und Zahlen SDi: Verwendet Intersystem Messaging um Lockkonflikte zu lösen (asynchron)  CPU Belastung Zeit: ~20msec SDa: Synchrone Interaktion mit der CF um Lockkonflikte zu lösen Zeit: ~100µsec Benötigt zum Auslesen einer 4K großen Seite 175µsec Begriff: Overhead  zusätzlich benötigte CPU Leistung um die selbe Leistung zu erreichen Statistik des IBM Santa Teresa Laboratory Test durch 7 verschiedene Tabellen und 7 Transaktionen  13,29% data sharing Overhead in two-way data sharing  13,55% data sharing overhead in three-way data sharing Overhead Beispiel: 2 non-Sharing Systeme schaffen insgesamt 200 Transaktionen/Sec wobei jeder n Units der CPU benutzt fügt man diese zusammen in eine in eine data sharing Umgebung und erreicht dabei mit der gleichen Anzahl der CPU Units nur noch 170 Transaktionen/Sec so hat man 15% data sharing Overhead