Download - DB2 für zOS bzw. OS/390 auf zSeries
DB2 für zOS bzw. OS/390 auf zSeries
Nutzung des Parallel Sysplex
Inhalt
1. Data Sharing Konzepte
2. Share Group
3. Sysplex im Übeblick
4. Global Locking
5. Group Buffer Pool
6. Update Beispiel
7. Castout
8. 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
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)
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
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
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
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
Nutzung der Lock Table
DB2A 0000000000000000…
01100011…
EXC BesitzerSHR BesitzerBitmap für 32 Systeme
LockzuständeExklusiv (EXC)Shared (SHR)Frei
n
j
i
.
.
2
1
Hashklassen
Real Contention: Realer Wettbewerb um dasselbe BetriebsmittelFalse 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 - optionalAdressraum - Auslagerungsspeicher des Virtual- R/W Operationen Pool- Abdeckung durch Hauptspeicher, - Expanded StorageExpanded Storage und Auxilary Storage - bis zu 8GB- bis zu 1,6GB
„no force at commit“ Strategie(außer logs)
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
Group Buffer Pool
Nutzung des Coherency Protocol zum Lesen einer Seite
SDa Update BeispielUPDATE Angest
SET Gehalt = ‚10000‘
WHERE name = ‚Hans‘
BP4 BP4 BP4
DB2A DB2CDB2B
GBP4
Coupling Facility Shared Disk
SDa Update BeispielUPDATE Angest
SET Beruf = ‚Siebenschläfer‘
WHERE name = ‚Hans‘
BP4 BP4
DB2A DB2CDB2B
GBP4
Coupling Facility Shared Disk
BP4
GBP4
Coupling Facility
Secondary GBP4
SDa Update BeispielCOMMIT
BP4 BP4
DB2A DB2CDB2B
GBP4
Coupling Facility Shared Disk
BP4
GBP4
Coupling Facility
Secondary GBP4
X
SDa Update BeispielSELECT *
FROM Angest
THERE name = ‚Hans‘
BP4 BP4 BP4
DB2A DB2CDB2B
GBP4
Coupling Facility Shared Disk
GBP4
Coupling Facility
Secondary GBP4
X
Castout
BP4 BP4 BP4
GBP4
Coupling Facility Shared Disk
GBP4
Coupling Facility
Secondary GBP4
DB2A DB2CDB2B
Interest Flags
Changed Cached Castout Status
etc.
DB2A 1 Yes Yes YesDB2B 0…
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)
Fakten und Zahlen
SDi: Verwendet Intersystem Messaging um Lockkonflikte zu lösen (asynchron) CPU Belastung
Zeit: ~20msecSDa: Synchrone Interaktion mit der CF um Lockkonflikte zu lösen
Zeit: ~100µsecBenö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