Las marcas de revisión indican texto que se ha añadido o cambiado. Una barra vertical ( | ) indica información que se añadió o cambió para la Versión 8.2 FixPak 4 (equivalente a la Versión 8.1 FixPak 11).
Puede que sea necesario que instale un producto DB2(R) que esté a un nivel diferente que la versión de otro producto DB2(R) que está actualmente instalada en el sistema. Es necesario que los productos DB2 estén al mismo nivel.
Si el producto que está instalando está a un nivel más reciente que la versión de otros productos DB2 instalados en el mismo sistema, será necesario que actualice los productos DB2 existentes al nivel más reciente. Por ejemplo, si está instalando DB2 Connect(TM) para iSeries(TM) al nivel del Fixpak 10 y sus otros productos DB2 están al nivel del Fixpak 9, es necesario que aplique el Fixpak 10 a los productos DB2 instalados actualmente antes de instalar DB2 Connect(TM) para iSeries(TM) al nivel del Fixpak 10.
Inversamente, si está instalando un producto en un sistema que tiene instalada una versión más reciente de un producto DB2, debe seguir algunas directrices:
db2licm -a nombre_archivodonde nombre_archivo es el nombre del archivo de licencia, que se puede encontrar en el directorio db2\license del soporte de almacenamiento original. Puede también añadir esta licencia al directorio db2\license del fixpak, y la licencia será instalada por el proceso de instalación.
Antes de instalar un producto o componente adicional, debe detener los elementos siguientes:
Las instancias y el servidor DAS que se deben detener son los pertenecientes a la instalación de DB2 en la que se instalará el producto o componente adicional de DB2.
Consulte el Readme del FixPak para obtener más instrucciones.
Si el servidor DB2 DAS no existe en el sistema actual y el producto o componente adicional necesita o es compatible con el servidor DB2 DAS, db2setup configurará el servidor DB2 DAS durante la instalación. En algunas plataformas, puede recibir errores durante la creación del servidor DB2 DAS mediante db2setup. Estos errores son previsibles y se pueden pasar por alto.
El programa db2setup se puede encontrar en el CD o imagen del producto DB2 correspondiente al producto o componente adicional que está instalando.
Consulte la guía Command Reference y el manual Installation and Configuration Supplement para obtener información detallada sobre la utilización de db2setup.
El script db2_install se puede encontrar en el CD o imagen del producto DB2 correspondiente al producto o componente adicional que está instalando.
Consulte el manual Installation and Configuration Supplement para obtener información detallada sobre la utilización del script db2_install.
Consulte el manual Installation and Configuration Supplement para obtener información detallada sobre la utilización del programa de instalación del sistema.
Como ejemplo de esta situación, suponga que se cumplen las condiciones siguientes:
Como paso posterior a la instalación, debe aplicar de nuevo el FixPak 10 normal.
El paquete db2cliv81 ya está instalado en el sistema. La instalación del parche nnnnnnn-nnn ha finalizado de forma anómala. Para reinstalar este parche, primero debe desinstalarlo antes de intentar instalarlo de nuevo.Este error se produce porque el paquete db2cliv81 existente en el sistema ya se encuentra en el mismo nivel que el nivel del fixpak que se está instalando. Puede pasar por alto esta clase de error. Utilice el programa de instalación del sistema para verificar que el componente o paquete de DB2 se encuentra verdaderamente en el mismo nivel que el fixpak que se está instalando.
Si crea una base de datos con DB2 Universal Database Versión 8.2, no podrá utilizar dicha base de datos en un nivel de la Versión 8.1. Dicha base de datos sólo se puede utilizar en la Versión 8.2 o en un nivel posterior.
Las bases de datos creadas en el nivel de DB2 UDB Versión 8.2 pueden tener funciones adicionales que no estaban disponibles en versiones anteriores. Esta diferencia puede dar como resultado un comportamiento inesperado y no deseable en el caso de que intente mover la base de datos nueva a un release anterior de DB2 UDB.
La sección "Visión general del cliente DB2" del manual Guía rápida de iniciación para clientes DB2 indica lo siguiente:
Los clientes de DB2 pueden conectarse a servidores de DB2 dos |releases posteriores o un release anterior al nivel de release del |cliente, así como a servidores del mismo nivel de release.|
Una enmienda a dicha sentencia es como sigue:
|Mientras que las conexiones |de clientes de Versión N a servidores Versión N + 2 son posibles en algunos entornos, |el equipo de soporte de DB2 sólo proporcionará soporte para esta configuración siguiendo |la versión N todavía en servicio. Una vez se ha retirado del servicio la Versión N, |esta configuración ya no recibe soporte por el equipo de soporte de DB2. Los clientes de |DB2 Versión 7 que se conectan a un servidor de DB2 Versión 8 ya no reciben soporte |por el equipo de soporte de DB2 porque la Versión 7 ha sido retirada del servicio.
Cualquier cambio en el registro realizado a nivel de DB2 UDB Versión 8.2 se pierde cuando se vuelve a migrar a DB2 UDB Versión 8.1. El registro vuelve al archivo HealthRules.reg de la versión 8.1 que contiene los valores existentes antes de que se realizara la actualización a DB2 UDB Versión 8.2 y se empezaran a utilizar los valores del archivo HealthRules2.reg.
Antes de DB2 Universal Database (UDB) Versión 8, los FixPaks sólo funcionaban como actualizaciones de los paquetes instalados de DB2 UDB o conjuntos de archivos en una sola ubicación fija. Esto significaba que la instalación de los FixPaks sustituía los archivos existentes por unos nuevos, que se proporcionaban en los FixPaks. No podían existir varios niveles FixPak de DB2 en un único sistema. Ahora, DB2 UDB Enterprise Server Edition (ESE) puede existir en varios niveles de FixPack en el mismo sistema para los sistemas operativos basados en Linux(TM) y UNIX(R). Esta característica soportada en entornos de operación de producción desde la Versión 8.1.2, se desarrolla utilizando los dos tipos de FixPak siguientes:
Para actualizar una instancia múltiple de FixPaks a un nivel de FixPak diferente, realice una de las operaciones siguientes:
Para obtener más información sobre FixPaks alternativos:
A partir de la Versión 8.2.2 (equivalente a la Versión 8.1 FixPak 9), el contenido de la tabla de control TRACK_QUERY_INFO de Query Patroller que se capturó en un entorno de 32 bits se puede utilizar en un entorno de 64 bits. Esta capacidad facilita el esfuerzo de migración a un entorno de 64 bits. La información capturada en la tabla de control TRACK_QUERY_INFO de Query Patroller en la Versión 8.2.2 no se puede utilizar para generar datos históricos para dicha consulta o para ejecutar consultas retenidas en algún nivel FixPak anterior.
Existen las limitaciones siguientes para el soporte de servidor de nivel anterior del Centro de depósito de datos de DB2 Universal Database (UDB) Enterprise Server Edition Versión 8:
Cuando se utiliza el Centro de desarrollo en un cliente de Application Development para DB2 Universal Database (UDB) Versión 8 en los sistemas operativos Windows o UNIX, es necesario instalar los APAR siguientes en el servidor para habilitar el soporte de SQLJ y SQL Assist:
Puede invocar la versión 7 y la versión 8 de SQL Assist desde DB2 Universal Database, Versión 8. Puede iniciar la versión 7 desde el Centro de depósito de datos de DB2. El resto de centros inicia la última Versión 8. La ayuda en línea del producto contiene información adicional para SQL Assist, Versión 7.
En la Versión 7, los servidores Unicode ignoraban cualquier página de códigos gráfica enviada por las aplicaciones durante la conexión y suponían que se utilizaba UCS2 Unicode (página de códigos 1200). Ahora, los servidores Unicode de la versión 8 respetan la página de códigos enviada por el cliente.
DB2 UDB Versión 8.2 utiliza un archivo de parámetros de configuración de la base de datos de 16K nuevo denominado SQLDBCONF. Este es un archivo independiente del archivo de parámetros de configuración de la base de datos de DB2 UDB Versión 8.1 de 4K denominado SQLDBCON.
Después de migrar a DB2 UDB Versión 8.2, el producto migra el contenido del archivo de 4K de la Versión 8.1 y utiliza el archivo de 16K para anotar cronológicamente los cambios del parámetro de configuración de la base de datos. Se retiene el archivo de 4K de la Versión 8.1, pero no se utiliza.
Si vuelve a migrar a DB2 UDB Versión 8.1, el producto DB2 UDB Versión 8.1 revierte a la utilización del archivo de 4K de la Versión 8.1 original para anotar cronológicamente los cambios del parámetro de configuración de la base de datos. Se retiene el archivo de 16K de la Versión 8.2, pero el producto DB2 UDB Versión 8.1 no lo reconoce. Los cambios efectuados en el archivo del parámetro de configuración de la base de datos de 16K entre la operación de migración a la Versión 8.2 y la operación de volver a efectuar la migración a la Versión 8.1 se ocultan, de hecho, respecto al nivel de DB2 UDB anterior ya que los cambios no se migran al archivo de 4K original.
Además, si vuelve a migrar a DB2 UDB Versión 8.2, el producto DB2 UDB Versión 8.2 reconoce que el archivo de configuración de la base de datos de 16K ya existe y revierte a la utilización del archivo de 16K de la Versión 8.2 para anotar cronológicamente los cambios del parámetro de configuración de la base de datos. Se retiene el archivo de 4K de la Versión 8.1, pero el producto DB2 UDB Versión 8.2 no lo reconoce. Los cambios efectuados en el archivo del parámetro de configuración de la base de datos de 4K entre la operación de volver a efectuar la migración a la Versión 8.1 y la operación de volver a efectuar la migración a la Versión 8.2 se ocultan, de hecho, respecto al nivel de DB2 UDB más reciente, ya que los cambios no se migran al archivo de 16K existente.
El formato del archivo db2diag.log se ha mejorado de varias formas para la Versión 8.2. El archivo de anotaciones es ahora más fácil de leer manualmente y más sencillo de analizar en el software. Las mejoras incluyen:
También se han realizado otros cambios, como la modificación del nombre del campo base de datos por DB.
Se han añadido registros de sucesos como mensajes de diagnóstico al archivo db2diag.log. A continuación se muestran ejemplos de estos sucesos:
En los registros de sucesos se especifica "Event" en el campo LEVEL. Aunque los sucesos no constituyen errores, es posible que queden anotados en niveles de diagnóstico distintos del 4 (Informativo) o 3 (Aviso), en función de su importancia.
A partir de la Versión 8.2, las siguientes actualizaciones se anotan en el archivo db2diag.log:
Los mensajes de estas actualizaciones quedan anotados en niveles de diagnóstico altos debido a su importancia.
Se anotan los siguientes tipos de actualizaciones del registro de perfiles de db2set:
2004-04-22-19.19.14.156959-240 I79582C286 NIVEL: Suceso PID : 2437242 TID : 1 PROC : db2set INSTANCIA: db2user NODO : 000 FUNCIÓN : DB2 UDB, servici. sis. oper, db2set_main, prueba:40 CAMBIO : CFG DB2SET: DB2DBDFT: De: "OLDDB" A: "SAMPLE"
CAMBIO : CFG DB2SET: DB2DBDFT: De: "SAMPLE" A: ""
CAMBIO : CFG DB2SET: Se ha restablecido el registro de perfiles
A continuación se muestran ejemplos de actualizaciones de parámetros de configuración de DB y DBM.
CAMBIO : EJEMPLO BD CFG: "Maxlocks" De: "10" A: "20" CAMBIO : CFG DBM: "Diaglevel" De: "3" A: "1" CAMBIO : CFG DBM: Restablecidos los valores por omisión del sistema
Para buscar estos mensajes de actualización de la configuración, utilice la herramienta db2diag. Por ejemplo:
DB2 Universal Database(TM) (UDB) para Linux, UNIX y Windows(R), Versión 8.2.2 (equivalente a la Versión 8.1 FixPak 9) es compatible con JDK 1.4.2 en todos los entornos soportados de sistema operativo de estación de trabajo de 32 bits y 64 bits de DB2 UDB. Este soporte incluye, entre otros, soporte para crear y ejecutar aplicaciones cliente de Java(TM), crear y ejecutar rutinas de Java(TM) desde la línea de mandatos, crear y ejecutar rutinas de Java(TM) desde el Centro de desarrollo de DB2 donde está soportado, así como soporte para ejecutar otras herramientas de DB2.
Cuando instale DB2 UDB, Versión 8.2, también se instalará la última versión soportada del kit del desarrollador de Java, en el caso de que aún no esté instalada, a menos que la instalación de DB2 UDB sea una actualización de una instalación anterior de DB2 UDB Versión 8. Si está actualizando una instalación anterior de DB2 UDB Versión 8, debe instalar el kit del desarrollador de Java desde el CD.
En la tabla siguiente se indican los entornos de sistema operativo de estación de trabajo de 32 bits y 64 bits soportados, y el último nivel JDK soportado para cada uno de ellos. Para obtener información sobre el soporte JDK anterior, consulte la página Web de en la siguiente dirección: http://www.ibm.com/software/data/db2/udb/ad/v8/java/.
| Entorno DB2 soportado | Último nivel JDK soportado |
|---|---|
| Windows IA/AMD de 32 bits | JDK 1.4.2 |
| Windows IA de 64 bits | JDK 1.4.2 |
| Windows AMD/EM64T de 64 bits | JDK 1.4.2 |
| AIX(R) 4.3.3 de 32 bits | JDK 1.3.1 SR6 [2] |
| AIX(R) 5 (híbrido [1]) | JDK 1.4.2 |
| Solaris (híbrido [1]) | JDK 1.4.2 |
| HPUX RISC & Itanium (híbrido [1]) | JDK 1.4.2.01 |
| Linux AMD/EM64T de 32 bits, 64 bits (híbrido [1]) | JDK 1.4.2 [3] |
| Linux IA de 32 bits | JDK 1.4.2 |
| Linux IA de 64 bits | JDK 1.4.2 |
| Linux 390 de 31 bits | JDK 1.4.2 |
| Linux 390 de 64 bits | JDK 1.4.2 |
| Linux PPC (híbrido [1]) | JDK 1.4.2 |
A continuación se proporciona un procedimiento actualizado para configurar el entorno Java de Linux.
Para crear aplicaciones Java en Linux con soporte JDBC para DB2:
Para ejecutar procedimientos almacenados de Java o funciones definidas por el usuario, el editor de enlaces en tiempo de ejecución de Linux debe poder acceder a determinadas bibliotecas compartidas de Java, y DB2 UDB debe poder cargar ambas bibliotecas y la máquina virtual Java. El proceso que ejecuta procedimientos almacenados y funciones definidas por el usuario sólo carga bibliotecas en ubicaciones seguras, tal como está definido en el archivo /etc/ld.so.conf. Una de estas ubicaciones seguras es /usr/lib. Las instrucciones restantes muestran qué bibliotecas requieren enlaces simbólicos en /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.sodonde JAVAHOME es el directorio base de IBM(R) Developer Kit. Si DB2 UDB no puede encontrar estas bibliotecas, el usuario obtendrá un error -4301 cuando intente ejecutar una rutina Java, y el archivo de anotaciones de notificación de administración contendrá mensajes sobre las bibliotecas no encontradas.
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.sodonde JAVAHOME es el directorio base del IBM Developer Kit. Si DB2 UDB no puede encontrar estas bibliotecas, el usuario obtendrá un error -4301 cuando intente ejecutar una rutina Java, y el archivo de anotaciones de notificación de administración contendrá mensajes sobre las bibliotecas no encontradas.
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.sodonde JAVAHOME es el directorio base del IBM Developer Kit. Si DB2 UDB no puede encontrar estas bibliotecas, el usuario obtendrá un error -4301 cuando intente ejecutar una rutina Java, y el archivo de anotaciones de notificación de administración contendrá mensajes sobre las bibliotecas no encontradas.
JAVAHOME/jre/bindonde JAVAHOME es el directorio base del IBM Developer Kit. Si DB2 UDB no puede encontrar estas bibliotecas, el usuario recibe un error -4301 o -1042 al intentar ejecutar una rutina de Java.
En lugar de crear explícitamente enlaces con las bibliotecas compartidas del directorio /usr/lib, puede añadir el nombre del directorio donde residen las bibliotecas compartidas de Java al archivo /etc/ld.so.conf. Es necesario tener permiso de usuario root para acceder a ese archivo. Después de actualizar /etc/ld.so.conf, debe ejecutar el mandato ldconfig como usuario root para que los cambios que ha realizado sean efectivos. Si con este procedimiento alternativo encuentra algún problema, cree los enlaces en el directorio /usr/lib según las instrucciones anteriores.
Si está utilizando el sistema operativo Microsoft XP de 64 bits (2600) configurado para utilizar el protocolo NETBIOS con la familia de productos DB2, deberá obtener un hotfix de Microsoft. Póngase en contacto con Microsoft acerca del artículo de Knowledge Base número Q317437.
El sistema operativo Windows XP Home Edition sólo está soportado por el producto DB2 Universal Database (UDB) Personal Edition.
El sistema operativo Windows XP Professional está soportado por los siguientes productos de DB2:
Los siguientes productos de DB2 están soportados en Windows XP sólo con fines de desarrollo o pruebas (los entornos de producción requieren Windows 2000 o Windows Server 2003):
En DB2 Universal Database(TM) (UDB) Versión 8.2, los clientes de DB2 UDB Workgroup Server Edition y DB2 UDB Express Edition (cuando la licencia se basaba en un modelo de precios para cada usuario) no podían instalar la opción de DB2 UDB Recuperación de catástrofes de alta disponibilidad (HADR) con un precio independiente. Este problema se ha arreglado en DB2 UDB Versión 8.2 FixPak 1 (equivalente a la Versión 8.1 FixPak 8).
Los programas de utilidad de OLAP de DB2 Warehouse Manager Standard Edición, Versión 8.2 no son compatibles con IBM DB2 OLAP Server FP3 (nivel de API de Essbase 6.5.4) y posteriores. Resulta aconsejable utilizar DB2 OLAP Server FP2 (Essbase 6.5.3) o anteriores hasta que se solucione este problema.
Para utilizar anotaciones cronológicas con dispositivos de E/S en bruto anteriores a DB2 Universal Database (UDB) Versión 8.2.2 (equivalente a la Versión 8.1 Fixpak 9) era necesario asociar un dispositivo físico al controlador de dispositivo de caracteres en bruto de Linux mediante el programa de utilidad raw. A partir de DB2 UDB Versión 8.2.2 (equivalente a la Versión 8.1 FixPak 9), en el kernel 2.6 de Linux, la E/S en bruto para anotaciones cronológicas se puede especificar directamente. Por ejemplo, para utilizar la partición de dispositivo /dev/sdb1 para anotaciones cronológicas en bruto de la base de datos SAMPLE, emita el mandato siguiente:
db2 update db cfg for sample using newlogpath /dev/sdb1
Aunque DB2 UDB todavía admite el método de utilizar el programa de utilidad raw para la E/S en bruto, está posibilidad se ha descartado en distribuciones recientes y puede que se elimine en el futuro. El método preferido es utilizar el nuevo método especificando los dispositivos directamente.
DB2 Universal Database, Versión 8.2 da soporte a Red Hat Enterprise Linux AS Versiones 3 y 2.1. Sin embargo, el Centro de depósito de datos sólo da soporte a Red Hat Enterprise Linux AS, Versión 2.1. El Centro de depósito de datos utiliza controladores ODBC de DataDirect que no dan soporte a Red Hat Enterprise Linux AS, Versión 3.1. Por tanto, el Centro de depósito de datos no da soporte a los destinos de depósito ni a las fuentes de depósito de ODBC desde un sitio de agente de Red Hat Enterprise Linux AS, Versión 3.1.
Cuando se ejecutan aplicaciones en un entorno IBM(R) WebSphere(R) MQ (anteriormente conocido como entorno IBM MQSeries(R)), WebSphere(R) MQ puede actuar como gestor de transacciones compatible con XA, coordinando cualquier transacción distribuida con confirmación en dos fases. Cuando WebSphere(R) MQ actúa de esta manera como gestor de transacciones, y las fuentes de datos proceden de la familia de productos DB2, existen varios requisitos de configuración. La mayoría de estos requisitos ya están documentados. Por ejemplo, debe establecer el parámetro de configuración TP_MON_NAME de DB2 en "MQ" en el cliente de ejecución de DB2.
Sin embargo, existe un requisito de configuración que no se ha documentado. El requisito es específico de DB2 Connect cuando se conecta con fuentes de datos que son servidores de DB2 para OS/390(R): cuando se utiliza WebSphere MQ para coordinar transacciones distribuidas en las que intervienen servidores de DB2 para z/OS(R) y DB2 para iSeries, el concentrador de conexiones de DB2 Connect debe estar habilitado en la pasarela. El concentrador de conexiones está habilitado cuando el valor del parámetro de configuración MAX_CONNECTIONS es mayor que el valor de MAX_COORDAGENTS. Si no habilita el concentrador de conexiones, se producirán comportamientos inesperados en las transacciones.
La página de códigos Shift-JIS de la versión Japonesa de Microsoft Windows está registrada como el identificador de conjunto de caracteres codificados (CCSID) 943 de IBM. No obstante, la página de códigos Shift-JIS en la plataforma HP-UX está registrada como el CCSID 5039. El CCSID 5039 contiene caracteres JIS (Japanese Industry Standard) solamente y carece de caracteres definidos por el proveedor. Es posible utilizar una base de datos DB2 Universal Database (UDB) del CCSID 5039 en HP-UX para almacenar caracteres Shift-JIS, pero se producirá una conversión de página de códigos entre el CCSID 5039 y el CCSID 943. Cuando utilice aplicaciones Microsoft ODBC, puede encontrarse con un problema al convertir datos del CCSID 5039 a Unicode, debido a diferencias entre la tabla de conversión de página de códigos de IBM y la tabla de conversión de página de códigos de Microsoft.
La siguiente lista de caracteres, al convertirse desde el CCSID 5039 a Unicode, dará como resultado puntos de código distintos según la tabla de conversión que se utilice (IBM o Microsoft). Para estos caracteres, la tabla de conversión de IBM cumple con las normas Japanese Industry Standard JISX0208 y JISX0221.
| Punto de código Shift-JIS (nombre del carácter) | Punto de código primario de IBM (nombre de Unicode) | Punto de código primario de Microsoft (nombre de Unicode) |
|---|---|---|
| X'815C' (guión largo) | U+2014 (guión largo) | U+2015 (barra horizontal) |
| X'8160' (guión ondulado) | U+301C (guión ondulado) | U+FF5E (tilde de ancho completo) |
| X'8161' (línea vertical doble) | U+2016 (línea vertical doble) | U+2225 (paralelas) |
| X'817C' (signo menos) | U+2212 (signo menos) | U+FF0D (guión de ancho completo-signo menos) |
Por ejemplo, el carácter de guión largo, con el punto de código del CCSID 5039 de X'815C' se convierte al punto de código Unicode de U+2014 al utilizar la tabla de conversión de IBM, pero se convierte a U+2015 al utilizar la tabla de conversión de Microsoft. Esto puede crear problemas potenciales para las aplicaciones Microsoft ODBC porque U+2014 será tratado como un punto de código no válido. Para evitar tales problemas, DB2 UDB proporciona la tabla de conversión alternativa de Microsoft del CCSID 5039 a Unicode, además de la tabla de conversión de IBM por omisión. Es necesario sustituir la tabla de conversión de IBM por omisión por la tabla de conversión alternativa de Microsoft. Tenga en cuenta que la tabla de conversión de IBM por omisión de Unicode al CCSID 5039 coincide con la versión de Microsoft.
Al convertir desde el CCSID 5039 a Unicode, se utiliza la tabla de conversión de página de códigos por omisión de DB2 Universal Database (UDB). Si desea utilizar otra versión de la tabla de conversión, como, por ejemplo, la versión de Microsoft, deberá sustituir manualmente el archivo de la tabla de conversión por omisión (.cnv).
Antes de sustituir el archivo de la tabla de conversión de página de códigos existente en el directorio sqllib/conv, debe realizar una copia de seguridad del archivo por si desea volver a cambiarlo. En UNIX y Linux, el directorio sqllib/conv está enlazado con la vía de acceso de instalación de DB2 UDB.
Para que la sustitución de tablas de conversión resulte efectiva, es necesario cambiar la tabla de conversión de cada cliente DB2 UDB que se conecte a la misma base de datos. De lo contrario, los distintos clientes pueden almacenar el mismo carácter utilizando puntos de código diferentes.
Para sustituir la tabla de conversión por omisión de DB2 UDB a fin de convertir desde el CCSID 5039 a Unicode, siga estos pasos:
El identificador de conjunto de caracteres codificados (CCSID) de IBM para la página de códigos EUC de japonés está registrado como CCSID 954. El CCSID 954 es una codificación común para las plataformas UNIX y Linux en japonés. Cuando utilice las aplicaciones Microsoft ODBC para conectarse a una base de datos DB2 Universal Database (UDB) del CCSID 954, puede encontrarse con un problema al convertir datos del CCSID 954 a Unicode. El problema potencial es debido a diferencias entre la tabla de conversión de página de códigos de IBM y la de Microsoft. La tabla de conversión de IBM se adapta a los nombres de caracteres especificados en Japanese Industry Standard (JIS) JISX0208, JISX0212 y JISX0221.
Los caracteres siguientes, al convertirse desde el CCSID 954 a Unicode, darán como resultado puntos de código distintos según se utilice la tabla de conversión de IBM o la de Microsoft.
| Punto de código EUC-JP (nombre del carácter) | Punto de código primario de IBM (nombre de Unicode) | Punto de código primario de Microsoft (nombre de Unicode) |
|---|---|---|
| X'A1BD' (guión largo) | U+2014 (guión largo) | U+2015 (barra horizontal) |
| X'A1C1' (guión ondulado) | U+301C (guión ondulado) | U+FF5E (tilde de ancho completo) |
| X'A1C2' (línea vertical doble) | U+2016 (línea vertical doble) | U+2225 (paralelas) |
| X'A1DD' (signo menos) | U+2212 (signo menos) | U+FF0D (guión de ancho completo-signo menos) |
| X'8FA2C3' (barra rota) | U+00A6 (barra rota) | U+FFE4 (barra rota de ancho completo) |
Por ejemplo, el carácter de guión largo, con el punto de código del CCSID 954 de X'A1BD' se convierte al punto de código Unicode de U+2014 al utilizar la tabla de conversión de IBM, pero se convierte a U+2015 al utilizar la tabla de conversión de Microsoft. A causa de esta diferencia en la correlación de la conversión, puede obtener dos puntos de código distintos para el mismo carácter en una base de datos DB2 UDB Unicode, o en una columna gráfica de una base de datos DB2 UDB 954. Esto puede crear problemas potenciales para las aplicaciones Microsoft ODBC porque U+2014 será tratado como un punto de código no válido. Para evitar tales problemas, DB2 UDB proporciona la tabla de conversión alternativa de Microsoft del CCSID 954 a Unicode, además de la tabla de conversión de IBM por omisión. Es necesario sustituir la tabla de conversión de IBM por omisión por la tabla de conversión alternativa de Microsoft. Tenga en cuenta que la tabla de conversión de IBM por omisión de Unicode al CCSID 954 coincide con la versión de Microsoft.
Al convertir desde el CCSID 954 a Unicode, se utiliza la tabla de conversión de página de códigos por omisión de DB2 Universal Database (UDB). Si desea utilizar otra versión de la tabla de conversión, como, por ejemplo, la versión de Microsoft, deberá sustituir manualmente el archivo de la tabla de conversión por omisión (.cnv).
Antes de sustituir el archivo de la tabla de conversión de página de códigos existente en el directorio sqllib/conv, debe realizar una copia de seguridad del archivo por si desea volver a cambiarlo. En UNIX y Linux, el directorio sqllib/conv está enlazado a la vía de acceso de instalación de DB2 UDB.
Para que esta operación resulte efectiva, es necesario cambiar la tabla de conversión de cada cliente DB2 UDB que se conecte a la misma base de datos del CCSID 954. Si el cliente utiliza Windows en japonés, cuya página de códigos ANSI es Shift-JIS (CCSID 943), también tendrán que cambiarse las tablas de conversión por omisión de DB2 entre CCSID 943 y Unicode por la versión de Microsoft. De lo contrario, los distintos clientes pueden almacenar el mismo carácter utilizando puntos de código diferentes.
Para sustituir la tabla de conversión por omisión de DB2 UDB a fin de convertir desde el CCSID 954 a Unicode, siga estos pasos:
Para sustituir las tablas de conversión por omisión de DB2 UDB a fin de convertir entre el CCSID 943 y Unicode, siga estos pasos:
Si se utiliza la página de códigos Shift-JIS de la versión Japonesa de Microsoft Windows registrada como el identificador de conjunto de caracteres codificados (CCSID) de IBM 943, es posible que se encuentre con los dos problemas siguientes al convertir caracteres entre CCSID 943 y Unicode. El problema potencial se debe a las diferencias entre las tablas de conversión de páginas de códigos de IBM y Microsoft. Para evitar tales problemas, DB2 Universal Database (UDB) proporciona las tablas de conversión alternativas de Microsoft entre CCSID 943 y Unicode, además de las tablas de conversión de IBM por omisión.
Por motivos históricos, más de 300 caracteres de la página de códigos CCSID 943 se representan mediante dos o tres puntos de código cada uno. El uso de editores de método de entrada (IME) y de tablas de conversión de páginas de códigos hace que se entre sólo uno de estos puntos de código equivalentes. Por ejemplo, el carácter en minúscula correspondiente al numeral uno romano 'i' tiene dos puntos de código equivalentes: X'EEEF' y X'FA40'. Los IME de Microsoft Windows siempre generan X'FA40' cuando se entra 'i'. En general, IBM y Microsoft utilizan el mismo punto de código principal para representar el carácter, excepto para los 13 caracteres siguientes:
| Nombre del carácter (punto de código Unicode) | Punto de código Shift-JIS principal de IBM | Punto de código Shift-JIS principal de Microsoft |
|---|---|---|
| Uno numeral romano (U+2160) | X'FA4A' | X'8754' |
| Dos numeral romano (U+2161) | X'FA4B' | X'8755' |
| Tres numeral romano (U+2162) | X'FA4C' | X'8756' |
| Cuatro numeral romano (U+2163) | X'FA4D' | X'8757' |
| Cinco numeral romano (U+2164) | X'FA4E' | X'8758' |
| Seis numeral romano (U+2165) | X'FA4F' | X'8759' |
| Siete numeral romano (U+2166) | X'FA50' | X'875A' |
| Ocho numeral romano (U+2167) | X'FA51' | X'875B' |
| Nueve numeral romano (U+2168) | X'FA52' | X'875C' |
| Diez numeral romano (U+2169) | X'FA53' | X'875D' |
| Stock ideográfico entre paréntesis (U+3231) | X'FA58' | X'FA58' |
| Signo numérico (U+2116) | X'FA59' | X'8782' |
| Signo telefónico (U+2121) | X'FA5A' | X'8754' |
Los productos de IBM como DB2 UDB utilizan en primer lugar puntos de código de IBM, como X'FA4A' para representar el uno numeral romano en mayúsculas 'I', pero los productos de Microsoft utilizan X'8754' para representar el mismo carácter. Una aplicación Microsoft ODBC puede insertar el carácter 'I' como X'8754' en una base de datos DB2 UDB de CCSID 943 y el Centro de control de DB2 UDB puede insertar el mismo carácter como X'FA4A' en la misma base de datos CCSID 943. Sin embargo, las aplicaciones ODBC sólo encuentran las filas que tienen 'I' codificado como X'8754' y el Centro de control de DB2 UDB sólo puede localizar las filas que tienen 'I' codificado como X'FA4A'. Para permitir que el Centro de control de DB2 UDB seleccione 'I' como X'8754', tiene que sustituir las tablas de conversión por omisión de IBM entre CCSID 943 y Unicode por las tablas de conversión alternativas de Microsoft.
La siguiente lista de caracteres, cuando se convierten de CCSID 943 a Unicode, dan lugar a distintos puntos de código, en función de si se utiliza la tabla de conversión de IBM o la tabla de conversión de Microsoft. Para estos caracteres, la tabla de conversión de IBM cumple con los estándares Japanese Industry Standard JISX0208, JISX0212 y JISX0221.
| Punto de código Shift-JIS (nombre del carácter) | Punto de código primario de IBM (nombre de Unicode) | Punto de código primario de Microsoft (nombre de Unicode) |
|---|---|---|
| X'815C' (guión largo) | U+2014 (guión largo) | U+2015 (barra horizontal) |
| X'8160' (guión ondulado) | U+301C (guión ondulado) | U+FF5E (tilde de ancho completo) |
| X'8161' (línea vertical doble) | U+2016 (línea vertical doble) | U+2225 (paralelas) |
| X'817C' (signo menos) | U+2212 (signo menos) | U+FF0D (guión de ancho completo-signo menos) |
| X'FA55' (barra rota) | U+00A6 (barra rota) | U+FFE4 (barra rota de ancho completo) |
Por ejemplo, el carácter de guión largo con el punto de código del CCSID 943 de X'815C' se convierte al punto de código de Unicode U+2014 cuando se utiliza la tabla de conversión de IBM. Sin embargo, se convierte a U+2015 cuando se utiliza la tabla de conversión de Microsoft. A causa de esta diferencia en la correlación de la conversión, puede obtener dos puntos de código distintos para el mismo carácter en una base de datos DB2 UDB de Unicode. Esto puede crear problemas potenciales para las aplicaciones Microsoft ODBC porque U+2014 será tratado como un punto de código no válido. Para evitar este problema potencial, tiene que sustituir las tablas de conversión por omisión de IBM entre CCSID 943 y Unicode por las tablas de conversión alternativas de Microsoft.
El uso de tablas de conversión alternativas de Microsoft entre el CCSID 943 y Unicode se debe restringir a entornos cerrados, en los que los clientes de DB2 UDB y las bases de datos de DB2 UDB tengan la página de códigos CCSID 943 y utilicen las mismas tablas de conversión alternativas de Microsoft. Si tiene un cliente de DB2 UDB que utiliza las tablas de conversión por omisión de IBM y otro cliente de DB2 UDB que utiliza las tablas de conversión alternativas de Microsoft y ambos clientes insertan datos en la misma base de datos DB2 UDB de CCSID 943, es posible que el mismo carácter se almacene como distintos puntos de código en la base de datos.
Cuando realiza una conversión entre CCSID 943 y Unicode, se utilizan las tablas de conversión de páginas de código por omisión de DB2 Universal Database (UDB). Si desea utilizar otra versión de las tablas de conversión, como, por ejemplo, la versión de Microsoft, deberá sustituir manualmente los archivos de las tablas de conversión por omisión (.cnv).
Antes de sustituir los archivos de las tablas de conversión de páginas de códigos existentes en el directorio sqllib/conv, debe realizar una copia de seguridad de los archivos por si desea volver a cambiarlos. En UNIX y Linux, sqllib/conv está enlazado con la vía de acceso de instalación de DB2 UDB.
Para que la sustitución de tablas de conversión resulte efectiva, es necesario cambiar la tabla de conversión de cada cliente DB2 UDB que se conecte a la misma base de datos. De lo contrario, los distintos clientes pueden almacenar el mismo carácter utilizando puntos de código diferentes.
Para sustituir las tablas de conversión por omisión de DB2 UDB a fin de convertir caracteres entre el CCSID 943 y Unicode:
A pesar de que se menciona en la documentación, el sistema operativo MVS ya no está soportado en DB2 Universal Database. MVS ha sido sustituido por z/OS.
Es posible que las operaciones de copia de seguridad y restauración realizadas en varios dispositivos de cintas no funcionen si utiliza el sistema operativo Linux 390.
Cuando acceda al Centro de desarrollo en UNIX con Hummingbird Exceed, debe habilitar la extensión XTEST versión 2.2 a fin de que pueda mover y acoplar vistas arrastrando las barras de título dentro del Centro de desarrollo.
Para habilitar la extensión XTEST: