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

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

  • Upload
    brier

  • View
    74

  • Download
    0

Embed Size (px)

DESCRIPTION

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 - PowerPoint PPT Presentation

Citation preview

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

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

Nutzung des Parallel Sysplex

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

Group Buffer Pool

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

Nutzung des Coherency Protocol zum Lesen einer Seite

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

SDa Update BeispielUPDATE Angest

SET Gehalt = ‚10000‘

WHERE name = ‚Hans‘

BP4 BP4 BP4

DB2A DB2CDB2B

GBP4

Coupling Facility Shared Disk

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

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

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

SDa Update BeispielCOMMIT

BP4 BP4

DB2A DB2CDB2B

GBP4

Coupling Facility Shared Disk

BP4

GBP4

Coupling Facility

Secondary GBP4

X

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

SDa Update BeispielSELECT *

FROM Angest

THERE name = ‚Hans‘

BP4 BP4 BP4

DB2A DB2CDB2B

GBP4

Coupling Facility Shared Disk

GBP4

Coupling Facility

Secondary GBP4

X

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

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…

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

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)

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

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