Cuando se emite el mandato export con un formato de archivo IXF y una cláusula SELECT *, se recoge información de índice, si es pertinente.
Si los nombres de columna especificados en el índice contienen los caracteres - o +, no se recoge información de índice y el usuario recibe el código SQL27984W de SQL. La exportación se realizará y los datos exportados no se verán afectados. Sin embargo, no se guardará información de índice en el archivo IXF.
Si vuelve a crear la tabla utilizando el mandato import con el parámetro CREATE, los índices no se reconstruirán. Para crear los índices por separado, utilice el programa de utilidad db2look.
La llamada a la API de db2ReadLog desde una aplicación puede originar un error si la aplicación se desconecta de la base de datos sin realizarse una operación de confirmación o retrotracción antes de la desconexión:
Para las aplicaciones de SQL no intercalado, active la modalidad de confirmación automática (autocommit) antes de llamar a la API de db2ReadLog.
Emita una sentencia COMMIT o ROLLBACK después de llamar a la API de db2ReadLog y antes de desconectar de la base de datos.
El mandato db2gcf inicia, detiene o supervisa una instancia de DB2 Universal Database (UDB), normalmente desde un script automatizado, como por ejemplo en un clúster HA (alta disponibilidad).
La utilización del mandato del sistema db2gcf con el parámetro -k en DB2 UDB Workgroup Server fallará.
El mandato "db2gcf -k" sólo funciona en DB2 UDB Enterprise Server Edition y no en DB2 UDB Workgroup Server Edition.
Si se ejecuta un servidor DB2 Universal Database (UDB) de 32 bits en un sistema AIX y una aplicación que se ejecuta en el mismo sistema tiene más de una conexión de bases de datos local a través del reiniciador DRDA, es posible que la aplicación reciba el siguiente error:
SQL1822N Código de error inesperado "-1224" recibido de la fuente de datos "W3_SERVER2". El texto y símbolos asociados son func="DriverConnect" msg="SQL1224N No se ha podido iniciar un agente de base de datos para atender una petición o se ha terminado como resultado de una conclusión del sistema de base de datos o un mandato force. " SQLSTATE=560BD
Para evitar este error, coloque la siguiente entrada en el archivo de configuración federado (directorio_instancia/cfg/db2dj.ini):
EXTSHM=ON
Como alternativa, puede catalogar la base de datos DB2 UDB local como si estuviera en un nodo TCP/IP. Por ejemplo:
CATALOG TCPIP NODE my_node REMOTE my_host SERVER 123; CATALOG DB mydb AT NODE my_node; CREATE WRAPPER drda; CREATE SERVER my_server TYPE DB2/UDB VERSION 8 WRAPPER drda AUTHORIZATION "my_id" PASSWORD "my_pw" OPTIONS(ADD DBNAME 'MYDB');
Si las teclas de atajo no funcionan en Microsoft Visual Studio .NET Framework 1.1, puede descargar un hotfix del sitio Web de Microsoft. Encontrará el hotfix en Microsoft Knowledge Base, artículo Q836745.
AIX ha cambiado el conjunto de códigos vinculado al entorno local de chino simplificado Zh_CN en:
El conjunto de códigos ha pasado de GBK (página de códigos 1386) a GB18030 (página de códigos 5488 ó 1392). Puesto que DB2 Universal Database (UDB) para AIX da soporte al conjunto de códigos GBK de forma nativa y al conjunto de códigos GB18030 mediante Unicode, DB2 UDB tomará por omisión ISO 8859-1 (página de códigos 819) como conjunto de códigos del entorno local Zh_CN y, en algunas operaciones, también tomará por omisión Estados Unidos (EE.UU.) como territorio del entorno local.
Para eludir esta limitación, tiene dos opciones:
Si elige utilizar la primera opción, emita los mandatos siguientes:
db2set DB2CODEPAGE=1386 db2set DB2TERRITORY=86 db2 terminate db2stop db2start
Si elige utilizar la segunda opción, cambie el entorno local de Zh_CN a ZH_CN o zh_CN. El conjunto de códigos del entorno local ZH_CN es Unicode (UTF-8), mientras que el conjunto de códigos del entorno local zh_CN es eucCN (página de códigos 1383).
Red Hat Versión 8 y posteriores (incluido Red Hat Enterprise Linux, versiones 2.1 y 3) han cambiado el conjunto de códigos por omisión para chino simplificado de GBK (página de códigos 1386) por GB18030 (página de códigos 5488 ó 1392).
Puesto que DB2 Universal Database (UDB) para Linux da soporte al conjunto de códigos GBK de forma nativa y al conjunto de códigos GB18030 mediante Unicode, DB2 UDB tomará por omisión ISO 8859-1 (página de códigos 819) como su conjunto de códigos y, en algunas operaciones, también tomará por omisión Estados Unidos (EE.UU.) como su territorio.
Para eludir esta limitación, tiene dos opciones:
Si elige utilizar la primera opción, emita los mandatos siguientes:
db2set DB2CODEPAGE=1386 db2set DB2TERRITORY=86 db2 terminate db2stop db2start
Si elige utilizar la segunda opción, emita cualquiera de los mandatos siguientes:
export LANG=zh_CN.gbk export LANG=zh_CN export LANG=zh_CN.utf8
donde el conjunto de códigos asociado a zh_CN es eucCN o la página de códigos 1383, y el conjunto de códigos asociado a zh_CN.utf8 es la página de códigos 1208.
Existen incompatibilidades con el soporte de Unicode cuando Merant Driver Manager accede al controlador ODBC de DB2 en UNIX. Dichas incompatibilidades hacen que Merant Driver Manager utilice Unicode incluso si la aplicación no ha solicitado utilizar Unicode. Esta situación puede conducir a problemas con componentes como el Centro de depósito de datos, el Gestor de catálogos de información y MQSI, que requieren que Merant Driver Manager dé soporte a fuentes de datos distintas de IBM. Puede utilizar una biblioteca de controlador ODBC de DB2 alternativa sin el soporte Unicode habilitado hasta que esté disponible una solución permanente.
Se incluye una biblioteca del controlador ODBC de DB2 alternativa sin el soporte Unicode habilitado con DB2 Universal Database (UDB) Versión 8.1 para AIX, HP-UX y Entorno operativo Solaris. Para utilizar esta biblioteca alternativa, deberá crear una copia de la misma, proporcionando a la copia el nombre de la biblioteca del controlador ODBC de DB2 original.
Para conmutar a la biblioteca ODBC sin Unicode en AIX, HP-UX o en el Entorno operativo Solaris, consulte las siguientes instrucciones. Puesto que esto es un proceso manual, deberá efectuarlo cada vez que actualice el producto, incluso después de la aplicación de los sucesivos FixPaks o niveles de modificación.
Para crear la biblioteca alternativa en AIX:
cp db2_36.o db2.o -r--r--r-- bin:bin for db2.o
Para volver al objeto original, siga el mismo procedimiento utilizando el archivo de copia de seguridad en lugar del archivo db2_36.o.
Para crear la biblioteca alternativa en un entorno operativo Solaris:
cp libdb2_36.so.1 libdb2.so.1 -r-xr-xr-x bin:bin libdb2.so.1
Para volver al objeto original, siga el mismo procedimiento utilizando el archivo de copia de seguridad en lugar del archivo libdb2_36.so.1.
Para crear la biblioteca alternativa en HP-UX PA-RISC:
cp libdb2_36.sl libdb2.sl -r-xr-xr-x bin:bin for libdb2.sl
Para volver al objeto original, siga el mismo procedimiento utilizando el archivo de copia de seguridad en lugar del archivo libdb2_36.sl.
Para crear la biblioteca alternativa en HP-UX en IA64:
cp libdb2_36.so libdb2.so -r-xr-xr-x bin:bin para libdb2.so
Para volver al objeto original, siga el mismo procedimiento utilizando el archivo de copia de seguridad en lugar del archivo libdb2_36.so.
Póngase en contacto con el soporte de IBM si necesita ayuda con DB2 UDB y Merant Driver Manager en otros sistemas operativos UNIX.
El APAR IY32512 para el NFS de AIX 5 puede hacer que el mandato db2stop no sea efectivo en sistemas que tengan un gran número de particiones.
En un servidor que recibe un gran número de peticiones para bloquear bloqueos de archivos que ya están bloqueados, cabe la posibilidad de que el daemon de bloqueo no responda. Esta situación se produce cuando todas las hebras de bloqueo disponibles están asignadas a hebras que esperan que los bloqueos estén disponibles, de modo que no hay ninguna hebra disponible para recoger el trabajo cuando la petición de desbloqueo llega.
Cuando se produce esta situación se deben reiniciar los nodos detenidos. Existe una solución temporal de DB2 Universal Database para esta situación que consiste en detener los nodos de uno en uno utilizando la opción NODENUM del mandato db2stop.
Si está habilitada la opción de precompilación SQLFLAG(STD), causará el error siguiente: Se ha producido la terminación anormal C6 durante la ejecución del programa de precompilación DSNHPC
Elimine la opción de precompilación SQLFLAG (STD) cuando utilice el Centro de desarrollo para crear procedimientos almacenados de SQL que se ejecuten en DB2 Universal Database para z/OS, Versión 8.
DB2 Connect(TM) no encamina conexiones hacia otro miembro de un DDF (Distributed Data Facility) cuando se ha cerrado el miembro de DDF que establece conexión perteneciente al grupo de compartimiento de datos de OS390. Si Sysplex está habilitado, DB2 Connect(TM) encamina conexiones hacia otro miembro del DDF de acuerdo con la lista de servidores.
El Sysplex de DB2 Connect Versión 8 se ha diseñado teniendo en cuenta la agrupación de agentes. La lista de servidores de Sysplex se libera si no existen agentes ni conexiones para una base de datos. Por tanto, se debe mantener como mínimo un agente para mantener la lista de servidores de Sysplex.
Habilite la agrupación de conexiones ejecutando los mandatos siguientes:
db2 update dbm cfg using num_poolagents número db2stop db2start
donde número es el número máximo de agentes que se pueden agrupar en la instancia de DB2. La agrupación de conexiones está habilitada cuando número es mayor que 0.
Establezca num_poolagents en -1, cuya resolución da como resultado la mitad del valor asignado al parámetro de configuración maxagents
Aunque aparece documentado en el manual DB2 Connect User's Guide, DB2 Connect Custom Advisor ya no recibe soporte en la Versión 8.2.
Esta anomalía también puede producirse al instalar DB2 UDB Versión 8.1 FixPak 7 en el caso de que hubiera actualizado manualmente el parámetro de configuración jdk_path del Servidor de administración de DB2 para que apunte al HP-UX SDK 1.4, o en el caso de que hubiera descartado y hubiera vuelto a crear el Servidor de administración de DB2 (DAS). La anomalía se produce debido a que, en cualquiera de estos casos, se cambió el parámetro de configuración jdk_path para que apuntara al HP-UX SDK 1.4.
Para ejecutarse de modo satisfactorio, una instancia de 32 bits de DB2 UDB Versión 8.2 requiere HP-UX SDK 1.3.
db2 update admin config using JDK_PATH /opt/java1.3
db2admin stop db2admin start
Si tiene problemas para visualizar los caracteres Indic cuando utilice las herramientas de la GUI de DB2, puede que no tenga instalados los fonts necesarios en el sistema.
DB2 Universal Database (UDB) ha empaquetado los siguientes fonts IBM TrueType y OpenType de idiomas Indic proporcionales, para su utilización. Puede encontrar estos fonts en el directorio font en cualquiera de los siguientes CD:
Estos fonts sólo deben utilizarse con DB2 UDB. No puede vender ni distribuir de forma generalizada y sin restricciones estos fonts:
Tipografía | Peso | Nombre de archivo de fonts |
---|---|---|
Devanagari MT para IBM | Medio | devamt.ttf |
Devanagari MT para IBM | Negrita | devamtb.ttf |
Tamil | Medio | TamilMT.ttf |
Tamil | Negrita | TamilMTB.ttf |
Telugu | Medio | TeluguMT.ttf |
Telugu | Negrita | TeleguMTB.ttf |
Encontrará instrucciones detalladas sobre cómo instalar los fonts y modificar el archivo font.properties en el apartado sobre internacionalización de la documentación de IBM Development Kit para Java.
Además, los productos de Microsoft siguientes se suministran con fonts Indic que pueden utilizarse con las herramientas de la GUI de DB2:
Con la excepción del asistente de instalación de DB2, las herramientas de la GUI no funcionarán en servidores zSeries que ejecuten el sistema operativo Linux. Esta limitación incluye cualquier elemento que normalmente se ejecuta desde el área de ejecución de la instalación, como, por ejemplo, la Visión general rápida.
Si desea utilizar las herramientas de la GUI con uno de estos sistemas, instale las herramientas administrativas en un sistema cliente con una configuración del sistema diferente y utilice este cliente para conectarse al servidor zSeries.
Para obtener resultados de búsqueda adecuados en el Centro de información de DB2, debe especificar entre comillas los términos de búsqueda que incluyan números.
Por ejemplo, si busca el siguiente término, no recibirá resultados:
1.4.1
Sin embargo, si especifica el término entre comillas, recibirá los resultados adecuados:
"1.4.1"
Una búsqueda del siguiente término devolverá temas adicionales:
DB20000I
Pero una búsqueda del siguiente término funcionará correctamente:
"DB20000I"
Si no se genera un archivo de anotaciones cronológicas del Centro de catálogos de información cuando importa archivos de lenguaje de códigos al mencionado Centro, realice los pasos siguientes para resolver el problema:
db2javit -j:com.ibm.db2.common.icm.tag.IcmImport -w: -i: -o:"-Xmx128m -Xms32m" -g:"d:\temp\myimport.trc" ...
Si no se han vinculado los paquetes de Query Patroller después de aplicar un FixPak, un usuario sin autorización DBADM o sin los privilegios correctos de Query Patroller puede encontrarse con el error siguiente al utilizar Query Patroller Center o la línea de mandatos de Query Patroller:
SQL0001N - La vinculación o precompilación no se ha completado satisfactoriamente.
Si utiliza Query Patroller Center, el error SQL0001N se anota cronológicamente en el archivo qpdiag.log. Si utiliza la línea de mandatos de Query Patroller, el error SQL0001N se devuelve a la consola.
Existe código de vinculación automática para iniciar la vinculación automática. No obstante, la vinculación automática falla cuando el usuario que se conecta no posee los privilegios necesarios para ejecutar todas las sentencias de los paquetes de Query Patroller. Un síntoma de este problema es que falten carpetas en Query Patroller Center.
Para evitar este problema, el que vincule los paquetes qpserver.lst manualmente debe ser un usuario con autorización DBADM o con los privilegios necesarios después de aplicar un FixPak.
Es posible que las consultas sometidas en Query Patroller reciban el código de SQL -29007 cuando no hay más puertos disponibles en Windows XP o Windows 2003. La posibilidad de obtener este error aumenta al aumentar el número de clientes que acceden a Query Patroller.
Defina las variables siguientes del registro de Windows:
MaxUserPort=65534 TcpTimedWaitDelay=30
y reinicie el sistema para que los cambios entren en vigor.
Encontrará detalles sobre la definición de variables del registro de Windows en el sitio Web de ayuda y soporte técnico de Microsoft(R), situado en http://support.microsoft.com/.
Puede que experimente problemas con permisos de archivos si utiliza DB2 Universal Database (UDB) en Windows y no es un administrador en el sistema Windows. Si recibe un mensaje de error SQL1035N, SQL1652N o SQL5005C, se muestran posibles causas y correcciones en la información siguiente:
Otorgue a los usuarios, como mínimo, el permiso MODIFICAR en el directorio dir_instancia en el nivel del sistema de archivos.
Es posible que algunos programas de ejemplo de XML Extender tengan el mismo nombre que otros programas instalados. Al invocar accidentalmente otro programa con el mismo nombre que un programa de ejemplo de XML Extender, pueden dañarse los archivos XML. La lista siguiente muestra los nombres antiguos de los programas de ejemplo de XML Extender, así como los nuevos nombres de los programas de sustitución que tienen menos probabilidades de causar conflictos. Asegúrese de utilizar los nuevos nombres de los programas de ejemplo en lugar de los antiguos para evitar que se dañen los archivos XML.
Programa antiguo (no utilizar) | Programa nuevo (utilizar) |
---|---|
insertx.exe | dxxisrt.exe |
retrieve.exe | dxxretr.exe |
retrieve2.exe | dxxretr2.exe |
retrievec.exe | dxxretrc.exe |
shred.exe | dxxshrd.exe |
tests2x.exe | dxxgenx.exe |
tests2xb.exe | dxxgenxb.exe |
tests2xc.exe | dxxgenxc.exe |
Programa antiguo (no utilizar) | Programa nuevo (utilizar) |
---|---|
insertx | dxxisrt |
retrieve | dxxretr |
retrieve2 | dxxretr2 |
retrievec | dxxretrc |
shred | dxxshrd |
tests2x | dxxgenx |
tests2xb | dxxgenxb |
tests2xc | dxxgenxc |
El código fuente (archivos .sqx) de los ejecutables listados anteriormente está ubicado en el directorio samples\db2xml\c de la instalación. Los archivos fuentes todavía están etiquetados con sus nombres antiguos. Si efectúa cambios en el código fuente, copie los ejecutables recién compilados (con los nombres antiguos) en el directorio sqllib\bin.
En plataformas Windows, debe hacer una copia adicional, renombrarla con su nuevo nombre y copiarla al directorio bin. Ambas copias sustituyen los archivos existentes en el directorio bin. Por ejemplo, después de compilar la nueva versión de shred.exe, necesita hacer dos copias y sustituir los archivos en el directorio bin: uno etiquetado como shred.exe y otro renombrado como dxxshrd.exe.
En las plataformas Linux y UNIX, sólo tiene que sustituir el archivo con el nombre antiguo por la versión recién compilada. Si crea nuevos archivos ejecutables a partir de estos ejemplos, debe copiar los nuevos archivos desde el directorio \SQLLIB\samples\db2xml\c\ en el directorio \SQLLIB\bin\ y, luego, crear una copia adicional renombrándolos de acuerdo con la tabla anterior.
Ahora puede descomponer los documentos que contienen atributos no exclusivos o nombres de elementos no exclusivos que se correlacionan con diferentes columnas (de la misma tabla o de diferentes tablas) sin recibir el error DXXQ045E. A continuación se muestra un ejemplo de un documento XML con nombres de elementos y atributos no exclusivos:
<Order ID="0001-6789"> <!-- Nota: el ID de nombre de atributo no es exclusivo --> <Customer ID = "1111"> <Name>John Smith</Name> </Customer> <!-- Nota: el nombre del elemento Name no es exclusivo --> <Salesperson ID = "1234"> <Name>Jane Doe</Name> </Salesperson> <OrderDetail> <ItemNo>xxxx-xxxx</ItemNo> <Quantity>2</Quantity> <UnitPrice>12.50</UnitPrice> </OrderDetail> <OrderDetail> <ItemNo>yyyy-yyyy</ItemNo> <Quantity>4</Quantity> <UnitPrice>24.99</UnitPrice> </OrderDetail> </Order>
El DAD que acompaña y que correlaciona los atributos y elementos duplicados con diferentes columnas tiene este aspecto:
<element_node name="Order"> <RDB_node> <table name="order_tab" key="order_id"/> <table name="detail_tab"/> <condition> order_tab.order_id=detail_tab.order_id </condition> </RDB_node> <!--ID atrib. dupli. después, pero correla. con una col. dif.--> <attribute_node name="ID"> <RDB_node> <table name="order_tab" /> <column name="order_id" type="char(9)"/> </RDB_node> </attribute_node> <element_node name="Customer"> <!--ID atrib. dupli. antes, pero correla. con una col. dif.--> <attribute_node name="ID"> <RDB_node> <table name="order_tab" /> <column name="cust_id" type="integer"/> </RDB_node> </attribute_node> <!--nombre elem. dupli. después, pero correla. con una col. dif.--> <element_node name="Name"> <text_node> <RDB_node> <table name="order_tab" /> <column name="cust_name" type="char(20)" /> </RDB_node> </text_node> </element_node> </element_node> <element_node name="Salesperson"> <!--ID atrib. dupli. antes, pero correla. con una col. dif.--> <attribute_node name="ID"> <RDB_node> <table name="order_tab" /> <column name="salesp_id" type="integer"/> </RDB_node> </attribute_node> <!--nombre elem. dupli. antes, pero correla. con una col. dif.--> <element_node name="Name"> <text_node> <RDB_node> <table name="order_tab" /> <column name="salesp_name" type="char(20)" /> </RDB_node> </text_node> </element_node> </element_node> <element_node name="OrderDetail" multi_occurrence="YES"> <element_node name="ItemNo"> <text_node> <RDB_node> <table name="detail_tab" /> <column name="itemno" type="char(9)"/> </RDB_node> </text_node> </element_node> <element_node name="Quantity"> <text_node> <RDB_node> <table name="detail_tab" /> <column name="quantity" type="integer"/> </RDB_node> </text_node> </element_node> <element_node name="UnitPrice"> <text_node> <RDB_node>detail_tab" /> <table name="detail_tab" /> <column name="unit_price" type="decimal(7,2)"/> </RDB_node> </text_node> </element_node> </element_node> </element_node>
El contenido de las tablas tendría un aspecto similar al ejemplo siguiente después de descomponer el documento anterior:
ORDER _TAB: ORDER_ID CUST_ID CUST_NAME SALESP_ID SALESP_NAME 0001-6789 1111 John Smith 1234 Jane Doe DETAIL_TAB: ORDER_ID ITEMNO QUANTITY UNIT_PRICE 0001-6789 xxxx-xxxx 2 12.50 0001-6789 yyyy-yyyy 4 24.99
Cuando se conecta a un sistema OS/390 mediante SNA, la capa VTAM del sistema principal emite automáticamente un compromiso al efectuarse una nueva conexión. El compromiso automático permite que el estado de la hebra de parte del sistema principal sea inactivo, e inmediatamente la hebra queda inactiva.
No obstante, cuando se conecta a un sistema OS/390 mediante TCP/IP, no se produce un compromiso automático. La propia aplicación debe emitir un compromiso explícito después de la conexión para permitir que la hebra quede inactiva en el sistema principal. Sin el compromiso explícito, la hebra está sujeta a un tiempo de espera excedido de hebra desocupada.
La solución que se sugiere es volver a escribir la aplicación de modo que realice un compromiso explícito si la conexión pasa a un estado desocupado después de establecerla.
[ Principio de página |Página anterior | Página siguiente | Contenido ]