Upgrade do Oracle Grid Infrastructure (GRID) 11.1.0.7 para 11.2.0.4 em ambiente Oracle Real Application Clusters (RAC)

Por Thiago Sgobe, Bruno Reis da Silva e Cleber Jose Campos Martins
Postado em Novembro 2016

Revisado por Marcelo Pivovar - Solution Architect

Este artigo focará nas atividades preparatórias e necessárias para o sucesso do upgrade de um Oracle Grid Infrastructure (GRID) versão 11.1.0.7 para 11.2.0.4 em plataforma IBM AIX 5.3.

Como qualquer alteração, o upgrade também requer cuidados básicos que garantam o reestabelecimento do ambiente a partir de qualquer ponto de falha.

Para garantir isso são necessários alguns backups:

  • Backup dos binários da versão 11.1 (binários do  GRID e  ASM)
  • Backup do voting disk

Com isso, o upgrade do cluster pode ser dividido em 3 etapas:

  1. Pré-requisitos
  2. Instalação do novo binário do GRID (runInstaller)
  3. Execução do script rootupgrade.sh em cada nó do cluster

1. Pré-requisitos

a. Validação das versões e patchs necessários.

- Verifique as restrições para a realização do upgrade para 11.2. Algumas dessas restrições são que a versão atual do GRID deve ser maior ou igual a 10.1.0.5, 10.2.0.3, 11.1.0.6 ou 11.2. No caso deste artigo estaremos trabalhando na versão 11.1.0.7.

- É importante ressaltar que para upgrade iniciando-se na versão 11.2.0.2, devemos aplicar o patch 11.2.0.2.1 (11.2.0.2 PSU 1) ou maior,  porém não é caso do artigo em questão.

- Aplicar o patch para o bug "11724953" no binário 11.1 antes do upgrade.


b. Verificação e correção do arquivo rootconfig.

Na versão atual do cluster obtenha as seguintes informações de configuração atual:

  • ocr
  • voting disk
  • Vip

Verificar se as informacões de OCR, VOLTEDISK e VIP estão corretas no início do arquivo rootconfig , que é  encontrado no binário antigo (11.1.0.7) ,  no diretório $ORA_CRS_HOME/install. Caso não estejam corretas, pode se efetuar um backup do arquivo e alterar com as informações corretas.

Segue exemplo de alterações que foram necessárias durante esta execução:

Trecho inicial do arquivo rootconfig original que fora analisado durante a execução. Verificado que os nomes dos OCR's dos nodes atuais do cluster estavam desatualizados:

SILENT=false 
ORA_CRS_HOME=/oracle/product/CRS/11.1.0 
CRS_ORACLE_OWNER=oracle 
CRS_DBA_GROUP=oinstall 
CRS_VNDR_CLUSTER=false 
CRS_OCR_LOCATIONS=/dev/ocrdisk1,/dev/ocrdisk2 
CRS_CLUSTER_NAME=crs 
CRS_HOST_NAME_LIST=open2kg10,1,open2kg20,2,open2kg30,3 
CRS_NODE_NAME_LIST=open2kg10,1,open2kg20,2,open2kg30,3 
CRS_PRIVATE_NAME_LIST=open2kg10_priv,1,open2kg20_priv,2,open2kg30_priv,3 
CRS_LANGUAGE_ID='AMERICAN_AMERICA.WE8ISO8859P1' 
CRS_VOTING_DISKS=/dev/votedisk01,/dev/votedisk02,/dev/votedisk03 
CRS_NODELIST=open2kg10,open2kg20,open2kg30 
CRS_NODEVIPS='open2kg10/open2kg10_vip,open2kg20/open2kg20_vip,open2kg30/open2kg30_vip' 
 

Segue abaixo trecho inicial do rootconfig com as correções já efetuadas nos nomes do OCR e dos nodes atuais do cluster:

