Systemverwaltung: Implementierung

Mit dem Authentifizierungstyp DATA_ENCRYPT_CMP können Clients von einem Vorgängerrelease, die keine Datenverschlüsselung unterstützen, eine Verbindung zu einem Server mit Hilfe der Authentifizierung SERVER_ENCRYPT an Stelle von DATA_ENCRYPT herstellen. Diese Authentifizierung funktioniert nicht, wenn Folgendes gilt:

In diesem Fall kann der Client keine Verbindung zum Server herstellen. Damit die Verbindung hergestellt werden kann, müssen Sie entweder für den Client einen Upgrade auf Version 8 ausführen, oder das Gateway darf höchstens die Version 8 FixPak 6 aufweisen.

Unterstützung von DIO (Direct I/O) und CIO (Concurrent I/O)

DIO (Direct I/O, direkte Ein-/Ausgabe) verbessert die Leistung des Hauptspeichers, da das Caching auf Dateisystemebene umgangen wird. Dieser Vorgang reduziert den CPU-Aufwand und stellt dem Datenbankexemplar mehr Hauptspeicher zur Verfügung.

CIO (Concurrent I/O, gleichzeitige Ein-/Ausgabe) schließt die Vorteile von DIO ein und entlastet darüber hinaus die serielle Verarbeitung von Schreibzugriffen.

DB2 Universal Database (UDB) unterstützt DIO und CIO unter AIX sowie DIO unter HP-UX, Linux, Windows und der Solaris-Betriebsumgebung.

Die Schlüsselwörter NO FILE SYSTEM CACHING und FILE SYSTEM CACHING sind Teil der SQL-Anweisungen CREATE und ALTER TABLESPACE, mit denen Sie angeben können, ob DIO oder CIO für die einzelnen Tabellenbereiche verwendet werden soll. Wenn NO FILE SYSTEM CACHING in Kraft tritt, versucht DB2 UDB wo immer es möglich ist, CIO zu verwenden. In Fällen, in denen CIO nicht unterstützt wird (z. B. wenn JFS verwendet wird), wird stattdessen DIO verwendet.

Weitere Informationen finden Sie im Artikel "Improve database performance on file system containers in IBM DB2 UDB Stinger using Concurrent I/O on AIX" unter der folgenden URL-Adresse:

Distributortechnologie und automatische Clientweiterleitung

Die folgenden Informationen sind Teil des Handbuchs Systemverwaltung: Implementierung, Anhang B ("Verwenden der automatischen Clientweiterleitung"):

Die automatische Clientweiterleitung in DB2 Universal Database für Linux, UNIX und Windows ermöglicht die Wiederherstellung von Clientanwendungen, nachdem die Verbindung zum Server unterbrochen wurde. Dazu wird die Datenbankverbindung vom Client zum Server automatisch wiederhergestellt, so dass die Anwendung mit einer minimalen Unterbrechung fortgesetzt werden kann.

Wenn das Herstellen einer Verbindung vom Client zum Server fehlschlägt, werden die Anforderungen des Clients für erneutes Herstellen der Verbindung an eine definierte Gruppe von Systemen verteilt. Dazu wird eine Verteilungs- oder Zuteilerroutine verwendet, wie z. B. WebSphere EdgeServer.

Sie können die Distributortechnologie in einer Umgebung verwenden, die der folgenden Umgebung ähnlich ist:

Client --> Distributor Technology --> (DB2 Connect-Server 1 oder DB2 Connect-Server 2) --> DB2 z/OS

Der Client wird unter Verwendung von DThostname katalogisiert, damit die Verteilungstechnologie zum Zugriff auf einen der DB2 Connect-Server verwendet wird. Die verarbeitende Distributortechnologie entscheidet darüber, ob GWYhostname1 oder GWYhostname2 verwendet wird. Nachdem die Entscheidung gefällt worden ist, verfügt der Client über eine direkte Socketverbindung zu einem dieser zwei DB2 Connect-Gateways. Sobald die Socketverbindung zum ausgewählten DB2 Connect-Server hergestellt worden ist, verfügen Sie über eine typische Konnektivität zwischen Client, DB2 Connect-Server und DB2 z/OS.

Gehen Sie z. B. davon aus, dass der Verteiler GWYhostname2 auswählt. Dadurch ergibt sich die folgende Umgebung:

Wenn ein Kommunikationsfehler aufgetreten ist, versucht der Verteiler nicht, die Verbindungen wiederherzustellen. Wenn Sie die Funktion zur automatischen Clientweiterleitung für eine Datenbank in einer solchen Umgebung aktivieren möchten, müssen Sie den alternativen Server für die zugeordnete Datenbank bzw. die zugeordneten Datenbanken auf dem DB2 Connect-Server (DB2 Connect-Server 1 oder DB2 Connect-Server 2) als Verteiler (DThostname) konfigurieren. Wenn der DB2 Connect-Server 1 aus irgendeinem Grund gesperrt wird, wird die automatische Clientweiterleitung ausgelöst, und es wird versucht, die Clientverbindung erneut herzustellen, wobei der Verteiler sowohl primärer und als auch alternativer Server ist. Mit dieser Option können Sie die Funktionalität des Verteilers mit der DB2-Funktion für automatische Clientweiterleitung kombinieren und verwalten. Wenn Sie den alternativen Server auf einen anderen Hostnamen setzen als den Hostnamen des Verteilers, wird den Clients die Funktion für automatische Clientweiterleitung weiterhin bereitgestellt. Die Clients stellen jedoch direkte Verbindungen zum definierten alternativen Server her und umgehen die Distributortechnologie, wodurch der Nutzen des Verteilers verloren geht.

