DB2 für OS/390 und zSeries

Architektur von DB2 für S/390 und Unterschiede zu DB2 für LUW

2

Inhalt1. Einleitung2. DB2 in der OS/390 Umgebung3. Von DB2 s/390 genutzte Attachment Facilities4. Distributed Data Facility5. Vergleich der Systemstrukturen von DB2 S/390 und DB2

LUW6. Vergleich von DB2 LUW und DB2 S/390 Datenstrukturen7. Kontrolle des Datenzugriffs8. Zusammenfassung

3

1. Einleitung- DB2 für S/390 ist führende relationale

Datenbank auf OS/390 bzw. z/OS Plattformen

- Vortrag soll dazu beitragen: - Architektur von DB2 S/390 ein wenig

kennen zu lernen - Unterschiede zu DB2 LUW aufzeigen

4

2. DB2 in der S/390 Umgebung operiert als formales Subsystem von OS/390

jedes DB2 Subsystem besteht aus 3 bis 5 Tasks jeder Task läuft in einem bestimmten Adress – Raum (adress space)

1. Database Services Address Space (DBAS)– dient der Manipulation der DB2 Datenstrukturen– verantwortlich für SQL – Ausführung und Buffermanagement– beinhaltet Kern – Logik des DBMS

2. System Services Address Space (SSAS)– koordiniert Zusammenarbeit von DB2 mit anderen Subsystemen– für alle Logging – Aktivitäten verantwortlich

3. Intersystem Resource Lock Manager (IRLM)– verantwortlich für Lock – Management (Deadlock eingeschlossen)

4. Distributed Data Facility (DDF)– notwendig für verteilte DB – Funktionalität

5. Stored Procedure Address Spaces (SPAS)– bestimmt für die Ausführung von Stored Procedures und

benutzerdefinierten Funktionen

DB2 Subsystem: getrennte Instanz des Relationalen DBVS, welche Schaffung, Organisation und Modifikation einer Datenbank kontrolliert und auf in der Datenbank gespeicherte Daten zugreift

Stored Procedure: benutzergeschriebene Anwendung, die durch SQL – Befehl CALL aufgerufen werden kann

5

DB2 in der S/390 Umgebung Komponenten des Database Services Address Space

6

DB2 in der S/390 Umgebung effiziente Zusammenarbeit mit anderen OS/390 Subsystemen und

Komponenten (OS/390 Security Server und Parallel Sysplex Umgebung)

Anwendungen, die auf DB2 Ressourcen zugreifen, können innerhalb des gleichen OS/390 Systems, CICS, IMS, TSO oder der Batch Umgebung laufen oder auch auf anderen Betriebssystemen

Zugriff auf DB2 – Ressourcen, durch Client/ Server -Dienste der Distributed Data Facility (DDF)

IBM bietet Anbindungsmöglichkeiten (attachment facilities), um DB2 mit all diesen Umgebungen zu verbinden

7

3. Von DB2 S/390 genutzte Attachment Facilities

eine attachment facility stellt Schnittstelle zwischen DB2 und anderen Umgebungen zur Verfügung

OS/390 beinhaltet Attachment Facilities für DB2 für:1. CICS : - dient Online Transaktions- Management

- unabhängiges Starten und Beenden von DB2 und CICS- im Fall eines System - Ausfalls koordiniert CICS Recovery von DB2 Daten und CICS Daten

2. IMS : - Datenbank – Berechnungssystem- erhält und interpretiert Anfragen für Zugriff auf DB2 Datenbanken- bei System - Ausfall koordiniert IMS Recovery von DB2 Daten und von IMS Daten

8

Von DB2 S/390 genutzte Attachment Facilities

3. TSO: - unterstütz interaktives Time - Sharing von Remote – Terminals- genutzt, um verschiedene Online Funktionen von DB2 auszuführen

4. CAF: - enthält alternative Verbindung zu TSO- Funktionen, um Verbindungsstatus zu DB2 zu kontrollieren

