Introdução
Quando vamos usar a abordagem Out-Of-Place Patching para atualizar o Grid Infrastructure, além da possibilidade de clonar o Oracle Home existente ou criar um Oracle Home novo de forma limpa, uma terceira abordagem muito prática e que poupa bastante tempo é o de criar uma Gold Image.
Uma Gold Image nada mais é do que um binário pronto com os patches já aplicados, e que podemos copiar para diversos servidores e depois executar o processo de instalação em poucos minutos para criar um novo Oracle Home. Essa abordagem é peça chave por trás do funcionamento do Oracle FPP, mas que também podemos facilmente utilizar de forma manual.
Para criar uma Gold Image, basta executar o gridSetup.sh com a opção -createGoldImage, ou simplesmente acessar o Oracle Home em questão e criar um tar a partir dele. Independente se estamos falando de automação do FPP ou de um processo manual, algumas experiências recentes me levaram conclusão de que pode não ser uma boa ideia criar uma Gold Image a partir de um Grid Home que foi previamente instalado com algum grupo definido na opção OSOPER.
Um dos pré requisitos do processo formal da opção –switchGiHome do gridSetup.sh, é que os grupos de SO de origem e destino sejam identificados, estamos falando dos grupos utilizados para OSDBA, OSOPER e OSASM. Então antes de realizar a instalação do novo GI Home, você precisa identificar quais grupos foram utilizados na instalação do GI Home atual. Obviamente, após algum tempo trabalhando no mesmo ambiente, você acaba sabendo isso de cabeça, mas na dúvida, pode usar o script get_groups.sh para verificar essa informação.
Problema
Acontece que durante a instalação do novo GI Home usando uma GoldImage, mesmo que a opção “oracle.install.asm.OSOPER” esteja sendo passada com um valor vazio (ou seja, sem nenhum grupo), a instalação herda o grupo que foi usado no GI Home de origem da Gold Image.
Por exemplo: Você cria um GoldImage a partir de um GI Home onde todos os grupos são definidos como “oinstall”. Então após tentar instalar esse mesmo binário em outro servidor deixando a opção de “OSOPER” vazio, o Grid Home em questão será instalado com “OSOPER=oinstall” de forma implicita.
O efeito colateral disso que é a operação de switchGiHome deverá falhar com o erro similar a este durante a janela de manutenção:
PRGO-1629 : The groups "OSOPER=oinstall" of the patched working copy are not configured in the Oracle Grid Infrastructure homeEste problema só acontece quando a GoldImage possui um grupo para o OSOPER e se você tenta deixar este grupo idefinido (vazio) na nova instalação. Caso você passe qualquer grupo no comando, como “dba” ou “oinstall”, a instalação irá respeitar este grupo.
Exemplo, se o GI Home do qual você criar uma GoldImage retorna algo assim no script get_groups, ao instalar essa Gold Image em outro servidor, o grupo OSOPER poderá ter qualquer valor que passarmos no comando do gridSetup.sh, inclusive um valor vazio:
[grid@lab01 ~]$ ~/get_groups.sh -home /u01/app/19.0.0/grid -oui oracle.install.asm.OSDBA=dba oracle.install.asm.OSOPER= oracle.install.asm.OSASM=dba
Agora se home de origem em questão tem uma configuração como essa abaixo, com o grupo OSOPER definido: Então ao usar essa GoldImage para criar outro home, a opção OSOPER poderá ser usadoa com qualquer grupo, mas ele não poderá ficar como vazio:
[grid@lab01 ~]$ ~/get_groups.sh -home /u01/app/19.0.0/grid -oui oracle.install.asm.OSDBA=dba oracle.install.asm.OSOPER=dba oracle.install.asm.OSASM=dba
Note que você pode até executar o comando gridSetup.sh deixando este grupo vazio, e ele não apresentará nenhum erro, mas implicitamente o home herdará o grupo de origem.
Exemplo, se você clonar o home do exemplo acima, e rodar o gridSetup.sh com as opções “OSDBA=oinstall”, “OSOPER=” e “OSASM=oinstall”, o resultado será algo assim:
[grid@lab02 ~]$ ~/get_groups.sh -home /u01/app/19.0.0/grid2 -oui oracle.install.asm.OSDBA=oinstall oracle.install.asm.OSOPER=dba oracle.install.asm.OSASM=oinstall
Então considerando um cenário onde você não tenha garantia de que este grupo é usado em 100% dos ambientes o qual vai aplicar patch usando a GoldImage, minha recomendação é sempre criar uma GoldImage com o grupo OSOPER vazio. Dessa forma, se você deixar essa opção vazia na nova instalação, o novo GI Home ficará com o grupo vazio, conforme esperado. Caso precise especificar algum grupo, este grupo será respeitado, conforme esperado.
Por se tratar de um comportamento do próprio instalador do Grid Infrastructure (gridSetup.sh), este problema pode ocorrer com qualquer ferramenta que utiliza-se deste método, incluindo o Fleet Patching and Provisioning (FPP). Na verdade eu precisei investigar este problema mais a fundo durante um cenário de erro com FPP mesmo, inicialmente achando que era uma falha da ferramenta, e não do processo de instalação em si.
DICA: Este problema costuma ocorrer especificamente com o grupo do OSOPER pois ele é opcional na instalação do Grid Infrastructure, então é esperado que os demais grupos sempre estejam preenchidos.
Efeito Colateral no FPP
Para o FPP, esse comportamento é mais danoso e mais confuso do que no cenário de instalação e swtichHome manual.
Quando usamos o FPP pela primeira vez em um servidor para criar uma workingcopy de um Grid Home, usando uma GoldImage que foi importada de um GI Home que tem o grupo OSOPER definido, caso o GI Home atual deste servidor não tenha o grupo OSOPER, dá início a um problema que pode passar despercebido em um primieiro momento, mas apresenta erro a partir segunda vez que precisar realizar um “move gihome” usando o FPP.
Exemplo: Considere que você tem um servidor com Grid 19.21, e vai usar o FPP para atualizar para 19.22, e alguns meses depois vai usar o FPP novamente para aplicar o 19.23. O problema vai estourar quando for fazer o move para o 19.23 (segundo move).
Sequencialmente, o problema ocorreria dessa forma:
- O FPP identifica que o GI Home atual (19.21) não tem o grupo OSOPER, ele emite o comando gridSetup.sh com “OSOPER=” para a instalação do novo GI home (19.22).
- O FPP registra no metadados da WorkingCopy que aquele novo Home não tem um grupo para OSOPER. Mas na prática, o binário possui esse grupo devido ao comportamento inesperado do instalador que herdou o grupo da GoldImage.
- Você emite um “move gihome” para atualizar de 19.21 para 19.22 e a operação é completada com sucesso. Nesse estágio tudo ocorre bem, porque quando se trata do primeiro “move gihome” em um servidor não gerenciado pelo FPP, ele irá comparar os grupos de SO do GI Home atual com os grupos vinculados a workingcopy de destino (ele tá comparando banana com laranja sem perceber).
- Você usa o FPP novamente para instalar o Grid 19.23, ele identifica que Grid Home atual tem o grupo OSOPER=oinstall e define esse grupo na instalação do novo Home. O metadados da workingcopy dessa nova instalação é registrada com a informação de que ele possui OSOPER=oinstall.
- Você emite um “move gihome” para atualizar de 19.22 para 19.23, a operação falha com a mensagem de que os grupos de SO não são iguais no GI Home de origem e destino. Dessa vez dá erro porque a partir do segundo move, o FPP compara a informação do metadados das duas workingcopy (origem e destino), ao invés de olhar para o que realmente foi instalado no binário.
Para demonstrar este comportamento ao suporte, eu montei o caso de teste abaixo.
1) Instalei um Grid normalmente deixando a opção de OSPOPER vazia:
2) Depois de já ter um ambiente de teste com Grid instalado, usei a GoldImage do FPP abaixo para criar um novo GI Home. Observe que esta GoldImage tem o grupo OSOPER definido:
Workingcopy 1 criada com sucesso:
Agora ao consultar o registro da workingcopy, o mesmo indica que ela não tem o grupo OSPER, que em teoria está correto porque o FPP identificou que o GI Home atual do servidor “lab01” não tem este grupo, então internamente o FPP executou o comando gridSetup.sh de forma apropriada:
No entanto, neste momento ao verificar o arquivo “config.c”, o notamos que o binário foi instalado com o grupo incorreto (ontem está oinstall, o esperado era estar vazio):
3) Seguindo o teste, fiz um move do GI Home atual para o novo criado na workingcopy 1:
Este primeiro move concluiu com sucesso porque quando se trata da primeira vez que ele está fazendo um “move gihome” no servidor, ele está fazendo um move de um “unmanaged gihome” para um “managed home”. A diferença é que quando se trata de um “unmanaged home”, o FPP conecta no servidor de destino e coleta as informações do GI Home de origem, e depois compara com as informações que ele já tem no metadados para o GI Home de destino.
Como a workingcopy foi registrada com a informação de que o home não tinha o OSPER, essa validação passou com sucesso na etapa de pré req do FPP.
4) Criando uma nova workingcopy usando a mesma Gold Image:
Ao consultar essa workingcopy, notamos que registro tem a informação de que ela foi criada com OSPER=oinstall
Isso acontece porque como a primeira workingcopy foi instalada com o grupo errado, e o primeiro move não percebeu isso, o Grid foi movido com sucesso para o novo home. No momento que criamos a segunda workingcopy, o FPP foi verificar novamente quais eram os grupos de SO usados na instalação do GI Home ativo, encontrando o OSOPER=oinstall.
Com isso, comando de instalação que o FPP rodou com gridSetup incluiu este grupo, que seria o resultado esperado mesmo. Para essa segunda workingcopy, a instalação e o registro seguiram o comportamento esperado, considerando que este grupo estava definido no GI Home ativo naquele momento.
5) Seguindo o teste, tentamos realizar um move para a segunda workingcopy.
O sintoma do problema aparece neste momento, pois agora por se tratar de um move envolvendo duas workingcopy (managed home), o FPP não compara o conteúdo do arquivo “config.c” dos dois GI Homes, mas sim o conteúdo do metadados de amabas as workingcopy.
Esse é o resultado:
Workaround para Cenário com FPP
Uma solução de contorno para isso é deletar o metadados da workingcopy de origem, fazendo com que o FPP use as informações reais do arquivo “config.c” para comparar os grupos de origem e destino:
rhpctl delete workingcopy -workingcopy WC_GI1922_lab01_test1 -metadataonly
Com isso, ao executar o comando de move novamente, o FPP irá passar na validação com sucesso, e partir deste ponto não ocorrerá mais o problema da diferença do grupo OSOPER em futuras atualizações.
Este workaround foi documentado pelo suporte na nota abaixo:
FPP Move Failed – Groups “OSOPER=oinstall” Of The Patched Working Copy Are Not Configured In GI Home (Doc ID 3019146.1)
Workaround para Cenário Manual
O mais recomendado seria reinstalar o novo GI Home com os grupos corretos fazendo uma instalação limpa, ou usando outra GoldImage que foi criada sem o grupo OSOPER para evitar que o erro ocorra novamente.
Mas caso não seja viável a reinstalação e queira forçar o move do home do Grid mesmo com o grupo do OSOPER diferente, isso é possível, desde que o grupo que está definido no binário seja um grupo válido para o usuário “grid owner” no SO (o grupo deve aparecer no resultado do nome “id”):
Ao invés de usar o -switchGiHome do gridSetup.sh, repita as etapas abaixo para cada node do Oracle RAC:
export OLD_GIHOME=/u01/app/19.0.0/GI1922 export NEW_GIHOME=/u01/app/19.0.0/GI1923 export LD_LIBRARY_PATH=$NEW_GIHOME/lib:$LD_LIBRARY_PATH $NEW_GIHOME/crs/install/rootcrs.sh -prepatch -dstcrshome $NEW_GIHOME $NEW_GIHOME/rdbms/install/rootadd_rdbms.sh $NEW_GIHOME/crs/install/rootcrs.sh -postpatch -dstcrshome $NEW_GIHOME
Para Oracle Restart esse já seria o método normal de mover o Grid para o novo GI Home, então ele não deve apresentar a mensagem de erro por conta da diferença do grupo.