DB2 für OS/390 und zSeries
Werbung
DB2 für OS/390 und zSeries Architektur von DB2 für S/390 und Unterschiede zu DB2 für LUW Inhalt 1. 2. 3. 4. 5. 6. 7. 8. Einleitung DB2 in der OS/390 Umgebung Von DB2 s/390 genutzte Attachment Facilities Distributed Data Facility Vergleich der Systemstrukturen von DB2 S/390 und DB2 LUW Vergleich von DB2 LUW und DB2 S/390 Datenstrukturen Kontrolle des Datenzugriffs Zusammenfassung 2 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 3 2. DB2 in der S/390 Umgebung operiert als formales Subsystem von OS/390 DB2 Subsystem: getrennte Instanz des Relationalen DBVS, welche Schaffung, Organisation und Modifikation einer Datenbank kontrolliert und auf in der Datenbank gespeicherte Daten zugreift 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 System Services Address Space (SSAS) 2. – – koordiniert Zusammenarbeit von DB2 mit anderen Subsystemen für alle Logging – Aktivitäten verantwortlich Intersystem Resource Lock Manager (IRLM) 3. – verantwortlich für Lock – Management (Deadlock eingeschlossen) Distributed Data Facility (DDF) 4. – notwendig für verteilte DB – Funktionalität Stored Procedure Address Spaces (SPAS) 5. – bestimmt für die Ausführung von Stored Procedures und benutzerdefinierten Funktionen Stored Procedure: benutzergeschrieben e Anwendung, die durch SQL – Befehl CALL aufgerufen werden kann 4 DB2 in der S/390 Umgebung Komponenten des Database Services Address Space 5 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 6 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 7 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 8 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 Thread: DB2 Struktur, welche die Anwendungsverbindung beschreibt und deren Fortschritt verfolgt, und ihren Zugriff auf DB2 Ressourcen begrenzt 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 9 5. Vergleich der Systemstrukturen von DB2 S/390 und DB2 LUW LUW Instanz vs. Subsystem 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 10 Vergleich der Systemstrukturen Dienste, Prozesse, Adress - Räume LUW S/390 DDF muss gestartet sein, um Kommunikation zu ermöglichen LUW es existieren Agents, die für Kommunikation zwischen Remote Clients und DB2 Engine sorgen S/390 beim DB2 – Start werden die SSAS, DSAS, IRLM und DDF Adress – Räume durch eine JCL proc gestartet LUW beim Start der DB2 – Engine mittels „db2start“ werden verschiedene Dienste/ Prozesse gestartet keine Prozesse, für den Umgang mit Sperren, außer db2dlock für die Deadlock – Erkennung S/390 IRLM für die Sperrenbehandlung 11 Vergleich der Systemstrukturen Adressieren von Befehlen an bestimmte Instanzen oder Subsysteme 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 Namen von Instanzen und Subsystemen 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 12 Vergleich der Systemstrukturen Verbinden mit Datenbank vs. Verbinden mit Subsystem 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 13 DB2 LUW System Struktur DB2 S/390 System Struktur (ohne Data Sharing) DB2 Client Instanz DB2 LUW Client DB2 Connect DB2 Subsystem DDF Datenbank MYDB1 Katalog Tempspace1 Userspace1 Katalog Datenbank DB Configfile_1 Directory Datenbank DSNDB01 Work File Datenbank DSNDB07 Logs Default Datenbank JOIN Tempspace1 Userspace1 DSNDB04 Datenbank MYDB1 TableSpace1 Datenbank MYDB2 Katalog DSNDB06 DB Configfile_2 JOIN Datenbank MYDB2 TableSpace2 Logs Logs BSDS 14 6. Vergleich von DB2 LUW und DB2 S/390 Datenstrukturen Das Datenbankkonzept in DB2 LUW und in DB2 S/390 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 15 Vergleich der Datenstrukturen LUW DB2 LUW Container vs. DB2 S/390 Storage Group 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 Datenbank MYDB1 DMS Tablespace 1 DMS Katalog Userspace1 Tempspace1 Logs Tablespace 2 Table A Index 1 auf Table A Table B Index 1 auf Table B Table C Index 2 auf Table A DMS DB Config file_1 Tablespace 3 SMS Tablespace 4 Table D Table E Index 1 auf Table D Index 1 auf Table C Index 1 auf Table E Directory Container RAW Device Container File Container RAW Device Container 16 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 Work File Datenbank DSNDB07 Datenbank MYDB1 Non – Partitioned Tablespace tbls1 Table A Table B Indexspace 1 Directory Datenbank DSNDB01 Default Datenbank Partitioned Tablespace tbls2 Index A1 auf Table A Indexspace 2 Index A2 auf Table A Indexspace 3 DSNDB04 Partitioned Indexspace C1 Table C Part 1 Index C1 Part 1 Table C Part 2 Index C1 Part 2 Index B1 auf Table B Volume 1 (DASD) Volume 2 (DASD) Storage Group G1 Volume 1 (DASD) Volume 2 (DASD) Storage Group G2 17 Vergleich der Datenstrukturen Tablespace - Konzept unter DB2 LUW und DB2 S/390 DB2 LUW Tablespace ist logisch, es gibt keine physische Repräsentation SMS TableSpace tblsA Table A Table B Index 1 auf Table A SMS Directory Container: tableA.dat … C:\temp tableB.dat … tableA.inx … Tablespace Klassifikation SMS (system – managed) Tablespaces werden durch Dateisystem des Betriebsystems gesteuert. DMS (datebase – managed) Tablespaces werden durch DB – System gesteuert. DB2 S/390 Tablespace ist physisch, zeigt auf einen oder mehrere physische Datensätze TableSpace tblsB Table A Volume 1 (DASD) DSN710.DSNDBD.MYDB1.TBLSB.I0001.A001 Table B innerer Datensatz Indexspace ixA Index ixA auf Table A DSN710.DSNDBD.MYDB1.IXA.I0001.A001 DSN710.DSNDBD.MYDB1.TBLSB.I0001.A001 Table A data… Table B Data… Storage Group G1 Tablespace Klassifikation nach interner Organisation, z.B. einfach, segmentiert, partioniert 18 7. Kontrolle des Datenzugriffs Vergleich der Sicherheit von DB2 LUW und DB2 S/390 DB2 S/390 Konzept DB2 LUW Analogie Primary 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. 19 8. Zusammenfassung DB2 S/390 Konzept DB2 LUW Analogie -Subsystem - Instanz -mehrere installierte Versionen möglich mit - Windows: nur eine Version; Unix: mehrere oder ohne verschiedenen Maintenance Versionen (nur ein Fixpack – Level pro Level Version) -Lock – Manager IRLM - keine Prozesse für Lock – Behandlung, außer db2dlock -Objekte verschiedener Datenbanken -Objekte verschiedener Datenbanken können nicht miteinander agieren können miteinander agieren -Ausführung von Anfragen, die Tabellen aus -Ausführung von Anfragen, die Tabellen aus 2 verschiedenen DBs betreffen, nicht 2 verschiedenen DBs betreffen, möglich möglich -Client verbindet sich mit DB2 Subsystem, -Client verbindet sich mit bestimmter DB nicht mit bestimmter DB -DB enthält keine System Informationen -Storage Group -Tablespace Klassifikation nach interner Organisation -DB enthält System Informationen -Container -Tablespace Klassifikation nach Management 20
