Upgrade Oracle Clusterware versión 10gR2 a 11gR2

Por Francisco Riccio
Publicado en marzo 2012

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:

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.

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:

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:

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:

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.

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.

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.

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.

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

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é.

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.

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.