Änderungsmarkierungen zeigen an, dass Text hinzugefügt oder geändert wurde. Ein vertikaler Balken ( | ) markiert Informationen, die in Version 8.2 FixPak 4 (äquivalent zu Version 8.1 FixPak 11). hinzugefügt oder geändert wurden.
Es kann vorkommen, dass Sie ein DB2(R)-Produkt installieren müssen, das eine andere Stufe aufweist als die Version eines anderen, momentan installierten DB2(R)-Produkts. DB2-Produkte müssen dieselbe Stufe aufweisen.
Wenn das Produkt, das Sie installieren, neuer ist als die Version anderer DB2-Produkte auf demselben Computer, müssen Sie die vorhandenen DB2-Produkte aktualisieren. Wenn Sie z. B. die FixPak-Stufe 10 von DB2 Connect(TM) für iSeries(TM) installieren und die übrigen DB2-Produkte die FixPak-Stufe 9 aufweisen, müssen Sie FixPak 10 auf die momentan installierte DB2-Produkte anwenden, bevor Sie die FixPak-Stufe 10 von DB2 Connect(TM) für iSeries(TM) installieren.
Wenn Sie umgekehrt ein Produkt auf einem Computer installieren, auf dem eine neuere Version eines DB2-Produkts installiert ist, müssen Sie einige Richtlinien beachten:
db2licm -a dateinameDabei ist dateiname der Name der Lizenzdatei, die sich auf dem Originaldatenträger im Verzeichnis db2\license befindet. Diese Lizenz können Sie auch dem Verzeichnis db2\license des FixPaks hinzufügen. Dann wird die Lizenz bei der Installation mitinstalliert.
Bevor Sie ein zusätzliches Produkt oder eine zusätzliche Komponente installieren, müssen Sie Folgendes stoppen:
Es müssen die Exemplare und der DB2-Verwaltungsserver gestoppt werden, die zu der DB2-Installation gehören, für die das zusätzliche DB2-Produkt oder die zusätzliche DB2-Komponente installiert werden soll.
Weitere Anweisungen hierzu finden Sie in der Readme-Datei des FixPaks.
Wenn der DB2-Verwaltungsserver auf dem aktuellen System nicht vorhanden ist und das zusätzliche Produkt oder die zusätzliche Komponente den DB2-Verwaltungsserver voraussetzt oder unterstützt, konfiguriert das Programm db2setup den DB2-Verwaltungsserver während der Installation. Auf einigen Plattformen können während der Erstellung des DB2-Verwaltungsservers mit Hilfe von db2setup Fehler auftreten. Diese Fehler werden erwartet und können ignoriert werden.
Das Programm db2setup befindet sich auf der DB2-Produkt-CD oder im Image für das zusätzliche Produkt oder die zusätzliche Komponente, das/die Sie installieren.
Detaillierte Informationen zur Verwendung von db2setup finden Sie im Handbuch Command Reference und im Handbuch DB2 Installation und Konfiguration Ergänzung.
Die Installationsprozedurdb2_install befindet sich auf der DB2-Produkt-CD oder im Image für das zusätzliche Produkt oder die zusätzliche Komponente, das/die Sie installieren.
Detaillierte Informationen zur Verwendung der Prozedur db2_install finden Sie im Handbuch DB2 Installation und Konfiguration Ergänzung.
Detaillierte Informationen zur Verwendung des Installationsprogramms des Betriebssystems finden Sie im Handbuch DB2 Installation und Konfiguration Ergänzung.
Zur Veranschaulichung wird im folgenden Beispiel die folgende Konfiguration vorausgesetzt:
Als Installationsabschluss müssen Sie das reguläre FixPak 10 erneut anwenden.
Das Paket db2cliv81 ist bereits auf dem System installiert. Die Installation des Patch-Codes nnnnnnn-nnn wurde abnormal beendigt. Zur Neuinstallation dieses Patch-Code diesen zuerst deinstallieren und danach neu installieren.Dieser Fehler tritt auf, weil db2cliv81 auf dem System bereits dieselbe Stufe aufweist wie das FixPak, das gerade installiert wird. Diese Art von Fehler können Sie ignorieren. Verwenden Sie das Installationsprogramm des Betriebssystems, um sicherzustellen, dass die DB2-Komponente oder das DB2-Paket dieselbe Stufe aufweist wie das FixPak, das gerade installiert wird.
Wenn Sie eine Datenbank mit DB2 Universal Database Version 8.2 erstellen, können Sie diese Datenbank nicht mit dem Versionsstand 8.1 verwenden. Diese Datenbank kann nur mit dem Versionsstand 8.2 oder höher verwendet werden.
Datenbanken, die mit dem DB2 UDB-Versionsstand 8.2 erstellt wurden, verfügen unter Umständen über zusätzliche Funktionen, die in älteren Versionen nicht verfügbar waren. Dieser Unterschied kann zu unerwartetem und unerwünschtem Verhalten führen, wenn Sie versuchen, Ihre neue Datenbank in ein Vorgängerrelease von DB2 UDB zu versetzen.
Im Kapitel "Übersicht über DB2-Clients" des Handbuchs IBM DB2 UDB für DB2-Clients Einstieg 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, das DB2-Unterstützungsteam unterstützt diese Konfiguration jedoch nur so lange, wie Version N vertrieben wird. Sobald Version N nicht mehr vertrieben wird, wird diese Konfiguration vom DB2-Unterstützungsteam nicht mehr unterstützt. DB2-Clients der Version 7, die eine Verbindung zu einem DB2-Server der Version 8 herstellen, werden vom DB2-Unterstützungsteam nicht mehr unterstützt, da Version 7 vom Markt genommen wurde.
Alle in DB2 UDB Version 8.2 vorgenommenen Änderungen der Registrierdatenbank gehen verloren, wenn Sie zurück auf DB2 UDB Version 8.1 migrieren. Die Registrierungsdatenbank wird auf die Datei 'HealthRules.reg' von Version 8.1 zurückgesetzt. Diese Datei enthält die Einstellungen, die vor dem Upgrade auf DB2 UDB Version 8.2 galten und bevor die Einstellungen in der Datei 'HealthRules2.reg' verwendet wurden.
Vor DB2 Universal Database (UDB) Version 8 konnten FixPaks nur als Aktualisierungen installierter DB2 UDB-Pakete oder -Dateigruppen an einer bestimmten Speicherposition verwendet werden. Dies bedeutete, dass FixPak-Installationen vorhandene Dateien durch aktualisierte Dateien ersetzten, die im FixPak enthalten waren. Mehrere DB2-FixPak-Stufen konnten nicht parallel auf einem System vorhanden sein. Ab sofort können auf Linux(TM)-- und UNIX(R)--Systemen mehrere FixPak-Stufen von DB2 UDB Enterprise Server (ESE) auf einem System verwendet werden. Diese Funktion, die in der Produktionsumgebung ab Version 8.1.2 unterstützt wird, wird mit folgenden beiden FixPak-Typen sichergestellt:
Führen Sie eine der folgenden Operationen aus, um ein Exemplar mit mehreren FixPaks auf eine andere FixPak-Stufe zu aktualisieren:
Weitere Informationen zu alternativen FixPaks finden Sie an folgenden Stellen:
Ab Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) kann der Inhalt der Query Patroller-Steuertabelle TRACK_QUERY_INFO, die in einer 32-Bit-Umgebung erfasst wurde, in einer 64-Bit-Umgebung verwendet werden. Dadurch wird die Migration auf einer 64-Bit-Umgebung erleichtert. Die in Version 8.2.2 erfassten Informationen der Query Patroller-Steuertabelle können nicht verwendet werden, um unter einer älteren FixPak-Stufe Protokolldaten für diese Abfrage zu generieren oder angehaltene Abfragen auszuführen.
Die folgenden Einschränkungen gelten für die Unterstützung von Servern einer älteren Version durch die Data Warehouse-Zentrale von DB2 Universal Database (UDB) Enterprise Server Edition Version 8:
Bei Verwendung der Entwicklungszentrale auf einem Anwendungsentwicklungsclient für DB2 Universal Database (UDB) Version 8 unter Windows oder UNIX müssen die folgenden APARs auf dem Server installiert werden, um die Unterstützung für SQLJ und SQL Assist zu aktivieren:
Sie können über DB2 Universal Database Version 8 sowohl Version 7 als auch Version 8 von SQL Assist aufrufen. Version 7 können Sie über die DB2 Data Warehouse-Zentrale starten. Alle übrigen Zentralen starten die neueste Version 8. Die Onlinehilfefunktion des Produkts enthält weitere Informationen zu SQL Assist Version 7.
In Version 7 ignorierten Unicode-Server grafische Codepages von Anwendungen während der Verbindungsdauer, und es wurde angenommen, dass UCS2 Unicode (Codepage 1200) verwendet wurde. Unicode-Server der Version 8 akzeptieren nun die vom Client gesendete Codepage.
DB2 UDB Version 8.2 verwendet eine neue 16-KB-Datenbankkonfigurationsparameterdatei mit dem Namen SQLDBCONF. Dies ist andere Datei als die 4-KB-Datenbankkonfigurationsparameterdatei von DB2 UDB Version 8.1 mit dem Namen SQLDBCON.
Nach der Migration auf DB2 UDB Version 8.2 migriert das Produkt den Inhalt der 4-KB-Datei von Version 8.1 und verwendet die 16-KB-Datei zum Protokollieren der Änderungen an den Datenbankkonfigurationsparametern. Die 4-KB-Datei der Version 8.1 wird beibehalten, aber nicht verwendet.
Wenn Sie zurück auf DB2 UDB Version 8.1 migrieren, verwendet DB2 UDB Version 8.1 wieder die ursprüngliche 4-KB-Datei der Version 8.1 zum Protokollieren der Änderungen an den Datenbankkonfigurationsparametern. Die 16-KB-Datei der Version 8.2 wird beibehalten, aber nicht von DB2 UDB Version 8.1 erkannt. Änderungen, die zwischen der Migration auf Version 8.2 und der Migration zurück auf Version 8.1 an der 16-KB-Datenbankkonfigurationsparameterdatei vorgenommen wurden, sind für die frühere DB2 UDB-Stufe verborgen, da die Änderungen nicht in die ursprüngliche 4-KB-Datei migriert werden.
Wenn Sie wieder auf DB2 UDB Version 8.2 migrieren, erkennt DB2 UDB Version 8.2 darüber hinaus, dass die 16-KB-Datenbankkonfigurationsdatei bereits vorhanden ist, und verwendet wieder die 16-KB-Datei der Version 8.2 zum Protokollieren der Änderungen an den Datenbankkonfigurationsparametern. Die 4-KB-Datei der Version 8.1 wird beibehalten, sie wird aber von DB2 UDB Version 8.2 nicht erkannt. Änderungen, die zwischen der Migration zurück auf Version 8.1 und der erneuten Migration auf Version 8.2 an der 4-KB-Datenbankkonfigurationsparameterdatei vorgenommen wurden, sind für die aktuellere DB2 UDB-Stufe verborgen, da die Änderungen nicht in die vorhandene 16-KB-Datei migriert werden.
Das Format der Datei 'db2diag.log' weist in Version 8.2 eine Reihe von Verbesserungen auf. Es ist jetzt einfacher, die Protokolldatei manuell zu lesen und im Rahmen von Software syntaktisch zu analysieren. Folgende Verbesserungen wurden vorgenommen:
Darüber hinaus wurden weitere Änderungen vorgenommen. Zum Beispiel wurde der Name des Datenbankfelds in DB geändert.
In die Datei 'db2diag.log' wurden Ereignisdatensätze als Diagnosenachricht aufgenommen. Beispiele für solche Ereignisse:
Bei Ereignisdatensätzen ist im Feld LEVEL "Event" angegeben. Obwohl es sich bei Ereignissen nicht um Fehler handelt, können sie je nach ihrer Wichtigkeit trotzdem mit einer anderen Diagnosestufe als 4 (Informativ) oder 3 (Warnung) protokolliert werden.
Ab Version 8.2 werden die folgenden Aktualisierungen in der Datei db2diag.log protokolliert:
Die Nachrichten für diese Aktualisierungen werden auf Grund ihrer Wichtigkeit mit hohen Diagnosestufen protokolliert.
Folgende db2set-Aktualisierungstypen der Profilregistrierdatenbank werden protokolliert:
2004-04-22-19.19.14.156959-240 I79582C286 LEVEL: Event PID : 2437242 TID : 1 PROC : db2set INSTANCE: db2user NODE : 000 FUNCTION: DB2 UDB, oper system services, db2set_main, probe:40 CHANGE : CFG DB2SET: DB2DBDFT: From: "OLDDB" To: "SAMPLE"
CHANGE : CFG DB2SET: DB2DBDFT: From: "SAMPLE" To: ""
CHANGE : CFG DB2SET: Profile registry was reset
Es folgen Beispiele für Aktualisierungen von Konfigurationsparametern für die Datenbank bzw. den Datenbankmanager:
CHANGE : CFG DB SAMPLE: "Maxlocks" From: "10" To: "20" CHANGE : CFG DBM: "Diaglevel" From: "3" To: "1" CHANGE : CFG DBM: Reset to the system defaults
Verwenden Sie das Tool db2diag, um diese Nachrichten zur Konfigurationsaktualisierung zu finden. Beispiel:
DB2 Universal Database(TM) (UDB) für Linux, UNIX und Windows(R) Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) unterstützt JDK 1.4.2 in allen von DB2 UDB unterstützten 32-Bit- und 64-Bit-Betriebssystemumgebungen für Workstations. Diese Unterstützung umfasst, ist aber nicht beschränkt auf, die Unterstützung für das Erstellen und Ausführen von Java(TM)-Clientanwendungen, das Erstellen und Ausführen von Java(TM)-Routinen über die Befehlszeile, das Erstellen und Ausführen von Java(TM)-Routinen über die DB2-Entwicklungszentrale sowie für das Ausführen anderer DB2-Tools.
Wenn Sie DB2 UDB Version 8.2 installieren, wird die aktuell unterstützte Version des Java Developer Kit ebenfalls installiert, sofern sie nicht bereits installiert ist und es sich bei der DB2 UDB-Installation nicht um eine Aktualisierung für DB2 UDB Version 8 handelt. Wenn Sie eine vorherige Installation von DB2 UDB Version 8 aktualisieren, müssen Sie das Java Developer Kit von der CD installieren.
In der folgenden Tabelle sind die von DB2 unterstützten 32-Bit- und 64-Bit-Betriebssystemumgebungen für Workstations und die aktuell unterstützte JDK-Stufe für jede Umgebung aufgelistet. Informationen zur Unterstützung früherer JDK-Stufen finden Sie auf der Webseite für die Entwicklung von Java-Anwendungen unter http://www.ibm.com/software/data/db2/udb/ad/v8/java/.
| Von DB2 unterstützte Umgebung | Aktuell unterstützte JDK-Stufe |
|---|---|
| Windows IA/AMD (32 Bit) | JDK 1.4.2 |
| Windows IA (64 Bit) | JDK 1.4.2 |
| Windows AMD/EM64T (64 Bit) | JDK 1.4.2 |
| AIX(R) 4.3.3 (32 Bit) | JDK 1.3.1 SR6 [2] |
| AIX(R) 5 (Hybrid [1]) | JDK 1.4.2 |
| Solaris (Hybrid [1]) | JDK 1.4.2 |
| HPUX RISC & Itanium (Hybrid [1]) | JDK 1.4.2.01 |
| Linux AMD/EM64T (32 Bit, 64 Bit) (Hybrid [1]) | JDK 1.4.2 [3] |
| Linux IA (32 Bit) | JDK 1.4.2 |
| Linux IA (64 Bit) | JDK 1.4.2 |
| Linux 390 (31 Bit) | JDK 1.4.2 |
| Linux 390 (64 Bit) | JDK 1.4.2 |
| Linux PPC (Hybrid [1]) | JDK 1.4.2 |
Im folgenden Abschnitt wird eine aktualisierte Prozedur zum Einrichten der Linux-Java-Umgebung beschrieben.
Gehen Sie wie folgt vor, um Java-Anwendungen unter Linux mit DB2-JDBC-Unterstützung zu erstellen:
Um gespeicherte Java-Prozeduren oder benutzerdefinierte Funktionen ausführen zu können, muss der Linux-Laufzeitverbindungseditor in der Lage sein, auf bestimmte gemeinsam genutzte Java-Bibliotheken zuzugreifen, und DB2 UDB muss in der Lage sein, sowohl diese Bibliotheken als auch die Java Virtual Machine zu laden. Der Prozess, der gespeicherte Prozeduren und benutzerdefinierte Funktionen ausführt, lädt Bibliotheken nur an sicheren Speicherpositionen, wie sie in der Datei /etc/ld.so.conf definiert sind. Eine dieser sicheren Speicherpositionen ist /usr/lib. Die übrigen Anweisungen zeigen, welche Bibliotheken symbolische Verbindungen in /usr/lib erfordern.
cd /usr/lib ln -fs JAVAHOME/jre/bin/libjava.so . ln -fs JAVAHOME/jre/bin/classic/libjvm.so . ln -fs JAVAHOME/jre/bin/libhpi.so .Dabei ist JAVAHOME das Basisverzeichnis für das IBM(R) Developer Kit. Wenn DB2 UDB diese Bibliotheken nicht finden kann, und Sie versuchen, eine Java-Routine auszuführen, erhalten Sie einen Fehler -4301, und das Protokoll mit Benachrichtigungen für die Systemverwaltung wird Nachrichten zu nicht gefundenen Bibliotheken enthalten.
cd /usr/lib ln -fs JAVAHOME/jre/bin/libjava.so ln -fs JAVAHOME/jre/bin/classic/libjvm.so ln -fs JAVAHOME/jre/bin/libhpi.so ln -fs JAVAHOME/jre/bin/libjsig.soDabei ist JAVAHOME das Basisverzeichnis für das IBM Developer Kit. Wenn DB2 UDB diese Bibliotheken nicht finden kann, und Sie versuchen, eine Java-Routine auszuführen, erhalten Sie einen Fehler -4301, und das Protokoll mit Benachrichtigungen für die Systemverwaltung wird Nachrichten zu nicht gefundenen Bibliotheken enthalten.
cd /usr/lib ln -fs JAVAHOME/jre/bin/libjava.so ln -fs JAVAHOME/jre/bin/classic/libjvm.so ln -fs JAVAHOME/jre/bin/libhpi.so ln -fs JAVAHOME/jre/bin/libjsig.so ln -fs JAVAHOME/jre/bin/libjitc.so ln -fs JAVAHOME/jre/bin/libxhpi.so ln -fs JAVAHOME/jre/bin/libdbgmalloc.soDabei ist JAVAHOME das Basisverzeichnis für das IBM Developer Kit. Wenn DB2 UDB diese Bibliotheken nicht finden kann, und Sie versuchen, eine Java-Routine auszuführen, erhalten Sie einen Fehler -4301, und das Protokoll mit Benachrichtigungen für die Systemverwaltung wird Nachrichten zu nicht gefundenen Bibliotheken enthalten.
JAVAHOME/jre/binDabei ist JAVAHOME das Basisverzeichnis für das IBM Developer Kit. Wenn DB2 UDB diese Bibliotheken nicht finden kann und Sie versuchen, eine Java-Routine auszuführen, erhalten Sie den Fehler -4301 oder -1042.
Statt explizit Verbindungen zu den gemeinsam genutzten Bibliotheken im Verzeichnis /usr/lib zu erstellen, können Sie der Datei /etc/ld.so.conf den Namen des Verzeichnisses hinzufügen, in dem sich die gemeinsam genutzte Java-Bibliothek befindet. Zur Bearbeitung dieser Datei müssen Sie über Rootberechtigung verfügen. Nach dem Ändern der Datei /etc/ld.so.conf müssen Sie den Befehl ldconfig als Root ausführen, damit die Änderungen wirksam werden. Wenn bei der Ausführung dieser alternativen Prozedur Probleme auftreten, erstellen Sie die Verbindungen im Verzeichnis /usr/lib wie zuvor beschrieben.
Wenn Sie mit dem 64-Bit-Betriebssystem Microsoft XP (2600) arbeiten, und dieses Betriebssystem für die Verwendung des NetBIOS-Protokolls mit der DB2-Produktfamilie konfiguriert ist, benötigen Sie einen Hotfix von Microsoft. Wenden Sie sich unter Angabe des Knowledge Base-Artikels Nummer Q317437 an Microsoft.
Das Betriebssystem Windows XP Home Edition wird nur von Produkten von DB2 Universal Database (UDB) Personal Edition unterstützt.
Das Betriebssystem Windows XP Professional wird von den folgenden DB2-Produkten unterstützt:
Die folgenden DB2-Produkte werden unter Windows XP nur für Entwicklungs- und Testzwecke unterstützt (Produktionsumgebungen erfordern Windows 2000 oder Windows Server 2003):
In DB2 Universal Database(TM) (UDB) Version 8.2 konnten Kunden von DB2 UDB Workgroup Server Edition und DB2 UDB Express Edition (wenn die Lizenz auf dem Preismodell pro Benutzer basierte) die gegen Aufpreis erhältliche DB2 UDB HADR-Option (High Availability Disaster Recovery) nicht installieren. Dieses Problem ist in DB2 UDB Version 8.2 FixPak 1 (äquivalent zu Version 8.1 FixPak 8) behoben worden.
Die OLAP-Dienstprogramme in DB2 Warehouse Manager Standard Edition Version 8.2 sind nicht kompatibel mit IBM DB2 OLAP Server FixPak 3 (Essbase-API-Stufe 6.5.4) und höher. Es wird empfohlen, DB2 OLAP Server FixPak 2 (Essbase 6.5.3) oder tiefer zu verwenden, bis dieses Problem beseitigt ist.
Vor DB2 Universal Database (UDB) Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) erforderte die Verwendung von Protokollen mit Einheiten für die unformatierte Ein-/Ausgabe (Raw I/O) das Binden einer physischen Einheit an den Linux-Treiber für unformatierte Zeicheneinheiten mit Hilfe des Dienstprogramms raw. Ab DB2 UDB Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) kann die unformatierte Ein-/Ausgabe für Protokolle unter dem 2.6-Linux-Kernel direkt angegeben werden. Wenn Sie beispielsweise die Einheitenpartition /dev/sdb1 für unformatierte Protokolle für die Datenbank SAMPLE verwenden wollen, setzen Sie den folgenden Befehl ab:
db2 update db cfg for sample using newlogpath /dev/sdb1
Obwohl DB2 UDB weiterhin die Verwendung des Dienstprogramms raw für die 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.
DB2 Universal Database Version 8.2 unterstützt die Versionen 3 und 2.1 von Red Hat Enterprise Linux AS. Die Data Warehouse-Zentrale unterstützt jedoch nur Red Hat Enterprise Linux AS Version 2.1. Die Data Warehouse-Zentrale verwendet DataDirect-ODBC-Treiber, die Red Hat Enterprise Linux AS Version 3.1 nicht unterstützen. Daher unterstützt die Data Warehouse-Zentrale keine ODBC-Warehouse-Quellen und -Warehouse-Ziele einer Agentensite von Red Hat Enterprise Linux AS Version 3.1.
Wenn Sie Anwendungen in einer IBM(R) WebSphere(R) MQ-Umgebung ausführen (früher: IBM MQSeries(R)-Umgebung), kann WebSphere(R) MQ als XA-kompatibler Transaktionsmanager fungieren, der alle verteilten Transaktionen mit zweiphasigen Festschreibungen koordiniert. Wenn WebSphere(R) MQ auf diese Weise als Transaktionsmanager fungiert und die Datenquellen zur DB2-Produktfamilie gehören, müssen mehrere Konfigurationsanforderungen erfüllt werden. Die meisten dieser Anforderungen sind bereits dokumentiert. So müssen Sie z. B. den DB2-Konfigurationsparameter TP_MON_NAME auf dem DB2 Run-Time Client auf "MQ" setzen.
Es gibt jedoch eine Konfigurationsanforderung, die nicht dokumentiert ist. Diese Anforderung bezieht sich auf DB2 Connect beim Herstellen der Verbindung zu Datenquellen, die DB2 für OS/390(R)-Server sind: Wenn Sie verteilte Transaktionen mit Hilfe von WebSphere MQ koordinieren und DB2 für z/OS(R)- und DB2 für iSeries-Server betroffen sind, muss am Gateway der DB2 Connect-Verbindungskonzentrator aktiviert sein. Der Verbindungskonzentrator ist aktiviert, wenn der Wert des Konfigurationsparameters MAX_CONNECTIONS größer ist als der Wert von MAX_COORDAGENTS. Wenn Sie den Verbindungskonzentrator nicht aktivieren, bewirkt dies ein unerwartetes Transaktionsverhalten.
Die japanische Windows-Codepage Shift-JIS von Microsoft ist als IBM CCSID 943 (ID des codierten Zeichensatzes) registriert. Auf HP-UX-Plattformen ist die Codepage Shift-JIS jedoch als CCSID 5039 registriert. CCSID 5039 enthält nur Zeichen des japanischen Industriestandards (JIS) und keine vom Hersteller definierten Zeichen. Sie können eine DB2 Universal Database-Datenbank mit CCSID 5039 unter HP-UX zur Speicherung von Shift-JIS-Zeichen verwenden. Es findet allerdings eine Codepage-Konvertierung zwischen CCSID 5039 und CCSID 943 statt. Bei Verwendung von Microsoft-ODBC-Anwendungen treten bei der Datenkonvertierung von CCSID 5039 in Unicode möglicherweise Fehler auf, da sich die IBM Codepage-Konvertierungstabelle von der Microsoft-Konvertierungstabelle unterscheidet.
Wenn die folgenden Zeichen von CCSID 5039 in Unicode konvertiert werden, resultieren daraus unterschiedliche Codepunkte, je nach dem, welche Konvertierungstabelle (IBM oder Microsoft) verwendet wird. Für diese Zeichen entspricht die IBM Konvertierungstabelle dem japanischen Industriestandard JISX0208 und JISX0221.
| Shift-JIS-Codepunkt (Name des Zeichens) | Primärer IBM Codepunkt (Unicode-Name) | Primärer Microsoft-Codepunkt (Unicode-Name) |
|---|---|---|
| X'815C' (Geviertstrich) | U+2014 (Geviertstrich) | U+2015 (horizontale Linie) |
| X'8160' (gewellter Bindestrich) | U+301C (gewellter Bindestrich) | U+FF5E (vollbreite Tilde) |
| X'8161' (doppelte vertikale Linie) | U+2016 (doppelte vertikale Linie) | U+2225 (parallel) |
| X'817C' (Minuszeichen) | U+2212 (Minuszeichen) | U+FF0D (vollbreites Minuszeichen) |
Das Geviertzeichen mit dem CCSID 5039-Codepunkt X'815C' wird bei Verwendung der IBM Konvertierungstabelle z. B. in den Unicode-Codepunkt U+2014 und bei Verwendung der Microsoft-Konvertierungstabelle in U+2015 konvertiert. Dies kann bei Microsoft-ODBC-Anwendungen zu Fehlern führen, da diese Anwendungen U+2014 als ungültigen Codepunkt behandeln. Zur Vermeidung dieser Fehler stellt DB2 UDB zusätzlich zur IBM Standardkonvertierungstabelle eine alternative Microsoft-Tabelle für die Konvertierung von CCSID 5039 in Unicode zur Verfügung. Ersetzen Sie die IBM Standardkonvertierungstabelle durch die alternative Microsoft-Konvertierungstabelle. Achten Sie darauf, dass die IBM Standardtabelle für die Konvertierung von Unicode in CCSID 5039 mit der Microsoft-Version übereinstimmt.
Bei der Konvertierung von CCSID 5039 in Unicode wird die DB2 Universal Database-Standardkonvertierungstabelle für Codepages verwendet. Wenn Sie eine andere Version der Konvertierungstabelle verwenden möchten, z. B. die Microsoft-Version, müssen Sie die Datei für die Standardkonvertierungstabelle (.cnv) manuell ersetzen.
Bevor Sie die vorhandene Datei für die Codepage-Konvertierungstabelle im Verzeichnis sqllib/conv ersetzen, sollten Sie eine Sicherungskopie für den Fall erstellen, dass Sie die ursprüngliche Datei später wiederherstellen möchten. Unter UNIX und Linux ist das Verzeichnis sqllib/conv mit dem Installationspfad von DB2 UDB verknüpft.
Damit das Ersetzen der Konvertierungstabelle effektiv sein kann, müssen die Konvertierungstabellen aller DB2 UDB-Clients geändert werden, die eine Verbindung zur gleichen Datenbank herstellen. Andernfalls speichern die Clients dasselbe Zeichen möglicherweise mit unterschiedlichen Codepunkten.
Führen Sie die folgenden Schritte aus, um die Standardkonvertierungstabelle von DB2 UDB zur Konvertierung von CCSID 5039 in Unicode zu ersetzen:
Die IBM CCSID für die japanische EUC-Codepage ist als CCSID 954 registriert. CCSID 954 ist eine gängige Codierung für japanische UNIX- und Linux-Plattformen. Wenn Sie zur Herstellung einer Verbindung mit einer DB2 Universal Database-Datenbank mit CCSID 954 Microsoft-ODBC-Anwendungen einsetzen, treten bei der Datenkonvertierung von CCSID 954 in Unicode möglicherweise Fehler auf. Dies liegt daran, dass sich die IBM Codepage-Konvertierungstabelle von der Microsoft-Konvertierungstabelle unterscheidet. Die IBM Konvertierungstabelle befolgt bei Zeichennamen die japanischen Industriestandards JISX0208, JISX0212 und JISX0221.
Wenn die folgenden Zeichen von CCSID 954 in Unicode konvertiert werden, resultieren daraus unterschiedliche Codepunkte, je nach dem, welche Konvertierungstabelle (IBM oder Microsoft) verwendet wird.
| EUC-JP-Codepunkt (Name des Zeichens) | Primärer IBM Codepunkt (Unicode-Name) | Primärer Microsoft-Codepunkt (Unicode-Name) |
|---|---|---|
| X'A1BD' (Geviertstrich) | U+2014 (Geviertstrich) | U+2015 (horizontale Linie) |
| X'A1C1' (gewellter Bindestrich) | U+301C (gewellter Bindestrich) | U+FF5E (vollbreite Tilde) |
| X'A1C2' (doppelte vertikale Linie) | U+2016 (doppelte vertikale Linie) | U+2225 (parallel) |
| X'A1DD' (Minuszeichen) | U+2212 (Minuszeichen) | U+FF0D (vollbreites Minuszeichen) |
| X'8FA2C3' (unterbrochener Strich) | U+00A6 (unterbrochener Strich) | U+FFE4 (vollbreiter, unterbrochener Strich) |
Das Geviertzeichen mit dem CCSID 954-Codepunkt X'A1BD' wird bei Verwendung der IBM Konvertierungstabelle z. B. in den Unicode-Codepunkt U+2014 und bei Verwendung der Microsoft-Konvertierungstabelle in U+2015 konvertiert. Auf Grund der unterschiedlichen Konvertierungszuordnung ist es möglich, dass in einer DB2 UDB-Unicode-Datenbank oder in der Grafikspalte einer DB2 UDB-954-Datenbank zwei unterschiedliche Codepunkte für dasselbe Zeichen verwendet werden. Dies kann bei Microsoft-ODBC-Anwendungen zu Fehlern führen, da diese Anwendungen U+2014 als ungültigen Codepunkt behandeln. Zur Vermeidung dieser Fehler stellt DB2 UDB zusätzlich zur IBM Standardkonvertierungstabelle eine alternative Microsoft-Tabelle für die Konvertierung von CCSID 954 in Unicode zur Verfügung. Ersetzen Sie die IBM Standardkonvertierungstabelle durch die alternative Microsoft-Konvertierungstabelle. Achten Sie darauf, dass die IBM Standardkonvertierungstabelle von Unicode in CCSID 954 mit der Microsoft-Version übereinstimmt.
Bei der Konvertierung von CCSID 954 in Unicode wird die DB2 Universal Database-Standardkonvertierungstabelle für Codepages verwendet. Wenn Sie eine andere Version der Konvertierungstabelle verwenden möchten, z. B. die Microsoft-Version, müssen Sie die Datei für die Standardkonvertierungstabelle (.cnv) manuell ersetzen.
Bevor Sie die vorhandene Datei für die Codepage-Konvertierungstabelle im Verzeichnis sqllib/conv ersetzen, sollten Sie eine Sicherungskopie für den Fall erstellen, dass Sie die ursprüngliche Datei später wiederherstellen möchten. Unter UNIX und Linux ist das Verzeichnis sqllib/conv mit dem Installationspfad von DB2 UDB verknüpft.
Damit das Ersetzen effektiv ist, müssen die Konvertierungstabellen aller DB2 UDB-Clients geändert werden, die eine Verbindung zu einer CCSID 954-Datenbank herstellen. Wenn es sich um einen japanischen Windows-Client handelt, der die ANSI-Codepage Shift-JIS (CCSID 943) verwendet, müssen Sie auch die DB2-Standardkonvertierungstabellen von CCSID 943 in Unicode in die Microsoft-Version ändern. Andernfalls speichern die Clients dasselbe Zeichen möglicherweise mit unterschiedlichen Codepunkten.
Führen Sie die folgenden Schritte aus, um die Standardkonvertierungstabelle von DB2 UDB zur Konvertierung von CCSID 954 in Unicode zu ersetzen:
Führen Sie die folgenden Schritte aus, um die Standardkonvertierungstabelle von DB2 UDB zur Konvertierung von CCSID 943 in Unicode zu ersetzen:
Wenn Sie die japanische Windows-Codepage Shift-JIS von Microsoft verwenden (bei IBM als CCSID 943 registriert), treten bei der Zeichenkonvertierung von CCSID 943 in Unicode möglicherweise die folgenden zwei Probleme auf. Dies liegt daran, dass sich die IBM Codepage-Konvertierungstabelle von der Microsoft-Konvertierungstabelle unterscheidet. Zur Vermeidung dieser Probleme stellt DB2 Universal Database (UDB) zusätzlich zu den IBM Standardkonvertierungstabellen alternative Microsoft-Tabellen für die Konvertierung von CCSID 943 in Unicode zur Verfügung.
Aus historischen Gründen werden die mehr als 300 Zeichen der Codepage CCSID 943 jeweils durch zwei oder drei Codepunkte dargestellt. Durch die Verwendung von Eingabemethodeneditoren (Input Method Editors, IMEs) und Codepagekonvertierungstabellen wird nur einer der entsprechenden Codepunkte eingegeben. Beispiel: Der Kleinbuchstabe 'i' für die römische Zahl Eins besitzt zwei äquivalente Codepunkte: X'EEEF' und X'FA40'. Die Eingabemethodeneditoren von Microsoft Windows generieren bei Eingabe von 'i' immer X'FA40'. Im Allgemeinen nutzen IBM und Microsoft die gleichen primären Codepunkte zur Darstellung eines Zeichens. Hiervon ausgenommen sind die folgenden 13 Zeichen:
| Zeichenname (Unicode-Codepunkt) | Primärer IBM Codepunkt (Shift-JIS) | Primärer Microsoft-Codepunkt (Shift-JIS) |
|---|---|---|
| Römische Zahl Eins (U+2160) | X'FA4A' | X'8754' |
| Römische Zahl Zwei (U+2161) | X'FA4B' | X'8755' |
| Römische Zahl Drei (U+2162) | X'FA4C' | X'8756' |
| Römische Zahl Vier (U+2163) | X'FA4D' | X'8757' |
| Römische Zahl Fünf (U+2164) | X'FA4E' | X'8758' |
| Römische Zahl Sechs (U+2165) | X'FA4F' | X'8759' |
| Römische Zahl Sieben (U+2166) | X'FA50' | X'875A' |
| Römische Zahl Acht (U+2167) | X'FA51' | X'875B' |
| Römische Zahl Neun (U+2168) | X'FA52' | X'875C' |
| Römische Zahl Zehn (U+2169) | X'FA53' | X'875D' |
| In Klammern gesetztes Zeichen, das einen Stub darstellt (U+3231) | X'FA58' | X'FA58' |
| Nummernzeichen (U+2116) | X'FA59' | X'8782' |
| Telefonzeichen (U+2121) | X'FA5A' | X'8754' |
IBM Produkte wie DB2 UDB verwenden grundsätzlich IBM Codepunkte, wie z. B. X'FA4A', um die großgeschriebene römische Zahl Eins ('I') darzustellen. Bei Microsoft-Produkten wird das gleiche Zeichen hingegen mit X'8754' dargestellt. Eine Microsoft-ODBC-Anwendung kann das Zeichen 'I' als X'8754' in eine DB2 UDB-Datenbank mit CCSID 943 einfügen und die DB2 UDB-Steuerzentrale kann dasselbe Zeichen als X'FA4A' in die gleiche CCSID 943-Datenbank einfügen. ODBC-Anwendungen können jedoch nur die Zeilen finden, in denen 'I' als X'8754' codiert ist, und die DB2 UDB-Steuerzentrale kann nur die Zeilen finden, in denen 'I' als X'FA4A' codiert ist. Damit die DB2 UDB-Steuerzentrale das Zeichen 'I' als X'8754' auswählen kann, müssen Sie die IBM Standardtabellen für die CCSID 943-Unicode-Konvertierung durch die alternativen Konvertierungstabellen von Microsoft ersetzen.
Wenn die folgenden Zeichen von CCSID 943 in Unicode konvertiert werden, resultieren daraus abhängig von der verwendeten Konvertierungstabelle (IBM oder Microsoft) unterschiedliche Codepunkte. Die IBM Konvertierungstabelle entspricht bei diesen Zeichen dem japanischen Industriestandard JISX0208, JISX0212 und JISX0221.
| Shift-JIS-Codepunkt (Name des Zeichens) | Primärer IBM Codepunkt (Unicode-Name) | Primärer Microsoft-Codepunkt (Unicode-Name) |
|---|---|---|
| X'815C' (Geviertstrich) | U+2014 (Geviertstrich) | U+2015 (horizontale Linie) |
| X'8160' (gewellter Bindestrich) | U+301C (gewellter Bindestrich) | U+FF5E (vollbreite Tilde) |
| X'8161' (doppelte vertikale Linie) | U+2016 (doppelte vertikale Linie) | U+2225 (parallel) |
| X'817C' (Minuszeichen) | U+2212 (Minuszeichen) | U+FF0D (vollbreites Minuszeichen) |
| X'FA55' (unterbrochener Strich) | U+00A6 (unterbrochener Strich) | U+FFE4 (vollbreiter, unterbrochener Strich) |
Das Geviertzeichen mit dem CCSID 943-Codepunkt X'815C' wird bei Verwendung der IBM Konvertierungstabelle z. B. in den Unicode-Codepunkt U+2014 konvertiert. Bei Verwendung der Microsoft-Konvertierungstabelle hingegen wird er in den Codepunkt U+2015 konvertiert. Auf Grund der unterschiedlichen Konvertierungszuordnung ist es möglich, dass in einer DB2 UDB-Unicode-Datenbank zwei unterschiedliche Codepunkte für dasselbe Zeichen verwendet werden. Dies kann bei Microsoft-ODBC-Anwendungen zu Fehlern führen, da diese Anwendungen U+2014 als ungültigen Codepunkt behandeln. Zur Vermeidung dieses möglichen Problems müssen Sie die IBM Standardtabellen für die Konvertierung der Zeichen von CCSID 943 in Unicode durch die alternativen Microsoft-Konvertierungstabellen ersetzen.
Die Verwendung der alternativen Microsoft-Tabellen für die Zeichenkonvertierung von CCSID 943 in Unicode sollte jedoch auf geschlossene Umgebungen beschränkt werden, in der alle DB2 UDB-Clients und DB2 UDB-Datenbanken über die Codepage 943 verfügen und alle die gleichen alternativen Microsoft-Konvertierungstabellen verwenden. Angenommen, Sie verfügen über einen DB2 UDB-Client, der die IBM Standardkonvertierungstabellen verwendet, und über einen anderen DB2 UDB-Client, der die alternativen Microsoft-Konvertierungstabellen verwendet. Wenn nun beide Clients Daten in dieselbe DB2 UDB-Datenbank mit CCSID 943 einfügen, wird das gleiche Zeichen in der Datenbank möglicherweise mit unterschiedlichen Codepunkten gespeichert.
Zur Konvertierung zwischen CCSID 943 und Unicode werden die Standardkonvertierungstabellen von DB2 Universal Database (UDB) verwendet. Wenn Sie eine andere Version der Konvertierungstabellen verwenden wollen, wie zum Beispiel die Microsoft-Version, müssen Sie die Standarddateien mit den Konvertierungstabellen (.cnv) manuell ersetzen.
Bevor Sie die vorhandenen Konvertierungstabellendateien für Codepages im Verzeichnis sqllib/conv ersetzen, sollten Sie die Dateien für den Fall sichern, dass Sie die Ersetzung rückgängig machen wollen. Unter UNIX und Linux ist das Verzeichnis sqllib/conv mit dem Installationspfad von DB2 UDB verknüpft.
Damit das Ersetzen der Konvertierungstabelle effektiv sein kann, müssen die Konvertierungstabellen aller DB2 UDB-Clients geändert werden, die eine Verbindung zur gleichen Datenbank herstellen. Andernfalls speichern die einzelnen Clients dasselbe Zeichen möglicherweise mit unterschiedlichen Codepunkten.
Gehen Sie wie folgt vor, um die DB2 UDB-Standardtabellen für die Konvertierung von CCSID 943 in Unicode zu ersetzen:
Das Betriebssystem MVS wird von DB2 Universal Database nicht mehr unterstützt, auch wenn dies in der Dokumentation noch erwähnt wird. MVS wurde durch z/OS ersetzt.
Sicherungs- und Wiederherstellungsoperationen von mehreren bzw. auf mehrere Bandeinheiten funktionieren möglicherweise nicht, wenn Sie das Betriebssystem Linux 390 verwenden.
Für den Zugriff auf die Entwicklungszentrale unter UNIX mit Hummingbird Exceed muss die XTEST-Erweiterung Version 2.2 aktiviert werden, bevor Sie Sichten durch Ziehen der Titelleiste mit der Maus innerhalb der Entwicklungszentrale versetzen und andocken können.
Gehen Sie wie folgt vor, um die XTEST-Erweiterung zu aktivieren: