Die Funktion für die automatische Clientweiterleitung wiederholt die Verbindungsherstellung zu einer Datenbank standardmäßig bis zu 10 Minuten. Sie können das präzise Wiederholungsverhalten jedoch mit Hilfe von von einer der beiden folgenden Registrierdatenbankvariablen oder unter Verwendung beider Variablen konfigurieren:
|Wenn DB2_MAX_CLIENT_CONNRETRIES festgelegt ist, DB2_CONNRETRIES_INTERVAL jedoch nicht, nimmt DB2_CONNRETRIES_INTERVAL standardmäßig den Wert 30 an.
|Wenn DB2_CONNRETRIES_INTERVAL festgelegt ist, DB2_MAX_CLIENT_CONNRETRIES jedoch nicht, nimmt DB2_MAX_CLIENT_CONNRETRIES standardmäßig den Wert 10 an.
|Wenn weder DB2_MAX_CLIENT_CONNRETRIES noch DB2_CONNRETRIES_INTERVAL festgelegt ist, |gilt für die Funktion der automatischen Clientweiterleitung das zuvor beschriebene Standardverhalten.
|Anmerkung:
|Benutzer, die Konnektivität des Typs 4 mit dem DB2(R) Universal JDBC-Treiber verwenden, müssen die automatische Clientweiterleitung mit Hilfe der beiden folgenden Datenquellenmerkmale konfigurieren:
|Die Registrierdatenbankvariable DB2TIMEOUT wird nicht mehr unterstützt. Mit dieser Einstellung wurde das Zeitlimitintervall für Windows(R) 3.x- und Macintosh-Clients bei langen SQL-Abfragen gesteuert. Diese Funktion wurde standardmäßig inaktiviert.
| | |Beim Erstellen von Tabellenbereichsbehältern erstellt DB2 UDB nicht vorhandene Verzeichnisebenen.
|Wenn z. B. ein Behälter als /project/user_data/container1 angegeben wird und das Verzeichnis /project nicht vorhanden ist, erstellt DB2 UDB |die Verzeichnisse /project und /project/user_data.
|Ab DB2 UDB Version 8.2 FixPak 4 erstellt DB2 UDB Verzeichnisse mit der Zugriffsberechtigung 700. Dies bedeutet, dass nur der Eigner Lese-, Schreib- und Ausführungszugriff hat.
|Beispielszenario beim Erstellen mehrerer Exemplare:
|Da DB2 UDB die Verzeichnisebenen /project/user_data basierend auf der ersten Anforderung mit |der Zugriffsberechtigung 700 erstellt hat, hat 'user2' keinen Zugriff auf diese Verzeichnisebenen und kann container2 in diesen Verzeichnissen nicht erstellen. In diesem Fall schlägt die Operation CREATE TABLESPACE fehl.
|Es gibt zwei Methoden zur Lösung dieses Konflikts:
|Durch die Änderung des Formats der Behälternamen haben sich ebenfalls die Tabellenbereichs-ID und die Behälter-ID geändert. Das neue Format lautet wie folgt:
<speicherpfad>/<exemplar>/NODE#### /T####### /C#######.<EXT>
Dabei gilt Folgendes:
Ab DB2(R) Universal Database Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) können generierte Spalten in eindeutigen Indizes verwendet werden.
Generierte Spalten können in Integritätsbedingungen, referenziellen Integritätsbedingungen, Primärschlüsseln und globalen temporären Tabellen nicht verwendet werden. Eine Tabelle, die mit LIKE und gespeicherten Sichten erstellt wurde, übernimmt Merkmale generierter Spalten nicht.
Wenn Sie DB2WORKLOAD=SAP gesetzt haben, werden der Benutzertabellenbereich SYSTOOLSPACE und der temporäre Benutzertabellenbereich SYSTOOLSTEMPSPACE nicht automatisch erstellt. Diese Tabellenbereiche werden für Tabellen verwendet, die automatisch von den folgenden Assistenten, Dienstprogrammen oder Funktionen erstellt wurden:
Ohne die Tabellenbereiche SYSTOOLSPACE und SYSTOOLSTEMPSPACE können Sie diese Assistenten, Dienstprogramme und Funktionen nicht verwenden.
Damit Sie diese Assistenten, Dienstprogramme oder Funktionen verwenden können, müssen Sie eine der folgenden Aktionen ausführen:
CREATE REGULAR TABLESPACE SYSTOOLSPACE
IN IBMCATGROUP
MANAGED BY SYSTEM
USING ('SYSTOOLSPACE')Erstellen Sie nach der Ausführung mindestens einer dieser Aktionen einen temporären Benutzertabellenbereich (bei Verwendung von DPF ebenfalls nur auf dem Katalogknoten). Beispiel:
CREATE USER TEMPORARY TABLESPACE SYSTOOLSTMPSPACE
IN IBMCATGROUP
MANAGED BY SYSTEM
USING ('SYSTOOLSTMPSPACE')
Sobald der Tabellenbereich SYSTOOLSPACE und der temporäre Tabellenbereich SYSTOOLSTEMPSPACE erstellt wurden, können Sie die bereits erwähnten Assistenten, Dienstprogramme oder Funktionen verwenden.
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.
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:
http://www.ibm.com/developerworks/db2/library/techarticle/dm-0408lee/
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
Dabei gilt Folgendes:
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:
Client --> DB2 Connect-Server 2 --> DB2 z/OS
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.
Die automatische Clientweiterleitung fängt die folgenden SQL-Codes ab:
Die folgenden beiden Aspekte sind im Hinblick auf die Verbindung zu alternativen Servern mit DB2 Connect-Server zu beachten:
Anwendungen, die im LSA-Kontext (Local System Account) ausgeführt werden, werden auf allen Windows-Plattformen außer unter Windows ME unterstützt.
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.
Sie können den Namen des Kerberos-Serverprincipals überschreiben, der vom DB2(R) Universal Database-Server (UDB) unter den UNIX(R)- und Linux(TM)-Betriebssystemen verwendet wird. Setzen Sie die Umgebungsvariable DB2_KRB5_PRINCIPAL auf den gewünschten vollständig qualifizierten Namen des Serverprincipals. Das Exemplar muss erneut gestartet werden, da der Name des Serverprincipals nur von DB2 UDB erkannt wird, nachdem db2start ausgeführt wurde.
Die Voraussetzungen für die Kerberos-Unterstützung unter Linux sind in der Dokumentation nicht ausreichend beschrieben. Das bereitgestellte DB2-Kerberos-Sicherheits-Plug-in wird mit Red Hat Enterprise Linux Advanced Server 3 auf einem Client mit IBM Network Authentication Service (NAS) 1.4 unterstützt.
Für Verbindungen zu zSeries und iSeries muss die Datenbank mit dem Parameter AUTHENTICATION KERBEROS katalogisiert werden. Der Parametername TARGET PRINCIPAL muss explizit angegeben werden.
zSeries und iSeries unterstützen keine gegenseitige Authentifizierung.
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.
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
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.
host/<hostname_des_servers>@<domänenname_des_servers>Beispiel:
host/myhost.domain.ibm.com@DOMAIN.IBM.COMAndernfalls müssen Sie den DB2-Service über ein gültiges Domänenkonto starten.