Amigo, Acho que nao precisa falar mais nada apos a explicacao chiappa, porem nao custa palpitar em solucoes.
Solucao1: Vc tbm pode fazer de uma forma mais segura, como vc tem um terceiro no vc pode utilizar ele como uma maquina ponte. 1 - Vc pode prepar esta maquina ponte com o a nova versao do SO e com o ultimo release da versao do oracle, apos isso migrar os dados para homologacao sua e dos usuarios finais. 2 - Apos a Homologacao desta maquina ponte(com o a nova versao do SO e com o ultimo release da versao do oracle) ai sim, pode migrar a producao para a sua maquina ponte; 3 - Apos isso prepa o rac nos outros 2 nos com mais tranquilidade dai libera para testes tbm no rac. Com isso vc tera um tempo suficiente para homologacao da atualizacao na maquina ponte e sem riscos. Obs: É importante para esta situacao é saber se o seu banco vai aguentar a carga neste nó ponte. ---------------------------- Solucao2: A Sua ideia tbm eh muito boa, porem caso ainda nao teve a oportunidade de aplica-la nao aconselharia fazer isto em um ambiente critico. Pelo que intendi esse rac de 2 nos passara a ter 3 nos, entao para nao mecher no mesmo storage que estao os dados de producao, vc poderia tbm migrar 1 dos seus nos atuais de rac para single-instance FILE SYSTEM. Desta forma vc estaria *isolando* completamente os dados desta maquina e com isso trabalharia no storage de forma mais segura. 1 - Com isso vc trabalharia nos outros 2 nos, apos os nos prontos faria as homologacoes; 2 - Apos as homologacoes migraria a producao que neste momento esta em single + 11gr1 + rh5.2 + FS para o rac + 11gr2 + rh5.5 + ASM; 3 - Ai sim o terceiro no vc iria estar mais tranquilo ainda para adicionalo como 3º no; Obs: Com isso vc so teria indisponibilidade em um momento que eh a virada da chave de single para o rac. Espero ter ajudado a ter mais uma possivel solucao, logo aparecera mais solucoes legais dai vc aplica a que se enquadra melhor com o seu ambiente. -- Att, Diego Leite DBA ORACLE m 2 de agosto de 2011 20:30, José Laurindo <jlchia...@yahoo.com.br>escreveu: > ** > > > Colega, antes uma obs : se tem qualquer criticidade acima de medíocre esse > database, vc ** nunca ** pode fazer um upgrade (e nem sequer qualquer outra > manutenção, como aplicação de patches, por exemplo) diretamente em Produção, > necessariamente vc ** TEM ** que testar antes direitinho num ambiente > teste/homologação, okdoc ??? A questão não é que seja um procedimento > complexo e obscuro, o ponto é que é um procedimento Extenso (absolutamente > Não É só rodar um "setup.exe" da vida e cabou) ,e além disso novos releases > necessariamente podem trazer novos bugs, podem mudar ,métodos de > acesso/conexão/sintaxes, ALÉM dos inevitáveis novos bugs - esses bichinhos > utilizam as novas versões como "táxi" preferencial... OU SEJA, ao contrário > da aplicação de patchsets , quase Tudo é permitido acontecer/mudar quando vc > fala de upgrade de versão, então vc antes tem que testar, testar E testar > .... Assim, se esse ambiente que vc pretende migrar no fim de semana é > produção, tem alguma criticidade E vc ainda não fez o teste num ambiente > teste/homo antes, eu recomendo que vc ABORTE isso e faça o procedimento fora > da Prod antes, blz ? > > Agora sim, respondo : começando pelo upgrade de Linux de 5.2 para 5.5 , ao > que entendo (CONFIRME com o Suporte da redHat e boas refs, mas afaik) isso > requer apenas um patch de SO, E os programas que rodavam antes sob 5.2 podem > continuar sem mudanças no 5.5 , então é simplesmente o caso de instalar o > 5.5 na máquina 3, parar o CRS e as instâncias (DB e ASM) na máquina 2, > aplicar o patch para 5.5 na máquina 2, restart de tudo e blz, aí vc repete o > mesmo processo na máquina 1. > > Indo pra dentro do ambiente Oracle agora, a tua referência Maior vai ser o > manual de Upgrade, e a (crucial) nota metalink 785351.1 "Upgrade Companion > 11g Release2", bem como a nota "RAC Assurance Support Team: RAC and Oracle > Clusterware Starter Kit and Best Practices (Generic)", Doc ID:810394.1 . > > Muito bem, Próximo passo é o upgrade do CRS : ele pode ser feito em > rolling, sem indisponibilidade (um nó por vez), veja a nota metalink "Oracle > Clusterware (formerly CRS) Rolling Upgrades", Doc ID 338706.1 . > > Para o ASM, é possível se fazer rolling upgrade também, veja no manual > "Oracle® Automatic Storage Management Administrator's Guide" o cap. 3 - > Administering Oracle ASM Instances" o item "Using Oracle ASM Rolling > Upgrade", ou até mesmo não fazer o upgrade neste momento : confira no > metalink mas afaik ASM 11gr1 no último patchset é Sim suportado para ser > usado por um database 11gr2... > > Finalmente, para vc não ter indisponibilidade em upgrade de versão do > database, a Recomendação é que vc monte um stanbdby físico temporário, a > nota "Oracle11g Data Guard: Database Rolling Upgrade Shell Script", Doc ID > 949322.1 documenta esta opção. > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, "luzizardba" <amorrim@...> escreveu > > > > > Boa tarde amigos, > > > > Neste final de semana, irei realizar a migração do cluster de 2 nós da > minha empresa que esta na versão 11.1.0.6 e utiliza Red Hat 5.2 para a > versão RAC 11.2.0.2 e RHEL 5.5 e gostaria de algumas sugestões dos caros > amigos... > > > > Hoje tenho um storage da DELL conectado a estes nós e possuo 3 diskgroups > (DATA, INDX e FRA). Tenho uma terceira maquina que será utilizada para o 3 > nó, então ela esta ainda parada. > > > > Minha idéia inicial seria mover todas as tablespaces que se encontram no > diskgroup INDX para DATA e desabilitar o segundo nó do cluster, deixando > somente o primeiro operacinal. Desta maneira eu já teria os dois primeiros > nós do novo cluster sendo montado em cima do novo diskgroup que será criado, > a partir do INDX que foi dropado. > > > > Aos poucos (durante a semana) iria movendo as tablespaces / usuário de um > servidor par ao outro e criando as devidas conexões entre as consultas, > através de DBLINK / sinomimos publicos. Desta maneira conseguir ter os dois > ambientes no ar. > > > > A idéia do transporte dos dados, seria através de tablespaces > transporaveis (datapump). Fiz alguns testes no transporte utilizando > tablespaces transportables da versão 11.1.0.6 para a versão 11.2.0.2 e não > tive problemas. > > > > No novo cluster, pretendo utilizar OCFS2 para recepcionar SPFILE, Voting > e OCR. > > > > O que acham ? alguma sugestão ? Lembrado somente que tive esta ideia > pensando em um ambiente disponível o mais tempo possível. > > > > > [As partes desta mensagem que não continham texto foram removidas] ------------------------------------ -------------------------------------------------------------------------------------------------------------------------- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -------------------------------------------------------------------------------------------------------------------------- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >http://www.oraclebr.com.br/ ------------------------------------------------------------------------------------------------------------------------ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: oracle_br-unsubscr...@yahoogrupos.com.br <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
