1 / 20

DB2 für zOS bzw. OS/390 auf zSeries

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

brier
Download Presentation

DB2 für zOS bzw. OS/390 auf zSeries

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

  3. 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

  4. 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)

  5. 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

  6. 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

  7. 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

  8. 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

  9. Nutzung der Lock Table Lockzustände Exklusiv (EXC) Shared (SHR) Frei SHR Besitzer Bitmap für 32 Systeme EXC Besitzer Hashklassen • Real Contention: Realer Wettbewerb um dasselbe Betriebsmittel • False Contention: System mit Hasheintrag hält anderes Lock

  10. 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 poolHiperpool - 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)

  11. 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

  12. Group Buffer Pool

  13. Nutzung des Coherency Protocol zum Lesen einer Seite

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

  15. SDa Update Beispiel 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

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

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

  18. Castout DB2A 1 Yes Yes Yes DB2B 0 … DB2A DB2B DB2C BP4 BP4 BP4 GBP4 GBP4 Secondary GBP4 Shared Disk Coupling Facility Coupling Facility

  19. 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)

  20. 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

More Related