SILENT=false 
ORA_CRS_HOME=/oracle/product/CRS/11.1.0 
CRS_ORACLE_OWNER=oracle 
CRS_DBA_GROUP=oinstall 
CRS_VNDR_CLUSTER=false 
CRS_OCR_LOCATIONS=/dev/ocrdisk01,/dev/ocrdisk02 
CRS_CLUSTER_NAME=crs 
CRS_HOST_NAME_LIST=open2kg10,1,open2kg20,2 
CRS_NODE_NAME_LIST=open2kg10,1,open2kg20,2 
CRS_PRIVATE_NAME_LIST=open2kg10_priv,1,open2kg20_priv,2 
CRS_LANGUAGE_ID='AMERICAN_AMERICA.WE8ISO8859P1' 
CRS_VOTING_DISKS=/dev/votedisk01,/dev/votedisk02,/dev/votedisk03 
CRS_NODELIST=open2kg10,open2kg20 
CRS_NODEVIPS='open2kg10/open2kg10_vip,open2kg20/open2kg20_vip' 
 

c. Pré-requisitos para a instalação da nova versão do GRID

Verifique a lista completa de pré-requisitos para a instalação da versão 11.2 na documentação oficial da Corporação Oracle, ressaltando principalmente a verificação de todos os itens que diferenciam a versão 11.1 da versão 11.2 . Como, por exemplo, a existência de um único binário para o Automatic Storage Management (ASM) ,  Cluster, IP Scan e demais configurações.

Segue abaixo a relação de alguns pré-requisitos básicos:

  • Necessidade de haver mais de 1 giga livre de espaço no diretório /tmp de todos os nodes.
  • Criar o filesystem para o Oracle Grid Infrastructure (GRID) em todos os nodes com no mínimo 16 gigas, sendo 6.6 gigas para os binários do GRID e 10 gigas para arquivos de traces e logs.
  • Configurações de rede (IP SCAN, DNS...)
  • Configuração do arquivo de hosts (/etc/hosts)
  • Assegure que os arquivos bpf* localizados no diretório /dev/ existem nos servidores. Caso estes arquivos não forem encontrados, execute o seguinte comando para criação destes dispositivos:
    /usr/sbin/tcpdump -D

 

Segue a listagem que confirme que os arquivos foram criados:

[oracle@open2kg10:/dev]ls -ltr bpf*
cr--------   1 root   system      36, 3 Mar 06 2013 bpf3
cr--------   1 root   system      36, 2 Mar 06 2013 bpf2
cr--------   1 root   system      36, 1 Mar 06 2013 bpf1
cr--------   1 root    system      36, 0 Mar 06 2013 bpf0

 

A existência dos arquivos bpf*, irá previnir que aconteça mensagens de erro conforme estas a seguir:

Start of resource "ora.cluster_interconnect.haip" failed
CRS-2672: Attempting to start 'ora.cluster_interconnect.haip' on 'open2kg20'
CRS-5017: The resource action "ora.cluster_interconnect.haip start" encountered the following error:
Start action for HAIP aborted. For details refer to "(:CLSN00107:)" 
in "/oracle/11.2.0/grid/log/ open2kg20 /agent/ohasd/ora rootagent_root//orarootagent_root.log".
CRS-2674: Start of 'ora.cluster_interconnect.haip' on ' open2kg20' failed
CRS-2679: Attempting to clean 'ora.cluster_interconnect.haip' on 'open2kg20'
CRS-2681: Clean of 'ora.cluster_interconnect.haip' on ' open2kg20' succeeded

 

d. Após isso, execute o script runcluvfy.sh para validar os pre-réquisitos de instalação.

Este script encontra-se no diretório grid que é criado quando descompactamos os binários para instalação do GRID (mesmo diretório do runInstaller).

Com isso, segue a sintaxe:

runcluvfy.sh stage -pre crsinst -upgrade [-n node_list] [-rolling] -src_crshome src_Gridhome -dest_crshome dest_Gridhome -dest_version dest_version [-fixup [-fixupdir path]] [-verbose]

Exporte a variável CV_ASSUME_CL_VERSION para que o runcluvfy.sh execute e verifique a sintax dos comandos usando a versão 11.2 conforme abaixo:

export CV_ASSUME_CL_VERSION=11.2
./runcluvfy.sh stage -pre crsinst -upgrade -n open2kg10,open2kg20 -rolling -src_crshome /oracle/product/CRS/11.1.0 
-dest_crshome /oracle/product/grid/11.2.0.4 -dest_version 11.2.0.4.0 -fixup -fixupdir /home2/lm/dba/install -verbose
 

O resultado do runcluvfy.sh deve ser analisado e esclarecido caso ocorra alguma falha. Se necessário abra uma Service Request no My Oracle Support da Oracle.

Entre muitas outras verificações, o runcluvrfy.sh verifica o permissionamento dos arquivos OCR e VOTE em todos os nodes, configurações de rede, parâmetros de sistema operacional, resolução de nomes, equivalência de usuários, conectividade entre os nodes, memória swap, memória física, espaço em discos e diretórios, existência do patch "11724953" em cada node, falta de pacotes de sistemas operacionais e outros.

Outro detalhe importante é executar o runcluvfy.sh em todos os nodes, pois o script pode ter dificuldade na execução de algum comando remotamente e reportar falha em algum item, não representando a veracidade das informações. Como por exemplo, situações em que executando o script a partir do node 1 acusa falta do patch "11724953" somente no node 2 , e executando a partir do node 2 acusa falta do patch "11724953" somente no node 1.

Dependendo dos parâmetros passados, o runcluvfy.sh pode solicitar a execução do arquivo runfixup.sh para corrigir algum item e indicará como deve ser executado.

Sendo assim, a seguir é apresentado  exemplos de problemas apontados pelo runcluvfy.sh:

ERROR:
PRVF-4172 : Check of OCR device "/dev/ocrdisk02" for sharedness failed
Could not find the storage
OCR integrity check failed
Check: Membership of user "oracle" in group "oinstall" [as Primary]
Node Name User Exists Group Exists User in Group Primary Status
---------------- ------------ ------------ ------------ ------------ ------------
open2kg10 yes yes yes no failed
open2kg20 yes yes yes no failed
open2kg30 yes yes yes no failed
Check: Kernel parameter for "tcp_ephemeral_low"
Node Name Current Required Status
------------ ------------------------ ------------------------ ----------
open2kg20 32768 9000 failed (ignorable)
open2kg10 32768 9000 failed (ignorable)
open2kg30 32768 9000 failed (ignorable)
Result: Kernel parameter check failed for "tcp_ephemeral_low"
Check: Kernel parameter for "tcp_ephemeral_high"
Node Name Current Required Status
------------ ------------------------ ------------------------ ----------
open2kg20 65535 65500 failed (ignorable)
open2kg10 65535 65500 failed (ignorable)
open2kg30 65535 65500 failed (ignorable)
Result: Kernel parameter check failed for "tcp_ephemeral_high"
PRVF-5605 : File "/etc/resolv.conf" does not exist on following nodes: open2kg20
Checking the file "/etc/resolv.conf" to make sure only one of domain and search entries is defined
File "/etc/resolv.conf" does not have both domain and search entries defined
Checking if domain entry in file "/etc/resolv.conf" is consistent across the nodes...
domain entry in file "/etc/resolv.conf" is consistent across nodes
Checking file "/etc/resolv.conf" to make sure that only one domain entry is defined
All nodes have one domain entry defined in file "/etc/resolv.conf"
Checking all nodes to make sure that domain is "leroy.ibm" as found on node "open2kg10"
All nodes of the cluster have same value for 'domain'
Checking if search entry in file "/etc/resolv.conf" is consistent across the nodes...
search entry in file "/etc/resolv.conf" is consistent across nodes
Checking DNS response time for an unreachable node
Node Name Status
------------------------------------ ------------------------
open2kg20 passed
open2kg10 passed
open2kg30 passed
The DNS response time for an unreachable node is within acceptable limit on all nodes

 

2. Instalação do novo binário do GRID (runInstaller)

Após todos as atividades de pré-requisitos, planeje suas atividades para a execução do upgrade.

