Deixa eu chutar: esse s.o. por acaso não é SLES ou openSUSE? ;)
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 19 de março de 2014 10:04, Evandro Giachetto <evandrogiache...@gmail.com>escreveu: > > > Olá Angelo. > > Acabo de realizar um reboot nesses servidores e tudo voltou a subir > normalmente. > > Eu acabei descobrindo que havia um outro script (/etc/sysconfig/oracle) > que forçava os parâmetros de kernel antigos. > > Corrigi os parametros nesse arquivo também (embora eu deva manter a conf > apenas no sysctl.conf, o que me parece mais lógico) e após o reboot q > acabei de fazer nos servidores, tudo subiu normalmente. > > Somente o auto-start das instâncias que não funcionou, subindo apenas o > ASM no segundo nó. No primeiro nó o auto-start funcionou normalmente para > as instancias. > > No mais, ao menos as instâncias estão de pé e aos poucos vou ajustando > esse ambiente que está um tanto quanto bagunçado. > > Muito obrigado pela ajuda de todos. > > Evandro Giachetto > Oracle DBA > evandrogiache...@gmail.com > > > > Em 12 de março de 2014 14:51, angelo <angelolis...@gmail.com> escreveu: > >> >> >> Evandro, >> >> Só por desencargo de consciência.. >> >> No próximo reboot que esse servidor sofrer... será que os parâmetros não >> vão voltar aos valores anteriores ? os novos parâmetros foram gravados na >> pedra, digo, no arquivo conf certinho? Testou isso para se certificar ? >> um detalhezinho que as vezes passa batido, pode colocar tudo a perder.. >> >> >> >> >> 2014-03-12 14:21 GMT-03:00 Evandro Giachetto <evandrogiache...@gmail.com> >> : >> >> >>> >>> Olá Chiappa, muito obrigado por sua ajuda. Realmente me ajudou muito. >>> >>> Consegui identificar o que havia mudado, apenas não consegui identificar >>> o que havia feito essa mudança. >>> >>> O arquivo ocr.loc havia sido algerado por alguém ou por algum processo. >>> Estou tentando identificar o que fez essa mudança e quando. >>> >>> Por esse motivo, o ocr não conseguia enxergar os raw devices, e por >>> isso, claro, não conseguia subir. >>> >>> Nos checks a partir do metalink que você passou, eu também identifiquei >>> que um dos VIP estavam desligados, passei essa informação para o pessoal do >>> datacenter e a interface de rede foi re-estabelecida. >>> >>> Depois de tudo isso, ainda encontrei alguns parametros do kernel do SO >>> defasados. >>> >>> (Já haviam sido alterados pelo DBA, mas pelo visto não persistiu a >>> informação e, quando o servidor reiniciou, voltou para os parametros >>> antigos). >>> >>> Depois de tudo arrumado, finalmente fui capaz de re-estabelecer o CRS e >>> subir as instâncias nesse nó. >>> >>> >>> Muito obrigado novamente por sua ajuda. >>> >>> Obrigado também ao Fábio Aneas e ao Marcelo Favero. Creio que também >>> acompanham esse grupo. 2 Monstros em Oracle. >>> >>> Evandro Giachetto >>> Oracle DBA >>> evandrogiache...@gmail.com >>> >>> >>> >>> Em 11 de março de 2014 20:43, <jlchia...@yahoo.com.br> escreveu: >>> >>> >>>> >>>> Bom, primeiro de tudo *** muito dificilmente *** o crs pára de >>>> funcionar do nada : com quase Absoluta certeza, alguma mudança teve aí... O >>>> difícil é que muitas vezes a mudança é de rede e/ou do próprio servidor, aí >>>> o pessoal de rede jura de pé junto que não, que não, mas depois de uma >>>> longa e difícil investigação aí vc descobre coisas como conflito de IPs (o >>>> um dos IPs quew deveria estar reservado para o cluster RAC não foi >>>> reservado no DNS e algum outro device na rede o quis usar, digamos), vc >>>> descobre que o monstrengo do sysadmin mudou senha e/ou detalhes do usuário >>>> oracle quebrando a conectividade ssh entre as máquinas, que neguim fez >>>> update no SO, que algum software idiótico de "segurança" remover os >>>> privilégios de CAP_NUMA_ATTACH,CAP_BYPASS_RAC_VMM,CAP_PROPAGATE do usuário >>>> que roda o CRS, coisas assim... >>>> A primeira coisa então é investigar ** EXATAMENTE ** o que mudou.... >>>> Uma ferramenta que pode ser utilíssima é o CVU, ele tem DIVERSOS checks (de >>>> hardware, de conectividade, de packages, etc) que vc pode pedir, baixe no >>>> metalink a versão mais recente dele...Infelizmente , coisas INTERNAs como >>>> DNS malconfigurado, conflito de IPs e quetais nem sempre com ele vc pega... >>>> na mesma toada, recomenda-se Muito que vc instale e rode o >>>> diagcollection.pl, o RDA e um oswatcher : todos esses te dão bons >>>> insgights e servem como material para um possível futuro chamado no Suporte >>>> Oracle... Essas coisas não são invenção da minha cabeça, estão nas notas : >>>> >>>> "Data Collecting for Troubleshooting Oracle Clusterware (CRS or GI) >>>> And Real Application Cluster (RAC) Issues" (Doc ID 289690.1) >>>> >>>> e >>>> >>>> "Oracle Clusterware 10gR2/ 11gR1/ 11gR2/ 12cR1 Diagnostic Collection >>>> Guide" (Doc ID 330358.1) ... >>>> >>>> Segunda coisa, checks de interesse em troubleshoot de CRS : veja a >>>> nota metalink "CRS can not Start After Node Reboot" (Doc ID 733260.1) , que >>>> ela lista diversos cenários comuns... Sobre logs, veja que além dos logs >>>> do crs (que INCLUSIVE a nota anterior mostra que nem todos estão abaixo do >>>> CRS_HOME), os logs ** do sistema ** (como /var/log/messages) ABSOLUTAMENTE >>>> tem que serem checados... >>>> >>>> >>>> Outro teste MUITO válido é : pedir o ./init.cssd stop , se ASSEGURAR >>>> que não há entradas perdidas em /var/.oracle, /tmp e quetais, e aí pedir o >>>> ./init.cssd start (sempre como o usuário que roda o CRS, of course:) : com >>>> isso vc recebe Diretamente as msgs de erro, às vezes isso ajuda... E sempre >>>> recheque o cssdout.log após suas tentativas... >>>> >>>> E finalmente : o VIP não subir num outro nó após uma falha com reboot >>>> é Extremamente comum : para verificar essa possibilidade, siga a nota "How >>>> to Troubleshoot CRS Not Starting a VIP Resource" (Doc ID 372643.1) ... >>>> >>>> []s >>>> >>>> Chiappa >>>> >>> >>> >> > >
