Menu de navegação

[armandovelosoParticipante]

Olá todos!

Tenho visto no meu arquivo de alerta do oracle (10g r2), que todos os dias há essa advertencia:

WARNING: inbound connection timed out (ORA-3136)

Li algumas coisas a respeito, mas não consegui assimilar para meu caso aqui… pelo que vi e entendi, isso pode ocorrer com conexoes que passam por firewall/NAT, algo do tipo…

Afora as conexões locais, temos tambem usuarios que se conectam na nossa rede de outra empresa do grupo, via terminal service num servidor windows, e a partir dessa conexao utilizam tambem o sistema local…

No mais, diariamente há reclamações de alguns usuarios com o sistema tendo ficado por alguns instantes bastante lento… depois ele volta ao normal, sem qualquer intervenção de DBA no banco…

Obrigado!

[IshiiParticipante]

Armando,

O terminal Service do Windows tem um comportamento um tanto instável e suas conexões remotas (não com o Oracle) sempre dão um pouco de problemas. Só para se ter uma ideia temos um caso onde mesmo fechando a Sessão do Terminal a Sessão do Oracle fica ativa e analisando no Servidor do Terminal o usuário ainda está logado, mesmo desligando a máquina cliente e efetuando o logoff corretamente.

A lentidão que vc menciona ocorre no Cliente do Terminal? Se sim o problema está nele e não no Oracle…

[]s Ishii

[armandovelosoParticipante]

Ola Ishii!

qto a sua pergunta: “A lentidão que vc menciona ocorre no Cliente do Terminal? Se sim o problema está nele e não no Oracle… ”

NAO! A lentidao que vejo acontecer é em maquinas dentro da rede local mesmo… e esta sendo dificil eu rastrear isso… pq o problema é intermitente.. nao sei nem como tentar a char o motivo disso… de repente aparece uma ampulheta e o usuario as vezes fica uns 3, 4 ou 5 minutos aguardando por uma coisa que era pra ser instantanea…

Obrigado!

[IshiiParticipante]

Armando.

Qdo eh intermitente fica bem difícil de analisar mesmo… segue abaixo umas perguntas que podem ajudar a traçar um perfil menos genérico do problema. Se conseguirmos identificar o problema real e suas causas já dá para analisar melhor:

1) Status do Servidor Oracle está sempre em alto processamento? Se sim quais processos?(DBWR, LGWR etc)
2) Qual a arquitetura da Aplicação? Three Tier? Two Tier? E Qual a linguagem desenvolvida?
3) Como está distribuida as máquinas clientes e qual a estrutura básica da Rede? Tem muito cascateamento de rede?
4) Nos momentos mencionados da espera do usuário qual o status da Sessão do Oracle? Se possível tente analisar o v$sqltext desta sessão…

Com isso já dá para começar. Note que estamos apenas começando de cada resposta pode surgir outras 3 perguntas..

[]s Ishii

[IshiiParticipante]

Armando,

Você poderia enviar tb o sqlnet.ora de uma as máquinas clientes que tem este problema?

[]s Ishii

[armandovelosoParticipante]

Vamos lá…

1) Status do Servidor Oracle está sempre em alto processamento? Se sim quais processos?(DBWR, LGWR etc)

R-> De um modo geral esta sempre com baixo o consumo de processamento no servidor de BD (red hat 4 ES).
Tanto pelo “top” quanto pelo “iostat” sempre vejo pouco consumo de recursos (cpu, memoria e disco), apesar de que nunca medi na hora que o usuario esta travado, ate pq fica dificil, pois o usuario tem que me comunicar na hora que esta ocorrendo e tenho poucos minutos pra averiguar… mas posso tentar ver isso e coloco a resposta em outro post!

2) Qual a arquitetura da Aplicação? Three Tier? Two Tier? E Qual a linguagem desenvolvida?

