Douglas Paiva de Sousa.
fbussCaros amigos, tenho uma duvida e gostaria de alguma sugestão, claro, se possível.
Tenho o seguinte Ambiente – Maquina RAC01 e RAC02 sendo que as maquinas são idênticas com 16g memoria e Linux (Red Hat Enterprise Linux Server release 5.5 (Tikanga))
Oracle Database 11g Release 11.2.0.1.0 – 64bit Production
PL/SQL Release 11.2.0.1.0 – Production
CORE 11.2.0.1.0 Production
TNS for Linux: Version 11.2.0.1.0 – Production
NLSRTL Version 11.2.0.1.0 – Production
Pretendo:
1. Acrescentar mais um No (Exemplo RAC03), sendo que nesta maquina, por ser atual tem 32gb de memoria e Linux (Red Hat Enterprise Linux Server release 7.0 (Maipo))
2. Verificar o desempenho.
3. Retirar um no da maquina mais antiga, por exemplo RAC02
4. Acrescentar mais um No (Exemplo RAC04), sendo que nesta maquina, por ser atual tem 32gb de memoria e Linux (Red Hat Enterprise Linux Server release 7.0 (Maipo))
5. Retirar um outro no da maquina mais antiga, por exemplo RAC01
Ou seja, substituir as maquinas antigas pelas novas. Porem estou fazendo desta forma, pois tenho somente uma porta (FC-HBA) disponível para uso.
O que vocês acham ? Agradeco sugestões.
Um abraco.
rman@fbuss
Só uma observação. Como você está utilizando a versão Standard o RAC é limitado em 4 sockets. Logo, dependendo de quantos sockets você tem em cada máquina, terá que se atentar na ordem de remover e adicionar nós.
Reparei também que você está utilizando a primeira versão do Oracle Database. A última versão é a 11.2.0.4.0.
Marcio68AlmeidaOlá…
Eu tenho algumas observações.
1. Eu não gosto de trabalhar com RAC/GRID com equipamentos não idênticos, neste caso, você estará com um servidor com sistema operacional muito mais atual, se você for utilizar a versão Oracle também mais atual, então o desastre é certo…
2. Por que, ao invés de ficar misturando, por que simplesmente não cria o nó um na máquina nova, já que ela é mais potente (pelo menos mais memória), deve suportar a primeira parte da empreitada, depois acrecente o segundo nó, também com a outra máquina nova. Se houver problemas com o nó único, alguma incompatibilidade, você tem os servidores anteriores para retomar o processo sem traumas.
3. Como diz um amigo, um RAC/GRID nada mais é do que um amplificador, se a aplicação é boa, ficará melhor, se ela for ruim, ficará bem pior, portanto, utilizar um único nó também possibilitará a você avaliar a qualidade da aplicação e da modelagem.
4. Se a aplicação é estável, e você domina o processo de RAC/GRID, então não há necessidade de ficar migrando paulatinamente, faça o processo e segue em frente.
5. Nem preciso lembrar de backup antecipado, lista de ações (check list) e teste em todas as partes, inclusive fechamentos e processos complexos, se você tiver as máquinas originais intactas e um backup ok, poderá retornar em caso de desastre.
Douglas Paiva de SousaCara eu já passei por isso, só que na época eu tinha uma base relativamente pequena (eram 10TB só) e como eu tinha uma janela de manutenção grande construí um novo ambiente do “zero” e restaurei um backup full.
Não sei se você tem a oportunidade de fazer isso, mas de qualquer forma trabalhar com ambiente heterogênio não é legal e nem seguro.
Att,
Douglas Paiva de Sousa
http://www.oradata.com.br
douglas.paiva@oradata.com.br