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

2 Inhalt 1. Einleitung 2. DB2 in der OS/390 Umgebung 3. Von DB2 s/390 genutzte Attachment Facilities 4. Distributed Data Facility 5. Vergleich der Systemstrukturen von DB2 S/390 und DB2 LUW 6. Vergleich von DB2 LUW und DB2 S/390 Datenstrukturen 7. Kontrolle des Datenzugriffs 8. 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: benutzergeschrieben e 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 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 = ), oder durch nutzen eines vorher definierten Nodes (attach to ) 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 Instanz Datenbank MYDB1 Katalog Tempspace1 Userspace1 DB Configfile_1 Logs Katalog Tempspace1 Userspace1 DB Configfile_2 Logs Datenbank MYDB2 JOIN DB2 Subsystem Katalog Datenbank DSNDB06 Directory Datenbank DSNDB01 Work File Datenbank DSNDB07 Default Datenbank DSNDB04 Datenbank MYDB1 TableSpace1 Datenbank MYDB2 TableSpace2 JOIN LogsBSDS DB2 LUW System StrukturDB2 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 DTable E Index 1 auf Table D Index 1 auf Table E Datenbank MYDB1 RAW Device Container File ContainerRAW 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 DSNDB06Directory Datenbank DSNDB01 Work File Datenbank DSNDB07Default Datenbank DSNDB04 Datenbank MYDB1 Non – Partitioned Tablespace tbls1 Table A Table B Indexspace 1 Index A1 auf Table A Indexspace 2 Index A2 auf Table A Indexspace 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äsentation SMS 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 Datensatz 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 Klassifikation SMS (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 Datenzugriffs DB2 S/390 KonzeptDB2 LUW Analogie Primary Authorization IDID, um Verbindung mit Datenbank herzustellen, oder sich an Instanz zu binden Secondary Authorization ID- CURRENT SQLIDCURRENT SQLID oder CURRENT SCHEMA 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 SYSADM Installation höchste AutorisierungSYSADM 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. Zusammenfassung DB2 S/390 KonzeptDB2 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