5. RRS: - koordiniert Prozessausführungen für widerherstellbare Ressourcen in OS/390 Systemen - benutzt, um auf Ressourcen, wie SQL Tabellen und widerherstellbare Virtual Storage Acces Method (VSAM) Dateien innerhalb einer Einzel - Transaktion, zuzugreifen

9

4. Distributed Data Facility

kurz DDF erlaubt Client - Anwendungen, die in einer Umgebung mit DRDA -

Unterstützung laufen, auf Daten von DB2 - Servern zuzugreifen ermöglicht DB2 Anwendungen auf Daten von anderen DB2 - Servern und

auf Daten, die sich in Remote Datenbanksystemen befinden, die DRDA unterstützen, zuzugreifen

gleichzeitig bis zu 150.000 verteilte Threads möglich, die mit einem einzelnen DB2 - Server verbunden sind

benutzt Methoden zum übertragen von Anfrage - Ergebnis - Mengen, die den Netzwerk - Verkehr minimieren, wenn auf verteilte Daten zugegriffen wird

Verwendung von Stored Procedures möglich, um Prozessorkosten für verteilte Zugriffe zu senken

Thread: DB2 Struktur, welche die Anwendungsverbindung beschreibt und deren Fortschritt verfolgt, und ihren Zugriff auf DB2 Ressourcen begrenzt

10

5. Vergleich der Systemstrukturen von DB2 S/390 und DB2 LUW

LUW Instanz bietet Umgebung für Erzeugung von DB – Objekten und

Ausführung von Anwendungen mehrere Instanzen auf einer Maschine möglich auf Windows – Plattformen ist es nur möglich eine DB2 Version mit

bestimmtem Fixpack - Level zu installieren alle Instanzen in DB2 UDB für Windows mit gleichem DB2 - Code verbunden

auf Unix - Plattformen mehrere DB2 Versionen auf der gleichen Maschine möglich, wenn diese in unterschiedlichen Pfaden liegen, jedoch ist nur ein Fixpack - Level pro Version erlaubt in DB2 UDB für Unix mehrere Instanzen möglich, die mit unterschiedlichem Code verbunden sind

S/390 Subsystem bietet DB2 Umgebung, ähnlich Instanz bei DB2 LUW mehrere DB2 S/390 Subsysteme in unterschiedlichen Versionen

können auf gleicher logischer Partition (LPAR) installiert sein ebenfalls möglich unterschiedliche DB2 Subsysteme mit gleicher

Version, aber unterschiedlichen Maintenance Leveln auf einer LPAR zu installieren

in beiden Fällen wird dann unterschiedlicher Code verwendet

Instanz vs. Subsystem

11

Vergleich der Systemstrukturen

LUW beim Start der DB2 – Engine mittels „db2start“ werden verschiedene

Dienste/ Prozesse gestartet S/390

beim DB2 – Start werden die SSAS, DSAS, IRLM und DDF Adress – Räume durch eine JCL proc gestartet

LUW es existieren Agents, die für Kommunikation zwischen Remote Clients

und DB2 Engine sorgen S/390

DDF muss gestartet sein, um Kommunikation zu ermöglichen

LUW keine Prozesse, für den Umgang mit Sperren, außer db2dlock für die

Deadlock – Erkennung S/390

IRLM für die Sperrenbehandlung

Dienste, Prozesse, Adress - Räume

12

Vergleich der Systemstrukturen LUW

durch setzten der DB2INSTANCE Variablen (set DB2INSTANCE = <instance_name>), oder durch nutzen eines vorher definierten Nodes (attach to <nodename>)

S/390 da mehrere DB2 Subsysteme installiert sein können, wird Befehlspräfix

benötigt, um es zu identifizieren z.B. Start eines DB2 S/390 V7 Subsystems das mit # assoziiert ist

Befehl : "#start DB2" von der MVS Konsole aus

LUW Name der Instanz Name der Datenbank beim Verbinden mit Datenbank außerdem TCPIP - Adresse und Port für

Instanz benötigt S/390

Subsystem ID (ssid) Location Name LU Name

Adressieren von Befehlen an bestimmte Instanzen oder Subsysteme

