21 Mar Actualizar Clusterware de 11.2.0.2 a 11.2.0.3 en RHEL 5
Hace poco tuve que hacer una actualización de 11.2.0.2 a 11.2.0.3. Aquí te presento la primera parte que es la que contempla lo que es el Clusterware.
De aquí en adelante voy hacer las siguientes suposiciones:
GI_HOME.- Es la locación donde se encuentra el software de Oracle Clusterware
RDBMS_HOME.- Es la locación donde se encuentra el software del RDBMS de Oracle
OCR.- Oracle Cluster Registry
De igual manera también estoy suponiendo que tienes roles separados , el usuario oracle es el dueño del RDBMS y el usuario grid es el dueño del Clusterware.
Por ultimo, si el titulo tiene un asterisco marcado en rojo (*) , esto lo tienes que hacer en cada nodo.
Como el usuario root crea una variable de ambiente, que contenga tu GI_HOME, así como el ORACLE_SID de la instancia de ASM, ya que vamos a estar saliendo y entrando a este ambiente, lo veo mas sencillo que cada vez tener que definirlas.
Respaldar tu OCR
Lo primero que hay que hacer es tener en plan de respaldo en caso de que algo salga mal, así que como el usuario root corre la utilería de ocrconfig para respaldar manualmente tu OCR, y aunque en 11g el OCR se respalda automáticamente, soy un poco paranoico 🙂
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle/bin
oracle $ su -
[root@servidor1 ~]# . /home/grid/bin/ASM
root@servidor1.oracleenespanol.blogspot.com /root
root $ ocrconfig -manualbackup
servidor1 2012/03/16 01:17:22 /mount/oracle/grid/11.2.0.2/cdata/orclespdev1/backup_20120316_011722.ocr
La opción -showbackup te lista los respaldos de OCR que tienes.
Respaldar el GI_HOME
Como el usuario root vamos hacer un archivo tar de nuestro GI_HOME en una locación donde podemos asegurar que nuestros respaldos van a estar asegurados
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle/bin
oracle $ su -
[root@servidor1 ~]# . /home/grid/bin/grid
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ cd $ORACLE_HOME
grid@servidor1.oracleenespanol.blogspot.com /mount/oracle/grid/11.2.0.2
root $ tar -cvf /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/GI_OH_11.2.0.2_SERV1.tar .
Descomprimir el Software del Clusterware 11.2.0.3 (*)
Como el usuario grid vamos a descomprimir el archivo 3 del Software 11.2.0.3 descargado de MOS, que lo puedes encontrar como el parche 10404530.
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle/bin
oracle $ su -grid
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ cd /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/
grid@servidor1.oracleenespanol.blogspot.com /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3
root $ unzip p10404530_112030_Linux-x86-64_3of7.zip
Si tienes ACFS verificar que este habilitados los mounts (*)
Esto es únicamente si estas manejando ACFS, verifica que estén habilitados los mounts para la actualización, si no lo están habilitalos con el comando asmcmd volenable -a
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle/bin
oracle $ su –grid
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ asmcmd volinfo -a
Diskgroup Name: ASM_COPY1
Volume Name: ACFS_COPY1
Volume Device: /dev/asm/acfs_copy1-299
State: ENABLED
Size (MB): 1913856
Resize Unit (MB): 256
Redundancy: UNPROT
Stripe Columns: 4
Stripe Width (K): 128
Usage: ACFS
Mountpath: /mount/acfsdevesp1/copy01
Preparando para instalar el Parche 6880880 y 12539000 (*)
Uno de los prerequisitos para la actualización del clusterware a 11.2.0.3 es que por lo menos tenga el PSU1 y el parche 12539000 este instalado en el GI_HOME. Como estamos en Marzo del 2012, supongo que ya tienes instalado el PSU1, así que nada mas me voy a concentrar en el 12539000.
Necesitas descargar de MOS los siguientes parches:
12539000.-11203:ASM UPGRADE FAILED ON FIRST NODE WITH ORA-03113
6880880.- El ultimo opatch
Como el usuario oracle, deten los servicios que esten relacionados con el GI_HOME y el RDBMS_HOME que vas a parchar, si tienes una base de datos que no esta usando el GI_HOME o el RDBMS_HOME, no lo tienes que detener. Esto lo vas hacer cada vez que vas a correr la utileria opatch, asi permites que los servicios esten arriba en el segundo nodo, mientras parchas el primero, y viceversa
oracle@servidor1.oracleenespanol.blogspot.com /home/bin
root $ srvctl stop home -o $ORACLE_HOME -n servidor1.oracleenespanol.blogspot.com
Descomprime el parche 6880880 en el $GI_HOME y en el $RDBMS_HOME de cada nodo, asegurate antes de descomprimirlos, de mover o borrar el directorio $GI_HOME/OPatch y $RDBMS_HOME/OPatch. Un ejemplo de como hacerlo esta aquí:
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3
oracle $ scp p6880880_112000_Linux-x86-64.zip $ORACLE_HOME
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3
oracle $ cd $ORACLE_HOME
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/oracle/product/11.2.0.2v3
oracle $ mv OPatch OPatch.Antes.Parche.Mar2012
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/oracle/product/11.2.0.2v3
oracle $ unzip p6880880_112000_Linux-x86-64.zip
Como el usuario grid tengo que crear el archivo de respuesta para ocm, esto es necesario, ya que a la mitad de estar aplicando el parche, te va a solicitar la ruta de este archivo. Este archivo se genera en la ruta donde corriste la utileria emocmrsp, en este caso fue en $GI_HOME/OPatch/ocm/bin
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle/bin
oracle $ su –gridgrid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ cd $GI_HOME/OPatch/ocm/bin
grid@servidor1.oracleenespanol.blogspot.com /mount/oracle/grid/11.2.0.2OPatch/ocm/bin
root $ ./emocmrsp
Email address/User Name: micorreo_con_que_acceso_metalink@oracleenespanol.blogspot.com
Provide your My Oracle Support password to receive security updates via your My Oracle Support account.
Password (optional):
If you do not wish to configure OCM through an Oracle Support Hub, enter NONE
Oracle Support Hub URL: NONE
If you want to remain uninformed of critical security issues in your
configuration, enter NONE
Proxy specification: NONE
The OCM configuration response file (ocm.rsp) was successfully created.
Como el usuario root asegurate que la ruta del OPatch se encuentre en la variable PATH
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle/bin
oracle $ su -
[root@servidor1 ~]# . /home/grid/bin/gridroot@servidor1.oracleenespanol.blogspot.com /root
root $ export GI_HOME=/mount/oracle/grid/11.2.0.2
root@servidor1.oracleenespanol.blogspot.com /root
root $ export PATH=$PATH:$GI_HOME/OPatch
El parche 12539000 tiene que estar descomprimido en un directorio vacío , no debe de contener ningún otro parche o software, ya que la manera en que se va a aplicar es de manera automática y fallaría y/o te puede causar muchos mas problemas.
En este caso lo descomprimí en un directorio llamado stage_dir
root@servidor1.oracleenespanol.blogspot.com /home/grid/bin
root $ cd /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/stage_dir
root@servidor1.oracleenespanol.blogspot.com /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/stage_dir
root $ unzip p12539000_112023_Linux-x86-64.zip
Archive: p12539000_112023_Linux-x86-64.zip
creating: 12539000/
creating: 12539000/files/
creating: 12539000/files/lib/
creating: 12539000/files/lib/libserver11.a/
inflating: 12539000/files/lib/libserver11.a/ksxp.o
creating: 12539000/etc/
creating: 12539000/etc/config/
inflating: 12539000/etc/config/inventory.xml
inflating: 12539000/etc/config/actions.xml
inflating: 12539000/etc/config/deploy.xml
creating: 12539000/etc/xml/
inflating: 12539000/etc/xml/GenericActions.xml
inflating: 12539000/etc/xml/ShiphomeDirectoryStructure.xml
inflating: 12539000/README.txt
root@servidor1.oracleenespanol.blogspot.com /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/stage_dir
root $ chown -R root:oinstall 12539000
root@servidor1.oracleenespanol.blogspot.com /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/stage_dir
root $ chmod -R g+r 12539000
root@servidor1.oracleenespanol.blogspot.com /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/stage_dir
root $ which opatch
/mount/oracle/grid/11.2.0.2/OPatch/opatch
Aplicando el parche 12539000 a tu GI_HOME
Este parche se le llama polling patch, asi que lo vas a aplicar en el primer nodo, esperar a que el Clusterware se reinicie y luego vas a aplicarlo en el segundo nodo, acuerdate que sigues con el usuario root y que en el directorio stage_dir unicamente se encuentra descomprimido el parche 12539000.
Cuando el parche te solicite la ruta de tu ocm.rsp, fue el que creamos arriba: $GI_HOME/OPatch/ocm/bin/ocm.rsp
Cuando el parche te haga la siguiente pregunta, teclea ‘yes’ sin las comillas.
Enter ‘yes’ if you have unzipped this patch to an empty directory to proceed (yes/no):yes
root@servidor1.oracleenespanol.blogspot.com /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/stage_dir
root $ opatch auto /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/stage_dir -oh /mount/oracle/grid/11.2.0.2
Una vez que el primer nodo termine, haz lo mismo en el segundo nodo.
root@servidor2.oracleenespanol.blogspot.com /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/stage_dir
root $ opatch auto /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/stage_dir -oh /mount/oracle/grid/11.2.0.2
Aplicando el parche 12539000 a tu RDBMS_HOME
De igual manera que aplicamos el parche para el GI_HOME, vamos a aplicar el parche para el RDBMS_HOME, nos va solicitar el mismo archivo de ocm.rsp y nos va ha hacer la misma pregunta, y de igual manera seguimos como el usuario root.
root@servidor1.oracleenespanol.blogspot.com /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/stage_dir
root $ opatch auto /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/stage_dir -oh /mount/oracle/product/11.2.0.2v3
Una vez que termine el primer nodo , haz lo mismo en el segundo nodo, acuerdate que una vez que termine el primer nodo puedes subir los servicios en este y tienes que bajar los servicios relacionados con el RDBMS_HOME en el segundo nodo.
root@servidor2.oracleenespanol.blogspot.com /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/stage_dir
root $ opatch auto /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/stage_dir -oh /mount/oracle/product/11.2.0.2v3
Aplicar el parche 11.2.0.3 a tu Clusterware
Una vez que aplicamos el parche 12539000, estamos listos para actualizar el clusterware. Lo primero que tenemos que hacer es crear el directorio donde va residir nuestro 11.2.0.3 GI_HOME, esto lo vas a hacer en cada nodo
root@servidor1.oracleenespanol.blogspot.com /root
root $ mkdir -p /mount/oracle/grid/11.2.0.3
root@servidor1.oracleenespanol.blogspot.com /root
root $ chown grid:oinstall /mount/oracle/grid/11.2.0.3
Vamos a correr como el usuario grid la utileria runcluvfy.sh, cualquier error o conflicto que resulte de correr esta utileria, la tienes que resolver antes de actualizar a 11.2.0.3.
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle/bin
oracle $ su –grid
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ cd /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/grid
grid@servidor1.oracleenespanol.blogspot.com /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/grid
root $ ./runcluvfy.sh stage -pre crsinst -upgrade -n all -rolling -src_crshome /mount/oracle/grid/11.2.0.2 -dest_crshome /mount/oracle/grid/11.2.0.3 -dest_version 11.2.0.3.0 -fixup -fixupdir /home/grid/bin/fixup –verbose
Hasta ahora todo lo había hecho desde una sesión de putty de ssh, pero para la siguiente parte, me voy a conectar a una sesión de vnc con el usuario grid.
Si no sabes como arrancar este servicio, aquí una entrada anterior de como arrancar tus servicios de vnc
Lo que voy a hacer es quitar de mi ambiente las siguientes variables
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ unset ORACLE_SID
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ unset DB_NAME
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ unset ORACLE_HOME
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ unset ORACLE_UNQNAME
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ unset ORACLE_BASE
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ unset ORA_NLS10
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ export LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib
Una vez que quitamos la variables mencionadas, ya nada mas nos queda correr el runInstaller
grid@servidor1.oracleenespanol.blogspot.com /mount/dump01/oracle/TEMP_FOR_UPGR_11.2.0.3/grid
root $ ./runInstaller
En mi caso, que no necesariamente tiene que ser tu caso, seleccione las siguientes opciones en cada pantalla que me fue apareciendo, asegurate que la respuesta que des, corresponda a lo que andes buscando o necesitando.
|
Pantalla
|
Respuesta
|
|
Download Software Updates
|
‘Skip software updates’
|
|
Select Installation Option
|
‘Upgrade Oracle Grid Infrastructure or Oracle Automatic Storage Management’
|
|
Select Product Languages
|
‘English’; ‘Next’
|
|
Grid Infrastructure Node Selection
|
‘servidor1’, ‘servidor2’; ‘Next’
|
|
Privileged Operating System Groups
|
‘asmdba’,’asmoper’,’asmadmin’;‘Next’
|
|
Specify Installation Location
|
ORACLE_BASE:/mount/oracle/gridbase
GI_HOME:/mount/oracle/grid/11.2.0.3
|
|
Summary
|
‘Next’
|
Una vez que este corriendo el proceso de actualización, te va a solicitar que corras el script rootupgrade.sh.
Así que tienes que abrir una sesión aparte con el usuario root, esta parte es la que va actualizar a ASM y tu OCR a 11.2.0.3 así que va a bajar los servicios todos los servicios de ASM e igualmente los va reiniciar.
Cuando termine el script en el primer nodo, tienes que correrlo en el siguiente nodo, no lo vayas a correr a la misma vez en todos tus nodos, es de uno en uno.
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle/bin
oracle $ su -
[root@servidor1 ~]# /mount/oracle/grid/11.2.0.3/rootupgrade.sh
El OCR no se actualiza hasta que llegues a correr el rootupgrade.sh en el ultimo nodo, así que básicamente no estas en 11.2.0.3 hasta que haya corrido en el ultimo nodo.
Ya para verificar, corre los siguientes comandos
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle/bin
oracle $ su -grid
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ sqlplus "/as sysasm"
+ASM1 > select version from v$instance;
VERSION
-----------------
11.2.0.3.0
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ crsctl query crs activeversion
Oracle Clusterware active version on the cluster is [11.2.0.3.0]
Desintalar el GI_HOME de 11.2.0.2 (*)
Ya por ultimo lo que nos falta el desintalar el GI_HOME de 11.2.0.2 , asiq ue como el usuario root , vamos a cambiar los permisos de GI_HOME 11.2.0.2
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle/bin
oracle $ su -
[root@servidor1 ~]# . /home/grid/bin/grid
root@servidor1.oracleenespanol.blogspot.com /root
root $ chmod -R 755 /mount/oracle/grid/11.2.0.2
root@servidor1.oracleenespanol.blogspot.com /root
root $ chown -R grid /mount/oracle/grid/11.2.0.2
root@servidor1.oracleenespanol.blogspot.com /root
root $ chown grid /mount/oracle/grid/11.2.0.2
Como el usuario grid vamos a correr deinstall, asegurate que ninguna variable como ORACLE_HOME o GI_HOME, apunte a tu versión de 11.2.0.3
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle/bin
oracle $ su -grid
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ unset ORACLE_SID
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ unset DB_NAME
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ unset ORACLE_HOME
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ unset ORACLE_UNQNAME
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ unset ORACLE_BASE
grid@servidor1.oracleenespanol.blogspot.com /home/grid
root $ export ORACLE_HOME=/mount/oracle/grid/11.2.0.2
grid@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/grid
root $ cd /mount/oracle/grid/11.2.0.2
grid@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/oracle/grid/11.2.0.2
root $ ./deinstall
Conclusión
Hasta aquí acabamos con la primera parte, que es el Clusterware, en la siguiente entrada, vamos a ver el RDBMS_HOME a 11.2.0.3
Sorry, the comment form is closed at this time.