Re: [oracle_br] TIMEOUT

[angelo angelolis...@gmail.com [oracle_br]]

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] :

>
>
> 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 - ProductionTCP/IP NT Protocol Adapter for IBM/AIX RISC
> System/6000: Version 11.2.0.3.0 - ProductionOracle 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 outns secondary err code: 12560nt
> main err code: 505*
>
>
>
> *TNS-00505: Operation timed outnt secondary err code: 78nt 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   cpuelapsed   disk  query
> currentrows
> --- --   -- -- -- --
> --
> Parse1  1.23   1.34  0  0
> 0   0
> Execute  1  0.00   0.00  0  0
> 0   0
> Fetch1  1.35   1.56 29   2199
> 0  12
> --- --   -- -- -- --
> --
> total3  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   10.00
> 0.00
>   db file sequential read250.00
> 0.00
>   db file scattered read  10.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=   )  (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?
>
>
>
>
>
>  
>

Re: [oracle_br] TIMEOUT

[Marcelo Santino e...@marcelosantino.com.br [oracle_br]]

Rafael, tudo certo?

Dá uma olhada no parâmetro SQLNET.EXPIRE_TIME no SQLNET. Tive um problema
desses há um tempo e a princípio resolveu muito bem pra mim. Pois tinha um
firewall no meio do caminho que eu não consegui evidenciar ser o
impactante, logo a equipe de Infra não se movimentou pra resolver no lado
deles e depois dessa alteração parei de ter o problema. No meu caso,
coloquei um valor bem baixo (=1) pra não ter erro, mas tenha em mente que
isso irá gerar mais tráfego na rede.

Segundo a documentação (
http://docs.oracle.com/cd/B19306_01/network.102/b14213/sqlnet.htm):



*PurposeUse parameter SQLNET.EXPIRE_TIME to specify a the time interval, in
minutes, to send a probe to verify that client/server connections are
active. Setting a value greater than 0 ensures that connections are not
left open indefinitely, due to an abnormal client termination. If the probe
finds a terminated connection, or a connection that is no longer in use, it
returns an error, causing the server process to exit. This parameter is
primarily intended for the database server, which typically handles
multiple connections at any one time.*



* - - - Limitations on using this terminated connection detection feature
are:*



* - It is not allowed on bequeathed connections.- Though very small, a
probe packet generates additional traffic that may downgrade network
performance. Depending on which operating system is in use, the server may
need to perform additional processing to distinguish the connection probing
event from other events that occur. This can also result in degraded
network performance.*

Abs,

  [image: photo]
*Marcelo Santino*
Administrador de Banco de Dados
 (21) 98206-9930 | e...@marcelosantino.com.br | http://www.bau-de-dev.com
   


2015-07-02 17:12 GMT-03:00 Rafael Mendonca raffaell.t...@yahoo.com
[oracle_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 - ProductionTCP/IP NT Protocol Adapter for IBM/AIX RISC
> System/6000: Version 11.2.0.3.0 - ProductionOracle 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 outns secondary err code: 12560nt
> main err code: 505*
>
>
>
> *TNS-00505: Operation timed outnt secondary err code: 78nt 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   cpuelapsed   disk  query
> currentrows
> --- --   -- -- -- --
> --
> Parse1  1.23   1.34  0  0
> 0   0
> Execute  1  0.00   0.00  0  0
> 0   0
> Fetch1  1.35   1.56 29   2199
> 0  12
> --- --   -- -- -- --
> --
> total3  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   10.00
> 0.00
>   db file sequential read250.00
> 0.00
>   db file scattered read  10.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=   )  (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
> inte