Ja vi uma situacao parecida, onde o culpado era um *switch* da rede que
pipocava de tempos em tempos... não tinha nada ver com nada do que pensava
ser. até que o dito cujo foi trocado.
Nao parava só banco de dados, mas as vezes a empresa inteira, rolando
timeout pra todo lado.

Claro, vc nao cuida da infra, fez o que podia e escalou o problema para
redes e depende do feedback do responsavel mas, desde abril problema
rolando, ta na hora deles começar a desconfiar de coisas que nao pareçam
ter a ver tb...da uma sugestão pros caras..

Se fosse alguma coisa no servidor, vc mesmo provavelmente ja teria notado,
pelos logs que ele gera, ou pelos erros que o Oracle daria

[]s



2015-07-02 17:12 GMT-03:00 Rafael Mendonca raffaell.t...@yahoo.com
[oracle_br] <oracle_br@yahoogrupos.com.br>:

>
>
> Amigos DBA's, estou com um problema na minha infra aonde todos os
> servidores estão enfrentando problemas de TIMEOUT. Ambientes de
> desenvolvimento, homologação e produção.
>
> Mensagens do tipo no alert.log são encontradas todas as vezes com uma
> frequência muito alta:
>
> *Fatal NI connect error 12170.*
>
>
>
>
>
>
>
> *  VERSION INFORMATION:        TNS for IBM/AIX RISC System/6000: Version
> 11.2.0.3.0 - Production        TCP/IP NT Protocol Adapter for IBM/AIX RISC
> System/6000: Version 11.2.0.3.0 - Production        Oracle Bequeath NT
> Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.3.0 -
> Production  Time: 02-JUL-2015 15:01:27  Tracing not turned on.  Tns error
> struct:    ns main err code: 12535*
>
>
> *TNS-12535: TNS:operation timed out    ns secondary err code: 12560    nt
> main err code: 505*
>
>
>
> *TNS-00505: Operation timed out    nt secondary err code: 78    nt OS err
> code: 0  Client address:
> (ADDRESS=(PROTOCOL=tcp)(HOST=xxx.xxx.xx.x)(PORT=xxx))*
>
>
>
> Meus TOP EVENTS estão sempre:
>
>
> *SQL*Net break/reset to clientSQL*Net more data from cliente*
>
>
>
> Recentemente um usuário veio até a mim reclamar que não estava conseguindo
> executar uma determinada função porque sofria problemas de TIMEOUT,
> executei um trace level 12 em sua sessão e encontrei os seguintes dados:
>
>
>
> call     count       cpu    elapsed       disk      query
> current        rows
> ------- ------  -------- ---------- ---------- ---------- ----------
> ----------
> Parse        1      1.23       1.34          0          0
> 0           0
> Execute      1      0.00       0.00          0          0
> 0           0
> Fetch        1      1.35       1.56         29       2199
> 0          12
> ------- ------  -------- ---------- ---------- ---------- ----------
> ----------
> total        3      2.59       2.91         29       2199
> 0          12
>
>
> Elapsed times include waiting on following events:
>   Event waited on                             Times   Max. Wait  Total
> Waited
>   ----------------------------------------   Waited  ----------
> ------------
>   SQL*Net message from client                     2     2176.60
> 2190.36
>   SQL*Net message to client                       1        0.00
> 0.00
>   db file sequential read                        25        0.00
> 0.00
>   db file scattered read                          1        0.00
> 0.00
>
>
>
>
> Recentemente um outro DBA aqui do grupo estava enfrentando o mesmo
> problema e guardei algumas informações preciosas do CHiappa:
>
> " Nesse caso, as mensagens indicam que nós tivemos um TIMEOUT de rede,
> isto é: Ou o RDBMS Oracle estava tentando se comunicar com alguém via rede
> OU alguém estava tentando se comunicar com o RDBMS via rede (provavelmente
> o último caso por causa da mensagem " Client address:
> (ADDRESS=(PROTOCOL=tcp)(HOST=  <NUMERO IP> )  (PORT=54218))" e a conexão
> foi cortada ou ficou esperando tempo demais por uma resposta. Isso pode
> acontecer devido a algum software de segurança (firewall, por exemplo) que
> interrompe conexões abertas há muito tempo, ou por recurso de rede ausente
> (gargalo de rede) ou pau de rede, mesmo....
>  Consultar detalhadamente os logs de rede (ie, logs dos servidores
> envolvidos, do DNS server, do roteador, do firewall, dos softwares de
> quality of service) procurando por anomalias de rede no período em questão.
>     Se for recomendado pelo pessoal de rede, considerar aumentar o
> timeout (ie, o intervalo máximo que uma conexão espera pela resposta).
> "
>
> Bom, passei essas informações para o restante das equipes de INFRA e até
> agora nada foi encontrado, nada foi resolvido, isso já está ocorrendo desde
> o dia 04 de abril. Chiappa e amigos daqui do grupo, alguém teria mais
> alguma coisa ou sugestão a dar?
>
>
>
>
>
>  
>

Responder a