Problemas con el fichero crsgenconfig_params al intentar extender un rac

Hoy vamos a ver un caso curioso .

En el proceso de añadir un nodo en el rac nos encontramos con el error

2021/02/10 20:14:04 CLSRSC-594: Executing installation step 4 of 19: 'GenSiteGUIDs'.
oracle.ops.mgmt.cluster.ClusterException: scp: /u01/app/19c/grid/crs/install/crsgenconfig_params: No such file or directory

2021/02/10 20:14:06 CLSRSC-180: An error occurred while executing the command '/u01/app/19c/grid/bin/cluutil -copy -sourcefile /u01/app/19c/grid/crs/install/crsgenconfig_params -fromnodesfile /tmp/7pqMR5nHtf -destfile /u01/app/19c/grid/crs/install/crsgenconfig_params -nodelist rac1'
2021/02/10 20:14:06 CLSRSC-571: failed to copy file '/u01/app/19c/grid/crs/install/crsgenconfig_params' from node 'rac2' to file '/u01/app/19c/grid/crs/install/crsgenconfig_params' on local node
Died at /u01/app/19c/grid/crs/install/crsutils.pm line 15809.

Afortunadamente el error es claro , nos falta el fichero /u01/app/19c/grid/crs/install/crsgenconfig_params del nodo del que estamos extendiendo el rac, lo que hace que falle el punto 4 de la ejecucion del root.sh
Si buscamos por internet veremos varias entradas en las que nos indican que es un problema en la descompresion de los paquetes originales, lo que no nos ayuda.
La ayda viene en la nota 12.2 GI Upgrade fails with : CLSRSC-635: Failed to get EXTENDED_CLUSTER_SITE_GUIDS (Doc ID 2259672.1)
En la que nos indican que solo hemos de poner el EXTENDED_CLUSTER_SITE_GUIDS en ese fichero y reejecutar el root.sh

La idea parece buena, pero … cual deberia de ser el contenido de ese fichero ?

El contenido de ese fichero es el siguiente

EXTENDED_CLUSTER_SITE_GUIDS=rac

Donde, el valor del campo EXTENDED_CLUSTER_SITE_GUIDS es el mismo que aparece en el campo CLUSTER_NAME del fichero /opt/app/19c/grid/crs/install/crsconfig_params

CLUSTER_TYPE=DB
VNDR_CLUSTER=false
OCR_LOCATIONS=
CLUSTER_NAME=rac
NODE_NAME_LIST=rac1,rac2
PRIVATE_NAME_LIST=
VOTING_DISKS=
#VF_DISCOVERY_STRING=%s_vfdiscoverystring%

Mas informacion en

  • 12.2 GI Upgrade fails with : CLSRSC-635: Failed to get EXTENDED_CLUSTER_SITE_GUIDS (Doc ID 2259672.1)

restaurar una base de datos desde el backup de una Standby

Hoy vamos a ver como anticipar un error en lo que puede ser una recuperacion larga

Supongamos que hemos recuperado una base de datos desde una standby database.
Si ese es el caso, cuando intentemos abrir la base de datos despues del recover tendremos un error

ORA-01666: control file is for a standby database

Como lo prevenimos

Vamos a ver primero como prevenir este error, y es simplemente añadiendo la clausula primary a la cadena que vamos a usar para recuperar la base de datos desde ese standby backup
rman target /
restore primary controlfile from '/backup/SID_STBY/standby_controlfile_backup';
exit;

Y pensareis, esto esta muy bien, pero.... y si ya tengo el backup restaurado

Como lo solucionamos ?

 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
ALTER DATABASE ACTIVATE STANDBY DATABASE;
select name,open_mode ,database_role from v$database;
alter database open resetlogs

El RAC se queda en estado [ROLLING PATCH]

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

Oracle PSU releases hasta 2022

Vamos a ver una entrada de esas para guardar en el bookmark

PSU documents

  • Database 12.1.0.2 Proactive Patch Information (Doc ID 2285558.1)
  • Database 12.2.0.1 Proactive Patch Information (Doc ID 2285557.1)
  • Database 19 Proactive Patch Information (Doc ID 2521164.1)
  • Database 11.2.0.4 Proactive Patch Information (Doc ID 2285559.1)

Diferencias entre PSU y RU

Comandos basicos en Orace RAC

Hoy vamoa a volver a las entradas para dummies, esta vez con los comandos basicos del RAC

Como paramos un RAC?

La manera mas sencilla escon permisos de root mediante el comando

export ORACLE_SID=+ASM1
export ORAENV_ASK=NO
. oraenv
sudo $ORACLE_HOME/bin/crsctl stop crs
sudo $ORACLE_HOME/bin/crsctl disable crs 

A la hora de arrancarlo ejecutaremos

export ORACLE_SID=+ASM1
export ORAENV_ASK=NO
. oraenv
sudo  $ORACLE_HOME/bin/crsctl enable crs
sudo $ORACLE_HOME/bin/crsctl start crs  

Como arrancamos/paramos una base de datos

srvctl stop database -d $DB_NAME

srvctl start database -d $DB_NAME

Como arrancamos/paramos una instancia en un nodo

Podemos hacerlo de varias maneras

srvctl start instance -d $DB_NAME-n $NODE_NAME 
srvctl start instance -d $DB_NAME -i $INSTANCE_NAME

Para pararla seria similar cambiando el start por stop

srvctl stop instance -d $DB_NAME-n $NODE_NAME 
srvctl stop instance -d $DB_NAME -i $INSTANCE_NAME

Parar elementos dedicados del RAC

Hay algunos componentes dedicados del RAC que no funcionan con la sintaxsis estandard, estos son:

  • Management database
  • ASM prxy

Administracion de la Management database

Los comados que podemos llevar a cabo sobre la management database son stop y relocate

srvctl start mgmtdb -n  $NODENAME 

srvctl stop mgmtdb -n $NODENAME 

srvctl relocate mgmtdb -n $OTRO_NODO

Administracion del ASM proxy

srvctl start res ora.proxy_advm -n  $NODENAME 

srvctl stop res ora.proxy_advm -n  $NODENAME

comandos sobre el CRS

Podemos ver la entrada Comprobar versiones del cluster

Comandos sobre el OCR

Podemos verlos en la entrada Oracle cluster registry OCR (componentes del grid)

Comandos sobre los voting disk

Podemos verlos en la entradas
Redundancia de los votingdisk en ASM
Voting disk (componentes del grid)

Comandos sobre ADVM

Introducción al ADVM

Mas entradas para dummies sobre RAC:
Comandos basicos en Orace RAC
Comandos basicos del RAC II
Eliminar un nodo del rac