Aspekte der automatischen Clientweiterleitung für die Katalogisierung auf einem DB2 Connect-Server

Die folgenden beiden Aspekte sind im Hinblick auf die Verbindung zu alternativen Servern mit DB2 Connect-Server zu beachten:

LSA-Unterstützung (Windows)

Anwendungen, die im LSA-Kontext (Local System Account) ausgeführt werden, werden auf allen Windows-Plattformen außer unter Windows ME unterstützt.

Unterstützung zweiteiliger Benutzer-IDs

Die Anweisung CONNECT und der Befehl ATTACH unterstützen zweiteilige Benutzer-IDs. Das Qualifikationsmerkmal der SAM-kompatiblen Benutzer-ID ist der NetBIOS-Name, der maximal 15 Zeichen lang ist. Diese Funktion wird unter Windows ME nicht unterstützt.

Zusätzliche Informationen für die Kerberos-Unterstützung

Aspekte unter Windows

Auf Grund der Art und Weise, wie Windows einige Fehler erkennt und protokolliert, führen die folgenden Bedingungen zu einem unerwarteten Fehler des Client-Sicherheits-Plug-ins (SQL30082N, rc=36):
- Abgelaufenes Konto
- Ungültiges Kennwort
- Abgelaufenes Kennwort
- Vom Administrator erzwungene Änderung des Kennworts
- Inaktiviertes Konto
Außerdem wird im DB2-Verwaltungsprotokoll oder in der Datei db2diag.log in allen Fällen eine Nachricht angezeigt, dass die Anmeldung fehlgeschlagen ist bzw. verweigert wurde.

Wenn der Kontoname einer Domäne auch lokal definiert wurde, schlagen Verbindungen fehl, in denen Domänenname und -kennwort explizit angeben sind, und die folgende Fehlernachricht wird angezeigt:
```
Die lokale Sicherheitsautorität (LSA) ist nicht erreichbar. 
```
Dieser Fehler tritt auf, da Windows zuerst den lokalen Benutzer erkennt. Der Fehler kann behoben werden, indem der Benutzer in der Verbindungszeichenfolge vollständig qualifiziert wird. Beispiel:
```
name@DOMAIN.IBM.COM
```

Windows-Konten dürfen in ihrem Namen nicht das Zeichen @ enthalten, da es vom DB2-Kerberos-Plug-in als Domänentrennzeichen interpretiert wird.

Wenn Sie auch mit einer anderen Plattform als Windows arbeiten, stellen Sie sicher, dass alle Konten des Windows-Domänenservers und des Windows-Clients so konfiguriert sind, dass die DES-Verschlüsselung verwendet werden kann. Wird das für den Start des DB2-Services verwendete Konto nicht so konfiguriert, dass die DES-Verschlüsselung verwendet werden kann, schlägt der DB2-Server beim Akzeptieren von Kerberos-Kontexten fehl. Speziell DB2 Universal Database schlägt mit einem unerwarteten Fehler des Server-Plug-ins fehl, und im Protokoll wird angegeben, dass die AcceptSecurityContext-API SEC_I_CONTINUE_NEEDED (0x00090312L) zurückgegeben hat.
Wenn Sie bestimmen wollen, ob Windows-Konten so konfiguriert sind, dass die DES-Verschlüsselung verwendet werden kann, prüfen Sie die Kontomerkmale für Active Directory. Wenn die Kontomerkmale geändert werden, ist möglicherweise ein Neustart erforderlich.

Wenn auf dem Client und auf dem Server Windows installiert ist, kann der DB2-Service über das Konto des lokalen Systems gestartet werden. Befinden sich der Client und der Server jedoch in unterschiedlichen Domänen, schlägt die Verbindung möglicherweise fehl, und es wird die Fehlernachricht angezeigt, dass der Name des Zielprincipals ungültig ist. Der Fehler kann vermieden werden, indem der Zielprincipalname auf dem Client mit Hilfe des vollständig qualifizierten Hostnamens des Servers und des vollständig qualifizierten Domänennamens explizit im folgenden Format katalogisiert wird:
```
host/<hostname_des_servers>@<domänenname_des_servers>
```
Beispiel:
```
host/myhost.domain.ibm.com@DOMAIN.IBM.COM
```
Andernfalls müssen Sie den DB2-Service über ein gültiges Domänenkonto starten.