Znaczniki zmian oznaczają dodany lub zmieniony tekst. Pionowa kreska ( | ) oznacza informacje, które zostały dodane lub zmienione dla wersji 8.2, pakiet poprawek 4 (odpowiednik wersji 8.1, pakiet poprawek 11).
Może wystąpić konieczność zainstalowania produktu DB2(R) będącego na innym poziomie niż wersja innego produktu DB2(R) aktualnie zainstalowanego na komputerze. Produkty DB2 muszą być na tym samym poziomie.
Jeśli instalowany produkt jest na poziomie nowszym niż wersja innych produktów DB2 zainstalowanych na tym samym komputerze, konieczne będzie przeprowadzenie aktualizacji posiadanych produktów DB2 do nowszego poziomu. Jeśli na przykład jest instalowany program DB2 Connect(TM) for iSeries(TM) na poziomie pakietu poprawek 10, a inne produkty DB2 są na poziomie pakietu poprawek 9, przed zainstalowaniem programu DB2 Connect(TM) for iSeries(TM) na poziomie pakietu poprawek 10 należy zastosować do nich pakiet poprawek 10.
I odwrotnie, jeśli instalujesz jakiś produkt na komputerze, na którym zainstalowany jest inny produkt DB2 w nowszej wersji, postępuj zgodnie z następującymi wskazówkami:
db2licm -a nazwa_plikugdzie nazwa_pliku to nazwa pliku licencji, który można znaleźć na oryginalnym nośniku w katalogu db2\license. Licencję tę można też dodać do katalogu db2\license pakietu poprawek; wówczas licencja zostanie zainstalowana przez program instalacyjny.
Przed zainstalowaniem dodatkowego produktu lub komponentu należy zatrzymać następujące programy:
Instancje i serwer DAS, które trzeba zatrzymać, należą do instalacji programu DB2, w której będzie instalowany dodatkowy produkt lub komponent DB2.
Dodatkowe instrukcje można znaleźć w pliku readme pakietu poprawek.
Jeśli w systemie nie ma serwera DAS, a dodatkowy produkt lub komponent wymaga obsługi serwera DAS, program db2setup skonfiguruje serwer DAS podczas instalacji. Na niektórych platformach podczas tworzenia serwera DAS przez program db2setup mogą występować błędy. Błędy te są spodziewane i można je ignorować.
Program db2setup można znaleźć na dysku CD produktu DB2 albo w obrazie instalowanego dodatkowego produktu lub komponentu.
Szczegółowe informacje na temat używania programu db2setup można znaleźć w podręcznikach Command Reference i Instalowanie i konfigurowanie - suplement
Skrypt db2_install znajduje się na dysku CD produktu DB2 albo w obrazie instalowanego dodatkowego produktu lub komponentu.
Szczegółowe informacje na temat korzystania ze skryptu db2_install można znaleźć w podręczniku Instalowanie i konfigurowanie - suplement.
Szczegółowe informacje na temat korzystania z instalatora systemowego można znaleźć w podręczniku Instalowanie i konfigurowanie - suplement.
Aby zilustrować ten scenariusz, załóżmy następujące warunki:
W ramach kroku poinstalacyjnego musisz ponownie zainstalować zwykły pakiet poprawek 10.
Pakiet db2cliv81 jest już zainstalowany w systemie. Instalacja poprawki nnnnnnn-nnn została zakończona nieprawidłowo. Aby ponownie zainstalować tę poprawkę, należy ją najpierw odinstalować.Ten błąd występuje dlatego, że program db2cliv81 w systemie jest już na tym samym poziomie, co instalowany pakiet poprawek. Błąd tego typu można zignorować. Potwierdź za pomocą instalatora systemowego, że komponent lub pakiet DB2 jest rzeczywiście na tym samym poziomie, co instalowany pakiet poprawek.
Bazy danych utworzonej za pomocą programu DB2 Universal Database, wersja 8.2, nie można używać z wersją 8.1. Taka baza danych może być używana wyłącznie w wersji 8.2 lub następnych.
Bazy danych utworzone przez program DB2 UDB, wersja 8.2, mogą obsługiwać dodatkowe funkcje, które nie były dostępne we wcześniejszych wersjach. Wynikiem tej różnicy może być nieoczekiwane i niepożądane działanie w przypadku próby przeniesienia nowej bazy danych do wcześniejszej wersji programu DB2 UDB.
W sekcji "Przegląd klientów DB2" podręcznika Klienci DB2 - Krótkie wprowadzenie można znaleźć następujące stwierdzenie:
Klienci DB2 mogą łączyć się z serwerami DB2 w wersjach o dwa poziomy wyższych lub jeden poziom niższych od wersji klienta, a także z serwerami o tej samej wersji.|
Stwierdzenie to wymaga następującej poprawki:
|Chociaż połączenia klientów w wersji N z serwerami w wersji N + 2 są możliwe w niektórych środowiskach, zespół wsparcia firmy DB2 będzie zapewniał obsługę takiej konfiguracji dopóki wersja N będzie nadal obsługiwana. Po wycofaniu wsparcia wersji N taka konfiguracja przestaje być obsługiwana przez zespół wsparcia DB2. Klienci bazy danych DB2, wersja 7, łączący się z serwerem DB2, wersja 8, nie są już obsługiwani przez zespół wsparcia DB2, ponieważ wsparcie dla wersji 7 zostało wycofane.
Wszelkie zmiany rejestru dokonane w programie DB2 UDB, wersja 8.2, zostają utracone w przypadku migracji wstecznej do programu DB2 UDB, wersja 8.1. Zostaje przywrócona wersja 8.1 pliku rejestru HealthRules.reg, która zawiera ustawienia istniejące przed aktualizacją do programu DB2 UDB, wersja 8.2, i rozpoczęciem korzystania z ustawień w pliku HealthRules2.reg.
W wersjach programu DB2 Universal Database (UDB) wcześniejszych niż wersja 8 pakiety poprawek funkcjonowały tylko jako aktualizacje do zainstalowanych pakietów DB2 UDB lub zestawów plików w jednym ustalonym położeniu. Oznacza to, że instalacje pakietów poprawek zastępowały istniejące pliki zaktualizowanymi plikami zawartymi w pakietach poprawek. W jednym systemie nie mogły być jednocześnie zainstalowane różne poziomy pakietów poprawek DB2. Obecnie w systemach operacyjnych z rodziny Linux(TM) i UNIX(R) program DB2 UDB Enterprise Server Edition (ESE) może być zainstalowany jednocześnie z różnymi poziomami pakietu poprawek. Ta opcja, obsługiwana w produkcyjnym środowisku operacyjnym od wersji 8.1.2, jest osiągana przy użyciu dwóch typów pakietów poprawek:
Aby zaktualizować instancję z wieloma pakietami poprawek do innego poziomu pakietu poprawek, wykonaj jedną z następujących czynności:
Aby uzyskać dodatkowe informacje dotyczące alternatywnych pakietów poprawek:
Poczynając od wersji 8.2.2 (odpowiadającej wersji 8.1 z pakietem poprawek 9), zawartość tabeli sterującej TRACK_QUERY_INFO programu Query Patroller przechwycona w środowisku 32-bitowym może być używana w środowisku 64-bitowym. Ułatwia to migrację do środowiska 64-bitowego. Informacje przechwycone w tabeli sterującej TRACK_QUERY_INFO programu Query Patroller w wersji 8.2.2 nie mogą być używane do generowania danych historycznych dla tego zapytania ani do wykonywania zadań wstrzymanych na żadnym innym poziomie pakietu poprawek.
Obsługa poprzednich wersji serwerów przez Centrum hurtowni danych programu DB2 Universal Database (UDB) Enterprise Server Edition, wersja 8, podlega następującym ograniczeniom:
Przy korzystaniu z Centrum projektowania w programie Application Development Client dla DB2 Universal Database (UDB), wersja 8, w systemach operacyjnych Windows lub UNIX wymagane jest zainstalowanie na serwerze następujących poprawek APAR w celu uruchomienia obsługi SQLJ i Asysty SQL:
Z programu DB2 Universal Database, wersja 8, można wywołać zarówno wersję 7, jak i wersję 8 programu Asysta SQL. Wersję 7 można uruchomić z Centrum hurtowni danych DB2. Wszystkie inne centra uruchamiają najnowszą wersję 8. Pomoc elektroniczna produktu zawiera dodatkowe informacje dotyczące Asysty SQL w wersji 7.
W wersji 7 serwery używające kodu Unicode ignorowały wszelkie graficzne strony kodowe dostarczane przez aplikacje w czasie połączenia i przyjmowane było założenie, że używany jest format Unicode UCS2 (strona kodowa 1200). W wersji 8 serwery kodu Unicode respektują stronę kodową przesyłaną przez klienta.
Program DB2 UDB, wersja 8.2, korzysta z nowego pliku parametrów konfiguracyjnych bazy danych o wielkości 16 kB i nazwie SQLDBCONF. Jest to inny plik niż plik parametrów konfiguracyjnych bazy danych programu DB2 UDB, wersja 8.1, o wielkości 4 kB i nazwie SQLDBCON.
Po migracji do programu DB2 UDB, wersja 8.2, produkt dokonuje migracji zawartości pliku z wersji 8.1 o wielkości 4 kB i używa pliku o wielkości 16 kB do protokołowania zmian parametrów konfiguracyjnych bazy danych. Plik o wielkości 4 kB z wersji 8.1 zostaje zachowany, ale nie jest używany.
W przypadku migracji wstecznej do programu DB2 UDB, wersja 8.1, produkt DB2 UDB, wersja 8.1, zaczyna ponownie wykorzystywać oryginalny plik z wersji 8.1 o wielkości 4 kB do protokołowania zmian parametrów konfiguracyjnych bazy danych. Plik o wielkości 16 kB z wersji 8.2 zostaje zachowany, ale nie jest rozpoznawany przez produkt DB2 UDB, wersja 8.1. Zmiany dokonane w pliku parametrów konfiguracyjnych bazy danych o wielkości 16 kB pomiędzy migracją do wersji 8.2 i migracją wsteczną do wersji 8.1 są wobec tego ukryte przed wcześniejszą wersją programu DB2 UDB, ponieważ nie dokonuje się ich migracji do oryginalnego pliku o wielkości 4 kB.
Ponadto w przypadku ponownej migracji do programu DB2 UDB, wersja 8.2, produkt DB2 UDB, wersja 8.2, wykrywa istnienie pliku konfiguracyjnego bazy danych o wielkości 16 kB i zaczyna ponownie wykorzystywać plik wersji 8.2 o wielkości 16 kB do protokołowania zmian parametrów konfiguracyjnych bazy danych. Plik o wielkości 4 kB z wersji 8.1 zostaje zachowany, ale nie jest rozpoznawany przez produkt DB2 UDB, wersja 8.2. Zmiany dokonane w pliku parametrów konfiguracyjnych bazy danych o wielkości 4 kB pomiędzy migracją wsteczną do wersji 8.1 i ponowną migracją do wersji 8.2 są wobec tego ukryte przed nowszą wersją programu DB2 UDB, ponieważ nie dokonuje się ich migracji do istniejącego pliku o wielkości 16 kB.
W wersji 8.2 wprowadzono wiele udoskonaleń formatu pliku protokołu db2diag.log. Nowe pliki protokołu można teraz łatwiej odczytywać ręcznie i łatwiej analizować przy użyciu oprogramowania. Wprowadzono między innymi następujące udoskonalenia:
Wprowadzono także inne modyfikacje, na przykład zmieniono nazwę pola database na DB.
Rekordy zdarzeń dodano jako komunikaty diagnostyczne do pliku protokołu db2diag.log. Przykładami takich zdarzeń mogą być:
Rekordy zdarzeń mają w polu LEVEL wartość "Event". Chociaż zdarzenia nie są błędami, mogą być protokołowane na poziomie innym niż 4 (informacje) lub 3 (ostrzeżenia), zależnie od ich ważności.
Poczynając od wersji 8.2 w pliku db2diag.log protokołowane są następujące aktualizacje:
Komunikaty dotyczące tych aktualizacji są protokołowane z wysokimi poziomami diagnostycznymi z uwagi na ich ważność.
Protokołowane są następujące typy aktualizacji rejestru profili db2set:
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
Przykłady aktualizacji parametrów konfiguracyjnych DB i DBM to
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
Aby znaleźć komunikaty informujące o zaktualizowaniu konfiguracji, należy użyć narzędzia db2diag. Na przykład:
Program DB2 Universal Database(TM) (UDB) dla systemów Linux, UNIX i Windows(R), wersja 8.2.2 (odpowiednik wersji 8.1 z pakietem poprawek 9) obsługuje pakiet JDK 1.4.2 we wszystkich 32-bitowych i 64-bitowych systemach operacyjnych stacji roboczych obsługiwanych przez program DB2 UDB. Obsługa ta obejmuje w szczególności możliwość budowania i uruchamiania aplikacji klienckich Java(TM), budowania i uruchamiania podprogramów Java(TM) z wiersza komend, budowania i uruchamiania podprogramów Java(TM) z Centrum projektowania DB2 (jeśli jest obsługiwane) oraz możliwość uruchamiania innych narzędzi DB2.
Podczas instalacji programu DB2 UDB wersja 8.2 zainstalowana zostanie także najnowsza obsługiwana wersja pakietu programistycznego Java, jeśli nie jest jeszcze zainstalowana, chyba że dana instalacja programu DB2 UDB jest aktualizacją poprzedniej instalacji programu DB2 UDB wersja 8. W przypadku aktualizacji poprzedniej instalacji programu DB2 UDB wersja 8 należy zainstalować pakiet programistyczny Java z dysku CD.
W poniższej tabeli wymieniono obsługiwane przez DB2 32-bitowe i 64-bitowe systemy operacyjne dla stacji roboczych oraz najnowszy obsługiwany poziom pakietu JDK dla każdego z tych systemów. Informacje na temat obsługi wcześniejszych pakietów JDK można znaleźć na stronie poświęconej programowaniu aplikacji w języku Java pod adresem http://www.ibm.com/software/data/db2/udb/ad/v8/java/.
| Środowisko obsługiwane przez DB2 | Najnowszy obsługiwany poziom JDK |
|---|---|
| Windows IA/AMD, 32-bitowe | JDK 1.4.2 |
| Windows IA, 64-bitowe | JDK 1.4.2 |
| Windows AMD/EM64T 64-bitowe | JDK 1.4.2 |
| AIX(R) 4.3.3 32-bitowe | JDK 1.3.1 SR6 [2] |
| AIX(R) 5 (hybrydowe [1]) | JDK 1.4.2 |
| Solaris (hybrydowe [1]) | JDK 1.4.2 |
| HPUX RISC & Itanium (hybrydowe [1]) | JDK 1.4.2.01 |
| Linux AMD/EM64T, 32-bitowe, 64-bitowe (hybrydowe [1]) | JDK 1.4.2 [3] |
| Linux IA, 32-bitowe | JDK 1.4.2 |
| Linux IA, 64-bitowe | JDK 1.4.2 |
| Linux 390, 31-bitowe | JDK 1.4.2 |
| Linux 390, 64-bitowe | JDK 1.4.2 |
| Linux PPC (hybrydowe [1]) | JDK 1.4.2 |
W następnej sekcji przedstawiono zaktualizowaną procedurę konfigurowania środowiska Java w systemie Linux.
Aby możliwe było budowanie aplikacji Java na systemach Linux z obsługą DB2 JDBC:
Aby możliwe było uruchamianie procedur zapisanych w bazie lub funkcji zdefiniowanych przez użytkownika w języku Java, konsolidator środowiska wykonawczego w systemie Linux musi mieć dostęp do określonych współużytkowanych bibliotek Java, a program DB2 UDB musi mieć możliwość załadowania zarówno tych bibliotek, jak i wirtualnej maszyny Java. Proces uruchamiający procedury zapisane w bazie i funkcje zdefiniowane przez użytkownika ładuje biblioteki tylko z miejsc bezpiecznych, zdefiniowanych w pliku /etc/ld.so.conf. Jednym z tych miejsc bezpiecznych jest katalog /usr/lib. W dalszych instrukcjach wymieniono biblioteki, dla których w katalogu /usr/lib muszą istnieć dowiązania symboliczne.
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 .gdzie JAVAHOME jest katalogiem podstawowym pakietu IBM(R) Developer Kit. Jeśli program DB2 UDB nie znajdzie tych bibliotek, przy próbie uruchomienia podprogramu Java zostanie zgłoszony błąd -4301, a w protokole powiadomień administracyjnych zostaną umieszczone komunikaty informujące o nieznalezieniu bibliotek.
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.sogdzie JAVAHOME jest katalogiem podstawowym pakietu IBM Developer Kit. Jeśli program DB2 UDB nie znajdzie tych bibliotek, przy próbie uruchomienia podprogramu Java zostanie zgłoszony błąd -4301, a w protokole powiadomień administracyjnych zostaną umieszczone komunikaty informujące o nieznalezieniu bibliotek.
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.sogdzie JAVAHOME jest katalogiem podstawowym pakietu IBM Developer Kit. Jeśli program DB2 UDB nie znajdzie tych bibliotek, przy próbie uruchomienia podprogramu Java zostanie zgłoszony błąd -4301, a w protokole powiadomień administracyjnych zostaną umieszczone komunikaty informujące o nieznalezieniu bibliotek.
JAVAHOME/jre/bingdzie JAVAHOME jest katalogiem podstawowym pakietu IBM Developer Kit. Jeśli program DB2 UDB nie może znaleźć tych bibliotek, podczas próby uruchomienia procedury Java pojawia się błąd -4301 lub -1042.
Zamiast jawnie tworzyć dowiązania do bibliotek współużytkowanych Java w katalogu /usr/lib można dodać nazwę katalogu zawierającego te biblioteki do pliku /etc/ld.so.conf. Jednak operacja ta wymaga uprawnień użytkownika root. Po zaktualizowaniu pliku /etc/ld.so.conf należy uruchomić komendę ldconfig jako użytkownik root, aby uaktywnić zmiany. W razie napotkania problemów z tą procedurą alternatywną, należy utworzyć dowiązania w katalogu /usr/lib, zgodnie z wcześniejszymi instrukcjami.
Jeśli razem z produktami z rodziny DB2 używany jest 64-bitowy system operacyjny Microsoft XP (2600) skonfigurowany do pracy z protokołem NETBIOS, konieczne będzie uzyskanie poprawki od firmy Microsoft. W tym celu należy skontaktować się z firmą Microsoft w sprawie artykułu o numerze Q317437 z bazy Knowledge Base.
System operacyjny Windows XP Home Edition jest obsługiwany wyłącznie przez produkty z rodziny DB2 Universal Database (UDB) Personal Edition.
System operacyjny Windows XP Professional jest obsługiwany przez następujące produkty DB2:
Następujące produkty DB2 są obsługiwane w systemie Windows XP wyłącznie do celów programowania i testowania (w środowiskach produkcyjnych wymagany jest system Windows 2000 lub Windows Server 2003):
W przypadku oprogramowania DB2 Universal Database(TM) (UDB), wersja 8.2, klienci korzystający z programów DB2 UDB Workgroup Server Edition i DB2 UDB Express Edition (gdy licencjonowanie oparte było na modelu ceny zależnej od liczby użytkowników) nie mogli instalować sprzedawanej oddzielnie opcji DB2 UDB do usuwania skutków awarii w środowisku o wysokiej dostępności (HADR). Problem ten został rozwiązany w programie DB2 UDB, wersja 8.2, pakiet poprawek 1 (odpowiednik wersji 8.1, pakiet poprawek 8).
Narzędzia OLAP w programie DB2 Warehouse Manager Standard Edition, wersja 8.2, nie są kompatybilne z oprogramowaniem IBM DB2 OLAP Server FP3 (Essbase API poziom 6.5.4) i wersjami późniejszymi. Do czasu rozwiązania tego problemu zaleca się korzystanie z oprogramowania DB2 OLAP Server FP2 (Essbase 6.5.3) lub wersji wcześniejszej.
Aby można było używać protokołów z urządzeniami surowego we/wy w wersjach programu DB2 Universal Database (UDB) wcześniejszych niż wersja 8.2.2 (odpowiadająca wersji 8.1 z pakietem poprawek 9), należy powiązać urządzenie fizyczne ze sterownikiem surowych danych znakowych systemu Linux za pomocą programu narzędziowego raw. Poczynając od wersji 8.2.2 programu DB2 UDB (odpowiednik wersji 8.1 z pakietem poprawek 9) w systemie Linux z jądrem 2.6 można bezpośrednio używać surowego we/wy na potrzeby protokołowania. Na przykład, aby używać partycji urządzenia /dev/sdb1 do zapisywania surowych protokołów bazy danych SAMPLE, należy użyć następującej komendy:
db2 update db cfg for sample using newlogpath /dev/sdb1
Mimo iż program DB2 UDB nadal obsługuje metodę z użyciem programu narzędziowego raw do surowego we/wy, w ostatnich dystrybucjach opcja ta została uznana za nieaktualną, a w przyszłości może zostać usunięta. Preferowane jest stosowanie nowej metody, polegającej na bezpośrednim podawaniu urządzeń.
Program DB2 Universal Database, wersja 8.2, obsługuje system Red Hat Enterprise Linux AS, wersja 3 i 2.1. Jednak Centrum hurtowni danych obsługuje tylko system Red Hat Enterprise Linux AS, wersja 2.1. Centrum hurtowni danych korzysta ze sterowników DataDirect ODBC, które nie obsługują systemu Red Hat Enterprise Linux AS, wersja 3.1. Z tego powodu Centrum hurtowni danych nie obsługuje źródeł ani celów ODBC hurtowni danych z serwera agenta Red Hat Enterprise Linux AS, wersja 3.1.
W przypadku uruchamiania aplikacji w środowisku IBM(R) WebSphere(R) MQ (zwanym wcześniej IBM MQSeries(R)) program WebSphere(R) MQ może działać jako menedżer transakcji zgodny z XA, koordynujący wszelkie rozproszone transakcje zatwierdzania dwufazowego. Gdy program WebSphere(R) MQ działa w ten sposób jako menedżer transakcji, a źródła danych są z rodziny produktów DB2, obowiązuje kilka wymagań konfiguracyjnych. Większość z nich jest już udokumentowana. Na przykład na kliencie DB2 Runtime Client należy ustawić parametr konfiguracyjny TP_MON_NAME programu DB2 na "MQ".
Jest jednak jedno nieudokumentowane wymaganie konfiguracyjne. Wymaganie to dotyczy wyłącznie programu DB2 Connect łączącego się ze źródłami danych DB2 dla serwerów OS/390(R): W przypadku używania programu WebSphere MQ do koordynowania transakcji rozproszonych związanych z programem DB2 for z/OS(R) i programem DB2 for iSeries w bramie musi być włączona opcja koncentratora połączeń programu DB2 Connect. Koncentrator połączeń jest włączony, gdy wartość parametru konfiguracyjnego MAX_CONNECTIONS jest większa niż wartość MAX_COORDAGENTS. Jeśli koncentrator połączeń nie zostanie włączony, może dojść do nieoczekiwanego działania transakcji.
Strona kodowa Shift-JIS w japońskiej wersji systemu Microsoft Windows jest rejestrowana przy użyciu identyfikatora kodowanego zestawu znaków (CCSID) 943 firmy IBM. Jednak strona kodowa Shift-JIS na platformie HP-UX jest rejestrowana przy użyciu identyfikatora CCSID 5039. Na stronie kodowej o identyfikatorze CCSID 5039 występują wyłącznie znaki określone w standardzie JIS (Japanese Industry Standard) i nie występują żadne znaki zdefiniowane przez dostawcę. Na platformie HP-UX w bazie danych DB2 Universal Database (UDB) o identyfikatorze CCSID 5039 można zapisać znaki strony kodowej Shift-JIS, lecz konieczne jest wówczas wykonywanie konwersji między stronami kodowymi CCSID 5039 i CCSID 943. Jeśli używane są aplikacje korzystające z technologii Microsoft ODBC, podczas przekształcania danych z formatu CCSID 5039 na format Unicode mogą wystąpić problemy, ponieważ tabele konwersji stron kodowych firm IBM i Microsoft nie są takie same.
Poniżej przedstawiono listę znaków, dla których punkty kodowe uzyskane w wyniku konwersji z formatu CCSID 5039 na format Unicode przy użyciu tabeli konwersji firmy IBM i tabeli konwersji firmy Microsoft nie będą takie same. W przypadku tych znaków tabela konwersji firmy IBM jest zgodna ze standardami JIS (Japanese Industry Standard) JISX0208 oraz JISX0221.
| Punkt kodowy w standardzie Shift-JIS (nazwa znaku) | Pierwotny punkt kodowy używany przez firmę IBM (nazwa znaku w formacie Unicode) | Pierwotny punkt kodowy używany przez firmę Microsoft (nazwa znaku w formacie Unicode) |
|---|---|---|
| X'815C' (znak pauzy) | U+2014 (znak pauzy) | U+2015 (kreska pozioma) |
| X'8160' (znak wartości przybliżonej) | U+301C (znak wartości przybliżonej) | U+FF5E (tylda pełnej długości) |
| X'8161' (podwójna pionowa kreska) | U+2016 (podwójna pionowa kreska) | U+2225 (znak równoległości) |
| X'817C' (minus) | U+2212 (minus) | U+FF0D (łącznik pełnej długości) |
Na przykład gdy używana jest tabela konwersji firmy IBM, znak pauzy o identyfikatorze CCSID 5039 punktu kodowego X'815C' jest przekształcany na punkt kodowy Unicode U+2014, a gdy używana jest tabela konwersji firmy Microsoft, znak ten jest przekształcany na punkt kodowy U+2015. Może to być przyczyną problemów w aplikacjach wykorzystujących technologię Microsoft ODBC, ponieważ aplikacje te mogą traktować znak U+2014 jako niepoprawny punkt kodowy. Aby można było uniknąć tego problemu, w programie DB2 UDB oprócz domyślnej tabeli konwersji firmy IBM dostępna jest alternatywna tabela konwersji firmy Microsoft służąca do wykonywania konwersji strony kodowej CCSID 5039 na format Unicode. Należy zastąpić domyślną tabelę konwersji firmy IBM alternatywną tabelą konwersji firmy Microsoft. Należy zauważyć, że domyślna tabela konwersji firmy IBM służąca do przekształcania znaków w formacie Unicode na znaki strony kodowej CCSID 5039 jest zgodna z odpowiednią tabelą konwersji firmy Microsoft.
Podczas konwersji strony kodowej CCSID 5039 na format Unicode w programie DB2 Universal Database (UDB) używana jest domyślna tabela konwersji stron kodowych. Aby użyć innej tabeli konwersji (na przykład tabeli konwersji firmy Microsoft), należy ręcznie zastąpić plik domyślnej tabeli konwersji (.cnv).
Przed zastąpieniem istniejącego pliku tabeli konwersji stron kodowych w katalogu sqllib/conv należy utworzyć kopię zapasową zastępowanego pliku, aby zapewnić możliwość jego ponownego użycia. W systemach UNIX i Linux katalog sqllib/conv jest dowiązany do ścieżki instalacyjnej programu DB2 UDB.
Aby operacja przyniosła pożądany skutek, należy zmienić tabele konwersji używane przez każdego klienta DB2 UDB, który nawiązuje połączenie z określoną bazą danych. W przeciwnym razie różne aplikacje klienckie mogą zapisywać ten sam znak przy użyciu innych punktów kodowych.
Aby zastąpić domyślną tabelę konwersji programu DB2 UDB służącą do przekształcania strony kodowej CCSID 5039 na format Unicode, wykonaj następujące czynności:
Identyfikator kodowanego zestawu znaków (CCSID) firmy IBM dla japońskiej strony kodowej EUC jest rejestrowany przy użyciu identyfikatora CCSID 954. Identyfikator CCSID 954 określa powszechnie używane kodowanie dla japońskich wersji platform UNIX i Linux. Gdy do nawiązania połączenia z bazą danych programu DB2 Universal Database (UDB) o identyfikatorze CCSID 954 używane są aplikacje wykorzystujące technologię Microsoft ODBC, mogą wystąpić problemy związane z konwersją danych zestawu znaków o identyfikatorze CCSID 954 na format Unicode. Problemy te wynikają z różnic między tabelami konwersji stron kodowych firm IBM i Microsoft. Tabela konwersji firmy IBM jest zgodna z nazwami znaków zdefiniowanymi przez standardy JIS (Japanese Industry Standard) JISX0208, JISX0212 oraz JISX0221.
Poniżej przedstawiono listę znaków, których punkty kodowe uzyskane w wyniku konwersji z formatu CCSID 954 na format Unicode przy użyciu tabeli konwersji firmy IBM i tabeli konwersji firmy Microsoft będą różne.
| Punkt kodowy w standardzie EUC-JP (nazwa znaku) | Pierwotny punkt kodowy używany przez firmę IBM (nazwa znaku w formacie Unicode) | Pierwotny punkt kodowy używany przez firmę Microsoft (nazwa znaku w formacie Unicode) |
|---|---|---|
| X'A1BD' (znak pauzy) | U+2014 (znak pauzy) | U+2015 (kreska pozioma) |
| X'A1C1' (znak wartości przybliżonej) | U+301C (znak wartości przybliżonej) | U+FF5E (tylda pełnej długości) |
| X'A1C2' (podwójna pionowa kreska) | U+2016 (podwójna pionowa kreska) | U+2225 (znak równoległości) |
| X'A1DD' (minus) | U+2212 (minus) | U+FF0D (łącznik pełnej długości) |
| X'8FA2C3' (kreska przerywana) | U+00A6 (kreska przerywana) | U+FFE4 (kreska przerywana pełnej długości) |
Na przykład gdy używana jest tabela konwersji firmy IBM, znak pauzy o identyfikatorze CCSID 954 punktu kodowego X'A1BD' jest przekształcany na punkt kodowy Unicode U+2014, a gdy używana jest tabela konwersji firmy Microsoft, znak ten jest przekształcany na punkt kodowy U+2015. Z powodu tej różnicy odwzorowań konwersji w pojedynczej bazie danych DB2 UDB w formacie Unicode lub w kolumnie graficznej bazy danych DB2 UDB 954 dla pojedynczego znaku mogą występować dwa różne punkty kodowe. Może to być przyczyną problemów w aplikacjach wykorzystujących technologię Microsoft ODBC, ponieważ aplikacje te mogą traktować znak U+2014 jako niepoprawny punkt kodowy. Aby można było uniknąć tego problemu, w programie DB2 UDB oprócz domyślnej tabeli konwersji firmy IBM dostępna jest alternatywna tabela konwersji firmy Microsoft służąca do wykonywania konwersji strony kodowej CCSID 954 na format Unicode. Należy zastąpić domyślną tabelę konwersji firmy IBM alternatywną tabelą konwersji firmy Microsoft. Należy zauważyć, że domyślna tabela konwersji firmy IBM służąca do przekształcania znaków w formacie Unicode na znaki strony kodowej CCSID 954 jest zgodna z odpowiednią tabelą konwersji firmy Microsoft.
Podczas konwersji strony kodowej CCSID 954 na format Unicode w programie DB2 Universal Database (UDB) używana jest domyślna tabela konwersji stron kodowych. Aby użyć innej tabeli konwersji (na przykład tabeli konwersji firmy Microsoft), należy ręcznie zastąpić plik domyślnej tabeli konwersji (.cnv).
Przed zastąpieniem istniejącego pliku tabeli konwersji stron kodowych w katalogu sqllib/conv należy utworzyć kopię zapasową zastępowanego pliku, aby zapewnić możliwość jego ponownego użycia. W systemach UNIX i Linux katalog sqllib/conv jest powiązany ze ścieżką instalacyjną programu DB2 UDB.
Aby operacja ta przyniosła pożądany skutek, należy zmienić tabele konwersji używane przez każdego klienta DB2 UDB, który nawiązuje połączenie z tą samą bazą danych CCSID 954. Jeśli używany klient działa w japońskiej wersji systemu Windows, w którym stroną kodową ANSI jest Shift-JIS (CCSID 943), konieczne będzie także zastąpienie domyślnej tabeli konwersji DB2 służącej do przekształcania znaków z formatu CCSID 943 na format Unicode przy użyciu odpowiedniej tabeli konwersji firmy Microsoft. W przeciwnym razie różne aplikacje klienckie mogą zapisywać ten sam znak przy użyciu innych punktów kodowych.
Aby zastąpić domyślną tabelę konwersji programu DB2 UDB służącą do przekształcania strony kodowej CCSID 954 na format Unicode, wykonaj następujące czynności:
Aby zastąpić domyślne tabele konwersji programu DB2 UDB służące do przekształcania strony kodowej CCSID 943 na format Unicode, wykonaj następujące czynności:
Strona kodowa Shift-JIS w japońskiej wersji systemu Microsoft Windows jest rejestrowana przy użyciu identyfikatora kodowanego zestawu znaków (CCSID) 943 firmy IBM; podczas konwersji znaków między identyfikatorem CCSID 943 i Unicode mogą wystąpić następujące dwa problemy. Potencjalne problemy wynikają z różnic między tabelami konwersji stron kodowych firm IBM i Microsoft. Aby ich uniknąć, w programie DB2 Universal Database (UDB) dostępne są, oprócz domyślnych tabel konwersji między identyfikatorem CCSID 943 i Unicode firmy IBM, także alternatywne tabele konwersji firmy Microsoft.
Z powodów historycznych ponad 300 znaków ze strony kodowej CCSID 943 jest reprezentowanych przez dwa lub trzy punkty kodowe. Zastosowanie edytorów metody wejścia (input method editors, IME) oraz tabel konwersji stron kodowych powoduje, że wystarczy wprowadzenie tylko jednego z tych równoważnych punktów kodowych. Na przykład mały znak cyfry rzymskiej jeden 'i' ma dwa równoważne punkty kodowe: X'EEEF' i X'FA40'. Edytory IME w systemach Microsoft Windows zawsze, gdy zostanie wprowadzony znak 'i', generują kod X'FA40'. Ogólnie, firmy IBM i Microsoft używają tych samych podstawowych punktów kodowych do reprezentacji znaków, oprócz następujących 13 znaków:
| Nazwa znaku (punkt kodowy Unicode) | Podstawowy punkt kodowy Shift-JIS używany przez IBM | Podstawowy punkt kodowy Shift-JIS używany przez Microsoft |
|---|---|---|
| Cyfra rzymska jeden (U+2160) | X'FA4A' | X'8754' |
| Cyfra rzymska dwa (U+2161) | X'FA4B' | X'8755' |
| Cyfra rzymska trzy (U+2162) | X'FA4C' | X'8756' |
| Cyfra rzymska cztery (U+2163) | X'FA4D' | X'8757' |
| Cyfra rzymska pięć (U+2164) | X'FA4E' | X'8758' |
| Cyfra rzymska sześć (U+2165) | X'FA4F' | X'8759' |
| Cyfra rzymska siedem (U+2166) | X'FA50' | X'875A' |
| Cyfra rzymska osiem (U+2167) | X'FA51' | X'875B' |
| Cyfra rzymska dziewięć (U+2168) | X'FA52' | X'875C' |
| Cyfra rzymska dziesięć (U+2169) | X'FA53' | X'875D' |
| Ujęty w nawias ideogram spółki akcyjnej (U+3231) | X'FA58' | X'FA58' |
| Znak numeru (U+2116) | X'FA59' | X'8782' |
| Znak telefonu (U+2121) | X'FA5A' | X'8754' |
Produkty IBM, na przykład program DB2 UDB, używają przede wszystkim punktów kodowych stosowanych przez IBM, na przykład X'FA4A' do reprezentacji wielkiej cyfry rzymskiej jeden 'I', natomiast produkty firmy Microsoft używają do reprezentacji tego samego znaku punktu kodowego X'8754'. Aplikacja ODBC firmy Microsoft może wstawić do bazy danych DB2 UDB w stronie kodowej CCSID 943 znak 'I' jako punkt kodowy X'8754', a Centrum sterowania DB2 UDB może wstawić ten sam znak do tej samej bazy danych z identyfikatorem CCSID równym 934 jako X'FA4A'. Jednak aplikacje ODBC mogą znajdować tylko wiersze, w których znak 'I' jest zakodowany jako X'8754', a Centrum sterownia DB2 UDB może znajdować tylko wiersze, w których znak 'I' jest zakodowany jako X'FA4A'. Aby umożliwić wybieranie przez Centrum sterowania DB2 UDB znaków 'I' kodowanych jako X'8754', konieczne jest zastąpienie domyślnych tabel konwersji firmy IBM ze strony kodowej CCSID 943 na Unicode alternatywnymi tabelami konwersji firmy Microsoft.
Konwersja znaków z poniższej listy ze strony CCSID 943 na Unicode daje różne punkty kodowe, zależnie od tego, czy używana jest tabela konwersji firmy IBM czy Microsoft. Dla tych znaków tabela konwersji IBM jest zgodna z japońskimi standardami przemysłowymi JISX0208, JISX0212 i JISX0221.
| Punkt kodowy w standardzie Shift-JIS (nazwa znaku) | Pierwotny punkt kodowy używany przez firmę IBM (nazwa znaku w formacie Unicode) | Pierwotny punkt kodowy używany przez firmę Microsoft (nazwa znaku w formacie Unicode) |
|---|---|---|
| X'815C' (znak pauzy) | U+2014 (znak pauzy) | U+2015 (kreska pozioma) |
| X'8160' (znak wartości przybliżonej) | U+301C (znak wartości przybliżonej) | U+FF5E (tylda pełnej długości) |
| X'8161' (podwójna pionowa kreska) | U+2016 (podwójna pionowa kreska) | U+2225 (znak równoległości) |
| X'817C' (minus) | U+2212 (minus) | U+FF0D (łącznik pełnej długości) |
| X'FA55' (kreska przerywana) | U+00A6 (kreska przerywana) | U+FFE4 (kreska przerywana pełnej długości) |
Na przykład gdy używana jest tabela konwersji IBM, znak pauzy (em-dash) o punkcie kodowym X'815C' strony kodowej CCSID 943 jest przekształcany na punkt kodowy U+2014 strony kodowej Unicode. Jednak gdy używana jest tabela konwersji Microsoft, znak ten jest przekształcany na punkt kodowy U+2015. Z powodu tej różnicy odwzorowań konwersji w pojedynczej bazie danych DB2 UDB w formacie Unicode dla pojedynczego znaku mogą występować dwa różne punkty kodowe. Może to być przyczyną problemów w aplikacjach wykorzystujących technologię Microsoft ODBC, ponieważ aplikacje te mogą traktować znak U+2014 jako niepoprawny punkt kodowy. Aby tego uniknąć, należy zastąpić domyślne tabele konwersji firmy IBM między stronami CCSID 943 i Unicode alternatywnymi tabelami konwersji firmy Microsoft.
Zastosowanie alternatywnych tabel konwersji firmy Microsoft między stronami CCSID 943 i Unicode powinno być ograniczone do zamkniętych środowisk, w których wszyscy klienci programu DB2 UDB i wszystkie bazy danych DB2 UDB mają strony kodowe CCSID 943 oraz wszystkie używają tych samych alternatywnych tabel konwersji firmy Microsoft. Jeśli w danym środowisku jeden klient DB2 UDB używa domyślnych tabel konwersji IBM, a inny klient DB2 UDB używa alternatywnych tabel konwersji Microsoft, i obaj wstawiają dane do tej samej bazy danych DB2 UDB ze stroną kodową CCSID 943, ten sam znak może być przechowywany w tej bazie danych jako różne punkty kodowe.
Podczas konwersji między stroną kodową CCSID 943 i stroną kodową Unicode używane są domyślne tabele konwersji programu DB2 Universal Database (UDB). Aby użyć innej wersji tabel konwersji, na przykład opracowanych przez firmę Microsoft, konieczne jest ręczne zastąpienie plików domyślnych tabel konwersji (.cnv).
Przed zastąpieniem istniejących plików tabel konwersji strony kodowej w katalogu sqllib/conv należy utworzyć kopię zapasową, aby można było wrócić do używanych obecnie plików. W systemach UNIX i Linux katalog sqllib/conv jest dowiązany do ścieżki instalacyjnej programu DB2 UDB.
Aby operacja przyniosła pożądany skutek, należy zmienić tabele konwersji używane przez każdego klienta DB2 UDB, który nawiązuje połączenie z określoną bazą danych. W przeciwnym razie różne aplikacje klienckie mogą zapisywać ten sam znak przy użyciu innych punktów kodowych.
Aby zastąpić domyślne tabele konwersji programu DB2 UDB służące do konwersji znaków strony kodowej CCSID 943 na stronę kodową Unicode, wykonaj następujące czynności:
Mimo wzmianki w dokumentacji program DB2 Universal Database nie obsługuje już systemu operacyjnego MVS. System MVS został zastąpiony przez system z/OS.
Operacje tworzenia i odtwarzania kopii zapasowej z użyciem wielu urządzeń taśmowych mogą nie działać w systemie operacyjnym Linux 390.
Gdy dostęp do Centrum projektowania w systemie UNIX realizowany jest za pośrednictwem programu Hummingbird Exceed, przenoszenie i dokowanie widoków przez przeciąganie ich pasków tytułu w oknie Centrum projektowania wymaga wcześniejszego włączenia rozszerzenia XTEST w wersji 2.2.
Aby włączyć rozszerzenie XTEST: