PDF de programación - Upgrade Oracle Clusterware versión 10gR2 a 11gR2

Upgrade Oracle Clusterware versión 10gR2 a 11gR2



Por Francisco Riccio



Introducción

El objetivo de este artículo es presentar un correcto procedimiento de cómo realizar un
upgrade al componente Clusterware versión 10gR2 (10.2.0.5) a 11gR2 (11.2.0.3).

El escenario presentado está sobre una plataforma Oracle Enterprise Linux 5.7 de 32 bits.

Debemos considerar que el clusterware de la versión 11gR2 viene incluido en el software
Oracle Infraestructura Grid.



Requisitos previos al upgrade

a) El clusterware debe contar con una versión 10.1.0.5 (10gR1) o 10.2.0.3 (10gR2)

como mínimo. (Nota: Si estamos migrando un clusterware versión 11gR1 debemos
aplicar el parche correctivo al bug: 7308467 y si queremos migrar un clusterware
versión 11.2.0.2 debemos aplicarle el PSU 11.1.0.2.2.1).

Para validar la versión actual del clusterware debemos aplicar el siguiente
comando:

b) La salida de la ejecución del comando ocrcheck debe salir sin errores, ejemplo:







1

c) El parámetro diagwait del componente CSS del clusterware no debe estar seteado,
con la finalidad de evitar el issue documentado en My Oracle Support (MOS) Nota:
1102283.1 (11gR2 rootupgrade.sh Fails as cssvfupgd Can not Upgrade Voting
Disk). Recordar que este parámetro permite que el clusterware pueda capturar
mayor información adicional antes de un evitamiento de nodos, en la versión
11gR2 ya no es necesario su configuración.

Para validar si está seteado, debemos ejecutar el siguiente comando:

En caso esté seteado, adjunto los pasos para retirar el valor ingresado:



• crsctl stop crs (Bajamos los servicios del clusterware, ejecutar en ambos

nodos).

• ps -ef |egrep "crsd.bin|ocssd.bin|evmd.bin|oprocd" (Validamos si hay

servicios arriba del clusterware, ejecutar en ambos nodos).

• crsctl unset css diagwait -force (Retiramos el valor seteado, solo se ejecuta

en un nodo).

• crsctl get css diagwait (Comprobamos si ya se retiró el valor seteado).

• crsctl start crs (Subimos los servicios del clusterware, ejecutar en ambos

nodos).

d) La IP pública y privada del clusterware no deberían estar referenciadas a la red

169.254.*.* y ambas deben estar en diferentes subnets para evitar el issue
documentado en My Oracle Support (MOS) Nota: 1062682.1 (11gR2
rootupgrade.sh Failed as Wrong NIC was Selected for Private Network).

e) Debemos contar con un servidor DNS el cual resuelva el scan name (nuevo virtual

hostname que permite a los usuarios conectarse al cluster) mediante 3 IPs
(también trabaja con resolución a 1 IP, el cual no es recomendado) en modalidad
round robin. Desde la versión 11.2.0.2 ya no está soportado el uso de resolución
local mediante el archivo hosts.

Para validar la resolución del scan name debemos aplicar el comando nslookup en
cada nodo.



2



f) Debemos considerar un upgrade de tipo out-of-place; el cual significa que el

software del clusterware de la versión 11gR2 (Oracle Infraestructura Grid) tendrá
un directorio diferente de instalación respecto al clusterware versión 10gR2.

g) Debemos retirar (unset) los valores a las siguientes variables de ambiente del

sistema operativo antes de realizar el upgrade:

• unset ORACLE_BASE

• unset ORACLE_HOME

• unset ORACLE_SID

Si no ejecutamos este paso, tendremos un issue documentado en My Oracle
Support (MOS) Nota: 952925.1 (NETCA & ASMCA Fail during Upgrade of
CRS/ASM to Grid Infrastructure 11gR2).

h) Si estamos realizando un upgrade del clusterware hacia una versión 11.2.0.2

debemos considerar que el uid del usuario con el que se realizará la instalación
debe ser menor o igual a 6 dígitos, debido a un bug documentado en My Oracle
Support (MOS) Nota: 10379703.8 (Bug 10379703 - Grid install error if users Unix
UID over 6 digits long). Asimismo el proceso de upgrade debe ser realizado con el
mismo usuario con que se realizó la instalación del clusterware versión 10g.

i) Recomiendo crear el grupo asmadmin en el sistema operativo y asimismo asociar

el usuario con el que se ha instalado el clusterware al grupo nuevo. Ejemplo:

j) Debemos ejecutar el cluster verifier ubicado en la media del Oracle Infraestructura

Grid con la siguiente sintaxis:

