Estou migrando vários scripts perl CGI de uma instalação RHEL5 mais antiga para um servidor RHEL6. No servidor antigo, o DB2 V9.7 foi instalado, o novo servidor tem o V10.5. Nenhum banco de dados nos próprios servidores, apenas várias conexões com bancos de dados remotos.
Posso acessar um desses bancos de dados remotos, que está rodando no AIX, sem problemas, então a instalação em si deve estar ok.
Posso me conectar a outro dos bancos de dados remotos, sem problemas no antigo servidor RHEL5. No novo servidor, consigo conectar ok, mas assim que tento selecionar algo, a conexão é interrompida com o seguinte erro:
[IBM][CLI Driver] SQL30081N A communication error has been detected.
Communication protocol being used: "TCP/IP".
Communication API being used: "SOCKETS".
Location where the error was detected: "10.199.252.155".
Communication function detecting the error: "recv".
Protocol specific error code(s): "*", "*", "0". SQLSTATE=08001
Observe que o endereço IP, 10.199.252.155, é o IP do servidor de banco de dados, não meu, então parece que o servidor DB2 detecta algum erro e relata isso para mim, em vez do próprio cliente detectar o erro.
Em ambos os meus servidores, os comandos para catalogar o banco de dados remoto (emitido há 2 anos no servidor RHEL5, emitido há alguns dias no RHEL6) foram
CATALOG TCPIP NODE TCP0000 REMOTE iaixdb2i SERVER 3910 REMOTE_INSTANCE tdbi30 SYSTEM IAIXDB2I OSTYPE AIX;
CATALOG DATABASE DB2I21 AS DB2I21 AT NODE TCP0000;
A saída de LIST NODE DIRECTORY, em ambos os servidores, mostra a mesma entrada:
Node name = TCP0000
Comment =
Directory entry type = LOCAL
Protocol = TCPIP
Hostname = iaixdb2i
Service name = 3910
e LIST DATABASE DIRECTORY é quase o mesmo - o servidor antigo tem:
Database alias = DB2I21
Database name = DB2I21
Node name = TCP0000
Database release level = d.00
Comment =
Directory entry type = Remote
Catalog database partition number = -1
Alternate server hostname =
Alternate server port number =
enquanto o novo servidor tem
Database release level = 10.00
(o resto é idêntico).
Ao pesquisar meus códigos de erro no Google, encontrei muitos sites em que a) a conexão não foi bem-sucedida ou b) a conexão foi interrompida por motivos de tempo limite. Ambos os erros não parecem se aplicar a mim. Além disso, essas entradas tinham alguns códigos de erro relevantes na seção específica do protocolo, não apenas " ", " ", "0" como eu tenho.
Portanto, a única diferença que vejo agora são os diferentes níveis de lançamento do banco de dados. O que significa que o único problema em que consigo pensar é que o banco de dados ainda está sendo executado em algo mais antigo e tem problemas com o protocolo V10.5. Isso significa que devo fazer o downgrade do meu cliente para 9.7 ou existe uma maneira de dizer ao cliente mais novo para usar um nível de protocolo mais antigo, alterando o nível de lançamento do banco de dados no catálogo? Se sim, quais seriam os comandos para fazer isso? Ou há mais alguma coisa que eu deveria tentar?
Editar: informações adicionadas conforme solicitado por mustaccio.
Não fui avisado quando não passei o usuário e a senha na linha de comando, então tive que modificar o comando connect para incluí-los. Além disso, mudei o nome de usuário e a senha neste post - o nome de usuário real #também começa com um.
Máquina antiga:
$ db2 connect to DB2I21 user '#ABCDEF' using XXXXXXX
Database Connection Information
Database server = DB2 z/OS 10.1.5
SQL authorization ID = #ABCDEF
Local database alias = DB2I21
$ db2 "select * from sysibm.sysdummy1"
IBMREQD
-------
Y
1 record(s) selected.
$
Nova máquina:
$ db2 connect to DB2I21 user '#ABCDEF' using XXXXXXXX
Database Connection Information
Database server = DB2 z/OS 10.1.5
SQL authorization ID = #ABCDEF
Local database alias = DB2I21
$ db2 "select * from sysibm.sysdummy1"
SQL0805N Package "DB2I21.NULLID.SQLC2K26.4141414141664164" was not found.
SQLSTATE=51002
$
Editar 2: ainda mais informações
A vinculação db2clipk.bndfunciona, mas não altera a mensagem de erro quando seleciono sysibm.sysdummy1.
Binding db2clpcs.bnd, conforme sugerido pela IBM para SQLC2K26 resulta em direitos de acesso ausentes; como este é um banco de dados de produção, não consigo fazer com que os DBAs mudem nada.
Ok, tentei o banco de dados de teste, que tem uma configuração idêntica, exceto que o I foi alterado para J:
Node name = TCP0001
Comment =
Directory entry type = LOCAL
Protocol = TCPIP
Hostname = iaixdb2j
Service name = 3910
Database alias = DB2J21
Database name = DB2J21
Node name = TCP0001
Database release level = 10.00
Comment =
Directory entry type = Remote
Catalog database partition number = -1
Alternate server hostname =
Alternate server port number =
tem a mesma mensagem de conexão
$ db2 connect to DB2J21 user '#ABCDEF' using XXXXXXXX
Database Connection Information
Database server = DB2 z/OS 10.1.5
SQL authorization ID = #ABCDEF
Local database alias = DB2J21
e, o que realmente me impressiona, não dá nenhum erro quando seleciono, da nova máquina!
$ db2 "select * from sysibm.sysdummy1"
IBMREQD
-------
Y
1 record(s) selected.
Isso poderia ser uma restrição no meu endereço IP? Em caso afirmativo, por que me permite vincular? Ou existe uma maneira de descobrir os níveis de patch de ambos os bancos de dados? (Será muito mais fácil para mim fazer com que os DBAs instalem um patch se eu tiver um número de patch e uma descrição que indique claramente que é isso que me impede de selecionar).
Edit 3: Como terminou
Apenas no caso de alguém estar interessado ou ter um problema semelhante:
Consegui que os DBAs ligassem os pacotes do cliente V10.5. Depois disso,
$ db2 "select * from sysibm.sysdummy1"
funcionou bem contra o banco de dados produtivo (DB2I21). Meu programa perl ainda travou.
DB2 Express C 10.5 desinstalado, instalado o driver 10.5FP3 DS. Ainda o mesmo problema, ambos os bancos de dados funcionam na linha de comando, o banco de dados de teste funciona com perl, o banco de dados prod não.
Eu fiz um rastreamento wireshark no programa perl contra bancos de dados test e prod - até certo ponto, eles parecem ser exatamente idênticos, exceto a troca de senha. Depois que o cliente executa a consulta e começa a recuperar os valores do resultado, o servidor apenas fecha a conexão TCP, sem retornar nada, nem mesmo um pacote TCP vazio ou com erro.
Desisti naquele ponto e instalei o driver 10.1FP3 DS. Tudo parece funcionar bem com aquele.