R-> O sistema é feito em delphi, a aplicacao é feita em duas camadas, a unica ressalva é que o sistema é todo dividido em modulos (ou “rotinas”) e, apesar da instalacao ser local na maquina, há um servidor windows que serve de distribuicao desses modulos, para facilitar a atualizacao dos mesmos, entao, toda vez que o usuario abre um modulo a partir de uma janela principal do sistema, esse cliente vai la nesse servidor windows e verifica se ha versao nova, caso haja, é feita uma cópia desse novo modulo pra maquina local e a partir da maquina local o modulo é aberto pro usuario…
Outro detalhe é que toda vez que um usuario abre um novo modulo é criado uma nova sessão no banco oracle, dificultando mais ainda eu rastrear o problema, pois assim cada usuario fica quase sempre com 3 ou 4 sessoes abertas no banco… e fico sem saber qual das sessoes desse usuario realmente é a correspondente ao modulo que ta lento…

3) Como está distribuida as máquinas clientes e qual a estrutura básica da Rede? Tem muito cascateamento de rede?

R-> A rede local é pequena, tem no maximo 30 estacoes cliente usando o sistema, montada em 2 switches D-Link de 24 portas cada uma (100 Mbps), mas nao temos a porta especial pra empilhamento, entao as 2 estao cascateadas…
Mas acompanho pelo utilitario web dessas SWs e nunca há trafego exagerado nas portas nao…
Pelo statspack há muito wait de “SQLNet more data from client” e “SQLNet more data to client”… mas sempre eu deixo de um dia pro outro pra gerar o relatorio… o que nao é bom pq nesseperiodo é feito backup on-line, ´efeito export… vou agora concentrar esses snapshots apenas em intervalos menores, tipo numa tarde somente ou numa manha… talvez ele me passe os waits mais proximos da realidade…

4) Nos momentos mencionados da espera do usuário qual o status da Sessão do Oracle? Se possível tente analisar o v$sqltext desta sessão…

R-> Como te falei acima, tenho a dificuldade de identificar a sessao do usuario correspondente ao modulo que ta lento, a nao ser que se feche todos os outros e deixe aberto so o modulo que ta rolando a ampulheta, aí tb tenho que ver pq as vezes a sessao no oracle demora a fechar…
Vou tentar ver a v$sqltext e procurar algo la, e postarei aqui qdo tiver alguma coisa…

5) Você poderia enviar tb o sqlnet.ora de uma as máquinas clientes que tem este problema?

R-> Conteudo do sqlnet.ora:

TRACE_LEVEL_CLIENT = OFF
#sqlnet.authentication_services = (NONE)
names.directory_path = (TNSNAMES, HOSTNAME)
names.default_domain = world
name.default_zone = world
automatic_ipc = off

Essa configuração do SQLNET.ora é antiga, qdo cheguei na empresa ja tava tudo assim, o servidor de BD era uma maquina antiga e esses problemas que estamos passando existe desde qdo mudamos de maquina (do servidor de BD). Compramos uma maquina DELL, com 2 processadores quad-core 1.6 Ghz, 3 raids 1 (HDs de 15K rpm), 4 Gb de RAM, etc… bem superior à maquina anterior…

[IshiiParticipante]

Armando,

Vamos por partes:
1) Pelo visto o problema não está no Oracle mesmo, pode ser na rede – client ou aplicação;
2) Como os executáveis estão na Máquina pode ser que parte do Problema esteja nesta Camada, na maioria das vezes estas Aplicações (Delphi, VB etc) costumam ter toda a regra desenvolvida no Front-End e não no banco de Dados, com isso o Oracle fica sub-utilizado ou vira apenas um repositório de Dados onde os cálculos mais complexos são efetuados na Máquina Cliente que se não for boa pode gerar esta lentidão mas isso é localizado e não geral – a não ser que todo o parque de máquna seja antigo;
3) Se não há grandes problemas na rede o item acima deve ser levado em consideração;
4) Na view v$Session tem uma coluna program que traz exatamente o executável que está rodando, tente localizar com ele que acho que fica mais fácil (espero que não tenha o mesmo nome de executável para todos estes módulos que vc menciona…);
5) Tente instalar um client do 10g e verificar se o problema persiste, não sei de problemas com clientes diferentes mas aí só no metalink mesmo…

Informação nova: no Listener do Server lsnrctl > utilize o comando

SET INBOUND_CONNECT_TIMEOUT 60

que vai aumentar o tempo de espera para 60 segundos para re-conexão, mas o ideal é descobrir o pq deste problema.

[]s Ishii

