Archivo de la etiqueta: opatchauto

El RAC se queda en estado [ROLLING PATCH]

Posted on por
Responder

Hoy vamos a ver una entrada sobre ago que puede dar mucho miedo pero que tiene una solucion muy sencila
Pongamos que tras aplicar una serie de parches comprobamos la version de nuesrto softare en el RAC y nos encontramos lo siguiente

[oracle@rac1~]$ sudo  $ORACLE_HOME/bin/crsctl query  crs  activeversion -f
Oracle Clusterware active version on the cluster is [19.0.0.0.0]. The cluster upgrade state is [ROLLING PATCH]. The cluster active patch level is [724960844].

Oracle Clusterware patch level on node rac1is [2701864972].
[oracle@rac1~]$ sudo  $ORACLE_HOME/bin/crsctl query  crs  softwarepatch rac2
Oracle Clusterware patch level on node rac2 is [387459443].

De alguna manera que no alcanzamos a entender ( o igual si), tenemos que tras finalizar un parcheado los parches de los dos nodos son iguales.

Que hacemos ??

Veamos a ver cuales son los parches que tenemos instalados.
Lo primero que se nos viene a la cabeza es tirar del comando optch
Y ecejutamos un
$ORACLE_HOME/OPatch/opatch -lsinventory
o bien
$ORACLE_HOME/OPatch/opatch -lspatches
Pero, para nuestra desesperacion resulta que Opatch nos dice que hay los mismos parches instalados.
¿que hacemos ahora?

La solucon esta en patchgen

Vamos a ver realmente que es lo que tenemos instalado en los nodos.
Para ello usaremos en ambos nodos el comando
$ORACLE_HOME/bin/kfod op=patches

[oracle@rac1~]$  $ORACLE_HOME/bin/kfod op=patches
---------------
List of Patches
===============
30489227
30489632
30557433
30655595

[oracle@rac2~]$ $ORACLE_HOME/bin/kfod op=patches
---------------
List of Patches
===============
29517242
29517247
29585399
30489227
30489632
30557433
30655595

Como podemos ver, en el rac2 nos aparecen 3 parches que no tenemos en rac1.
El siguiente paso deberia de ser el buscar cuales son esos parches y decidir si los queremos aplicar donde no estan , o quitrlos de donde estan.
Dado que quitar un parche suele ser mas complicado que ponerlo , vamos ha hacer esta segunda opcion y a eliminar esos 3 parches de rac2.

Para ello,lo primero que tendremos que hacer es como usuario root

. oaenv
 $ORACLE_HOME/crs/install/rootcrs.sh -prepatch

Y tras esto, eliminaremos los parches con 

$ORACLE_HOME/bin/patchgen commit -rb 29517242 
$ORACLE_HOME/bin/patchgen commit -rb 29517247
$ORACLE_HOME/bin/patchgen commit -rb 29585399

Una vez eliminados, comprobamos d enuevo con kfod que tenemos solamente los parches deseados, y sera en ese momento cuando cerremos la operacion con (de nuevo como root)

 $ORACLE_HOME/crs/install/rootcrs.sh -postpatch

Tras esto solamente tenemos que comprobar que el estado del cluster es normal y que las versiones y parches son los correctos

[oracle@rac1~]$) crsctl query crs softwarepatch -all
Oracle Clusterware patch level on node rac1 is [2701864972].
[oracle@rac1~]$ crsctl query crs activeversion  -f
Oracle Clusterware active version on the cluster is [19.0.0.0.0]. The cluster upgrade state is [NORMAL]. The cluster active patch level is [2701864972].
[oracle@rac1~]$ crsctl query crs releasepatch
Oracle Clusterware release patch level is [2701864972] and the complete list of patches [30489227 30489632 30557433 30655595 ] have been applied on the local node. The release patch string is [19.6.0.0.0].
[oracle@rac2~]$ crsctl query crs releasepatch
Oracle Clusterware release patch level is [2701864972] and the complete list of patches [30489227 30489632 30557433 30655595 ] have been applied on the local node. The release patch string is [19.6.0.0.0].

