Übersicht

#### Search Results

Search

# Übersicht

- NDZ-Architektur

- Bestandteile der Installation

- Natural Batch-Aspekte

- Performance-Aspekte

- Db2-Aspekte

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.

#### Vergleich der Arbeitslastverteilung bei zIIP-Nutzung

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.

## NDZ-Architektur

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

## Bestandteile der Installation

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

## Natural Batch-Aspekte

- Erstellen (Build)

- Ausführen

- Failover-Mechanismus

### Erstellen (Build)

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.

### Ausführen

- Überlegungen zum TSO Db2 Interface (DSNELI)
- DB2=(NDZSRV=) Subparameter

#### Überlegungen zum TSO Db2 Interface (DSNELI)

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.

#### DB2=(NDZSRV=) Subparameter

Geben Sie den 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` .

### Failover-Mechanismus

#### Failover nach NDB wenn NDZSRV nicht verfügbar

    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 Subparameter `NDZSRV` 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.

## Performance-Aspekte

- Client-WLM-Enklaven unter gestartetem NDZ-Task

- Db2 DIST enclaves

- Automatisches Neuladen von Profilen - Automatic profile reload

### Client-WLM-Enklaven unter gestartetem NDZ-Task

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.

### Db2 DIST enclaves

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.

### Automatisches Neuladen von Profilen - Automatic profile reload

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.

## Db2-Aspekte

- Verbindung und vertrauenswürdiger Kontext

- Passwortverschlüsselung - Password encryption

- Db2-Sicherheitsaspekte

- Statische Vorbereitung und Ausführung

### Verbindung und vertrauenswürdiger Kontext

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.

#### Verbindungspool

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

### Passwortverschlüsselung - Password encryption

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

### Db2-Sicherheitsaspekte

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.

#### Abrechnung

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.

### Statische Vorbereitung und Ausführung

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.

### On this page

- NDZ-Architektur
- Bestandteile der Installation
- Natural Batch-Aspekte
- Performance-Aspekte
- Db2-Aspekte