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:

Comprobar versiones del cluster

Hoy vamos a ver otra de estas entradas sencillas que nos pueden llegar a ser de utilidad llegado el caso

Hay veces ( especialmente en los momentos del parcheado) que queremos saber la version de los componentes del cluster. En estos casos podemos tener varios binarios en la máquina y que sean distintos a el software que está corriendo, o distintas versiones entre distintos componentes del cluster, para ello tenemos las opción query del crsctl .
Las opciones que nos serán útiles son:

  • b>releaseversion: Muestra la versión de los binarios instalados en el nodo local. Este comando puede ser “engañado” modificando la variable PATH
  • activeversion: Muestra la versión que está funcionando. Durante un rolling upgrade la activeversion no cambiará hasta que el upgrading finalize. La activeversion siempre es la versión mas baja entre todos los nodos del cluster.
  • softwareversion:Es el contrario de activeversion, nos indicará la ultima versión instalada en el cluster, también puede indicarnos la version mas alta instalada en uno de los nodos.

Algunos ejemplos de la salida son:

[grid@rac1 ]# crsctl query crs releaseversion
Oracle High Availability Services release version on the local node is [11.2.0.4.0]
 
[grid@rac1 ]# crsctl query crs activeversion
Oracle Clusterware active version on the cluster is [11.2.0.4.0]
 
[grid@rac1 ]# crsctl query crs softwareversion
Oracle Clusterware version on node [rac1] is [11.2.0.4.0]
En single node no
[grid@rac1 ]# crsctl query has releaseversion
Oracle High Availability Services release version on the local node is [11.2.0.4.0]