Namen von Instanzen und Subsystemen

13

Vergleich der Systemstrukturen

LUW Instanz kann aus mehreren Datenbanken bestehen jede DB ist eine eigenständige Einheit, mit eigenen Logs, Katalogen und

DB – Konfigurationsdateien S/390

Subsystem kann aus mehreren Datenbanken bestehen, die miteinander kommunizieren können

Katalog ist eine eigene DB

LUW man bindet sich an Instanz, um Verwaltungsoperationen auszuführen,

und man verbindet sich mit DB um DB - Operationen durchzuführen

S/390 man verbindet sich nur mit Subsystem und kann beides ausführen eine DB hat nicht einen Katalog für sich, es gibt nur einen für das

gesamte DB2 Subsystem

Verbinden mit Datenbank vs. Verbinden mit Subsystem

14

InstanzDatenbank MYDB1

Katalog

Tempspace1

Userspace1

DB Configfile_1

Logs

Katalog

Tempspace1

Userspace1

DB Configfile_2

Logs

Datenbank MYDB2

JOINJOIN

DB2 Subsystem

Katalog Datenbank DSNDB06

Directory Datenbank DSNDB01

Work File Datenbank DSNDB07

Default Datenbank DSNDB04

Datenbank MYDB1

TableSpace1

Datenbank MYDB2

TableSpace2

JOINJOIN

Logs BSDS

DB2 LUW System Struktur DB2 S/390 System Struktur (ohne Data Sharing)

DB2 Client DB2 Connect

DDF

DB2 LUW Client

15

6. Vergleich von DB2 LUW und DB2 S/390 Datenstrukturen

LUW DB ist unabhängige Einheit mit Tablespaces, Tabellen, Indizes

und System Informationen (Katalog, Logs, Konfigurationsdateien)

Objekte aus verschiedenen Datenbanken können nicht miteinander agieren

S/390 DB ebenfalls unabhängige Einheit mit Tablespaces, Tabellen

und Indizes, jedoch gehören System Informationen nicht dazu Katalog, Logs und Konfigurationsparameter werden auf DB2

Subsystem Ebene gesichert, nicht auf DB – Ebene Objekte von verschiedenen Datenbanken können miteinander

agieren

Das Datenbankkonzept in DB2 LUW und in DB2 S/390

16

Vergleich der Datenstrukturen LUW

Container, physisches Objekt zum Daten speichern (Directory, Raw Device, File), der mit Tablespace assoziiert wird

möglich, Container einzeln zu bestimmen, die mit einem bestimmten Tablespace assoziiert sind

Instanz

Katalog

Tempspace1

Userspace1

Logs

DB Config file_1

DMS Tablespace 1

Table A

Table B

Table C

DMS Tablespace 2

Index 1 auf Table A

Index 1 auf Table B

Index 2 auf Table A

DMS Tablespace 3

Index 1 auf Table C

SMS Tablespace 4

Table D Table E

Index 1 auf Table D

Index 1 auf Table E

Datenbank MYDB1

RAW Device Container

File Container RAW Device Container

Directory Container

DB2 LUW Container vs. DB2 S/390 Storage Group

17

Vergleich der Datenstrukturen S/390

Storage Group, ähnliches Ziel Daten speichern Storage Group besteht aus Anzahl physischer Devices (DASD

Volumes), von DB2 überwacht, ebenfalls mit Tablespace assoziiert nicht möglich Storage Groups, die mit bestimmtem Tablespace

assoziiert sind, einzeln zu bestimmen, da Storage Group normalerweise mehrere DASD Volumes enthält

DB2 Subsystem Katalog Datenbank DSNDB06 Directory Datenbank DSNDB01

Work File Datenbank DSNDB07 Default Datenbank DSNDB04

Datenbank MYDB1

Non – Partitioned Tablespace tbls1

Table A

Table B

Indexspace 1

Index A1 auf Table AIndexspace 2

Index A2 auf Table AIndexspace 3

Index B1 auf Table B

Partitioned Tablespace tbls2

Table C Part 1

Table C Part 2

Partitioned Indexspace C1

