1 / 20

DB2 für OS/390 und zSeries

DB2 für OS/390 und zSeries. Architektur von DB2 für S/390 und Unterschiede zu DB2 für LUW. Inhalt. 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

rangle
Download Presentation

DB2 für OS/390 und zSeries

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Inhalt • 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

  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 DB2 Subsystem: getrennte Instanz des Relationalen DBVS, welche Schaffung, Organisation und Modifikation einer Datenbank kontrolliert und auf in der Datenbank gespeicherte Daten zugreift • 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) • 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) • koordiniert Zusammenarbeit von DB2 mit anderen Subsystemen • für alle Logging – Aktivitäten verantwortlich • Intersystem Resource Lock Manager (IRLM) • verantwortlich für Lock – Management (Deadlock eingeschlossen) • Distributed Data Facility (DDF) • notwendig für verteilte DB – Funktionalität • Stored Procedure Address Spaces (SPAS) • bestimmt für die Ausführung von Stored Procedures und benutzerdefinierten Funktionen 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: • 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 • 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 • TSO: - unterstütz interaktives Time - Sharing von Remote – Terminals - genutzt, um verschiedene Online Funktionen von DB2 auszuführen • CAF: - enthält alternative Verbindung zu TSO - Funktionen, um Verbindungsstatus zu DB2 zu kontrollieren • 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 Instanz vs. Subsystem • 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

  11. Vergleich der Systemstrukturen Dienste, Prozesse, Adress - Räume • 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

  12. 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 • 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 Namen von Instanzen und Subsystemen

  13. 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

  14. DB2 LUW System Struktur DB2 S/390 System Struktur (ohne Data Sharing) DB2 Client DB2 LUW Client DB2 Connect Instanz DB2 Subsystem DDF Datenbank MYDB1 Katalog Datenbank DSNDB06 Katalog DB Configfile_1 Directory Datenbank DSNDB01 Tempspace1 Work File Datenbank DSNDB07 Logs Userspace1 Default Datenbank DSNDB04 Datenbank MYDB1 JOIN TableSpace1 Datenbank MYDB2 JOIN Katalog DB Configfile_2 Datenbank MYDB2 Tempspace1 TableSpace2 Logs Userspace1 Logs BSDS

  15. 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

  16. Vergleich der Datenstrukturen DB2 LUW Container vs. DB2 S/390 Storage Group • 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 Datenbank MYDB1 Katalog Userspace1 DB Config file_1 Tempspace1 Logs 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 Directory Container File Container RAW Device Container RAW Device Container

  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 Indexspace 1 Index A1 auf Table A Partitioned Tablespace tbls2 Table C Part 1 Table C Part 2 Partitioned Indexspace C1 Index C1 Part 1 Index C1 Part 2 Non – Partitioned Tablespace tbls1 Table A Table B Indexspace 2 Index A2 auf Table A Indexspace 3 Index B1 auf Table B Volume 1 (DASD) Volume 2 (DASD) Volume 1 (DASD) Volume 2 (DASD) Storage Group G2 Storage Group G1

  18. 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: C:\temp Tablespace Klassifikation SMS (system – managed) Tablespaces werden durch Dateisystem des Betriebsystems gesteuert. DMS (datebase – managed) Tablespaces werden durch DB – System gesteuert. tableA.dat … tableB.dat … tableA.inx … DB2 S/390 Tablespace ist physisch, zeigt auf einen oder mehrere physische Datensätze TableSpace tblsB Table A Table B Volume 1 (DASD) DSN710.DSNDBD.MYDB1.TBLSB.I0001.A001 innerer Datensatz DSN710.DSNDBD.MYDB1.IXA.I0001.A001 DSN710.DSNDBD.MYDB1.TBLSB.I0001.A001 Indexspace ixA Index ixA auf Table A Table A data… Table B Data… Storage Group G1 Tablespace Klassifikation nach interner Organisation, z.B. einfach, segmentiert, partioniert

  19. 7. Kontrolle des Datenzugriffs Vergleich der Sicherheit von DB2 LUW und DB2 S/390

  20. 8. Zusammenfassung

More Related