View
213
Download
0
Category
Preview:
Citation preview
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
Recommended