Quando o comando export é emitido com um formato de arquivo IXF |e uma cláusula SELECT *, a informação do índice é coletada, se aplicável.
|Se os nomes da coluna especificados no índice contiverem caracteres - ou +, |a informação do índice não será coletada e você receberá um código SQL |SQL27984W. A exportação será concluída e os dados que estão sendo exportados não serão |afetados. Porém, a informação do índice não será salva no arquivo IXF.
Se você estiver recriando a tabela utilizando o comando import com o parâmetro CREATE, os índices não serão recriados. |Para criar os índices separadamente, utilize o utilitário db2look .
Chamar o API db2ReadLog a partir de um aplicativo, pode resultar em erro quando |o aplicativo desconectar do banco de dados, caso uma confirmação ou rollback não tiver |sido desempenhado antes da desconexão:
|Para aplicativos não-incorporados, configure o modo de confirmação automática como on antes de chamar |o API db2ReadLog.
Emita uma instrução COMMIT ou ROLLBACK após chamar o API db2ReadLog e |antes de desconectar do banco de dados.
O comando db2gcf inicia, pára ou monitora uma instância do DB2 UDB (Universal Database), geralmente de um script automatizado, como em um cluster HA (High Availability).
Utilizando o comando do sistema db2gcf com o parâmetro -k no DB2 UDB Workgroup Server falhará.
O comando "db2gcf -k" funciona apenas no DB2 UDB Enterprise Server Edition e não no DB2 UDB Workgroup Server Edition.
Se um servidor DB2 UDB (Universal Database) de 32 bits for executado em um sistema AIX e um aplicativo em execução no mesmo sistema tiver mais de uma conexão de banco de dados local através do wrapper DRDA, o aplicativo poderá obter o seguinte erro:
SQL1822N Código de erro inesperado "-1224" recebido da origem de dados "W3_SERVER2". Associated text and tokens are func="DriverConnect" msg="SQL1224N Não foi possível iniciar um agente de banco de dados para servir um pedido ou foi finalizado como um resultado de um encerramento do sistema de banco de dados ou de um comando de força. " SQLSTATE=560BD
Para evitar este erro, coloque a seguinte entrada no arquivo de configuração federado (diretório_da_instância/cfg/db2dj.ini):
EXTSHM=ON
Como alternativa, é possível catalogar o banco de dados local do DB2 UDB como estando em um nó TCP/IP. Exemplo:
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');
Se suas teclas de atalho não estiverem funcionando no Microsoft Visual Studio .NET Framework 1.1, você poderá fazer download de um hotfix a partir do Web site da Microsoft. O hotfix pode ser localizado no Microsoft Knowledge Base, artigo Q836745.
O AIX alterou o conjunto de códigos ligado ao código do idioma chinês simplificado Zh_CN no:
O conjunto de códigos foi alterado de GBK (página de código 1386) para GB18030 (página de código 5488 ou 1392). Como o DB2 UDB (Universal Database) para AIX suporta o conjunto de códigos GBK nativamente e o conjunto de códigos GB18030 através do Unicode, o DB2 UDB padronizará o conjunto de códigos do código do idioma Zh_CN para ISO 8859-1 (página de códigos 819) e em algumas operações também padronizará o território do código do idioma para US (Estados Unidos).
Para solucionar essa limitação, você tem duas opções:
Se você escolher utilizar a primeira opção, emita os seguintes comandos:
db2set DB2CODEPAGE=1386 db2set DB2TERRITORY=86 db2 terminate db2stop db2start
Se você optar por utilizar a segunda opção, altere o código de idioma de Zh_CN para ZH_CN ou zh_CN. O conjunto de códigos do código de idioma ZH_CN é Unicode (UTF-8), enquanto o conjunto de códigos do código de idioma zh_CN é eucCN (página de código 1383).
O Red Hat Versão 8 e posterior (incluindo o Red Hat Enterprise Linux [RHEL] versões 2.1 e 3) alteraram o conjunto de códigos padrão para chinês simplificado de GBK (página de códigos 1386) para GB18030 (página de códigos 5488 ou 1392).
Como o DB2 UDB (Universal Database) para Linux suporta o conjunto de códigos GBK nativamente e o conjunto de códigos GB18030 através do Unicode, o DB2 UDB padronizará seu conjunto de códigos para ISO 8859-1 (página de códigos 819) e em algumas operações padronizará também seu território para US (Estados Unidos).
Para solucionar essa limitação, você tem duas opções:
Se você escolher utilizar a primeira opção, emita os seguintes comandos:
db2set DB2CODEPAGE=1386 db2set DB2TERRITORY=86 db2 terminate db2stop db2start
Se você escolher utilizar a segunda opção, emita um dos seguintes comandos:
export LANG=zh_CN.gbk export LANG=zh_CN export LANG=zh_CN.utf8
em que o conjunto de códigos associado ao zh_CN é eucCN ou página de código 1383 e, ao zh_CN.utf8, é a página de código 1208.
Existem incompatibilidades com o suporte Unicode quando o Merant Driver Manager acessa o driver ODBC do DB2 no UNIX. Essas incompatibilidades fazem com que o Merant Driver Manager utilize o Unicode mesmo que o aplicativo não tenha solicitado o seu uso. Esta situação pode levar a problemas com produtos como o Centro de Data Warehouse, Gerenciador de Catálogos de Informações e MQSI, que requerem que o Merant Driver Manager suporte origens de dados não IBM. Você pode utilizar uma biblioteca alternativa do driver ODBC do DB2 sem suporte Unicode ativado até que uma solução permanente esteja disponível.
Uma biblioteca alternativa do driver ODBC do DB2 sem suporte Unicode ativado é incluída com o DB2 UDB (Universal Database) Versão 8.1 para AIX, HP-UX e Solaris Operating Environment. Para utilizar essa biblioteca alternativa, você deve criar uma cópia dela, fornecendo à cópia o nome da biblioteca do driver ODBC do DB2 original.
Para mudar para a biblioteca ODBC não-Unicode no AIX, HP-UX ou Solaris Operating Environment, consulte as instruções a seguir. Como este é um processo manual, é necessário executá-lo sempre que atualizar seu produto, inclusive após a aplicação de FixPaks ou níveis de modificação sucessivos.
Para criar a biblioteca alternativa no AIX:
cp db2_36.o db2.o -r--r--r-- bin:bin for db2.o
Para voltar para o objeto original, siga o mesmo procedimento utilizando o arquivo de backup em vez do db2_36.o.
Para criar a biblioteca alternativa em um Solaris Operating Environment:
cp libdb2_36.so.1 libdb2.so.1 -r-xr-xr-x bin:bin libdb2.so.1
Para voltar para o objeto original, siga o mesmo procedimento utilizando o arquivo de backup em vez do libdb2_36.so.1.
Para criar a biblioteca alternativa no HP-UX PA-RISC:
cp libdb2_36.sl libdb2.sl -r-xr-xr-x bin:bin for libdb2.sl
Para voltar para o objeto original, siga o mesmo procedimento utilizando o arquivo de backup em vez do libdb2_36.sl.
Para criar a biblioteca alternativa no HP-UX no IA64:
cp libdb2_36.so libdb2.so -r-xr-xr-x bin:bin for libdb2.so
Para voltar ao objeto original, siga o mesmo procedimento utilizando o arquivo de backup em vez do arquivo libdb2_36.so.
Entre em contato com o Suporte IBM se você precisar de assistência com o DB2 UDB e o Merant Driver Manager em outros sistemas operacionais UNIX.
AIX 5 NFS APAR IY32512 pode fazer com que o comando db2stop falhe em sistemas com um grande número de partições.
Em um servidor que recebe grandes números de pedidos de bloqueios de travamentos em arquivos já travados, o daemon de travamento pode não responder. Isso acontece quando todos os encadeamentos de trava disponíveis estão alocados nos encadeamentos, aguardando que as travas sejam disponibilizadas, portanto, não há encadeamento disponível para coletar o trabalho quando o pedido de destravamento é feito.
Quando esta situação ocorrer, os nós parados devem ser reiniciados. Há uma solução alternativa do DB2 Universal Database para essa situação parando os nós um de cada vez utilizando a opção NODENUM do comando db2stop.
Se a opção de pré-compilação SQLFLAG (STD) estiver ativada, ela causará o seguinte erro: C6 abortado ao executar o programa DSNHPC de Pré-compilação
Remova a opção de pré-compilação SQLFLAG (STD) ao utilizar o Development Center para criar procedimentos armazenados SQL para serem executados no DB2 Universal Database para z/OS, Versão 8.
| | |O DB2 Connect(TM) não trilha conexões para outros membros de um DDF |(Distributed Data Facility) quando o membro de conexão do DDF no grupo de compartilhamento |de dados em OS390 foi encerrado. Com o Sysplex ativado, o DB2 Connect trilha |conexões para outro membro em DDF de acordo com a lista de servidor.
|O Sysplex do DB2 Connect Versão 8 foi projetado pensando no conjunto de agente. |A lista de servidor do Sysplex é liberada se não houver agentes e conexões |para um banco de dados. Porém, pelo menos um agente deve ser armazenado para manter a |lista de servidor do Sysplex.
Ative o conjunto de conexão executando os comandos a seguir:
|db2 update dbm cfg using num_poolagents number |db2stop |db2start
em que number é o |número máximo de agentes permitidos para serem unidos na instância DB2. O conjunto de |conexão é ativado quando number for |maior que 0.
|Configure num_poolagents como -1, o que separa metade do valor |designado para o parâmetro de configuração maxagents
Apesar de estar documentado no DB2 Connect User's Guide, o DB2 Connect Custom Advisor não é mais suportado na Versão 8.2.
Esse defeito também pode ocorrer ao instalar o DB2 UDB Versão 8.1 FixPak 7 se você atualizou manualmente o parâmetro de configuração jdk_path do DB2 Administration Server para apontar para o HP-UX SDK 1.4 ou se você soltou e recriou o DAS (DB2 Administration Server). O defeito ocorre porque, em qualquer um desses casos, o parâmetro de configuração jdk_path mudou para apontar para o HP-UX SDK 1.4.
Uma instância de 32 bits do DB2 UDB Versão 8.2 requer HP-UX SDK 1.3 para ser executada com êxito.
db2 update admin config using JDK_PATH /opt/java1.3
db2admin stop db2admin start
Se você tiver problemas para exibir caracteres indianos ao utilizar as ferramentas da GUI do DB2, você pode não ter as fontes requeridas instaladas no seu sistema.
O DB2 UDB (Universal Database) fornece as seguintes fontes de idioma indiano proporcionais IBM TrueType e OpenType para sua utilização. Você pode localizar estas fontes no diretório font em qualquer um dos seguintes CDs:
Essas fontes devem ser utilizadas apenas junto com o DB2 UDB. Você não pode utilizar a venda ou distribuição geral ou irrestrita destas fontes:
Tipo | Peso | Nome do Arquivo Backup |
---|---|---|
Devanagari MT para IBM | Média | devamt.ttf |
Devanagari MT para IBM | Negrito | devamtb.ttf |
Tâmil | Média | TamilMT.ttf |
Tâmil | Negrito | TamilMTB.ttf |
Telugu | Média | controladores |
Telugu | Negrito | TeleguMTB.ttf |
Instruções detalhadas sobre como instalar as fontes e modificar o arquivo font.properties podem ser localizadas na seção Internationalization da Documentação IBM Development Kit Java.
Além disso, os produtos Microsoft a seguir vêm com fontes indianas que podem ser utilizadas com ferramentas da GUI do DB2:
Com a exceção do assistente de configuração do DB2, as ferramentas da GUI não funcionarão em servidores zSeries executando o sistema operacional Linux. Esta limitação inclui os itens ativados normalmente a partir da barra de lançamento Instalação, como o Quick Tour.
Se desejar utilizar as ferramentas da GUI com um desses sistemas, instale as ferramentas administrativas em um sistema cliente com uma configuração de sistema diferente e utilize esse cliente para se conectar ao seu servidor zSeries.
Para obter resultados exatos da procura no DB2 Information Center, é necessário colocar entre aspas os termos da procura que incluem números.
Por exemplo, se você procurar o seguinte termo, não receberá nenhum resultado:
1.4.1
No entanto, se você colocar o termo entre aspas, receberá os resultados apropriados:
"1.4.1"
Uma procura pelo seguinte termo retornará tópicos extras:
DB20000I
Mas uma procura pelo seguinte termo funcionará corretamente:
"DB20000I"
Se um arquivo de log do Centro de Catálogo de Informações não for gerado durante a importação de arquivos com idioma com tags no Centro de Catálogo de Informações, execute as seguintes etapas de resolução de problemas:
db2javit -j:com.ibm.db2.common.icm.tag.IcmImport -w: -i: -o:"-Xmx128m -Xms32m" -g:"d:\temp\myimport.trc" ...
Se os pacotes do Query Patroller não estiverem ligados após aplicar um fixpak, um usuário sem autoridade DBADM ou privilégios do Query Patroller pode encontrar os seguintes erros quando estiver utilizando o Query Patroller Center ou a linha de comandos do Query Patroller:
SQL0001N - A ligação ou pré-compilação não foi concluída com sucesso.
Se estiver utilizando o Query Patroller Center, o erro SQL0001N é registrado no arquivo qpdiag.log. Se estiver utilizando a linha de comandos do Query Patroller, o SQL0001N é devolvido ao console.
O código de ligação automática existe para inicializar a ligação automática. Entretanto, a ligação automática pode falhar se o usuário conectado não tem os privilégios requeridos para executar todas as instruções nos pacotes do Query Patroller. Um sintoma desse tipo de problema é o desaparecimento de pastas dentro do Centro do Query Patroller.
Para evitar esse problema, os pacotes qpserver.lst devem ser ligados manualmente por um usuário com autoridade DBADM ou privilégios necessários após aplicar um fixpak.
As consultas fornecidas no Query Patroller podem receber o código SQL -29007 quando não há mais portas disponíveis no Windows XP ou Windows 2003. A probabilidade deste erro aumenta proporcionalmente com um número maior de clientes que acessam o Query Patroller.
Configure as variáveis de registro do Windows a seguir:
MaxUserPort=65534 TcpTimedWaitDelay=30
e reinicie seu sistema para que as alterações entrem em vigor.
Detalhes sobre a configuração das variáveis de registro do Windows podem ser localizados no web site de Ajuda e Suporte da Microsoft(R) em http://support.microsoft.com/.
Você poderá ter problemas de permissão de arquivo se estiver utilizando o DB2 UDB (Universal Database) no Windows e não for um administrador no sistema Windows. Se você receber uma mensagem de erro SQL1035N, SQL1652N ou SQL5005C, as possíveis causas e soluções alternativas são mostradas a seguir:
Conceder aos usuários, pelo menos, a permissão MODIFY para o diretório instance_dir no nível do sistema de arquivos.
Alguns programas de amostras do XML Extender podem ter o mesmo nome de outros programas instalados. Chamar acidentalmente outro programa que tenha o mesmo nome do programa de amostra do XML Extender pode danificar seus arquivos XML. A lista a seguir mostra os programas de amostra do XML Extender além de novos nomes de programas de substituição que causarão menos conflitos. Certifique-se de utilizar os novos nomes dos programas de amostras ao invés dos antigos para prevenir danos aos arquivos XML.
Programa Antigo (Não Utilizar) | Novo Programa (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 Antigo (Não Utilizar) | Novo Programa (Utilizar) |
---|---|
insertx | dxxisrt |
retrieve | dxxretr |
retrieve2 | dxxretr2 |
retrievec | dxxretrc |
shred | dxxshrd |
tests2x | dxxgenx |
tests2xb | dxxgenxb |
tests2xc | dxxgenxc |
O código fonte (arquivos .sqx) para os executáveis listados acima está localizado no diretório samples\db2xml\c de sua instalação. Os arquivos de origem ainda estão rotulados com seus nomes antigos. Se você fizer alterações no código fonte, copie os executáveis recém-compilados (com os nomes antigos) para o diretório sqllib\bin.
Em plataformas Windows, você deve fazer uma cópia adicional, renomeá-la com seu novo nome acima e copiá-la para o diretório bin. As duas cópias substituem os arquivos existentes no diretório bin. Por exemplo, depois de compilar sua nova versão do shred.exe, é necessário fazer duas cópias e substituir os arquivos no diretório bin: um identificado como shred.exe e o outro renomeado dxxshrd.exe.
Em plataformas Linux e UNIX, é necessário apenas substituir o arquivo com o nome antigo pela versão recém-compilada. Se criar os novos arquivos executáveis a partir dessas amostras, você deverá copiar os novos arquivos a partir do diretório \SQLLIB\samples\db2xml\c\ para o diretório \SQLLIB\bin\ e fazer uma cópia adicional, renomeando-os de acordo com a tabela acima.
Agora você pode decompor documentos que contenham nomes de atributos e/ou de elementos não exclusivos que são mapeados para diferentes colunas (de tabelas iguais ou diferentes) sem receber o erro DXXQ045E. A seguir está um exemplo de um documento XML com nomes de atributos e elementos não-exclusivos:
<Order ID="0001-6789"> <!-- Note: attribute name ID is non-unique --> <Customer ID = "1111"> <Name>John Smith</Name> </Customer> <!-- Note: element name Name is non_unique --> <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>
O DAD de acompanhamento, que mapeia os elementos/atributos duplicados para diferentes colunas, tem o seguinte 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> <!--attribute ID duplicated below, but mapped to a different col--> <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"> <!--attribute ID duplicated above, but mapped to a different col--> <attribute_node name="ID"> <RDB_node> <table name="order_tab" /> <column name="cust_id" type="integer"/> </RDB_node> </attribute_node> <!--element name duplicated below, but mapped to a different col--> <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"> <!--attribute ID duplicated above, but mapped to a different col--> <attribute_node name="ID"> <RDB_node> <table name="order_tab" /> <column name="salesp_id" type="integer"/> </RDB_node> </attribute_node> <!--element name duplicated above, but mapped to a different col--> <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>
O conteúdo das tabelas teriam o seguinte aspecto após a decomposição do documento acima:
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
Ao conectar a um sistema OS/390 utilizando SNA, a camada VTAM do host envia automaticamente uma consolidação quando uma nova conexão é feita. A consolidação automática permite que o estado de encadeamento do lado do host fique inativo e o encadeamento se torna inativo imediatamente.
Porém, ao conectar-se a um sistema OS/390 utilizando TCP/IP, não há consolidação automática. O próprio aplicativo deve enviar uma consolidação explícita após a conexão para permitir que o encadeamento fique inativo no host. Sem a consolidação explícita, o encadeamento está sujeito à uma finalização de encadeamento inativo.
A sugestão é regravar o aplicativo para que ele execute uma consolidação explícita se a conexão tornar-se inativa após a conexão.
[ Início da Página |Página Anterior | Próxima Página | Índice ]