TNS-12535: TNS: operação esgotada - Oracle DB

Question

Estou vendo muitas consultas de um servidor de acesso a dados .Net. Mantenho o tempo limite. Parece ser totalmente aleatório, sem relação com dados ou bloqueios de dados. Por exemplo, a consulta a seguir atingiu o tempo limite!

 SELECT NULL FROM DUAL 

Os registros do sistema mostram que, quando aconteceu, a CPU estava em 20%, a memória em 42% e o disco em 3%. O que está acontecendo?

O DB é a versão 10.2.0.3.0 no HPUX. O driver ODP é 2.111.6.20 (driver 11g)

Eu verifiquei o sqlnet.log e encontrei um grande número dessas mensagens de erro:

***********************************************************************
Fatal NI connect error 12170.

  VERSION INFORMATION:
        TNS for HPUX: Version 10.2.0.3.0 - Production
        Oracle Bequeath NT Protocol Adapter for HPUX: Version 10.2.0.3.0 - Production
        TCP/IP NT Protocol Adapter for HPUX: Version 10.2.0.3.0 - Production
  Time: 29-JUN-2009 06:42:04
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12535
    TNS-12535: TNS:operation timed out
    ns secondary err code: 12606
    nt main err code: 0
    nt secondary err code: 0

    

Answer 1

O erro específico e o fato de que isso acontece com todos os aplicativos em execução no banco de dados apontariam strongmente para um problema de rede como a origem do problema.

• Como os aliases do TNS são resolvidos? Está você está usando um arquivo tnsnames.ora local?

• Supondo que você esteja usando um local O arquivo tnsnames.ora é o alias do TNS para o banco de dados usando um endereço IP ou um nome de host? Usando um endereço IP elimina a necessidade de acertar o DNS, por isso pode valer a pena tentar isso no caso o problema é que o seu servidor DNS está ficando louca brevemente.

• Você também pode tentar configurar um ouvinte de backup e adicionar uma opção de failover ao alias do TNS. Se o problema é que a rede soluça e perde os pacotes do cliente para a comunicação do ouvinte aleatoriamente, ter uma opção de failover que pode ser tentada pode resolver a grande maioria dos problemas sem precisar descobrir qual parte da rede está ficando escamosa. Naturalmente, isso pressupõe que o problema se corrija com rapidez suficiente para que a próxima tentativa de conexão seja bem-sucedida, mas isso pode ser uma suposição razoável. Se adicionar um ouvinte de backup resolve o problema, você pode ter certeza de que se trata de um problema de rede.

Answer 2

Descobri que desativar o pool de conexões é mais confiável. Eu encontrei várias situações como você descreveu.

Descobrimos que as conexões são testadas ANTES de serem colocadas de volta na piscina, em vez de serem puxadas para uso posterior.

Em um bom dia, você receberá algum tipo de erro. Em um dia ruim, você só vai esperar para usar uma conexão que está completamente confusa e nunca funcionará.

Se você for usar o pool, eu leio recomendações de que você execute um comando alter contra a sessão. (Não, eu não sei de uma boa. A Oracle não esclareceu nada no manual)

Brad

    

Answer 3

Eu tive esse problema quando as seguintes condições eram verdadeiras: - Cliente JDBC estava sendo executado em uma máquina com IP ZZ.ZZ.ZZ.ZZ - O Database Server tinha duas placas de rede - uma com IP XX.XX.XX.XX e outra com YY.YY.YY.YY - A URL do cliente JDBC estava apontando para IP XX.XX.XX.XX, porta 1521 - Usando a tabela de roteamento, o cliente ZZ.ZZ.ZZ.ZZ conseguiu alcançar XX.XX.XX.XX - O padrão "LISTENER" estava escutando na porta YY.YY.YY.YY 1521, (hostname resolve este IP) - O parametyer LOCAL_LISTENER no SPFILE era NULL - ou seja, nunca foi definido

Eu resolvi isso fazendo o seguinte: - Parou o ouvinte (lsnrctl stop) - LISTENER.ORA alterado para escutar em XX.XX.XX.XX (em vez do padrão hostname de YY.YY.YY.YY) - Adicionada uma entrada em TNSNAMES.ORA para definir o listener local (LISTENER = (...)), essencialmente uma cópia da entrada usada em LISTENER.ORA) - Adicionado um parâmetro LOCAL_LISTENER = LISTENER no spfile (ALTER SYSTEM SET ... SCOPE = SPFILE) - Reiniciei o LISTENER (lsnrctl start) - Reiniciei o banco de dados

    

Answer 4

Não há informações suficientes para encontrar uma solução, mas aqui estão algumas coisas para tentar.

Você consegue reproduzir isso fora do aplicativo? Você já viu falhas com tnsping? Você pode pingar o servidor de forma confiável?

O aplicativo está executando várias conexões em paralelo? Existem limites para o número de conexões?

E a rede - existe um firewall entre o aplicativo e o banco de dados?

    

Answer 5

Embora isso seja tratar o sintoma em vez de qualquer doença de pilha de rede que você tenha, você pode tentar aumentar o inbound_connect_timeout para ver se o problema desaparece.

Para verificar o que você está executando agora, invoque o LSNRCTL no host do banco de dados e emita o comando:

show inbound_connect_timeout

Você precisa alterar isso nos arquivos sqlnet.ora e listener.ora do seu host db:

sqlnet.ora: SQLNET.INBOUND_CONNECT_TIMEOUT = 100 (supondo que 100 é maior que seu tempo limite atual)

listener.ora: INBOUND_CONNECT_TIMEOUT_yourLIstenerNameGoesHere = 100

    

Answer 6

Verifique também o seu firewall. A porta de entrada 1521 no servidor de banco de dados deve estar aberta (se você estiver se conectando ao servidor de banco de dados de outro servidor).

    

Answer 7

Acabei de resolver esse problema, descobri que, se você estiver executando no servidor DHCP, verifique se o arquivo host possui o endereço IP correto atual, C:\windows\system32\drivers\etc\host (abra-o usando o bloco de notas) & isso consertará seu problema.

    

Answer 8

Dicas adicionais: Verifique as configurações do seu firewall do servidor / PC. Em algumas janelas do sistema operacional, como o Vista / Win7 / Win Server; O firewall é habilitado para computadores em rede SOHO. Certifique-se de testar todos os grupos de rede privados / de escritório / públicos. Em seguida, pare o serviço de firewall e teste a conexão.