E aí Chiappa, obrigado pelas observações. O que temos é um script na crontab que roda a cada 2m e executa algumas consultas que me mostraram esses eventos que repassei. O l.a. do servidor no momento estava bem baixo, assim como a utilização de disco (I/O inexistente). Talvez alguma coisa de rede, mas aí eu não teria esse histórico. Infelizmente o mistério continua hehehe
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 30 de dezembro de 2013 18:50, <jlchia...@yahoo.com.br> escreveu: > > > Bom, eu rigorosamente desconheço bug com esses sintomas que vc > descreve... Dado que log file sync é sintoma de lgrw esperando para poder > terminar o flush do log buffer pra disco, que LGWR wait for redo copy são > as atualizações efetuadas dum log file indo pro(s) destino(s) de > multiplexação e que buffer busy wait é concorrência de acesso em buffer > blocks sendo alterados, eu DEDUZO que na verdade o que aconteceu aí é que > vc teve um pico de processamento tão grande (usuários fazendo carga fora de > hora, atualização mensal/anual sem aviso, algum outro software concorrendo > com o RDBMS, talvez ??) que o hardware saturou, e aí ** OU ** o I/O não deu > conta de gravar os logs em disco (evidentemente quando há logs não-seguros > o banco TEM que "parar"/não aceitar nada novo até isso ser corrigido, senão > teria chance de perder dados comitados - é ESSE o motivo do RDBMS Oracle > ficar indisponível para os usuários e não para os DBAs quando a archive > area enche, por exemplo), ** E/OU ** (uma outra possibilidade) os recursos > necessários para se criar uma conexão de rede (ie, CPU, banda de rede, > memória RAM do sistema, etc) se esgotaram por causa do tal pico, ou > derivados... > No que toca à investigação : Se fosse banco 10g vc até teria chance a > capacidade de talvez ter históricos licensiados e ativos (ie, AWR e ASH), > mas sendo 9i caso vc não tenha implementado nada por conta (tipo o S-ASH em > http://www.kylehailey.com/ash-masters/, digamos) , aí as suas opções são > limitadas para tentar comprovar a hipótese de concorrência extrema e/ou > sobrecarga/pico causando esgotamento do hardware : se vc tiver algum tipo > de Auditoria ativo talvez isso possa te dar indicações, talvez vc possa > minerar via logminer o log gerado, talvez haja logs da aplicação e/ou do > pool de conexões ou correlatos que possam ser consultados, vai ser por > aí.... Itens complementares podem ser o listener.log, o sqlnet.log (do > servidor e eventualmente do cliente) , E os logs de SO das máquinas.... > > []s > > Chiappa > >
