Instalacion de Oracle 26ai – Oracle restart

Vamos a continuar con la instalacion de un Oracle26ai

En la anterior entrada vimos como teniamos que preparar un Oracle Linux 9.
Ahora veremos como instalar el Oracle Restart. Para no hacer la entrada muy larga, instalaremos solamente los binarios y en la siguiente configuraremos la capa de almacenamiento y crearemos el ASM.

Nosotros usaremos el paquete clásico LINUX.X64_2326100_grid_home.zip ya que instalar desde .rpm no tiene ninguna gracia.

Tras haer ejecutado esos pasos, nos conectaremos con nuestro usuario GRID y pondremos las variables de entorno en su fichero .bash_profile.

En muchos documentos hablan indistintamente e GI_HOME y GROD_HOME, con lo que nosotros nos ahorraremos el aburrimiento de ir poniéndolas siempre añadiéndolas directamente en nuestro bash_profile


export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=/u01/app/grid
export GI_HOME=$GRID_HOME
export ORACLE_HOME=$GRID_HOME
export ORACLE_SID=+ASM
export PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
umask 022
# Required for install and compile
export VUQDISK_GRP=oinstall
export CV_ASSUME_DISTID=OL8

Descomprimir binarios

Iremos a nuestro ORACLE_HOME y descomprimiremos los binarios:

cd $ORACLE_HOME
unzip /var/tmp/26ai/LINUX.X64_2326100_grid_home.zip

Descomprimir el utimo Opatch

Siempre usaremos la última versión de Opatch, como curiosidad, veremos como aun no le han cambiado el nombre de 23ai a 26 ai 😉

cd $ORACLE_HOME
rm -fR OPatch
unzip /var/tmp/26ai/p6880880_230000_LINUX.zip

Instalar el paquete cvuqdisk

Aunque pensábamos que todos los pasos requeridos como root ya estaban, exsiste algún paquete requerido que no es parte de la distribución sino del propio grid, por lo que solo lo tenemos cuando descargamos el software del grid, el paquete cvuqdisk puede encontrarse con un simple find, y lo instalaremos con el gestor de paquetes de red-hat dnf con el comando:

grid@gigabyte grid]$ find . -name *.rpm
./cv/remenv/cvuqdisk-1.0.10-1.rpm
./cv/rpm/cvuqdisk-1.0.10-1.rpm
sudo dnf install -y ./cv/rpm/cvuqdisk-1.0.10-1.rpm

Preparar un archivo de response

Ahora tendremos que preparar un archivo de respuesta con las configuraciones que queremos.
Esto va a ser mas sencillo y limpio que tener una linea de comandos enormes , para ello haremos una copia del gridsetup.rsp y modificaremos las lineasque vemos en el bloque de debajo:

cp ./install/response/gridsetup.rsp ./install/response/pamplona_dba.rsp


grid@gigabyte grid]$ diff ./install/response/gridsetup.rsp ./install/response/pamplona_dba.rsp

< INVENTORY_LOCATION= > INVENTORY_LOCATION=/u01/app/oraInventory
---
< installOption= > installOption=CRS_SWONLY
---
< ORACLE_BASE= > ORACLE_BASE=/u01/app/oracle
---
< OSDBA= > OSDBA=asmdba
---
< OSOPER= > OSOPER=asmoper
---
< OSASM= > OSASM=asmadmin
---
< configureAsExtendedCluster= > configureAsExtendedCluster=false
---
< executeRootScript= > executeRootScript=false

Una vez tenemos nuestro fichero, podríamos proceder a la instalacion

Nota Desde Cafe database nos dieron un consejo muy interesante, y es que podemos usar la utilidad de verificación de cluster para asegurarnos que todos los prerrequisitos de nuestro GRID se cumplen, para ello ejecutaríamos:

/runcluvfy.sh stage -pre crsinst -n `hostname -s`

INstalacion

Y llegamos al momento de la verdad, donde haríamos la Instalacion como usuario gridcon el comando

cd $ORACLE_HOME
./gridSetup.sh -silent -responseFile ./install/response/pamplona_dba.rsp

Nota En el momento de hacer este documento no exsiste ningun parche adicional que aplicar, en el caso de que hubiese disponible algun RU, deberiamos de descargarlo y ejecutar como usuario grid

