Chiappa, Obrigado pelas dicas, já estamos analisando ponto a ponto.
Mas tudo indica ser algo relacionado a rede/firewall, e não banco mesmo. Grato, Ednilson De: sentto-1682896-122077-1506699714-ednilson.silva=jbs.com...@returns.groups.yahoo.com [mailto:sentto-1682896-122077-1506699714-ednilson.silva=jbs.com...@returns.groups.yahoo.com] Em nome de jlchia...@yahoo.com.br [oracle_br] Enviada em: sexta-feira, 29 de setembro de 2017 12:42 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: Fatal NI connect error 12170. Blz ? Então : a msg "Fatal NI connect error 12170" simplesmente é um Anúncio de que ocorreu um erro de Rede, e o erro mais tarde indicado foi "TNS-12535: TNS:operation timed out", ou seja : CLARAMENTE a conexão de rede deixa de responder, seja porque foi ELIMINADA, seja porque a rede está sobrecarregada e não consegue atender a demanda a tempo... Isso tá Claro até aqui, né ? O outro ponto é que, ** AO CONTRÁRIO ** do que muita gente pode pensar, o RDBMS Oracle ABSOLUTA e COMPLETAMENTE NÃO CONTROLA A REDE, ok ?? Ele e apenas e tão somente um CONSUMIDOR dos serviços de Rede providenciados pelo Sistema Operacional e pelo software+hardware de rede , okdoc ?? Isso leva á necessidade de que vc, como DBA, necessariamente ENVOLVA O ADMINISTRADOR DE REDE e o ADMINISTRADOR DO SO, sim sim ?? Sem isso, vc Não Vai Conseguir fazer muito, como DBA, atuando sozinho... Tá legal ?? INCLUSIVE : uma pista Inestimável que vc, como DBA, pode (e DEVE!!) fornecer pro sysadmin e pro admin de rede é um TRACE DE REDE : isso pode ser feito tanto no servidor Oracle quanto nas máquinas clientes que conectam no database, além da Documentação uma ref pode ser http://www.juliandyke.com/Diagnostics/Trace/NetTrace.php , Não Esquecendo que no 11gR2 pra isso funcionar normalmente vc tem que desativar o ADG, veja https://www.pythian.com/blog/oracle-net-trace-in-11g-or-build-in-itil/ ... Muito bem, agora vem a sua resposta : realmente, enquanto DBA tua primeira Atuação é tentar se assegurar que não é o Banco que está matando as conexões : para isso, não basta só dizer que o profile DEFAULT é o que está em uso, vc TEM que confirmar que o profile em si não foi alterado, fazendo uma consulta select * from dba_profiles; e CONFIRMANDO que NENHUM resource que tenha a ver com tempo de conexão foi alterado/limitado artificialmente (ie, nem SESSIONS_PER_USER nem IDLE_TIME nem CONNECT_TIME nem nada)... Outra coisa é se ASSEGURAR que não há JOBs de banco ou coisa assim que dispare e regularmente saia matando conexões... Uma vez Confirmado que o BANCO em si não está matando conexões, aí vc vai ter que (** junto ** com o admin de rede, o sysadmin E o analista-chefe da Aplicação!!) olhar para FORA do database.... Por exemplo, há um POOL DE CONEXÕES nessa tal aplicação ? Se sim, o controle de quando uma conexão de rede é feita para atender a uma sessão basicamente reside nesse software de connection pooling, é LÁ que vc vai eventualmente setar timeouts e controles, o banco Oracle não apita NADA VEZES NADA nesse cenário.... Um teste EXCELENTE pra vc debugar issues de pool de conexão é estabelecer (da mesma máquina onde roda a aplicação E onde está o client Oracle) uma sessão DEDICADA via sqlplus e ver se ela também sofre algum tipo de timeout... INCLUSIVE, um teste que vc pode facilmente fazer para checar se é TIMEOUT o problema é ativar o DCD (Dead Connection Detection), que é uma feature do Oracle que faz o sql*net enviar a cada x segundos (vc configura) um pacotinho de dados pela rede, de forma a que o firewall, o pool de conexão ou seja quem for não "pense" que a conexão está inativa : veja a nota metalink número 151972.1 "Dead Connection Detection (DCD) Explained" e os links dela... Outra situação EXTERNA ao database mas comum por demais é um FIREWALL, seja no servidor Oracle, seja no servidor da aplicação, seja na máquina-cliente.... Isso é tão comum que uma das notas metalink/my oracle support dedicadas à troubleshoot da situação, que é a nota "Alert Log Errors: 12170 TNS-12535/TNS-00505: Operation Timed Out" (Doc ID 1628949.1) indica de cara isso como uma possibilidade.... Inclusive, vc tem que entender que em ambiente Windows a conexão inicial se estabelece na porta mesmo do Listener (a porta 1521, normalmente) mas Depois 'migra' para uma porta aleatória, então essa linha : Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.242.120.61)(PORT=57282)) pode muito bem estar indicando justamente isso, ie, algum tipo de firewall/antivírus/controlador de rede fechando essa porta de rede, que pelo número alto e bem diferente do range de portas comuns no listener imho é Sim uma das portas 'aleatórias' do lado do cliente... Veja a possibilidade de liberação de ranges no firewall MAS atente ao detalhe que, como vc diz que a conexão inicialmente se estabelece *** MAS ** algum tempo depois é que dá o 'erro', parece ser não um caso de porta de rede proibida/permanentemente fechada mas sim de keepalive, ie, portas que não respondem/não ficam ativas num intervalo X aí sim tem suas conexões fechadas/encerradas/matadas... Dá um look nas notas metalink "Resolving Problems with Connection Idle Timeout With Firewall" (Doc ID 257650.1) e a "Resolving Problems with Connection Idle Timeout With Firewall" (Doc ID 257650.1) para refs sobre keepalive no firewall E na "Solving Firewall Problems on Windows" (Doc ID 68652.1) para algumas idéias sobre port sharing em firewalls... ===>>> REPITO, porém : tudo isso vc vai fazer EM CONJUNTO COM O ADMIN DE REDE, sim sim sim ??? É ELE que pode te dizer QUAIS firewalls estão em ação (de repente vc pode ter firewall TANTO no servidor Oracle QUANTO nas máquinas-clientes, no servidor da aplicação e/ou no próprio hardware de rede), é ELE que pode consultar NOS FIREWALLS como estão setados keepalives e exclusão de portas..... É EXTERNO AO DATABASE, yes ?? A outra parte da minha resposta é : antes de vc sair setando parâmetros de tempo de resposta de rede (seja no listener como vc disse, seja no sql*net), vc Deveria fazer isso apenas uma vez que vc tenha PROVADO e COMPROVADO que não é caso da rede sobrecarregada estar demorando demais a responder, sim sim ?? Refs pra isso são (além da Documentação!!) as notas "Oracle Net SQLNET.SEND_TIMEOUT and SQLNET.RECV_TIMEOUT Parameters and errors ORA-12170 TNS-12535 ORA-12609 ORA-12608" (Doc ID 1335630.1) e os links da própria nota master sobre a issue, a "OERR: ORA-12170 / TNS-12170 'TNS:Connect timeout occurred' Reference Note" (Doc ID 194295.1) ... []s Chiappa OBS : 1. obviamente, prestar atenção TOTAL à Edição dos arqs de parâmetros/sqlnet.ora, pois um eventual caracter de controle inválido ou um erro de sintaxe pode levar à erros tal como mostrado na nota "SQLNET.ORA File Improperly Formatted Cause an ORA-12699 Error" (Doc ID 2288262.1) ... 2. friso NOVAMENTE que a maneira PROFISSIONAL de resolver issues do tipo é ** Analisar ** antes de sair "atirando pra todo lado", mexendo params a torto e a direito : vc até pode acertar o alvo mas é mais comum que vc acerte o olho de alguém.... 3. dependendo do caso vc pode necessitar restatar o listener ou até (num caso extremos) o banco também, vide nota metalink "When do SQLNET.ORA changes take effect ?" (Doc ID 562589.1) ...