A execução do runInstaller fará a instalação do novo binário do GRID. No entanto, antes de executar o mesmo é necessário fazer o UNSET das variáveis abaixo:

ORA_CRS_HOME; ORACLE_HOME; ORA_NLS10; TNS_ADMIN;

 

Execute o runInstaller até o Step  11 onde será solicitado a execução do script rootupgrade.sh em todos os nodes com o usuário root, como apresentado na imagem a seguir:

Upgrade GRID para RAC

3. Execução do script rootupgrade.sh

Neste momento, antes de executar o rootupgrade.sh você deve aplicar o último PSU para GRID para a versão que está sendo instalada seguindo as instruções da nota Doc ID 1410202.1, com o intuito de  evitar problemas conhecidos como os apresentados a seguir:

    • Known Issues: Grid Infrastructure Redundant Interconnect and ora.cluster_interconnect.haip (Doc ID 1640865.1)
    • 11.2.0.4 Grid Infrastructure Patch Set Updates - List of Fixes in each GI PSU (Doc ID 1614046.1)
    • AIX HAIP: failed to create arp - operation: open, loc: bpfopen:1,os, OS error: 2 (Doc ID 2059802.1)

a. Execução do rootupgrade.sh em cada nó do cluster

Execute o script um node por vez. É importante não executar em paralelo em outros nodes enquanto não for finalizado com sucesso a execução no node anterior.

Com isso, segue exemplo de execução com sucesso:

root@open2kg10:/oracle/product/grid/11.2.0.4 # ./rootupgrade.sh
Performing root user operation for Oracle 11g
The following environment variables are set as:
ORACLE_OWNER= oracle
ORACLE_HOME= /oracle/product/grid/11.2.0.4
Enter the full pathname of the local bin directory: [/usr/local/bin]:
The file "dbhome" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: y
Copying dbhome to /usr/local/bin ...
The file "oraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: y
Copying oraenv to /usr/local/bin ...
The file "coraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: y
Copying coraenv to /usr/local/bin ...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Using configuration parameter file: /oracle/product/grid/11.2.0.4/crs/install/crsconfig_params
Creating trace directory
User ignored Prerequisites during installation
Installing Trace File Analyzer
User oracle has the required capabilities to run CSSD in realtime mode
OLR initialization - successful
root wallet
root wallet cert
root cert export
peer wallet
profile reader wallet
pa wallet
peer wallet keys
pa wallet keys
peer cert request
pa cert request
peer cert
pa cert
peer root cert TP
profile reader root cert TP
pa root cert TP
peer pa cert TP
pa peer cert TP
profile reader pa cert TP
profile reader peer cert TP
peer user cert
pa user cert
Replacing Clusterware entries in inittab
clscfg: EXISTING configuration version 4 detected.
clscfg: version 4 is 11 Release 1.
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'system'..
Operation successful.
Configure Oracle Grid Infrastructure for a Cluster ... succeeded

 

Exemplo de rootupgrade com falha na execução:

