Natural for Db2 for zIIP (NDZ) ergänzt die Natural for Db2 (NDB) Datenbankmanagementschnittstelle um die Möglichkeit, Db2-Workloads auf IBM System z Integrated Information Processors (zIIP) auszuführen.
Natural for Db2 for zIIP (NDZ) nutzt die zIIP-Eigenschaften, indem es über ein Remote-DRDA-Protokoll auf Db2 zugreift, anstatt herkömmliche lokale Db2-Attachments zu verwenden. Lokale Aufrufe bei Db2 sind nicht zIIP-fähig, daher ermöglicht der Zugriff auf Db2 über das DRDA-Protokoll die kontinuierliche Ausführung von Natural-Programmen auf zIIP-Prozessoren.
Java-Workloads, die auf z/OS laufen, sind zIIP-fähig. Aus diesem Grund verwendet Natural for Db2 for zIIP (NDZ) Java und Java Database Connectivity (JDBC) für den Zugriff auf Db2 über das DRDA-Protokoll. Die folgenden Diagramme zeigen einen groben Vergleich der Arbeitslastverteilung beim Zugriff auf Db2 unter ausschließlicher Verwendung von Natural for Db2 (NDB) und bei gleichzeitiger Verwendung von NDB und NDZ.
Einige Workloads, z.B. Eingabe-/Ausgabe-Aufrufe, sind nicht zIIP-fähig. Bei nicht zIIP-fähigen Workloads müssen die entsprechenden Natural-Programme aushilfsweise auf den General Central Processors (GCP) ausgeführt werden.
Das Beispiel [3] für die Verarbeitung auf GP in der Abbildung unten stellt die Arbeitslast dar, die auf dem General Processor ausgeführt wird. Diese Arbeitslast umfasst 40 Prozent der nicht zIIP-fähigen Db2-Arbeitslast, einen Teil der Natural-Arbeitslast und einen Teil der NDZ-Arbeitslast, die nicht zIIP-fähig ist. Beispielsweise führt der NDZ-Server während des Starts, des Herunterfahrens und während der Ausführung der Operator-Änderungskommandos auf dem General Processor aus.
Um die Fähigkeiten von Natural for Db2 for zIIP (NDZ) nutzen zu können, müssen Sie sicherstellen, dass genügend System z Integrated Information Processors (zIIP) in der Zielumgebung verfügbar sind. Die Ausführung von NDZ-Workloads ohne die erforderliche zIIP-Kapazität kann zu einer erhöhten Auslastung des General Central Processor (GCP) führen, weil zIIP-fähige Workloads auf allgemeinen Prozessoren ausgeführt werden. Beachten Sie den Abschnitt Honor Priority im IBM-Handbuch z/OS MVS Planning: Workload Management.
Natural for Db2 for zIIP (NDZ) läuft in einem eigenen Adressraum. Eine Instanz des NDZ-Servers ist in der Lage, Anfragen von mehreren Natural-Batch-Jobs zu verarbeiten. Die folgende Abbildung vermittelt einen Überblick über die NDZ-Architektur:
Die folgende Abbildung veranschaulicht die Anfragen von
verschiedenen Clients, die Db2-Statements in einer NDZ-Instanz ausführen, die
im gestarteten Task NDZSTC läuft.
Da der NDZ mehrere gleichzeitige Client-Anfragen verwendet, nutzt er den Verbindungspool des IBM Data Server Driver for JDBC und SQLJ, um den Verarbeitungsaufwand zu verringern. Er verwendet die bestehenden Verbindungen wieder, um die Auswirkungen des Aufbaus und Schließens der Verbindung für jede Db2-Anfrage zu minimieren.
Der NDZ-Server besteht sowohl aus einem Nukleus als auch aus einer
Java Virtual Machine. Während der Initialisierung stellt NDZ über JDBC in einem
vertrauenswürdigen Kontext eine Verbindung zu Db2 her und erstellt sowohl
Java-Client-Tasks als auch einen Pool von Db2-Verbindungen, die später zur
Verarbeitung von SQL-Anfragen im Namen der Clients verwendet werden können. Ein
Natural Batch-Client kann eine NDZ-Serverinstanz über den
Schlüsselwort-Subparameter NDZSRV des
Natural-Profilparameters DB2 auswählen. Wenn
der Client eine Verbindung zur NDZ-Serverinstanz herstellt, wird ein neuer
Db2-Thread mit der gleichen Benutzerkennung wie der Job des Natural
Batch-Clients aus einer der im Pool enthaltenen Verbindungen erstellt.
Die Natural for Db2 for zIIP-Distribution besteht aus einer nativen Ladebibliothek, einer TAR-Datei und Jobs zur Installation und Konfiguration von NDZ-Komponenten. Die native Ladebibliothek besteht aus den folgenden Lademodulen:
NDZ-Nukleus-Lademodul
NDZJVM-Lademodul
Das NDZ-Installationsverzeichnis, das aus der verteilten TAR-Datei extrahiert wird, besteht aus den folgenden Unterverzeichnissen.
| classes | Enthält ausführbare jar-Dateien für NDZ. |
| bin | Enthält ausführbare Skripte für die Konfiguration und Ausführung von NDZ. |
| etc | Enthält die Dateien ndz.properties und db2.properties. Mit diesen Eigenschaftsdateien können Sie die Parameter für Db2 für z/OS und NDZ-Konfigurationen angeben. |
| lib | Enthält gemeinsam genutzte Bibliotheken (.so-Dateien) für NDZ. |
| static | Verzeichnis zum Speichern der statischen serialisierten Profilinformationen. |
Informationen zu den NDZ-Installationsjobs siehe Installing Natural for Db2 for zIIP in der Installation for z/OS -Dokumentation.
Der Natural Batch-Nukleus muss editiert und verlinkt werden, um die folgenden Aktionen durchzuführen:
Einbinden von NDBNDZ aus der
Natural-Batch-Bibliothek. Diese enthält die NDZ-eigene
DSNHLI-Schnittstelle, die in den Natural Batch-Nukleus aufgenommen
werden muss.
Einbinden des Db2-Schnittstellenmoduls DSNALI
oder DSNELI, je nach Umgebung, wobei der Einstiegspunkt
DSNHLI in DB2HLI umbenannt wird.
Ausführliche Informationen zum Build-Schritt siehe Installing Natural for Db2 for zIIP -Dokumentation.
Wenn NDB die TSO Db2-Schnittstelle
DSNELI
verwendet, wird mit dem DSN-Statement eine Verbindung zu Db2 hergestellt. Wenn
NDZSRV im Job angegeben ist, verwendet der NDZ-Server seine
eigenen Verbindungen aus dem Verbindungspool und die TSO-Verbindung wird nicht
verwendet. Wenn der Job ohne IKJEFT01 ausgeführt wird, wird die
TSO-Verbindung nicht erstellt, sondern der Failover-Mechanismus funktioniert
nicht, da keine explizite Verbindung ausgegeben wird. Es ist besser, CAF
DSNALI zu verwenden, um ungenutzte Verbindungen zu vermeiden und
auf NDB umzuschalten, falls der NDZ-Server nicht verfügbar ist.
Geben Sie den Schlüsselwort-Subparameter
NDZSRV des
Natural-Profilparameters DB2 als Teil der
DB2-Parameter an, um den NDZ-Server zur Ausführung der
Db2-Workloads auf einem zIIP-Prozessor zu verwenden. Stellen Sie sicher, dass
der angegebene NDZ-Server aktiv ist und läuft. Weitere Einzelheiten finden Sie
unter NDZSRV.
NAT7380: NDZ server ":1:" is not available. NAT7382: Natural SQL interface active without Natural for Db2 for zIIP.
Natural for Db2 for zIIP ergänzt Natural for Db2 und führt die auf
zIIP ausgeführten Db2-Workloads aus. Wenn der im Schlüsselwort-Subparameter
NDZSRV des
Natural-Profilparameters DB2 angegebene
NDZ-Server nicht verfügbar ist, wird die folgende Warnmeldung angezeigt und die
Db2-Anfrage wird über eine lokale Verbindung verarbeitet und in einem General
Processor ausgeführt.
Dieser Failsafe-Mechanismus hilft bei der Verarbeitung einer Db2-Anfrage, selbst wenn der NDZ-Server nicht verfügbar ist.
Für jeden mit den spezifischen Qualifikationselementen (Qualifiers) verbundenen Client wird eine WLM-Enklave erstellt. Nachfolgend sind die vom NDZ festgelegten WLM-Qualifikatoren aufgeführt.
| Qualifier | Von NDZ festgelegter Wert |
|---|---|
| Correlation | Client-Jobkennung |
| User ID | Client-Job-Benutzerkennung |
| Process name | Client-Job-Name |
| Transaction / Job name | Name der NDZ Started Task |
| Subsystem type | STC |
| Subsystem name | Name der NDZ Started Task |
Sie können eine WLM-Klassifizierungsregel erstellen, um NDZ STC und/oder Enklaven mithilfe dieser Qualifier in eine andere Service-/Reportklasse einzuordnen. Weitere Informationen finden Sie in der IBM-Dokumentation z/OS MVS Planning: Workload Management.
DDF-Workloads werden in bestimmten, festgelegten Enklaven ausgeführt. Diese Enklaven werden durch die WLM-Serviceklassendefinitionen gesteuert. NDZ erstellt einen Thread pro verbundenem Client. Während der Db2-Thread-Erstellung weist es die folgenden Thread-/Verbindungswerte zu.
| Qualifier | Von NDZ festgelegter Wert |
|---|---|
| Client transaction or Application name (CTN) | Client-Job-Name |
| Client user ID (CUI) | Client-Job-Benutzerkennung |
| Client Accounting Information (CAI) | Client-Job-Name |
| Correlation ID(CI) | Client-Job-Name |
Sie können eine WLM-Klassifizierungsregel erstellen, um NDZ STC und/oder Enklaven mithilfe dieser Qualifier in eine andere Service-/Reportklasse einzuordnen. Weitere Informationen finden Sie in der IBM-Dokumentation z/OS MVS Planning: Workload Management.
Jedes Mal, wenn die statischen Profile im NDZ-Statikverzeichnis
erstellt/aktualisiert werden, muss der NDZ-Cache für statische Profile neu
geladen werden, um die aktualisierten Profile auszuwählen. NDZ bietet eine
Option, um diese Änderungen automatisch zu ermitteln und den Cache für
statische Profile neu zu laden. Der Parameter
ndz.automaticProfileReload legt fest, ob der Cache für
statische Profile neu geladen werden soll, wenn Änderungen im angegebenen
Verzeichnis erfolgen.
Anmerkung
Die Einstellung Automatic profile reload
bedeutet, dass ein statisches Verzeichnis auf Änderungen überwacht wird und
viele Ressourcen verbraucht. Diese Option kann auf false gesetzt werden, um
diesen Ressourcenverbrauch zu vermeiden. In diesem Fall müssen Sie bei einer
Profiländerung die statischen Profile manuell mit dem Änderungskommando
R neu laden.
Ausführliche Informationen zur Vorbereitung der statischen Ausführung finden Sie unter Programme für die statische Ausführung vorbereiten.
NDZ verfügt über eine einzige Verbindung zu Db2 unter Verwendung
eines vertrauenswürdigen Kontexts und erstellt Verbindungen im Namen seiner
Clients. Sie müssen einen vertrauenswürdigen Kontext erstellen, der auf einer
Systemberechtigungskennung (ndzDb2user) und Verbindungsattributen
basiert.
Bei der Ausführung von Db2-Anfragen wird im Namen des Benutzers, der die Anfrage gestellt hat, eine Verbindung hergestellt, ohne dass der Benutzer am Db2-Server authentifiziert werden muss.
In einer Multi-Thread-Umgebung ist das Öffnen und Schließen jeder einzelnen Verbindung sehr aufwendig, weshalb das NDZ einen Verbindungspool verwendet. Der Hauptvorteil besteht darin, dass er die Wiederverwendbarkeit fördert und das Öffnen und Schließen der Verbindungen überflüssig macht.
Der NDZ erstellt einen Thread pro verbundenem Client. Wenn beispielsweise vier Natural-Batch-Jobs mit dem NDZ verbunden sind, gibt es vier gleichzeitige Db2-Verbindungen/Threads. Sobald der Client die Verbindung trennt und der Natural-Batch-Client-Job endet, werden die Threads beendet.
Der NDZ hält im Pool befindliche Verbindungen zur Wiederverwendung
durch Clients geöffnet. Sie erscheinen nicht in der Ausgabe des Kommandos
DIS THD(*) LOCATION(*) TYPE(ACTIVE) DETAIL, bis sie
einem Client zugewiesen werden. Wenn sich ein Natural Batch Job-Client mit dem
NDZ verbindet, wird ihm eine der Verbindungen zugewiesen und es wird ein
Db2-Thread erstellt.
Im Folgenden wird die Ausgabe des Kommandos -DISPLAY
THREAD beschrieben, wenn zwei Clients verbunden sind und ihre
Db2-Workloads über NDZ ausführen. Sie sind über einen vertrauenswürdigen
Kontext, der für den ndzDb2user NATJAVA erstellt wurde, mit Db2
verbunden. APPLICATION NAME identifiziert den Jobnamen und den
Plan, der als DISTSERV identifiziert wird, und dies ist für alle
Jobs gleich, die über NDZ ausgeführt werden, da NDZ eine Remote-Verbindung zu
Db2 herstellt. AUTHID gibt den Benutzer an, der den Job
eingereicht hat, und die SYSTEM AUTHID bezieht sich auf den
ndzDb2-user.
DSNV401I = DISPLAY THREAD REPORT FOLLOWS - DSNV402I = ACTIVE THREADS NAME ST A REQ ID AUTHID PLAN ASID TOKEN SERVER RA * 8024 db2jcc_appli JAYM DISTSERV 00EF 13262 V485-TRUSTED CONTEXT=CTXNDZ, SYSTEM AUTHID=NATJAVA, ROLE= * V437-WORKSTATION=DB2CALL USERID=JAYM APPLICATION NAME=NDZDS1K4 V442-CRTKN=NDZDS1K4 V445-GA144A3D.P510.DF9F35DB7498=13262 ACCESSING DATA FOR ::FFFF:10.20.74.61 SERVER RA * 8026 db2jcc_appli JAYM DISTSERV 00EF 13261 V485-TRUSTED CONTEXT=CTXNDZ, SYSTEM AUTHID=NATJAVA, ROLE= * V437-WORKSTATION=DB2CALL USERID=JAYM APPLICATION NAME=NDZDS1K3 V442-CRTKN=NDZDS1K3 V445-GA144A3D.P50F.DF9F35DB7368=13261 ACCESSING DATA FOR ::FFFF:10.20.74.61
Natural for Db2 for zIIP (NDZ) bietet einen Schutzmechanismus zur
sicheren Speicherung des Passworts von ndzDb2user.
Das Skript
<NDZ-Homeverzeichnis>/bin/ndz-db2-pass.sh ermöglicht
es dem Benutzer, das Passwort zu verschlüsseln. Während der Ausführung
entschlüsselt NDZ das Passwort auf der Grundlage der Schlüsseldatei und
verwendet es für Db2-Verbindungen. Dies ist der empfohlene Ansatz zum Speichern
des Passworts für den ndzDb2user.
Vergewissern Sie sich, dass Sie Execute-Zugriff auf das Skript ndz-db2-pass.sh und Write-Zugriff auf die NDZ-Bibliothek haben, da NDZ ein <NDZ home directory>/var-Verzeichnis erstellt, wenn Sie dieses Skript ausführen.
Weitere Einzelheiten finden Sie unter Db2-Passwortverschlüsselung.
Natural for Db2 for zIIP (NDZ) stellt eine Remote-Verbindung zu Db2 über eine Db2 Distributed Data Facility (DDF) her. Alle Remote-Client-Anwendungen, die über die verteilte Db2-Dateneinrichtung auf Db2 zugreifen, sind standardmäßig mit dem Plan DISTSERV verbunden. Daher ist es nicht möglich, Sicherheit über Planberechtigungen einzurichten.
Sie können Berechtigungen mit
GRANT/REVOKE auf Packages
und Collections verwalten.
Da das NDZ über DDF eine Verbindung zu Db2 herstellt, wird die
Erstellung von Abrechnungssätzen über die Db2-Subsystemparameter
ACCUMACC und ACCUMUID
verwaltet.
Der Parameter ACCUMUID gibt an, welcher
Qualifier des Threads zur Identifizierung eines eindeutigen Mandanten
herangezogen werden soll. Je nach seinem Wert können alle NDZ-Threads als
derselbe Mandant betrachtet werden. In diesem Fall wird nach der durch den
Parameter ACUMMACC festgelegten Anzahl von Transaktionen
ein neuer Abrechnungssatz erstellt, wenn er nicht auf NO gesetzt
ist.
Derzeit setzt der NDZ die folgenden Db2-Thread-/Verbindungswerte:
| Qualifier | Value |
|---|---|
| Application Name | Client-Jobname |
| User ID | Client-Job-Benutzerkennung |
| Client Accounting Information | Client-Jobname |
| Correlation Token | Client-Jobname |
Der Wert des Parameters ACCUMUID sollte
entsprechend eingestellt werden, um den Anwendungsnamen und optional die
Benutzerkennung zur eindeutigen Identifizierung von Clients zu
berücksichtigen.
Zum Beispiel 0 (Benutzerkennung, Anwendungsname und
Name der Workstation), 4 (Benutzerkennung und Anwendungsname) usw.
Weitere Einzelheiten zu den Parametern ACCUMUID und
ACUMMACC siehe Db2 Installation and Migration
Guide.
Natural for Db2 for zIIP (NDZ) unterstützt die statische Vorbereitung und Ausführung durch SQLJ und ist unabhängig von der statischen Generierung von NDB.
Ausführliche Informationen zur statischen Vorbereitung und Ausführung von Natural-Programmen mit NDZ finden Sie unter Programme zur statischen Ausführung vorbereiten.
