Cenário: Depois de atualizar o servidor para
DB2 Universal Database (DB2 UDB)
Versão 8.1 Fix Pack 10 (também conhecido como Versão 8.2 Fix Pack 3), uma
mensagem de erro SQL0443N do DB2 será emitida se você invocar uma
função do catálogo do DB2 Call Level Interface (CLI), como SQLTables(),
SQLColumns() ou SQLStatistics(). Um exemplo de mensagem de erro é:
SQL0443N A rotina "SYSIBM.SQLTABLES"
(nome específico "TABLES") retornou um erro SQLSTATE com o texto de diagnóstico SYSIBM:CLI:-805". SQLSTATE=38553.
Solução: Ligue o arquivo db2schema.bnd a cada banco de dados, digitando os seguintes comandos em um prompt de comandos:
db2 terminate
db2 connect to database-name
db2 bind path\db2schema.bnd blocking all grant public sqlerror continue
db2 terminate
em que database-name é o nome do banco de dados ao qual os utilitários devem ser ligados e path é o nome completo do caminho do diretório onde os arquivos de ligação estão localizados.
Por exemplo, o local padrão em Windows é C:\Program
Files\IBM\SQLLIB\bnd\.
Para
listar todos os nomes do banco de dados para uma instância específica do DB2, execute o comando CLI do DB2db2 list
database directory. Para obter informações adicionais, consulte a documentação do DB2.
A Mensagem de Erro SQL0805N do DB2 é
Emitida
Cenário: Ao executar o comando mqsicreatebroker, ou quando um fluxo de mensagens que inclui um nó de Banco de Dados for executado, o erro SQL
SQL0805N NULLID.SQLLF000 é enviado.
Solução: Abra uma janela do Command Line Processor do DB2
e emita um comando de ligação para o banco de dados.
Em sistemas Linux e UNIX, digite os comandos:
connect to db
bind ~/sqllib/bnd/@db2cli.lst grant public CLIPKG 5
connect reset
em que db é o nome do banco de dados.
Em sistemas Windows, digite os comandos:
connect to db
bind x:\sqllib\bnd\@db2cli.lst blocking all grant public
connect reset
em que x: identifica a unidade na qual instalou o DB2, e me quedb é o nome do banco de dados.
A Mensagem de Erro SQL0998N do DB2 é
Emitida
Cenário: Ao utilizar um fluxo de mensagens globalmente coordenadas
com um banco de dados do DB2 8.1, um erro SQL0998N
é emitido com Código de Razão 09 e Subcódigo 02.
Solução: Utilize o procedimento a seguir para definir o parâmetro de configuração do gerenciador
de banco de dados do DB2TP_MON_NAME para MQ e alterar XAOpenString no arquivo qm.ini para o
gerenciador de banco de dados:
Para configurar o parâmetro TP_MON_NAME, utilize o
comando a seguir a partir de um login que possui autoridade administrativa para a instância do DB2:
db2 update dbm cfg using TP_MON_NAME MQ
Pare e reinicie a instância do DB2,
para que o valor seja reconhecido.
Para configurar o valor AXLIB no arquivo qm.ini, altere o
XAOpenString para corresponder ao exemplo a seguir:
Configure o caminho de biblioteca AXLIB para um dos seguintes valores, dependendo de seu sistema operacional:
No Windows:
AXLIB=mqmax
No AIX:
AXLIB=usr/mqm/lib/libmqmax_r.a
No HP-UX:
AXLIB=/opt/mqm/lib/libmqmax_r.sl
No Linux:
AXLIB=/opt/mqm/lib/libmqmax_r.so
No Solaris:
AXLIB=/opt/mqm/lib/libmqmax.so
Pare e inicie novamente o intermediário e o gerenciador de filas para que essas alterações sejam
efetivadas.
A mensagem de erro SQL0998N ou SQL1248N do DB2 é emitida
Cenário: Ao tentar utilizar um fluxo de mensagens globalmente coordenado com um banco de dados
DB2 versão 8.1, você obtém uma das seguintes mensagens de erro:
SQL0998N com Código de Razão 09 e Subcódigo ""
SQL1248N com uma mensagem indicando que o banco de dados não está definido com o gerenciador de transações
Cenário: Você está utilizando o DB2
e a mensagem de erro BIP2322 é emitida com o erro SQL1040N.
Explicação: A mensagem do DB2 a seguir
indica que o valor DB2
do parâmetro de configuração maxappls do banco de dados foi alcançado:
"SQL1040N O número máximo de aplicativos já está conectado ao banco de dados.
SQLSTATE=57030"
DB2 rejeitou a tentativa de conexão.
Se esse banco de dados for um dos bancos de dados definidos do intermediário, implicando que um pedido de conexão de encadeamento do intermediário falhou, provavelmente o intermediário não está
funcionando corretamente.
Solução:
Pare todos os intermediários que se conectam ao banco de dados afetado.
Aumente o valor do parâmetro de configuração maxappls. Além disso, verifique o valor do parâmetro associado maxagents e aumente-o em linha com o maxappls.
Reinicie o banco de dados do DB2.
A mensagem de erro SQL1224N
DB2 é emitida ao conectar-se ao DB2
Cenário: A mensagem de erro do DB2SQL1224N é enviada quando você se conecta ao DB2. Este erro indica que um agente de
banco de dados não pôde ser iniciado ou que foi finalizado como resultado
de um comando de encerramento ou force do banco de dados.
Solução: No AIX,
utilize o nó TCP/IP para conectar-se ao DB2 para evitar o limite de 10 conexões da memória compartilhada. Para configurar o AIX e o auto-retorno do DB2 para utilizar uma conexão TCP/IP:
Utilize o comando mqsideletebroker para excluir seu intermediário.
Configure o DB2 para utilizar TCP/IP,
e para iniciar o listener TCP/IP. Na máquina do servidor, efetue login como o proprietário da instância do DB2, geralmente db2inst1, e emita os seguintes comandos:
db2set DB2COMM=tcpip
db2stop
db2start
Se a porta de Conexão do DB2 não
estiver definida em /etc/services, edite o arquivo
services para incluir as portas de Conexão e Interrupção do
DB2. Você deve utilizar nomes exclusivos e números de porta que ainda
não estejam definidos no arquivo services; por exemplo:
db2svc1 3700/tcp # DB2 Connection Service
db2isvc1 3701/tcp # DB2 Interrupt Service
Atualize a configuração do DB2;
por exemplo:
db2 update dbm cfg using svcenamedb2svc1
em quedb2svc1 é o nome do serviço de porta Conexão doDB2 em
/etc/services.
Como alternativa, você pode especificar um número de porta diretamente.
Pare e reinicie o banco de dados utilizando os seguintes
comandos:
db2stop
db2start
Catalogue um novo nó de conexão TCP/IP:
db2 catalog tcpip node NODENAME remote HOSTNAME server db2svc1
em que:
NODENAME
é o nome do novo nó de conexão TCP/IP. É possível utilizar local como
o nome de seu nó, desde que seja um identificador exclusivo.
HOSTNAME
é o nome de seu computador.
db2svc1
é o nome do serviço de porta de conexão do DB2 em /etc/services.
A mensagem DB20000I é exibida
quando o comando é concluído com êxito.
Catalogue o banco de dados com um novo nome de alias, por exemplo:
db2 catalog database DATABASE comoDBALIAS no nó NODENAME
em que:
DATABASE
é o nome físico do banco de dados.
DBALIAS
é o nome do alias do banco de dados que você deseja utilizar.
Especifique o novo nome de alias em todas as referências subseqüentes para o banco de dados locais; por exemplo quando você executa o comando mqsicreatebroker.
Pare e inicie o DB2:
db2 terminate
db2stop
db2start
Efetue logon utilizando o ID de usuário de serviço do intermediário.
Atualize o arquivo de configuração ODBC
para cada intermediário para incluir definições ao banco de dados (o arquivo
odbc.ini do arquivo padrão está em no diretório /var/wmqi/odbc):
Na parte superior do arquivo, inclua uma definição para o nome do alias do banco de dados:
DBALIAS=IBM DB2 ODBC Driver
Inclua uma nova sub-rotina para alias de banco de dados:
[DBALIAS]
Driver=INSTHOME/sqllib/lib/libdb2.a
Description=Broker Database Alias
Database=DBALIAS
em queINSTHOME é o caminho de seu diretóri ode Instâncias do
DB2.
Crie um novo intermediário utilizando DBALIAS no parâmetro -n; por exemplo:
Inicie o intermediário e redefina-o no ambiente de trabalho.
Implemente o intermediário e teste os fluxos.
A Mensagem de Erro SQLSTATE=58005 do DB2 É Emitida
Cenário: O erro SQLSTATE=58005 do DB2 é emitido quando você utiliza o WebSphere Message Broker no Linux com o DB2 Versão 8.1 e Fix Pack 9.
Explicação: Esse erro é emitido quando os valores dos parâmetros do kernel (msgmni, sem) são muito baixos.
Solução: Aumente os parâmetros de kernel (msgmni, sem).
Esses parâmetros de kernel devem estar significativamente acima de seus valores mínimos e pelo menos o mais alto dos valores recomendados para DB2, WebSphere MQ e WebSphere Message Broker.
O exemplo a seguir mostra valores possíveis para um ambiente de carga de trabalho pesado, no qual o intermediário possui dois grupos de execução com 200 fluxos de mensagens implementados e aproximadamente 45 aplicativos que estão utilizando esses fluxos de mensagens:
As Mensagens de Erro do DB2 ou ODBC são
Emitidas no z/OS
Cenário: Mensagens do DB2 ou
ODBC são emitidas no z/OS indicando que:
Uma exceção foi capturada ao emitir o comando de SQL connect do banco de dados.
Houve um erro do banco de dados com um código de retorno ODBC -1, um estado SQL
58004 e um código de erro nativo -99999.
O servidor intermediário fez uma tentativa mal-sucedida de acessar o banco de dados
utilizando um ID de usuário específico.
Solução: Se uma mensagem ODBC for exibida:
Ativa o rastreamento de aplicativos ODBC para produzir o arquivotraceodbc.
Localizar o arquivo traceodbc. Isto está localizado no subdiretório /output. Por exemplo,/u/argo/VCP0BRK/output/traceodbc.
Vá para o final desse arquivo e procure instâncias anteriores de SQLerror.
Problemas comuns do DB2 incluem:
código de retorno ODBC -1, estado SQL 58004, Código de erro
nativo -99999
Ele pode ser causado por:
Sem código SQL. O subsistema do DB2 não foi inicializado
O RRS não está iniciado.
SQLCODE 922.
O ID do usuário da tarefa iniciada não está autorizado a
utilizar o plano DSNACLI.
Código de retorno
ODBC -1, Estado SLQ 42503, Código de erro nativo -553
Isso pode
ser causado pelo ID do usuário da tarefa iniciada não estar
autorizado a utilizar o ID de SQL atual.
Reconfigure o intermediário e especifique DB2_TABLE_NAME
como um nome válido ou crie um grupo RACF
e conecte o ID do usuário da tarefa iniciada a este grupo.
A Mensagem de Erro BIP1780 É Emitida no AIX
Cenário: A mensagem de erro BIP1780 é emitida no AIX, indicando que o ID do usuário não pôde ser validado.
Explicação: Se você alterar a senha do sistema operacional AIX após criar o intermediário, ao executar uma ação, como implementar um arquivo bar, ele falha, pois a alteração da senha faz com que a conexão com o banco de dados
DB2 falhe.
Solução: Execute o comando mqsichangebroker para obter o ID do usuário utilizado para conectar ao banco de dados:
mqsichangebrokerbroker -p password
Isso permite que o
DB2 autentique o ID do usuário corretamente.
Você Não Sabe quantas Conexões de Banco de Dados um
Intermediário Requer
Cenário: Não é necessário saber quantas conexões de banco de dados precisam ser definidas para seu intermediário.
Solução: Determine o número de conexão com o banco de dados
requeridas por um intermediário para planejamento de capacidade e recursos.
No DB2, a ação padrão adotada é limitar o número de conexões simultâneas a um banco de dados para
o valor do parâmetro de configuração maxappls; o padrão
para maxappls é 40.O
parâmetro maxagents
associado também impacta as conexões atuais.
Os requisitos de conexão para um intermediário único são:
Cinco são requeridos por encadeamentos internos do intermediário.
Um é requerido para cada vizinho do Publicação/Assinatura, caso a topologia tenha sido implementada.
Um é requerido para cada encadeamento de fluxo de mensagens que
contenha um nó de Publicação.
Uma é requerida para cada encadeamento de fluxo de mensagens que analise mensagens MRM.
Uma é requerida para cada nó de acesso a banco de dados para separar nomes de origens de
dados ODBC para cada encadeamento de fluxo de mensagens (ou seja, se o mesmo DSN for
utilizado por um nó diferente, a mesma conexão é utilizada).
Se estiver utilizando nós SCADA com WebSphere MQ Everyplace, inclua um número adicional de conexões
dependendo de se o conjunto de encadeamentos está sendo utilizado (verifique a propriedade Utilizar Conjunto de
Encadeamentos do nó SCADAInput):
Se Utilizar Conjunto de Encadeamentos não estiver selecionado (o padrão), inclua o número de clientes
SCADA que se conectarão ao nó SCADAInput.
Se Utilizar Conjunto de Encadeamentos estiver selecionado, inclua o valor na propriedade Encadeamentos Máx.
do nó SCADAInput.
O valor padrão é 500.
As conexões para vizinhos e nós de Publicação são necessárias apenas se você estiver utilizando publicações retidas.
Se desejar utilizar XA com DB2
Cenário: Você deseja utilizar XA comDB2.
Solução: Se você desejar utilizar a coordenação XA com o
DB2V8.1, certifique-se de que o seu gerenciador de filas
esteja configurado para utilizar o ThreadOfControl=THREAD. No Linux ou UNIX é possível configurar esse parâmetro na
sub-rotina XAResourceManager em qm.ini. No Windows é
possível configurar esse parâmetro utilizando o snap-in do WebSphere MQ Explorer
ou do WebSphere MQ Services
dependendo da versão do WebSphere MQ que está
sendo utilizada.
Falha de coordenação XA com o DB2 V8
Fix Pack 2
Cenário: Existe uma falha de coordenação XA com DB2 V8
Fix Pack 2 no AIX, HP-UX, Linux, Solaris
ou Windows.
Explicação: Se um fluxo de mensagens coordenadas não-XA tentar acessar
um banco de dados sendo utilizado anteriormente por um fluxo de mensagens coordenadas XA,
poderá ocorrer uma falha pois DB2 acredita que
o fluxo posterior ainda é coordenado pelo fluxo anterior.
Solução: Isto foi corrigido noDB2 V8 com Fix Pack 3 pelo APAR IY44711.
A Coordenação XA Falhará Se o Banco de Dados Reiniciar ao Executar o Intermediário
Cenário: A coordenação global XA falha e você obterá um erro
semelhante ao do exemplo a seguir, que é de um banco de dados do usuário do DB2:
Erro do banco de dados: Estado SQL '40003'; Código de Erro Nativo '-900'; Texto de Erro '[IBM][CLI Driver] SQL0900N O estado do aplicativo está com erro.
Uma conexão com o banco de dados não existe.SQLSTATE=08003'.
Explicação: Um fluxo de mensagens coordenado globalmente não pode ser automaticamente reconectado a um banco de dados do usuário se o banco de dsdos for reiniciado enquanto o intermediário ainda estiver em execução.
Solução: Pare e reinicie o intermediário se o banco de dados do usuário ficar inativo ou for desativado por causa de uma manutenção planejada.
A Mensagem de Erro BIP2322 é Emitida ao Acessar o DB2 no z/OS
Cenário: Você está utilizando um fluxo de mensagens no qual um
nó de Banco de Dados, um nó Compute ou um nó Filter tenta acessar uma
tabela em um grupo de compartilhamento de dados do DB2
diferente daquele utilizado pelo intermediário. Se o
rastreio de ODBC estiver ativado, uma mensagem de erro será escrita no
no arquivo traceodbc:
SQLError( hEnv=0, hDbc=0, hStmt=1, pszSqlState=&302f8ecc, pfNativeError=&302f8ec8,
pszErrorMsg=&28f6a6d0, cbErrorMsgMax=1024, pcbErrorMsg=&302f8eb4 )
SQLError( pszSqlState="51002", pfNativeError=-805, pszErrorMsg="{DB2 for OS/390}
{ODBC Driver}{DSN06011}
DSNT408I SQLCODE = -805, ERROR: DBRM OR PACKAGE NAME DSN610GH..DSNCLICS.16877-
BE5086005F4 NOT FOUND IN PLAN DSNACLI. REASON 02
DSNT418I SQLSTATE = 51002 SQLSTATE RETURN CODE
DSNT415I SQLERRP = DSNXEPM SQL PROCEDURE DETECTING ERROR
DSNT416I SQLERRD = -350 0 0 -1 0 0 SQL DIAGNOSTIC INFORMATION
DSNT416I SQLERRD = X'FFFFFEA2' X'00000000' X'00000000' X'FFFFFFFF'
X'00000000' X'00000000' SQL DIAGNOSTIC INFORMATION
Esse erro é acompanhado pela seguinte mensagem de erro BIP2322 no syslog:
BIP2322E: DATABASE ERROR: SQL
STATE '51002'; NATIVE ERROR CODE '-805'
Explicação: Isto ocorre quando o plano DSNACLI não foi ligado da maneira correta.
Solução: Assegure-se de que o plano DSNACLI seja ligado corretamente.
No Oracle, uma Operação de Banco de Dados Falha em Retornar
Linhas, Mesmo que as Linhas Existam
Cenário: Você está utilizando os bancos de dados
Oracle nos fluxos de mensagens e o ESQL está ligado em oposição às
colunas, declaradas como tipo de dados CHAR e esses marcadores de
parâmetros são referenciados em uma cláusula WHERE. A operação do banco de dados
falha em retornar linhas, embora as linhas existam.
Explicação: Essas cadeias de caracteres com
comprimento fixo precisam ser preenchidas com caracteres em branco no
Oracle para esse tipo de comparação ser bem-sucedido.
Solução: Defina as colunas CHAR como colunas
VARCHAR2 ou preencha a variável ESQL com caracteres em branco até o
comprimento de coluna requerido, para que a comparação localize as
linhas desejadas na tabela.
Ocorre uma Fuga de Memória na Oracle Client Interface do HP-UX
11
Cenário: Foi observado fuga de memória da OCI
(Oracle Client Interface), ao utilizar o Oracle 9i Release 2
(9.2.0.1) no HP-UX 11.
Solução: Esse problema foi corrigido pelo Oracle e
a correção está disponível através do upgrade para o Oracle 9i
Release 2 Database Server Patch Set 2 para HP9000 Series HP-UX (64 bits).
Esse possui o número de correção do Oracle 2761332. Para instalar a correção do Oracle acima,
você pode precisar primeiro fazer o upgrade do instalador Oracle (OUI) para a
versão 2.2.0.18.0.
O número de correção do Oracle para esse upgrade é 2878462.
Os Tamanhos de Parâmetros de Procedimento Armazenado São Diferentes no Oracle 9i e no Oracle 10g
Cenário: Um procedimento armazenado que contém um char(16) retorna
um tamanho de parâmetro de 2000 em vez de 16.
Explicação: O Oracle 9i e o Oracle 10g retornam tamanhos diferentes para
parâmetros em um procedimento armazenado. Isto ocorre devido a diferenças na forma que
o Oracle 9 e o Oracle 10 funcionam. Uma instrução do Oracle sobre esta alteração de comportamento e um cenário que o ilustra estão disponíveis no Web site do metalink
do Oracle no TAR 4567976.993.
A Mensagem de Erro ORA-12500 do Oracle É Emitida no Solaris 8 com Oracle 9
Cenário: A mensagem de erro ORA-12500 do Oracle é emitida no Solaris
8 com o Oracle 9 quando você executa aplicativos de carga de trabalho que estão executando as operações inserir, atualizar ou excluir banco de dados.
Explicação: Esse erro é emitido quando os valores dos parâmetros de ajuste são muito baixos.
Solução: Aumente os seguintes parâmetros SGA de ajuste do Oracle 9i Release 2 no arquivo initSID.ora:
JAVA_POOL_SIZE
SHARED_POOL_SIZE
SORT_AREA_SIZE
O exemplo a seguir mostra valores maiores possíveis para uma configuração de carga de trabalho com um único intermediário que possui dois grupos de execução, cada um com 92 fluxos de mensagens:
As Mensagens de Erro BIP2731, BIP2321 e
BIP2322 São Emitidas Quando Você Utiliza Publicações Retidas com um Banco de Dados Sybase
Cenário: As mensagens a seguir de erro são emitidas ao utilizar
as publicações retidas e um banco de dados Sybase do intermediário:
BIP2731 Database statement 'INSERT INTO dbo.BRETAINEDPUBS
VALUES(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)' não pôde ser executada.
BIP2321 Erro de banco de dados: Código de retorno ODBC '-1'.
BIP2322 Erro de banco de dados: Estado SQL '40001'; Código de Erro Nativo '1205'.
Text '[SYBASE][ODBC Sybase Driver][SQL Server]Seu comando de servidor
(family id #0, process id #234) encontrou uma situação de conflito.
Execute novamente seu comando.'
Explicação: Esses erros devem ocorrer apenas ao
manter publicações com vários tópicos, com uma carga de trabalho
substancial.
Solução: Aplique bloqueio de nível de linha em uma das tabelas de banco de dados do intermediário:
Em um prompt de comandos do Sybase, digite o comando:
isql -Uusername -Ppassword
Conecte ao banco de dados do intermediário:
use broker DSN
em que broker
DSN é o DSN (Data Source Name) ODBC do banco de dados do intermediário.
Digite o comando:
alter table dbo.BRETAINEDPUBS lock datarows
em que dbo é o nome do esquema.
Digite o comando:
go
A Mensagem de Erro BIP2275 É Emitida quando um Fluxo de Mensagens Grande É Implementado em um Banco de Dados do Intermediário Sybase
Cenário: Você está utilizando o Sybase como o banco de dados do intermediário e as mensagens de erro
BIP2275, BIP5009 e BIP5004 são emitidas durante a inicialização do intermediário.
Explicação: As mensagens de erro BIP2275, BIP5009
e BIP5004 indicam que uma definição XML do fluxo de mensagens recuperada do banco de dados do intermediário na inicialização é XML inválido.
Isso pode ser causado por uma definição de fluxo de mensagens maior do que 1 MB de comprimento ser truncado quando recuperado da tabela BROKERRESOURCES na inicialização do intermediário. A razão para ser truncado é que o comprimento máximo padrão dos dados, para o Sybase, que podem ser recuperados na inicialização do intermediário da coluna RESOURCEDATA (onde as definições de fluxos de mensagens são armazenadas) da tabela BROKERRESOURCES é
1 MB.
Solução:
Pare todos os intermediários que se conectam ao banco de dados afetado.
Inclua DefaultLongDataBuffLen=2048 na definição DSN nos arquivos de configuração ODBC ($ODBCINI ou $ODBCINI64, ou ambos).
Reinicie o intermediário.
A mensagem de erro BIP2322Driver Incapaz é
enviada quando você utiliza um banco de dados Informix
Cenário: Ao tentar acessar um banco de dados Informix a partir de um nó em um
fluxo de mensagens, a seguinte mensagem de erro é enviada:
BIP2322E: Erro do Banco de Dados: Estado SQL 'HYC00'; Código de Erro
Nativo '-11092'; Texto do Erro '[Informix][Informix ODBC Driver]Driver Não Capaz.'.
Explicação: O intermediário utiliza instruções de transação; portanto,
o banco de dados deve ser criado e configurado para ativar a criação de log.
Solução: Consulte seu administrador de banco de dados para
garantir que o log de transações foi ativado no banco de dados Informix que o intermediário de mensagem
está tentando acessar. Por exemplo, crie o banco de dados com um log em buffer:
create database with [buffered] log;
As Atualizações do Banco de Dados Não São Consolidadas
Conforme Esperado
Cenário: Você incluiu um nó de Banco de Dados, um nó Compute ou um nó Filter em um fluxo de mensagens
e configurou a propriedade Transações para Cometer.
O fluxo de mensagens levantou uma exceção e foi revertido, mas as
atualizações do banco de dados não foram consolidadas.
Explicação: Quando você configura Transaction para Commit,
as atualizações de banco de dados realizadas pelo nós serão consolidadas quando o nó for
concluído com êxito. Se uma exceção surgir antes do nó ser concluído e isso causar
a reversão do fluxo de mensagens, a consolidação não é emitida e as
atualizações do banco de dados também são revertidas.
As situações nas quais isso pode ocorrer são:
O nó em si causa o levante de uma exceção. A
consolidação nunca é executada.
O ESQL contém uma instrução PROPAGATE. Essa instrução
não é concluída até todo o processamento ao longo do caminho
utilizado pela mensagem propagada ser concluído e o controle retornar
ao nó.
Somente, então, a consolidação pode ser executada.
Se uma exceção surgir ao longo desse caminho, o controle não é
retornado e as atualizações do banco de dados são revertidas como
parte do fluxo de mensagens.
Solução: Reveja a operação do nó que executa as atualizações de banco de dados. Por exemplo, pode ser possível dividir o trabalho
entre dois nós, com o primeiro atualizando o banco de dados e o
segundo propagando a mensagem de saída.
Considere alterar o código ESQL para processar a mensagem de maneira
diferente.
O Sistema de Rastreio DataDirect Não Pode Abrir o Arquivo de Rastreio ODBC
Cenário: Comandos, como o mqsichangetrace e o mqsicreatebroker, falham e uma mensagem é exibida informando que o arquivo de rastreio ODBC não pode ser aberto.
Explicação: O arquivo DataDirect ODBC está inacessível ou seu
tamanho excedeu 2 GB e o rastreio foi ativado.
Solução: Para solucionar esse problema:
Desative o rastreio no arquivo para o qual a
variável de ambiente ODBCINI aponta.
Localize o arquivo de rastreio ODBC para o qual
'TraceFile' na sub-rotina ODBC aponta. Se você precisa manter o
rastreio, mova o arquivo de rastreio ODBC para outro local.
Se você não deseja manter o rastreio, exclua o
arquivo de rastreio ODBC.
Se ainda precisar reunir o rastreio ODBC, reconfigure TRACE=1 no
arquivo odbc.ini.
Encerramento de Forma Anormal ao Implementar um Fluxo de Mensagens
Cenário: Você está executando o DB2 versão 9 no HP-UX em PA-RISC. Você tenta implementar um fluxo de mensagens, mas a implementação falha.
Solução: Exporte a variável de ambiente MQSI_SIGNAL_EXCLUSIONS
no ambiente do intermediário:
export MQSI_SIGNAL_EXCLUSIONS=10
Você Deseja Listar as Conexões com o Banco de Dados Contidas no Intermediário
Cenário: Você deseja listar as conexões com o banco de dados contidas
no intermediário.
Solução: O intermediário não possui nenhuma funcionalidade para listar
as conexões que ele possui com um banco de dados. Utilize os recursos fornecidos por
seu banco de dados para listar conexões. Consulte a documentação de seu banco de dados
para obter informações sobre elas.