Index C1 Part 1

Index C1 Part 2

Volume 1 (DASD)

Storage Group G1

Volume 2 (DASD) Volume 1 (DASD)

Storage Group G2

Volume 2 (DASD)

18

Vergleich der Datenstrukturen

SMS TableSpace tblsA

Table A

Table B

Index 1 auf Table A

tableA.dat …

tableB.dat …

tableA.inx …

DB2 LUW Tablespace ist logisch, es gibt keine physische RepräsentationSMS Directory Container:

C:\temp

DB2 S/390 Tablespace ist physisch, zeigt auf einen oder mehrere physische Datensätze

TableSpace tblsB

Table A

Table B

Indexspace ixA

Index ixA auf Table A

Volume 1 (DASD)

Storage Group G1

innerer DatensatzDSN710.DSNDBD.MYDB1.TBLSB.I0001.A001

DSN710.DSNDBD.MYDB1.TBLSB.I0001.A001

Table A data… Table B Data…

DSN710.DSNDBD.MYDB1.IXA.I0001.A001

Tablespace - Konzept unter DB2 LUW und DB2 S/390

Tablespace KlassifikationSMS (system – managed) Tablespaces werden durch Dateisystem des Betriebsystems gesteuert.DMS (datebase – managed) Tablespaces werden durch DB – System gesteuert.

Tablespace Klassifikation nach interner Organisation, z.B. einfach, segmentiert, partioniert

19

7. Kontrolle des DatenzugriffsDB2 S/390 Konzept DB2 LUW AnalogiePrimary Authorization ID ID, um Verbindung mit Datenbank

herzustellen, oder sich an Instanz zu binden

Secondary Authorization ID -

CURRENT SQLID CURRENT SQLID oder CURRENT SCHEMA

SET CURRENT SQLID SET CURRENT SQLID SET CURRENT SCHEMA

Zugriff auf DB2 Subsystem kontrolliert durch RACF oder anderer Sicherheitssoftware

Zugriff auf DB2 kontrolliert durch Betriebssystem

Zugriff innerhalb DB2 kontrolliert durch DB2 mittels Autorisierungen und Rechte

Zugriff innerhalb DB2 kontrolliert durch DB2 mittels Autorisierungen und Rechte

SYSADM Installation höchste Autorisierung SYSADM höchste Autorisierung

Andere Autorisierungen: SYSADM (verschieden von SYSADM Inst.), SYSCTRL, DBADM, PACKADM, DBCTRL, DBMAINT, SYSOPR, SYSOPR Installation

Andere Autorisierungen: SYSCTRL, SYSMAINT, DBADM, LOAD

SYSADM – u. SYSOPR Installation können nicht mit GRANT oder REVOKE erteilt oder widerrufen werden. Alle anderen können.

SYSADM, SYSCTRL und SYSMAINT können nicht mit GRANT oder REVOKE erteilt oder widerrufen werden. Alle anderen können.

Vergleich der Sicherheit von DB2 LUW und DB2 S/390

20

8. ZusammenfassungDB2 S/390 Konzept DB2 LUW Analogie-Subsystem-mehrere installierte Versionen möglich mit oder ohne verschiedenen Maintenance Level-Lock – Manager IRLM

-Objekte verschiedener Datenbanken können miteinander agieren-Ausführung von Anfragen, die Tabellen aus 2 verschiedenen DBs betreffen, möglich-Client verbindet sich mit DB2 Subsystem, nicht mit bestimmter DB-DB enthält keine System Informationen-Storage Group-Tablespace Klassifikation nach interner Organisation

- Instanz- Windows: nur eine Version; Unix: mehrere Versionen (nur ein Fixpack – Level pro Version)- keine Prozesse für Lock – Behandlung, außer db2dlock -Objekte verschiedener Datenbanken können nicht miteinander agieren-Ausführung von Anfragen, die Tabellen aus 2 verschiedenen DBs betreffen, nicht möglich-Client verbindet sich mit bestimmter DB

-DB enthält System Informationen-Container-Tablespace Klassifikation nach Management