cd $ORACLE_HOME
./gridSetup.sh -silent  -applyRU /var/tmp/[NUMERO_RU_DESCOMPRIMIDO] -responseFile ./install/response/pamplona_dba.rsp

Esto nos dará una salida similar a:

-----------------------------------------------
[WARNING] [INS-13014] Target environment does not meet some optional requirements.
   CAUSE: Some of the optional prerequisites are not met. See logs for details. gridSetupActions2026-01-25_06-23-45PM.log.
   ACTION: Identify the list of failed prerequisite checks from the log: gridSetupActions2026-01-25_06-23-45PM.log. Then either from the log file or from installation manual find the appropriate configuration to meet the prerequisites and fix it manually.
The response file for this session can be found at:
 /u01/app/grid/install/response/grid_2026-01-25_06-23-45PM.rsp

You can find the log of this install session at:
 /tmp/GridSetupActions2026-01-25_06-23-45PM/gridSetupActions2026-01-25_06-23-45PM.log

As a root user, run the following script(s):
	1. /u01/app/oraInventory/orainstRoot.sh
	2. /u01/app/grid/root.sh

Run /u01/app/oraInventory/orainstRoot.sh on the following nodes:
[gigabyte]
Run /u01/app/grid/root.sh on the following nodes:
[gigabyte]


Successfully Setup Software with warning(s).
Moved the install session logs to:
 /u01/app/oraInventory/logs/GridSetupActions2026-01-25_06-23-45PM

Ejecucion de comandos como root

Vamos pues a ejecutarlos comandos de root

[root@gigabyte u01]# /u01/app/oraInventory/orainstRoot.sh
Changing permissions of /u01/app/oraInventory.
Adding read,write permissions for group.
Removing read,write,execute permissions for world.

Changing groupname of /u01/app/oraInventory to oinstall.
The execution of the script is complete.
[root@gigabyte u01]# /u01/app/grid/root.sh
Check /u01/app/grid/install/root_gigabyte.pamplona.name_2026-01-25_18-31-43-054623113.log for the output of root script

Con lo que ya tenemos los binarios listos !!

Siguiente paso en:

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

Actualizar bases de datos antiguas antes de Junio de 2019

Hoy vamos a ver una entrada de la que no me puedo atribuir ningun merito, ya que , practiccamente es una traduccion + recopilacion de las URL’s en ingles que os adjunto al final como documentacion adicional.

Tal y como indica Mike Dietrich DEBEMOS parchear las bases de datos que tengamos en version 12.1.0.1, 11.2.0.3 y anteriores antes del 23 de Junio de 2019 .

¿Por que ?

En la nota de oracle MOS Note: 2335265.1 nos explican que, estas versiones de bases de datos están afectadas por un especie de Efecto 2000 en la manera en la que la base de datos calcula el SCN.
Un problema que incrementa la criticada del parcheado es que, este bug afecta a los DBlinks , por lo que no solamente puede causar problemas en nuestras bases de de datos afectadas, sino que, si esta esta conectada a una nueva aunque no este afectada provocara que nuestra obtención de datos falle.

Como indicaba al principio, podemos encontrar este caso muy bien explicado en el blog de Job Oprel, pero, en cualquier caso , es muy conveniente el llevar a cabo la comprobación de hasta que punto estamos afectados en todas las bases de datos que tengamos dentro de las versiones mencionadas.

La consulta a ejecutar es

set pagesize 200;
set linesize 200;
column  OWNER format a30;
column  USERNAME format a30;
column DB_LINK format a20;
col HOST format a40;
col created format a20;

select * from DBA_DB_LINKS;

SELECT NAME,  
   (current_scn/281474976710656)*100 as PCT_OF_SCN_KEYSPACE_USED,  
   ROUND(SYSDATE-CREATED) as DAYS_SINCE_DB_CREATION, 
   ROUND(1/(current_scn/281474976710656)*(SYSDATE-CREATED)) 
        AS EST_DAYS_BEFORE_SCN_EXHAUSTED, 
   ROUND(1/(current_scn/281474976710656)*(SYSDATE-CREATED)/365) 
        AS EST_YEARS_BEFORE_SCN_EXHAUSTED  
FROM v$database;

La fuente de esta informacion donde se pude ver el analisis completo es

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

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