Пометки отмечают текст, который был добавлен или изменен. Вертикальная черта ( | ) отмечает информацию, которая была добавлена или изменена для Версии 8.2 FixPak 4 (эквивалентна Версии 8.1 FixPak 11).
Возможно, вам потребуется установить продукт DB2(R), уровень которого отличается от версии другого продукта DB2(R), установленного в настоящее время на данном компьютере. Продукты DB2 должны быть одного уровня.
Если устанавливаемый продукт более позднего уровня, чем версия других продуктов DB2, установленных на том же компьютере, нужно будет обновить существующие продукты DB2 до этого более позднего уровня. Например, если вы устанавливаете DB2 Connect(TM) for iSeries(TM) с уровнем Fixpak 10, а установленные другие продукты DB2 с уровнем Fixpak 9, нужно перед установкой DB2 Connect(TM) for iSeries(TM) с уровнем Fixpak 10 применить Fixpak 10 для установленных в настоящее время продуктов DB2.
Если же вы устанавливаете некоторый продукт на компьютер, на котором установлена более поздняя версия какого-то продукта DB2, следуйте таким правилам:
db2licm -a имя_файлагде имя_файла - имя файла лицензии, который находится на исходном носителе в каталоге db2\license. Можно также добавить эту лицензию в каталог db2\license пакета Fixpak, тогда эта лицензия будет установлена при установке пакета.
Перед установкой дополнительных продуктов или компонентов необходимо остановить:
Нужно остановить те экземпляры и DAS, которые входят в установку DB2, куда будет установлен дополнительный продукт или компонент DB2.
Более подробные инструкции смотрите в файле Readme для пакета FixPak.
Если в текущей системе нет DB2 DAS, а дополнительный продукт или компонент требует или поддерживает DB2 DAS, db2setup установит DB2 DAS в процессе установки. На некоторых платформах при создании DB2 DAS с помощью db2setup могут возникать ошибки. Это ожидаемые ошибки, их можно проигнорировать.
Программа db2setup находится на компакт-диске продукта DB2 или в установочном образе для устанавливаемого дополнительного продукта или компонента.
Подробная информация об использовании команды db2setup приведена в руководстве Command Reference (Справочник по командам) и документе Дополнение по установке и настройке.
Сценарий db2_install находится на компакт-диске продукта DB2 или в установочном образе для устанавливаемого дополнительного продукта или компонента.
Подробная информация об использовании сценария db2_install приведена в документе Дополнение по установке и настройке.
Подробная информация об использовании системной программы установки приведена в документе Дополнение по установке и настройке.
Чтобы проиллюстрировать этот сценарий, предположим, что:
После установки нужно повторно применить обычный пакет FixPak 10.
В этой системе уже установлен пакет db2cliv81. Установка исправления nnnnnnn-nnn завершена аварийно. Перед повторной установкой этого исправления нужно сначала деинсталлировать его.Эта ошибка возникает из-за того, что в системе уже установлен db2cliv81 с тем же уровнем, что и устанавливаемый пакет Fixpak. Эту ошибку можно проигнорировать. Используйте системную программу установки, чтобы подтвердить, что действительно нужно установить компонент или пакет DB2 с тем же уровнем Fixpak.
Базу данных, созданную в DB2 Universal Database Версии 8.2, нельзя использовать на уровне Версии 8.1. С этой базой данных можно работать только на уровне Версии 8.2 или новее.
У баз данных, созданные на уровне DB2 UDB Версии 8.2, могут быть дополнительные функциональные возможности, отсутствующие в более ранних версиях. Эти различия могут привести к непредсказуемому и нежелательному поведению системы при попытке переноса новой базы данных в более старый выпуск DB2 UDB.
В разделе "DB2 client overview" (Обзор клиентов DB2) книги |DB2 Quick Beginnings for Clients |утверждается:
Клиенты DB2 могут подключаться к серверам DB2 одного с ними уровня выпуска, |а также к серверам на два выпуска новее или на один выпуск старше.|
Это утверждение надо скорректировать так:
|Хотя соединения клиента версии N с серверами версии N + 2 и возможны в |некоторых средах, группа поддержки DB2 будет обеспечивать поддержку такой конфигурации только до тех пор, пока версия N обслуживается. Когда обслуживание версии N прекращается, прекращается и поддержка этой конфигурации группой поддержки DB2. Подключение клиентов DB2 Версии 7 к серверам DB2 Версии 8 группой поддержки DB2 больше не обеспечивается, поскольку Версия 7 уже не обслуживается.
Любые изменения в реестре, сделанные на уровне DB2 UDB Версии 8.2, будут потеряны при перенастройке обратно в DB2 UDB Версии 8.1. От файла HealthRules2.reg DB2 UDB Версии 8.2 с новыми параметрами реестр вернется к файлу HealthRules.reg Версии 8.1, с параметрами, которые вы использовали до обновления.
До DB2 Universal Database (UDB) Версии 8 пакеты FixPak работали только как пакеты обновления для установленных пакетов DB2 UDB или наборов файлов в одном постоянном положении. Это означало, что при установке пакетов FixPak существующие файлы заменялись обновленными, поставляемыми пакетах FixPak. Несколько уровней пакетов FixPak DB2 не могли существовать в одной системе. Теперь DB2 UDB Enterprise Server Edition (ESE) может существовать в одной системе с несколькими уровнями пакетов исправлений (для операционных систем на основе Linux(TM) и UNIX(R)). Эта возможность поддерживается в производственных средах, начиная с Версии 8.1.2; для ее реализации применяются два типа пакетов FixPak:
Чтобы обновить экземпляр пакета FixPak в такой установке до другого уровня FixPak, используйте одно из следующих действий:
Дополнительную информацию об альтернативных пакетах FixPak смотрите:
Начиная с Версии 8.2.2 (эквивалентна Версии 8.1 Fixpack 9), содержимое таблицы управления Query Patroller TRACK_QUERY_INFO, захваченное в 32-битной среде, можно использовать в 64-битной среде. Эта возможность упрощает работу по перенастройке в 64-битную среду. Информацию, захваченную в таблице управления TRACK_QUERY_INFO Query Patroller Версии 8.2.2, нельзя использовать для генерации данных хронологии запросов или для выполнения задержанных запросов ни в каких ранних уровнях FixPak.
Следующие ограничения применяются при поддержке прежних версий сервера для Центра хранилищ данных DB2 Universal Database (UDB) Enterprise Server Edition Версии 8:
При использовании Центра разработки в клиенте разработки программ для DB2 Universal Database (UDB) Версии 8 в операционных системах Windows или UNIX для включения поддержки SQLJ и SQL Assist необходимо установить на сервере следующие исправления APAR:
Из DB2 Universal Database Версии 8 можно вызвать как Версию 7, так и Версию 8 SQL Assist. Версию 7 можно запустить из Центра хранилищ данных DB2. Все прочие центры запускают последнюю версию - Версию 8. В электронной справке по продукту есть дополнительная информация о SQL Assist Версии 7.
В Версии 7 серверы Unicode игнорировали любые графические кодовые страницы, сообщаемые программами во время соединения, и предполагали, что используется UCS2 Unicode (кодовая страница 1200). Серверы Unicode Версии 8 теперь принимают во внимание кодовую страницу, указываемую клиентом.
В DB2 UDB Версии 8.2 используется новый файл параметров конфигурации базы данных SQLDBCONF размером 16 Кбайт. Это отдельный файл по отношению к файлу параметров конфигурации базы данных DB2 UDB Версии 8.1 с именем SQLDBCON и размером 4 Кбайта.
После перенастройки в DB2 UDB Версии 8.2 продукт просто переносит в нее содержимое 4-Кбайтного файла Версии 8.1, а изменения параметров конфигурации базы данных регистрирует с помощью 16-Кбайтного файла. Файл Версии 8.1 размером 4 Кбайта сохраняется, но не используется.
При перенастройке обратно в DB2 UDB Версии 8.1 продукт DB2 UDB Версии 8.1 вновь начинает регистрировать изменения параметров конфигурации базы данных с помощью 4-Кбайтного файла Версии 8.1. Файл Версии 8.2 размером 16 Кбайт сохраняется, но не распознается продуктом DB2 UDB Версии 8.1. Изменения в 16-Кбайтном файле параметров конфигурации базы данных, сделанные в промежутке между перенастройкой в Версию 8.2 и обратной перенастройкой в Версию 8.1, таким образом, оказываются скрытыми для DB2 UDB более старого выпуска, поскольку эти изменения не записывались в исходный 4-Кбайтный файл.
Кроме того, если вы снова выполните перенастройку до DB2 UDB Версии 8.2, продукт DB2 UDB Версии 8.2 обнаружит, что 16-Кбайтный файл конфигурации базы данных уже существует, и вернется к регистрации изменений параметров конфигурации базы данных с помощью 16-Кбайтного файла Версии 8.2. Файл Версии 8.1 размером 4 Кбайта сохраняется, но не распознается продуктом DB2 UDB Версии 8.2. Изменения в 4-Кбайтном файле параметров конфигурации базы данных, сделанные в промежутке между перенастройкой в Версию 8.1 и обратной перенастройкой в Версию 8.2, таким образом, оказываются скрытыми для DB2 UDB более нового выпуска, поскольку эти изменения не записываются в существующий 16-Кбайтный файл.
В Версии 8.2 формат файла db2diag.log улучшен во многих отношениях. Этот файл журнала теперь проще читать вручную и анализировать программно. Некоторые усовершенствования:
Внесены и другие изменения, в частности, имя поля database изменено на DB.
В файл db2diag.log добавлены записи событий, играющие роль диагностических сообщений. Примеры таких событий:
У записей событий в поле LEVEL указано "Event". Хотя события - не ошибки, они могут записываться при уровнях диагностики, отличающихся от уровня 4 (информационный уровень) и 3 (уровень предупреждений), в зависимости от важности события.
Начиная с Версии 8.2, в файле db2diag.log записываются следующие изменения:
В связи с важностью этих изменений сообщения для них записываются в журнал на высоких диагностических уровнях.
Записываемые типы изменений в реестре профиля 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
Примеры изменения параметров конфигурации DB и DBM -
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
Для поиска этих сообщений об изменениях конфигурации используйте инструмент db2diag. Например:
DB2 Universal Database(TM) (UDB) для Linux, UNIX и Windows(R) Версии 8.2.2 (эквивалент Версии 8.1 с пакетом FixPak 9) поддерживает JDK 1.4.2 во всех поддерживаемых DB2 UDB 32-битных и 64-битных средах операционных систем рабочих станций. Эта поддержка включает в себя, в частности, построение и запуск клиентских программ Java(TM), построение и запуск подпрограмм Java(TM) из командной строки, построение и запуск подпрограмм Java(TM) из Центра разработки DB2 (где он поддерживается), а также запуск других инструментов DB2.
При установке DB2 UDB Версии 8.2 будет также установлена и последняя поддерживаемая версия Java Development Kit (если она уже не установлена), но только в том случае, если данная установка DB2 UDB не является обновлением установленной ранее DB2 UDB Версии 8. Если обновляется прежняя установка DB2 UDB Версии 8, Java Developer Kit необходимо установить с компакт-диска.
В следующей таблице перечислены поддерживаемые 32-битные и 64-битные среды операционных систем рабочих станций DB2 и последний поддерживаемый уровень JDK для каждой из них. Информацию о ранней поддержке JDK смотрите на Web-странице Java Application Development по адресу http://www.ibm.com/software/data/db2/udb/ad/v8/java/.
| Среда, поддерживаемая DB2 | Последний поддерживаемый уровень JDK |
|---|---|
| 32-битная Windows IA/AMD | JDK 1.4.2 |
| 64-битная Windows IA | JDK 1.4.2 |
| 64-битная Windows AMD/EM64T | JDK 1.4.2 |
| 32-битная AIX(R) 4.3.3 | JDK 1.3.1 SR6 [2] |
| AIX(R) 5 (гибридная [1]) | JDK 1.4.2 |
| Solaris (гибридная, [1]) | JDK 1.4.2 |
| HPUX RISC & Itanium (гибридная [1]) | JDK 1.4.2.01 |
| Linux AMD/EM64T 32-, 64-битная (гибридная [1]) | JDK 1.4.2 [3] |
| 32-битная Linux IA | JDK 1.4.2 |
| 64-битная Linux IA | JDK 1.4.2 |
| 31-битная Linux 390 | JDK 1.4.2 |
| 64-битная Linux 390 | JDK 1.4.2 |
| Linux PPC (гибридная, [1]) | JDK 1.4.2 |
Обновленная процедура для задания параметров Linux Java Environment приведена ниже.
Для построения программ Java в Linux с поддержкой JDBC DB2:
Для запуска хранимых процедур или пользовательских функций Java компоновщику времени выполнения Linux нужна возможность доступа к определенным совместно используемым библиотекам Java, а DB2 UDB должна быть в состоянии загрузить и эти библиотеки, и виртуальную Java-машину. Процесс, запускающий хранимые процедуры и пользовательские функции, загружает библиотеки только в защищенное положение, определенное в файле /etc/ld.so.conf. Одно из таких защищенных положений - каталог /usr/lib. В остальных инструкциях указаны библиотеки, для которых требуются символические ссылки в каталоге /usr/lib.
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 .где JAVAHOME - базовый каталог для IBM(R) Developer Kit. Если DB2 UDB не сможет найти эти библиотеки, при попытке запустить подпрограмму Java вы получите код ошибки -4301, а в журнал уведомлений администратора будут записаны сообщения, что библиотеки не найдены.
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где JAVAHOME - базовый каталог для IBM Developer Kit. Если DB2 UDB не сможет найти эти библиотеки, при попытке запустить подпрограмму Java вы получите код ошибки -4301, а в журнал уведомлений администратора будут записаны сообщения, что библиотеки не найдены.
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.soгде JAVAHOME - базовый каталог для IBM Developer Kit. Если DB2 UDB не сможет найти эти библиотеки, при попытке запустить подпрограмму Java вы получите код ошибки -4301, а в журнал уведомлений администратора будут записаны сообщения, что библиотеки не найдены.
JAVAHOME/jre/binгде JAVAHOME - базовый каталог для IBM Developer Kit. Если DB2 UDB не сможет найти эти библиотеки, при попытке запустить подпрограмму Java вы получите код ошибки -4301 или -1042.
Вместо явного создания ссылок на совместно используемые библиотеки в каталоге /usr/lib можно добавить имя каталога, в котором хранятся совместно используемые библиотеки Java, в файл /etc/ld.so.conf. Для работы с этим файлом требуются полномочия root. После изменения файла /etc/ld.so.conf нужно (от имени пользователя root) ввести команду ldconfig для активации внесенных изменений. Если при выполнении альтернативной процедуры будут обнаружены какие-либо ошибки, создайте ссылки в каталоге /usr/lib по приведенным выше инструкциям.
При использовании 64-битной операционной системы Microsoft XP (2600), сконфигурированной для использования протокола NETBIOS с продуктами семейства DB2, нужно получить от Microsoft свежие исправления. Свяжитесь с Microsoft, указав номер в базе Knowledge Base Q317437.
Операционная система Windows XP Home Edition поддерживается только продуктами DB2 Universal Database (UDB) Personal Edition.
Операционная система Windows XP Professional поддерживается следующими продуктами DB2:
Следующие продукты DB2 поддерживаются в Windows XP только для возможностей разработки и тестирования (для производственных сред требуется Windows 2000 или Windows Server 2003):
В DB2 Universal Database(TM) (UDB) Версии 8.2 заказчики DB2 UDB Workgroup Server Edition и DB2 UDB Express Edition (при лицензировании на основе числа пользователей) не могли устанавливать отдельно поставляемую опцию DB2 UDB HADR (High Availability Disaster Recovery - высокая доступность и восстановление после аварий). Эта проблема решена в пакете исправлений FixPak 1 для Версии 8.2 (эквивалентен FixPak 8 для Версии 8.1).
Утилиты OLAP в стандартном выпуске Менеджера хранилищ DB2 Версии 8.2 несовместимы с сервером IBM DB2 OLAP Server FP3 (уровень Essbase API 6.5.4) и новее. До разрешения этой проблемы рекомендуется использовать DB2 OLAP Server FP2 (Essbase 6.5.3) или более ранний.
Для возможности использования журналов на устройствах прямого ввода-вывода до DB2 Universal Database (UDB) Версии 8.2.2 (эквивалентна Версии 8.1 Fixpack 9) физическое устройство необходимо было связать с драйвером непосредственного символьного устройства Linux при помощи утилиты raw. Начиная с DB2 UDB Версии 8.2.2 (эквивалент Версии 8.1 с FixPak 9), работающей на ядре Linux 2.6, непосредственный ввод-вывод для журналов можно задать непосредственно. Например, чтобы использовать раздел устройства /dev/sdb1 для журналов непосредственных устройств базы данных SAMPLE, введите следующую команду:
db2 update db cfg for sample using newlogpath /dev/sdb1
Хотя DB2 UDB все еще поддерживает метод использования утилиты raw для прямого ввода-вывода, в последних дистрибутивах эта возможность считается устаревшей и в будущем она может быть удалена. Предпочтительно использовать новый метод - непосредственное задание устройств.
DB2 Universal Database Версии 8.2 поддерживает Red Hat Enterprise Linux AS Версий 3 и 2.1. Однако Центр хранилищ данных поддерживает только Red Hat Enterprise Linux AS Версии 2.1. В Центре хранилищ данных используются драйверы DataDirect ODBC, которые не поддерживают Red Hat Enterprise Linux AS Версии 3.1. Поэтому Центр хранилищ данных не поддерживает источники хранилища и потребители хранилища ODBC на узле агента Red Hat Enterprise Linux AS Версии 3.1.
При работе прикладных программ в среде IBM(R) WebSphere(R) MQ (старое название - IBM MQSeries(R)) система WebSphere(R) MQ может выполнять функции совместимого с XA менеджера транзакций, координирующего все распределенные транзакции с двухфазным принятием. Когда WebSphere(R) MQ действует как такой менеджер транзакций и в качестве источников данных используются продукты семейства DB2, есть некоторые требования к конфигурации. Большинство из этих требований уже указаны в документации. Например, для клиента времени выполнения DB2 нужно задать для параметра DB2 TP_MON_NAME значение "MQ".
Однако существует требование к конфигурации, не описанное в документации. Это требование относится только к DB2 Connect, соединяющемуся с источниками данных на серверах DB2 for OS/390(R): При использовании WebSphere MQ для координации распределенных транзакций, включающих серверы DB2 for z/OS(R) и DB2 for iSeries, на шлюзе должен быть включен концентратор соединений DB2 Connect. Концентратор соединений будет включен, если значение параметра конфигурации MAX_CONNECTIONS больше значения MAX_COORDAGENTS. Если концентратор соединений не включен, поведение транзакций будет непредвиденным.
Кодовая страница Microsoft Japanese Windows Shift-JIS зарегистрирована с идентификатором кодового набора символов IBM (CCSID) 943. Однако на платформе HP-UX кодовая страница Shift-JIS зарегистрирована как CCSID 5039. CCSID 5039 содержит только символы Japanese Industry Standard (JIS) и не допускает дополнительных символов, определенных другими разработчиками. База данных DB2 Universal Database (UDB) с CCSID 5039 в HP-UX позволяет хранить символы Shift-JIS, но при этом применяется преобразование кодовых страниц между CCSID 5039 и CCSID 943. При использовании программ ODBC версии Microsoft возможны ошибки преобразования данных CCSID 5039 в Unicode из-за различий между таблицами преобразования кодовых страниц IBM и Microsoft.
Ниже приведен список символов CCSID 5039, которые по-разному преобразуются в символы Unicode при использовании таблиц преобразования (IBM и Microsoft). Таблица преобразования IBM преобразует эти символы согласно стандартам Japanese Industry Standard JISX0208 и JISX0221.
| Символ Shift-JIS (имя символа) | Первичный символ IBM (имя Unicode) | Первичный символ Microsoft (имя Unicode) |
|---|---|---|
| X'815C' (длинное тире) | U+2014 (длинное тире) | U+2015 (горизонтальная черта) |
| X'8160' (волнистая черта) | U+301C (волнистая черта) | U+FF5E (длинная тильда) |
| X'8161' (двойная вертикальная черта) | U+2016 (двойная вертикальная черта) | U+2225 (знак параллельности) |
| X'817C' (знак минус) | U+2212 (знак минус) | U+FF0D (длинный дефис-минус) |
Например, символ длинного тире с кодом X'815C' в CCSID 5039 преобразуется в символ Unicode U+2014 при использовании таблицы преобразования IBM или в U+2015 при использовании таблицы преобразования Microsoft. Это может приводить к ошибкам программ ODBC версии Microsoft, которые обработают U+2014 как недопустимый символ. Чтобы предотвратить такие ошибки, в DB2 UDB, наряду с используемой по умолчанию таблицей преобразования из CCSID 5039 в Unicode версии IBM, входит и альтернативная таблица преобразования версии Microsoft. При необходимости можно заменить используемую по умолчанию таблицу преобразования IBM на альтернативную таблицу преобразования Microsoft. Обратите внимание на то, что используемая по умолчанию таблица преобразования из Unicode в CCSID 5039 версии IBM совпадает с версией Microsoft.
При преобразовании из CCSID 5039 в Unicode используется таблица преобразования кодовых страниц DB2 Universal Database по умолчанию. Если вы хотите использовать другую версию таблицы преобразования, например, версию Microsoft, необходимо вручную заменить файл таблицы преобразования по умолчанию (.cnv).
Перед заменой существующего файла таблицы преобразования кодовых страниц в каталоге sqllib/conv создайте его резервную копию на случай, если потребуется обратное изменение. В UNIX и Linux каталог sqllib/conv связан с путем установки DB2 UDB.
Чтобы данное изменение вступило в силу, требуется замена таблицы преобразования на каждом клиенте DB2 UDB, который соединяется с этой же базой данных. Иначе различные клиенты могут сохранять одни и те же символы с разными кодами символов.
Чтобы заменить таблицу преобразования из CCSID 5039 в Unicode, используемую DB2 UDB по умолчанию:
Идентификатор кодового набора символов (CCSID) IBM для кодовой страницы Japanese EUC зарегистрирован под CCSID 954. CCSID 954 - обычная кодировка для японских платформ UNIX и Linux. Если программы ODBC версии Microsoft должны соединяться с базой данных DB2 Universal Database (UDB), использующей CCSID 954, возможны ошибки преобразования данных из CCSID 954 в Unicode. Возможные ошибки связаны с различиями между таблицами преобразования кодовых страниц IBM и Microsoft. Таблица преобразований IBM соответствует именам символов, заданным в стандартах Japanese Industry Standard (JIS) JISX0208, JISX0212 и JISX0221.
Приведенные ниже символы CCSID 954 по-разному преобразуются в символы Unicode при использовании таблиц преобразования IBM и Microsoft.
| Символ EUC-JP (имя символа) | Первичный символ IBM (имя Unicode) | Первичный символ Microsoft (имя Unicode) |
|---|---|---|
| X'A1BD' (длинное тире) | U+2014 (длинное тире) | U+2015 (горизонтальная черта) |
| X'A1C1' (волнистая черта) | U+301C (волнистая черта) | U+FF5E (длинная тильда) |
| X'A1C2' (двойная вертикальная черта) | U+2016 (двойная вертикальная черта) | U+2225 (знак параллельности) |
| X'A1DD' (знак минус) | U+2212 (знак минус) | U+FF0D (длинный дефис-минус) |
| X'8FA2C3' (прерывистая черта) | U+00A6 (прерывистая черта) | U+FFE4 (длинная прерывистая черта) |
Например, символ длинного тире с кодом X'A1BD' в CCSID 954 преобразуется в символ Unicode U+2014 при использовании таблицы преобразования IBM или в U+2015 при использовании таблицы преобразования Microsoft. Из-за этого различия в отображении символов один и тот же символ может преобразовываться в разные символы в базе данных DB2 UDB, работающей с Unicode, и в графическом столбце базы данных DB2 UDB, работающей с CCSID 954. Это может приводить к ошибкам программ ODBC версии Microsoft, которые обработают U+2014 как недопустимый символ. Чтобы предотвратить такие ошибки, в DB2 UDB, наряду с используемой по умолчанию таблицей преобразования из CCSID 954 в Unicode версии IBM, входит и альтернативная таблица преобразования версии Microsoft. При необходимости можно заменить используемую по умолчанию таблицу преобразования IBM на альтернативную таблицу преобразования Microsoft. Обратите внимание на то, что используемая по умолчанию таблица преобразования из Unicode в CCSID 954 версии IBM совпадает с версией Microsoft.
При преобразовании CCSID 954 в Unicode используется таблица преобразования кодовых страниц DB2 Universal Database по умолчанию. Если вы хотите использовать другую версию таблицы преобразования, например, версию Microsoft, необходимо вручную заменить файл таблицы преобразования по умолчанию (.cnv).
Перед заменой существующего файла таблицы преобразования кодовых страниц в каталоге sqllib/conv создайте его резервную копию на случай, если потребуется обратное изменение. В UNIX и Linux каталог sqllib/conv связан с установочным каталогом DB2 UDB.
Чтобы данное изменение вступило в силу, требуется замена таблицы преобразования на каждом клиенте DB2 UDB, который соединяется с этой же базой данных CCSID 954. Для клиента японской версии Windows, использующего кодовую страницу ANSI Shift-JIS (CCSID 943), необходимо также изменить таблицы преобразования DB2 между CCSID 943 и Unicode с версии по умолчанию на версию Microsoft, Иначе различные клиенты могут сохранять одни и те же символы с разными кодами символов.
Чтобы заменить таблицу преобразования из CCSID 954 в Unicode, используемую DB2 UDB по умолчанию:
Чтобы заменить таблицы преобразования между CCSID 943 и Unicode, используемые DB2 UDB по умолчанию:
При работе с кодовой страницей Microsoft Japanese Windows Shift-JIS, зарегистрированной с идентификатором кодового набора символов IBM (CCSID) 943, возможны две ошибки преобразования символов между CCSID 943 и Unicode. Эти ошибки связаны с различиями между таблицами преобразования кодовых страниц IBM и Microsoft. Для предотвращения таких ошибок в DB2 Universal Database (UDB), наряду с используемыми по умолчанию таблицами преобразования из CCSID 943 в Unicode IBM, входят и альтернативные таблицы преобразования версии Microsoft.
Исторически сложилось, что в кодовой странице CCSID 943 более 300 символов представлены двумя-тремя различными кодами каждый. Использование редакторов IME (Input Method Editor - редактор метода ввода) и таблиц преобразования кодовых страниц приводит к тому, что употребляется лишь один из эквивалентных кодов. Например, для строчного латинского 'i', используемого как 1 в римских цифрах, есть два эквивалентных кода: X'EEEF' и X'FA40'. При вводе 'i' IME Microsoft Windows всегда генерируют X'FA40'. В целом IBM и Microsoft используют один и тот же первичный код для представления всех символов, кроме следующих 13:
| Название символа (код символа в Unicode) | Первичный символ Shift-JIS IBM | Первичный символ Shift-JIS Microsoft |
|---|---|---|
| Римская цифра один (U+2160) | X'FA4A' | X'8754' |
| Римская цифра два (U+2161) | X'FA4B' | X'8755' |
| Римская цифра три (U+2162) | X'FA4C' | X'8756' |
| Римская цифра четыре (U+2163) | X'FA4D' | X'8757' |
| Римская цифра пять (U+2164) | X'FA4E' | X'8758' |
| Римская цифра шесть (U+2165) | X'FA4F' | X'8759' |
| Римская цифра семь (U+2166) | X'FA50' | X'875A' |
| Римская цифра восемь (U+2167) | X'FA51' | X'875B' |
| Римская цифра (U+2168) | X'FA52' | X'875C' |
| Римская цифра десять (U+2169) | X'FA53' | X'875D' |
| Иероглиф "ствол" в скобках, означающий "Inc." (U+3231) | X'FA58' | X'FA58' |
| Знак номера (U+2116) | X'FA59' | X'8782' |
| Знак телефона (U+2121) | X'FA5A' | X'8754' |
Продукты IBM, такие как DB2 UDB используют в первую очередь коды IBM, например, X'FA4A' для представления римской цифры один ('I') в верхнем регистре, а продукты Microsoft представляют тот же символ с помощью X'8754'. Прикладная программа ODBC Microsoft вставляет символ 'I' в базу данных DB2 UDB, использующую CCSID 943, как X'8754', а Центр управления DB2 UDB вставляет тот же символ в ту же базу данных с CCSID 943 как X'FA4A'. Однако программы ODBC способны находить только те строки, где 'I' кодируется как X'8754', а Центр управления DB2 UDB находит только строки, где 'I' кодируется как X'FA4A'. Чтобы Центр управления DB2 UDB мог выбрать 'I' в кодировке X'8754', надо заменить таблицы преобразования IBM по умолчанию между CCSID 943 и Unicode на альтернативные таблицы преобразования Microsoft.
Перечисленные ниже символы CCSID 943 по-разному преобразуются в символы Unicode при использовании таблиц преобразования IBM или Microsoft. Таблица преобразования IBM преобразует эти символы согласно стандартам Japanese Industry Standard JISX0208, JISX0212 и JISX0221.
| Символ Shift-JIS (имя символа) | Первичный символ IBM (имя Unicode) | Первичный символ Microsoft (имя Unicode) |
|---|---|---|
| X'815C' (длинное тире) | U+2014 (длинное тире) | U+2015 (горизонтальная черта) |
| X'8160' (волнистая черта) | U+301C (волнистая черта) | U+FF5E (длинная тильда) |
| X'8161' (двойная вертикальная черта) | U+2016 (двойная вертикальная черта) | U+2225 (знак параллельности) |
| X'817C' (знак минус) | U+2212 (знак минус) | U+FF0D (длинный дефис-минус) |
| X'FA55' (прерывистая черта) | U+00A6 (прерывистая черта) | U+FFE4 (длинная прерывистая черта) |
Например, символ длинного тире с кодом X'815C' в CCSID 943 при использовании таблицы преобразования IBM преобразуется в символ Unicode U+2014. Однако при использовании таблицы преобразования Microsoft он преобразуется в символ U+2015. Из-за этого различия в отображении символов один и тот же символ может преобразовываться в разные символы в базе данных DB2 UDB, работающей с Unicode. Это может приводить к ошибкам программ ODBC версии Microsoft, которые обработают U+2014 как недопустимый символ. Чтобы избежать этой ошибки, надо заменить используемые по умолчанию таблицы преобразования между CCSID 943 и Unicode IBM на альтернативные таблицы преобразования Microsoft.
Использование альтернативных таблиц преобразования между CCSID 943 и Unicode Microsoft следует ограничить закрытыми средами, где и клиенты DB2 UDB, и базы данных DB2 UDB работают с кодовой страницей CCSID 943 и используют одни и те же альтернативные таблицы преобразования Microsoft. Если ваш клиент DB2 UDB использует таблицы преобразования IBM, а другой клиент DB2 UDB использует альтернативные таблицы преобразования Microsoft, и оба этих клиента вставляют данные в одну и ту же базу данных DB2 UDB с CCSID 943, возможно сохранение символа в одной базе данных с разными кодами символа.
При преобразовании между CCSID 943 и Unicode используются таблицы преобразования кодовых страниц DB2 Universal Database по умолчанию. Если вы хотите использовать другую версию таблиц преобразования, например, версию Microsoft, необходимо вручную заменить файлы таблицы преобразования по умолчанию (.cnv).
Перед заменой существующих файлов таблиц преобразования кодовых страниц в каталоге sqllib/conv создайте их резервные копии на случай, если потребуется обратное изменение. В UNIX и Linux каталог sqllib/conv связан с путем установки DB2 UDB.
Чтобы данное изменение вступило в силу, требуется замена таблицы преобразования на каждом клиенте DB2 UDB, который соединяется с этой же базой данных. Иначе различные клиенты могут сохранять одни и те же символы с разными кодами символов.
Чтобы заменить таблицы преобразования символов между CCSID 943 и Unicode, используемые DB2 UDB по умолчанию:
Несмотря на упоминания в документации, операционная система MVS больше не поддерживается в DB2 Universal Database. MVS заменена на z/OS.
Если вы используете операционную систему Linux 390, операции резервного копирования и восстановления на несколько ленточных устройств могут не работать.
При обращении к Центру разработки в UNIX с помощью Hummingbird Exceed, надо включить расширение XTEST версии 2.2, иначе вы не сможете перемещать и закреплять окна, перетаскивая полосы их заголовков в Центре разработки.
Чтобы включить расширение XTEST: