Menu de navegação

[airoospParticipant]

Boa tarde,

Alguém sabe como fazer para que na consulta abaixo, a mesma seja encerrada caso não tenha resposta?

select nota from notas@compras;

No exemplo acima ela esta em execução a várias horas mas não termina e também na ocorre timeout.

Ao executar c:TNSPING compras também inicia mas não termina.

Se alguém tiver alguma dica, agradeço.

Obrigado.

Airton

[José Laurindo ChiappaModerator]

Antes de responder, OBSERVO que necessariamente o cenário que vc descreve parece Muitíssimo Mais ser uma issue de rede – INCLUSIVE, esse fato do TNSPING não responder é SIGNIFICATIVO : esse programinha TNSPING ** Nem Sequer ** abre uma conexão dentro do banco-destino , ele só envia um pacote de rede até o listener do destino, então se mesmo não chegando até o banco destino a tentativa de envio de pacote de rede congela, imho tá MAIS QUE CLARO que vc tem uma questõa Séria de Rede a tratar, e essa questão está FORA DO DATABASE, sim sim ??? Pode ser o servidor de DNS, pode ser firewall, pode ser roteador, pode ser conflito de IP, muitas Possibilidades e todas ela FORA DO BANCO, insisto….Assim sendo, vou te dar o que vc quer (ie, parâmetros e métodos de config de timeout de rede) mas eu Não Asseguro que eles vão ser Efetivos no cenário que vc descreve, onde realmente é alguma coisa FORA DO BANCO que parece estar ‘pegando’… E NEM PRECISO DIZER que vc deveria é achar o PROBLEMA da sua rede, não tentar workarounds…

Respondendo : sete no arquivo SQLNET.ORA da máquina em questão de onde a tentativa de conexão via dblink tá saindo os parâmetros abaixo – consulte na Documentação da sua versão exata a sintaxe e os valores possíveis de cada um deles… Note também que como vc não diz se o dblink está sendo aberto pela primeira vez ou não, indico vc testar tanto os params que estabelecem tempo máximo pra abrir a conexão de rede quanto os params que especificam o tempo máximo que o Oracle espera para a rede enviar um pacote que ele pediu ou para que ele receba um pacote da rede, E também indico setar o parâmetro que não deixa uma sessão ficar inativa (mandando um pacotezinho mínimo de rede a cada poucos minutos)…
Opciuonalmente (mas Recomendado) se possível/viável indico que vc sete no PROFILE do usuário sendo usado para receber a conexão do dblink setar o parâmetro IDLE_TIME (que controla o máximo de tempo que uma sessão pode ficar aberta) de modo a que casos como esse de uma sessão ficar aberta esperando por um recurso externo qualquer (rede no caso mas seja qual for) não ocorram mais…

São eles :

SQLNET.INBOUND_CONNECT_TIMEOUT
SQLNET.SEND_TIMEOUT
SQLNET.RECV_TIMEOUT
SQLNET.EXPIRE_TIME

Isso é o que vc perguntou, e está Respondido…. REFORÇO porém que vc, junto com teu admin de rede, VAI TER QUE fazer uns debugs aí… Entre outras coisas vc vai :

a. testar conexão pelo dblink (E também uma conexão pelo sqlplus com os mesmos dados do dblin) a partir de OUTRA máquina. Vc pode repetir este E os testes abaixo também, a partir de OUTRA máquina e a partir dessa mesma máquina problemática

b. tentar usar o IP (ou o nome do host, se hoje usa IP) no TNSNAMES.ORA

c. testar o reconhecimento da rota até a máquina-destino do dblink com traceroute (tracert no Windows)

d. testar envio de probe até a máquina-destino com PING e com TNSPING

e. testar o envio de um pacote de rede até a porta do listener : uma das maneiras de se fazer isso no WIndows é instalar um client de TELNET e pedir telnet destino numerodaporta

f. confirmar que na máquina-destino o LISTENER está ativo, verificando que não alcançou limites do sistema operacional (digamos, em tamanho dos arquivos de log dele, em número de conexões abertas pela rede, nada assim)

E o último passo : se nada mais te dar nenhuma pista, aí vc Ativa o TRACE DE REDE : pro banco 10gR2 http://docs.oracle.com/cd/B19306_01/network.102/b14212/troublestng.htm é a Documentação envolvida…. EU chamei esse de último recurso porque Realmente ele não é simples de usar E traz uma montanha de informações que para o DBA não querem dizer muito, que pode talvez extrair dados dessa montanha é um especialista em Redes…

[]s

Chiappa

[airoospParticipant]

Chiappa,

Vi as suas explicações, fiz um teste com o parâmetro SQLNET.RECV_TIMEOUT=10 e funcionou.

Com esse parâmetro consegui fazer o teste do TNSPING maquina1 e depois de um tempo no caso 10 segundos sem resposta, o comando TNSPING foi encerrado.

Era isso que eu queria fazer, assim o TNSPING não ficou infinito.

Só que ao acessar o banco homologação para fazer outra atividade, a conexão caiu depois de um tempo.

Estou testando em ambiente de homologação.

Obrigado.

Airton

[José Laurindo ChiappaModerator]

São coisas completamente diferentes : pelo que vc diz, entendo que o cenário anterior era de conexão não sendo aberta, aí setando um tempo máximo de resposta vc contornou , certo ?
Ao que entendo o que vc tem agora é Totalmente outra coisa : a conexão está sendo feita mas está CAINDO depois de x minutos, certo ? A recomendação número 1 pra isso é vc checar, JUNTO COM TEU ADMIN DE REDE e com o ADMIN dessa máquina, se tem alguém (roteador, firewall, servidor de DNS, software de controle de rede, whatever) MATANDO a conexão depois de x minutos OU se ela tá morrendo sozinha/se auto-desconectando….CASO se comprove que a conexão está sendo matada, ela estava INATIVA nesses x minutos, tipo : vc conectou, fez um SELECT e está esperando receber os orimeiros resultados, ou estava com um UPDATE/INSERT/DELETE rodando no banco durante esses x minutos ?? SE sim, vc tem que descobrir QUEM está matando a sessão após x minutos de inatividade e OU ajustar o forewall/roteador/software de QOS para não matar sessões inativas OU aumentar bem o tempo de inatividade OU ajustar no SQLNET.ORA o parâmetro SQLNET.EXPIRE_TIME para o banco mandar um ping de rede a intervalos…

[]s

Chiappa

==> IMPORTANTE : como eu tinha dito, se vc NÃO observa o mesmo comportamento acessando outro banco (ou acessando o mesmo banco novo a partir de outra máquina) fica PROVADO que em princípio não é algo geral a nível de rede (tipo firewall, roteador, QOS, etc) mas sim um problema localizado na máquina problemática , tipo conflito de IP, ponto de rede mal-configurado, etc…

[Author]

Posts