Mas informacion como siempre en la documentacion de oracle

  • Troubleshooting OPatchAuto
  • KFOD, KFED, AMDU (Doc ID 1485597.1)
  • Note 1180491.1 – KFED Tool For Windows OS
  • Note 1346190.1 – KFED.PL for diagnosing – ORA-15036 ORA-15042 ORA-15020 ORA-15033
  • Note 1505005.1 – Where to find kfed utility before Oracle Grid Infrastructure is installed

Problemas con optachauto y resolucion de nombres (error code 238)

Posted on por
Responder

Hoy vamos a ver una entrada rápida

Recientemente me he encontrado con el error code 238 intentando llevar a cabo la aplicación de un parche con el optachauto.

Al intentar llevar a cabo el parcheado me devolvía el siguiente error:

root:$GRID_HOME/OPatch/opatchauto apply $PARCHES/26610308 
OPatchauto session is initiated at Sun Nov 18 15:56:14 2017 

Patch version not found


OPatchauto session completed atSun Nov 18 15:56:20 2017 
Time taken to complete the session 0 minute, 7 seconds 

opatchauto bootstrapping failed with error code 238.

La primera conclusion que debemos de sacar de esto. siempre hay que hacer el analize antes de la aplicacion, ya que de esa manera habríamos comprobado el error .

Tras mucho buscar en la web de soporte y abrir un caso con Oracle, encontramos el problema.

El fichero /etc/hosts de mi servidor tenia mas de dos entradas, supongamos que fuese algo similar a:


10.0.0.1  SERVER server server.dominio  server-vip.dominio

Si desde el sistema operativo preguntábamos por cualquiera de las 4 entradas, el servidor funcionaba correctamente.

Sin embargo, al cambiar esa linea por


10.0.0.1  server server.dominio
10.0.0.1  SERVER  SERVER.dominio 
10.0.0.1  serve-vip  server-vip.dominio

Todo volvió a funcionar a la perfeccion.

Un expediente X que nos sirve para recordar que no todo vale a la hora de solcitar las instalaciones a los equipos responsables de los sistemas operativos, las nuevas herramientas de gestion de los componentes de oracle (opatchauto,datapatch …) son muy potentes, pero no dejan de ser componentes externos a la base de datos que requieren de configuraciones correctas que, desgraciadamente no suelen estar tan documentadas como los prerrequisitos del GRID, RAC o Base de datos, por lo que siempre deberemos de velar por que los sistemas operativos donde se encuentran nuestros motores esten prefectametne configurados

Obtener los parches instalados en la base de datos /CBD

Posted on por
Responder

Hoy vamos a ver una entrada muy rápida saber como ver el nivel de parcheado de una máquina.

Con el nuevo modelo de datapatch y los pdb/cbd la propia base de datos /contenedor necesita saber en que nivel de parcheado se encuentra, para ello tenemos un nuevo conjunto de librerías en el paquete DBMS_QOPATCH que informan de los parches que se han aplicado en la base de datos.
En nuestro caso, vamos a ver la llamada dbms_qopatch.get_sqlpatch_status;

[oracle@TEST] $ sqlplus "/as sysdba"
SQL*Plus: Release 12.1.0.2.0 Production on Fri Jun 16 16:54:59 2017
SQL>  set serverout on
SQL> exec dbms_qopatch.get_sqlpatch_status;

Patch Id : 25171037
        Action : APPLY
        Action Time : 14-JUN-2017 23:09:33
        Description : DATABASE PATCH SET UPDATE 12.1.0.2.170418
        Logfile :
/u01/app/oracle/cfgtoollogs/sqlpatch/25171037/21099266/25171037_apply_SID_2017Jun14_23_09_20.log
        Status : SUCCESS
PL/SQL procedure successfully completed.

Aquí podemos ver como , a esta base de datos sele ha aplicado el PATCH SET UPDATE 12.1.0.2.170418
Pero puede darse el caso de que , se aplique un parche sobre la infraestructura, o sobre los binarios sin aplicarse sobre el motor.

IMPORTANTE

Así pues recordar que , ahora, deberemos de mirar

  • Opatch lsinventory para ver el nivel de parcheado del motor
  • bms_qopatch.get_sqlpatch_status Para ver los parches aplicados sobre tu cbd o base de datos

Informacion en el arranque

“Dumping current patch information” in Alert Log 12c can lead to a misinterpretation