root@open2kg20:/oracle/11.2.0/grid # rootupgrade.sh
Performing root user operation for Oracle 11g
The following environment variables are set as:
ORACLE_OWNER= oracle
ORACLE_HOME= /oracle/11.2.0/grid
Enter the full pathname of the local bin directory: [/usr/local/bin]:
The file "dbhome" already exists in /usr/local/bin. Overwrite it? (y/n) [n]:
The file "oraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]:
The file "coraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]:
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Using configuration parameter file: /oracle/11.2.0/grid/crs/install/crsconfig_params
Creating trace directory
User ignored Prerequisites during installation
Installing Trace File Analyzer
User oracle has the required capabilities to run CSSD in realtime mode
OLR initialization - successful
root wallet
root wallet cert
root cert export
peer wallet
profile reader wallet
pa wallet
peer wallet keys
pa wallet keys
peer cert request
pa cert request
peer cert
pa cert
peer root cert TP
profile reader root cert TP
pa root cert TP
peer pa cert TP
pa peer cert TP
profile reader pa cert TP
profile reader peer cert TP
peer user cert
pa user cert
Replacing Clusterware entries in inittab
Start of resource "ora.cluster_interconnect.haip" failed
CRS-2672: Attempting to start 'ora.cluster_interconnect.haip' on 'open2kg20'
CRS-5017: The resource action "ora.cluster_interconnect.haip start" encountered the following error:
Start action for HAIP aborted. 
For details refer to "(:CLSN00107:)" 
in "/oracle/11.2.0/grid/log/open2kg20/agent/ohasd/orarootagent_root/orarootagent_root.log".
CRS-2674: Start of 'ora.cluster_interconnect.haip' on 'open2kg20' failed
CRS-2679: Attempting to clean 'ora.cluster_interconnect.haip' on 'open2kg20'
CRS-2681: Clean of 'ora.cluster_interconnect.haip' on 'open2kg20' succeeded
CRS-4000: Command Start failed, or completed with errors.
clscfg: EXISTING configuration version 4 detected.
clscfg: version 4 is 11 Release 1.
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'system'..
Operation successful.
Configure Oracle Grid Infrastructure for a Cluster ... succeeded

 

Assim como apresentado no exemplo anterior, caso haja alguma falha durante a execução do script rootpupgrade que consiga ser remediado no momento, o script pode ser reexecutado.

No entanto, caso a execução termine com sucesso, é possível checar a versão nova ativa com o comando apresentado abaixo:

crsctl query crs activeversion

 

CONCLUSÃO:

É de suma importância manter o seu sistema na versão atualizada, evitando assim vulnerabilidades das versões anteriores. Como no artigo em questão, as vulnerabilidades apresentadas na release 11.1.0.7 foram corrigidas na versão 11.2.0.4. No entanto, para este tipo de atividade é fundamental um bom planejamento tomando nota de todos os problemas conhecidos no My Oracle Support (MOS) validando o procedimento e então atuar com maior segurança e assertividade em ambientes produtivos.


REFERÊNCIAS:

[1] Oracle Database (RDBMS) on Unix AIX,HP-UX,Linux,Mac OS X,Solaris,Tru64 Unix Operating Systems Installation and Configuration Requirements Quick Reference (8.0.5 to 11.2) (Doc ID 169706.1)

[2] How to Upgrade to Oracle Grid Infrastructure 11g Release 2 [https://docs.oracle.com/cd/E11882_01/install.112/e41961/procstop.htm#CWLIN417]

[3] How to Apply a Grid Infrastructure Patch Before root script (root.sh or rootupgrade.sh) is Executed? (Doc ID 1410202.1 )

[4] How to Validate Network and Name Resolution Setup for the Clusterware and RAC (Doc ID 1054902.1)

 


Thiago Sgobe é brasileiro, Bacharel em Ciencia da Computação, Administrador de banco de dados. Profissional certificado OCP 11g e 12c e OCE RAC 11g com experiência nas versões 9i a 12c, já tendo atuado em diversos clientes nacionais e internacionais. Atualmente é Advisory Oracle Database pela IBM Global Service Delivery Centre Polônia.

Bruno Reis da Silva é brasileiro, Cientista da Computação, Administrador de Banco de Dados Oracle/MySQL há mais de 5 anos e profissionalmente certificado em administração de banco de dados. Especialista em administração e infraestrutura de banco de dados com experiência na implementação e administração de ambientes de bancos de dados com Data Warehouse , Business Intelligence , segurança de banco de dados, perfomance tuning e alta disponiblidade . Já administrou os bancos de dados de grandes empresas brasileiras e internacionais. Também compartilha informações no seu blog techdatabasket.com.

Cleber Jose Campos Martins é brasileiro, Administrador de Banco de Dados Oracle há mais de 15 anos e profissionalmente certificado OCP para as versões 10g,11g e 12c e Oracle RAC 11g Release 2 and Grid Infrastructure Administration. Possui experiência profissional nas versões de 7 á 12c em empresas como IBM, Lojas Marisa e DPaschoal.

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.