E aí Chiappa. Então, já respondendo ao teu mail anterior, não existe ASM. É filesystem. E sobre essas propostas:
a. Sim, inclusive em versões mais antigas dava problema ao chegar a 2G por limitação. Mas temos rotate a cada 200m. Acho que não é esse o problema. b. Caso o problema volte a acontecer irei atuar de acordo com a descrição na nota. c. Sim, estou investigando todas as camadas com o que tenho, rede, os, hardware, database, app e afins. Até agora nada aponta para esgotamento de recursos. 1. conforme respondi anteriormete temos o nosso snap, que nos dá uma ideia disso tudo. 2. o restart do listener NÃO RESOLVEU. O que resolveu foi o restart do database. Esse foi um incidente isolado, nunca havia ocorrido. O cliente tinha um banco 9i 32 e migrou pra 9i 64. O que eu não concordei, mas foi acordado pelo comercial, então foi feito. Agora estamos passando por uma pá de problemas... enfim. Pode ser que não se repita, vai saber, a minha dúvida era mais se alguém já tinha visto algo assim. Notei que a auditoria de logoff está ativa e que a tabela aud$ possui 104 milhões de registros, com 20G, sendo que no momento da crise haviam várias sessões fazendo insert nessa tabela. Acredito ser mais consequência do que causa, de qualquer forma, desabilitei essa auditoria e trunquei a tabela aud$, visto que o cliente não precisa dessa informação. Vou continuar atuando, mas agora só em 2014! :) Aproveito pra desejar um ótimo 2014 pra todos, e em meu nome agradecer toda ajuda que trocamos em 2013. Esse grupo sem dúvida é fantástico, e poder ver o conhecimento que alguns aqui tem, exemplo: o Chiapa, Rodrigo Almeida e o Mufalani que tive o prazer de conhecer pessoalmente num evento do GUORS, entre tantos outros 'monstros'. Obrigado a todos. São meus ídolos e inspiração! Att,/Regards, Vitor Jr. Infraestrutura / Infrastructure Team Oracle 11g DBA Certified Professional - OCP Oracle Certified Expert, Oracle Real Application Clusters 11g and Grid Infrastructure Administrator - OCE Oracle Database 11g Performance Tuning Certified Expert - OCE Oracle Exadata 11g Certified Implementation Specialist Oracle Certified Associate, MySQL 5 mail, gtalk e msn: vitorj...@gmail.com http://certificacaobd.com.br/ skype: vjunior1981 https://mybizcard.co/vitor.jr.385628 Em 31 de dezembro de 2013 10:19, <jlchia...@yahoo.com.br> escreveu: > > > Vitor, estava pensando no seu caso e seguem algumas obs a mais que > talvez te ajudem : > > > > a. imagino que vc saiba que nas versões mais antigas de listener era > muito comum lentidão se os arquivos de log/trace ficassem muito grandes : > não era nem bug, era mais uma ineficiência ao lidar com grandes volumes > inesperados.... No caso, vc Olhou os tamanhos de logs / traces ?/ Vc TEM > alguma automação para fazer log rotate e arquivamento de traces a cada > poucos dias e/ou se o tamanho dos logs ou traces chegar perto da casa dos > gigabytes ?? > > > b. até onde eu lembrava, os bugs clássicos de listener travando (ie, > aqueles causados ou por RDBMS se registrando sozinho no ONS ou então por > listener sob alta demanda abrindo um processo secundário que não se fecha), > que eu fiquei conhecendo bem há uns anos com cliente que se recusava > point-blank a sair dum 9ir2 mais antigo aplicando o patchset mais recente > na ocasião, já tinham sido corrigidos no 9.2.0.8 que é o seu e então achei > que não se aplicavam... > > Porém, de curiosidade fui olhar no metalink a nota correspondente > Intermittent TNS Listener Hang, New Child Listener Process Forked (Doc ID > 340091.1) e ela em algum momento foi updateada marcando agora 10.2.0.3.x > como o patchset de solução, e não há mais menção ao 9i : TALVEZ a issue não > tenha sido eliminada totalmente no 9ir2 no último patchset e quando o foi, > já não existia Suporte pro 9i aí o fix não foi backported ... > > Assim, (já que Imagino que pra esse cliente upgrade pra uma versão > suportada vai rolar sabe Deus quando), experimenta implementar os > work-arounds citados na nota, que são basicamente acrescentar um > SUBSCRIBE_FOR_NODE_DOWN_EVENT_<listener_name>=OFF , Renomear o arquivo > $ORACLE_HOME/opmn/conf/ons.config para uma outra extensão & restart do > listener.... > > > > c. caso vc não consiga encontrar nenhuma Evidência sólida de recursos se > esgotando (o que, Óbvio, além do hardware do servidor Oracle ** inclui ** > coisas como servidor DNS, switches/routers, IPs flutuantes demorando para > serem associados, enfim) a possibilidade fica no ar : para a comprovar, o > que vc pode fazer é : > > > > 1. implementar alguma coisa que não só registre waits mas forneça ao > menos um sample de consumo, tipo qtdades de sessões, logins/resource usage, > I/O, etc - tanto dentro do database, via algo tipo o S-ASH que citei, > quanto FORA do database... Fora do database eu não re-inventaria a roda e > implementaria o OSwatcher, talvez junto com uma boa solução de > monitoramento de workload de rede , tipo o cacti... > > 2. na próxima vez que der o problema, rapidamente antes de restartar o > listener mensurar consumo de memória (via cat /proc/piddolistener/status,) > qtdade de processos abertos pelo listener E pelo So (via ps, mesmo) , > qtdade de sockets abertos (via netstat -na), se possível gerar um stack via > gdb $ORACLE_HOME/bin/tnslsnr piddolistener... > > Espero ter ajudado/contribuído com mais idéias e caminhos.... > > > > []s > > Chiappa > > >
