Dokumentationsaktualisierungen

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:

/T####### ist die Tabellenbereichs-ID. Beispiel: T0000003.
/C####### ist die Behälter-ID. Beispiel: C0000012.

Definieren einer generierten Spalte in einer vorhandenen Tabelle

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.

Kumulative Registrierdatenbankvariablen

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:

Automatische Verwaltung
Designadvisor
Datenbankinformationsanzeige der Steuerzentrale
Gespeicherte Prozedur SYSINSTALLOBJECTS, falls der Eingabeparameter für den Tabellenbereich nicht angegeben ist
Gespeicherte Prozedur GET_DBSIZE_INFO

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:

Erstellen Sie SYSTOOLSPACE manuell (bei Verwendung von DPF nur auf dem Katalogknoten). Beispiel:

   CREATE REGULAR TABLESPACE SYSTOOLSPACE 
      IN IBMCATGROUP 
      MANAGED BY SYSTEM 
      USING ('SYSTOOLSPACE')

Erstellen Sie mit SYSINSTALLOBJECTS für jedes der folgenden Tools Objekte, und geben Sie dabei jeweils einen gültigen Tabellenbereich an: "DB2AC", "POLICY" und "STMG_DBSIZE_INFO"

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.

Authentifizierungsaspekte für ferne Clients

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:

Die Version des Clients ist Version 7.2.
Die Version des Gateways ist Version 8 FixPak 7 oder höher.
Der Server ist Version 8 FixPak 7 oder höher.

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:

http://www.ibm.com/developerworks/db2/library/techarticle/dm-0408lee/

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

Dabei gilt Folgendes:

Die Distributortechnologiekomponente hat den TCP/IP-Hostnamen DThostname.
Der DB2 Connect-Server 1 hat den TCP/IP-Hostnamen GWYhostname1.
Der DB2 Connect-Server 2 hat den TCP/IP-Hostnamen GWYhostname2.
Der DB2 z/OS-Server hat den TCP/IP-Hostnamen zOShostname.

Der Client wird unter Verwendung von DThostname katalogisiert, damit die Verteilungstechnologie zum Zugriff auf einen der DB2 Connect-Server ver- wendet 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:

SQLCODE-Wert -20157
SQLCODE-Wert -1768 (Ursachencode = 7)

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:

Der erste Aspekt betrifft die Verwendung des DB2 Connect-Servers für die Bereitstellung des Zugriffs auf eine Hostdatenbank oder eine iSeries-Datenbank für ferne und lokale Clients. In diesen Fällen kann es in Bezug auf Informationen zur Verbindung zu alternativen Servern in einem Eintrag des Systemdatenbankverzeichnisses zu Unklarheiten kommen. Katalogisieren Sie daher zur Vermeidung von Unklarheiten zwei Einträge im Systemdatenbankverzeichnis, um dieselbe Host- oder iSeries-Datenbank darzustellen. Katalogisieren Sie einen Eintrag für ferne Clients und einen weiteren für lokale Clients.
Des weiteren ist zu beachten, dass die Informationen zu alternativen Servern, die von einem Zielserver zurückgegeben werden, nur im Cache gespeichert werden. Nach Abschluss des DB2-Prozesses gehen die Informationen im Cache und damit die Informationen zu alternativen Servern verloren.

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.

Details zur Kerberos-Authentifizierung

Kerberos- und Clientprincipals

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.

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

Voraussetzungen für Linux

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.

zSeries- und iSeries-Kompatibilität

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.

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.

Systemverwaltung: Optimierung

| | |

Dienstprogramm Governor

Ein Governor-Exemplar besteht aus einem Front-End-Dienstprogramm und mindestens einem Dämon. |Jedes Governor-Exemplar, das Sie starten, ist genau einem Exemplar des Datenbankmanagers zugeordnet. Wenn Sie den Governor starten, wird auf jeder Partition einer partitionierten Datenbank standardmäßig ein Governor-Dämon gestartet. Sie können jedoch angeben, dass auf einer einzelnen zu überwachenden Partition ein Dämon gestartet werden soll.

| |

Anmerkungen:

Wenn der Governor aktiv ist, können sich dessen Momentaufnahmeanforderungen auf die Leistung des Datenbankmanagers auswirken. Erhöhen Sie zur Leistungssteigerung das Abfrageintervall des Governors, damit seine CPU-Belastung reduziert wird.

Governor-Dämonen setzen bei der Ausführung lokale Momentaufnahmen an das lokale Exemplar ab. |Daher werden alle Regeln, die setlimit-Klauseln enthalten, auf Ausgaben von lokalen Momentaufnahmen statt auf das zusammengefasste Ergebnis aus globalen Momentaufnahmen angewendet.

Jeder Governor-Dämon sammelt Daten zu den Anwendungen, die für die Datenbank ausgeführt werden. +Anschließend überprüft der Governor-Dämon diese Daten anhand von Regeln, die Sie in der Governor-Konfigurationsdatei für diese Datenbank angeben.

| | |

Auswählen einer Methode zur Tabellenreorganisation

Wenn Sie die Inplace-Tabellenreorganisation (statt der herkömmlichen Tabellenreorganisation) in Betracht ziehen, sollten Sie beachten, dass die Inplace-Tabellenreorganisation mehr Protokollspeicherbereich erfordert.

Da die Inplace-Tabellenreorganisation ihre Aktivitäten protokolliert, um nach einem unvorhergesehenen Ausfall eine Wiederherstellung ausführen zu können, wird für diesen Reorganisationstyp mehr Protokollspeicherbereich benötigt als für die herkömmliche Reorganisation.

Die Inplace-Tabellenreorganisation kann unter Umständen als Protokollspeicherbereich ein Vielfaches der Größe der reorganisierten Tabelle erfordern. Die Größe des erforderlichen Speicherbereichs hängt von der Anzahl der verschobenen Zeilen sowie von der Anzahl und Größe der Indizes für die Tabelle ab.

Empfehlung: Wählen Sie die Inplace-Tabellenreorganisation für Operationen aus, die mit minimalen Wartungszeiten rund um die Uhr ausgeführt werden.

Während einer Onlinetabellenreorganisation einer DMS-Tabelle können Sie eine Onlinesicherung für einen Tabellenbereich aufrufen, in dem sich die Tabelle befindet. Während der Abschneidephase können für die Reorganisationsoperation Wartestatus für Sperren (Lock Waits) auftreten.

Detaillierte Informationen zur Ausführung dieser Tabellenreorganisationsmethoden finden Sie in den Beschreibungen zur Syntax von REORG TABLE.

| | |

Unterstützung großer Seiten für FCM-Speicher (AIX 5L, 64 Bit)

Unter AIX^(R) 5L, 64 Bit, unterstützt die Registrierdatenbankvariable DB2_LARGE_PAGE_MEM nun das Schlüsselwort FCM.

Unter AIX 5L^(TM), 64 Bit, befindet sich FCM-Speicher standardmäßig in der DBMS-Speichergruppe. Wenn jedoch die Registrierdatenbankvariable DB2_FORCE_FCM_BP aktiviert ist, befindet sich der FCM-Speicher in seiner eigenen Speichergruppe. Unter AIX 5L, 64 Bit, unterstützt die Registrierdatenbankvariable DB2_LARGE_PAGE_MEM die Angabe der DBMS-Speichergruppe. Wenn sich FCM-Speicher in der DBMS-Speichergruppe befindet und die Unterstützung großer Seiten für diese Speichergruppe aktiviert ist, verfügt der FCM-Speicher über größere Seiten. Wenn FCM-Speicher sich in einer eigenen Speichergruppe befindet, muss dem Wert der Registrierdatenbankvariablen DB2_LARGE_PAGE_MEM das Schlüsselwort FCM hinzugefügt werden, damit große Seiten für FCM-Speicher unterstützt werden.

Registrierdatenbankvariable DB2_RESOURCE_POLICY akzeptiert ein neues Element

Ab DB2 Universal Database^(TM) (UDB) Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) akzeptiert die Konfigurationsdatei, die von der Registrierdatenbankvariablen DB2_RESOURCE_POLICY angegeben wird, ein SCHEDULING_POLICY-Element. Das SCHEDULING_POLICY-Element kann einigen Plattformen zur Auswahl folgender Elemente verwendet werden:

Planungsrichtlinie des Betriebssystems, die vom DB2 UDB-Server verwendet wird
Anmerkung:

Die Funktionalität zum Festlegen einer Planungsrichtlinie für das Betriebssystems gilt auch für DB2 für AIX ^(R). Früher war sie nur für DB2 UDB für Windows^(R) unter Verwendung der Registrierdatenbankvariablen DB2NTPRICLASS verfügbar.
Betriebssystemprioritäten, die von einzelnen DB2-Serveragenten verwendet werden

Die Registrierdatenbankvariablen DB2PRIORITIES und DB2NTPRICLASS können einzeln zum Steuern der Planungsrichtlinie des Betriebssystems und zum Festlegen von DB2-Agentenprioritäten verwendet werden.

Durch die Angabe eines SCHEDULING_POLICY-Elements in der Konfigurationsdatei für die Ressourcenrichtlinie können Sie die Planungsrichtlinie und die zugehörigen Agentenprioritäten an einer Stelle festlegen.

Beispiel 1

Auswahl der AIX-Planungsrichtlinie SCHED_FIFO2 mit gleichzeitiger Zuordnung einer höheren Priorität für die Prozesse der DB2-Ein- und -Ausgabeprogramme für Protokolle:

<RESOURCE_POLICY>
   <SCHEDULING_POLICY>
      <POLICY_TYPE>SCHED_FIFO2</POLICY_TYPE>
      <PRIORITY_VALUE>60</PRIORITY_VALUE>

      <EDU_PRIORITY>
         <EDU_NAME>db2loggr</EDU_NAME>
         <PRIORITY_VALUE>56</PRIORITY_VALUE>
      </EDU_PRIORITY>

      <EDU_PRIORITY>
         <EDU_NAME>db2loggw</EDU_NAME>
         <PRIORITY_VALUE>56</PRIORITY_VALUE>
      </EDU_PRIORITY>
   </SCHEDULING_POLICY>
</RESOURCE_POLICY>

Beispiel 2

Ersatz für DB2NTPRICLASS=H unter Windows.

<RESOURCE_POLICY>
   <SCHEDULING_POLICY>
      <POLICY_TYPE>HIGH_PRIORITY_CLASS</POLICY_TYPE>
   </SCHEDULING_POLICY>
</RESOURCE_POLICY>

Neue Systemumgebungsvariablen (Linux)

In FixPak 8 wurden die Systemumgebungsvariablen DB2_MAPPED_BASE und DB2DBMSADDR hinzugefügt.

Nur fortgeschrittene Benutzer sollten diese Registrierdatenbankvariablen verwenden.

DB2_MAPPED_BASE

Variablenname

DB2_MAPPED_BASE

Werte

0 oder (hexadezimale) virtuelle Adresse im 31-Bit- und 32-Bit-Adressbereich oder NULL (nicht gesetzt)

Betriebssysteme

Linux auf x86 und Linux auf zSeries (31 Bit)

Beschreibung

Mit der Registrierdatenbankvariablen DB2_MAPPED_BASE können Sie den verfügbaren zusammenhängenden virtuellen Adressraum für einen Prozess von DB2 Universal Database (UDB) erhöhen, indem Sie die Anschlussadresse der gemeinsam genutzten Bibliotheken für den jeweiligen Prozess verlagern. Der zusammenhängende virtuelle Adressraum ist wichtig, um die Größe des für die gemeinsame Datenbanknutzung verfügbaren Speichers für DB2 UDB zu maximieren. Diese Variable tritt nur bei Verteilungen in Kraft, für die sich im Dateisystem proc die Datei mapped_base im Verzeichnis für die Prozessidentifikation befindet.

Wenn diese Variable nicht gesetzt ist, versucht DB2 UDB, die gemeinsam genutzten Bibliotheken an die virtuelle Adresse 0x10000000 zu verlagern.

Die Registrierdatenbankvariable kann auch auf eine beliebige virtuelle Adresse (hexadezimal) im Bereich des 31- und 32-Bit-Adressraums gesetzt werden.

Anmerkung:

Eine falsche Adresse kann schwer wiegende Probleme bei DB2 UDB verursachen, die vom Fehlschlagen des Starts von DB2 UDB bis zum Fehlschlagen der Verbindung zur Datenbank reichen können. Eine falsche Adresse ist eine Adresse, die einen Konflikt mit einem Adressbereich verursacht, der bereits verwendet wird oder der für andere Daten oder Programme reserviert ist. Dieses Problem können Sie beheben, indem Sie die Variable DB2_MAPPED_BASE mit dem folgenden Befehl auf NULL setzen:

db2set DB2_MAPPED_BASE=

Die folgende Nachricht kann mehrmals in der Datei db2diag.log vorkommen, da diese Änderung für jeden logischen Knoten einmal erforderlich ist:

ADM0506I  DB2 hat den Kernelparameter "mapped_base" 
automatisch von "0x40000000(hex) 1073741824(dec)" auf 
den empfohlenen Wert "0x10000000(hex) 268435456(dec)" aktualisiert.

Diese Nachricht wird nur angezeigt, wenn das Setzen der Registrierdatenbankvariablen erfolgreich war, und sie enthält die Adresse, an die die gemeinsam genutzten Bibliotheken verlagert werden.

DB2DBMSADDR

Variablenname

DB2DBMSADDR

Werte

Virtuelle Adressen im Bereich 0x09000000 bis 0xB0000000 in Inkrementen von 0x10000

Betriebssysteme

Linux auf x86 und Linux auf zSeries (31 Bit)

Beschreibung

Gibt die Standardadresse des gemeinsam benutzten Datenbankspeichers im Hexadezimalformat an.

Anmerkung:

Eine falsche Adresse kann schwer wiegende Probleme bei DB2 UDB verursachen, die vom Fehlschlagen des Starts von DB2 UDB bis zum Fehlschlagen der Verbindung zur Datenbank reichen können. Ein Beispiel für eine falsche Adresse ist eine Adresse, die einen Konflikt mit einem Speicherbereich verursacht, der bereits verwendet wird oder der für andere Daten oder Programme reserviert ist. Dieses Problem können Sie beheben, indem Sie die Variable DB2DBMSADDR mit dem folgenden Befehl auf NULL setzen:

db2set DB2DBMSADDR=

Diese Variable können Sie in Verbindung mit DB2_MAPPED_BASE oder alleine setzen, um die Adressraumbelegung von DB2 UDB-Prozessen zu optimieren. Diese Variable ändert die Position des gemeinsam genutzten Speichers für das Exemplar von der aktuellen Position bei der virtuellen Adresse 0x20000000 in den neu angegebenen Wert.

Neue Kommunikationsvariable der Registrierdatenbank

In Version 8.2 wurde die Registrierdatenbankvariable DB2TCP_CLIENT_RCVTIMEOUT hinzugefügt.

Tabelle 12. Kommunikationsvariablen
Variablenname	Betriebssysteme	Werte
Beschreibung
DB2TCP_CLIENT_RCVTIMEOUT	Alle	Standard=0 (nicht definiert) Werte: 0 bis 32767 Sekunden
Gibt den Zeitraum (in Sekunden) an, den ein Client beim Empfang über TCP/IP auf Daten wartet. Wenn für die Registrierdatenbankvariable kein Wert festgelegt oder 0 angegeben wurde, ist kein Zeitlimit vorhanden. Wenn beim Empfang über TCP/IP vor Ablauf des Zeitlimits Daten zurückgegeben werden, wird die Anwendung wie üblich weiter ausgeführt. Läuft das Zeitlimit ab, bevor Daten zurückgegeben wurden, wird die Verbindung abgebrochen. Anmerkung: Diese Registrierdatenbankvariable gilt nur für den DB2-Client und die Clientseite des DB2-Gateways. Sie gilt nicht für den DB2-Server.

Neue Leistungsvariable

In Version 8.2 wurde die Leistungsvariable DB2_LARGE_PAGE_MEM hinzugefügt.

Tabelle 13. Leistungsvariablen
Variablenname	Betriebssysteme	Werte
Beschreibung
DB2_LARGE_PAGE_MEM	Nur AIX 5.x (64 Bit) Linux	Standardwert=NULL Geben Sie mit Hilfe eines Sterns (*) an, dass alle gültigen Speicherbereiche große Seitenspeicher verwenden sollen, oder geben Sie eine durch Kommas getrennte Liste spezifischer Speicherbereiche an, die den großen Seitenspeicher verwenden sollen. Die verfügbaren Bereiche variieren je nach dem verwendeten Betriebssystem. Unter AIX 5.x (64 Bit) können die folgenden Bereiche angegeben werden: DB, DBMS oder PRIVATE. Unter Linux kann der folgende Bereich angegeben werden: DB.
Der große Seitenspeicher wird lediglich für DB2 Universal Database (UDB) für AIX 5L (64-Bit-Edition) und DB2 UDB für Linux unterstützt. Die Registrierdatenbankvariable DB2_LARGE_PAGE_MEM wird verwendet, um unter AIX 5.x oder für eine beliebige Linux-Architektur mit der entsprechenden Kernelunterstützung die Unterstützung für große Seiten zu aktivieren. Sie ersetzt die Registrierdatenbank- variable DB2_LGPAGE_BP, die lediglich zur Aktivierung des großen Seitenspeichers für den gemeinsam genutzten Datenbankspeicherbereich verwendet wird. Dieser kann jetzt durch die Angabe von DB2_LARGE_PAGE_MEM=DB aktiviert werden. In einigen Doku- mentationen wird erläutert, dass große Seiten mit der Registrierdatenbankvariablen DB2_LGPAGE_BP ermöglicht werden. Dies entspricht der Einstellung DB2_LARGE_PAGE_MEM=DB. Die Verwendung großer Seiten dient hauptsächlich zur Leistungsverbesserung hochleistungsfähiger Datenverarbeitungsanwendungen. Bei Anwendungen, die einen intensiven Speicherzugriff erfordern und große Mengen an virtuellem Speicher verwenden, kann die Verwendung großer Seiten zu einer Leistungsverbesserung führen. Um DB2 UDB für die Verwendung großer Seiten zu aktivieren, müssen Sie zunächst das Betriebssystem für die Verwendung solcher Seiten konfigurieren. Durch die Aktivierung großer privater Seiten nimmt die DB2 UDB-Speicherbelegung deutlich zu, da jeder DB2 UDB-Agent mindestens eine große Seite (16 MB) an physischem Speicher belegt. Zum Aktivieren großer Seiten für privaten Agentenspeicher auf 64-Bit-DB2 UDB für AIX (Einstellung DB2_LARGE_PAGE_MEM=PRIVATE) müssen große Seiten auf dem Betriebssystem konfiguriert sein. Außerdem müssen die folgenden Voraussetzungen gegeben sein: Der Exemplareigner muss die Funktionen CAP_BYPASS_RAC_VMM und CAP_PROPOGATE aufweisen. Der Kernel muss Schnittstellen unterstützen, mit denen ein Prozess die zugehörige Seitengröße während der Ausführung modifizieren kann. Unter DB2 UDB für AIX (64 Bit) reduziert diese Variable die Größe des gemeinsamen Speichersegments, das den Datenbankspeicher unterstützt, auf den Mindestbedarf. Standardmäßig wird ein 64-GB-Segment erstellt. Weitere Informationen hierzu finden Sie unter dem Konfigurationsparameter für die Größe des gemeinsamen Datenbankspeichers. Dadurch wird vermieden, dass mehr gemeinsam genutzter Speicher im Arbeitsspeicher belassen wird als voraussichtlich verwendet wird. Die Aktivierung dieser Variablen schränkt die Möglichkeit ein, die Konfiguration für den gesamten gemeinsamen Daten- bankspeicher dynamisch zu erhöhen (z. B. Vergrößerung der Pufferpools). Unter Linux muss als zusätzliche Voraussetzung die Bibliothek libcap.so verfügbar sein. Diese Bibliothek muss installiert sein, damit diese Option funktioniert. Wenn die Option aktiviert wird und die Bibliothek nicht im System vorhanden ist, inaktiviert DB2 UDB die großen Kernelseiten und setzt die Verarbeitung wie zuvor fort. Um unter Linux zu prüfen, ob große Kernelseiten verfügbar sind, können Sie den folgenden Befehl absetzen: cat /proc/meminfo Wenn sie verfügbar sind, sollten die drei folgenden Zeilen angezeigt werden (mit anderen Werten, je nach Größe des auf Ihrer Maschine konfigurierten Speichers): HugePages_Total: 200 HugePages_Free: 200 Hugepagesize: 16384 KB Wenn diese Zeilen nicht angezeigt werden oder HugePages_Total den Wert 0 hat, ist eine Konfiguration des Betriebssystems oder des Kernels erforderlich.

Variablen des SQL-Compilers

Die folgende Aktualisierung gilt für das Thema "Variablen des SQL-Compilers" im Anhang A "Registrierdatenbank- und Umgebungsvariablen von DB2" des Handbuchs Systemverwaltung: Optimierung:

Wenn mindestens eine der beiden DB2-Compilervariablen DB2_MINIMIZE_LISTPREFETCH und DB2_INLIST_TO_NLJN auf ON gesetzt ist, bleibt sie selbst dann aktiv, wenn REOPT(ONCE) angegeben ist.

Aktualisierung von Konfigurationsparametern

Im Folgenden finden Sie die Aktualisierungen der Dokumentation zu den Konfigurationsparametern:

authentication - Authentifizierungstyp

Der Konfigurationsparameter für den Authentifizierungstyp (authentication) des Datenbankmanagers akzeptiert außerdem die folgenden Werte:

DATA_ENCRYPT
Der Server akzeptiert verschlüsselte SERVER-Authentifizierungsschemata und die Verschlüsselung von Benutzerdaten. Die Authentifizierung funktioniert genau wie für SERVER_ENCRYPT.

Die folgenden Benutzerdaten werden bei Verwendung dieses Authentifizierungstyps verschlüsselt:
- SQL-Anweisungen
- Daten von SQL-Programmvariablen
- Ausgabedaten aus der Serververarbeitung einer SQL-Anweisung, einschließlich einer Beschreibung der Daten
- Einige oder alle Antwortgruppendaten, die aus einer Abfrage resultieren
- LOB-Datenströme (große Objekte)
- SQLDA-Deskriptoren
DATA_ENCRYPT_CMP
Der Server akzeptiert verschlüsselte SERVER-Authentifizierungsschemata und die Verschlüsselung von Benutzerdaten. Darüber hinaus bietet dieser Authentifizierungstyp Kompatibilität mit Produkten früherer Versionen, die den Authentifizierungstyp DATA_ENCRYPT nicht unterstützen. Diese Produkte erhalten die Möglichkeit, die Verbindung mit dem Authentifizierungstyp SERVER_ENCRYPT und ohne Verschlüsselung von Benutzerdaten herzustellen. Produkte, die den neuen Authentifizierungstyp unterstützen, müssen ihn verwenden. Dieser Authentifizierungstyp ist nur in der Konfigurationsdatei des Datenbankmanagers des Servers, jedoch nicht im Befehl CATALOG DATABASE gültig.

util_impact_lim - Auslastungswirkung durch gedrosselte Dienstprogramme

Ab DB2 Universal Database Version 8.2 wird der Standardwert des Konfigurationsparameters Auslastungswirkung durch gedrosselte Dienstprogramme (util_impact_lim) für den Datenbankmanager von 100 in 10 geändert.

sysadm_group, sysmaint_group, sysctrl_group, sysmon_group

Die folgenden Konfigurationsparameter für den Datenbankmanager akzeptieren auf allen Plattformen bis zu 30 Byte lange Gruppennamen:

Berechtigungsgruppenname für Systemverwaltung (sysadm_group)
Berechtigungsgruppenname für Systemwartung (sysmaint_group)
Berechtigungsgruppenname für Systemsteuerung (sysctrl_group)
Berechtigungsgruppenname für Systemmonitor (sysmon_group)

Die Tabelle unter der Übersicht über die Konfigurationsparameter des Datenbankmanagers (Handbuch Systemverwaltung: Optimierung) enthält falsche Datentypen zu diesen Konfigurationsparametern für den Datenbankmanager. Der richtige Wert muss in allen Fällen char(30) lauten.

estore_seg_sz - Segmentgröße für erweiterten Speicher

Die Maximalgröße für den Datenbankkonfigurationsparameter Segmentgröße für erweiterten Speicher (estore_seg_size) auf Windows-Plattforman lautet 16.777.216.

hadr_timeout - HADR-Zeitlimitwert

Die richtige Obergrenze für den Datenbankkonfigurationsparameter HADR-Zeitlimitwert (hadr_timeout) lautet 4.294.967.295.

locklist - Maximaler Speicher für Sperrenliste

In der Dokumentation zum Datenbankkonfigurationsparameter Max. Speicher für Sperrenliste (locklist) steht, dass der Maximalwert für Windows-64-Bit- und 32-Bit-Server, die nur Server für lokale Clients sind, 60.000 beträgt. Dieser Wert ist falsch. Er muss 524.288 lauten.

num_db_backups - Anzahl der Datenbanksicherungen

Der Wertebereich für den Datenbankkonfigurationsparameter Anzahl der Datenbanksicherungen (num_db_backups) ist falsch. Der richtige Bereich ist 0 - 32.767.

Datei SQLDBCONF für Datenbankkonfigurationsparameter

Nach der Migration von Version 8.1 auf DB2 Universal Database (UDB) Version 8.2 verwendet DB2 UDB eine neue 16 KB große Datei für Datenbankkonfigurationsparameter mit dem Namen SQLDBCONF. (In Version 8.1 war die Datei für Datenbankkonfigurationsparameter nur 4 KB groß und hieß SQLDBCON.)

Änderung des Standardwerts für DB2_HASH_JOIN

Ab Version 8.1 ist die Registrierdatenbankvariable DB2_HASH_JOIN standardmäßig auf ON gesetzt.

Die Hashverknüpfungsvariable DB2_HASH_JOIN sollte verwendet werden, muss jedoch optimiert werden, um die maximale Leistung zu erzielen.

Die Leistung der Hashverknüpfung ist am besten, wenn Sie Hashschleifen und Überläufe auf den Plattenspeicher vermeiden können. Zur Optimierung der Leistung von Hashverknüpfungen schätzen Sie die maximale Speichergröße ab, die für den Parameter sheapthres verfügbar ist, und optimieren anschließend den Parameter sortheap. Erhöhen Sie den Wert dieses Parameters, bis Sie möglichst viele Hashschleifen und Überläufe auf den Plattenspeicher vermeiden, jedoch nicht den durch den Parameter sheapthres definierten Grenzwert erreichen.

Weitere Informationen finden Sie im Thema "Verknüpfungsmethoden" im Handbuch Systemverwaltung: Optimierung.

Registrierdatenbankvariable DB2NTNOCACHE wird ersetzt

Die zuvor durch die Variable DB2NTNOCACHE erreichte Funktionalität kann auf Tabellenbereichsebene erreicht werden, indem in der Anweisung CREATE TABLESPACE oder ALTER TABLESPACE die Klausel NO FILE SYSTEM CACHING angegeben wird. Weitere Informationen hierzu finden Sie im Handbuch SQL Reference. Die Registrierdatenbankvariable DB2NTNOCACHE wird in einem zukünftigen Release entfernt.

EXPLAIN-Tabellen und Organisieren von EXPLAIN-Informationen

EXPLAIN-Tabellen können für mehrere Benutzer gemeinsame Daten enthalten. Die EXPLAIN-Tabellen können jedoch auch für nur einen Benutzer definiert werden. Außerdem können Aliasnamen für jeden weiteren Benutzer definiert werden, der denselben Namen verwendet, um auf die definierten Tabellen zu verweisen. Die EXPLAIN-Tabellen können auch unter dem Schema SYSTOOLS definiert werden. Die EXPLAIN-Funktion verwendet standardmäßig das Schema SYSTOOLS, wenn keine anderen EXPLAIN-Tabellen oder -Aliasnamen unter der Sitzungs-ID des Benutzers für dynamisches SQL oder unter der Berechtigungs-ID der Anweisung für statisches SQL gefunden werden. Jeder Benutzer, der auf die gemeinsamen EXPLAIN-Tabellen zugreift, muss das Zugriffsrecht INSERT zum Einfügen für diese Tabellen aufweisen. Der Lesezugriff für die allgemeinen EXPLAIN-Tabellen muss ebenfalls eingeschränkt werden, speziell für Benutzer, die die EXPLAIN-Informationen analysieren.

Richtlinien zur Erfassung von EXPLAIN-Informationen

EXPLAIN-Daten werden bei der Kompilierung einer SQL-Anweisung erfasst, wenn Sie dies anfordern. Bei der Anforderung von EXPLAIN-Daten sollten Sie berücksichtigen, wie die erfassten Informationen später verwendet werden sollen.

Erfassen von Informationen in EXPLAIN-Tabellen

Dynamische SQL-Anweisungen:
Informationen für EXPLAIN-Tabellen werden in folgenden Fällen erfasst:
- Das Sonderregister CURRENT EXPLAIN MODE enthält einen der folgenden Werte:
  - YES: Der SQL-Compiler erfasst EXPLAIN-Daten und führt die SQL-Anweisung aus.
  - EXPLAIN: Der SQL-Compiler erfasst EXPLAIN-Daten, führt die SQL-Anweisung jedoch nicht aus.
  - RECOMMEND INDEXES: Der SQL-Compiler erfasst EXPLAIN-Daten, und die Daten zu den empfohlenen Indizes werden in der Tabelle ADVISE_INDEX gespeichert, jedoch wird die SQL-Anweisung nicht ausgeführt.
  - EVALUATE INDEXES: Der SQL-Compiler verwendet die vom Benutzer in die Tabelle ADVISE_INDEX eingefügten Indizes zur Beurteilung. Im Modus EVALUATE INDEXES werden alle dynamischen Anweisungen mit EXPLAIN so bearbeitet, als wären diese virtuellen Indizes verfügbar. Der SQL-Compiler wählt in diesem Fall die virtuellen Indizes aus, wenn sie die Leistung der Anweisungen verbessern. Ansonsten werden die Indizes ignoriert. Durch eine Analyse der EXPLAIN-Ergebnisse können Sie feststellen, ob die vorgeschlagenen Indizes nützlich wären.
  - REOPT: Der SQL-Compiler erfasst EXPLAIN-Daten für statische oder dynamische SQL-Anweisungen bei der Reoptimierung der Anweisung während der Ausführung, wenn für die Hostvariablen, Sonderregister oder Parametermarken tatsächliche Werte zur Verfügung stehen.
- Die Option EXPLAIN ALL wurde im Befehl BIND oder PREP angegeben. Der SQL-Compiler erfasst EXPLAIN-Daten für dynamisches SQL bei der Ausführung, auch wenn das Sonderregister CURRENT EXPLAIN MODE auf den Wert NO gesetzt ist. Die SQL-Anweisung wird ausgeführt und gibt die Abfrageergebnisse zurück.

Zusätzliche Rückkehrcodes von der API db2CfgGet, Parameter collate_info

Der Parameter für Sortierinformationen kann nur mit der API db2CfgGet angezeigt werden. Er kann nicht mit Hilfe des Befehlszeilenprozessors oder der Steuerzentrale angezeigt werden.

Konfigurationstyp: Datenbank
Parametertyp: Informativ

Dieser Parameter enthält 260 Byte mit Informationen zur Sortierfolge der Datenbank. Die ersten 256 Byte geben die Sortierfolge der Datenbank an, wobei Byte "n" die Sortierwertigkeit des Codepunkts enthält, dessen zu Grunde liegende dezimale Darstellung "n" in der Codepage der Datenbank ist.

Die letzten 4 Byte enthalten interne Informationen zum Typ der Sortierfolge. Bei den letzten vier Byte von collate_info handelt es sich um eine ganze Zahl. Die ganze Zahl erkennt die Endian-Folge der Plattform. Die möglichen Werte sind:

0 - Die Sortierfolge enthält nicht eindeutige Wertigkeiten.
1 - Die Sortierfolge enthält ausschließlich eindeutige Wertigkeiten.
2 - Die Sortierfolge ist die Identitätssortierfolge, nach der Zeichenfolgen Byte für Byte verglichen werden.
3 - Die Sortierfolge lautet NLSCHAR und wird für das Sortieren von Zeichen in der Datenbank für Thailändisch TIS620-1 (Codepage 874) verwendet.
4 - Die Sortierfolge lautet IDENTITY_16BIT und implementiert den Algorithmus "CESU-8 Compatibility Encoding Scheme for UTF-16: 8-Bit", wie er im Unicode Technical Report 26 spezifiziert wird, der auf der Webseite des Unicode Technical Consortium (http://www.unicode.org) zur Verfügung steht.
X'8001' - Die Sortierfolge lautet UCA400_NO und implementiert den UCA-Algorithmus (Unicode Collation Algorithm) auf der Grundlage von Unicode Standard Version 4.00 mit implizit aktivierter Normalisierung.
X'8002' - Die Sortierfolge lautet UCA400_LTH und implementiert den UCA-Algorithmus (Unicode Collation Algorithm) auf der Grundlage von Unicode Standard Version 4.00. Sie sortiert alle Zeichen der thailändischen Sprache in der Reihenfolge des Royal Thai Dictionary.
X'8003' - Die Sortierfolge lautet UCA400_LSK und implementiert den UCA-Algorithmus (Unicode Collation Algorithm) auf der Grundlage von Unicode Standard Version 4.00. Sie sortiert alle Zeichen der slowakischen Sprache in der richtigen Reihenfolge.

Wenn Sie diese internen Informationen zum Typ der Sortierfolge verwenden, müssen Sie eine Bytefolgeumkehrung in Betracht ziehen, wenn Informationen zu einer Datenbank auf einer anderen Plattform abgerufen werden.

Sie können die Sortierfolge bei der Erstellung der Datenbank angeben.

Automatische Einstellung der Standardgröße für den Vorablesezugriff und der Standardwerte für Aktualisierungen

Ab DB2 Universal Database (UDB) Version 8.2 können Sie als Vorablesezugriffsgröße für einen Tabellenbereich die Einstellung AUTOMATIC verwenden. DB2 UDB aktualisiert automatisch die Vorablesezugriffsgröße, sobald sich die Anzahl der Behälter für den Tabellenbereich ändert.

Die Syntax der Registrierdatenbankvariablen DB2_PARALLEL_IO wird so erweitert, dass Behälter mit unterschiedlichen Merkmalen für die E/A-Parallelität erkannt werden. Bei der erweiterten Syntax können Behälter für unterschiedliche Tabellenbereiche unterschiedliche Merkmale für die E/A-Parallelität aufweisen. Die Merkmale für die E/A-Parallelität der einzelnen Tabellenbereiche werden verwendet, wenn für den Tabellenbereich als Vorablesezugriffsgröße AUTOMATIC angegeben ist. Wenn die Registrierdatenbankvariable DB2_PARALLEL_IO aktiviert ist, die erweiterte Syntax zur Angabe besonderer Merkmale für die E/A-Parallelität für Tabellenbereiche jedoch nicht verwendet wird, wird die Standardstufe für die Parallelität vorausgesetzt. Die Standardstufe ist RAID 5 (6+1).

Die vom Optimierungsprogramm verwendeten Daten für die Vorablesezugriffsgröße werden nur aktualisiert, wenn Sie eine ALTER TABLESPACE-Anweisung absetzen, die die Vorablesezugriffsgröße eines Tabellenbereichs oder die Anzahl der Behälter (mit ADD/DROP/BEGIN NEW STRIPE SET/ADD TO NEW STRIPE SET) ändert. Wenn sich die Anzahl physischer Festplatten pro Behälter in den Registry-Einstellungen ändert, muss die Anweisung ALTER TABLESPACE <tabellenbereichsname> PREFETCHSIZE AUTOMATIC abgesetzt werden, um die Daten des Optimierungsprogramms zu aktualisieren (es sei denn, eine ALTER TABLESPACE-Anweisung zur Aktualisierung der Daten des Optimierungsprogramms wurde bereits abgesetzt).

Wenn ein Tabellenbereich umgeleitet oder wiederhergestellt wird, so dass eine andere Anzahl von Behältern verwendet wird, sollten Sie die Daten des Optimie- rungsprogramms aktualisieren, indem Sie eine Anweisung ALTER TABLESPACE <tabellenbereichsname> PREFETCHSIZE AUTOMATIC absetzen. Wenn in einem Tabellenbereich mehrere Stripe-Sets vorhanden sind, wird der Stripe-Set mit der maximalen Anzahl von Behältern zur Berechnung der Vorablesezugriffsgröße verwendet. Wenn die berechnete Vorablesezugriffsgröße die Maximalgröße (32.767 Seiten) überschreitet, wird als Vorablesezugriffsgröße das größte Vielfache der Behäl- teranzahl verwendet, das kleiner als die Maximalgröße ist.

Wenn ein Tabellenbereich in einer DB2 UDB Enterprise Server Edition-Umgebung die Einstellung AUTOMATIC für die Vorablesezugriffsgröße verwendet, kann die Vorablesezugriffsgröße auf unterschiedlichen Datenbankpartitionen voneinander abweichen. Diese Situation kann eintreten, da unterschiedliche Datenbankpartitionen eine unterschiedliche Anzahl von Behältern aufweisen können, die zur Berechnung der Vorablesezugriffsgröße verwendet werden. Zum Generieren des Abfragezugriffsplans verwendet das Optimierungsprogramm die Vorablesezugriffsgröße aus der ersten Partition innerhalb einer Datenbankpartitionsgruppe.

Systemverwaltung: Konzept

Bereichsclustertabelle

Eine Bereichsclustertabelle kann nicht in einer Datenbank erstellt werden, die mehr als eine Partition hat.

Konzept des Katalogtabellenbereichs

Bei der Erstellung einer Datenbank werden drei Tabellenbereiche definiert. Dazu gehört der Tabellenbereich SYSCATSPACE für die Systemkatalogtabellen. Die Seitengröße, die als Standardeinstellung für alle Tabellenbereiche gilt, wird bei der Erstellung der Datenbank festgelegt. Bei Auswahl einer Seitengröße von mehr als 4096 bzw. 4 KB wird die Seitengröße für die Katalogtabellen auf eine Zeilengröße beschränkt, die sie haben würde, wenn der Katalogtabellenbereich eine Seitengröße von 4 KB hätte. Die Standardseitengröße der Datenbank wird als informativer Datenbankkonfigurationsparameter mit dem Namen pagesize gespeichert.

Unterstützte Gebietscodes und Codepages

Im Anhang B "Unterstützung in der Landessprache" des Handbuchs Systemverwaltung: Konzept finden Sie im Thema "Unterstützte Gebietscodes und Codepages" Tabellen für die einzelnen Gebiete. Für zwei Tabellen ist eine Aktualisierung erforderlich:

China (VRC), Gebietskennung: CN

Die Codepage für die GBK-Zeile für Linux in der Tabelle "China (VRC), Gebietskennung: CN" muss von 1383 in 1386 geändert werden.

Die Zeile sollte also wie folgt lauten:

1386     D-4     GBK     86     zh_CN.GBK     Linux

Japan, Gebietskennung: JP

Die Tabelle für "Japan, Gebietskennung: JP" wurde überarbeitet.

Der folgende Name für die Ländereinstellung muss entfernt werden:

954      D-1      eucJP   81       japanese      Solaris

Die überarbeitete Tabelle sieht wie folgt aus:

Tabelle 14. Japan, Gebietskennung: JP
Codepage	Gruppe	Codierter Zeichens.	Gebietscode	Ländereinstellung	Betriebs- system
932	D-1	IBM-932	81	Ja_JP	AIX
943	D-1	IBM-943	81	Ja_JP	AIX
954	D-1	IBM-eucJP	81	ja_JP	AIX
1208	N-1	UTF-8	81	JA_JP	AIX
930	D-1	IBM-930	81	-	Host
939	D-1	IBM-939	81	-	Host
5026	D-1	IBM-5026	81	-	Host
5035	D-1	IBM-5035	81	-	Host
1390	D-1		81	-	Host
1399	D-1		81	-	Host
954	D-1	eucJP	81	ja_JP.eucJP	HP-UX
5039	D-1	SJIS	81	ja_JP.SJIS	HP-UX
954	D-1	EUC-JP	81	ja_JP	Linux
932	D-1	IBM-932	81	-	OS/2
942	D-1	IBM-942	81	-	OS/2
943	D-1	IBM-943	81	-	OS/2
954	D-1	eucJP	81	ja	SCO
954	D-1	eucJP	81	ja_JP	SCO
954	D-1	eucJP	81	ja_JP.EUC	SCO
954	D-1	eucJP	81	ja_JP.eucJP	SCO
943	D-1	IBM-943	81	ja_JP.PCK	Solaris
954	D-1	eucJP	81	ja	Solaris
1208	N-1	UTF-8	81	ja_JP.UTF-8	Solaris
943	D-1	IBM-943	81	-	Windows
1394	D-1		81	-

Von DB2 Universal Database unterstützte XA-Funktionalität

DB2 Universal Database (UDB) unterstützt die Spezifikation XA91, die in X/Open CAE Specification Distributed Transaction Processing: The XA Specification definiert ist, mit folgenden Ausnahmen:

Asynchrone Services Die XA-Spezifikation ermöglicht der Schnittstelle die Verwendung asynchroner Services, so dass das Ergebnis einer Anforderung zu einem späteren Zeitpunkt überprüft werden kann. Für den Datenbankmanager müssen die Anforderungen im synchronen Modus aufgerufen werden.
Registrierung Die XA-Schnittstelle ermöglicht zwei Methoden zur Registrierung eines Ressourcenmanagers: statische und dynamische Registrierung. DB2 UDB unterstützt die dynamische und statische Registrierung. DB2 UDB stellt zwei Schalter zur Verfügung:
- db2xa_switch für dynamische Registrierung
- db2xa_switch_static für statische Registrierung
Migration von Zuordnungen DB2 UDB unterstützt die Transaktionsmigration zwischen Threads der Steuerung nicht.

Verwendung und Position von XA-Schaltern

Wie für die XA-Schnittstelle erforderlich, stellt der Datenbankmanager eine externe C-Variable db2xa_switch und db2xa_switch_static des Typs xa_switch_t bereit, um die XA-Schalterstruktur an den Transaktionsmanager zurückzugeben. Neben den Adressen verschiedener XA-Funktionen werden folgende Felder zurückgegeben:

Feld

Wert

name

Der Produktname des Datenbankmanagers. Beispielweise DB2 UDB für AIX.

flags

Für db2xa_switch ist der Wert TMREGISTER | TMNOMIGRATE festgelegt.

Gibt explizit an, dass DB2 UDB die dynamische Registrierung verwendet und dass der TM keine Migration von Zuordnungen verwenden soll. Gibt implizit an, dass kein asynchroner Betrieb unterstützt wird.

Für db2xa_switch_static ist der Wert TMNOMIGRATE festgelegt.

version

Muss Null sein.

Verwenden des XA-Schalters von DB2 Universal Database

Die XA-Architektur erfordert, dass ein Ressourcenmanager (RM) einen Schalter bereitstellt, der dem XA-Transaktionsmanager (TM) Zugriff auf die xa_-Routinen des Ressourcenmanagers gibt. Ein RM-Schalter verwendet eine Struktur, die als xa_switch_t bezeichnet wird. Der Schalter enthält den Namen des RMs, Nicht-NULL-Zeiger auf die XA-Eingangspunkte des RMs, eine Markierung (Flag) und eine Versionsnummer.

Linux- und UNIX-basierte Systeme

Der Schalter für DB2 Universal Database (UDB) kann durch eine der folgenden Methoden abgerufen werden:

Über eine weitere Zwischenstufe. In einem C-Programm kann dies durch Definieren eines Makros erfolgen:
```
      #define db2xa_switch (*db2xa_switch)
   #define db2xa_switch_static (*db2xa_switch)
```
Führen Sie dies vor Verwendung von db2xa_switch oder db2xa_switch_static durch.
Durch Aufrufen von db2xacic oder db2xacicst.
DB2 UDB stellt diese APIs zur Verfügung, die die Adresse der Struktur db2xa_switch oder db2xa_switch_static zurückgeben. Der Prototyp dieser Funktion lautet:
```
      struct xa_switch_t * SQL_API_FN  db2xacic( )
   struct xa_switch_t * SQL_API_FN  db2xacicst( )
```

Bei beiden Methoden müssen Sie die Anwendung an libdb2 binden ("linken").

Windows NT

Der Zeiger auf die Struktur xa_switch, db2xa_switch oder db2xa_switch_static wird in Form von DLL-Daten exportiert. Dies heißt für eine Anwendung unter Windows NT, die diese Struktur verwendet, dass sie mit Hilfe einer der folgenden drei Methoden auf die Struktur zugreifen muss:

Über eine weitere Zwischenstufe. In einem C-Programm kann dies durch Definieren eines Makros erfolgen:
```
   #define db2xa_switch (*db2xa_switch)
   #define db2xa_switch_static (*db2xa_switch)
```
Führen Sie dies vor Verwendung von db2xa_switch oder db2xa_switch_static durch.

Bei Verwendung des Microsoft Visual C++-Compilers kann db2xa_switch oder db2xa_switch_static folgendermaßen definiert werden:

   extern __declspec(dllimport) struct xa_switch_t db2xa_switch
   extern __declspec(dllimport) struct xa_switch_t db2xa_switch_static

Durch Aufrufen von db2xacic oder db2xacicst.
DB2 UDB stellt diese API zur Verfügung, die die Adresse der Struktur db2xa_switch oder db2xa_switch_static zurückgibt. Der Prototyp dieser Funktion lautet:
```
   struct xa_switch_t * SQL_API_FN  db2xacic( )
   struct xa_switch_t * SQL_API_FN  db2xacicst( )
```

Bei jeder dieser Methoden müssen Sie die Anwendung an db2api.lib binden ("linken").

C-Beispielcode

Der folgende Code veranschaulicht die verschiedenen Methoden des Zugriffs auf db2xa_switch oder db2xa_switch_static über ein C-Programm auf einer beliebigen DB2 UDB-Plattform. Stellen Sie sicher, dass die Anwendung mit der entsprechenden Bibliothek verbunden wird.

   #include <stdio.h>
   #include <xa.h>

   struct xa_switch_t * SQL_API_FN  db2xacic( );

   #ifdef DECLSPEC_DEFN
   extern __declspec(dllimport) struct xa_switch_t db2xa_switch;
   #else
   #define db2xa_switch (*db2xa_switch)
   extern struct xa_switch_t db2xa_switch;
   #endif

main( )
   {
      struct xa_switch_t *foo;
      printf ( "%s \n", db2xa_switch.name );
      foo = db2xacic();
printf ( "%s \n", foo->name );
      return ;
   }

Aktualisierte TPM- und tp_mon_name-Werte für xa_open-Zeichenfolgeformate

Die Spalte "Interne Einstellungen" in der folgenden Tabelle wurde so aktualisiert, dass sie die Einstellungen für den TOC (Thread of Control) enthält.

TOC ist die Entität, an die alle DB2 UDB-XA-Verbindungen gebunden werden:

Wenn Sie den Wert auf T setzen, sind alle DB2 UDB-XA-Verbindungen, die unter einem bestimmten Betriebssystemthread gebildet werden, für diesen Thread eindeutig. DB2 UDB-Verbindungen können nicht von mehreren Threads gemeinsam genutzt werden. Jeder Betriebssystemthread muss einen eigenen Satz von DB2 UDB-XA-Verbindungen bilden.
Wenn Sie den Wert auf P setzen, sind alle DB2 UDB-XA-Verbindungen für den Betriebssystemprozess eindeutig, und alle XA-Verbindungen können von den Betriebssystemthreads gemeinsam genutzt werden.

Tabelle 15. Gültige Werte für TPM und tp_mon_name
TPM-Wert	TP-Monitorprodukt	Interne Einstellungen
CICS	IBM TxSeries CICS	AXLIB=libEncServer (für Windows) =/usr/lpp/encina/lib/libEncServer (für Linux and UNIX-Systeme) HOLD_CURSOR=T CHAIN_END=T SUSPEND_CURSOR=F TOC=T
ENCINA	IBM TxSeries Encina Monitor	AXLIB=libEncServer (für Windows) =/usr/lpp/encina/lib/libEncServer (für Linux and UNIX-Systeme) HOLD_CURSOR=F CHAIN_END=T SUSPEND_CURSOR=F TOC=T
MQ	IBM MQSeries	AXLIB=mqmax (für Windows) =/usr/mqm/lib/libmqmax_r.a (für AIX-Anwendungen mit Threads) =/usr/mqm/lib/libmqmax.a (für AIX-Anwendungen ohne Threads) =/opt/mqm/lib/libmqmax.so (für Solaris) =/opt/mqm/lib/libmqmax_r.sl (für HP-Anwendungen mit Threads) =/opt/mqm/lib/libmqmax.sl (für HP-Anwendungen ohne Threads) =/opt/mqm/lib/libmqmax_r.so (für Linux-Anwendungen mit Threads) =/opt/mqm/lib/libmqmax.so (für Linux-Anwendungen ohne Threads) HOLD_CURSOR=F CHAIN_END=F SUSPEND_CURSOR=F TOC=P
CB	IBM Component Broker	AXLIB=somtrx1i (für Windows) =libsomtrx1 (für Linux and UNIX-Systeme) HOLD_CURSOR=F CHAIN_END=T SUSPEND_CURSOR=F TOC=T
SF	IBM San Francisco	AXLIB=ibmsfDB2 HOLD_CURSOR=F CHAIN_END=T SUSPEND_CURSOR=F TOC=T
TUXEDO	BEA Tuxedo	AXLIB=libtux HOLD_CURSOR=F CHAIN_END=F SUSPEND_CURSOR=F TOC=T
MTS	Microsoft Transaction Server	Es ist nicht nötig, DB2 UDB für MTS zu konfigurieren. MTS wird vom ODBC-Treiber von DB2 UDB automatisch erkannt.
JTA	Java Transaction API	Es ist nicht nötig, DB2 UDB for Enterprise Java Servers (EJS) wie IBM WebSphere zu konfigurieren. Der JDBC-Treiber von DB2 UDB erkennt diese Umgebung automatisch. In diesem Fall wird der TPM-Wert ignoriert.

Aktivieren von Konvertierungstabellen für die Codepages 923 und 924

Die folgende Tabelle enthält eine Liste mit allen Konvertierungstabellendateien für Codepages, die den Codepages 923 und 924 zugeordnet sind. Jeder Dateiname hat das Format XXXXYYYY.cnv oder ibmZZZZZ.ucs, wobei XXXX die Nummer der Quellencodepage und YYYY die Nummer der Zielcodepage ist. Die Datei ibmZZZZZ.ucs unterstützt die Konvertierung zwischen Codepage ZZZZZ und Unicode.

Vorgehensweise

Zur Aktivierung einer bestimmten Codepagekonvertierungstabelle benennen Sie die Konvertierungstabellendatei in den neuen Namen um (oder kopieren die Datei in den neuen Namen), der in der zweiten Spalte angegeben ist.

Wenn Sie zum Beispiel bei der Verbindung eines Clients mit 8859-1/15 (Latin 1/9) mit einer Windows-1252-Datenbank das Euro-Symbol verwenden wollen, müssen Sie die folgenden Dateien mit Codepagekonvertierungstabellen im Verzeichnis sqllib/conv/ in den neuen Namen umbenennen bzw. kopieren:

09231252.cnv in 08191252.cnv
12520923.cnv in 12520819.cnv
ibm00923.ucs in ibm00819.ucs

Tabelle 16. Konvertierungstabellendateien für die Codepages 923 und 924
Konvertierungstabellendateien für 923 und 924 im Verzeichnis sqllib/conv/	Neuer Name
04370923.cnv	04370819.cnv
08500923.cnv	08500819.cnv
08600923.cnv	08600819.cnv
08630923.cnv	08630819.cnv
09230437.cnv	08190437.cnv
09230850.cnv	08190850.cnv
09230860.cnv	08190860.cnv
09231043.cnv	08191043.cnv
09231051.cnv	08191051.cnv
09231114.cnv	08191114.cnv
09231252.cnv	08191252.cnv
09231275.cnv	08191275.cnv
09241252.cnv	10471252.cnv
10430923.cnv	10430819.cnv
10510923.cnv	10510819.cnv
11140923.cnv	11140819.cnv
12520923.cnv	12520819.cnv
12750923.cnv	12750819.cnv
ibm00923.ucs	ibm00819.ucs

Konvertierungstabellendateien für Euro-fähige Codepages

In den folgenden Tabellen sind die Konvertierungstabellen aufgelistet, die zur Unterstützung des Euro-Symbols erweitert wurden. Wenn Sie die Unterstützung für das Euro-Symbol inaktivieren wollen, laden Sie die Konvertierungstabellendatei herunter, die in der Spalte 'Konvertierungstabellendateien' angegeben ist.

Arabisch

Datenbankserver-CCSIDs/CPGIDs	Datenbankclient-CCSIDs/CPGIDs	Konvertierungstabellendateien
864, 17248	1046, 9238	08641046.cnv, 10460864.cnv, IBM00864.ucs
864, 17248	1256, 5352	08641256.cnv, 12560864.cnv, IBM00864.ucs
864, 17248	1200, 1208, 13488, 17584	IBM00864.ucs
1046, 9238	864, 17248	10460864.cnv, 08641046.cnv, IBM01046.ucs
1046, 9238	1089	10461089.cnv, 10891046.cnv, IBM01046.ucs
1046, 9238	1256, 5352	10461256.cnv, 12561046.cnv, IBM01046.ucs
1046, 9238	1200, 1208, 13488, 17584	IBM01046.ucs
1089	1046, 9238	10891046.cnv, 10461089.cnv
1256, 5352	864, 17248	12560864.cnv, 08641256.cnv, IBM01256.ucs
1256, 5352	1046, 9238	12561046.cnv, 10461256.cnv, IBM01256.ucs
1256, 5352	1200, 1208, 13488, 17584	IBM01256.ucs

Baltikum

Datenbankserver-CCSIDs/CPGIDs	Datenbankclient-CCSIDs/CPGIDs	Konvertierungstabellendateien
921, 901	1257	09211257.cnv, 12570921.cnv, IBM00921.ucs
921, 901	1200, 1208, 13488, 17584	IBM00921.ucs
1257, 5353	921, 901	12570921.cnv, 09211257.cnv, IBM01257.ucs
1257, 5353	922, 902	12570922.cnv, 09221257.cnv, IBM01257.ucs
1257, 5353	1200, 1208, 13488, 17584	IBM01257.ucs

Weißrussland

Datenbankserver-CCSIDs/CPGIDs	Datenbankclient-CCSIDs/CPGIDs	Konvertierungstabellendateien
1131, 849	1251, 5347	11311251.cnv, 12511131.cnv
1131, 849	1283	11311283.cnv

Kyrillisch

Datenbankserver-CCSIDs/CPGIDs	Datenbankclient-CCSIDs/CPGIDs	Konvertierungstabellendateien
855, 872	866, 808	08550866.cnv, 08660855.cnv
855, 872	1251, 5347	08551251.cnv, 12510855.cnv
866, 808	855, 872	08660855.cnv, 08550866.cnv
866, 808	1251, 5347	08661251.cnv, 12510866.cnv
1251, 5347	855, 872	12510855.cnv, 08551251.cnv, IBM01251.ucs
1251, 5347	866, 808	12510866.cnv, 08661251.cnv, IBM01251.ucs
1251, 5347	1124	12511124.cnv, 11241251.cnv, IBM01251.ucs
1251, 5347	1125, 848	12511125.cnv, 11251251.cnv, IBM01251.ucs
1251, 5347	1131, 849	12511131.cnv, 11311251.cnv, IBM01251.ucs
1251, 5347	1200, 1208, 13488, 17584	IBM01251.ucs

Estland

Datenbankserver-CCSIDs/CPGIDs	Datenbankclient-CCSIDs/CPGIDs	Konvertierungstabellendateien
922, 902	1257	09221257.cnv, 12570922.cnv, IBM00922.ucs
922, 902	1200, 1208, 13488, 17584	IBM00922.ucs

Griechisch

Datenbankserver-CCSIDs/CPGIDs	Datenbankclient-CCSIDs/CPGIDs	Konvertierungstabellendateien
813, 4909	869, 9061	08130869.cnv, 08690813.cnv, IBM00813.ucs
813, 4909	1253, 5349	08131253.cnv, 12530813.cnv, IBM00813.ucs
813, 4909	1200, 1208, 13488, 17584	IBM00813.ucs
869, 9061	813, 4909	08690813.cnv, 08130869.cnv
869, 9061	1253, 5349	08691253.cnv, 12530869.cnv
1253, 5349	813, 4909	12530813.cnv, 08131253.cnv, IBM01253.ucs
1253, 5349	869, 9061	12530869.cnv, 08691253.cnv, IBM01253.ucs
1253, 5349	1200, 1208, 13488, 17584	IBM01253.ucs

Hebräisch

Datenbankserver-CCSIDs/CPGIDs	Datenbankclient-CCSIDs/CPGIDs	Konvertierungstabellendateien
856, 9048	862, 867	08560862.cnv, 08620856.cnv, IBM0856.ucs
856, 9048	916	08560916.cnv, 09160856.cnv, IBM0856.ucs
856, 9048	1255, 5351	08561255.cnv, 12550856.cnv, IBM0856.ucs
856, 9048	1200, 1208, 13488, 17584	IBM0856.ucs
862, 867	856, 9048	08620856.cnv, 08560862.cnv, IBM00862.ucs
862, 867	916	08620916.cnv, 09160862.cnv, IBM00862.ucs
862, 867	1255, 5351	08621255.cnv, 12550862.cnv, IBM00862.ucs
862, 867	1200, 1208, 13488, 17584	IBM00862.ucs
916	856, 9048	09160856.cnv, 08560916.cnv
916	862, 867	09160862.cnv, 08620916.cnv
1255, 5351	856, 9048	12550856.cnv, 08561255.cnv, IBM01255.ucs
1255, 5351	862, 867	12550862.cnv, 08621255.cnv, IBM01255.ucs
1255, 5351	1200, 1208, 13488, 17584	IBM01255.ucs

Latin-1

Datenbankserver-CCSIDs/CPGIDs	Datenbankclient-CCSIDs/CPGIDs	Konvertierungstabellendateien
437	850, 858	04370850.cnv, 08500437.cnv
850, 858	437	08500437.cnv, 04370850.cnv
850, 858	860	08500860.cnv, 08600850.cnv
850, 858	1114, 5210	08501114.cnv, 11140850.cnv
850, 858	1275	08501275.cnv, 12750850.cnv
860	850, 858	08600850.cnv, 08500860.cnv
1275	850, 858	12750850.cnv, 08501275.cnv

Latin-2

Datenbankserver-CCSIDs/CPGIDs	Datenbankclient-CCSIDs/CPGIDs	Konvertierungstabellendateien
852, 9044	1250, 5346	08521250.cnv, 12500852.cnv
1250, 5346	852, 9044	12500852.cnv, 08521250.cnv, IBM01250.ucs
1250, 5346	1200, 1208, 13488, 17584	IBM01250.ucs

Vereinfachtes Chinesisch

Datenbankserver-CCSIDs/CPGIDs	Datenbankclient-CCSIDs/CPGIDs	Konvertierungstabellendateien
837, 935, 1388	1200, 1208, 13488, 17584	1388ucs2.cnv
1386	1200, 1208, 13488, 17584	1386ucs2.cnv, ucs21386.cnv

Traditionelles Chinesisch

Datenbankserver-CCSIDs/CPGIDs	Datenbankclient-CCSIDs/CPGIDs	Konvertierungstabellendateien
937, 835, 1371	950, 1370	09370950.cnv, 0937ucs2.cnv
937, 835, 1371	1200, 1208, 13488, 17584	0937ucs2.cnv
1114, 5210	850, 858	11140850.cnv, 08501114.cnv

Thailand

Datenbankserver-CCSIDs/CPGIDs	Datenbankclient-CCSIDs/CPGIDs	Konvertierungstabellendateien
874, 1161	1200, 1208, 13488, 17584	IBM00874.ucs

Türkisch

Datenbankserver-CCSIDs/CPGIDs	Datenbankclient-CCSIDs/CPGIDs	Konvertierungstabellendateien
857, 9049	1254, 5350	08571254.cnv, 12540857.cnv
1254, 5350	857, 9049	12540857.cnv, 08571254.cnv, IBM01254.ucs
1254, 5350	1200, 1208, 13488, 17584	IBM01254.ucs

Ukraine

Datenbankserver-CCSIDs/CPGIDs	Datenbankclient-CCSIDs/CPGIDs	Konvertierungstabellendateien
1124	1251, 5347	11241251.cnv, 12511124.cnv
1125, 848	1251, 5347	11251251.cnv, 12511125.cnv

Unicode

Datenbankserver-CCSIDs/CPGIDs	Datenbankclient-CCSIDs/CPGIDs	Konvertierungstabellendateien
1200, 1208, 13488, 17584	813, 4909	IBM00813.ucs
1200, 1208, 13488, 17584	862, 867	IBM00862.ucs
1200, 1208, 13488, 17584	864, 17248	IBM00864.ucs
1200, 1208, 13488, 17584	874, 1161	IBM00874.ucs
1200, 1208, 13488, 17584	921, 901	IBM00921.ucs
1200, 1208, 13488, 17584	922, 902	IBM00922.ucs
1200, 1208, 13488, 17584	1046, 9238	IBM01046.ucs
1200, 1208, 13488, 17584	1250, 5346	IBM01250.ucs
1200, 1208, 13488, 17584	1251, 5347	IBM01251.ucs
1200, 1208, 13488, 17584	1253, 5349	IBM01253.ucs
1200, 1208, 13488, 17584	1254, 5350	IBM01254.ucs
1200, 1208, 13488, 17584	1255, 5351	IBM01255.ucs
1200, 1208, 13488, 17584	1256, 5352	IBM01256.ucs
1200, 1208, 13488, 17584	1386	ucs21386.cnv, 1386ucs2.cnv

Vietnamesisch

Datenbankserver-CCSIDs/CPGIDs	Datenbankclient-CCSIDs/CPGIDs	Konvertierungstabellendateien
1258, 5354	1129, 1163	12581129.cnv

API Reference

Unterstützung der Option SYNCPOINT

Die Option SYNCPOINT für die APIs sqlesetc, sqleqryc und sqlaprep wird ab Version 8 ignoriert; sie ist nur aus Gründen der Abwärtskompatibilität verfügbar.

Neues Feld für die Struktur SQLEDBDESC

Der API sqlecrea wurde ein neues Feld hinzugefügt, damit direkte E/A unterstützt wird.

Feldname

Unsigned char sqlfscaching

Beschreibung

Zwischenspeichern des Dateisystems

Werte

0: Das Zwischenspeichern des Dateisystems ist für den aktuellen Tabellenbereich eingeschaltet.
1: Das Zwischenspeichern des Dateisystems ist für den aktuellen Tabellenbereich ausgeschaltet.
Sonstige Codes: Das Zwischenspeichern des Dateisystems ist für den aktuellen Tabellenbereich eingeschaltet.

Korrektur beim neuen Feld in der Struktur SQLB-TBSPQRY-DATA

Der Struktur SQLB-TBSPQRY-DATA wurde das neue Feld unsigned char fsCaching hinzugefügt. Dieses Feld unterstützt die direkte E/A. Obwohl die Größe des reservierten Bits in der Dokumentation als 32 Bit dokumentiert ist, muss die richtige Größe 31 Bit lauten.

Anwendungsentwicklung: Erzeugen und Ausführen von Anwendungen

| | |

Beispiele für die dynamische Rekonfiguration (AIX)

In DB2 Universal Database^(TM) (UDB) Version 8.2 FixPak 3 (äquivalent zu Version 8.1 |FixPak 10) ist die neue Musterdatei ibm_db2_sln_upart_smt enthalten. In der folgenden Tabelle sind der Name und die Beschreibung der Musterdatei dargestellt.

| |||||||||||||||

Tabelle 17. Musterscripts für die dynamische Rekonfiguration
Name des Musterscripts	Dateibeschreibung
`ibm_db2_sln_upart_smt`	Dieses Korn-Shell-Script für die dynamische Rekonfiguration \|(DR-Script) unter AIX ermöglicht die Verwendung der DLPAR-Funktionalität (Dynamic Logical Partitioning), die unter AIX Version 5.3 auf POWER5-basierten pSeries^(R)-Systemen bereitgestellt wird, wie z. B. auf dem p5-570 und dem p5-590. Dieses Script ähnelt dem DR-Script `ibm_db2_sln`, ist jedoch für die Unterstützung der Merkmale von POWER5^(TM) und AIX Version 5.3 optimiert, wie z. B. für die Mikropartitionierung und für SMT. Weitere Informationen hierzu finden Sie im DR-Script selbst.

Das Beispielscript ibm_db2_sln_upart_smt befindet sich in DB2 UDB für AIX im Verzeichnis sqllib/samples/DLPAR.

Von Linux unterstützte Entwicklungssoftware

Details zur Installation finden Sie in der Beschreibung der Linux 2.6-Kernel-Installations-Images in den Release-Informationen für DB2 UDB Version 8.2.2 (Abschnitt Neuheiten in diesem Release).

In den folgenden Tabellen wird die DB2-Unterstützung der Linux-Architektur in FixPak 9 beschrieben. Aktualisierungen für diese Unterstützung finden Sie auf der folgenden Website:

   http://www.ibm.com/db2/linux/validate

Tabelle 18. Linux für Intel^(R) x86 (32 Bit)
Varianten	Kernel	Bibliothek	Kommentare
Conectiva Linux Enterprise Edition (CLEE)	2.4.19	glibc 2.2.5	Powered by United Linux 1.0
LINX Rocky Secure Server 2.1	2.4.21	glibc 2.2.5
Red Flag Advanced Server 4.0	2.4.21-as.2	glibc 2.2.93-5
Red Flag Function Server 4.0	2.4.20-8smp	glibc 2.2.93-5
Red Hat Enterprise Linux 2.1 AS/ES/WS	2.4.9-e16	glibc 2.2.4
Red Hat Enterprise Linux (RHEL) 3 AS/ES/WS	2.4.21-7.EL	glibc-2.3.2-95.3
Red Hat Enterprise Linux (RHEL) 4	2.6.9	glibc-2.3.3	Erfordert außerdem das Paket compat-libstdc++-33
SCO Linux 4.0	2.4.19	glibc 2.2.5	Powered by United Linux 1.0
SuSE Pro 8.0	2.4.18	glibc 2.2.5
SuSE Pro 8.1	2.4.19	glibc 2.2.5
SuSE Linux Enterprise Server (SLES) 7	2.4.7	glibc 2.2.2
SuSE Linux Enterprise Server (SLES) 8	2.4.19	glibc 2.2.5	Geprüft bis SuSE Service-Pack 2
SuSE Linux Enterprise Server (SLES) 9	2.6.5	glibc-2.3.3
Turbolinux 7 Server	2.4.9	glibc 2.2.4
Turbolinux 8 Server	2.4.18-5	glibc 2.2.5
Turbolinux Enterprise Server 8	2.4.19	glibc 2.2.5
United Linux 1.0	2.4.19	glibc 2.2.5

Tabelle 19. Linux für Intel^(R) x86 (32 Bit) Nicht-Enterprise-Varianten (nicht mehr vom Hersteller unterstützt)
Varianten	Kernel	Bibliothek
Red Hat 7.2	2.4.9-34	glibc 2.2.4
Red Hat 7.3	2.4.18	glibc 2.2.5
Red Hat 8.0	2.4.18-14	glibc 2.2.93-5
SuSE 7.3	2.4.10	glibc 2.2.4

Tabelle 20. Linux für s/390 und zSeries^(R) (31-Bit-Kernel-Version für s/390 unterstützt; 64 Bit für zSeries)
Varianten	Kernel	Bibliothek	Kommentare
Red Hat 7.2	2.4.9-38	glibc 2.2.4
Red Hat Enterprise Linux (RHEL) 4	2.6.9	glibc-2.3.3	Erfordert außerdem das Paket compat-libstdc++-33
SuSE Linux Enterprise Server (SLES) 7	2.4.7-58	glibc 2.2.4	compat.rpm enthält libstdc++ 6.1. Verwenden Sie JDK 1.3.1 SR 1 für Java^(TM).
SuSE Linux Enterprise Server (SLES) 8	2.4.19	glibc 2.2.5	Powered by United Linux 1.0
SuSE Linux Enterprise Server (SLES) 9	2.6.5	glibc-2.3.3
Turbo Linux Enterprise Server (TLES) 8	2.4.19	glibc 2.2.5	Powered by United Linux 1.0
United Linux 1.0	2.4.19	glibc 2.2.5

Tabelle 21. Linux für x86-64
Varianten	Kernel	Bibliothek	Kommentare
Red Hat Enterprise Linux (RHEL) 3 AS/ES/WS	2.4.21-7.EL	glibc-2.3.2-95.3
Red Hat Enterprise Linux (RHEL) 4	2.6.9	glibc-2.3.3	Erfordert außerdem das Paket compat-libstdc++-33
SuSE Linux Enterprise Server (SLES) 8.0	2.4.19-SMP	glibc 2.2.5-16
SuSE Linux Enterprise Server (SLES) 9	2.6.5	glibc-2.3.3

Tabelle 22. Linux für POWER^(TM) (iSeries und pSeries^(R))
Varianten	Kernel	Bibliothek	Kommentare
Red Hat Enterprise Linux (RHEL) 3 AS	2.4.21-7.EL	glibc-2.3.2-95.3
Red Hat Enterprise Linux (RHEL) 4	2.6.9	glibc-2.3.3	Erfordert außerdem das Paket compat-libstdc++-33
SuSE Enterprise Server (SLES) 8	2.4.19-16	glibc 2.2.5	Powered by United Linux 1.0
SuSE Linux Enterprise Server (SLES) 9	2.6.5	glibc-2.3.3
Turbolinux Enterprise Server 8	2.4.19-16	glibc 2.2.5	Powered by United Linux 1.0
United Linux 1.0	2.4.19	glibc 2.2.5

Tabelle 23. Linux für IA64
Varianten	Kernel	Bibliothek	Kommentare
Red Hat Enterprise Linux 2.1 AS/ES/WS	2.4.18-e.12smp	glibc
Red Hat Enterprise Linux (RHEL) 3 AS/ES/WS	2.4.21-7.EL	glibc-2.3.2-95.3
Red Hat Enterprise Linux (RHEL) 4	2.6.9	glibc-2.3.3	Erfordert außerdem das Paket compat-libstdc++-33
SuSE Linux Enterprise Server (SLES) 8	2.4.19-SMP	glibc 2.2.5	Powered by United Linux 1.0
SuSE Linux Enterprise Server (SLES) 9	2.6.5	glibc-2.3.3
United Linux 1.0	2.4.19	glibc 2.2.5

DB2 UDB für auf dem 2.6-Kernel basierende Linux-Varianten für Intel x86 unterstützt die folgenden Programmiersprachen und Compiler:

C: GNU/Linux gcc Version 3.3
C++: GNU/Linux g++ Version 3.3
COBOL: Micro Focus COBOL Server Express Version 2.2 mit Service-Pack 1
Java^(TM): IBM^(R) Developer Kit und Runtime Environment für Linux, Java 2 Technology Edition Version 1.3.1 und 1.4.1 Service-Release 1 (32 Bit)
Anmerkung:

DB2 UDB installiert die neueste unterstützte Developer Kit-Version, sofern diese noch nicht installiert ist, es sei denn, die DB2 UDB-Installation ist eine Aktualisierung einer früheren Insallation von DB2 UDB Version 8. Wenn eine frühere Installation von DB2 UDB Version 8 aktualisiert wird, muss das unterstützte Developer Kit manuell von der CD-ROM installiert werden.
Perl: Perl 5.004_04 oder höher, DBI 0.93 oder höher
PHP: PHP 4.3.4 oder höher
REXX: Object REXX Interpreter für Linux Version 2.1

Ein 32-Bit-Exemplar für DB2 UDB für auf dem 2.6-Kernel basierende Linux-Varianten für x86-64 unterstützt die folgenden Programmiersprachen und Compiler:

C

GNU/Linux gcc Version 3.3

Anmerkung:

Die Compileroption "-m32" muss verwendet werden, um 32-Bit-Anwendungen oder -Routinen (gespeicherte Prozeduren und benutzerdefinierte Funktionen) zu generieren.

C++

GNU/Linux g++ Version 3.3

Anmerkungen:

Diese Versionen des GNU/Linux-Compilers g++ akzeptieren für einige fstream-Funktionen keine ganzzahligen Parameter. Weitere Informationen finden Sie in der Dokumentation zu diesem Compiler.
Die Compileroption "-m32" muss verwendet werden, um 32-Bit-Anwendungen oder -Routinen (gespeicherte Prozeduren und benutzerdefinierte Funktionen) zu generieren.

Java

IBM Developer Kit und Runtime Environment für Linux x86, Java 2 Technology Edition Version 1.3.1 Service-Release 4 (32 Bit) und Version 1.4.1 Service-Release 1 (32 Bit)

Anmerkung:

DB2 UDB installiert die neueste unterstützte Developer Kit-Version, sofern diese noch nicht installiert ist, es sei denn, die DB2 UDB-Installation ist eine Aktualisierung einer früheren Insallation von DB2 UDB Version 8. Wenn eine frühere Installation von DB2 UDB Version 8 aktualisiert wird, muss das unterstützte Developer Kit manuell von der CD-ROM installiert werden.

Perl

Perl 5.8

PHP

PHP 4.3.4 oder höher

Ein 64-Bit-Exemplar für DB2 UDB für auf dem 2.6-Kernel basierende Linux-Varianten für x86-64 unterstützt die folgenden Programmiersprachen und Compiler:

C: GNU/Linux gcc Version 3.3
C++: GNU/Linux g++ Version 3.3
Anmerkung:

Diese Versionen des GNU/Linux-Compilers g++ akzeptieren für einige fstream-Funktionen keine ganzzahligen Parameter. Weitere Informationen finden Sie in der Dokumentation zu diesem Compiler.
Java: DB2 UDB unterstützt zurzeit kein 64-Bit-Java Developer Kit für Linux für x86-64.
Perl: Perl 5.8
PHP: PHP 4.3.4 oder höher

Anpassen der Optionen für das Vorkompilieren und Binden für SQL-Prozeduren

Die Optionen für das Vorkompilieren und Binden für SQL-Prozeduren können Sie anpassen, indem Sie die im Exemplar gültige DB2-Registrierdatenbankvariable DB2_SQLROUTINE_PREPOPTS mit dem folgenden Befehl setzen:

db2set DB2_SQLROUTINE_PREPOPTS=<optionen>

Außer den Optionen, die in Version 8.2 dokumentiert sind, ist die Option REOPT zulässig:

BLOCKING {UNAMBIG | ALL | NO}
DATETIME {DEF | USA | EUR | ISO | JIS | LOC}
DEGREE {1 | grad-der-parallelität | ANY}
DYNAMICRULES {BIND | RUN}
EXPLAIN {NO | YES | ALL}
EXPLSNAP {NO | YES | ALL}
FEDERATED {NO | YES}
INSERT {DEF | BUF}
ISOLATION {CS | RR | UR | RS | NC}
QUERYOPT optimierungsgrad
REOPT {ALWAYS | NONE | ONCE}
VALIDATE {RUN | BIND}

C/C++-Compileroption erforderlich (Linux auf POWER (64 Bit))

Die Compileroption "-m64" ist erforderlich, wenn gcc/g++ zur Erzeugung von C/C++-Anwendungen und -Routinen für ein 64-Bit-Exemplar unter DB2 Universal Database für Linux auf POWER verwendet wird.

Die Compileroption "-q64" ist erforderlich, wenn xlc/xlC zur Erzeugung von C/C++-Anwendungen und -Routinen für ein 64-Bit-Exemplar unter DB2 Universal Database für Linux auf POWER verwendet wird.

Kompilierungs- und Bindebefehl für gespeicherte Micro Focus COBOL-Prozeduren (HP-UX)

Der Kompilierungs- und Bindebefehl in der Dokumentation zu DB2 Universal Database Version 8.2, mit dem gespeicherte Prozeduren in Micro Focus COBOL unter HP-UX erzeugt werden, ist falsch. Der Kompilierungsbefehl in der Prozedur sqllib/samples/cobol_mf/bldrtn ist jedoch richtig. Die Befehle zum Kompilieren und Binden werden nun in einem einzigen Befehl zusammengefasst, wobei mit der Option -y angegeben wird, dass die gewünschte Ausgabe eine gemeinsam genutzte Bibliothek ist.

Mindestens unterstützte Version von Micro Focus COBOL (HP-UX)

Vom Micro Focus COBOL-Compiler und von der Micro Focus COBOL-Laufzeitumgebung unter HP-UX wird mindestens die Version Micro Focus Server Express 2.2 - Service Pack 1 mit Fixpack Fixpack22.02_14 für HP-UX PA-RISC 11.x (32/64 Bit) unterstützt. Dieser Fixpack ist auf der Website der Micro Focus Support Line unter http://supportline.microfocus.com verfügbar .

Setzen der Umgebungsvariablen für gespeicherte Micro Focus COBOL-Prozeduren (Windows)

Damit externe Micro Focus COBOL-Routinen unter Windows ausgeführt werden können, müssen die Micro Focus COBOL-Umgebungsvariablen dauerhaft als Systemvariablen gesetzt sein.

Vorgehensweise

Gehen Sie wie folgt vor, um die Umgebungsvariablen als Systemvariablen zu setzen:

Öffnen Sie die Systemsteuerung.
Wählen Sie System aus.
Wählen Sie die Indexzunge Erweitert aus.
Klicken Sie die Option Umgebungsvariablen an.
Fügen Sie die Variablen der Liste Systemvariablen hinzu.

Wenn Sie die Umgebungsvariablen in der Liste Benutzervariablen, an der Eingabeaufforderung oder mit einer Prozedur setzen, reicht dies nicht aus.

Anwendungsentwicklung: CLI (Call Level Interface)

| | |

Diagnosetabellenaktualisierung für die Funktion SQLDescribeParam (CLI)

Die Funktion SQLDescribeParam() gibt die Beschreibung einer Parametermarke zurück, die einer vorbereiteten SQL-Anweisung zugeordnet ist.

Bei SQLSTATE HYC00 wurde die Diagnosetabelle aktualisiert.

|Diagnose |

| |||||||||||||||||

Tabelle 24. SQLSTATE-Werte für SQLDescribeParam
SQLSTATE-Wert	Beschreibung	Erläuterung
HYC00	Treiber ist nicht funktionsfähig.	Die gespeicherten Prozeduren der Schemafunktion sind auf dem Server nicht zugänglich. \|Installieren Sie die gespeicherten Prozeduren der Schemafunktion auf dem Server, und stellen Sie sicher, dass sie zugänglich sind.

| | |

Asynchrone Ausführung der CLI (Call Level Interface)

Die DB2 CLI (DB2 Call Level Interface) kann eine Untermenge von Funktionen asynchron ausführen. |Der DB2 CLI-Treiber gibt die Steuerung nach dem Aufruf der Funktion, jedoch vor der Beendung ihrer Ausführung, an die Anwendung zurück. Die Funktion gibt bei jedem Aufruf SQL_STILL_EXECUTING zurück, bis ihre Ausführung beendet ist. Danach gibt sie einen anderen Wert zurück (z. B. SQL_SUCCESS).

Die asynchrone Ausführung ist nur unter Single-Thread-Betriebssystemen von Vorteil. Anwendungen, die unter Multithread-Betriebssystemen ausgeführt werden, sollten Funktionen in separaten Threads ausführen. Die asynchrone Ausführung ist für diejenigen Funktionen möglich, die normalerweise eine Anforderung an den Server senden und anschließend auf eine Antwort warten. Statt zu warten, gibt eine asynchron ausgeführte Funktion die Steuerung an die Anwendung zurück. Die Anwendung kann anschließend andere Tasks ausführen, oder sie kann die Steuerung an das Betriebssystem zurückgeben und die Funktion mit Hilfe eines Interrupts wiederholt abfragen, bis ein anderer Rückkehrcode als SQL_STILL_EXECUTING zurückgegeben wird.

Die Unterstützung für eine asynchrone Ausführung der CLI ist ab Version 8.2 FixPak 1 (äquivalent zu Version 8.1 FixPak 8) in DB2 Universal Database (UDB) enthalten. Die Dokumentation zu dieser Funktion finden Sie unter der URL-Adresse http://publib.boulder.ibm.com/infocenter/db2v7luw/index.jsp in Information - Unterstützung für DB2 UDB Version 7. Alle Informationen in der Dokumentation zu Version 7 gelten für Versionen ab Version |8.2 FixPak 1 (äquivalent zu Version 8.1 FixPak 8). Information - Unterstützung für DB2 Version |8 enthält keine Dokumentation zu dieser Funktion.

| | |

Verbindungsattribut SQL_ATTR_PING_DB

|SQL_ATTR_PING_DB (DB2 CLI Version 8.2) |

SQL_ATTR_PING_DB ist eine 32-Bit-Ganzzahl, die mit der Funktion SQLGetConnectAttr() verwendet wird, um die Antwortzeit des Netzwerks bei einer vorhandenen Verbindung zwischen dem DB2 UDB-Client und dem DB2 UDB-Server abzurufen. Die Antwortzeit wird in Mikrosekunden zurückgemeldet.

Wenn die Datenbank vorher eine Verbindung hergestellt und diese freigegeben hat, wird der Wert 0 zurückgemeldet. Wenn die Verbindung von der Anwendung geschlossen wurde, wird der SQLSTATE-Wert 08003 zurückgemeldet. Dieses Verbindungsattribut kann von SQLGetConnectAttr() zurückgegeben werden, Es kann jedoch nicht mit Hilfe von SQLSetConnectAttr() gesetzt werden. |Wenn Sie versuchen, dieses Attribut festzulegen, wird der SQLSTATE-Wert HYC00 (Treiber ist nicht funktionsfähig) zurückgegeben.

| | |

Funktion SQLBindParameter (CLI)

In der Dokumentation zur Funktion SQLBindParameter ist die Beschreibung im Abschnitt zum Eingabeparameter falsch. Die richtige Beschreibung muss wie folgt lauten:

Eingabeparameter: Der Wert 0 für ColumnSize bedeutet, dass DB2 CLI die maximale Länge für den SQL-Typ verwendet, der als Größe für den Spaltenparameter oder für den Parameter für gespeicherte Prozedur angegeben wird. DB2 CLI führt alle erforderlichen Konvertierungen unter Verwendung dieser Größe aus. |

| | |

Funktion SQLMoreResults (CLI)

In der Dokumentation zur Funktion SQLMoreResults ist das Anweisungsattribut SQL_ATTR_ROW_ARRAY_SIZE falsch angegeben. Das richtige Anweisungsattribut muss SQL_ATTR_PARAMSET_SIZE lauten. Der Abschnitt zur Verwendung muss wie folgt lauten:

Diese Funktion gibt mehrere Ergebnismengen sequenziell zurück, wenn Folgendes ausgeführt wird:

Abfrage mit Parameterangaben und mit einer Feldgruppe von Eingabeparameterwerten, die mit dem Anweisungsattribut SQL_ATTR_PARAMSET_SIZE und mit SQLBindParameter() eingegeben werden

Zusätzliche Umgebungsattribute

Die folgenden Attribute sind CLI-Verbindungsattribute und werden außerdem als CLI-Umgebungsattribute unterstützt:

SQL_ATTR_INFO_ACCTSTR
SQL_ATTR_INFO_APPLNAME
SQL_ATTR_INFO_USERID
SQL_ATTR_INFO_WRKSTNNAME

Informationen zu diesen Attributen finden Sie in der Dokumentation zu den CLI-Verbindungsattributen in DB2 Information - Unterstützung oder in CLI Guide and Reference Volume 2.

Voraussetzung für dynamische verschiebbare Cursor

Zum Aktualisieren und Löschen von Zeilen in der Ergebnismenge eines dynamischen verschiebbaren Cursors muss die Anweisung UPDATE oder DELETE alle Spalten von mindestens einem eindeutigen Schlüssel in der Basistabelle einschließen. Dies kann der Primärschlüssel oder ein beliebiger anderer eindeutiger Schlüssel sein.

| | |

CLI/ODBC-Konfigurationsschlüsselwort RetCatalogAsCurrServer

Beschreibung des Schlüsselworts

||Katalogfunktionen geben für die Katalogspalten nicht den Nullwert sondern den Wert für CURRENT SERVER zurück. |

Syntax für das Schlüsselwort der db2cli.ini:

||RetCatalogAsCurrServer= 0 | 1 |

Standardeinstellung:

||Wenn das Ziel-DBMS für die Katalogspalten einen Nullwert zurückgibt, wird der Wert für CURRENT |SERVER nicht ersetzt. |

Verwendungshinweise:

||Wenn die Katalogfunktionen für das Ziel-DBMS einen Nullwert für die Katalogspalten zurückgeben, und wenn Sie den Wert für RetCatalogAsCurrServer auf 1 setzen, gibt das DBMS stattdessen den Wert für CURRENT SERVER zurück. |

0 = Katalogfunktionen geben für die Katalogspalten den Nullwert zurück (Standardeinstellung).

1 = Katalogfunktionen geben für die Katalogspalten nicht den Nullwert sondern den Wert für CURRENT SERVER zurück

Beispiel: Die Katalogfunktion SQLTables() gibt eine Ergebnismenge zurück, in der die Werte für die Spalte TABLE_CAT Nullwerte sind. Wenn der Wert für |RetCatalogAsCurrServer auf 1 gesetzt wird, gibt das DBMS den Wert für CURRENT SERVER in der Spalte TABLE_CAT zurück.

| |

Anmerkung:

Dieses Schlüsselwort wird von DB2 |UDB für Linux, UNIX^(R) und Windows^(R) ab Version 8.2 FixPak 3 (äquivalent zu Version 8.1 FixPak 10) unterstützt.

CLI/ODBC-Konfigurationsschlüsselwort ReceiveTimeout

Beschreibung des Schlüsselworts: Geben Sie die Zeit in Sekunden an, die auf eine Antwort vom Server über eine hergestellte Verbindung gewartet werden soll, bevor der Versuch beendet wird und ein Fehler auf Grund der Zeitlimitüberschreitung bei der Datenübertragung generiert wird.
Syntax für das Schlüsselwort der db2cli.ini:: ReceiveTimeout = 0 | 1 | 2 | ... | 32767
Standardeinstellung:: Der Client wartet unbestimmte Zeit auf eine Antwort vom Server über eine hergestellte Verbindung.
Funktional entsprechendes Anweisungsattribut:: SQL_ATTR_RECEIVE_TIMEOUT
Verwendungshinweise:: Der Standardwert 0 gibt an, dass der Client unbestimmte Zeit auf eine Antwort wartet. Die Zeitlimitüberschreitung bei Empfang hat während des Verbindungsaufbaus keine Auswirkungen. Sie wird nur für TCP/IP unterstützt und wird für jedes andere Protokoll ignoriert.

Anweisungsattribut SQL_ATTR_RECEIVE_TIMEOUT

SQL_ATTR_RECEIVE_TIMEOUT (DB2 CLI Version 8): Ein ganzzahliger 32-Bit-Wert, der die Anzahl Sekunden angibt, die ein Client auf eine Antwort vom Server über eine hergestellte Verbindung wartet, bevor der Versuch beendet wird und ein Fehler auf Grund der Zeitlimitüberschreitung bei der Datenübertragung generiert wird. Der Standardwert 0 gibt an, dass der Client unbestimmte Zeit auf eine Antwort wartet. Die Zeitlimitüberschreitung bei Empfang hat während des Verbindungsaufbaus keine Auswirkungen. Sie wird nur für TCP/IP unterstützt und wird für jedes andere Protokoll ignoriert. Als unterstützte Werte gelten ganze Zahlen von 0 bis 32767.

CLI/ODBC-Konfigurationsschlüsselwort Reopt

Beschreibung des Schlüsselworts

Ermöglicht die Abfrageoptimierung oder -reoptimierung für SQL-Anweisungen, die spezielle Register oder Parametermarken haben.

Syntax für das Schlüsselwort der db2cli.ini:

Reopt = 2 | 3 | 4

Standardeinstellung:

Während der Ausführungszeit einer Abfrage wird keine Abfrageoptimierung durchgeführt. Die vom Compiler ausgewählten Standardschätzwerte werden für spezielle Register oder Parametermarken verwendet.

Funktional entsprechendes Anweisungsattribut:

SQL_ATTR_REOPT

Verwendungshinweise:

Die Optimierung wird durchgeführt, wenn an Stelle der vom Compiler ausgewählten Standardschätzwerte die Werte verwendet werden, die während der Ausführungszeit der Abfrage für die speziellen Register und Parametermarken verfügbar sind. Die gültigen Werte des Schlüsselwerts lauten wie folgt:

2 = SQL_REOPT_NONE. Dies ist der Standardwert. Während der Ausführungszeit einer Abfrage wird keine Abfrageoptimierung durchgeführt. Die vom Compiler ausgewählten Standardschätzwerte werden für spezielle Register oder Parametermarken verwendet. Der "NULLID"-Standardpaketsatz wird für die Ausführung dynamischer SQL-Anweisungen verwendet.
3 = SQL_REOPT_ONCE. Die Abfrageoptimierung wird während der Ausführungszeit einer Abfrage einmal durchgeführt, und zwar bei der ersten Ausführung der Abfrage. Es wird der "NULLIDR1"-Paketsatz verwendet, der mit der Bindeoption REOPT ONCE gebunden ist.
4 = SQL_REOPT_ALWAYS. Die Abfrageoptimierung oder -reoptimierung wird während der Ausführungszeit einer Abfrage bei jeder Ausführung der Abfrage durchgeführt. Es wird der "NULLIDRA"-Paketsatz verwendet, der mit der Bindeoption REOPT ALWAYS gebunden ist.

"NULLIDR1" und "NULLIDRA" sind reservierte Paketsatznamen, bei deren Verwendung REOPT ONCE und REOPT ALWAYS entsprechend impliziert sind. Diese Paketsätze müssen mit den folgenden Befehlen explizit erstellt werden:

db2 bind db2clipk.bnd collection NULLIDR1
db2 bind db2clipk.bnd collection NULLIDRA

Wenn sowohl das Schlüsselwort Reopt als auch das Schlüsselwort CurrentPackageSet angegeben sind, hat CurrentPackageSet Vorrang.

Anweisungsattribut SQL_ATTR_REOPT

SQL_ATTR_REOPT (DB2 CLI Version 8)

Ein ganzzahliger 32-Bit-Wert, der die Abfrageoptimierung für SQL-Anweisungen ermöglicht, die spezielle Register oder Parametermarken enthalten. Die Optimierung wird durchgeführt, wenn an Stelle der vom Compiler ausgewählten Standardschätzwerte die Werte verwendet werden, die während der Ausführungszeit einer Abfrage für spezielle Register und Para- metermarken verfügbar sind. Die gültigen Werte des Attributs lauten wie folgt:

2 = SQL_REOPT_NONE. Dies ist der Standardwert. Während der Ausführungszeit einer Abfrage wird keine Abfrageoptimierung durchgeführt. Die vom Compiler ausgewählten Standardschätzwerte werden für spezielle Register oder Parametermarken verwendet. Der "NULLID"-Standardpaketsatz wird für die Ausführung dynamischer SQL-Anweisungen verwendet.
3 = SQL_REOPT_ONCE. Die Abfrageoptimierung wird während der Ausführungszeit einer Abfrage einmal durchgeführt, und zwar bei der ersten Ausführung der Abfrage. Es wird der "NULLIDR1"-Paketsatz verwendet, der mit der Bindeoption REOPT ONCE gebunden ist.
4 = SQL_REOPT_ALWAYS. Die Abfrageoptimierung oder -reoptimierung wird während der Ausführungszeit einer Abfrage bei jeder Ausführung der Abfrage durchgeführt. Es wird der "NULLIDRA"-Paketsatz verwendet, der mit der Bindeoption REOPT ALWAYS gebunden ist.

db2 bind db2clipk.bnd collection NULLIDR1
db2 bind db2clipk.bnd collection NULLIDRA

SQL_ATTR_REOPT und SQL_ATTR_CURRENT_PACKAGE_SET schließen sich gegenseitig aus. Wenn also eines dieser Attribute gesetzt ist, ist das andere Attribut nicht zulässig.

CLI/ODBC-Konfigurationsschlüsselwort CurrentPackageSet

Beschreibung des Schlüsselworts

Setzt die Anweisung SET CURRENT PACKAGESET nach jedem Verbindungsaufbau ab.

Syntax für das Schlüsselwort der db2cli.ini:

CurrentPackageSet = schemaname

Standardeinstellung:

Die Klausel ist nicht angehängt.

Funktional entsprechendes Verbindungsattribut:

SQL_ATTR_CURRENT_PACKAGE_SET

Verwendungshinweise:

Diese Option setzt die SQL-Anweisung SET CURRENT PACKAGESET mit dem Wert CurrentPackageSet ab, sobald eine Verbindung zu einer Datenbank hergestellt wurde. Die Klausel ist standardmäßig nicht angehängt.

Die SQL-Anweisung SET CURRENT PACKAGESET legt den Schemanamen (Objektgruppen-ID) fest, mit dem das Paket für nachfolgende SQL-Anweisungen ausgewählt wird.

CLI/ODBC-Anwendungen setzen dynamische SQL-Anweisungen ab. Mit dieser Option können Sie die Zugriffsrechte steuern, mit denen diese Anweisungen ausgeführt werden:

Wählen Sie ein Schema aus, das bei der Ausführung von SQL-Anweisungen in CLI/ODBC-Anwendungen verwendet werden soll.
Stellen Sie sicher, dass die Objekte im Schema die gewünschten Zugriffsrechte haben, und führen Sie anschließend eine erneute Bindeoperation aus.
Geben Sie dieses Schema in der Option CurrentPackageSet an.

Die SQL-Anweisungen in den CLI/ODBC-Anwendungen werden jetzt unter dem angegebenen Schema ausgeführt und verwenden die dort definierten Zugriffsrechte.

Die folgenden Paketsatznamen sind reserviert: "NULLID", "NULLIDR1", "NULLIDRA".

Wenn sowohl das Schlüsselwort Reopt als auch das Schlüsselwort CurrentPackageSet angegeben sind, hat CurrentPackageSet Vorrang.

Verbindungsattribut SQL_ATTR_CURRENT_PACKAGE_SET

SQL_ATTR_CURRENT_PACKAGE_SET (DB2 CLI Version 5)

Eine auf Null endende Zeichenfolge, die den Schemanamen (Objektgruppen-ID) angibt, mit dem das Paket für nachfolgende SQL-Anweisungen ausgewählt wird. Durch das Setzen dieses Attributs wird die SQL-Anweisung SET CURRENT PACKAGESET abgesetzt. Wenn dieses Attribut gesetzt wird, bevor eine Verbindung hergestellt wurde, wird die SQL-Anweisung SET CURRENT PACKAGESET abgesetzt, sobald eine Verbindung hergestellt wird.

CLI/ODBC-Anwendungen setzen dynamische SQL-Anweisungen ab. Mit diesem Verbindungsattribut können Sie die Zugriffsrechte steuern, mit denen diese Anweisungen ausgeführt werden:

Wählen Sie ein Schema aus, das bei der Ausführung von SQL-Anweisungen in CLI/ODBC-Anwendungen verwendet werden soll.
Stellen Sie sicher, dass die Objekte im Schema die gewünschten Zugriffsrechte haben, und führen Sie anschließend eine erneute Bindeoperation aus. In der Regel werden dabei die CLI-Pakete (sqllib/bnd/db2cli.lst) unter Verwendung der Option COLLECTION <sammid> gebunden. Weitere Informationen hierzu finden Sie in der Dokumentation zum Befehl BIND.
Geben Sie dieses Schema in der Option CURRENTPACKAGESET an.

Die SQL-Anweisungen in den CLI/ODBC-Anwendungen werden jetzt unter dem angegebenen Schema ausgeführt und verwenden die dort definierten Zugriffsrechte.

Das Setzen des CLI/ODBC-Konfigurationsschlüsselworts CURRENTPACKAGESET ist eine alternative Methode zur Angabe des Schemanamens.

Die folgenden Paketsatznamen sind reserviert: "NULLID", "NULLIDR1", "NULLIDRA".

SQL_ATTR_REOPT und SQL_ATTR_CURRENT_PACKAGE_SET schließen sich gegenseitig aus. Wenn also eines dieser Attribute gesetzt ist, ist das andere Attribut nicht zulässig.

Schlüsselwort MapBigintCDefault für die CLI/ODBC-Konfiguration

Beschreibung des Schlüsselworts: Geben Sie den Standard-C-Typ der BIGINT-Spalten und der BIGINT-Parametermarken an.
Syntax für das Schlüsselwort der db2cli.ini:: MapBigintCDefault = 0 | 1 | 2
Standardeinstellung:: Die Standard-C-Typ-Darstellung für BIGINT-Daten ist SQL_C_BIGINT.
Verwendungshinweise:

MapBigintCDefault steuert den C-Typ, der verwendet wird, wenn SQL_C_DEFAULT für BIGINT-Spalten und für BIGINT-Parametermarken angegeben wird. Dieses Schlüsselwort sollte vor allem für Microsoft-Anwendungen eingesetzt werden, z. B. für die Anwendung Microsoft Access, die keine 8-Byte-Ganzzahlen verarbeiten kann. Setzen Sie MapBigintCDefault wie folgt:

0 - für die SQL_C_BIGINT-Standard-C-Typ-Darstellung
1 - für eine SQL_C_CHAR-C-Typ-Darstellung
2 - für eine SQL_C_WCHAR-C-Typ-Darstellung

Dieses Kennwort wirkt sich auf das Verhalten von CLI-Funktionen aus, bei denen SQL_C_DEFAULT als C-Typ angegeben werden kann, z. B. SQLBindParameter(), SQLBindCol() und SQLGetData().

Schlüsselwort DescribeOutputLevel für die CLI/ODBC-Konfiguration

Beschreibung des Schlüsselworts: Legt die Stufe der DESCRIBE-Daten der Ausgabespalte fest, die vom CLI-Treiber bei PREPARE- oder DESCRIBE-Anforderungen angefordert werden.
Syntax für das Schlüsselwort der db2cli.ini:: DescribeOutputLevel = 0 | 1 | 2 | 3
Standardeinstellung:: Anforderung der DESCRIBE-Daten, die in Stufe 2 der Tabelle 25 aufgelistet sind.
Verwendungshinweise:

Dieses Schlüsselwort steuert die Datenmenge, die der CLI-Treiber bei einer PREPARE- oder DESCRIBE-Anforderung anfordert. Standardmäßig gibt der Server bei Empfang einer DESCRIBE-Anforderung die Informationen zurück, die in Stufe 2 der Tabelle 25 für die Ergebnismengenspalten aufgelistet sind. Möglicherweise benötigt eine Anwendung jedoch nicht alle Informationen, oder sie benötigt zusätzliche Informationen.

Wenn das Schlüsselwort DescribeOutputLevel auf eine Stufe gesetzt wird, die dem Bedarf der Clientanwendung entspricht, wird möglicherweise die Leistung gesteigert, da die zwischen dem Client und dem Server übertragenen DESCRIBE-Daten auf die Mindestmenge begrenzt sind, die für die Anwendung erforderlich ist. Wenn DescribeOutputLevel auf einen zu niedrigen Wert gesetzt wird, kann sich dies auf die Funktionalität der Anwendung auswirken (in Abhängigkeit von den Anforderungen der Anwendung). Die CLI-Funktionen zum Abrufen der DESCRIBE-Informationen schlagen in diesem Fall möglicherweise nicht fehl, die zurückgegebenen Daten sind jedoch möglicherweise unvollständig.

Folgende Einstellungen für DescribeOutputLevel werden unterstützt:

0 - Es werden keine DESCRIBE-Informationen an die Clientanwendung zurückgegeben.
1 - DESCRIBE-Informationen, die in Stufe 1 kategorisiert werden (siehe Tabelle 25), werden an die Clientanwendung zurückgegeben.
2 - (Standardeinstellung) DESCRIBE-Informationen, die in Stufe 2 kategorisiert werden (siehe Tabelle 25), werden an die Clientanwendung zurückgegeben.
3 - DESCRIBE-Informationen, die in Stufe 3 kategorisiert werden (siehe Tabelle 25), werden an die Clientanwendung zurückgegeben.

In der folgenden Tabelle sind die Felder aufgeführt, aus denen die DESCRIBE-Informationen bestehen, die der Server bei Empfang einer PREPARE- oder DESCRIBE-Anforderung zurückgibt. Diese Felder werden in Stufen gruppiert, und das Schlüsselwort DescribeOutputLevel für die CLI/ODBC-Konfiguration steuert, welche Stufen von DESCRIBE-Informationen der CLI-Treiber anfordert.

Anmerkung:

Nicht alle Stufen von DESCRIBE-Informationen werden von allen DB2-Servern unterstützt. Auf den folgenden DB2-Servern werden alle Stufen von DESCRIBE-Informationen unterstützt: DB2 Universal Database (UDB) für Linux, UNIX und Windows ab Version 8, DB2 UDB für z/OS ab Version 8 und DB2 UDB für iSeries ab Version 5 Release 3. Alle übrigen DB2-Server unterstützten für DescribeOutputLevel nur die Einstellung 2 oder 0.

Tabelle 25. Stufen der DESCRIBE-Informationen
Stufe 1	Stufe 2	Stufe 3
SQL_DESC_COUNT SQL_COLUMN_COUNT SQL_DESC_TYPE SQL_DESC_CONCISE_TYPE SQL_COLUMN_LENGTH SQL_DESC_OCTET_LENGTH SQL_DESC_LENGTH SQL_DESC_PRECISION SQL_COLUMN_PRECISION SQL_DESC_SCALE SQL_COLUMN_SCALE SQL_DESC_DISPLAY_SIZE SQL_DESC_NULLABLE SQL_COLUMN_NULLABLE SQL_DESC_UNSIGNED SQL_DESC_SEARCHABLE SQL_DESC_LITERAL_SUFFIX SQL_DESC_LITERAL_PREFIX SQL_DESC_CASE_SENSITIVE SQL_DESC_FIXED_PREC_SCALE	Alle Felder der Stufe 1 und: SQL_DESC_NAME SQL_DESC_LABEL SQL_COLUMN_NAME SQL_DESC_UNNAMED SQL_DESC_TYPE_NAME SQL_DESC_DISTINCT_TYPE SQL_DESC_REFERENCE_TYPE SQL_DESC_STRUCTURED_TYPE SQL_DESC_USER_TYPE SQL_DESC_LOCAL_TYPE_NAME SQL_DESC_USER_DEFINED_ TYPE_CODE	Alle Felder der Stufen 1 und 2 und: SQL_DESC_BASE_COLUMN_NAME SQL_DESC_UPDATABLE SQL_DESC_AUTO_UNIQUE_VALUE SQL_DESC_SCHEMA_NAME SQL_DESC_CATALOG_NAME SQL_DESC_TABLE_NAME SQL_DESC_BASE_TABLE_NAME

Tabelle 25. Stufen der DESCRIBE-Informationen

Stufe 1

Stufe 2

Stufe 3

SQL_DESC_COUNT
SQL_COLUMN_COUNT
SQL_DESC_TYPE
SQL_DESC_CONCISE_TYPE
SQL_COLUMN_LENGTH
SQL_DESC_OCTET_LENGTH
SQL_DESC_LENGTH
SQL_DESC_PRECISION
SQL_COLUMN_PRECISION
SQL_DESC_SCALE
SQL_COLUMN_SCALE
SQL_DESC_DISPLAY_SIZE
SQL_DESC_NULLABLE
SQL_COLUMN_NULLABLE
SQL_DESC_UNSIGNED
SQL_DESC_SEARCHABLE
SQL_DESC_LITERAL_SUFFIX
SQL_DESC_LITERAL_PREFIX
SQL_DESC_CASE_SENSITIVE
SQL_DESC_FIXED_PREC_SCALE

Alle Felder der Stufe 1
und:
SQL_DESC_NAME
SQL_DESC_LABEL
SQL_COLUMN_NAME
SQL_DESC_UNNAMED
SQL_DESC_TYPE_NAME
SQL_DESC_DISTINCT_TYPE
SQL_DESC_REFERENCE_TYPE
SQL_DESC_STRUCTURED_TYPE
SQL_DESC_USER_TYPE
SQL_DESC_LOCAL_TYPE_NAME
SQL_DESC_USER_DEFINED_
         TYPE_CODE

Alle Felder der Stufen 1
und 2 und:
SQL_DESC_BASE_COLUMN_NAME
SQL_DESC_UPDATABLE
SQL_DESC_AUTO_UNIQUE_VALUE
SQL_DESC_SCHEMA_NAME
SQL_DESC_CATALOG_NAME
SQL_DESC_TABLE_NAME
SQL_DESC_BASE_TABLE_NAME

Anwendungsentwicklung: Programmieren von Clientanwendungen

| | |

Lastausgleich für DB2 Universal JDBC-Treiber über Verbindungskonzentrator und Sysplex

Java-Anwendungen, die über die DB2 Universal JDBC-Treiber Type 4-Konnektivität auf DB2 UDB für z/OS^(R)-Server zugreifen, können die zugehörigen Verbindungskonzentrator- und Sysplex-Funktionen für den Lastausgleich nutzen.

Diese Funktionen ähneln den Verbindungskonzentrator- und Sysplex-Funktionen für Lastausgleich von DB2 Connect.

Der Verbindungskonzentrator für den DB2 Universal JDBC-Treiber kann die Ressourcen reduzieren, die DB2 |UDB für z/OS-Datenbankserver zur Unterstützung einer großen Anzahl Clientanwendungen benötigen. Dies geschieht, indem viele Verbindungsobjekte dieselbe physische Verbindung verwenden dürfen. Dadurch verringert sich die Gesamtzahl physischer Verbindungen zum Datenbankserver.

Der Sysplex-Lastausgleich für DB2 Universal JDBC-Treiber kann die Verfügbarkeit einer Gruppe mit gemeinsamer Datennutzung verbessern, da der Treiber häufige Statusinformationen zu den Mitgliedern einer solchen Gruppe erhält. Der Treiber bestimmt anhand dieser Informationen das Mitglied der Gruppe mit gemeinsamer Datennutzung, an das die nächste Transaktion weitergeleitet werden soll. Über den Sysplex-Lastausgleich stellen der DB2 UDB für z/OS-Server und der Workload Manager für z/OS (WLM) sicher, dass die Last zwischen Mitgliedern der Gruppe mit gemeinsamer Datennutzung effizient verteilt und dass die Last bei Ausfall eines Mitglieds einer Gruppe mit gemeinsamer Datennutzung an die anderen Mitglieder dieser Gruppe übertragen wird.

Der DB2 Universal JDBC-Treiber verwendet Transportobjekte und einen globalen Transportobjektpool, damit der Verbindungskonzentrator- und Sysplex-Lastausgleich unterstützt wird. Für jede physische Verbindung zum Datenbankserver gibt es ein einziges Transportobjekt. |Wenn Sie den Verbindungskonzentrator- und Sysplex-Lastausgleich aktivieren, können Sie die maximale Anzahl physischer Verbindungen zum Datenbankserver zu einem beliebigen Zeitpunkt festlegen, indem Sie die maximale Anzahl Transportobjekte festlegen.

Für die Anzahl Transportobjekte legen Sie auf Treiberebene mit Hilfe der Konfigurationsmerkmale des DB2 Universal JDBC-Treibers Grenzen fest.

Auf Verbindungsebene aktivieren und inaktivieren Sie für den DB2 Universal JDBC-Treiber den Verbindungskonzentrator- und Sysplex-Lastausgleich und legen Grenzen für die Anzahl Transportobjekte fest. Dazu verwenden Sie die DataSource-Merkmale.

Sie können den globalen Transportobjektpool auf eine der folgenden Arten überwachen:

Verwendung von Traces, die Sie unter Verwendung der Konfigurationsmerkmale des DB2 Universal JDBC-Treibers starten

Verwendung einer Anwendungsprogrammierschnittstelle

| |

Konfigurationsmerkmale des DB2 Universal JDBC-Treibers für den Verbindungskonzentrator- und Sysplex-Lastausgleich

Jedes der folgenden Konfigurationsmerkmale wird für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet.

db2.jcc.dumpPool

|||Gibt zusätzlich zur geschriebenen Zusammenfassungsstatistik die Statistiktypen an, die für globale Transportpoolereignisse geschrieben wurden. Der globale Transportpool wird für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet. | |

Der Datentyp von db2.jcc.dumpPool ist eine ganze Zahl (int.). Die Konfigu- |rationsmerkmale db2.jcc.dumpPoolStatisticsOnSchedule |und db2.jcc.dump- |PoolStatisticsOnScheduleFile müssen für das Schreiben von Statistiken eben- |falls festgelegt werden, noch bevor Statistiken geschrieben werden.

Sie können für das Merkmal db2.jcc.dumpPool folgende Statistiktypen angeben:

DUMP_REMOVE_OBJECT (hexadezimal: X'01', dezimal: 1)

DUMP_GET_OBJECT (hexadezimal: X'02', dezimal: 2)

DUMP_WAIT_OBJECT (hexadezimal: X'04', dezimal: 4)

DUMP_SET_AVAILABLE_OBJECT (hexadezimal: X'08', dezimal: |8)

DUMP_CREATE_OBJECT (hexadezimal: X'10', dezimal: 16)

DUMP_SYSPLEX_MSG (hexadezimal: X'20', dezimal: 32)

DUMP_POOL_ERROR (hexadezimal: X'80', dezimal: 128)

Wenn Sie einen Trace für mehrere Ereignistypen durchführen möchten, fügen Sie die Werte für diese Ereignistypen hinzu. Nehmen Sie z. B. einmal an, Sie möchten einen Trace für die Ereignisse DUMP_GET_OBJECT und DUMP_CREATE_OBJECT durchführen. Die numerischen Entsprechungen dieser Werte sind 2 und 16. Also geben Sie als Wert für db2.jcc.dumpPool die Zahl 18 an.

Der Standardwert ist 0, d. h., für den globalen Transportpool werden nur Zusammenfassungstatistiken geschrieben.

db2.jcc.dumpPoolStatisticsOnSchedule

||||Gibt in der Maßeinheit Sekunden an, wie oft Transportpoolstatistiken in die Datei geschrieben werden, die mit dem Konfigurationsmerkmal db2.jcc.dumpPoolStatisticsOnScheduleFile angegeben wurde. Der globale Transportpool wird für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet. |

Der Standardwert lautet -1, d. h., die Statistikdaten für den globalen Transportpool werden nicht überschrieben.

db2.jcc.dumpPoolStatisticsOnScheduleFile

||||Gibt den Namen der Datei an, in die die Statistikdaten für den globalen Transportpool geschrieben werden. Der globale Transportpool wird für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet. |

Wenn das Konfigurationsmerkmal db2.jcc.dumpPoolStatisticsOnScheduleFile nicht angegeben ist, werden die Statistikdaten für den globalen Transportpool nicht geschrieben.

db2.jcc.maxTransportObjectIdleTime

||||Gibt die Zeitspanne in Sekunden an, die ein nicht verwendetes Transportobjekt im globalen Transportobjektpool bleibt, bis es aus dem Pool gelöscht werden kann. Transportobjekte werden für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet. |

Der Standardwert für das Konfigurationsmerkmal db2.jcc.maxTransportObjectIdleTime beträgt 60. Wenn Sie das Konfigurationsmerkmal b2.jcc.maxTransportObjectIdleTime auf einen Wert unter 0 setzen, werden nicht verwendete Transportobjekte sofort aus dem Pool gelöscht. Diese Aktion wird nicht empfohlen, da sie hohe Leistungseinbußen verursachen kann.

db2.jcc.maxTransportObjectWaitTime

||||Gibt die Höchstdauer in Sekunden an, die eine Anwendung auf ein Transportobjekt wartet, falls der Wert für db2.jcc.maxTransportObjects erreicht wurde. Transportobjekte werden für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet. Wenn eine Anwendung länger wartet als im Wert für db2.jcc.maxTransportObjectWaitTime angegeben, löst der globale Transportobjektpool eine SQLException aus. |

Der Standardwert für das Konfigurationsmerkmal db2.jcc.maxTransportObjectWaitTime beträgt -1. Ein negativer Wert bedeutet, dass Anwendungen unbegrenzte Zeit warten.

db2.jcc.maxTransportObjects

||||Gibt die Obergrenze für die Anzahl Transportobjekte in einem globalen Transportobjektpool für den Verbindungskonzentrator- und Sysplex-Last- |ausgleich an. Wenn die Anzahl Transportobjekte im Pool den Wert für db2.jcc.maxTransportObjects erreicht, werden Transportobjekte aus dem Pool gelöscht, die nicht länger als im Wert für db2.jcc.maxTransportObjectIdleTime angegeben verwendet wurden. |

Der Standardwert für das Konfigurationsmerkmal db2.jcc.maxTransportObjects beträgt -1. Dies bedeutet, dass es für die Anzahl Transportobjekte im globalen Transportobjektpool keinen Grenzwert gibt.

db2.jcc.minTransportObjects

||||Gibt die Untergrenze für die Anzahl Transportobjekte in einem globalen Transportobjektpool für den Verbindungskonzentrator- und Sysplex-Lastausgleich an. Wenn eine JVM erstellt wird, sind im Pool keine Transportobjekte vorhanden. |Transportobjekte werden dem Pool bei Bedarf hinzugefügt. Nach Erreichen des Werts für db2.jcc.minTransportObjects unterschreitet die Anzahl Transportobjekte im globalen Transportobjektpool für die Lebensdauer der entsprechenden JVM nie den Wert für db2.jcc.minTransportObjects. |

Der Standardwert für das Konfigurationsmerkmal db2.jcc.minTransportObjects beträgt 0. Alle Werte kleiner-gleich 0 bedeuten, dass der globale Transportobjektpool leer werden kann.

|| | |

DataSource-Merkmale für den DB2 Universal JDBC-Treiber zum Verbindungskonzentrator- und Sysplex-Lastausgleich

Jedes der folgenden DataSource-Merkmale für den DB2 Universal JDBC-Treiber wird für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet.

enableConnectionConcentrator

|||Gibt an, ob die Verbindungskonzentratorfunktion des DB2 Universal JDBC-Treibers aktiviert ist. Die Verbindungskonzentratorfunktion ist nur für Verbindungen zu DB2 UDB für z/OS-Server verfügbar. |

Der Datentyp des Merkmals enableConnectionConcentrator ist Boolean. Der Standardwert ist false. Wenn jedoch enableSysplexWLB auf true gesetzt ist, lautet der Standardwert true.

enableSysplexWLB

||||Gibt an, ob die Sysplex-Lastausgleichsfunktion des DB2 Universal JDBC-Treibers aktiviert ist. Die Sysplex-Lastausgleichsfunktion ist nur für Verbindungen zu DB2 UDB für z/OS-Servern verfügbar. |

Der Datentyp des Merkmals enableSysplexWLB ist Boolean. Der Standardwert ist false. Wenn enableSysplexWLB jedoch auf true gesetzt ist, wird enableConnectionConcentrator standardmäßig auf true gesetzt.

maxTransportObjects

||||Gibt die maximale Anzahl Transportobjekte an, die für alle Verbindungen mit dem zugeordneten DataSource-Objekt verwendet werden können. Transportobjekte werden für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet. Der Wert für maxTransportObjects wird ignoriert, falls das Merkmal enableConnectionConcentrator oder enableSysplexWLB nicht so eingestellt ist, dass die Verwendung des Verbindungskonzentrator- und Sysplex-Lastausgleichs aktiviert ist. |

Der Datentyp dieses Merkmals ist eine ganze Zahl (int.).

Wenn der Wert für maxTransportObjects nicht erreicht wurde und wenn im globalen Transportobjektpool kein Transportobjekt verfügbar ist, erstellt der Pool ein neues Transportobjekt. Wenn der Wert für maxTransportObjects erreicht ist, wartet die Anwendung während der Zeitspanne, die im Konfigurationsmerkmal db2.jcc.maxTransportObjectWaitTime angegeben ist. Wenn diese Zeitspanne vorbei ist und im Pool immer noch kein Transportobjekt verfügbar ist, löst der Pool eine SQLException aus.

Das Merkmal maxTransportObjects überschreibt das Konfigurationsmerkmal db2.jcc.maxTransportObjects nicht. Das Merkmal maxTransportObjects wirkt sich nicht auf Verbindungen von anderen DataSource-Objekten aus. |Wenn der Wert für maxTransportObjects größer ist als der Wert für db2.jcc.maxTransportObjects, erhöht der Wert für maxTransportObjects den Wert für db2.jcc.maxTransportObjects nicht.

Der Standardwert für das Merkmal maxTransportObjects beträgt -1. Dies bedeutet, dass die Anzahl der Transportobjekte für DataSource nur durch |den Wert für db2.jcc.maxTransportObjects für den Treiber begrenzt wird.

|| | |

Beispiel für die Aktivierung der Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion für den DB2 Universal JDBC-Treiber bei WebSphere Application Server

Die folgende Vorgehensweise ist ein Beispiel für die Aktivierung der Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion für den DB2 Universal JDBC-Treiber bei WebSphere^(R) Application Server.

|Voraussetzungen |

Servervoraussetzungen:

WLM für z/OS

DB2 UDB für OS/390^(R) und z/OS ab Version 7

Clientvoraussetzungen:

DB2 Universal JDBC-Treiber mit FixPak 10

WebSphere Application Server ab Version 5.1

|Vorgehensweise |

Gehen Sie wie folgt vor, um die Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion für den DB2 Universal JDBC-Treiber bei WebSphere Application Server zu aktivieren:

Überprüfen Sie, ob der DB2 Universal JDBC-Treiber die richtige Stufe aufweist, damit er die Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion unterstützt. Setzen Sie dazu an den Befehlszeilenprozessor unter z/OS oder in den System Services unter UNIX den folgenden Befehl ab: |
```
java com.ibm.db2.jcc.DB2Jcc -version
```
Suchen Sie in der Ausgabe eine Zeile ähnlich der Folgenden: |
```
[ibm][db2][jcc] Driver: IBM DB2 JDBC Universal Driver Architecture n n
```
Dabei steht n für eine Versionsnummer ab 2.7.

Setzen Sie die Konfigurationsmerkmale für den DB2 Universal JDBC-Treiber so, dass der Verbindungskonzentrator- und Sysplex-Lastausgleich für alle DataSource-Exemplare aktiviert wird, die unter dem Treiber erstellt werden. |
Legen Sie die Konfigurationsmerkmale in der Datei DB2JccConfiguration.properties fest.
|
1. Erstellen Sie eine Datei mit dem Namen DB2JccConfiguration.properties, oder editieren Sie die vorhandene Datei DB2JccConfiguration.properties.
2. Legen Sie die folgenden Konfigurationsmerkmale fest: |
  - db2.jcc.minTransportObjects
  - db2.jcc.maxTransportObjects
  - db2.jcc.maxTransportObjectWaitTime
  - db2.jcc.dumpPool
  - db2.jcc.dumpPoolStatisticsOnScheduleFile
  Starten Sie mit Einstellungen ähnlich den Folgenden: |
```
db2.jcc.minTransportObjects=0
|db2.jcc.maxTransportObjects=1500
|db2.jcc.maxTransportObjectWaitTime=-1
|db2.jcc.dumpPool=0
|db2.jcc.dumpPoolStatisticsOnScheduleFile=
|  /home/WAS/logs/srv1/poolstats
```
3. Fügen Sie den Verzeichnispfad für die Datei DB2JccConfiguration.properties dem Klassenpfad des DB2 Universal JDBC-Treibers für WebSphere Application Server hinzu.

Legen Sie die Datenquellenmerkmale für den DB2 Universal JDBC-Treiber so fest, dass die Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion aktiviert ist. |

Legen Sie in der WebSphere Application Server-Verwaltungskonsole die folgenden Merkmale für die Datenquelle fest, die die Anwendung zum Herstellen der Verbindung zum Datenbankserver verwendet:

enableSysplexWLB

enableConnectionConcentrator

maxTransportObjects

Angenommen, Sie möchten sowohl die Verbindungskonzentratorfunktion als auch die Sysplex-Lastausgleichsfunktion aktivieren. Starten Sie mit Einstellungen ähnlich den Folgenden: | ||||||||||||||||||||||

Tabelle 26. Beispiel für Einstellungen von Datenquellenmerkmalen für die Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion für den DB2 Universal JDBC-Treiber
Merkmal	Einstellung
enableSysplexWLB	true¹
maxTransportObjects	100
\| \| Anmerkungen: \| \| Das Merkmal enableConnectionConcentrator ist standardmäßig auf `true` gesetzt, da das Merkmal enableSysplexWLB auf `true` gesetzt ist. \|

Starten Sie WebSphere Application Server erneut.

| |

Methoden zur Überwachung der Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion für den DB2 Universal JDBC-Treiber

Zur Überwachung der Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion für den DB2 Universal JDBC-Treiber müssen Sie den globalen Transportobjektpool überwachen. Sie können den globalen Transportobjektpool auf eine der folgenden Arten überwachen:

Verwendung von Traces, die Sie über die Einstellung der Konfigurationsmerkmale des DB2 Universal JDBC-Treibers starten

Verwendung einer Anwendungsprogrammierschnittstelle

| |

Konfigurationsmerkmale zur Überwachung des globalen Transportobjektpools

Die Konfigurationsmerkmale db2.jcc.dumpPool, db2.jcc.dumpPoolStatisticsOnSchedule und db2.jcc.dumpPoolStatisticsOnScheduleFile steuern die Traceverarbeitung des globalen Transportobjektpools.

Zum Beispiel führen die folgenden Konfigurationsmerkmale dazu, dass Sysplex-Fehlernachrichten und Nachrichten über Speicherauszugspoolfehler alle 60 Sekunden in eine Datei mit dem Namen /home/WAS/logs/srv1/poolstats geschrieben werden:

db2.jcc.dumpPool=DUMP_SYSPLEX_MSG|DUMP_POOL_ERROR
|db2.jcc.dumpPoolStatisticsOnSchedule=60
|db2.jcc.dumpPoolStatisticsOnScheduleFile=/home/WAS/logs/srv1/poolstats

Ein Eintrag in der Poolstatistikdatei sieht wie folgt aus:

uhrzeit Scheduled PoolStatistics npr:2575 nsr:2575 lwroc:439
|hwroc:1764 coc:372 aooc:362 rmoc:362 nbr:2872 tbt:857520 tpo:10

Die Felder haben die folgenden Bedeutungen:

npr: Gesamtzahl der Anforderungen, die der DB2 Universal JDBC-Treiber seit der Erstellung des Pools an diesen gesendet hat. |
nsr: Anzahl der erfolgreichen Anforderungen, die der DB2 Universal JDBC-Treiber an den Pool seit der Erstellung des Pools gesendet hat. Eine erfolgreiche Anforderung bedeutet, dass der Pool ein Objekt zurückgegeben hat. |
lwroc: Anzahl der Objekte, die wiederverwendet wurden, jedoch nicht im Pool waren. Dieser Fall kann eintreten, wenn ein Verbindungsobjekt an einer Transaktionsgrenze ein Transportobjekt freigibt. Wenn das Verbindungsobjekt später ein Transportobjekt benötigt und wenn das ursprüngliche Transportobjekt von keinem anderen Verbindungsobjekt verwendet wurde, kann das Verbindungsobjekt dieses Transportobjekt verwenden. |
hwroc: Anzahl der Objekte, die aus dem Pool wiederverwendet wurden. |
coc: Anzahl der seit der Poolerstellung vom DB2 Universal JDBC-Treiber erstellten Objekte. |
aooc: Anzahl der Objekte, die die im Konfigurationsmerkmal db2.jcc.maxTransportObjectIdleTime angegebene Leerlaufzeit überschritten haben und aus dem Pool gelöscht wurden. |
rmoc: Anzahl der Objekte, die seit der Poolerstellung aus dem Pool gelöscht wurden. |
nbr: Anzahl der Anforderungen, die der DB2 Universal JDBC-Treiber an den Pool gesendet hat und die der Pool wegen bereits belegter maximaler Kapazität blockiert hat. Eine blockierte Anforderung kann erfolgreich sein, falls ein Objekt an den Pool zurückgegeben wird, bevor der Konfigura- |tionswert für db2.jcc.maxTransportObjectWaitTime überschritten und eine Ausnahmebedingung ausgelöst wird. |
tbt: Gesamtzeit in Millisekunden, während der der Pool Anforderungen blockiert hat. Wenn die Anwendung mehrere Threads verwendet, kann diese Zeitdauer viel größer sein als die Ausführungszeit der Anwendung. |
tpo: Anzahl der Objekte, die sich momentan im Pool befinden. |

| |

Anwendungsprogrammierschnittstellen zur Überwachung des globalen Transportobjektpools

Sie können Anwendungen schreiben, um Statistikdaten zum globalen Transportobjektpool zu erfassen. Derartige Anwendungen erstellen Objekte in der Klasse DB2PoolMonitor und rufen Daten zum Pool mit Hilfe von Methoden ab.

Der folgenden Code erstellt z. B. ein Objekt zur Überwachung des globalen Transportobjektpools:

import com.ibm.db2.jcc.DB2PoolMonitor;
|DB2PoolMonitor transportObjectPoolMonitor =  
|	DB2PoolMonitor.getPoolMonitor (DB2PoolMonitor.TRANSPORT_OBJECT);

Nach der Erstellung des DB2PoolMonitor-Objekts können Sie die folgenden Methoden verwenden, um den globalen Transportobjektpool zu überwachen.

getMonitorVersion

||Format: |

public int getMonitorVersion()

Ruft die Version der DB2PoolMonitor-Klasse ab, die mit dem DB2 Universal JDBC-Treiber ausgeliefert wird.

totalRequestsToPool

||Format: |

public int totalRequestsToPool()

Ruft die Gesamtzahl der Anforderungen ab, die der DB2 Universal JDBC-Treiber seit der Poolerstellung an den Pool gesendet hat.

successfullRequestsFromPool

||Format: |

public int successfullRequestsFromPool()

Ruft die Anzahl erfolgreicher Anforderungen ab, die der DB2 Universal JDBC-Treiber seit der Poolerstellung an den Pool gesendet hat. Eine erfolgreiche Anforderung bedeutet, dass der Pool ein Objekt zurückgegeben hat.

numberOfRequestsBlocked

||Format: |

public int numberOfRequestsBlocked()

Ruft die Anzahl der Anforderungen ab, die der DB2 Universal JDBC-Treiber an den Pool gesendet hat und die der Pool wegen bereits belegter maximaler Kapazität blockiert hat. Eine blockierte Anforderung kann erfolgreich sein, falls ein Objekt an den Pool zurückgegeben wird, bevor der Konfigurationswert für db2.jcc.maxTransportObjectWaitTime überschritten und eine Ausnahmebedingung ausgelöst wird.

totalTimeBlocked

||Format: |

public long totalTimeBlocked()

Ruft die Gesamtzeit in Millisekunden ab, während der der Pool Anforderungen blockiert hat. Wenn die Anwendung mehrere Threads verwendet, kann diese Zeitdauer viel größer sein als die Ausführungszeit der Anwendung.

lightWeightReusedObjectCount

||Format: |

public int lightWeightReusedObjectCount()

Ruft die Anzahl der Objekte ab, die wiederverwendet wurden, jedoch nicht im Pool waren. Dieser Fall kann eintreten, wenn ein Verbindungsobjekt an einer Transaktionsgrenze ein Transportobjekt freigibt. Wenn das Verbindungsobjekt später ein Transportobjekt benötigt und wenn das ursprüngliche Transportobjekt von keinem anderen Verbindungsobjekt verwendet wurde, kann das Verbindungsobjekt dieses Transportobjekt verwenden.

heavyWeightReusedObjectCount

||Format: |

public int heavyWeightReusedObjectCount()

Ruft die Anzahl der Objekte ab, die aus dem Pool wiederverwendet wurden.

createdObjectCount

||Format: |

public int createdObjectCount()

Ruft die Anzahl der seit der Poolerstellung vom DB2 Universal JDBC-Treiber erstellten Objekte ab.

agedOutObjectCount

||Format: |

public int agedOutObjectCount()

Ruft die Anzahl der Objekte ab, die die im Konfigurationsmerkmal db2.jcc.maxTransportObjectIdleTime angegebene Leerlaufzeit überschritten haben und aus dem Pool gelöscht wurden.

removedObjectCount

||Format: |

public int removedObjectCount()

Ruft die Anzahl der Objekte ab, die seit der Poolerstellung aus dem Pool gelöscht wurden.

totalPoolObjects

||Format: |

public int totalPoolObjects()

Anzahl der Objekte, die sich momentan im Pool befinden.

CLI/ODBC-Konfigurationsschlüsselwort OleDbReportIsLongForLongTypes

Das Schlüsselwort OleDbReportIsLongForLongTypes wird für die folgenden Datenbankserver unterstützt:

DB2 UDB für z/OS Version 6 mit PTF UQ93891
DB2 UDB für z/OS Version 7 mit PTF UQ93889
DB2 UDB für z/OS Version 8 mit PTF UQ93890
DB2 UDB für Linux, UNIX und Windows ab Version 8.2 (äquivalent zu Version 8.1 FixPak 7)

Beschreibung des Schlüsselworts: Bewirkt, dass OLE DB LONG-Datentypen mit DBCOLUMNFLAGS_ ISLONG markiert.
Syntax für das Schlüsselwort der db2cli.ini:: OleDbReportIsLongForLongTypes = 0 | 1
Funktional entsprechendes Anweisungsattribut:: SQL_ATTR_REPORT_ISLONG_FOR_LONGTYPES_OLEDB
Standardeinstellung:: Für LONG-Typen (LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC und LONG VARGRAPHIC FOR BIT DATA) ist das Flag DBCOLUMNFLAGS_ISLONG nicht gesetzt. Dadurch können die Spalten ggf. in der WHERE-Klausel verwendet werden.
Verwendungshinweise:

CCE (Client Cursor Engine) von OLE DB und CommandBuilder von OLE DB .NET Data Provider generieren Aktualisierungs- und Löschanweisungen auf der Basis von Spalteninformationen, die von IBM DB2 OLE DB Provider bereitgestellt werden. Wenn die generierte Anweisung in der WHERE-Klausel einen LONG-Typ enthält, schlägt die Anweisung fehl, da LONG-Typen bei einer Suche mit Gleichheitsoperator nicht verwendet werden können. Wenn Sie das Schlüsselwort OleDbReportIsLongForLongTypes auf 1 setzen, meldet IBM DB2 OLE DB Provider LONG-Typen (LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC und LONG VARGRAPHIC FOR BIT DATA) über das gesetzte Flag DBCOLUMNFLAGS_ISLONG zurück. Dadurch wird verhindert, dass die Spalten mit LONG-Typen in der WHERE-Klausel verwendet werden.

CLI/ODBC-Konfigurationsschlüsselwort OleDbSQLColumnsSortByOrdinal

Das Schlüsselwort OleDbSQLColumnsSortByOrdinal wird von den folgenden Datenbankservern unterstützt:

DB2 UDB für z/OS Version 6 mit PTF UQ93891
DB2 UDB für z/OS Version 7 mit PTF UQ93889
DB2 UDB für z/OS Version 8 mit PTF UQ93890
DB2 UDB für Linux, UNIX und Windows ab Version 8.2 (äquivalent zu Version 8.1 FixPak 7)

Beschreibung des Schlüsselworts: Bewirkt, dass IDBSchemaRowset::GetRowset(DBSCHEMA_COLUMNS) von OLE DB eine Zeilengruppe zurückgibt, die nach der Spalte ORDINAL_POSITION sortiert ist.
Syntax für das Schlüsselwort der db2cli.ini:: OleDbSQLColumnsSortByOrdinal = 0 | 1
Funktional entsprechendes Anweisungsattribut:: SQL_ATTR_SQLCOLUMNS_SORT_BY_ORDINAL_OLEDB
Standardeinstellung:: IDBSchemaRowset::GetRowset(DBSCHEMA_COLUMNS) gibt die Zeilengruppe nach den Spalten TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME und COLUMN_NAME sortiert zurück.
Verwendungshinweise:

Die Microsoft OLE DB-Spezifikation erfordert, dass IDBSchemaRowset::GetRowset(DBSCHEMA_COLUMNS) die Zeilengruppe nach den Spalten TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME und COLUMN_NAME sortiert zurückgibt. IBM DB2 OLE DB Provider entspricht der Spezifikation. Allerdings wurden Anwendungen, die den Microsoft ODBC Bridge-Provider (MSDASQL) verwenden, normalerweise so codiert, dass die Zeilengruppe nach ORDINAL_POSITION sortiert wird. Wenn Sie das Schlüsselwort OleDbSQLColumnsSortByOrdinal auf 1 setzen, gibt der Provider eine Zeilengruppe zurück, die nach ORDINAL_POSITION sortiert ist.

Eigenschaftsgruppe DB2 Data Source für IBM DB2 OLE DB Provider

IBM DB2 OLE DB Provider hat eine neue Eigenschaftsgruppe hinzugefügt: DB2 Data Source. Diese Eigenschaftsgruppe für DB2 Data Source ist DBPROPSET_DB2DATASOURCE.

Die GUID für die Eigenschaftsgruppe lautet wie folgt: {0x8a80412a,0x7d94,0x4fec,{0x87,0x3e,0x6c,0xd1,0xcd,0x42,0x0d,0xcd}}

DBPROPSET_DB2DATASOURCE weist drei Merkmale auf:

DB2PROP_REPORTISLONGFORLONGTYPES
DB2PROP_RETURNCHARASWCHAR
DB2PROP_SORTBYORDINAL

DB2PROP_REPORTISLONGFORLONGTYPES

#define DB2PROP_REPORTISLONGFORLONGTYPES 4
Eigenschaftsgruppe: DB2 Data Source 
Eigenschaftsset: DB2PROPSET_DATASOURCE
Typ: VT_BOOL
Typischer Schreib-/Lesezugriff: R/W
Beschreibung: IsLong für LONG-Typen zurückmelden

Tabelle 27. Werte für DB2PROP_REPORTISLONGFORLONGTYPES
Werte	Bedeutung
VARIANT_TRUE	IBM DB2 OLE DB Provider meldet LONG-Typen (LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC und LONG VARGRAPHIC FOR BIT DATA) über das gesetzte Flag DBCOLUMNFLAGS_ISLONG zurück. Dadurch wird verhindert, dass die Spalten mit LONG-Typen in der WHERE-Klausel verwendet werden.
VARIANT_FALSE	DBCOLUMNFLAGS_ISLONG ist für LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC und LONG VARGRAPHIC FOR BIT DATA nicht gesetzt. Dies ist der Standardwert.

DB2PROP_RETURNCHARASWCHAR

#define DB2PROP_RETURNCHARASWCHAR 2
Eigenschaftsgruppe: DB2 Data Source 
Eigenschaftsset: DB2PROPSET_DATASOURCE
Typ: VT_BOOL
Typischer Schreib-/Lesezugriff: R/W
Beschreibung: Char als WChar zurückgeben

Tabelle 28. Werte für DB2PROP_RETURNCHARASWCHAR
Werte	Bedeutung
VARIANT_TRUE	OLE DB beschreibt Spalten des Typs CHAR, VARCHAR, LONG VARCHAR oder CLOB als DBTYPE_WSTR. Die Codepage der in ISequentialStream implizierten Daten ist UCS-2. Dies ist der Standardwert.
VARIANT_FALSE	OLE DB beschreibt Spalten des Typs CHAR, VARCHAR, LONG VARCHAR oder CLOB als DBTYPE_STR. Die Codepage der in ISequentialStream implizierten Daten ist die lokale Codepage des Clients.

DB2PROP_SORTBYORDINAL

#define DB2PROP_SORTBYORDINAL 3
Eigenschaftsgruppe: DB2 Data Source 
Eigenschaftsset: DB2PROPSET_DATASOURCE
Typ: VT_BOOL
Typischer Schreib-/Lesezugriff: R/W
Beschreibung: Nach Ordinalzahl sortieren

Tabelle 29. Werte für DB2PROP_SORTBYORDINAL
Werte	Bedeutung
VARIANT_TRUE	Der Provider gibt eine Zeilengruppe zurück, die nach ORDINAL_POSITION sortiert ist.
VARIANT_FALSE	Der Provider gibt eine Zeilengruppe zurück, die nach TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME und COLUMN_NAME sortiert ist. Dies ist der Standardwert.

Falsche URL-Syntax im Syntaxdiagramm für DB2Binder

Im Thema "Installieren des allgemeinen DB2-Treibers", ist im Syntaxdiagramm für DB2Binder die URL-Syntax für den allgemeinen DB2-JDBC-Treiber falsch definiert. Die richtige Darstellung der URL-Syntax für DB2Binder sehen Sie im folgenden Diagramm:

Syntax für DB2Binder

>>-java--com.ibm.db2.jcc.DB2Binder------------------------------>
 
>---url jdbc:db2://server-+---------+-/datenbank---------------->
                          '-:--port-'
 
>---user benutzer-id---password kennwort------------------------>
 
>--+------------------+--+-------------------------------+------>
   '--size ganze-zahl-'  '--collection objektgruppenname-'
 
>--+-------------------------------+--+-------+----------------><
   |              .-,------------. |  '--help-'
   |              V              | |
   '--tracelevel ---trace-option-+-'

Datenweiterleitung bei Clients mit DB2 Universal JDBC-Treiber

Die Funktion für automatische Clientweiterleitung in DB2 Universal Database (UDB) für Linux, UNIX und Windows ermöglicht die Wiederherstellung von Clientanwendungen, nachdem die Verbindung zum Server unterbrochen wurde, so dass die Anwendungen nach minimaler Ausfallzeit weiterarbeiten können.

Immer wenn ein Server gesperrt wird, empfängt jeder Client, der mit diesem Server verbunden ist, einen Kommunikationsfehler, der die Verbindung beendet und zu einem Anwendungsfehler führt. Wenn die Verfügbarkeit wichtig ist, sollte eine redundante Installation oder eine Funktionsübernahme eingerichtet sein. (Die Funktionsübernahme ist die Fähigkeit des Servers, bei einem Ausfall eines anderen Servers dessen Aufgaben zu übernehmen.) In jedem Fall versucht der Client mit dem DB2 Universal JDBC-Treiber, die Verbindung zu einem neuen Server oder zum ursprünglichen Server wiederherzustellen, der möglicherweise auf einem Knoten mit Funktionsübernahme aktiv ist. Wenn die Verbindung wiederhergestellt wird, empfängt die Anwendung eine SQL-Ausnahmebedingung, die ihr das Fehlschlagen der Transaktion mitteilt, die Anwendung kann jedoch mit der nächsten Transaktion fortfahren.

Einschränkungen

Die Unterstützung für die Clientweiterleitung mit dem DB2 Universal JDBC-Treiber ist nur für Verbindungen verfügbar, die die Schnittstelle javax.sql.DataSource verwenden.
Bevor eine Clientanwendung nach einem Kommunikationsausfall wiederhergestellt werden kann, muss auf dem Server die Position eines alternativen Servers angegeben werden. Der Datenbankadministrator gibt den alternativen Server mit dem Befehl UPDATE ALTERNATE SERVER FOR DATABASE an.

Vorgehensweise

Nachdem der Datenbankadministrator den alternativen Serverstandort für eine bestimmte Datenbank im Serverexemplar angegeben hat, werden die Positionen des primären und des alternativen Servers beim Verbindungsaufbau an den Client zurückgegeben. Der DB2 Universal JDBC-Treiber erstellt ein Exemplar des referenzierbaren Objekts DB2ClientRerouteServerList und speichert dieses in seinem Übergangsspeicher. Bei einem Kommunikationsausfall versucht der DB2 Universal JDBC-Treiber, die Verbindung unter Verwendung der vom Server zurückgegebenen Serverinformationen wieder herzustellen.

Das DataSource-Merkmal clientRerouteServerListJNDIName stellt auf dem Client zusätzliche Unterstützung für die Clientweiterleitung zur Verfügung; clientRerouteServerListJNDIName hat die folgenden zwei Funktionen:

Daten zu alternativen Servern können JVM-übergreifend persistent vorhanden sein.
Falls die erste Verbindung zum Datenbankserver fehlschlägt, wird die Position eines alternative Servers zur Verfügung gestellt.

clientRerouteServerListJNDIName gibt eine JNDI-Referenz zu einem DB2ClientRerouteServerList-Exemplar in einem JNDI-Repository für Daten zu alternativen Server an. Nach erfolgreicher Herstellung der Verbindung zum primären Server werden die Daten zum alternativen Server, die von clientRerouteServerListJNDIName zur Verfügung gestellt werden, mit den Daten vom Server überschrieben. Der DB2 Universal JDBC-Treiber versucht, die aktualisierten Daten nach der Funktionsübernahme an den JNDI-Speicher weiterzugeben, falls das Merkmal clientRerouteServerListJNDIName definiert ist. Wenn clientRerouteServerListJNDIName angegeben ist, werden für die Verbindung zum primären Server Informationen verwendet, die in DB2ClientRerouteServerList angegeben sind. Wenn der primäre Server nicht angegeben ist, werden die serverName-Informationen verwen- det, die auf der Datenquelle angegeben sind.

DB2ClientRerouteServerList ist eine serialisierbare JavaBean mit den folgenden vier Merkmalen:

alternateServerName
alternatePortNumber
primaryServerName
primaryPortNumber

Getter- und Setter-Methoden zum Zugriff auf diese Merkmale werden zur Verfügung gestellt. Die Definition der Klasse DB2ClientRerouteServerList lautet wie folgt:

package com.ibm.db2.jcc;
public class DB2ClientRerouteServerList 
  implements java.io.Serializable,
  javax.naming.Referenceable
{
  public String[] alternateServerName;
  public synchronized void 
    setAlternateServerName(String[] alternateServer);
  public String[] getAlternateServerName();
  public int[] alternatePortNumber;
  public synchronized void 
    setAlternatePortNumber(int[] alternatePortNumberList);
  public int[] getAlternatePortNumber();
  
  public synchronized void 
    setPrimaryServerName (String primaryServerName);
  public String getPrimaryServerName ();
  public synchronized void setPrimaryPortNumber (int primaryPortNumber)
  public int getPrimaryPortNumber (); 
}

Eine neue hergestellte Verbindung für Funktionsübernahme wird mit den ursprünglichen Datenquellenmerkmalen konfiguriert, mit Ausnahme des Servernamens und der Portnummer. Außerdem werden alle DB2 UDB-Sonderregister, die bei der ursprünglichen Verbindung modifiziert worden sind, in der Funktionsübernahmeverbindung vom DB2 Universal JDBC-Treiber wiederhergestellt.

Bei einem Kommunikationsausfall versucht der DB2 Universal JDBC-Treiber zuerst eine Wiederherstellung für den primären Server auszuführen. Sollte dies fehlschlagen, versucht der Treiber, eine Verbindung zur alternativen Position (Funktionsübernahme) herzustellen. Nachdem erneut eine Verbindung hergestellt worden ist, sendet der Treiber eine java.sql.SQLException mit dem SQLCODE-Wert -4498 an die Anwendung, wodurch der Anwendung angezeigt wird, dass automatisch eine Verbindung zum alternativen Server wiederhergestellt worden ist. Die Anwendung kann anschließend die Transaktion wiederholen.

Vorgehensweise zum persistenten Festlegen von DB2ClientRerouteServerList

Gehen Sie wie folgt vor, um Speicher so zu konfigurieren, dass DB2ClientRerouteServerList persistent festgelegt wird:

Erstellen Sie ein Exemplar von DB2ClientRerouteServerList, und binden Sie dieses Exemplar an die JNDI-Registrierdatenbank. Beispiel:

// Startkontext für Namensoperationen erstellen
InitialContext registry = new InitialContext();
// DB2ClientRerouteServerList-Objekt erstellen
DB2ClientRerouteServerList address=new DB2ClientRerouteServerList();

// Portnummer und Servernamen für primären Server setzen
address.setPrimaryPortNumber(50000);
address.setPrimaryServerName("mvs1.sj.ibm.com");

// Portnummer und Servernamen für alternativen Server setzen
int[] port = {50002};
String[] server = {"mvs3.sj.ibm.com"};
address.setAlternatePortNumber(port);
address.setAlternateServerName(server);
    
registry.rebind("serverList", address);

Ordnen Sie den JNDI-Namen des DB2ClientRerouteServerList-Objekts dem DataSource-Merkmal clientRerouteServerListJNDIName zu. Beispiel:
```
datasource.setClientRerouteServerListJNDIName("serverList");
```

Anpassen der Merkmale der DB2 Universal JDBC-Treiberkonfiguration

Über die Merkmale der DB2 Universal JDBC-Treiberkonfiguration können Sie Merkmalwerte setzen, die für den gesamten Treiber gelten. Diese Einstellungen werden anwendungsübergreifend und DataSource-Exemplar-übergreifend angewendet. Sie können die Einstellungen ändern, ohne den Anwendungsquellcode oder die DataSource-Merkmale zu ändern.

Die einzelnen Merkmaleinstellungen der DB2 Universal JDBC-Treiberkonfiguration weisen das folgende Format auf:

merkmal=wert

Wenn das Konfigurationsmerkmal mit db2.jcc.override beginnt, ist es auf alle Verbindungen anwendbar und überschreibt alle Connection- oder DataSource-Merkmale mit demselben Merkmalnamen. Wenn das Konfigurationsmerkmal mit db2.jcc oder db2.jcc.default beginnt, ist der Konfigurationsmerkmalwert ein Standardwert. Einstellungen für die Connection- oder DataSource-Merkmale überschreiben diesen Wert.

Vorgehensweise

Gehen Sie wie folgt vor, um Konfigurationsmerkmale festzulegen:

Definieren Sie die Konfigurationsmerkmale als Java-Systemmerkmale. Diese Einstellungen überschreiben alle anders lautenden Einstellungen.
Für Standalone-Java-Anwendungen können Sie die Konfigurationsmerkmale als Java-Systemmerkmale festlegen, indem Sie bei der Ausführung des Befehls java die Option -Dmerkmal=wert angeben.
Legen Sie die Konfigurationsmerkmale in einer Ressource fest, deren Namen Sie im Java-Systemmerkmal db2.jcc.propertiesFile angeben. Sie können z. B. für den Wert db2.jcc.propertiesFile einen absoluten Pfadnamen angeben.
Für Standalone-Java-Anwendungen können Sie die Konfigurationsmerkmale festlegen, indem Sie bei der Ausführung des Befehls java die Option -Ddb2.jcc.propertiesFile=pfad angeben.
Definieren Sie die Konfigurationsmerkmale in einer Ressource mit dem Namen DB2JccConfiguration.properties. Die Ressource DB2JccConfiguration.properties wird mit einer Standard-Java-Ressourcensuche gesucht. Der DB2 Universal JDBC-Treiber sucht nur nach dieser Ressource, wenn Sie das Java-Systemmerkmal db2.jcc.propertiesFile nicht gesetzt haben.
DB2JccConfiguration.properties kann eine Standalone-Datei sein oder sich in einer JAR-Datei befinden.

Wenn DB2JccConfiguration.properties eine Standalone-Datei ist, muss der Pfad für DB2JccConfiguration.properties in der CLASSPATH-Angabe enthalten sein.

Wenn DB2JccConfiguration.properties sich in einer JAR-Datei befindet, muss diese JAR-Datei in der CLASSPATH-Angabe enthalten sein.

Sie können die folgenden Konfigurationsmerkmale für DB2 Universal JDBC-Treiber festlegen. Alle Merkmale sind optional.

db2.jcc.override.traceFile

Aktiviert den DB2 Universal JDBC-Treibertrace für Java-Treibercode, und gibt den Namen an, auf dem die Tracedateinamen basieren.

Geben Sie einen vollständig qualifizierten Dateinamen als Wert des Merkmals db2.jcc.override.traceFile an.

Das Merkmal db2.jcc.override.traceFile überschreibt das Merkmal traceFile für ein Connection- oder DataSource-Objekt.

Wenn Sie z. B. die folgende Einstellung für db2.jcc.override.traceFile angeben, wird die Traceverarbeitung des Java-Codes für den DB2 Universal JDBC-Treiber in einer Datei mit dem Namen /SYSTEM/tmp/jdbctrace aufgezeichnet:

db2.jcc.override.traceFile=/SYSTEM/tmp/jdbctrace

Sie sollten die Tracemerkmale unter Anleitung der IBM Unterstützungsfunktion festlegen.

db2.jcc.sqljUncustomizedWarningOrException

Gibt die Aktion an, die der DB2 Universal JDBC-Treiber ausführt, wenn eine nicht angepasste SQLJ-Anwendung aktiv ist. db2.jcc.sqljUncustomizedWarningOrException kann die folgenden Werte aufweisen:

0: Der DB2 Universal JDBC-Treiber generiert keine Warnung oder Ausnahmebedingung, wenn eine nicht angepasste SQLJ-Anwendung aktiv ist. Dies ist der Standardwert.
1: Der DB2 Universal JDBC-Treiber generiert eine Warnung, wenn eine nicht angepasste SQLJ-Anwendung aktiv ist.
2: Der DB2 Universal JDBC-Treiber generiert eine Ausnahmebedin- gung, wenn eine nicht angepasste SQLJ-Anwendung aktiv ist.

Funktion db2secFreeToken entfernt

Die Funktion db2secFreeToken (durch Token belegten Speicher freigeben) ist nicht mehr Bestandteil der Benutzerauthentifizierungs-Plug-in-API db2secGssapiServerAuthFunctions_1.

Sorgfältiges Implementieren benutzerdefinierter Sicherheits-Plug-ins

Die Integrität der Installation von DB2 Universal Database (UDB) kann beeinträchtigt sein, wenn die Implementierung von Sicherheits-Plug-ins nicht auf geeignete Weise codiert, geprüft und getestet wird. DB2 UDB ergreift Vorsichtsmaßnahmen gegen viele allgemein auftretende Arten von Fehlern, kann jedoch keine vollständige Integrität garantieren, wenn benutzerdefinierte Sicherheits-Plug-ins implementiert werden.

Sicherheits-Plug-ins

Wenn Sie Ihr eigenes Sicherheits-Plug-in verwenden, können Sie in einer CONNECT-Anweisung, die über den Befehlszeilenprozessor (CLP) oder über eine Anweisung für dynamisches SQL abgesetzt wird, eine Benutzer-ID mit bis zu 255 Zeichen verwenden.

Sicherheits-Plug-in-APIs

Für die APIs db2secGetGroupsForUser, db2secValidatePassword und db2secGetAuthIDs kann der Eingabeparameter dbname einen Nullwert haben, und der entsprechende Eingabeparameter dbnamelen für die Länge wird auf 0 gesetzt.

Namenskonventionen für Sicherheits-Plug-ins (Linux und UNIX)

.so wird nun als Dateinamenerweiterung für benutzerdefinierte Sicherheits-Plug-in-Bibliotheken auf allen Linux- und UNIX-Plattformen akzeptiert.

Unter AIX können Sicherheits-Plug-in-Bibliotheken die Erweiterung .a oder .so aufweisen. Sollten beide Versionen der Plug-in-Bibliothek vorhanden sein, wird die Version mit der Erweiterung .a verwendet.

Unter HP-UX auf PA-RISC können Sicherheits-Plug-in-Bibliotheken die Erweiterung .sl oder .so aufweisen. Sollten beide Versionen der Plug-in-Bibliothek vorhanden sein, wird die Version mit der Erweiterung .sl verwendet.

Auf allen übrigen Linux- und UNIX-Plattformen ist .so die einzige unterstützte Dateinamenerweiterung für Sicherheits-Plug-in-Bibliotheken.

Einschränkungen für Sicherheits-Plug-in-Bibliotheken

Unter AIX können Sicherheits-Plug-in-Bibliotheken die Dateinamenerweiterung .a oder .so aufweisen. Der Mechanismus zum Laden der Plug-in-Bibliothek hängt von der verwendeten Erweiterung ab:

Plug-in/Bibliotheken mit der Dateinamenerweiterung .a

Plug-in/Bibliotheken mit der Dateinamenerweiterung .a gelten als Archive, die gemeinsam genutzte Objektelemente enthalten. Diese Elemente müssen den Namen shr.o (32 Bit) oder shr64.o (64 Bit) aufweisen. Ein einzelnes Archiv kann sowohl 32-Bit- als auch 64-Bit-Elemente enthalten, so dass es auf beiden Plattformtypen implementiert werden kann.

Beispiel für die Erzeugung einer Plug-in-Bibliothek als 32-Bit-Archiv:

  xlc_r -qmkshrobj -o shr.o MeinPlugin.c -bE:MeinPlugin.exp
  ar rv MeinPlugin.a shr.o

Plug-in/Bibliotheken mit der Dateinamenerweiterung .so

Plug-in-Bibliotheken mit der Dateinamenerweiterung .so gelten als dynamisch ladbare gemeinsam genutzte Objekte. Ein solches Objekt ist entweder ein 32-Bit- oder ein 64-Bit-Objekt, je nachdem, welche Optionen bei seiner Erzeugung zur Kompilierung und zum Binden verwendet wurden. Beispiel für die Erzeugung einer 32-Bit-Plug-in-Bibliothek:

  xlc_r -qmkshrobj -o MeinPlugin.so MeinPlugin.c -bE:MeinPlugin.exp

Auf allen Plattformen außer AIX wird angenommen, dass Sicherheits-Plug-in- Bibliotheken immer dynamisch ladbare gemeinsam genutzte Objekte sind.

GSS-API-Sicherheits-Plug-ins unterstützen keine Authentifizierung mit mehreren Tokens

Bei der GSS-API-Authentifizierung wird nur ein einziges Token vom Client an den Server und ein einziges Token vom Server an den Client gesendet. Diese Tokens werden auf dem Client von gss_init_sec_context() und auf dem Server von gss_accept_sec_context() abgerufen. Wenn GSS-API-Plug-ins versuchen, weitere Tokens zu senden, wird ein unerwarteter Fehler für Sicherheits-Plug-ins generiert, und die Verbindung schlägt fehl.

GSS-API-Sicherheits-Plug-ins unterstützen keine Nachrichtenverschlüsselung und keine Signaturen

Nachrichtenverschlüsselung und Signaturen sind in GSS-API-Sicherheits-Plug-ins nicht verfügbar.

Implizite Beendung von Transaktionen in Standalone-Anwendungen

Alle (normalen und abnormalen) Beendigungen machen, unabhängig vom Betriebssystem, ausstehende Arbeitseinheiten implizit rückgängig.

Unterstützung verteilter Transaktionen

Die Dokumentation zu neuen Funktionen für DB2 Universal Database (UDB) Version 8.2 enthält im Abschnitt zu den DB2 Universal JDBC-Treiberverbesserungen falsche Informationen zur Unterstützung von verteilten Transaktionen. Der letzte Satz dieses Abschnitts ist falsch. Richtig muss er wie folgt lauten:

Ab Version 8.2 stellt DB2 UDB Unterstützung für verteilte Transaktionsverarbei- tung bereit, die der XA-Spezifikation entspricht. Diese Unterstützung implementiert die JTS- (Java Transaction Service) und JTA-Spezifikationen (Java Transaction API) von Java 2 Platform Enterprise Edition (J2EE).

Anwendungsentwicklung: Programmieren von Serveranwendungen

Mehrere Ergebnismengen von CLR-Prozeduren

Die maximale Anzahl Ergebnismengen, die von einer CLR-Prozedur (CLR - Common Language Runtime) zurückgegeben werden können, ist beschränkt. Der Grenzwert wird von der maximalen Anzahl gleichzeitig geöffneter DB2DataReader-Objekte bestimmt, die von DB2 .NET Data Provider in einer Verbindung unterstützt werden. Die Unterstützung von gleichzeitig ablaufenden aktiven Eingabeprogrammen für Daten ermöglicht es, dass mehrere DB2DataReader-Objekte in einer Verbindung geöffnet sein können. Somit können mehrere Ergebnismengen über eine CLR-Prozedur zurückgegeben werden.

Modi zur Ausführungssteuerung von CLR-Routinen (Klausel EXECUTION CONTROL)

Als Datenbankadministrator oder Anwendungsentwickler können Sie die Baugruppen, die den externen DB2 Universal Database-Routinen zugeordnet sind, vor unerwünschtem Zugriff schützen, indem Sie die Aktionen von Routinen während der Ausführung beschränken. DB2 .NET-CLR-Routinen (Common Language Run Time) unterstützen die Angabe eines Modus zur Ausführungssteuerung, der angibt, welche Typen von Aktionen eine Routine zur Laufzeit ausführen darf. DB2 kann während der Ausführung erkennen, ob die Routine versucht, Aktionen auszuführen, die außerhalb des Bereichs des zugehörigen Modus zur Ausführungssteuerung sind; dies kann nützlich sein, wenn Sie bestimmen wollen, ob eine Baugruppe beeinträchtigt wurde.

Zum Festlegen des Modus zur Ausführungssteuerung für eine CLR-Routine geben Sie für die Routine in der Anweisung CREATE die optionale Klausel EXECUTION CONTROL an. Gültige Modi:

SAFE
FILEREAD
FILEWRITE
NETWORK
UNSAFE

Wenn Sie den Modus zur Ausführungssteuerung in einer vorhandenen CLR-Routine modifizieren möchten, führen Sie die Anweisung ALTER PROCEDURE oder ALTER FUNCTION aus.

Wenn die Klausel EXECUTION CONTROL für eine CLR-Routine nicht angegeben ist, wird die CLR-Routine standardmäßig unter Verwendung des restriktivsten Modus zur Ausführungssteuerung, im Modus SAFE, ausgeführt. Routinen, die mit diesem Modus zur Ausführungssteuerung erstellt werden, können nur auf Ressourcen zugreifen, die vom Datenbankmanager gesteuert werden. Weniger restriktive Modi zur Ausführungssteuerung lassen zu, dass eine Routine auf Dateien im lokalen Dateisystem (FILEREAD oder FILEWRITE) oder im Netzwerk zugreift. Der Modus zur Ausführungssteuerung UNSAFE gibt an, dass für das Verhalten der Routine keine Einschränkungen gelten sollen. Routinen, die mit dem Modus zur Ausführungssteuerung UNSAFE definiert sind, können Binärcode ausführen.

Diese Steuerungsmodi stellen eine Hierarchie zulässiger Aktionen dar, und ein Modus einer höheren Ebene schließt Aktionen ein, die sich in der Hierarchie unterhalb von ihm befinden. Beispiel: Der Modus zur Ausführungssteuerung NETWORK lässt zu, dass eine Routine auf Dateien im Netzwerk, auf Dateien im lokalen Dateisystem und auf Ressourcen zugreift, die vom Datenbankmanager gesteuert werden. Verwenden Sie den restriktivsten Modus zur Ausführungssteuerung, und vermeiden Sie die Verwendung des Modus UNSAFE.

Wenn DB2 UDB zur Laufzeit erkennt, dass eine CLR-Routine versucht, eine Aktion außerhalb des Geltungsbereichs seines Modus zur Ausführungssteuerung auszuführen, gibt DB2 UDB einen Fehler zurück (SQLSTATE 38501).

Die Klausel EXECUTION CONTROL kann nur für CLR-Routinen angegeben werden. Der Bereich der Anwendbarkeit der Klausel EXECUTION CONTROL ist auf die .NET-CLR-Routine selbst begrenzt und kann nicht auf andere Routinen erweitert werden, die sie möglicherweise aufruft.

Maximale DECIMAL-Genauigkeit und Anzahl Kommastellen in CLR-Routinen

Der Datentyp DECIMAL in DB2 Universal Database (UDB) wird mit einer Genauigkeit von 31 Stellen und mit 28 Kommastellen dargestellt. Der .NET-CLR-Datentyp System.Decimal ist auf eine Genauigkeit von 29 Stellen und 28 Kommastellen begrenzt. Deshalb dürfen externe DB2 UDB-CLR-Routinen höchstens den Wert (2^96)-1 zuordnen, den höchsten Wert, der mit der Genauigkeit von 29 Stellen und mit 28 Kommastellen in einer Variablen des Datentyps System.Decimal dargestellt werden kann. DB2 UDB verursacht den Laufzeitfehler (SQLSTATE 22003, SQLCODE -413), wenn eine solche Zuordnung erfolgt.

Wenn bei der Ausführung einer Anweisung zur Routinenerstellung ein Parameter mit dem Datentyp DECIMAL definiert wird, der mehr als 28 Kommastellen aufweist, verursacht DB2 UDB den Fehler (SQLSTATE 42611, SQLCODE -604).

Commands Reference

| | |

Befehl REORGCHK

Die mit dem Befehl REORGCHK verwendeten Indexstatistikformeln wurden überarbeitet. Die neuen Formeln und deren Erläuterungen müssen wie folgt lauten:

Formel F5: |
```
100 * (KEYS * (ISIZE + LEAF_REC_OVERHEAD) + (CARD - KEYS) 
|            * DUPKEYSIZE ) 
|    / ((NLEAF - NUM EMPTY LEAFS - 1) * 
|       (INDEXPAGESIZE - 96) > MIN(50, (100 - PCTFREE))
```
Dabei ist LEAF_REC_OVERHEAD = 9 und DUPKEYSIZE = 5. |
Eine Reorganisation wird empfohlen, wenn mehr als 50 Prozent des für den Index vorgesehenen Speicherbereichs frei sind, oder wenn PCTFREE auf einer Wert größer als 50 gesetzt ist und im Index mehr als PCTFREE % Speicherplatz frei ist. Diese Formel wird nur überprüft, wenn der Wert für NLEAF - NUM EMPTY LEAFS - 1 größer 0 ist. (Vom Wert für NLEAF wird 1 abgezogen, da |die letzte zugeordnete Blattseite normalerweise nicht gefüllt ist.)

Formel F6: |
```
(100 - PCTFREE) * 
|     [ Floor((100 - min(10, PCTFREE)) / 100 * (INDEXPAGESIZE - 96) 
|             / (ISIZE + NONLEAF_REC_OVERHEAD)) ** (NLEVELS - 2)] 
|     * (INDEXPAGESIZE - 96) / 
|       (KEYS * (ISIZE + LEAF_REC_OVERHEAD) 
|             + (CARD - KEYS) * DUPKEYSIZE) < 100
```
Dabei ist NONLEAF_REC_OVERHEAD = 12. |
Es wird bestimmt, ob die erneute Erstellung des Index eine Baumstruktur mit weniger Ebenen ergibt. Dazu wird die Größe des Speicherplatzes in einem Indexbaum, der eine Ebene weniger aufweist als die aktuelle Baumstruktur, mit Hilfe dieser Formel ins Verhältnis zum erforderlichen Speicherplatz gesetzt. Sollte eine Baumstruktur mit einer Ebene weniger erstellt werden können und noch PCTFREE verfügbar sein, wird eine Reorganisation empfohlen. |Die tatsächliche Anzahl Indexeinträge sollte über 90 % (bzw. 100 % - |PCTFREE) der Anzahl Einträge liegen, die ein Indexbaum mit NLEVELS - 1 bearbeiten kann (nur überprüft, wenn NLEVELS > 1).

| |

Anmerkung:

Alle Formeln basieren auf Statistikdaten. Die Statistikdaten und die Ergebnisse aus diesen Formeln sind lediglich Schätzwerte. Sie sollten dies berücksichtigen, wenn Sie die Ergebnisse von REORGCHK prüfen.

| | |

Befehl REORG INDEXES/TABLE

Reorganisiert einen Index oder eine Tabelle.

Die Option REORG INDEXES ALL FOR TABLE tabellenname reorganisiert alle Indizes, die für eine Tabelle definiert sind, indem sie die Indexdaten als unfragmentierte, physisch zusammenhängende Seiten erneut erstellt. Wenn Sie die Option CLEANUP ONLY der Indexoption angeben, wird eine Bereinigung ausgeführt, ohne die Indizes erneut zu erstellen. Wenn Sie versuchen, diesen Befehl auf Indizes für deklarierte temporäre Tabellen anzuwenden, wird der SQLSTATE-Wert 42995 zurückgegeben.

Die Option REORG TABLE tabellenname reorganisiert eine Tabelle, indem sie die Zeilen so wiederherstellt, dass fragmentierte Daten beseitigt und Daten in kompakter Form gespeichert werden. Die Reorganisation der Tabelle wird mit einer der folgenden zwei Methoden ausgeführt:

Herkömmliche Reorganisation: Ermöglicht während der ersten Phasen der Reorganisation nur begrenzten Lesezugriff auf Daten. |
Inplace-Reorganisation: Ermöglicht während der gesamten Reorganisation den Datenzugriff, ohne jedoch eine perfekte Sortierung der Daten sicherzustellen. |Die Inplace-Tabellenreorganisation ist nur für Tabellen zulässig, die Indizes des Typs 2 und keine erweiterten Indizes aufweisen. |

Bei beiden Reorganisationstypen werden die Indizes der Tabelle nach der Reorganisation der Tabelle erneut erstellt. |Beim Inplace-Verfahren wird der Index jedoch unvollständig reorganisiert, so dass Sie die Indizes möglicherweise später reorganisieren müssen, um die Indexfragmentierung zu reduzieren und Speicherbereiche von Indexobjekten freizugeben.

|Beispiel |

Bei der herkömmlichen Tabellenreorganisation (offline ausgeführter Befehl REORG TABLE), wie der Standardeinstellung in DB2 Universal Database |(UDB) Version 7, geben Sie den folgenden Befehl ein:

   db2 reorg table employee index empid allow no access indexscan
|      longlobdata

| |

Anmerkung:

In DB2 UDB Version 8 gelten andere Standardeinstellungen.

|Hinweise zur Verwendung |

DB2 UDB bietet zwei Verfahren zur Tabellenreorganisation: das herkömmliche | Verfahren und das Inplace-Verfahren. |Allgemein ist die herkömmliche Tabellenreorganisation schneller, Sie sollten diese jedoch nur anwenden, wenn die Anwendungen während der Reorganisation ohne Schreibzugriffe auf Tabellen funktionieren. |Wenn die Umgebung diese Einschränkung nicht zulässt, kann die Inplace-Reorganisation trotz ihrer geringeren Geschwindigkeit im Hintergrund ausgeführt werden, während der normale Datenzugriff fortgesetzt wird.

Die herkömmliche Tabellenreorganisation ist am schnellsten, besonders wenn Sie keine LOB- oder LONG-Daten reorganisieren müssen. |Darüber hinaus werden die Indizes nach der Tabellenreorganisation bei der erneuten Erstellung perfekt sortiert. Anwendungen mit Lesezugriff können mit Ausnahme der letzten Reorganisationsphase auf das Original der Tabelle zugreifen, da die permanente Tabelle die Spiegelkopie der Tabelle ersetzt und die Indizes erneut erstellt werden.

Die Inplace-Tabellenreorganisation ist langsamer und garantiert keine perfekt sortierten Daten. Anwendungen können jedoch während der Reorganisation auf die Tabelle zugreifen. |Darüber hinaus kann die Inplace-Tabellenreorganisation unterbrochen und später von einer beliebigen Person mit entsprechender Berechtigung fortgesetzt werden, wobei der Schema- und Tabellenname verwendet werden.

|Aktualisierte Einschränkungen |

Das Dienstprogramm REORG unterstützt keine Kurznamen.

Für deklarierte temporäre Tabellen wird der Befehl REORG TABLE nicht unterstützt.

In Sichten kann der Befehl REORG TABLE nicht verwendet werden.

Die Reorganisation einer Tabelle ist nicht kompatibel mit Bereichsclustertabellen, da der Bereich der Tabelle immer ein Cluster bleibt.

Während einer Offlinetabellenreorganisation können Sie für einen Tabellenbereich, in dem sich die Tabelle befindet, keine Onlinesicherung starten.

Während einer Onlinetabellenreorganisation einer SMS-Tabelle können Sie keine Onlinesicherung für einen Tabellenbereich starten, in dem sich die entsprechende Tabelle befindet.

Während einer Onlinetabellenreorganisation einer DMS-Tabelle können Sie eine Onlinesicherung für einen Tabellenbereich starten, in dem sich die entsprechende Tabelle befindet. Während der Abschneidephase können für die Reorganisationsoperation Wartestatus für Sperren (Lock Waits) auftreten.

Der Befehl REORG TABLE kann keinen Index verwenden, der auf einer Indexerweiterung basiert.

| | |

Befehl BACKUP DATABASE

|Hinweise zur Verwendung |

Beachten Sie die folgenden Einschränkungen:

Der Start einer Onlinesicherung eines DMS-Tabellenbereichs ist zulässig, wenn eine Tabelle innerhalb desselben Tabellenbereichs online reorganisiert wird. Während der Abschneidephase können für die Reorganisationsoperation Wartestatus für Sperren (Lock Waits) auftreten.

Der Start einer Onlinesicherung eines SMS-Tabellenbereichs ist unzulässig, wenn eine Tabelle innerhalb desselben Tabellenbereichs online reorganisiert wird. Beide Operationen erfordern eine exklusive Sperre.

Migrieren von Datenbanken

Einschränkungen

In der Dokumentation von Version 8 steht, dass keine Datenbankmigration erforderlich ist, wenn die Datenbank auf eine FixPak-Stufe von DB2 UDB Version 8 migriert wurde. Genauer gesagt ist eine Datenbankmigration zwischen FixPaks nicht erforderlich, wenn sich die Datenbank auf einer Stufe von Version 8 befindet (Version 8.1 oder 8.2 oder ein nachfolgendes FixPak). In Version 8.2 wurden Änderungen an der Verzeichnisdateistruktur der Datenbank vorgenommen, und die Migration wird automatisch ausgeführt, wenn Sie von Version 7 oder Version 8.1 zu Version 8.2 wechseln. Wenn Sie jedoch von Version 8.2 zurück zu Version 8.1 wechseln, müssen Sie db2demigdbd ausführen, um die Verzeichnisdateistruktur der Datenbank wiederherzustellen. Wenn Sie dies nicht tun, tritt bei dem Versuch, auf die Datenbank zuzugreifen, der Fehler SQL10004 auf.

db2inidb - Befehl zur Initialisierung einer Spiegeldatenbank

Setzen Sie den Befehl db2 connect to datenbank erst dann ab, wenn Sie den Befehl db2inidb datenbank as mirror abgesetzt haben.

Wenn Sie versuchen, eine Verbindung zu einer geteilten Spiegeldatenbank herzustellen, bevor diese initialisiert wurde, werden die Protokolldateien gelöscht, die für eine aktualisierende Wiederherstellung erforderlich sind.

Die Verbindung setzt die Datenbank in den Status zurück, in dem sie sich zum Zeitpunkt der Zurückstellung befand. Wenn die Datenbank zum Zeitpunkt der Zurückstellung als konsistent markiert ist, geht DB2 Universal Database davon aus, dass eine Wiederherstellung nach einem Systemabsturz nicht erforderlich ist und leert die Protokolldateien für zukünftige Verwendung. In einem solchen Fall wird bei dem Versuch, eine aktualisierende Wiederherstellung durchzuführen, ein Fehler SQL4970 generiert.

Verwendungshinweis für den Befehl db2iupdt

Wenn Sie ab Version 8.2 ein DB2 Universal Database-Exemplar mit dem Befehl db2iupdt aktualisieren, müssen Sie zuerst alle DB2-Prozesse stoppen, die für dieses Exemplar ausgeführt werden.

Neuer Parameter für den Befehl db2sqljcustomize

Für den Befehl db2sqljcustomize gibt es einen neuen Parameter.

db2sqljcustomize - DB2-SQLJ-Befehl zur Profilanpassung

-storebindoptions: Speichert die Werte von -bindoptions und -staticpositioned im serialisierten Profil. Wenn diese Werte beim Aufruf des Tools dbsqljbind nicht angegeben werden, werden die im serialisierten Profil gespeicherten Werte verwendet. Wenn die Anpassungsfunktion mit der .grp-Datei aufgerufen wird, werden die Werte in jeder einzelnen .ser-Datei gespeichert. Die gespeicherten Werte können mit dem Tool db2sqljprint angezeigt werden.

Neuer Parameter für den Befehl sqlj

Für den Befehl sqlj gibt es einen neuen Parameter.

sqlj - Befehl für DB2-SQLJ-Umsetzung

-db2optimize: Gibt an, dass das SQLJ-Umsetzungsprogramm Code für eine Verbindungskontextklasse generiert, die für DB2 Universal Database optimiert ist. Diese Option optimiert den Code für den benutzerdefinierten Kontext, jedoch nicht für den Standardkontext. Wenn Sie das SQLJ-Umsetzungsprogramm mit dieser Option ausführen, muss sich die DB2 Universal JDBC-Treiberdatei db2jcc.jar im CLASSPATH befinden, damit die generierte Java-Anwendung kompiliert werden kann.

Aktualisierungen für den Befehl zur Überwachung und Fehlerbehebung (db2pd)

Der DB2-Befehl zur Überwachung und Fehlerbehebung (db2pd) ruft Informationen aus den DB2 UDB-Speichergruppen ab. Der Systembefehl db2pd wurde wie folgt erweitert:

Neuer Parameter -hadr

Der in Version 8.2 (äquivalent zu Version 8.1 FixPak 7) eingeführte Parameter -hadr listet HADR-Informationen (High Availability Disaster Recovery) auf. Beschreibungen der einzelnen aufgelisteten Elemente finden Sie im Abschnitt zu High Availability Disaster Recovery des Handbuchs System Monitor Guide and Reference.

Neuer Parameter -utilities

Der in Version 8.2 (äquivalent zu Version 8.1 FixPak 7) eingeführte Parameter -utilities listet Informationen zu Dienstprogrammen auf. Beschreibungen der einzelnen ausgegebenen Elemente finden Sie im Abschnitt zu Dienstprogrammen des Handbuchs System Monitor Guide and Reference.

Neuer Parameter -activestatements

Der in Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) eingeführte Parameter -activestatements gibt Informationen zu aktiven Anweisungen zurück. Die folgenden Informationen wurden zurückgegeben:

AppHandl: Die Anwendungskennung, die die aktive Anweisung verwendet, einschließlich des Knotens und des Index.
UOW-ID: Für die Anwendung, die AppHandl zugeordnet ist, die Kennung der Arbeitseinheit, in der die Anweisung aktiv wurde.
StmtID: Die Anweisungs-ID in der Arbeitseinheit.
AnchID: Die ID für den Hashanker der im dynamischen Paketcache gespeicherten dynamischen SQL-Anweisungen.
StmtUID: Die ID für die im dynamischen Paketcache gespeicherte dynamische SQL-Anweisung, die im Hashanker eindeutig ist.
EffISO: Die effektive Isolationsstufe der Anweisung.
EffLockTOut: Der effektive Wert für das Zeitlimit für Sperre für die Anweisung.
EffDegree: Der effektive Grad der Parallelität der Anweisung.
StartTime: Die Zeit, zu der die Anweisung gestartet wurde.
LastRefTime: Das letzte Mal, als von einer Anwendung auf die Anweisung verwiesen wurde.

Neue Option 'wait' für den Parameter -locks

Ab Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) können Sie die Option wait mit dem Parameter -locks angeben, um nur Sperren mit einem Wartestatus sowie Sperren, auf die gewartet wird, zurückzugeben.

Vom Parameter -applications zurückgegebene neue Felder

Ab Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) gibt der Parameter -applications vier neue Felder zurück:

C-AnchID: Dieses neue Feld ist die ID für den Hashanker der im dynamischen Paketcache gespeicherten dynamischen SQL-Anweisungen für die aktuelle Anweisung. Der Wert für dieses Feld ist 0, wenn keine aktuelle Anweisung vorhanden ist. Das Feld für die aktuelle Hashanker-ID wird nur ausgefüllt, wenn die Anwendung eine auf die Anweisung bezogene Anforderung ausführt, wie z. B. eine FETCH-Anforderung für einen Cursor.
Sobald die Anforderung verarbeitet wurde, werden die Werte auf 0 gesetzt. Auch für statische SQL-Anweisungen wird der Wert auf 0 gesetzt.
C-StmtUID: Dieses neue Feld ist die eindeutige ID für die im dynamischen Paketcache gespeicherten dynamischen SQL-Anweisungen im Hashanker der aktuellen Anweisung. Der Wert für dieses Feld ist 0, wenn keine aktuelle Anweisung vorhanden ist. Das Feld für die eindeutige ID der aktuellen Anweisung wird nur ausgefüllt, wenn die Anwendung eine auf die Anweisung bezogene Anforderung ausführt. Sobald die Anforderung ausgeführt wurde, werden die Werte auf 0 gesetzt. Auch für statische SQL-Anweisungen wird der Wert auf 0 gesetzt.
L-AnchID: Dieses neue Feld ist die Hashanker-ID der im dynamischen Paketcache gespeicherten dynamischen SQL-Anweisungen für die zuletzt ausgeführte Anweisung der Anwendung. Der Wert für dieses Feld ist 0, wenn keine zuletzt ausgeführte Anweisung vorhanden ist, wie z. B. vor der Ausführung einer dynamischen SQL-Anweisung. Der Wert wird auch für statische SQL-Anweisungen auf 0 gesetzt. Die letzte Hashanker-ID wird nach der Ausführung jeder Anforderung ausgegeben und bleibt bis zum Abschluss der jeweils nächsten zugeordneten Anforderung erhalten.
L-StmtUID: Dieses neue Feld ist die eindeutige ID für die im dynamischen Paketcache gespeicherten dynamischen SQL-Anweisungen im Hashanker der zuletzt ausgeführten Anweisung der Anwendung. Der Wert für dieses Feld ist 0, wenn keine zuletzt ausgeführte Anweisung vorhanden ist oder wenn die zuletzt ausgeführte Anweisung eine statische SQL-Anweisung war. Die letzte Anweisungs-ID wird ausgegeben, nachdem die aktuelle Anforderung verarbeitet wurde, und bleibt bis zum Abschluss der nächsten Anforderung erhalten.

Aktualisierung zum Befehl SET CLIENT

Der Befehl SET CLIENT gibt Verbindungseinstellungen für den Back-End-Prozess an.

Der Befehlsparameter SYNCPOINT für diesen Befehl wird ab Version 8 ignoriert. SYNCPOINT ist jedoch aus Gründen der Abwärtskompatibilität weiterhin vorhanden.

Aktualisierung zum Befehl PRECOMPILE

Der Befehl PRECOMPILE verarbeitet eine Quellendatei eines Anwendungsprogramms, die eingebettete SQL-Anweisungen enthält. Es wird eine modifizierte Quellendatei generiert, die SQL-Aufrufe in der Hostprogrammiersprache enthält, und in der Datenbank wird standardmäßig ein Paket erstellt.

Der Befehlsparameter SYNCPOINT für diesen Befehl wird ab Version 8 ignoriert. SYNCPOINT ist jedoch aus Gründen der Abwärtskompatibilität weiterhin vorhanden.

Aktualisierung zum Befehl UPDATE HISTORY FILE

Aktualisiert die Position, den Einheitentyp oder den Kommentar in einem Verlaufsdateieintrag.

Der Befehlsparameter STATUS gibt für einen Eintrag einen neuen Status an.

In der früheren Dokumentation steht irrtümlich, dass der Befehlsparameter STATUS den Wert "I" haben kann, womit der Eintrag als inaktiv markiert wird. Gültige Werte:

A: Markiert den Eintrag als aktiv.
E: Markiert den Eintrag als abgelaufen.

Aktualisierungen zu den Befehlen EXPORT und IMPORT

Der gesamte Unterabschnitt "Erforderliche Verbindung" für die Befehle EXPORT und IMPORT lautet wie folgt:

Erforderliche Verbindung

Datenbank. Wenn das implizite Herstellen der Verbindung aktiviert ist, wird eine Verbindung zur Standarddatenbank hergestellt. Der Dienstprogrammzugriff auf Linux-, UNIX- oder Windows-Datenbankserver von Linux-, UNIX- oder Windows-Clients aus muss über eine direkte Verbindung über die Steuerkomponente, und nicht über ein DB2 Connect-Gateway oder über eine Rückschleife erfolgen.

Aktualisierung zum Befehl LOAD

Die vollständigen Informationen für den AUTOSELECT-Wert des Parameters INDEXING MODE lauten wie folgt:

INDEXING MODE

AUTOSELECT: Das Dienstprogramm LOAD wählt automatisch zwischen dem Modus REBUILD und dem Modus INCREMENTAL aus. Diese Auswahl basiert auf der Menge der geladenen Daten und auf der Tiefe der Indexbaumstruktur. Daten zur Tiefe der Indexbaumstruktur werden im Indexobjekt gespeichert. RUNSTATS ist zum Auffüllen dieser Daten nicht erforderlich. Der Standardwert für den Indexmodus lautet AUTOSELECT.

Dateitypmodifikatoren für das Dienstprogramm LOAD

Der Befehl SET INTEGRITY in der Beschreibung für den Modifikator "generatedoverride" wurde aktualisiert.

Die Beschreibung für den Modifikator "usedefaults" wurde ebenfalls aktualisiert.

Die Aktualisierungen lauten wie folgt:

Tabelle 30. Gültige Dateitypmodifikatoren für das Dienstprogramm LOAD: alle Dateiformate
Modifikator	Beschreibung
generatedoverride	Dieser Modifikator weist das Dienstprogramm LOAD an, die vom Benutzer angegebenen Daten für alle generierten Spalten in der Tabelle zu akzeptieren (entgegen den normalen Regeln für diese Spaltentypen). Dies ist zweckmäßig, wenn Sie Daten aus anderen Datenbanksystemen migrieren oder wenn Sie Daten in eine Tabelle laden, die mit der Option RECOVER DROPPED TABLE des Befehls ROLLFORWARD DATABASE wiederhergestellt wurden. Wenn dieser Modifikator verwendet wird, werden Zeilen mit keinen Daten oder mit Nulldaten für eine generierte Spalte zurückgewiesen, die keine Nullwerte enthalten darf (SQL3116W). Anmerkung: Wenn dieser Modifikator verwendet wird, wird die Tabelle in den Status für anstehende Überprüfung (CHECK PENDING) versetzt. Geben Sie nach der Ladeoperation den folgenden Befehl ein, um den Status für anstehende Überprüfung für die Tabelle aufzuheben, ohne die benutzerdefinierten Werte zu überprüfen: SET INTEGRITY FOR < tabellenname > GENERATED COLUMN IMMEDIATE UNCHECKED Geben Sie nach der Ladeoperation den folgenden Befehl ein, um den Status für anstehende Überprüfung für die Tabelle aufzuheben und dabei die Überprüfung für benutzerdefinierte Werte zu erzwingen: SET INTEGRITY FOR < tabellenname > IMMEDIATE CHECKED Diesen Modifikator können Sie weder mit dem Modifikator `generatedmissing` noch mit dem Modifikator `generatedignore` verwenden.
usedefaults	Wenn eine Quellenspalte für eine Zieltabellenspalte angegeben worden ist, diese jedoch keine Daten für mindestens ein Zeilenexemplar enthält, werden Standardwerte geladen. Beispiele für fehlende Daten: Für DEL-Dateien: Für einen Spaltenwert sind zwei Spaltenbegrenzer angegeben, die direkt benachbart (",,") oder durch eine beliebigen Anzahl von Leerzeichen (", ,") getrennt sind. Für DEL/ASC/WSF-Dateien: Eine Zeile weist nicht genügend Spalten auf oder ist für die ursprüngliche Spezifikation nicht lang genug. Anmerkung: Für ASC-Dateien gelten Spaltenwerte mit Nullwerten nicht explizit als fehlende Werte, und für solche Spalten wird kein Standardwert verwendet. Spaltenwerte mit Nullwerten werden für numerische Spalten, für Datums- und Zeitspalten sowie für Zeitmarkenspalten als Leerzeichen dargestellt, oder sie werden für eine Spalte beliebigen Typs mit dem Nullanzeiger angegeben, was bedeutet, dass die Spalte einen Nullwert enthält. Wenn diese Option nicht verwendet wird und eine Quellenspalte keine Daten für ein Zeilenexemplar enthält, wird eine der folgenden Aktionen ausgeführt: Für DEL/ASC/WSF-Dateien: Wenn die Spalte Nullwerte enthalten kann, wird ein Nullwert geladen. Wenn die Spalte keinen Nullwert enthalten kann, weist das Dienstprogramm die Zeile zurück.

Dateitypmodifikatoren für das Importdienstprogramm

Die Beschreibung zu den Modifikatoren "usedefaults" und "codepage=x" wurde wie folgt aktualisiert:

Tabelle 31. Gültige Dateitypmodifikatoren für das Importdienstprogramm: alle Dateiformate
Modifikator	Beschreibung
usedefaults	Wenn eine Quellenspalte für eine Zieltabellenspalte angegeben worden ist, diese jedoch keine Daten für mindestens ein Zeilenexemplar enthält, werden Standardwerte geladen. Beispiele für fehlende Daten: Für DEL-Dateien: Für einen Spaltenwert sind zwei Spaltenbegrenzer angegeben, die direkt benachbart (",,") oder durch eine beliebigen Anzahl von Leerzeichen (", ,") getrennt sind. Für DEL/ASC/WSF-Dateien: Eine Zeile weist nicht genügend Spalten auf oder ist für die ursprüngliche Spezifikation nicht lang genug. Anmerkung: Für ASC-Dateien gelten Spaltenwerte mit Nullwerten nicht explizit als fehlende Werte, und für solche Spalten wird kein Standardwert verwendet. Spaltenwerte mit Nullwerten werden für numerische Spalten, für Datums- und Zeitspalten sowie für Zeitmarkenspalten als Leerzeichen dargestellt, oder sie werden für eine Spalte beliebigen Typs mit dem Nullanzeiger angegeben, was bedeutet, dass die Spalte einen Nullwert enthält. Wenn diese Option nicht verwendet wird und eine Quellenspalte keine Daten für ein Zeilenexemplar enthält, wird eine der folgenden Aktionen ausgeführt: Für DEL/ASC/WSF-Dateien: Wenn die Spalte Nullwerte enthalten kann, wird ein Nullwert geladen. Wenn die Spalte keinen Nullwert enthalten kann, weist das Dienstprogramm die Zeile zurück.

Tabelle 32. Gültige Dateitypmodifikatoren für das Importdienstprogramm: ASCII-Dateiformate (ASC/DEL)
Modifikator	Beschreibung
codepage=x	x ist eine ASCII-Zeichenfolge. Der Wert wird als Codepage für die Daten in der Ausgabedatei interpretiert. Zeichendaten werden beim Import aus dieser Codepage in die Anwendungscodepage konvertiert. Es gelten die folgenden Regeln: Für reinen DBCS-Code (grafisch), gemischten DBCS-Code und für EUC sind Begrenzer auf den Bereich von x00 bis einschließlich x3F begrenzt. `nullindchar` muss Symbole angeben, die sich im Standard-ASCII-Zeichensatz zwischen den Codepunkten x20 bis einschließlich x7F befinden. Dies bezieht sich auf ASCII-Symbole und -Codepunkte. Anmerkungen: Der Modifikator `codepage` kann nicht mit dem Modifikator `lobsinfile` verwendet werden. Wenn bei der Konvertierung von der Codepage der Anwendung in die Codepage der Datenbank eine Datenerweiterung erfolgt, werden die Daten möglicherweise abgeschnitten, und es können Datenverluste auftreten.

Befehl ATTACH

Der Parameter USER des Befehls ATTACH gibt die Authentifizierungskennung an. Wenn Sie eine Verbindung zu einem DB2 Universal Database-Exemplar unter einem Windows-Betriebssystem herstellen, kann der Benutzername in einem Format angegeben werden, das mit Microsoft Windows NT Security Account Manager (SAM) kompatibel ist. Das Qualifikationsmerkmal muss ein NetBIOS-Name sein, der maximal 15 Zeichen lang ist. Beispiel: domaene\benutzer

Befehl RECOVER DATABASE

Im Abschnitt für Beispiele der Dokumentation zum Befehl RECOVER DATABASE für Version 8.2 sind Zeitmarken falsch als jjjj:mm:tt:hh:mm:ss formatiert.

Das richtige Format muss jjjj-mm-tt-hh.mm.ss lauten.

Befehl UPDATE HISTORY FILE

Der Befehl UPDATE HISTORY FILE aktualisiert die Position, den Einheitentyp, den Kommentar oder den Status in einem Verlaufsdateieintrag.

Aktualisierte Befehlssyntax

>>-UPDATE HISTORY--+-FOR--objektteil-+--WITH-------------------->
                   '-EID--eid--------'
 
>--+-LOCATION--neue-position--DEVICE TYPE--neuer-einheitentyp-+-><
   +-COMMENT--neuer-kommentar---------------------------------+
   '-STATUS--neuer-status-------------------------------------'

Aktualisierte Befehlsparameter

FOR objektteil

Gibt die Kennung für den zu aktualisierenden Verlaufseintrag an. Diese ist eine Zeitmarke mit einer optionalen Folgenummer von 001 bis 999.

Anmerkung:

Dies kann nicht zur Aktualisierung des Eintragstatus verwendet werden. Geben Sie zur Aktualisierung des Eintragstatus stattdessen eine EID an.

STATUS neuer-status

Gibt einen neuen Status für einen Eintrag an. Nur von Sicherungseinträgen kann der Status aktualisiert werden. Gültige Werte:

A: Aktiv. Die meisten Einträge sind aktiv.
I: Inaktiv. Sicherungsimages, die sich nicht mehr in der Kette für aktive Protokolldateien befinden, werden inaktiv.
E: Verfallen. Sicherungsimages, die nicht mehr erforderlich sind, weil mehr als die in NUM_DB_BACKUPS angegebene Anzahl aktiver Images vorhanden sind, werden als verfallen markiert.
D: Sicherungsimages, die nicht mehr zur Wiederherstellung verfügbar sind, müssen als gelöscht markiert werden.

db2updv8 - Befehl zur Aktualisierung der Datenbank auf die aktuelle Stufe von Version 8

Dieser Befehl aktualisiert die Systemkataloge in einer Datenbank, um die aktuelle Stufe auf die folgenden Arten zu unterstützen:

Führt neue Routinen ein, die mit dem aktuellen Datenbankmanager geliefert werden.
Katalogisiert die ODBC/CLI/JDBC-Schemaprozeduren als vertrauenswürdige Prozeduren, damit die Leistung und die Skalierbarkeit verbessert wird.
Behebt zwei typographische Fehler in den Rückgabeparametern der Tabellenfunktion SYSPROC.SNAPSHOT_QUIESCERS:
- OUIESCER_TBS_ID wurde korrigiert in QUIESCER_TBS_ID
- OUIESCER_STATE wurde korrigiert in QUIESCER_STATE
Behebt Spaltendeskriptoren von LOB-Spalten, so dass das Bit für "protokolliert" konsistent mit den Katalogtabellen ist.
Erstellt die Sicht SYSIBM.SYSREVTYPEMAPPINGS.
Aktualisiert die Sichtdefinitionen für SYSSTAT.COLUMNS und SYSSTAT.TABLES.
Aktualisiert die Spalte SYSCOLDIST.DISTCOUNT in aktualisierbar.
Aktualisiert die Spalte SYSINDEXES.TBSPACEID so, dass die Spaltenmarkierungen nicht gesetzt sind.
Korrigiert Parameterlängen von 17 Tabellenfunktionen. Eine vollständige Liste der Funktionen finden Sie unter Spaltenerweiterung für benutzerdefinierte Funktionen für Momentaufnahmen im Abschnitt Dokumentationsaktualisierungen | SQL-Verwaltungsroutinen der Veröffentlichung Release-Informationen Version 8.2.
Ändert 33 SYSPROC-Momentaufnahme-UDFs in THREADSAFE:
- SNAPSHOT_DBM
- SNAPSHOT_FCM
- SNAPSHOT_FCMNODE
- SNAPSHOT_SWITCHES
- SNAPSHOT_APPL_INFO
- SNAPSHOT_APPL
- SNAPSHOT_STATEMENT
- SNAPSHOT_LOCKWAIT
- SNAPSHOT_AGENT
- SNAPSHOT_SUBSECT
- SNAPSHOT_DATABASE
- SNAPSHOT_BP
- SNAPSHOT_LOCK
- SNAPSHOT_TABLE
- SNAPSHOT_DYN_SQL
- SNAPSHOT_TBS
- SNAPSHOT_TBS_CFG
- SNAPSHOT_QUIESCERS
- SNAPSHOT_CONTAINER
- SNAPSHOT_RANGES
- SNAPSHOT_TBREORG
- HEALTH_DBM_INFO
- HEALTH_DBM_HI
- HEALTH_DBM_HI_HIS
- HEALTH_DB_INFO
- HEALTH_DB_HI
- HEALTH_DB_HI_HIS
- HEALTH_TBS_INFO
- HEALTH_TBS_HI
- HEALTH_TBS_HI_HIS
- HEALTH_CONT_INFO
- HEALTH_CONT_HI
- HEALTH_CONT_HI_HIS

Berechtigung

SYSADM

Erforderliche Verbindung

Datenbank. Mit diesem Befehl stellen Sie automatisch eine Verbindung zur angegebenen Datenbank her.

Befehlssyntax

>>-db2updv8-- -d--datenbankname--------------------------------->
 
>--+---------------------------------+--+-----+----------------><
   '- -u--benutzer-ID-- -p--kennwort-'  '- -h-'

Befehlsparameter

-d datenbankname: Gibt den Namen der zu aktualisierenden Datenbank an.
-u benutzer-ID: Gibt die Benutzer-ID an.
-p kennwort: Gibt das Kennwort für den Benutzer an.
-h: Zeigt den Hilfetext an. Bei Angabe dieser Option werden alle übrigen Optionen ignoriert, und nur der Hilfetext wird angezeigt.

Beispiel

Nach der Installation der aktuellen Stufe (FixPak oder neue Version) können Sie den Systemkatalog in der Beispieldatenbank mit dem folgenden Befehl aktualisieren:

db2updv8 -d sample

Hinweise zur Verwendung

Dieser Befehl kann nur für eine Datenbank verwendet werden, die unter DB2 Universal Database ab Version 8.1.2 aktiv ist. Wenn der Befehl mehrmals abgesetzt wird, werden keine Fehler ausgegeben, und die einzelnen Katalogaktualisierungen werden nur einmal angewendet.
Zur Aktivierung der neuen integrierten Funktionen müssen alle Anwendungen ihre Verbindungen zur Datenbank unterbrechen, und die Datenbank muss inaktiviert werden, sofern sie zuvor aktiviert war.

Formatieren von Trapdateien (Windows)

Für die Formatierung von Trapdateien (*.TRP) steht das neue Tool db2xprt.exe zur Verfügung. Mit diesem Tool können binäre DB2 Universal Database-Trapdateien in eine lesbare ASCII-Datei umgewandelt werden. Trapdateien befinden sich stan- dardmäßig im Verzeichnis des Exemplars (DB2INSTPROF) oder im Verzeichnis für Diagnosedaten, wenn der Konfigurationsparameter DIAGPATH des Datenbankmanagers festgelegt wurde.

Berechtigung

Sie müssen über die Zugriffsberechtigung für das Verzeichnis DIAGPATH verfügen.

Befehlssyntax

>>-db2xprt--+----------+--+----+--+----+------------------------>
            +-/p--pfad-+  '-/m-'  '-/n-'
            '-/v-------'
 
>--eingabedatei--+--------------+------------------------------><
                 '-ausgabedatei-'

Befehlsparameter

/p pfad: Ein durch ein Semikolon (;) getrennter Pfad, der auf die Position(en) der Binärdateien und PDB-Dateien verweist.
/v: Zeigt die Versionsnummer an.
/m: Formatiert einen Hauptspeicherauszug zusammen mit der übrigen Trapdatei.
/n: Formatiert Daten ohne Berücksichtigung von Informationen zur Zeilennummer.
eingabedatei: Gibt die Eingabedatei an.
ausgabedatei: Gibt die Ausgabedatei an.

Versetzen von Daten

Von Export-, Import- und Ladedienstprogrammen verwendete Bindedateien

Eine neue Bindedatei mit dem Namen db2uImpInsUpdate.bnd wurde dem Importdienstprogramm mit der Standardisolationsstufe Lesestabilität (RS) hinzugefügt. Diese Bindedatei wird nur bei Verwendung der Option INSERT_UPDATE vom Importdienstprogramm verwendet. Die Optionen INSERT, REPLACE und CREATE des Importdienstprogramms verwenden immer noch die Datei db2uimpm.bnd.

Die Bindedatei db2uImpInsUpdate.bnd kann mit der Option INSERT BUF nicht gebunden werden. Der Versuch, IMPORT INSERT_UPDATE auszuführen, während db2uImpInsUpdate.bnd mit INSERT BUF gebunden wird, führt zum Fehlschlagen des Importdienstprogramms und zum Auftreten des folgenden Fehlers:

SQL3525: Die Option "INSERT_UPDATE" ist mit der Option "INSERT BUF BIND ON DB2UIMPINSUPDATE.BND" nicht kompatibel.

Verwenden von IMPORT mit gepufferten INSERT-Operationen

In Version 8.2 des Handbuchs Dienstprogramme für das Versetzen von Daten Handbuch und Referenz heißt es wie folgt:

Die Funktion der gepufferten INSERT-Operationen kann nicht zusammen mit Importoperationen verwendet werden, bei denen der Parameter INSERT_UPDATE angegeben wird. Um diese Einschränkung umzusetzen, wird eine neue Bindedatei (db2uimpm2.bnd) eingeführt.

Auf Grund der Einführung einer neuen Bindedatei sollte die Anweisung wie folgt lauten:

Die Funktion der gepufferten INSERT-Operationen kann nicht zusammen mit Importoperationen verwendet werden, bei denen der Parameter INSERT_UPDATE angegeben wird. Um diese Einschränkung umzusetzen, wird eine neue Bindedatei (db2uImpInsUpdate.bnd) eingeführt.

Verlust von Indexierungsinformationen bei Verwendung des Importdienstprogramms

Sie können das Importdienstprogramm verwenden, um eine Tabelle erneut zu erstellen, die mit dem Exportdienstprogramm gespeichert worden ist.

In Versetzen von Daten ist im Thema "Erneutes Erstellen einer exportierten Tabelle mit IMPORT" angegeben, dass Attribute der Originaltabelle nicht beibehalten werden. Außer den Attributen, die bereits dokumentiert sind, werden die folgenden Attribute nicht beibehalten:

Indexinformationen:
- INCLUDE-Spalten (falls vorhanden)
- Indexname, falls der Index ein Primärschlüsselindex ist
- Absteigende Reihenfolge, falls der Index ein Primärschlüsselindex ist (Standardwert: aufsteigende Reihenfolge)

Datenwiederherstellung und hohe Verfügbarkeit

| | |

Übersicht über das Sicherungsdienstprogramm

Beachten Sie die folgenden Einschränkungen:

Der Start einer Onlinesicherung eines DMS-Tabellenbereichs ist zulässig, wenn eine Tabelle innerhalb desselben Tabellenbereichs online reorganisiert wird. Während der Abschneidephase können für die Reorganisationsoperation Wartestatus für Sperren (Lock Waits) auftreten.

Der Start einer Onlinesicherung eines SMS-Tabellenbereichs ist unzulässig, wenn eine Tabelle innerhalb desselben Tabellenbereichs online reorganisiert wird. Beide Operationen erfordern eine exklusive Sperre.

| | |

Verwenden des Sicherungsdienstprogramms

Für das Sicherungsdienstprogramm gelten die folgenden Einschränkungen:

Die Sicherung und die Wiederherstellung eines Tabellenbereichs können nicht gleichzeitig ausgeführt werden, selbst wenn davon unterschiedliche Tabellenbereiche betroffen sind.

Wenn Sie in einer Umgebung mit partitionierten Datenbanken eine aktualisierende Wiederherstellung ausführen möchten, müssen Sie die Datenbank auf den Knoten der Knotenliste regelmäßig sichern, und Sie müssen über mindestens ein Sicherungsimage der übrigen Knoten im System verfügen (selbst der Knoten, die keine Benutzerdaten für diese Datenbank enthalten). In zwei Situationen ist das Sicherungimage einer Datenbankpartition auf einem Datenbankpartitionsserver erforderlich, der keine Benutzerdaten für die Datenbank enthält: |
- Sie haben dem Datenbanksystem nach der letzten Sicherung einen Daten- |bankpartitionsserver hinzugefügt und müssen für diesen Datenbankparti- |tionsserver eine aktualisierende Wiederherstellung durchführen.
- Die punktuelle Wiederherstellung wird verwendet. Diese erfordert, dass alle Datenbankpartitionen im System sich im Status für anstehende aktualisierende Wiederherstellung befinden.
- Onlinesicherungsoperationen für DMS-Tabellenbereiche sind mit den folgenden Operationen inkompatibel: |
  - Laden
  - Reorganisation (nur offline) (Die Onlinereorganisation einer Tabelle im gesicherten Tabellenbereich kann verwendet werden, obwohl während der Abschneidephase für die Reorganisationsoperation Wartestatus für Sperren (Lock Waits) auftreten können.)
  - Tabellenbereich löschen
  - Tabelle abschneiden
  - Index erstellen
  - Klausel NOT LOGGED INITIALLY (Verwendung in den Anweisungen CREATE TABLE und ALTER TABLE)

Übersicht über die HADR-Funktion (High Availability Disaster Recovery)

Wenn Sie die Befehle START HADR, STOP HADR oder TAKEOVER HADR ausführen, werden möglicherweise die entsprechenden Fehlercodes generiert: SQL01767N, SQL01769N oder SQL01770N mit Ursachencode 98. Der Ursachencode zeigt an, dass auf dem Server, auf dem der Befehl ausgeführt wurde, keine installierte Lizenz für HADR vorhanden ist. Installieren Sie zur Behebung dieses Fehlers mit db2licm eine gültige HADR-Lizenz, oder installieren Sie eine Serverversion, die eine gültige HADR-Lizenz einschließt.

Unterstützung für plattformübergreifende Sicherung und Wiederherstellung

DB2 Universal Database unterstützt plattformübergreifende Sicherungs- und Wiederherstellungsoperationen.

Sie können Datenbanken, die mit DB2 UDB Version 8 auf 32-Bit-Windows-Plattformen erstellt wurden, in DB2 UDB Version 8 auf 64-Bit-Windows-Plattformen wiederherstellen oder umgekehrt.

Sie können Datenbanken, die mit DB2 UDB Version 8 auf 32-Bit-Linux-x86-Plattformen erstellt wurden, in DB2 UDB Version 8 auf 64-Bit-Linux-x86-64-Plattformen oder -IA64-Plattformen wiederherstellen oder umgekehrt.

Sie können Datenbanken, die mit DB2 UDB Version 8 auf AIX-, HP-UX-, Linux PPC-, Linux zSeries-Plattformen oder auf Plattformen mit Solaris-Betriebsumge- bungen (32 oder 64 Bit) erstellt wurden, in DB2 UDB Version 8 für AIX-, HP-UX-, Linux PPC-, Linux zSeries-Plattformen oder für Plattformen mit Solaris-Betriebsumgebungen (32 oder 64 Bit) wiederherstellen.

Sicherung auf Band (Linux)

Die maximale Blockgröße für 3480- und 3490-Bandeinheiten unter Linux ist 61.440 Byte.

Tabelle 33. Maximale Blockgröße für 3480- und 3490-Bandeinheiten unter Linux
Einheit	Anschluss	Blockgrößengrenzwert	Grenzwert für DB2-Puffer (in 4 KB großen Seiten)
3480	s370	61.440	15
3490	s370	61.440	15

Tivoli Storage Manager

Wenn Sie die Befehle BACKUP DATABASE oder RESTORE DATABASE aufrufen, können Sie angeben, dass Sie die Sicherungs- oder Wiederherstellungsoperation für die Datenbank bzw. den Tabellenbereich mit dem Produkt Tivoli Storage Manager (TSM) verwalten wollen. Der erforderliche Mindeststand der TSM-Client-API ist Version 4.2.0 außer auf folgenden Systemen:

64-Bit-Solaris-Systeme, für die Version 4.2.1 der TSM-Client-API erforderlich ist.
64-Bit-Windows NT-Betriebssysteme, für die Version 5.1 der TSM-Client-API erforderlich ist.
32-Bit-Linux-iSeries- und -pSeries-Systeme, für die ein TSM-Client ab API-Version 5.1.5 erforderlich ist.
|64-Bit-Linux-iSeries- und -pSeries-Systeme, für die ein TSM-Client ab API-Version 5.3 erforderlich ist.
64-Bit-Linux auf AMD-Opteron-Systemen, für die mindestens Version 5.2.0 der TSM-Client-API erforderlich ist.
Linux für zSeries (64 Bit), für das ein TSM-Client ab API-Version 5.2.2 erforderlich ist.

Einschränkungen der Werte der HADR-Parameter für lokalen Host und lokalen Service

Wenn Sie die Werte der HADR-Parameter (High Availability Disaster Recovery) für lokalen Host und lokalen Service (HADR_LOCAL_SVC und HADR_REMOTE_SVC) angeben, während Sie einen update database configuration-Befehl vorbereiten, müssen Sie Ports angeben, die von keinem anderen Service belegt werden. Wenn die Parameter über die Linux- oder UNIX-Befehlszeile konfiguriert werden, müssen die Werte auch in der Datei /etc/services gesetzt werden.

Zusätzliche Systemvoraussetzungen für HADR (High Availability Disaster Recovery)

Wenn Sie einen Tabellenbereich in der Primärdatenbank erstellen und die Wiedergabe des Protokolls in der Bereitschaftsdatenbank fehlschlägt, weil die Behälter nicht verfügbar sind, empfängt die Primärdatenbank keine Fehlernachricht darüber, dass die Wiederhabe des Protokolls fehlgeschlagen ist.

Zur Prüfung auf Wiedergabefehler müssen Sie bei der Erstellung neuer Tabellenbereiche die Datei db2diag.log und das Verwaltungsprotokoll für die Bereitschaftsdatenbank überwachen.

Wenn eine Übernahme auftritt, ist der von Ihnen neu erstellte Tabellenbereich in der neuen Primärdatenbank nicht verfügbar. Diese Situation können Sie beheben, indem Sie den Tabellenbereich in der neuen Primärdatenbank von einem Sicherungsimage wiederherstellen.

Im folgenden Beispiel wird der Tabellenbereich MEIN_TB in der Datenbank MEINE_DB vor der Verwendung als neue Primärdatenbank wiederhergestellt:

db2 connect to meine_db
db2 list tablespaces show detail
Anmerkung:

Führen Sie den Befehl db2 list tablespaces show detail aus, um den Status aller Tabellenbereiche anzuzeigen und die Tabellenbereich-ID abzurufen, die für Schritt 5 erforderlich ist.
db2 stop hadr on database meine_db
db2 "restore database meine_db tablespace (mein_tb) online redirect"
db2 "set tablespace containers for mein_tb_ID_# ignore rollforward container operations using (path '/mein_neuer_behälterpfad/')"
db2 "restore database meine_db continue"
db2 rollforward database meine_db to end of logs and stop tablespace "(mein_tb)"
db2 start hadr on database meine_db as primary

Nicht replizierte Operationen für HADR

In der Dokumentation zu Version 8.2 steht Folgendes:

BLOBs und CLOBs werden nicht repliziert, der Speicherbereich für die BLOBs und CLOBs wird jedoch in der Bereitschaftsdatenbank zugeordnet.

Diese Aussage muss jedoch wie folgt lauten:

Nicht protokollierte BLOBs und CLOBs werden nicht repliziert, der Speicherbereich für die BLOBs und CLOBs wird jedoch in der Bereitschaftsdatenbank zugeordnet.

HADR unterstützt keine Protokolle auf unformatierten Einheiten

HADR (High Availability Disaster Recovery) unterstützt nicht die Verwendung unformatierter Ein-/Ausgabe (direkter Plattenzugriff) für Datenbankprotokolldateien. Wenn HADR mit dem Befehl START HADR gestartet wird oder wenn die Datenbank mit konfiguriertem HADR erneut gestartet wird, schlägt der zugeordnete Befehl mit der Fehlernachricht SQL1768N und Ursachencode "9" fehl.

Data Warehouse-Zentrale

| | |

Aktualisieren der Datenbankmanagerkonfiguration vor der Installation der Data Warehouse-Umsetzungsprogramme

Im Handbuch DB2 Warehouse Manager Standard Edition Installation von Version 8.2 erhalten Sie im Thema "Aktualisieren der Datenbankmanagerkonfiguration vor der Installation von Warehouse-Umsetzungsprogrammen" eine falsche Anweisung zur Aktualisierung des SDK-Pfadparameters. Sie müssen den JDK-Pfadparameter aktualisieren.

Verwenden Sie den DB2-Befehlszeilenprozessor (CLP), um die Datenbankmanagerkonfiguration für das Ziel-DB2-Exemplar zu aktualisieren, bevor Sie Data Warehouse-Umsetzungsprogramme installieren.

|Vorgehensweise |

Gehen Sie wie folgt vor, um vor der Installation von Data Warehouse-Umsetzungsprogrammen die Datenbankmanagerkonfiguration zu aktualisieren:

Setzen Sie den JDK-Pfadparameter (JDK_PATH) auf das Unterverzeichnis, in dem das JDK installiert ist: |
```
UPDATE DATABASE MANAGER CONFIGURATION USING JDK_PATH pfad
```
Dabei steht pfad für das Unterverzeichnis, in dem das JDK installiert ist. | |
Anmerkung:
|
Fügen Sie das Verzeichnis bin nicht in den JDK-Pfad ein. Wenn Sie als Ziel DB2 Universal Database Version 7.2 (oder eine ältere Version) verwenden, für die Umsetzungsprogramme installiert sind, sollten Sie nicht JDK_PATH, sondern die JDK11_PATH aktualisieren.

Setzen Sie den Parameter für die Größe des JVM-Zwischenspeichers (JAVA_ |HEAP_SZ) auf 4096: |
```
UPDATE DATABASE MANAGER CONFIGURATION USING JAVA_HEAP_SZ 4096
```

| | |

Neue Umgebungsvariable VW_NETRC in der Data Warehouse-Zentrale (UNIX)

Unter UNIX-Betriebssystemen außer Linux können Sie für die Data Warehouse-Zentrale ab Version 8.2 FixPak 10 (äquivalent zu Version 8.1 FixPak 3) die Umgebungsvariable VW_NETRC setzen. Wenn Sie die Umgebungsvariable VW_NETRC auf off setzen, können Sie die .netrc-Datei manuell verwalten. Weitere Informationen zum richtigen Format der .netrc-Datei finden Sie in der Dokumentation zu Ihrem Betriebssystem.

Durch die Ausführung gleichzeitig ablaufender, benutzerdefinierter FTP-Programme kann die .netrc-Datei beschädigt werden. Wenn Sie gleichzeitig ablaufende, benutzerdefinierte FTP-Programmschritte ausführen möchten, können Sie die Umgebungsvariable VW_NETRC auf OFF setzen (VW_NETRC=OFF). Fügen Sie diese Umgebungsvariable dem Profil Ihres Agentendämons für ferne Agenten und der Datei IWH.environment für den Standardagenten oder für den lokalen Agenten hinzu.

DB2 Data Warehouse-Zentrale erfordert eine Datenbank im Unicode-Format

Nach der Installation von DB2 Universal Database Version 8.1 FixPak 7 oder höher müssen Sie das Tool zur Verwaltung der Data Warehouse-Steuerungsdaten ausführen, um eine neue Data Warehouse-Steuerungsdatenbank im Unicode-Format zu erstellen.

Voraussetzungen

Zum Erstellen und Speichern einer Kopie der vorhandenen Data Warehouse-Steuerungsdatenbank muss Ihre Workstation über genügend Plattenspeicherplatz verfügen, um diese Kopie zu speichern, sowie zusätzlich die doppelte Menge Speicherplatz bereitstellen, die die Data Warehouse-Steuerungsdatenbank zum Speichern temporärer Dateien benötigt. Wenn die vorhandene Data Warehouse-Steuerungsdatenbank eine Größe von 10 MB hat, müssen insgesamt 30 MB Speicherplatz in demselben Exemplar verfügbar sein, in dem sich auch die vorhandene Data Warehouse-Steuerungsdatenbank befindet.

Vorgehensweise

Führen Sie zum Erstellen einer neuen Data Warehouse-Steuerungsdatenbank im Unicode-Format die folgenden Schritte aus:

Führen Sie das Tool zur Verwaltung der Data Warehouse-Steuerungsdatenbank aus:
- Unter Windows: Klicken Sie Start an, und wählen Sie Programme -> IBM DB2 -> Installations- und Konfigurationstools -> Data Warehouse-Zentrale - Steuerungsdatenbankverwaltung aus.
- Unter AIX: Führen Sie die Prozedur db2wcdbm aus.
Geben Sie den Namen der vorhandenen Data Warehouse-Steuerungsdatenbank ein. Anschließend werden Sie aufgefordert, einen neuen Warehouse-Steuerungsdatenbanknamen einzugeben. Dadurch wird eine neue Warehouse-Steuerungsdatenbank im Unicode-Format erstellt.

Definieren von DB2-Warehouse-Quellen und -Zielen

Die folgende Aktualisierung betrifft zwei Themen im Zusammenhang mit der Data Warehouse-Zentrale:

Definieren von DB2-Warehouse-Quellen
Definieren eines Warehouse-Ziels

Bei der Definition einer Warehouse-Quelle oder eines Warehouse-Ziels ist die Anzahl der zurückgegebenen Tabellen der Standardwert 250. Sie können jedoch die neue Umgebungsvariable VWS_MAX_TABLELIST verwenden, um die Anzahl der zurückgegebenen Tabellen festzulegen. Die maximale Anzahl der Tabellen, die zurückgegebenen werden können, beträgt 40 000. Diese Anzahl kann je nach Größe der Tabellennamen in der Liste auch kleiner sein. Sie sollten eine Anzahl angeben, die viel kleiner ist als 40 000.

Aktualisierungen des Lernprogramms für das Informationsmanagement

Prüfen, ob die Datenbanken DWCTBC und TBC_MD für ODBC registriert sind

In Version 8 muss die Steuerungsdatenbank TBC_MD, die im Lernprogramm verwendet wird, keine ODBC-Datenquelle des Systems sein. Die Zieldatenbank oder Datenbankquelle DWCTBC muss jedoch eine System-ODBC-Datenquelle sein.

Öffnen des Notizbuchs 'Warehouse-Quelle definieren'

Die Vorgehensweise zum Öffnen des Notizbuchs Warehouse-Quelle definieren hat sich für die relationale Quelle des Lernprogramms geändert.

Vorgehensweise

Gehen Sie wie folgt vor, um das Notizbuch Warehouse-Quelle definieren für die relationale Quelle des Lernprogramms zu öffnen:

Klicken Sie im Fenster der Data Warehouse-Zentrale mit Maustaste 2 den Ordner Warehouse-Quellen an.
Klicken Sie Definieren --> ODBC --> DB2 --> DB2-Produktfamilie an.

Das Notizbuch Warehouse-Quelle definieren wird geöffnet.

Öffnen des Notizbuchs 'Warehouse-Ziel definieren'

Die Vorgehensweise zum Öffnen des Notizbuchs Warehouse-Ziel definieren hat sich geändert.

Vorgehensweise

Gehen Sie wie folgt vor, um das Notizbuch Warehouse-Ziel definieren zu öffnen:

Klicken Sie im Fenster der Data Warehouse-Zentrale mit Maustaste 2 den Ordner Warehouse-Ziele an.
Klicken Sie Definieren --> ODBC --> DB2 --> DB2-Produktfamilie an.

Das Notizbuch Warehouse-Ziel definieren wird geöffnet.

Festlegen des Grenzwerts für die Freigabe von Warehouse-Protokolldateien

In der Protokolldatei werden Datensätze so lange gespeichert, bis ein festgelegter Additionsgrenzwert erreicht ist. Der Additionsgrenzwert beträgt standardmäßig 1000 Datensätze. In der Regel werden bei jeder Jobausführung 12 bis 15 Protokollsätze erstellt. Legen Sie den Grenzwert für die Freigabe entsprechend Ihren Erfordernissen fest. Aktualisieren Sie hierzu das Feld Protokoll löschen, wenn Anzahl Einträge gleich auf der Indexzunge Server der Seite mit den Warehouse-Merkmalen.

Unterstützung der Data Warehouse-Zentrale für cursorbasiertes Laden

Der DB2 Universal Database-Ladeschritt ermöglicht jetzt die Verwendung einer Sicht oder Tabelle als Quelle für den Schritt, was cursorbasiertes Laden zur Folge hat.

Der Radioknopf Spalten gemäß den in der Eingabedatei vorhandenen Spaltenpositionen zuordnen muss ausgewählt sein, damit im Assistenten Spalten für cursorbasiertes Laden zugeordnet werden können.

Migration auf und Einschränkungen der Unicode-Warehouse-Steuerungsdatenbank

Ab Version 8.2 der Data Warehouse-Zentrale muss es sich bei der Warehouse-Steuerungsdatenbank um eine Unicode-Datenbank handeln. Auch wenn Sie eine Unicode-Warehouse-Steuerungsdatenbank einer Version der Data Warehouse-Zentrale vor Version 8.2 verwenden, müssen Sie eine neue Unicode-Steuerungsdatenbank mit dem Tool zur Verwaltung der Warehouse-Steuerungsdatenbank erstellen.

Wenn Sie eine Warehouse-Steuerungsdatenbank von einer Version der Data Warehouse-Zentrale vor Version 8.2 migrieren, führt das Tool zur Verwaltung der Steuerungsdatenbank der Data Warehouse-Zentrale den Befehl db2move aus, um die Daten in eine neue Unicode-Steuerungsdatenbank zu versetzen. Während dieses Prozesses werden Fenster angezeigt, die den Fortschritt des Befehls db2move zeigen. Dieses Migrationsverfahren wird nur einmal ausgeführt.

Die Data Warehouse-Zentrale unterstützt Unicode auf Sybase-Servern nicht.

Änderung des Datumsformats für die Spalte 'Modifiziert'

In der Detailsicht des Hauptfensters der Data Warehouse-Zentrale wurde das Datumsformat in der Spalte Modifiziert aktualisiert. Das Datum in der Spalte Modifiziert wird im Format für die Ländereinstellung angezeigt und umfasst die Uhrzeit. Diese Änderung des Datumsformats stellt sicher, dass das Sortieren von Objekten in der Spalte Modifiziert richtig ausgeführt wird. Diese Aktualisierung gilt für die meisten Listen mit Objekten der Data Warehouse-Zentrale, die in der Navigations- und Detailsicht angezeigt werden. Beispiel:

Themen
Prozesse
Warehouse-Schemata
Warehouse-Agentensites
Programme
Schritte
Datenressourcen
Benutzer
Benutzergruppen

Definieren von statistischen Umsetzungsprogrammen in der Data Warehouse-Zentrale

Definieren Sie zum Ausführen einer statistischen Umsetzung Ihrer Daten das statistische Umsetzungsprogramm, das Sie verwenden wollen.

Vorgehensweise

Gehen Sie wie folgt vor, um statistische Umsetzungsprogramme zu definieren:

Öffnen Sie das Fenster Prozessmodell.
Klicken Sie das Umsetzungsprogrammsymbol an, und wählen Sie ein Umsetzungsprogramm aus der Liste der verfügbaren Umsetzungsprogramme aus.
Verbinden ("Linken") Sie das ausgewählte Umsetzungsprogramm mit einer Warehouse-Quelle und einem Warehouse-Ziel entsprechend der Regeln für dieses Umsetzungsprogramm.

Für jedes Umsetzungsprogramm gibt es eigene Regeln für die Verbindung mit einer Warehouse-Quelle und einem Warehouse-Ziel. Weitere Informationen finden Sie in der Dokumentation für die einzelnen Umsetzungsprogramme.

Voraussetzungen für den iSeries-Warehouse-Agenten

Für die Verwendung eines iSeries-Warehouse-Agenten für DB2 Warehouse Manager auf Systemen mit Version 5 Release 2 bzw. 3 ist die folgende vorläufige Programmkorrektur (PTF) erforderlich:

PTF SI13558

Mit dieser vorläufigen Programmkorrektur für Datenbanken kann die CLI auf iSeries Unicode-Daten verarbeiten.

DB2 .NET Data Provider

Unterstützung von gleichzeitig ablaufenden aktiven Eingabeprogrammen für Daten

DB2 .NET Data Provider unterstützt jetzt die Verwendung von gleichzeitig ablaufenden aktiven Eingabeprogrammen für Daten. Dies bedeutet, dass Sie gleichzeitig auf Daten von mehreren DB2DataReader-Exemplaren zugreifen können, die dasselbe DB2Connection-Exemplar verwenden. Jedes DB2DataReader-Exemplar muss seinem eigenen DB2Command-Exemplar zugeordnet sein. Wenn Sie das zugeordnete DB2Command-Exemplar zu einem anderen Zweck verwenden möchten, müssen Sie explizit die Methode DB2DataReader.Close aufrufen.

Merkmal DB2Connection.ConnectionString

Es gibt ein Zusatzschlüsselwort für das Merkmal DB2Connection.ConnectionString:

CurrentSchema: Das Schema, das nach einer erfolgreichen Verbindungsherstellung verwendet werden soll. Bei einer erfolgreichen Verbindungsherstellung wird eine Anweisung SET CURRENT SCHEMA an den DB2-Server gesendet. Dadurch kann die Anwendung SQL-Objekte benennen, ohne sie mit einem Schemanamen qualifizieren zu müssen.

DB2 Connect

Änderung der Festlegung des Authentifizierungstyps über ein Gateway

Ab DB2 Connect^(TM) Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) ist das Gateway während der Authentifizierungsfestlegung kein passiver Teilnehmer mehr. Stattdessen übernimmt das Gateway eine aktive Rolle. Der Authentifizierungstyp, der im Datenbankverzeichniseintrag am Gateway angegeben wurde, überschreibt den Authentifizierungstyp, der auf dem Client katalogisiert wurde. Sowohl der Client als auch das Gateway und der Server müssen kompatible Typen angeben. Wenn der katalogisierte Authentifizierungstyp am Gateway nicht im Datenbank- verzeichniseintrag angegeben wurde, wird vom Server standardmäßig die SER- VER-Authentifizierung verwendet. Die Festlegung wird jedoch auch zwischen dem Client und dem Server vorgenommen, wenn der Server die SERVER-Authentifizierung nicht unterstützt. Dieses Verhalten weicht vom Verhalten des Clients ab, der standardmäßig den Wert SERVER_ENCRYPT verwendet, wenn kein Authentifizierungstyp angegeben wurde.

Der Authentifizierungstyp, der am Gateway katalogisiert wurde, wird nicht verwendet, wenn die Option DB2NODE oder SQL_CONNECT_NODE der SET CLIENT-API auf dem Client gesetzt wurde. In diesen Fällen erfolgt die Festlegung ausschließlich zwischen dem Client und dem Server.

Ein Server, für den der Authentifizierungstyp SERVER_ENCRYPT in der Daten- bankmanagerkonfiguration angegeben wurde, akzeptiert keine Verbindungen oder Anhänge von Clients mehr, die die SERVER-Authentifizierung anfordern.

Neues Sicherheitsszenario

Es wurde ein neues Sicherheitsszenario für APPC-Verbindungen hinzugefügt:

Authentifizierung: GSSPLUGIN
Sicherheit: NONE
Gültigkeitsprüfung: Mechanismus mit GSS-API-Sicherheits-Plug-in

Korrekturen an Abbildungen

In den folgenden DB2 Connect Enterprise Edition-Themen sind fehlerhafte Abbildungen enthalten:

Zugreifen auf Host- oder iSeries-DB2-Daten über DB2 Connect Enterprise Edition
Zugreifen auf DB2-Daten über das Web mit Java

Die folgende Tabelle zeigt Korrekturen für Abbildungen im Thema "Zugreifen auf Host- oder iSeries-DB2-Daten über DB2 Connect Enterprise Edition".

Tabelle 34. Korrekturen für Abbildungen im Thema "Zugreifen auf Host- oder iSeries-DB2-Daten über DB2 Connect Enterprise Edition"
Position innerhalb des Themas	Korrektur
Legende für alle vier Abbildungen	Verweise auf DB2 für OS/390 Version 5 Release 1" sollten "DB2 für OS/390 Version 6 oder höher" lauten. Verweise auf "DB2 für AS/400 Version 4 Release 2" sollten "DB2 für iSeries Version 5 Release 1 oder höher" lauten.
Erste Abbildung (Abbildung 1: DB2 Connect Enterprise Edition)	Alle Verweise auf "APPC" und "SNA-Kommunikationsunterstützung" sind inkorrekt. SNA/APPC wird von DB2-Servern unter Linux, Unix und Windows, einschließlich DB2 Connect Enterprise Edition, nicht als eingehendes Protokoll für DB2 Runtime Client unterstützt.

Die folgende Tabelle zeigt Korrekturen für Abbildungen im Thema "Zugreifen auf DB2-Daten über das Web mit Java".

Tabelle 35. Korrekturen für Abbildungen im Thema "Zugreifen auf DB2-Daten über das Web mit Java"
Position innerhalb des Themas	Korrektur
Legende	Verweise auf DB2 für OS/390 Version 5 Release 1" sollten "DB2 für OS/390 Version 6 oder höher" lauten. Verweise auf "DB2 für AS/400 Version 4 Release 2" sollten "DB2 für iSeries Version 5 Release 1 oder höher" lauten.

Entwicklungszentrale

DB2-Entwicklungszentrale Version 8.2 erfordert Stufe 9.2.9 von Distributed Debugger

Die DB2-Entwicklungszentrale Version 8.2 erfordert jetzt Version 9.2.9 von IBM Distributed Debugger. Wenn Sie Distributed Debugger Version 9.2.9 nicht installiert haben, können Sie Fehler in gespeicherten Java-Prozeduren nicht mit Hilfe der Entwicklungszentrale beheben.

Distributed Debugger Version 9.2.9 unterstützt keine Solaris-Betriebsumgebungen mehr.

Weitere Informationen zu Distributed Debugger finden Sie im Internet unter http://www.ibm.com/software/awdtools/debugger.

Längenbeschränkung im Fenster 'Variablenbereich ändern' der DB2-Entwicklungszentrale

Wenn Sie die Länge einer Variablen mit Hilfe des Dialogs 'Variablenbereich ändern' in der DB2-Entwicklungszentrale ändern, beträgt die maximale Länge 1024 Byte. Diese Begrenzung wird zurzeit in einer Nachricht dokumentiert, die nur auf englisch vorliegt.

Einschränkungen für DB2 Universal Driver Typ 2 und 4

In Version 8.2 wurde Unterstützung dafür hinzugefügt, dass Benutzer über die Entwicklungszentrale eine Verbindung zu einer DB2 Universal Database-Datenbank mit DB2 Universal Driver Typ 2 und 4 herstellen können. Wenn Sie jedoch versuchen, einen dieser Treiber zu verwenden, um eine Verbindung zu einem iSeries-Server oder zu einem DB2 UDB-Server von Version 8.1 oder früher herzustellen, wird folgende Fehlernachricht angezeigt:

Verbindung zu <datenbank> ist fehlgeschlagen. 
IBM DB2 Universal Driver (JCC) wurde nicht gefunden.

Weitere Informationen dazu, welche Treiber Sie verwenden sollten, um diesen Fehler zu vermeiden, finden Sie im Thema "JDBC-Treiber" von DB2 Information - Unterstützung.

GUI-Tools

Modifizieren des Abschlusszeichens für die Anweisung

Ab DB2 Universal Database (UDB) Version 8.2 FixPak 1 (äquivalent zu Version 8.1 FixPak 8) können Sie das Abschlusszeichen für die Anweisung innerhalb einer Prozedur modifizieren, die vom Befehlszeilenprozessor (CLP) oder vom Befehlseditor ausgeführt wird. Dieses Modifizieren während der Verarbeitung ähnelt der momentan in DB2 UDB für OS/390 verfügbaren Methode. Im folgenden Beispiel wird veranschaulicht, wie das Abschlusszeichen nach den einzelnen Anweisungen geändert werden kann:

   connect to gilroy user newton using password;
   select * from newton.department;
   --#SET TERMINATOR :
   select * from newton.employee:
   --#SET TERMINATOR @
   select * from newton.department@
   --#SET TERMINATOR ;
   select * from newton.department;
   --#SET TERMINATOR &
   terminate&

Die Möglichkeit, das Abschlusszeichen zu ändern, ist von Bedeutung, wenn eine Prozedur zusammengesetzte Anweisungen enthält. Im folgenden Beispiel geht DB2 UDB davon aus, dass der erste Strichpunkt ; in der zusammengesetzten Anweisung CREATE TRIGGER das Abschlusszeichen für die gesamte Anweisung CREATE TRIGGER ist. Dies trifft jedoch nicht zu. Es soll lediglich das Abschlusszeichen für eine der Anweisungen innerhalb der zusammengesetzten Anweisung CREATE TRIGGER sein.

  
CONNECT TO SAMPLE;
   DROP TRIGGER newton.NWTTRIGGER;
   CREATE TRIGGER newton.NWTTRIGGER AFTER DELETE 
   ON newton.NWTTABLE FOR EACH ROW MODE DB2SQL 
      BEGIN ATOMIC
      insert into newton.nwttable values(0,'0');
      insert into newton.nwttable values( -1, '-1');
   END;
   CONNECT RESET;
   TERMINATE;

Im folgenden Beispiel wird veranschaulicht, wie das Abschlusszeichen für Anweisungen innerhalb der Prozedur modifiziert werden kann, um das gewünschte Ergebnis zu erzielen.

   CONNECT TO SAMPLE;
   DROP TRIGGER newton.NWTTRIGGER;
   --#SET TERMINATOR @
   CREATE TRIGGER newton.NWTTRIGGER AFTER DELETE 
   ON newton.NWTTABLE FOR EACH ROW MODE DB2SQL 
      BEGIN ATOMIC
      insert into newton.nwttable values(0,'0');
      insert into newton.nwttable values( -1, '-1');
   END@
   --#SET TERMINATOR ;
   CONNECT RESET;

Wenn Sie Ihre Prozeduren nicht lokal unter DB2 für OS/390 ausführen möchten oder wenn die DB2 UDB-Prozeduren keine Verbindung zu OS/390 herstellen, sollten Sie zum Modifizieren von Abschlusszeichen für Anweisungen nicht die Methode mit --#SET TERMINATOR verwenden. Stattdessen sollten Sie die vorhandenen Optionen -tdX oder ;-- verwenden.

Mit der Option -tdX können Sie das Abschlusszeichen angeben, wenn Sie eine Prozedur unter Verwendung eines CLP-Befehls aufrufen. Das Zeichen 'X' steht für das als Abschlusszeichen für Anweisungen zu verwendende Zeichen. Dies sehen Sie z. B. im folgenden Befehl:

   db2 -tvf test.txt -td&

Das Zeichen & wird als Abschlusszeichen für Anweisungen verwendet, wenn die Prozedur in der Datei test.txt ausgeführt wird. Wenn diese Prozedur die zusammengesetzte Anweisung CREATE TRIGGER enthält, wird diese wie folgt geschrieben:

   CONNECT TO SAMPLE&
   DROP TRIGGER newton.NWTTRIGGER&
   CREATE TRIGGER newton.NWTTRIGGER AFTER DELETE 
   ON newton.NWTTABLE FOR EACH ROW MODE DB2SQL 
      BEGIN ATOMIC
      insert into newton.nwttable values(0,'0');
      insert into newton.nwttable values( -1, '-1');
   END&
   CONNECT RESET&
   TERMINATE&

Anmerkung:

Die Option -tdX ist im Befehlseditor nicht verfügbar.

Die Prozedur, die die zusammengesetzte Anweisung CREATE TRIGGER enthält, kann auch mit der Option ;-- auf andere Weise wie folgt geschrieben werden:

   CONNECT TO SAMPLE;
   DROP TRIGGER newton.NWTTRIGGER;
   CREATE TRIGGER newton.NWTTRIGGER AFTER DELETE 
   ON newton.NWTTABLE FOR EACH ROW MODE DB2SQL 
      BEGIN ATOMIC
      insert into newton.nwttable values(0,'0');--
      insert into newton.nwttable values( -1, '-1');--
   END;
   CONNECT RESET;
   TERMINATE;

Nicht verfügbarer Datenbankstatus im Teilfenster mit Datenbankdetails der Steuerzentrale

Sie können das Detailteilfenster der Steuerzentrale verwenden, um Informationen zu Ihren Datenbanken anzuzeigen. Durch Auswählen einer Datenbank in der Objektbaumstruktur oder dem Inhaltsteilfenster wird eine Zusammenfassung ihres Status angezeigt. In manchen Situationen sind Datenbankinformationen möglicherweise nicht verfügbar. Einige Ursachen für die Nichtverfügbarkeit werden in der folgenden Tabelle beschrieben.

Tabelle 36. Ursachen für einen nicht verfügbaren Datenbankstatus
Datenbankstatuselement	Mögliche Ursachen für nicht verfügbaren Status
Letzte Sicherung	Es wurden keine Sicherungen für die Datenbank ausgeführt. Der Benutzer verfügt nicht über die Berechtigung zum Zugriff auf diese Informationen.
Datenbankgröße	Die Datenbankversion ist älter als Version 8.2. Der Benutzer verfügt nicht über die Berechtigung zum Zugriff auf diese Informationen.
Kapazität	Die Datenbankversion ist älter als Version 8.2. Die Datenbank hat mehrere Partitionen. Der Benutzer verfügt nicht über die Berechtigung zum Zugriff auf diese Informationen.
Ordnungsgemäßer Betrieb	Diagnosemonitor ist nicht aktiviert. Zeitverzögerung. Es gibt eine ungefähr 5-minütige Verzögerung von dem Zeitpunkt, zu dem eine Datenbank aktiviert wird, bis zur Verfügbarkeit ihres Diagnosestatus.
Verwaltung	Die Datenbankversion ist älter als Version 8.2.

Generierung der Standardausgabeoption für das Schreiben in die Tabelle (Ereignismonitor erstellen)

Dem Dialog Ausgabeoptionen, der über das Fenster Ereignismonitor erstellen gestartet wird, wurde ein Knopf Generieren hinzugefügt. Durch Anklicken des Knopfs Generieren wird die Standardausgabeoption für das Schreiben in die Tabelle generiert. Diese Ausgabe entspricht der Syntax, die vom Befehl db2evtbl generiert wird.

Die generierte Option zeigt dem Benutzer, welche Tabellen und Datenelemente eingeschlossen werden, wenn der Ereignismonitor erstellt wird. Benutzer können den Befehl entsprechend ihren Anforderungen modifizieren.

Die generierte Syntax basiert auf dem Ereignismonitornamen und den Ereignistypen, die im Fenster Ereignismonitor erstellen angegeben wurden. Geben Sie den Ereignismonitornamen und die Ereignistypen an, bevor Sie die Ausgabeoptionssyntax generieren.

Wenn sich der Ereignismonitorname oder die Ereignistypen nach der Generierung der Ausgabeoption ändern, wird eine Nachricht angezeigt, um den Benutzer daran zu erinnern, die Ausgabeoption vor der Erstellung des Ereignismonitors erneut zu generieren. Wenn die Ausgabeoption nicht erneut generiert wird, werden Ereignistabellen basierend auf dem Ereignismonitornamen generiert, der zuvor angegeben wurde.

Informationskatalogzentrale

Beispielkonfigurationsprozeduren

Die Beispielprozeduren ICCConfig.jacl und ICCConfig.properties werden mit der Informationskatalogzentrale für das Web mit DB2 Embedded Application Server (integrierter Anwendungsserver von DB2) zur Verfügung gestellt. Sie können diese Beispielprozeduren verwenden, um die Informationskatalogzentrale für das Web mit WebSphere Application Server 5 zu konfigurieren. Diese Prozeduren befinden sich im Verzeichnis sqllib\samples\icweb.

Web-Server-Konfiguration

Wenn Ihre Metadaten beim Konfigurieren der Informationskatalogzentrale für das Web mit DB2 Embedded Application Server URLs enthalten, die auf Dateien auf dem Server zugreifen, müssen Sie die URLs der richtigen Position zuordnen, indem Sie Aliasnamen in der Web-Server-Konfiguration verwenden. Sie müssen auch die Hilfe- und Copyright-Links zuordnen. Wenn Sie DB2 Embedded Application Server verwenden, muss ein Web-Server richtig konfiguriert und aktiv sein, damit diese Links funktionieren, obwohl Sie keinen Web-Server verwenden müssen.

Installation und Konfiguration Ergänzung

| | |

DB2-Knotenkonfigurationsdatei db2nodes.cfg

Der Parameter resourcesetname wird nur unter AIX, HP-UX und Linux sowie in der Solaris-Betriebsumgebung unterstützt.

Unter Linux-Betriebssystemen definiert die Spalte resourcesetname eine Zahl, die einem NUMA-Knoten (Non-Uniform Memory Access) auf dem System entspricht. Das Systemdienstprogramm numactl muss zusätzlich zum Kernel der Version 2.6 mit NUMA-Richtilinienunterstützung verfügbar sein. Weitere Informationen zur NUMA-Unterstützung unter Linux-Betriebssystemen finden Sie in der Man-Page zu numact1.

|Beispiel für die Verwendung des Parameters "resourcesetname" unter Linux-Betriebssystemen |

Dieses Beispiel zeigt, wie Sie einen NUMA-Computer mit vier Knoten so konfigurieren können, dass jeder logische Knoten einem NUMA-Knoten zugeordnet ist.

|Vorgehensweise |

Stellen Sie sicher, dass auf dem System NUMA-Funktionalität vorhanden ist.

Setzen Sie den folgenden Befehl ab: |

$ numactl --hardware

Es wird eine der folgenden Ausgabe ähnliche Ausgabe angezeigt: |

Verfügbar: 4 Knoten (0-3)
|Knoten 0 Größe: 1901 MB
|Knoten 0 frei: 1457 MB
|Knoten 1 Größe: 1910 MB
|Knoten 1 frei: 1841 MB
|Knoten 2 Größe: 1910 MB
|Knoten 2 frei: 1851 MB
|Knoten 3 Größe: 1905 MB
|Knoten 3 frei: 1796 MB

In diesem Beispiel gibt es auf dem System vier NUMA-Knoten. Editieren Sie die Datei db2nodes.cfg wie folgt, um jedem MLN (Multiple Logical Node) einen NUMA-Knoten auf dem System zuzuordnen: |
```
0 hostname 0 hostname 0
|1 hostname 1 hostname 1
|2 hostname 2 hostname 2
|3 hostname 3 hostname 3
```

Registrierdatenbankvariable DB2NOLIOAIO durch DB2LINUXAIO ersetzt (Linux)

Die DB2 Universal Database-Registrierdatenbankvariable DB2NOLIOAIO wird ab Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) nicht mehr unterstützt. Für Linux-Benutzer wurde die Registrierdatenbankvariable DB2NOLIOAIO durch DB2LINUXAIO ersetzt.

Führen Sie den folgenden Befehl aus, um die Unterstützung der asynchronen E/A (AIO) unter Linux zu aktivieren:
```
  db2set DB2LINUXAIO=true
```
Starten Sie DB2 UDB anschließend erneut.
Anmerkung:

Zur Verwendung von AIO müssen Benutzer libaio-0.3.98 oder eine spätere Version installieren und einen Kernel haben, der AIO unterstützt.
Führen Sie den folgenden Befehl aus, um die AIO-Unterstützung unter Linux zu inaktivieren:
```
  db2set DB2LINUXAIO=false
```
Starten Sie DB2 UDB anschließend erneut.

Anwendungsserver für DB2 UDB

Der Anwendungsserver für DB2 Universal Database unterstützt die Fernverwaltung oder gespeicherte Prozeduren nicht mehr.

Aktualisierte Themen:

Aktivieren des Anwendungsservers für DB2 UDB

Durch die Aktivierung der Datenbank werden folgende Aktionen ausgeführt:

Herstellen einer Verbindung zur angegebenen Datenbank
Erstellen und Füllen von Metadatentabellen
Aktualisieren der DBM-Konfigurationsparameter JDK_PATH und JAVA_HEAP_SZ
Installieren der Anwendung DB2 Web Services

Voraussetzung

Unter Linux müssen Sie nach der Installation des Anwendungsservers und vor dem Aktivieren des Anwendungsservers die Linux-Java-Umgebung konfigurieren. Weitere Informationen zur Konfiguration der Linux-Java-Umgebung finden Sie im Handbuch Application Development Guide: Building and Running Applications.

Vorgehensweise

Gehen Sie wie folgt vor, um den Anwendungsserver für DB2 zu aktivieren:

Melden Sie sich am DB2-Server als root unter Linux- oder UNIX-Betriebssystemen oder als Benutzer mit der Berechtigung Administrator unter Windows-Betriebssystemen an.
Führen Sie für Linux- und UNIX-basierte Betriebssysteme den folgenden Befehl aus:
```
. /pfad_des_db2-exemplars/sqllib/db2profile 
```
Dabei ist pfad_des_db2-exemplars der Pfad, in dem das DB2-Exemplar erstellt wurde.
Führen Sie einen der folgenden Befehle aus:
- Für die Betriebssysteme Linux und UNIX:
```
   installationspfad_des_anwendungsservers/bin/enable.sh 
         -db aliasname_der_datenbank 
         -user datenbankbenutzer 
         -password datenbankkennwort 
         -db2path pfad_für_sqllib 
         -instance exemplarname
         -easpath pfad_für_eas

         -fencedid abgeschirmte_benutzer-id
```
- Unter Windows-Betriebssystemen:
```
   installationspfad_des_anwendungsservers\bin\enable 
         -db aliasname_der_datenbank 
         -user datenbankbenutzer 
         -password datenbankkennwort 
         -db2path pfad_für_sqllib 
         -instance exemplarname
         -easpath pfad_für_eas
```
Dabei gilt Folgendes:
- aliasname_der_datenbank ist der Aliasname der zu aktivierenden Datenbank.
- datenbankbenutzer ist die Benutzer-ID, die beim Herstellen einer Verbindung zur Datenbank verwendet werden muss.
- datenbankkennwort ist das Kennwort, das zusammen mit der Benutzer-ID beim Herstellen der Verbindung zur Datenbank verwendet werden muss.
- pfad_für_sqllib ist der Pfad für das SQLLIB-Verzeichnis des DB2-Exemplars. Dieser Pfad wird dazu verwendet, DB2EAS mit den erforderlichen JAR-Dateien zu aktualisieren.
- exemplarname ist der Name eines DB2 UDB-Exemplars.
- pfad_für_eas ist der Pfad für den integrierten Anwendungsserver (Embedded Application Server).
- abgeschirmte_benutzer-id ist die Benutzer-ID des abgeschirmten Benutzers.

Nachdem Sie den Anwendungsserver für DB2 UDB aktiviert haben, erfolgt das Starten des Anwendungsservers automatisch.

Lokales Starten des Anwendungsservers für DB2 UDB

Der Anwendungsserver sollte mit der abgeschirmten Benutzer-ID für Systeme gestartet werden, die Web-Services in einer .NET-Umgebung erstellen oder ausschließlich XML Metadata Registry (XMR) ausführen.

Starten des Anwendungsservers für DB2 UDB über Fernzugriff

Dieser Abschnitt wurde entfernt. Der Anwendungsserver für DB2 UDB unterstützt die Fernverwaltung nicht mehr.

Lokales Stoppen des Anwendungsservers für DB2 UDB

Der Anwendungsserver sollte mit der abgeschirmten Benutzer-ID für Systeme gestoppt werden, die Web-Services in einer .NET-Umgebung erstellen oder ausschließlich XML Metadata Registry (XMR) ausführen.

Stoppen des Anwendungsservers für DB2 UDB über Fernzugriff

Dieser Abschnitt wurde entfernt. Der Anwendungsserver für DB2 UDB unterstützt die Fernverwaltung nicht mehr.

Deinstallieren des Anwendungsservers für DB2 UDB

Dieser Abschnitt wurde entfernt. Der Anwendungsserver für DB2 UDB unterstützt die Fernverwaltung nicht mehr.

DB2 Embedded Application Server-Aktivierung

Die aktivierte Datenbank eines integrierten Anwendungsservers von DB2 (Embedded Application Server) muss sich in einem 32-Bit-Exemplar befinden. Datenbanken, auf die über DB2 Embedded Application Server zugegriffen wird, können sich in 32-Bit- oder 64-Bit-Exemplaren befinden.

Implementieren von DB2-Webtools

Für Anwendungsserver, die JDK 1.4 verwenden, muss die Variable CLASSPATH nicht mehr während der Implementierung der DB2-Webtools angepasst werden. Alle Abhängigkeiten, einschließlich der für den XML-Parser und das XML-Umsetzungsprogramm, werden nun mit dem Webmodul implementiert und sollten entsprechend der J2EE-Spezifikation aus dem Verzeichnis WEB-INF\lib geladen werden. Diese Änderung betrifft zwei Informationsthemen:

Implementieren der DB2-Webtools auf WebLogic-Anwendungsservern
Implementieren der DB2-Webtools auf anderen Anwendungsservern

Aktualisierte Themen:

Implementieren der DB2-Webtools auf WebLogic-Anwendungsservern

In diesem Abschnitt wird beschrieben, wie die DB2-Webtools (einschließlich der Webbefehlszentrale und der Webdiagnosezentrale) auf BEA WebLogic 7.0 implementiert und konfiguriert werden. Diese Tools können als Webanwendungen auf einem Web-Server ausgeführt werden, um den Zugriff auf DB2-Server über Webbrowser verfügbar zu machen.

Voraussetzungen

Bevor die DB2-Webtools auf WebLogic installiert werden können, müssen die folgenden Voraussetzungen erfüllt sein:

Der BEA WebLogic 7.0-Anwendungsserver muss installiert sein.
IBM DB2 Administration Client Version 8 muss verfügbar sein.
Ein mit dem HTML 4.0-Standard kompatibler Webbrowser muss verfügbar sein.
Anmerkung:

DB2-Webtools wurden mit Netscape 4.x, Netscape 6.x, Netscape 7.x, Mozilla 1.x, Internet Explorer 5.x, Opera 6.x, Konqueror 3.x (Linux) und EudoraWeb 2.x (Palm OS) getestet. Für die Verwendung bestimmter Webbrowser, die nicht getestet wurden, müssen der Servletkonfiguration möglicherweise explizite Verweise hinzugefügt werden.

Einschränkungen

Für die Implementierung der DB2-Webtools gelten die folgenden Einschränkungen:

Mehrfache Sprach- und Codepagekonvertierungen zwischen den Mittlerservern und den DB2-Servern werden nicht unterstützt. Die Sprache des Servers wird zwar für die Anzeige verwendet, einige Zeichen werden jedoch möglicherweise falsch angezeigt.
Um die Diagnose-Alerts für Datenbanken, Tabellenbereiche und Tabellenbereichsbehälter in der Webdiagnosezentrale angezeigt zu bekommen, müssen Sie sicherstellen, dass die Datenbanken auf dem Webanwendungsserver katalogisiert sind.
Die Verwendung der Webbrowserknöpfe (Stopp, Zurück, Verlauf) wird während der Verwendung der DB2-Webtools nicht unterstützt.
Wenn Sie Netscape Navigator 4 in Verbindung mit den DB2-Webtools verwenden, wird die Browseranzeige möglicherweise nicht korrekt aktualisiert. Falls dieses Problem auftritt, können Sie die Anzeige aktualisieren, indem Sie das Fenster minimieren und danach wieder maximieren. Alternativ hierzu können Sie die Anzeige aktualisieren, indem Sie das Browserfenster hinter einem anderen Fenster verbergen und dann wieder in den Vordergrund holen.
Um Ihren eigenen Aliasnamen einem DB2 Universal Database-System, einem Exemplarknoten oder einer Datenbank zuzuordnen, müssen Sie ihn mit dem DB2-Konfigurationsassistenten oder der DB2-Steuerzentrale explizit auf dem Anwendungsserver katalogisieren.
Beim ersten Start benötigen die DB2-Webtools deutlich mehr Zeit für die Initialisierung als bei späteren Starts. Der größte Teil dieser Wartezeit wird durch den automatischen Katalogisierungsprozess verursacht. Falls Sie die automatische Katalogisierungsfunktion nicht verwenden wollen, können Sie die Wartezeit abkürzen, indem Sie die automatische Katalogisierung über die Servletkonfiguration inaktivieren.
Anmerkung:

Die Parameter der Servletkonfiguration stehen in der Implementierungsdeskriptordatei web.xml zur Verfügung. Die Parameternamen und Standardwerte ändern sich bei jedem Release. Einige Anwendungsserver lassen Änderungen an diesen Parametern zu. Diese Änderungen können entweder über die Schnittstelle des Servers oder über eine direkte Bearbeitung der Datei web.xml vorgenommen werden.
Der Ausgabepuffer (Ergebnisse) hat bei Verwendung eines Desktop- oder Laptop-Browsers eine maximale absolute Größe von 1 MB, auch wenn er für eine größere Kapazität konfiguriert wurde. Bei PDA-Webbrowsern liegt die Begrenzung bei 1 KB.
Unter Linux-, UNIX- und Windows-Betriebssystemen erkennen die DB2- Webtools automatisch alle Systeme im gleichen TCP/IP-Netzwerk wie der Anwendungsserver und katalogisieren sie. Bei Systemen im gleichen TCP/IP-Netzwerk stimmen die ersten drei Ziffern der IP-Adressen überein. Die Tools versuchen, die DB2 UDB-Systemknoten mit Hilfe des ursprünglichen fernen TCP/IP-Hostnamens zu katalogisieren. Bei Namenskonflikten ordnen die Tools einen zufällig gewählten, eindeutigen Namen zu. Alle anderen DB2-Verwal- tungsserver müssen Sie im Anwendungsserver explizit katalogisieren, wenn der Zugriff auf sie möglich sein soll. Dies gilt für alle Server, die mit TCP/IP arbeiten und sich nicht im gleichen TCP/IP-Netzwerk wie der Anwendungsserver befinden, sowie alle Server, die nicht mit TCP/IP arbeiten.
Unter Linux-, UNIX- und Windows-Betriebssystemen versuchen die DB2-Webtools automatisch, alle DB2 UDB-Exemplarknoten und -Datenbanken zu erkennen und zu katalogisieren, die sich auf den katalogisierten DB2 UDB-Systemen befinden. Es ist möglich, ein fernes Exemplar für mehrere Kommunikationsprotokolle zu konfigurieren. Infolgedessen enthält der Katalog einen separaten Knoteneintrag für jedes von einem automatisch katalogisierten Exemplar unterstützte Protokoll. Bei Namenskonflikten ordnen die Tools einen zufällig gewählten, eindeutigen Namen zu.

Vorgehensweise

Gehen Sie wie folgt vor, um die DB2-Webtools auf WebLogic-Anwendungsservern zu installieren:

Implementieren Sie die DB2-Webtools über die WebLogic-Verwaltungskonsole, indem Sie wie folgt vorgehen:
1. Starten Sie die WebLogic-Verwaltungskonsole.
2. Klicken Sie im linken Teilfenster der Anzeige die Option domain -> deployments -> Web Applications an.
3. Klicken Sie den Link Configure a new Web Application an, um die Webanwendung 'DB2-Webtools' zu installieren.
4. Durchsuchen Sie die Auflistung des Dateisystems, und suchen Sie die Datei Sqllib\tools\web\db2wa.war.
5. Klicken Sie die Option select neben dem Dateinamen db2wa.war an.
6. Wählen Sie den Server, auf dem die DB2-Webtools installiert werden sollen, aus der Liste der verfügbaren Server aus, und klicken Sie den Pfeil an, um den Server in die Liste der Zielserver zu versetzen.
  Anmerkung:
  
  Der ursprüngliche Name db2wa muss beibehalten werden, da er in den DB2-Webtools fest codiert ist.
7. Klicken Sie Configure and Deploy an.
8. Warten Sie, bis der Implementierungsstatus der Webanwendung auf dem gewünschten Server durch den Anwendungsserver aktualisiert wird. War die Implementierung erfolgreich, sollte die Nachricht Deployed=true angezeigt werden.
Rufen Sie die Webanwendung 'DB2-Webtools' unter der folgenden Adresse auf:
```
http://servername:portnummer_des_anwendungsservers/db2wa
```
Beispiel: http://servername:7001/db2wa.

Implementieren der DB2-Webtools auf anderen Anwendungsservern

In diesem Abschnitt wird beschrieben, wie die DB2-Webtools (einschließlich der Webbefehlszentrale und der Webdiagnosezentrale) auf anderen Anwendungsservern, wie beispielsweise Tomcat 4.0 oder Macromedia JRun 4.0, implementiert und konfiguriert werden. Diese Tools können als Webanwendungen auf einem Web-Server ausgeführt werden, um den Zugriff auf DB2-Server über Webbrowser verfügbar zu machen.

Voraussetzungen

Bevor die DB2-Webtools installiert werden können, müssen die folgenden Voraussetzungen erfüllt sein:

Ein Anwendungsserver, wie beispielsweise einer der folgenden, muss installiert sein:
- Tomcat 4.0 Servlet/JSP Container (http://jakarta.apache.org/tomcat/)
- Macromedia JRun 4.0
IBM DB2 Administration Client Version 8 muss verfügbar sein.
Ein mit dem HTML 4.0-Standard kompatibler Webbrowser muss verfügbar sein.

Einschränkungen

Für die Implementierung der DB2-Webtools gelten die folgenden Einschränkungen:

Mehrfache Sprach- und Codepagekonvertierungen zwischen den Mittlerservern und den DB2-Servern werden nicht unterstützt. Die Sprache des Servers entspricht zwar der Anzeige, einige Zeichen können jedoch falsch angezeigt werden.
Um die Diagnose-Alerts für Datenbanken, Tabellenbereiche und Tabellenbereichsbehälter in der Webdiagnosezentrale angezeigt zu bekommen, müssen Sie sicherstellen, dass die Datenbanken auf dem Webanwendungsserver katalogisiert sind.
Die Verwendung der Webbrowserknöpfe (Stopp, Zurück, Verlauf) wird während der Verwendung der DB2-Webtools nicht unterstützt.
Wenn Sie Netscape Navigator 4 in Verbindung mit den DB2-Webtools verwenden, wird die Browseranzeige möglicherweise nicht korrekt aktualisiert. Falls dieses Problem auftritt, können Sie die Anzeige aktualisieren, indem Sie das Fenster minimieren und danach wieder aufrufen. Alternativ hierzu können Sie die Anzeige aktualisieren, indem Sie das Browserfenster hinter einem anderen Fenster verbergen und dann wieder in den Vordergrund holen.
Um Ihren eigenen Aliasnamen einem DB2 UDB-System, einem Exemplarknoten oder einer Datenbank zuzuordnen, müssen Sie ihn mit dem DB2-Konfigurationsassistenten oder der DB2-Steuerzentrale explizit auf dem Anwendungsserver katalogisieren.
Beim ersten Start benötigen die DB2-Webtools deutlich mehr Zeit für die Initialisierung als bei späteren Starts. Der größte Teil dieser Wartezeit wird durch den automatischen Katalogisierungsprozess verursacht. Falls Sie die automatische Katalogisierungsfunktion nicht verwenden wollen, können Sie die Wartezeit abkürzen, indem Sie die automatische Katalogisierung über die Servletkonfiguration inaktivieren.
Anmerkung:

Die Parameter der Servletkonfiguration stehen in der Implementierungsdeskriptordatei web.xml zur Verfügung. Die Parameternamen und Standardwerte ändern sich bei jedem Release. Einige Anwen- dungsserver lassen Änderungen an diesen Parametern zu. Diese Änderungen können entweder über die Schnittstelle des Servers oder über eine direkte Bearbeitung der Datei web.xml vorgenommen werden.
Der Ausgabepuffer (Ergebnisse) hat bei Verwendung eines Desktop- oder Laptop-Browsers eine maximale absolute Größe von 1 MB, auch wenn er mit einem höheren Wert konfiguriert wurde. Bei PDA-Webbrowsern liegt die Begrenzung bei 1 KB.
Unter Linux-, UNIX- und Windows-Betriebssystemen erkennen die DB2- Webtools automatisch alle Systeme im gleichen TCP/IP-Netzwerk wie der Anwendungsserver und katalogisieren sie. Bei Systemen im gleichen TCP/IP-Netzwerk stimmen die ersten drei Ziffern der IP-Adressen überein. Die Tools versuchen, die DB2 UDB-Systemknoten mit Hilfe des ursprünglichen fernen TCP/IP-Hostnamens zu katalogisieren. Bei Namenskonflikten ordnen die Tools einen zufällig gewählten, eindeutigen Namen zu. Alle anderen DB2-Verwal- tungsserver müssen Sie im Anwendungsserver explizit katalogisieren, wenn der Zugriff auf sie möglich sein soll. Dies gilt für alle Server, die mit TCP/IP arbeiten und sich nicht im gleichen TCP/IP-Netzwerk wie der Anwendungsserver befinden, sowie alle Server, die nicht mit TCP/IP arbeiten.
Unter Linux-, UNIX- und Windows-Betriebssystemen versuchen die DB2-Webtools automatisch, alle DB2 UDB-Exemplarknoten und -Datenbanken zu erkennen und zu katalogisieren, die sich auf den katalogisierten DB2 UDB-Systemen befinden. Es ist möglich, ein fernes Exemplar für mehrere Kommunikationsprotokolle zu konfigurieren. Infolgedessen enthält der Katalog einen separaten Knoteneintrag für jedes von einem automatisch katalogisierten Exemplar unterstützte Protokoll. Bei Namenskonflikten ordnen die Tools einen zufällig gewählten, eindeutigen Namen zu.

Vorgehensweise

Im Folgenden wird die Vorgehensweise für die Installation der DB2-Webtools auf Anwendungsservern, wie beispielsweise Tomcat 4.0 oder Macromedia JRun 4.0, beschrieben:

Tomcat 4.0

Bereiten Sie die Konfigurationsdatei (CLASSPATH) von Tomcat 4.0 vor, indem Sie die folgenden Schritte ausführen:
1. Erstellen Sie die neue Umgebungs-/Systemvariable CATALINA_ HOME, die den Pfad (das Ausgangsverzeichnis) für Tomcat 4.0 enthält. Beispiel: D:\jakarta-tomcat-4.0.3.
2. Überprüfen Sie wie folgt, ob Tomcat Servlet/JSP Container aktiv ist:
  1. Starten Sie Tomcat, indem Sie die Datei startup.bat im Verzeichnis bin der Tomcat-Verzeichnisstruktur ausführen.
  2. Greifen Sie über einen Webbrowser auf die Hauptwebseite http://localhost:8080/ zu.
Implementieren Sie die DB2-Webtools in Tomcat Servlet/JSP Container. Lokalisieren Sie hierzu den Installationspfad für die DB2-Webtools (d. h. Sqllib\tools\web\db2wa.war), und kopieren Sie die Datei db2wa.war in das Implementierungsverzeichnis von Tomcat (d. h. das Verzeichnis webapps der Tomcat-Verzeichnisstruktur).
Rufen Sie die DB2-Webtools in Tomcat Servlet/JSP Container auf, indem Sie die folgenden Schritte ausführen:
1. Öffnen Sie ein DB2-Befehlsfenster, und wechseln Sie in das Verzeichnis bin der Tomcat-Verzeichnisstruktur.
2. Starten Sie Tomcat mit der Datei startup.bat, und stellen Sie sicher, dass ein neues Verzeichnis (db2wa) im Verzeichnis webapps erstellt wurde.
  Anmerkung:
  
  Wird die Datei startup.bat über eine Eingabeaufforderung ausgeführt, wird der Wert für DB2PATH nicht festgelegt. Die CLASSPATH-Zeile muss so geändert werden, dass sie explizit auf den DB2 UDB-Installationspfad und nicht nur auf die Umgebungsvariable %DB2PATH% verweist, um das Festlegen von DB2PATH zu ermöglichen.
3. Die Unternehmensanwendung DB2-Webtools befindet sich an der folgenden Adresse: http://localhost:8080/db2wa. Auf die DB2-Webtools kann über einen mit HTML 4.0 kompatiblen Browser zugegriffen werden.

JRun

Bereiten Sie einen neuen Anwendungsserver für die DB2-Webtools vor, indem Sie die folgenden Tasks ausführen:
Empfehlung
Das Erstellen eines neuen Anwendungsservers wird empfohlen, ist jedoch nicht obligatorisch. Zu Testzwecken kann der Standardserver verwendet werden. In diesem Fall ist es nur erforderlich, den JVM-Klassenpfad zu konfigurieren und die Webtools zu implementieren.
1. Starten Sie die JRun-Verwaltungskonsole, und melden Sie sich als Administrator des Anwendungsservers an.
2. Erstellen Sie einen neuen Anwendungsserver. Verwenden Sie hierzu die Option Create New Server im oberen rechten Bereich der Hauptseite. Ändern Sie den vorgegebenen Hostnamen localhost nicht.
3. Geben Sie den Namen des neuen Servers (DB2WebToolsServer) ein, und klicken Sie das Verzeichnis des JRun-Servers an. Der Wert wird automatisch angegeben.
4. Klicken Sie den Knopf Create Server an.
5. Notieren Sie für die folgenden Einträge die generierten Werte oder geben Sie neue Werte ein:
  - JNDI Provider URL
  - Web Server Port Number. Dies ist der Wert, der in der URL für die DB2-Webtools verwendet werden muss (d. h. http://localhost:portnummer_des_web-servers/db2wa).
  - Web Connector Proxy Port Number
6. Klicken Sie gegebenenfalls die Option update port numbers an, und schließen Sie das Fenster.
Implementieren Sie die DB2-Webtools auf dem JRun-Anwendungsserver, indem Sie die folgenden Tasks ausführen:
1. Starten Sie den Anwendungsserver, der als Host der Webanwendung DB2-Webtools verwendet werden soll (DB2WebToolsServer, Standard oder ein beliebiger anderer Server, außer dem Verwaltungsserver).
2. Klicken Sie Web Applications und anschließend Add an.
3. Durchsuchen Sie den Abschnitt Deployment File, und wählen Sie die Datei Sqllib\tools\web\db2wa.war im DB2-Installationspfad aus.
4. Klicken Sie Deploy an, und stellen Sie sicher, dass der Kontextpfad /db2wa ist.
5. Wählen Sie den Anwendungsserver aus, und stellen Sie sicher, dass die Anwendung DB2-Webtools im Abschnitt Web Applications angezeigt wird. Klicken Sie auf dieser Seite nicht die Option Apply an.
6. Wählen Sie den Link Home im oberen linken Teilfenster der Hauptseite aus.
7. Starten Sie den Anwendungsserver über die Ansicht Home, die die DB2-Webtools enthält (DB2WebToolsServer).

Die Unternehmensanwendung DB2-Webtools befindet sich unter der folgenden Adresse: http://localhost:portnummer_des_web-servers/db2wa. Auf die DB2-Webtools kann über einen mit HTML 4.0 kompatiblen Browser zugegriffen werden.

Direkte Ein-/Ausgabe auf Blockeinheiten (Linux)

Für Linux-Varianten mit einem 2.6-Kernel wird die direkte Ein-/Ausgabe (Direct I/O) jetzt auf Dateisystemen und auf Blockeinheiten unterstützt. Die direkte Ein-/Ausgabe auf Blockeinheiten ist eine Alternative zum Angeben von Einheitenbehältern für den direkten Plattenzugriff oder zur unformatierten Ein-/Ausgabe. Die Leistung der direkten Ein-/Ausgabe ist äquivalent zur Methode mit unformatierten Zeicheneinheiten. DB2 Universal Database aktiviert die direkte Ein-/Aus- gabe beim Öffnen des Tabellenbereichs, wenn die Anweisung CREATE TABLE- SPACE einen Blockeinheitennamen für den Behälterpfad angibt. Bisher wurde dieselbe Leistung durch die Methode mit unformatierter Ein-/Ausgabe erreicht, bei der die Blockeinheit mit dem Dienstprogramm raw an eine Zeicheneinheit gebunden werden musste.

Tabelle 37. Vergleich der direkten und der unformatierten Ein-/Ausgabe
Unformatierte Ein-/Ausgabe unter Verwendung einer Blockeinheit mit DIO (neue Methode)	Unformatierte Ein-/Ausgabe unter Verwendung eines Zeicheneinheitentreiber und des Dienstprogramms raw (alte Methode)
CREATE TABLESPACE dms1 MANAGED BY DATABASE USING (DEVICE '/dev/sda5' 11170736)	CREATE TABLESPACE dms1 MANAGED BY DATABASE USING (DEVICE '/dev/raw/raw1' 11170736)

Obwohl DB2 UDB weiterhin die Verwendung des Dienstprogramms raw für unformatierte Ein-/Ausgabe unterstützt, ist dies in neueren Varianten veraltet und wird in Zukunft möglicherweise ganz entfernt. Die neue Methode, bei der die Einheiten direkt angegeben werden, wird bevorzugt verwendet.

Empfehlung

Wenn Sie den direkten Plattenzugriff nutzen wollen, erstellen Sie Ihre DMS-Einheitenbehälter mit direkter Ein-/Ausgabe, um später Probleme bei der Migration zu vermeiden.

Anmerkung:

Die direkte Ein-/Ausgabe wird von DB2 UDB unter Linux/390 nicht unterstützt.

Dämon für Information - Unterstützung für DB2 (Linux und UNIX)

Der Dämon für DB2 Information - Unterstützung ist für die Steuerung des DB2-Dokumentationsservers zuständig. Der Dämon, der Teil der Installation von DB2 Information - Unterstützung ist, besteht aus zwei Dateien:

db2icd - die Initialisierungsprozedur
db2ic.conf - die Konfigurationsdatei

Diese Dateien werden an folgenden Positionen installiert:

AIX: /etc/db2icd
/var/db2/v81/db2ic.conf
HP: /sbin/init.d/db2icd
/var/opt/db2/v81/db2ic.conf
Solaris-Betriebsumgebung: /etc/init.d/db2icd
/var/db2/v81/db2ic.conf
Linux: /etc/init.d/db2icd
/var/db2/v81/db2ic.conf

Starten oder Stoppen des Dämons für 'DB2 Information - Unterstützung' (AIX, Solaris-Betriebsumgebung, HP, Linux)

Sie sollten den Dämon nur manuell starten oder stoppen müssen, wenn Sie die Konfigurationsvariablen für den Dämon ändern wollen. Normalerweise wird der Dämon beim Systemstart gestartet, entsprechend der Ausführungsebenen, die während der Installation von DB2 Information - Unterstützung erstellt wurden.

Vorgehensweise

Gehen Sie wie folgt vor, um den Dämon für DB2 Information - Unterstützung zu stoppen und zu starten:

Stoppen Sie den Dämon, wenn er bereits aktiv ist. Geben Sie in einer Befehlszeile Folgendes ein:
```
INIT_DIR/db2icd stop
```
Dabei ist INIT_DIR das Installationsverzeichnis der Datei db2icd, die oben aufgeführt wird.
Ändern Sie beliebige Variablen für den Dämon, indem Sie die Datei db2ic.conf editieren. Zurzeit können Sie die TCP-Portnummer ändern, unter der die Dokumentation verfügbar ist, und die Position des temporären Arbeitsbereichs, der von dem Dämon verwendet wird, während er aktiv ist.
Starten Sie den Dämon. Geben Sie in einer Befehlszeile Folgendes ein:
```
INIT_DIR/db2icd start
```
Dabei ist INIT_DIR das Installationsverzeichnis der Datei db2icd, die oben aufgeführt wird.

Wenn der Dämon startet, verwendet er die neuen Umgebungsvariablen.

Es gibt auch eine Option zum Beenden und unverzüglichen erneuten Starten des Dämons. Geben Sie in einer Befehlszeile Folgendes ein:

INIT_DIR/db2icd restart

Dabei ist INIT_DIR das Installationsverzeichnis der Datei db2icd, die oben aufgeführt wird.

Sie können den Status des Dämons jederzeit überprüfen. Geben Sie in einer Befehlszeile Folgendes ein:

INIT_DIR/db2icd status

Dabei ist INIT_DIR das Installationsverzeichnis der Datei db2icd, die oben aufgeführt wird. Der Dämon gibt den aktuellen Status zurück und zeigt die ID des Dämonprozesses oder der Dämonprozesse an, wenn er aktiv ist.

Schlüsselwörter und Beispieldateien für Antwortdateien

Verwenden Sie zur Installation von DB2 Information - Unterstützung Version 8.2 bei Verwendung einer Antwortdatei die folgenden Informationen:

Schlüsselwort für Antwortdateien (PROD): INFORMATION_CENTER
Name der Antwortdatei: db2doce.rsp

Fehlercodes bei der Installation der Antwortdatei

Der folgende Fehlercode ist nur für Windows- und nicht für Linux- und UNIX-Betriebssysteme gültig.

3010: Die Installation war erfolgreich. Um die Installation vollständig abzuschließen, ist jedoch ein Systemneustart erforderlich.

Erforderliche Benutzerkonten für die Installation von DB2-Servern (Windows)

Anheben einer Quote

Die Benutzerberechtigung Anheben einer Quote wurde auf den Betriebssystemen Windows XP und Windows Server 2003 in Anpassen von Speicherkontingenten für einen Prozess geändert.

Vom DB2-Installationsprogramm erteilte Benutzerberechtigungen - Debuggen von Programmen

Das DB2-Installationsprogramm erteilt die Benutzerberechtigung "Debuggen von Programmen" nicht. Das DB2-Installationsprogramm erteilt die folgenden Benutzerberechtigungen:

Als Teil des Betriebssystems handeln
Erstellen eines Tokenobjekts
Sperren von Seiten im Speicher
Anmelden als Dienst
Anheben einer Quote
Ersetzen eines Token auf Prozessebene

Unterstützung der asynchronen Ein-/Ausgabe (Linux)

Unter Linux (Kernel Version 2.6 und einige Versionen von 2.4) steht jetzt Unterstützung für asynchrone E/A (AIO) für unformatierte Einheiten und O_DIRECT-Dateisysteme zur Verfügung. AIO verbessert die Leistung der Seitenlöschfunktion. Mit dem Befehl db2set können Sie AIO unter Linux aktivieren oder inaktivieren.

Zur Verwendung von AIO müssen Benutzer libaio-0.3.98 oder eine spätere Version installieren und einen Kernel haben, der AIO unterstützt. Benutzer müssen außerdem den Befehl db2set DB2LINUXAIO=true ausführen und DB2 Universal Database erneut starten.

Geänderter Befehl db2ln zur Erstellung von DB2 UDB-64-Bit-Bibliotheksprogrammverbindungen (Linux und UNIX)

In früheren Stufen von DB2 Universal Database (UDB) Version 8 erstellte der Befehl db2ln bestimmte DB2-Programmverbindungen unter /usr/lib und /usr/include. Auf Plattformen, auf denen 32-Bit- und 64-Bit-DB2 UDB-Exemplare unterstützt werden, zeigen diese Programmverbindungen standardmäßig auf Bibliotheksdateien oder auf INCLUDE-Dateien in den Verzeichnissen DB2VERZ/lib64 oder DB2VERZ/include64. (Dabei steht DB2VERZ für das Verzeichnis, in dem DB2 UDB Version 8 installiert ist.) Wenn Sie den Standardwert nicht wünschen, können Sie die Bitbreite angeben, indem Sie den Befehl db2ln mit dem Flag -w ausführen:

db2ln -w 32|64

Dadurch wird verhindert, dass auf einigen Plattformen gleichzeitig 32-Bit-Exemplare und 64-Bit-Exemplare von DB2 UDB vorhanden sind.

Ab DB2 UDB Version 8.2 erstellt der Befehl db2ln auf diesen Plattformen in den entsprechenden Verzeichnissen DB2-64-Bit-Bibliotheksprogrammverbindungen. In diesem Fall wird das Flag -w nur zum Auffüllen von /usr/include verwendet. Wenn der Befehl db2ln die Programmverbindungen für DB2 UDB-Bibliotheksdateien erstellt, werden auf unterstützten Plattformen sowohl 32-Bit- als auch 64-Bit-Programmverbindungen erstellt. Dadurch können 32-Bit-Exemplare und 64-Bit-Exemplare vorhanden sein und gleichzeitig ausgeführt werden.

Einige Linux-Varianten enthalten den Entwickungs-RPM libc in der Bibliothek /usr/lib/libdb2.so oder /usr/lib64/libdb2.so. Diese Bibliothek wird für die Implementierung der Datenbank Berkeley DB von Sleepycat Software verwendet und ist nicht IBM DB2 UDB zugeordnet. Diese Datei bewirkt jedoch, dass die Befehle db2ln und db2rmln nicht funktionieren. Der Befehl db2ln setzt die Datei nicht außer Kraft, und der Befehl db2rmln entfernt die Datei nicht. Damit in dieser Situation unter Verwendung von DB2 UDB Anwendungen kompiliert werden können, müssen die Kompilierungs- und Verbindungsprozesse einen vollständigen Pfad zu den Kopfdaten bzw. den Bibliotheken von DB2 UDB bereitstellen. Dies ist die empfohlene Methode, weil dadurch das Kompilieren und Verbinden für mehrere Releases von DB2 UDB auf demselben Computer möglich ist.

Weitere Informationen zu Einschränkungen für den Befehl db2ln finden Sie im Handbuch Installation und Konfiguration von DB2 UDB Version 8.2.

Query Patroller

Aktualisierung für das Verhalten von Abfrageklassen

Wenn eine der folgenden Tasks über die Query Patroller-Zentrale oder die Query Patroller-Befehlszeile ausgeführt wird, wird eine Warnung zurückgegeben:

Hinzufügen einer Abfrageklasse
Entfernen einer Abfrageklasse
Aktualisieren des maximalen Aufwands einer Abfrage für eine Abfrageklasse

Die Warnung lautet wie folgt:

DQP1024W  Das Erstellen, Ändern oder Entfernen einer
Abfrageklasse wird erst wirksam, wenn der Query
Patroller-Server erneut gestartet wird.

Im DB2 Query Patroller^(TM)-Handbuch: Installation, Verwaltung und Verwendung der Version 8.2 wird beschrieben, dass Sie den Query Patroller-Server nach dem Erstellen, Ändern oder Entfernen von Abfrageklassen erneut starten müssen, damit Ihre Änderungen wirksam werden.

Die Nachricht und die Aussage im Handbuch treffen nicht mehr zu. Die drei zuvor aufgelisteten Tasks für Abfrageklassen werden sofort ausgeführt, es sei denn, es sind Abfragen vorhanden, die sich in der Warteschlange befinden oder gerade ausgeführt werden. Wenn dies der Fall ist (auch unter Berücksichtigung neu übergebener Abfragen), werden die an den Abfrageklassen vorgenommenen Änderungen wirksam, sobald die Abfragen, die sich in der Warteschlange befinden oder gerade ausgeführt werden, abgeschlossen sind. Wenn Sie nicht warten wollen, bis alle Abfragen, die sich in der Warteschlange befinden bzw. gerade ausgeführt werden, abgeschlossen sind, müssen Sie den Query Patroller-Server erneut starten.

Anmerkung:

Wie auch bei anderen Query Patroller-Versionen wird die Aktualisierung der maximalen Anzahl Abfragen für eine Abfrageklasse immer sofort ausgeführt.

Definitionsaktualisierungen für den Status verwalteter Abfragen

Die Bedeutungen der Abfragestatus Abgebrochen und Fertig werden wie folgt aktualisiert:

Abgebrochen: Die Abfrage wurde durch den Administrator, den übergebenden Benutzer oder einen Bediener, dessen Profil das Zugriffsrecht MONITORING mit Editierberechtigung aufweist, über die Query Patroller-Zentrale oder über die Query Patroller-Befehlszeile abgebrochen. Nur aktive, angehaltene, freigegebene und in der Warteschlange stehende Abfragen können abgebrochen werden.
Fertig: Die Abfrage wurde erfolgreich beendet.
Anmerkung:

Obwohl die Abfrage selbst ohne Fehler beendet wurde, empfängt die Anwendung möglicherweise einen Fehler, wenn die Beendigung von einem externen Ereignis verursacht wurde, z. B. von einer DB2 force-Anwendung.

Erstellen von EXPLAIN-Tabellen vor der Ausführung des Query Patroller-Generators für Protokolldaten

Wenn Sie den Generator für Protokolldaten für Query Patroller ausführen, falls die EXPLAIN-Tabellen nicht bereits vorhanden sind, wird der Generator diese für Sie erstellen. Es ist jedoch sehr empfehlenswert, dass Sie die EXPLAIN-Tabellen vor der Ausführung des Generators für Protokolldaten erstellen. Wenn Sie die EXPLAIN-Tabellen erstellen, stellen Sie sicher, dass Sie diese auf derselben Partition erstellen. Das aktive Erstellen der EXPLAIN-Tabellen auf derselben Partition verbessert die Leistung des EXPLAIN-Tools. Diese Verbesserung erhöht die Leistung des Generators für Protokolldaten.

Überprüfen der Query Patroller-Protokolldateien für die Protokollanalyse

Wenn in der Spalte Ausführung mit EXPLAIN bearbeiten des Berichts Abfrageaktivität im Laufe der Zeit (Protokollanalysen) ein Status Nicht erfolgreich ausgeführt für eine Abfrage angezeigt wird, wurden keine Protokolldaten für diese Abfrage generiert. Daher wird die Abfrage in keinen Protokollanalyseberichten oder -diagrammen angezeigt. Wie in Version 8 dokumentiert, können Sie die Datei qpuser.log überprüfen, um festzustellen, warum die Abfrage nicht erfolgreich war.

Sie sollten nicht nur die Datei qpuser.log, sondern auch die Datei qpdiag.log überprüfen.

Abnormale Beendigung des Generators für Protokolldaten

Wenn der Generator für Protokolldaten ausgeführt und abnormal beendet wird, wird beim nächsten Versuch, den Generator auszuführen, ein Fehler ausgegeben. Beispiele für eine abnormale Beendigung:

DB2 Universal Database wird unerwartet gestoppt.
Der Befehl db2stop force wird abgesetzt.
Der Befehl killdb2 wird abgesetzt.

Wenn der Generator für Protokolldaten abnormal beendet wird, müssen Sie vor der erneuten Ausführung des Generators den folgenden Befehl absetzen:

    qp -d datenbank generate historical_data stop

Dabei gibt datenbank die Datenbank an, für die der Befehl ausgeführt wird.

Dynamische Aktualisierung von Abfrageklassen

Einige Operationen für Abfrageklassen können ab sofort ausgeführt werden, ohne dass Query Patroller gestoppt und erneut gestartet werden muss.

In der folgenden Tabelle ist eine aktive Abfrage eine Abfrage, die sich in einem aktiven Status oder in einer Warteschlange befindet.

Tabelle 38. Bedingungen für die erfolgreiche Durchführung von Abfrageklassenänderungen
Art der Änderung	Bedingungen für die erfolgreiche Änderung
Hinzufügen, Entfernen oder Aktualisieren einer Abfrageklasse	Wenn keine aktiven Abfragen vorhanden sind, werden die Änderungen umgehend durchgeführt.
Aktualisieren einer Abfrageklasse mit nur einer Änderung an Max. Anzahl Abfragen	Die Änderung wird umgehend durchgeführt, auch wenn aktive Abfragen vorhanden sind.
Aktualisieren einer Abfrageklasse mit nur einer Änderung an Max. Aufwand einer Abfrage	Wenn aktive Abfragen vorhanden sind, wird die Aktualisierung in den folgenden Fällen durchgeführt: Query Patroller wird gestoppt und erneut gestartet. Es sind keine aktiven Abfragen mehr vorhanden. Anmerkung: Wenn eine Änderung bezüglich des maximalen Aufwands einer Abfrage ansteht, werden nachfolgende Aktualisierungen von Abfrageklassen erst dann wirksam, wenn eine der obigen Bedingungen erfüllt ist.
Hinzufügen oder Entfernen einer Abfrageklasse	Wenn aktive Abfragen vorhanden sind, kann eine Abfrageklasse in den folgenden Fällen hinzugefügt oder entfernt werden: Query Patroller wird gestoppt und erneut gestartet. Es sind keine aktiven Abfragen mehr vorhanden.

Verhalten verschachtelter Abfragen

Verschachtelte Abfragen können nicht in eine Warteschlange eingereiht werden. Stattdessen wird die verschachtelte Abfrage bei Überschreitung eines Schwellenwerts, der normalerweise die Einreihung in eine Warteschlange zur Folge hätte, umgehend ausgeführt.

Einschränkungen nach SQL-Anweisungstyp

Im Gegensatz zu früheren Angaben können Abfragen mit den folgenden Anweisungen in eine Warteschlange eingereiht werden:

Abfragen, die statisches SQL mit Hostvariablen enthalten
Abfragen mit einer Identitätswertfunktion (IDENTITY_VAL_LOCAL) oder einer Folgewertfunktion (z. B. NEXT VALUE FOR oder PREVIOUS VALUE FOR)

Einschränkungen der Auflösung bei der Verwendung von Terminal Services Client

Wenn Sie Terminal Services Client mit einer Auflösung von 640x480 verwenden, um eine Verbindung zu einem fernen Desktop herzustellen, auf dem die Query Patroller-Zentrale aktiv ist, wird das Fenster Übergabevorgaben möglicherweise leer angezeigt. Sie müssen eine höhere Auflösung als 640x480 verwenden, damit das Fenster Übergabevorgaben richtig angezeigt wird.

Neue Unterstützung von Gruppen für Abfrageübergaben

Ab Version 8.2 unterstützt DB2 Universal Database (UDB) auch andere Benutzergruppen als Betriebssystemgruppen. Daher gibt es eine leichte Änderung in der Dropdown-Liste Zu verwendendes Übergabeprofil im Fenster Vorgaben für die Abfrageübergabe der Query Patroller-Zentrale.

Wenn Sie angemeldet sind, aber weder die Berechtigung DBADM noch das Zugriffsrecht zum Editieren für die Query Patroller-Benutzerverwaltung haben, können Sie nur eine Übergabeeinstellung für sich selbst hinzufügen oder aktualisieren. In diesem Fall enthält die Dropdown-Liste Zu verwendendes Übergabeprofil die vorhandenen Übergabeprofile der DB2 UDB-Gruppen, zu denen Sie gehören, und nicht nur die Betriebssystemgruppen, zu denen Sie gehören.

Wenn Sie angemeldet sind und entweder die Berechtigung DBADM oder das Zugriffsrecht zum Editieren für die Query Patroller-Benutzerverwaltung haben, können Sie Übergabeeinstellungen für andere Benutzer hinzufügen oder aktualisieren. In diesem Fall enthält die Dropdown-Liste Zu verwendendes Übergabeprofil alle vorhandenen Gruppenübergabeprofile.

Query Patroller-Zeitplaneinschränkungen

Beim Arbeiten mit Zeitplänen in der Query Patroller-Zentrale können Sie das Zeitplanfenster verwenden, um Zeitpläne in einer Datei zu speichern und später zu importieren. Wenn Sie einen Zeitplan haben, den Sie mit FixPak 6 oder einer früheren Version gespeichert haben, können Sie den Zeitplan nicht mit Version 8.2 oder einer späteren Version importieren. Der Grund für diese Einschränkung ist die Änderung der Serialisierung zwischen den JDK-Stufen, die mit DB2 UDB Version 8.2 eingeführt wurde.

Berechtigung zum Verwenden des Befehls RUN IN BACKGROUND QUERY erforderlich

Zum Ausführen des Befehls RUN IN BACKGROUND QUERY müssen Sie die Abfrage ursprünglich übergeben haben.

Erstellen eines Aliasnamens für eine Ergebnistabelle

Seit Query Patroller Version 8.1 FixPak 5 erstellt Query Patroller keine Ergebnistabellen mehr in dem Schema, das mit der Berechtigungs-ID des übergebenden Benutzers der Abfrage übereinstimmt. Stattdessen erstellt Query Patroller seitdem Ergebnistabellen in einem allgemeinen Schema DB2QPRT. Mit Query Patroller Version 8.2 wird eine Option eingeführt, mit der automatisch ein Aliasname für jede neue Ergebnistabelle erstellt wird, die Query Patroller erstellt, um Verweise auf die Ergebnistabellen mit dem Schema des übergebenden Benutzers zu ermöglichen. Die Ergebnistabelle wird im Schema DB2QPRT erstellt, und der Aliasname wird in einem Schema erstellt, das mit der Berechtigungs-ID des übergebenden Benutzers übereinstimmt.

Setzen Sie zum Aktivieren oder Inaktivieren dieser Option den Befehl UPDATE QP_SYSTEM mit der Option CREATE_RESULT_TABLE_ALIASES ab:

>>-UPDATE QP_SYSTEM USING--------------------------------------->
 
>--+-DEFAULT------------------------------+--------------------><
   '-CREATE_RESULT_TABLE_ALIASES--+-'Y'-+-'
                                  '-'N'-'

Entfernen von nicht mehr benötigten Aliasnamen für Ergebnistabellen

Aliasnamen, die mit der Option CREATE_RESULT_TABLE_ALIASES erstellt werden, werden automatisch gelöscht, wenn eine Ergebnistabelle gelöscht wird. Es gibt jedoch zwei Situationen, in denen eine Ergebnistabelle gelöscht werden kann, ohne dass der entsprechende Aliasname gelöscht wird.

Wenn die Ergebnistabelle manuell gelöscht wird, ohne die Befehlszeile qp oder die Query Patroller-Zentrale zu verwenden.
Wenn die Ergebnistabelle mit der Befehlszeile qp oder der Query Patroller-Zentrale unter der Berechtigung eines Operators gelöscht wird, der nicht der übergebende Benutzer der Abfrage ist und nicht die Berechtigung DBADM hat.

Zum Bereinigen von Aliasnamen ohne zugehörige Ergebnistabellen wurde ein neuer Befehl, REMOVE RESULT_TABLE_ALIASES, erstellt. Dieser Befehl wird automatisch ausgeführt, wenn die Ergebnistabellen während des terminierten Query Patroller-Prozesses zum Löschen von Ergebnistabellen gelöscht werden. Der Befehl REMOVE RESULT_TABLE_ALIASES erhält die Liste der Aliasnamen, die gelöscht werden sollen, mit der folgenden Abfrage:

with a as (select tabschema, tabname from syscat.tables 
           where type = 'A' and tabname like 'QUERY%_RESULTS'), 
     t as (select tabname from syscat.tables 
           where type = 'T' and tabname like 'QUERY%_RESULTS')
  select all tabschema, tabname from a 
  where not exists (select * from t where t.tabname=a.tabname)

Voraussetzungen

Sie müssen die Berechtigung DBADM haben.

Vorgehensweise

Setzen Sie den Befehl REMOVE RESULT_TABLE_ALIASES ab.

Dieser Befehl entfernt alle Aliasnamen, die noch vorhanden sind, nachdem ihre zugehörigen Ergebnistabellen gelöscht wurden. Die Aliasnamen wurden ursprünglich von Query Patroller für Ergebnistabellen erstellt.

Befehlssyntax

>>-REMOVE RESULT_TABLE_ALIASES---------------------------------><

Anmerkung:

Informationen zur Eingabe von Query Patroller-Befehlen mit der Befehlszeilenschnittstelle und zur allgemeinen Syntax für Query Patroller-Befehle finden Sie in der Query Patroller-Befehlszeilenschnittstelle.

Abgeschirmte Benutzer-ID erfordert den Schreibzugriff auf die Datei 'qpdiag.log' und auf deren Pfad

Query Patroller verwendet mehrere abgeschirmte gespeicherte Prozeduren, die zu Protokolleinträgen in der Datei qpdiag.log führen können. Daher muss die abgeschirmte Benutzer-ID Schreibzugriff auf die Datei qpdiag.log und auf den Pfad haben, in der sich diese Datei befindet.

Einstieg

| | |

Speicherbedarf

Für DB2 Universal Database (UDB) sind mindestens 256 MB Arbeitsspeicher erforderlich. Für ein System, auf dem nur DB2 UDB und die DB2-GUI-Tools ausgeführt werden, sind mindestens 512 MB Arbeitsspeicher erforderlich. Zur Leistungssteigerung wird jedoch 1 GB Hauptspeicher empfohlen. Speicherbedarf für weitere Software, die auf dem System ausgeführt wird, wird in diesen Angaben nicht berücksichtigt.

Berücksichtigen Sie bei der Ermittlung des Speicherbedarfs Folgendes:

Für die DB2-Clientunterstützung wurde dieser Speicherbedarf auf der Basis von fünf gleichzeitigen Clientverbindungen berechnet. Für weitere fünf Clientverbindungen benötigen Sie weitere 16 MB Hauptspeicher.

Der Speicherbedarf wird von der Größe und von der Komplexität des Datenbanksystems sowie vom Umfang der Datenbankaktivität und der Anzahl der auf das System zugreifenden Clients beeinflusst.

Unter Linux-Betriebssystemen wird ein Auslagerungsspeicher empfohlen, der mindestens doppelt so groß ist wie der Arbeitsspeicher. Dies ist jedoch nicht obligatorisch.

Erläuterung der DB2 UDB-Clientunterstützung

Im Thema "Übersicht über DB2-Clients" des Handbuchs IBM DB2 UDB für DB2-Clients Einstieg Version 8.1 heißt es wie folgt:

DB2-Clients können eine Verbindung zu DB2-Servern, die zwei Releases höher bzw. ein Release niedriger als die Client-Release-Stufe liegen, und zu Servern auf derselben Releasestufe herstellen.

Eine Ergänzung zu dieser Aussage lautet wie folgt:

Verbindungen von Clients mit Version N zu Servern mit Version N+2 sind zwar in einigen Umgebungen möglich, diese Konfiguration wird jedoch nur so lange unterstützt, wie Version N vertrieben wird. Sobald Version N nicht mehr vertrieben wird, wird diese Konfiguration nicht mehr unterstützt.
DB2-Clients der Version 7, die eine Verbindung zu einem DB2-Server der Version 8 herstellen, werden nicht mehr unterstützt, da DB2 Version 7 vom Markt genommen wurde.

Modifizieren von Kernelparametern (Linux)

Bevor Sie DB2 UDB installieren, sollten Sie die Linux-Kernelparameter aktualisieren. Die IPC-Begrenzungen werden im Bedarfsfall automatisch von DB2 Universal Database (UDB) erhöht. Sollten Sie jedoch besondere Anforderungen haben, können Sie diese Begrenzungen weiter erhöhen.

Voraussetzungen

Um die Kernelparameter ändern zu können, müssen Sie über Rootberechtigung verfügen.

Vorgehensweise

Um die Kernelparameter zu aktualisieren, gehen Sie wie folgt vor:

Red Hat und SuSE

Systeme, die einen Kernel der Serie 2.4.x verwenden, verfügen über einen Standardwert für den Parameter der Nachrichtenwarteschlange (msgmni), der lediglich einige wenige gleichzeitige Verbindungen zu DB2 UDB zulässt. Damit DB2 UDB erfolgreich ausgeführt werden kann, müssen auch Semaphor-Array-Parameter geändert werden. Um die Begrenzungen für gemeinsam benutzte Speichersegmente, Semaphor-Arrays und Nachrichtenwarteschlangen zu überprüfen, geben Sie den Befehl ipcs -l aus.

Der Befehl ipcs -l gibt die folgende Ausgabe zurück:

   # ipcs -l

------ Shared Memory Limits --------
max number of segments = 4096              // SHMMNI
max seg size (kbytes) = 262144             // SHMMAX
max total shared memory (kbytes) = 8388608 // SHMALL
min seg size (bytes) = 1

------ Semaphore Limits --------
max number of arrays = 1024                // SEMMNI
max semaphores per array = 250
max semaphores system wide = 256000
max ops per semop call = 32
semaphore max value = 32767

------ Messages: Limits --------
max queues system wide = 1024              // MSGMNI
max size of message (bytes) = 65535        // MSGMAX
default max size of queue (bytes) = 16384  // MSGMNB

Dabei gilt Folgendes:

  max semaphores system wide = 
  max number of arrays x max semaphores/array

Ändern Sie die Kernelparameter für Linux-Kernels (32 Bit), indem Sie der standardmäßigen Konfigurationsdatei /etc/sysctl.conf zur Systemsteuerung die folgenden Einträge hinzufügen:

  kernel.msgmni = 1024
  kernel.sem = "250 256000  32 1024"
  kernel.shmmax=268435456

Ändern Sie die Kernelparameter für Linux-Kernels (64 Bit), indem Sie der standardmäßigen Konfigurationsdatei /etc/sysctl.conf zur Systemsteuerung die folgenden Einträge hinzufügen:

  kernel.msgmni = 1024
  kernel.sem = "250 256000  32 1024"
  kernel.shmmax=1073741824

Führen Sie sysctl mit dem Parameter -p aus, um Einstellungen aus der Standarddatei /etc/sysctl.conf in 'sysctl' zu laden:

   sysctl -p

Die Einträge aus der Datei sysctl.conf werden beim Systemstart vom Script für die Netzwerkinitialisierung gelesen.

In einigen Varianten ist es unter Umständen erforderlich, einer der Systeminitialisierungsdateien sysctl -p hinzuzufügen, wie z. B. rc.local, damit Kernelparameter nach jedem Neustart gesetzt werden.

Modifizieren von Kernelparametern (Solaris-Betriebsumgebung)

Die folgenden Informationen sind eine Ergänzung des Themas "Modifizieren von Kernelparametern (Solaris-Betriebsumgebung)" im Handbuch DB2 Universal Database für DB2-Server Einstieg:

Für einen ordnungsgemäßen Betrieb von DB2 Universal Database (UDB) wird die Aktualisierung der Kernelkonfigurationsparameter des Systems empfohlen. Sie können über das Dienstprogramm db2osconf empfohlene Einstellungen für die Kernelparameter vorschlagen lassen.

Damit Sie den Befehl db2osconf verwenden können, müssen Sie zuerst DB2 UDB installieren. Das Dienstprogramm db2osconf kann nur über $DB2DIR/bin ausgeführt werden.

Nach der Modifizierung von Kernelparametern muss das System erneut gestartet werden.

Handbuch 'DB2 Universal Database Express Edition Version 8.2 Basics' zum Download verfügbar

IBM DB2 Universal Database Express (DB2 UDB Express) ist das neueste Mitglied der Produktfamilie von DB2 Universal Database Version 8. Es vereint die Leistungsfähigkeit, Funktionalität und Zuverlässigkeit der mehrfach ausgezeichneten relationalen Datenbank DB2 UDB von IBM mit den Vorteilen einer einfachen Konfektionierung, Installation und Implementierung bei minimalen Investitionskosten, um den Bedürfnissen kleiner und mittlerer Unternehmen (Mittelstand) im Bereich Datenmanagement gerecht zu werden.

DB2 UDB Express wurde für Kunden mit minimalem internen Know-how im Bereich Datenbanken entwickelt, die eine einfach zu installierende und in-house in die jeweiligen Anwendungssoftwarelösungen integrierte Datenbank benötigen. Es handelt sich um eine DB2 UDB-Version für mehrere Benutzer, die lokale und ferne Anwendungen in eigenständigen Umgebungen (Standalone-Umgebungen) und LAN-Umgebungen unterstützt.

Wenn Sie weitere Informationen zu DB2 UDB Express benötigen, können Sie die Handbücher DB2 Universal Database Express Edition Einstieg und DB2 Universal Database Express Edition Version 8.2 Basics von der Webseite für DB2 UDB-Produkthandbücher unter http://www.ibm.com/software/data/db2/udb/support/manualsv8.html herunterladen.

Prüfen, ob die Datenbanken für die Migration bereit sind

Der folgende Voraussetzungsabschnitt ist in Version 8.2 in dem Thema dokumentiert, das die Prüfung Ihrer Datenbanken auf Bereitschaft für die Migration erklärt.

Voraussetzungen: Stellen Sie sicher, dass die Datei migration.log im Ausgangsverzeichnis des Exemplareigners den folgenden Text enthält: Version von DB2CKMIG wird ausgeführt: VERSION 8.

Diese Voraussetzung ist jedoch ein Schritt, der nach der Migration am Ende der Prozedur ausgeführt wird.

Common Criteria-Zertifizierung für DB2 UDB

Die bestätigten Informationen für DB2 UDB-Konfigurationen, die für Common Criteria zertifiziert wurden, finden Sie unter http://niap.nist.gov/cc-scheme.

Spatial Extender

Prüfen der Spatial Extender-Installation

Das Beispielprogramm runGseDemo kann verwendet werden, um sich mit der Anwendungsprogrammierung für DB2 Spatial Extender vertraut zu machen. Eine Beschreibung der Schritte, die das Beispielprogramm ausführt, um eine Datenbank zu erstellen, die räumliche Daten verarbeiten kann, und eine räumliche Analyse von Daten in dieser Datenbank auszuführen, finden Sie in dem Thema mit dem Titel "Beispielprogramm von DB2 Spatial Extender". Dieses Thema finden Sie in DB2 Information - Unterstützung und dem Handbuch Spatial Extender und Geodetic Extender Benutzer- und Referenzhandbuch.

DB2 Spatial Extender stellt ein weiteres Beispielprogramm, seBankDemoRunBankDemo, zur Verfügung, das veranschaulicht, wie einem vorhandenen Informationssystem Funktionalität für räumliche Daten hinzugefügt wird.

Weitere Informationen zu beiden Beispielprogrammen finden Sie in den Readme-Dateien in folgenden Verzeichnissen:

Windows

~\sqllib\samples\spatial
~\sqllib\samples\spatial\bank

Linux und UNIX

~/sqllib/spatial
~/sqllib/spatial/bank

SQL-Verwaltungsroutinen

Falscher Spaltenname in der Ergebnismenge für die Tabellenfunktion SNAP_GET_DYN_SQL

Im Thema "Tabellenfunktion SNAP_GET_DYN_SQL" in Information - Unterstützung der Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) wird die Ergebnismenge für die Tabellenfunktion SNAP_GET_DYN_SQL falsch beschrieben.

Eine der Spalten wird fälschlicherweise als STMT_TXT bezeichnet.

Der richtige Name der Ausgabespalte lautet STMT_TEXT.

Snapshot Monitor-Tabellenfunktionen haben versionsspezifische Sichten

Versionsspezifische Sichten wurden für die folgenden Snapshot Monitor-Tabellenfunktionen definiert, die in DB2 Universal Database Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) eingeführt werden:

SNAP_GET_CONTAINER
SNAP_GET_DB
SNAP_GET_DYN_SQL
SNAP_GET_STO_PATHS
SNAP_GET_TAB
SNAP_GET_TBSP
SNAP_GET_TBSP_PART

Die versionsspezifischen Sichten lauten wie folgt:

SYSCATV82.SNAPCONT
SYSCATV82.SNAPDB
SYSCATV82.SNAPDYNSQL
SYSCATV82.SNAPSTOPATHS
SYSCATV82.SNAPTAB
SYSCATV82.SNAPTBSPACE
SYSCATV82.SNAPTBSPACEPART

Da es keine Garantie dafür gibt, dass die Ergebnistabellen der Snapshot Monitor-Tabellenfunktionen von Release zu Release nicht geändert werden, wird die Verwendung von versionsspezifischen Sichten empfohlen, wenn Sie Ergebnistabellen bevorzugen, die garantiert nicht geändert werden. Jede Sicht enthält alle Spalten der Ergebnistabelle der zugehörigen Snapshot Monitor-Tabellenfunktion.

Prozedur GET_DB_CONFIG erfordert eine Seitengröße von mindestens 8 KB für einen temporären Benutzertabellenbereich

Die Prozedur GET_DB_CONFIG erfordert einen temporären Benutzertabellenbereich mit einer Seitengröße von mindestens 8 KB.

Das Beispiel zur Verwendung der Prozedur GET_DB_CONFIG muss durch das folgende Beispiel ersetzt werden.

Ändern Sie mit Hilfe des Befehlszeilenprozessors (CLP - Command Line Processor) den Wert der Datenbankkonfigurationsparameter logretain und userexit. Rufen Sie die Originalwerte (auf der Festplatte) sowie die aktualisierten Werte (im Speicher) ab, indem Sie die Prozedur GET_DB_CONFIG aufrufen.

   UPDATE DB CFG USING LOGRETAIN RECOVERY USEREXIT YES
   CALL SYSPROC.GET_DB_CONFIG()

Das folgende Beispiel zeigt einen Teil der Ausgabe dieses Prozeduraufrufs:

Ergebnismenge 1
--------------

DBCONFIG_TYPE ... LOGRETAIN   ... USEREXIT...
-------------     -----------     -----------
            0               1               1
            1               0               0

     2 Satz/Sätze ausgewählt.

Rückgabestatus = 0

SQL Reference

EXPLAIN_DIAGNOSTIC: Eine neue EXPLAIN-Tabelle

Die Tabelle EXPLAIN_DIAGNOSTIC enthält einen Eintrag für jede Diagnosenachricht, die für ein bestimmtes Exemplar einer mit EXPLAIN bearbeiteten Anweisung in der Tabelle EXPLAIN_STATEMENT erstellt wurde.

Die Tabellenfunktion EXPLAIN_GET_MSGS fragt die EXPLAIN-Tabellen EXPLAIN_DIAGNOSTIC und EXPLAIN_DIAGNOSTIC_DATA ab und gibt formatierte Nachrichten zurück.

Tabelle 39. Tabelle EXPLAIN_DIAGNOSTIC
Spaltenname	Datentyp	Dateneingabe optional	Schlüssel ¹	Beschreibung
EXPLAIN_REQUESTER	VARCHAR(128)	Nein	PS, FS	Berechtigungs-ID des Initiators dieser EXPLAIN-Anforderung.
EXPLAIN_TIME	TIMESTAMP	Nein	PS, FS	Startzeit der EXPLAIN-Anforderung.
SOURCE_NAME	VARCHAR(128)	Nein	PS, FS	Name des Pakets, das ausgeführt wird, als die dynamische Anweisung mit EXPLAIN bearbeitet wurde, oder der Name der Quellendatei, als das statische SQL mit EXPLAIN bearbeitet wurde.
SOURCE_SCHEMA	VARCHAR(128)	Nein	PS, FS	Schema oder Qualifikationsmerkmal der Quelle der EXPLAIN-Anforderung.
SOURCE_VERSION	VARCHAR(64)	Nein	PS, FS	Version der Quelle der EXPLAIN-Anforderung.
EXPLAIN_LEVEL	CHAR(1)	Nein	PS, FS	Ebene der EXPLAIN-Informationen, für die diese Zeile relevant ist. Gültige Werte: 0: Originaltext (wie vom Benutzer eingegeben) P: PLANAUSWAHL
STMTNO	INTEGER	Nein	PS, FS	Nummer der Anweisung in einem Paket, zu der diese EXPLAIN-Informationen gehören. Wird für Dynamic Explain-SQL-Anweisungen auf 1 gesetzt. Für statische SQL-Anweisungen ist dieser Wert mit dem Wert identisch, der für die Katalogsicht SYSCAT.STATEMENTS verwendet wird.
SECTNO	INTEGER	Nein	PS, FS	Nummer des Abschnitts in einem Paket, der diese SQL-Anweisung enthält. Für Dynamic Explain-SQL-Anweisungen ist dies die Nummer des Abschnitts, der den Abschnitt für diese Anweisung während der Ausführung enthält. Für statische SQL-Anweisungen ist dieser Wert mit dem Wert identisch, der für die Katalogsicht SYSCAT.STATEMENTS verwendet wird.
DIAGNOSTIC_ID	INTEGER	Nein	PK	ID der Diagnosedaten für ein bestimmtes Exemplar einer Anweisung in der Tabelle EXPLAIN_STATEMENT.
CODE	INTEGER	Nein	Nein	Eine eindeutige Nummer, die jeder Diagnosenachricht zugeordnet ist. Die Nummer kann von einer Nachrichten-API verwendet werden, um den vollständigen Text der Diagnosenachricht abzurufen.

PK bedeutet, dass die Spalte Teil eines Primärschlüssel ist. FK bedeutet, dass die Spalte Teil eines Fremdschlüssels ist.

EXPLAIN_DIAGNOSTIC_DATA: Eine neue EXPLAIN-Tabelle

Die Tabelle EXPLAIN_DIAGNOSTIC_DATA enthält Nachrichtentoken für bestimmte Diagnosenachrichten, die in der Tabelle EXPLAIN_DIAGNOSTIC eingetragen sind. Die Nachrichtentoken enthalten zusätzliche Informationen zur Ausführung der SQL-Anweisung, die die Nachricht generiert hat.

Die Tabellenfunktion EXPLAIN_GET_MSGS fragt die EXPLAIN-Tabellen EXPLAIN_DIAGNOSTIC und EXPLAIN_DIAGNOSTIC_DATA ab und gibt formatierte Nachrichten zurück.

Tabelle 40. Tabelle EXPLAIN_DIAGNOSTIC_DATA
Spaltenname	Datentyp	Dateneingabe optional	Schlüssel ¹	Beschreibung
EXPLAIN_REQUESTER	VARCHAR(128)	Nein	FS	Berechtigungs-ID des Initiators dieser EXPLAIN-Anforderung.
EXPLAIN_TIME	TIMESTAMP	Nein	FS	Startzeit der EXPLAIN-Anforderung.
SOURCE_NAME	VARCHAR(128)	Nein	FS	Name des Pakets, das ausgeführt wird, als die dynamische Anweisung mit EXPLAIN bearbeitet wurde, oder der Name der Quellendatei, als das statische SQL mit EXPLAIN bearbeitet wurde.
SOURCE_SCHEMA	VARCHAR(128)	Nein	FS	Schema oder Qualifikationsmerkmal der Quelle der EXPLAIN-Anforderung.
SOURCE_VERSION	VARCHAR(64)	Nein	FS	Version der Quelle der EXPLAIN-Anforderung.
EXPLAIN_LEVEL	CHAR(1)	Nein	FS	Ebene der EXPLAIN-Informationen, für die diese Zeile relevant ist. Gültige Werte: 0: Originaltext (wie vom Benutzer eingegeben) P: PLANAUSWAHL
STMTNO	INTEGER	Nein	FS	Nummer der Anweisung in einem Paket, zu der diese EXPLAIN-Informationen gehören. Wird für Dynamic Explain-SQL-Anweisungen auf 1 gesetzt. Für statische SQL-Anweisungen ist dieser Wert mit dem Wert identisch, der für die Katalogsicht SYSCAT.STATEMENTS verwendet wird.
SECTNO	INTEGER	Nein	FS	Nummer des Abschnitts in einem Paket, der diese SQL-Anweisung enthält. Für Dynamic Explain-SQL-Anweisungen ist dies die Nummer des Abschnitts, der den Abschnitt für diese Anweisung während der Ausführung enthält. Für statische SQL-Anweisungen ist dieser Wert mit dem Wert identisch, der für die Katalogsicht SYSCAT.STATEMENTS verwendet wird.
DIAGNOSTIC_ID	INTEGER	Nein	PK	ID der Diagnosedaten für ein bestimmtes Exemplar einer Anweisung in der Tabelle EXPLAIN_STATEMENT.
ORDINAL	INTEGER	Nein	Nein	Position des Tokens im vollständigen Nachrichtentext.
TOKEN	VARCHAR(1000)	Ja	Nein	Nachrichtentoken, das in einen vollständigen Nachrichtentext eingefügt werden soll; ist möglicherweise abgeschnitten.
TOKEN_LONG	BLOB(3M)	Ja	Nein	Genauere Informationen, sofern verfügbar.

PK bedeutet, dass die Spalte Teil eines Primärschlüssel ist. FK bedeutet, dass die Spalte Teil eines Fremdschlüssels ist.

Von der EXPLAIN-Einrichtung verwendetes Schema

Die EXPLAIN-Einrichtung verwendet die folgenden IDs als Schema für die Qualifizierung der EXPLAIN-Tabellen, die gefüllt werden:

Die Sitzungsberechtigungs-ID für dynamisches SQL
Die Anweisungsberechtigungs-ID für statisches SQL

Das Schema kann einer Gruppe von EXPLAIN-Tabellen oder Aliasnamen zugeordnet werden, die auf eine Gruppe von EXPLAIN-Tabellen in einem anderen Schema zeigen.

Wenn unter dem Schema keine EXPLAIN-Tabellen gefunden werden, sucht die EXPLAIN-Einrichtung im Schema SYSTOOLS nach EXPLAIN-Tabellen und versucht, diese zu verwenden.

Zeichenfolgedarstellung von Werten für Datum und Uhrzeit

Zeitzeichenfolgen

Eine Zeichenfolgedarstellung einer Zeit ist eine Zeichenfolge, die mit einer Ziffer beginnt und mindestens vier Zeichen hat. Folgende Leerzeichen können eingeschlossen werden; eine führende Null kann in dem Teil der Zeit, der die Stunde angibt, ausgelassen werden, und Sekunden können vollständig ausgelassen werden. Wenn Sekunden ausgelassen werden, wird eine implizite Angabe von null Sekunden angenommen. 13:30 ist also äquivalent zu 13:30:00.

In der folgenden Tabelle werden gültige Zeichenfolgeformate für Zeiten aufgelistet. Jedes Format wird mit einem Namen und einer zugeordneten Abkürzung angegeben.

Tabelle 41. Formate für Zeichenfolgedarstellungen von Zeiten
Formatname	Abkürzung	Zeitformat	Beispiel
International Standards Organization	ISO	hh.mm.ss	13.30.05
IBM USA-Standard	USA	hh:mm AM oder PM	1:30 PM
Europäischer IBM Standard	EUR	hh.mm.ss	13.30.05
Japanese Industrial Standard (christliche Zeitrechnung)	JIS	hh:mm:ss	13:30:05
Site-definiert	LOC	Abhängig vom Gebietscode der Anwendung	-

Ab Version 8.2 können "AM" und "PM" in Kleinbuchstaben oder in Großbuchstaben dargestellt werden.

Systemmonitor

Diagnoseanzeiger - Zusammenfassung

Im Thema "Diagnoseanzeiger - Zusammenfassung" in DB2 Information - Unterstützung für Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) wird als ID für den Diagnoseanzeiger der Auslastung des dynamischen Datenbankspeichers fälschlicherweise db.db_auto_storage_util angegeben.

Die richtige ID für den Diagnoseanzeiger der Auslastung des dynamischen Datenbankspeichers lautet db.auto_storage_util.

Liste mit Anwendungen ohne Verbindung, obwohl der Verbindungskonzentrator nicht aktiviert ist

Es ist möglich, dass beim Absetzen des Befehls list applications Anwendungen ohne Verbindung angezeigt werden, selbst wenn der Verbindungskonzentrator nicht aktiviert ist.

Fortschrittsüberwachung des Laufzeit-ROLLBACK-Prozesses

Die Fortschrittsüberwachung des Laufzeit-ROLLBACK-Prozesses stellt Fortschrittsinformationen zu ROLLBACK-Ereignissen anhand von Anwendungsmomentauf- nahmen zur Verfügung. Es gibt zwei Typen von ROLLBACK-Ereignissen:

ROLLBACK-Operation einer Arbeitseinheit: Umfasst explizite (vom Benutzer aufgerufene) und implizite (erzwungene) ROLLBACK-Operationen der gesamten Transaktion.
ROLLBACK-Operation zum Sicherungspunkt: Umfasst Sicherungspunkte auf Anweisungs- und Anwendungsebene. Verschachtelte Sicherungspunkte werden als eine Einheit betrachtet, wobei der äußerste Sicherungspunkt verwendet wird.

Die zur Verfügung gestellten Informationen umfassen die Startzeit des ROLLBACK-Ereignisses, die gesamte auszuführende Arbeit sowie die abgeschlossene Arbeit. Die Messgröße für die Arbeit ist Byte.

Die Einheiten von Gesamte Arbeit geben den Bereich im Protokolldatenstrom an, der für die Transaktion oder den Sicherungspunkt rückgängig gemacht werden muss.

Die Einheiten von Abgeschlossene Arbeit zeigen die relative Position der Daten im Protokolldatenstrom an, die rückgängig gemacht wurden.

Aktualisierungen an Abgeschlossene Arbeit werden nach der Verarbeitung jedes Protokollsatzes vorgenommen. Aktualisierungen werden nicht regelmäßig ausgeführt, da die Protokollsätze unterschiedliche Größen haben.

Beispielausgabe des Befehls GET SNAPSHOT FOR ALL APPLICATIONS

                        Momentaufnahme einer Anwendung

Anwendungskennzeichen        = 6
Anwendungsstatus             = ROLLBACK-Operation aktiv
      Startzeit              = 20/02/2004 12:49:27.713720
      Abgeschlossene Arbeit  = 1024000 Byte
      Gesamte Arbeit         = 4084000 Byte

            Momentaufnahme einer Anwendung

Anwendungskennzeichen        = 10
Anwendungsstatus             = Ausführung von Rollback zum Sicherungspunkt
      Startzeit              = 20/02/2004 12:49:32.832410

      Abgeschlossene Arbeit  = 102400 Byte
      Gesamte Arbeit         = 2048000 Byte

Anmerkung:

Wenn die Verwendung von ROLLBACK-Operationen während einer Momentaufnahme nicht aktiv ist, werden keine ROLLBACK-Elemente angezeigt.

XML Extender

| | |

Änderung der Parameter für die gespeicherten Prozeduren dxxGenXML, dxxGenXMLClob, dxxRetrieveXML und dxxRetrieveXMLClob

Für die folgenden gespeicherten Prozeduren hat sich die Beschreibung des Parameters override geändert:

dxxGenXML()

dxxGenXMLClob()

dxxRetrieveXML()

dxxRetrieveXMLClob()

| |Die Änderung lautet wie folgt:

|Parameter | |||||||||||||||||

Tabelle 42. Parameter 'override' für die gespeicherten Prozeduren dxxGenXML, dxxGenXMLClob, dxxRetrieveXML und dxxRetrieveXMLClob
Parameter	Beschreibung	IN/OUT-Parameter
`override`	Überschreibt die Bedingung in der DAD-Datei. Der Eingabewert basiert auf `overrideType`. \| \| NO_OVERRIDE: Gibt eine Nullzeichenfolge an. \| SQL_OVERRIDE: Gibt eine gültige SQL-Anweisung an. Die Verwendung dieses `overrideType` erfordert die Verwendung der SQL-Zuordnung in der DAD-Datei. \|Die Eingabe-SQL-Anweisung überschreibt SQL_stmt in der DAD-Datei. \| XML_OVERRIDE: Ist eine Zeichenfolge, die mindestens einen Ausdruck enthält, wobei Ausdrücke mit dem Wort AND getrennt werden. Wenn Sie diesen `overrideType` verwenden, muss in der DAD-Datei die RDB_node-Zuordnung verwendet werden.	IN

| | |

Zerlegen von XML-Dokumenten in DB2 UDB-Daten

|Zerlegung von Tabellengrößenbegrenzungen

Über die RDB_node-Zuordnung wird bei der Zerlegung angegeben, wie durch Extrahieren der Element- und Attributwerte und durch Speichern dieser Werte in Tabellenzeilen ein XML-Dokument in einzelne DB2 UDB-Tabellen zerlegt wird. Die Werte aus den einzelnen XML-Dokumenten werden in mindestens einer DB2 UDB-Tabelle gespeichert. Jede Tabelle kann maximal 10240 Zeilen aufweisen, die aus jedem Dokument durch Zerlegung gewonnen werden.

Wenn z. B. ein XML-Dokument in fünf Tabellen zerlegt wird, kann jede der fünf Tabellen bis zu 10240 Zeilen für dieses eine Dokument aufweisen. Wenn die Tabelle Zeilen für mehrere Dokumente enthält, kann Sie bis 10240 Zeilen für jedes Dokument aufweisen.

Das mehrfache Vorkommen von Elementen (Elementen mit Standortpfaden, die in der XML-Struktur mehrmals vorkommen können) wirkt sich auf die Anzahl der Zeilen aus. Ein Dokument, das z. B. das Element <Part> 20 Mal enthält, kann in einer Tabelle in 20 Zeilen zerlegt werden. Wenn Sie mehrfach vorkommende Elemente verwenden, müssen Sie beachten, dass aus einem Dokument maximal 10240 Zeilen in einer einzige Tabelle zerlegt werden können.

Zerlegen von Dokumenten, die größer als 1 MB sind

Sie müssen die gespeicherte Prozedur dxxShredXML nicht löschen und erneut erstellen, um Dokumente zu zerlegen, die größer als 1 MB sind. Wenn Sie Dokumente zerlegen möchten, die größer als 1 MB sind, rufen Sie die gespeicherte Prozedur dxxShredXML100MB auf, die bis zu 100 MB große Dokumente zerlegen kann. Obwohl dxxShredXML100MB große Dokumente verarbeiten kann, müssen Sie u. U. andere Ressourcen vergrößern, um diese gespeicherte Prozedur erfolgreich ausführen zu können. Zum Aufruf der gespeicherten Prozedur über das Beispielprogramm dxxshrd können Sie das neue Flag "-large" verwenden. Beispiel:

dxxshrd -large meine_db xxx.xml

Wenn Ihre Version von DB2 Universal Database älter als Version 8 FixPak 6 ist, müssen Sie dxxMigv ausführen, um XML Extender auf die aktuelle Stufe zu migrieren und die neue gespeicherte Prozedur ausführen zu können.

Konfigurieren von benutzerdefinierten MQ-XML-Funktionen mit XML Extender

Sie müssen benutzerdefinierte MQ-XML-Funktionen (UDFs) konfigurieren und aktivieren, bevor Sie sie verwenden können.

Voraussetzungen

Installieren Sie die benutzerdefinierten Funktionen anhand der Prozedur im Thema "DB2 WebSphere MQ-Funktionen installieren" in DB2 Information - Unterstützung bzw. im entsprechenden Abschnitt des Handbuchs IBM DB2 Information Integrator Application Developer's Guide.

Vorgehensweise

Gehen Sie wie folgt vor, um benutzerdefinierte MQ-XML-Funktionen mit XML Extender zu konfigurieren und zu aktivieren:

Öffnen Sie ein DB2-Eingabeaufforderungsfenster.
Stellen Sie eine Verbindung zu der Datenbank her, die die benutzerdefinierten MQ-XML-Funktionen verwenden wird, indem Sie folgenden Befehl eingeben:
```
db2 connect to <datenbank>
```
Wechseln Sie in das Verzeichnis bnd in dem Pfad, in dem Sie DB2 Universal Database installiert haben. Beispiel:
- SQLLIB/bnd (Linux und UNIX)
- C:\Programme\IBM\SQLLIB\bnd (Windows)
Binden Sie die Datenbank mit folgendem Befehl an XML Extender:
```
db2 bind @dbxxbind.lst
```
Binden Sie die Datenbank für XML Extender mit folgendem Befehl, so dass sie die benutzerdefinierten MQ-XML-Funktionen verwendet:
```
db2 bind mqxml.bnd
```
Binden Sie die Datenbank mit folgendem Befehl an die CLI:
```
db2 bind @db2cli.lst
```

XML Extender-Umgebungsvariable DB2DXX_MIN_TMPFILE_SIZE

DB2 XML Extender kann große Dokumente in temporären Dateien speichern, damit der Speicherbedarf während der Verarbeitung nicht zu hoch ist. Bei Systemen mit einer hohen physischen Speicherkapazität kann das Versetzen von Dokumenten in temporäre Dateien vermieden werden, so dass die Ein-/Ausgabeakti- vität reduziert wird. Die Umgebungsvariable DB2DXX_MIN_TMPFILE_SIZE veranlasst XML Extender dazu, zur Verarbeitung von Dokumenten, die kleiner sind als der angegebene Wert, anstelle von temporären Dateien Speicherpuffer zu verwenden. Die Variable ist nur auf dem Server gültig. Wenn in einer partitionierten Umgebung mehrere physische Knoten vorhanden sind, kann die Variable für jeden Knoten anders gesetzt werden, um die Speicherkapazität jedes Computers korrekt wiederzugeben. Wenn die Umgebungsvariable nicht gesetzt ist, werden Dokumente mit einer Größe von mehr als 128 KB während der Verarbeitung automatisch in temporären Dateien gespeichert. Dokumente, die kleiner als 128 KB sind, werden im Hauptspeicher verarbeitet.

Neudefinition des benutzerdefinierten Datentyps DB2XML.XMLVarchar

Sie können den benutzerdefinierten Datentyp (User-Defined Type - UDT) DB2XML.XMLVarchar auf bis zu 32 KB erneut definieren. Zum Ändern der Größe eines benutzerdefinierten XMLVarchar-Datentyps erstellen Sie den benutzerdefinierten Datentyp, bevor Sie die Datenbank für XML Extender aktivieren.

Weitere Informationen finden Sie im Handbuch DB2 XML Extender Verwaltung und Programmierung.

[ Seitenanfang |Vorherige Seite | Inhaltsverzeichnis ]