[armandovelosoParticipante]

Ishii obrigado pela atencao…

Coloquei a linha de comando no listener hoje.. mas ainda nao o reiniciei ainda… vou reiniciar a noite e verificar se continua aperecendo o erro no alert log….

Na v$session eu procurei na coluna program mas nao aparece nada! Os executaveis sao diferentes no cliente mas mesmo assim nao aparece nada nessa coluna.. o que me causa estranheza eh que a minha sessao que abro com o sqlplus aparece em program o executavel (sqlplusw.exe) e SEMPRE essa sessao eh a unica com status ACTIVE, todas as outras sessoes dos usuarios ficam INACTIVE.

Ontem a tarde tirei um relatorio do statspack num intervalo de 1 hora, no periodo da tarde, e por coincidencia houve uma reclamacao de lentidao por parte de um usuario nesse intervalo…
no top 5 de waits em primeiro ficou o evento:
“enq: TX – row lock contention”

Queria saber como posso fazer um trace 10046 de uma sessao de um usuario (isso se eu conseguir identificar a sessao..) e depois identificar o arquivo gerado pelo trace…

Obrigado!
[/list]

[IshiiParticipante]

Armando,

Vamos lá:

1) trace por sessão do usuário: POG 1- Trigger de Logon setando um alter session sql_trace = TRUE, o trace gerado será do Process então será bom armazenar este process em algum lugar… (separar um espaço para o trace pois pode ser que vários sejam gerados… é possível no trigger tb separar apenas alguns usuários…

2) O program do v$session não aparece nada pode ser mesmo um problema de incompatibilidade do Client Oracle, melhor verificar no metalink se há algum referência dele ou fazer o teste com o client 10g mesmo.

3) row lock contention… ocorre normalmente qdo dois ou mais usuários tentam alterar a mesma linha de Dados….minha sugestão particular seria rever a Aplicação pois o problema está nela mesmo…(se quiser mais detalhes me avise…)

[]s Ishii

[armandovelosoParticipante]

Ishii,

o problema maior é que essa aplicação é uma solução pronta, mas bastante usada, com clientes em todo o Brasil…
Posso abrir um chamado, mas acho meio ‘vago’ as informações que tenho pra passar pra empresa… mas se for o jeito…

Realmente usamos o client muito antigo… vou desinstalar esse antigo e por o do 10G mesmo…

Obrigado!

[armandovelosoParticipante]

Verificando o arquivo de LOG do SQLNET (sqlnet.log) no servidor, percebi que sempre que ocorre (no mesmo horario) um ORA-3136 no alert.log SEMPRE é registrado tambem no sqlnet.log do servidor de banco a seguinte informacao:

---

Fatal NI connect error 12170.

VERSION INFORMATION:
TNS for Linux: Version 10.2.0.1.0 – Production
Oracle Bequeath NT Protocol Adapter for Linux: Version 10.2.0.1.0 – Production
TCP/IP NT Protocol Adapter for Linux: Version 10.2.0.1.0 – Production
Time: 11-FEB-2008 14:17:11
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
nt OS err code: 0
Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.10.3.179)(PORT=1496))

==============

Sendo que esse IP aí é de uma maquina da rede local!

Com menos frequencia, há casos em que a ultima linha nao diz qual HOST é:
Client address:

[IshiiParticipante]

Armando,

Notei que todos os erros se referem apenas ao TIMEOUT e não há erro de OS. Isso me leva a imaginar que deve mesmo haver um problema na sua rede. Verifique se não há nenhum roteador, hub, switch, placa de rede do servidor com problema. Se possível instale uma nova placa de rede no servidor e faça uns testes com ela. E vamos tentando…

boa sorte!

[]s Ishii

[armandovelosoParticipante]

Beleza Ishii,

apesar de ser um DELL PowerEdge 2900, a placa de rede é on-board, e eu ja vinha com vontade mesmo de comprar uma placa de rede, ate porque meses atras tava tendo muito problema de desconexão no sistema com o banco, ate conexoes SSH que eu fazia as vezes caía!

A DELL trocou a placa-mãe, melhorou, mas acho que só colocando placa de rede off-board pra testar de vez!

Obrigado!

[Autor]

Posts