runcluvfy.sh stage -pre crsinst -n nodo1,nodo2 -verbose

La salida del comando no debe devolver ningún error; en caso contrario debemos
ir solucionando los issues reportados. Algunos de estos issues pueden ser:

3





parámetros de sistema operativo no configurados correctamente, rpms faltantes,
etc.

Ejemplo, en mi escenario devolvió los siguientes mensajes de error:





Debemos conseguir el siguiente mensaje después de solucionar todos los errores
encontrados:



4

























Pasos del Upgrade

a) Corremos el ejecutable runInstaller que se encuentra en la media del Oracle

Infraestructura Grid.

b) Luego seleccionamos la opción: Upgrade Oracle Grid Infrastructure or Oracle

Automatic Storage Management.

c) Luego en la sección Node Selection, veremos que estarán seleccionados los

nodos participantes en el cluster y asimismo estará seleccionado la opción:
Upgrade Cluster Automatic Storage Management (Oracle ASM) por default, el cual
Oracle recomienda no cambiar las selecciones por default.

d) Si contamos con versiones de clusterware 11gR1 hacia abajo, conseguiremos el

siguiente mensaje:



5





Procedemos luego a dar clic al botón YES, por lo cual las instancias ASM de todos
los nodos serán bajadas y levantadas de forma automática y se encontrarán
disponibles durante todo el proceso de instalación hasta llegar a la última parte,
donde correremos un script llamado rootupgrade.sh; el cual reiniciará cada
instancia ASM en el nodo donde se ejecuta.

e) Luego seremos consultados por el scan name por el instalador.

















6

f) Es importante elegir una correcta selección para el rol: Oracle ASM Administrator.

g) Debemos recordar que el upgrade se realiza out-of-place.





























7

h) La siguiente pantalla reportará una inconsistencia en los discos del OCR.

Este mensaje es un bug reportado con el código 10024549; el detalle del bug se
encuentra en My Oracle Support (MOS) Nota: 1233505.1 (Checklist for PRVF-
10037 : Failed to retrieve storage type for xx on node xx). Acorde a la nota indica
que este mensaje debe ser ignorado y se proceda con el upgrade.

i) Luego tendremos que ejecutar el script rootupgrade.sh en cada nodo, el nodo

donde está ejecutándose el asistente de upgrade debe ser el primero y si
tuviéramos más nodos podemos correr el script en forma paralela posterior al
primero a excepción del último nodo listado el cual debe ser ejecutado al final.



8



Al correr el script en cada nodo tendremos el siguiente mensaje:





Una de las características considerables al correr el script en cada nodo es que la
versión aun no está activa:

Como se mencionó previamente, al ejecutar el script rootupgrade.sh la instancia
ASM es reiniciada de forma automática en el nodo donde se realiza la ejecución.

Al finalizar la ejecución del script en el último nodo, nosotros podemos apreciar
que el software de Infraestructura Grid ya está activado.









9

j) Al finalizar la instalación nosotros tendremos la siguiente pantalla de error:

Acorde a My Oracle Support (MOS) Nota: 1051763.1 (INS-20802 PRVF-4172
Reported after Successful Upgrade to 11gR2 Grid Infrastructure), indica que es un
bug con el código 8901969; el cual puede ser ignorado siempre y cuando no
existan otros mensajes de error.

k) Veremos a continuación la pantalla de finalización.

l) Por último debemos recompilar objetos inválidos en cada base de datos asociada

a la solución de cluster, podemos hacer uso del script @?/rdbms/admin/utlrp.sql

10







Validación

a) A continuación se presenta los recursos del clusterware versión 11.2.0.3, donde se

puede visualizar que existen 3 scan listeners debido a los 3 IPs que resuelven el
scan name y además que el servicio GSD se encuentra en offline debido a que en
mi implementación no lo habilité.

















11

b) Se puede validar que la versión de la instancia ASM es 11.2.0.3

También se puede validar que el diskgroup tiene el atributo de
database_compatibility en 10.1, por lo cual nuestra instancia rdbms que aún corre
en versión 10gR2 puede acceder al diskgroup listado.

La instancia de base de datos sigue con la versión 10.2.0.5.







Hasta aquí tenemos el sistema operando y sin problemas, luego podríamos realizar el
upgrade al motor de base de datos a la versión 11.2.0.3 en una ventana posterior o a
continuación del upgrade realizado previamente.





12

Publicado por Ing. Francisco Riccio. Es un IT Specialist en IBM Perú e instructor de
cursos oficiales de certificación Oracle. Está reconocido por Oracle como un Oracle ACE y
certificado en productos de Oracle Application & Base de Datos.

e-mail: [email protected]

web: www.friccio.com









13