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:

Version del parcheado de la base de datos

Hoy vamos a ver otra de estas entradas para dummies utiles en el dia a dia.
Como sabemos en que version de parcheado nos encontramos?

La primera opcion y mas sencilla es la del uso del binario del sistema operativo opatch, pero , como podemos estar seguros de que el parche/psu se ha ejecutado correctamente y se ha aplicado tambien la parte SQL

Oracle 11g

Si estamos en la version 11g deberemos de hacerlo consultando la tabla del diccionario sys.registry$history

SET LINESIZE 180 PAGESIZE 90 
COLUMN FECHA FORMAT A18
COLUMN action FORMAT A20
COLUMN version FORMAT A10
COLUMN comments FORMAT A30
COLUMN bundle_series FORMAT A10
SELECT TO_CHAR(action_time, 'YYYY-MM-DD HH24:MI') AS FECHA,
       action,
       namespace,
       version,
       comments,
       bundle_series
FROM   sys.registry$history
ORDER by action_time;

Lo que nos devolvera algo similar a :

FECHA              ACTION               NAMESPACE            VERSION    COMMENTS                       BUNDLE_SER
------------------ -------------------- -------------------- ---------- ------------------------------ ----------
07-JAN-2017 15:21  APPLY                SERVER               11.2.0.3   PSU 11.2.0.3.15                PSU
01-DEC-2017 18:59  UPGRADE              SERVER               11.2.0.4.0 Upgraded from 11.2.0.3.0
01-DEC-2017 19:00  APPLY                SERVER               11.2.0.4   PSU 11.2.0.4.171017            PSU

Oracle 12c

Cuando estamos en la version 12c, tendremos dos maneras de encontrar esta informacion:

Preguntando a DBA_REGISTRY_SQLPATCH

La consulta sera muy similar a la anterior, pero en ved de preguntar a el dicionario sys.registry$history, lo haremos a la tabla DBA_REGISTRY_SQLPATCH



SET LINESIZE 180 PAGESIZE 90 
COLUMN FECHA FORMAT A20
COLUMN action FORMAT A10
COLUMN status FORMAT A20
COLUMN description FORMAT A90
COLUMN version FORMAT A10
COLUMN bundle_series FORMAT A10
SELECT TO_CHAR(action_time, 'YYYY-MM-DD HH24:MI:SS') AS action_time,
       action,
       status,
       description,
       version,
       patch_id,
       bundle_series
FROM   sys.dba_registry_sqlpatch
ORDER by action_time;

Lo que nos devolvera algo similar a

ACTION_TIME          ACTION     STATUS     DESCRIPTION                              VERSION      PATCH_ID BUNDLE_SER
-------------------- ---------- ---------- ---------------------------------------- ---------- ---------- ----------
07-MAR-2018 21:37:51 APPLY      SUCCESS    Database Patch Set Update : 12.1.0.2.4  12.1.0.2     20831110 PSU
                                         (20831110)

Mediante el package dbms_qopatch

En la version 12c tenemos el nuevo datapatch en los parcheados, la informacion de los parches de la base de datos esta tambien accesible con el package dbms_qopatch.
Esto ya lo vimos en la entrada Obtener los parches instalados en la base de datos CDB que venia a decir :

 
 set serverout on
exec dbms_qopatch.get_sqlpatch_status;

Lo que nos devuelve

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.

Sobre el uso de dbms_qopatch tenemos la URL hay una URL Como saber si un parche esta aplicado en la BBDD que tiene consultas muy utiles para obtener informacion de la base de datos (inventario,paches…)

Esta informacion ha sido obtenido en su totalidad de las URLS:

Bienvenidos a Oracle 18c

Si.
Habeis oido bien.
Vamos a tener oracle 18c.

¿que ha pasado con la 13,14,15,16 y 17 ?

Realmente no ha pasado nada, puesto que la 18c es lo mismo que la 12.2.0.2 . Lo que ocurre es que Oracle va a cambiar la notacion de las bases de datos, nombrandolas por el año en el que esta y el trimestre

Si miramos la grafica de suporte con las versiones (Doc ID 742060.1) vemos claramente como la 12 pasa a 18

Esto viene bien explicado en los blogs de Oracle que enlazamos abajo, y especialmente en el de Mike Dietrich’s, que os aclara que ahora vamos a pasar de tener PSU y BP a tener , RU y RUR

Veamos rapidamente que es cada una de las cosas :

  • PSU EL PSU (Patch Set Update) contenia una agrupacion de parches.
  • BU EL BU (Bundle update) contenia una agrupacion de parches y ADEMAS , los fixes y mejoras de la base de datos.

Es decir, el PSU solventaba bugs, pero no modificaba las funcionalidades, algo que es si que hacian los Bundle Patches

¿Que vamos a tener ahora?

  • RU: Son practicamente el equivalente a los BP , ya que contienen los parches y las mejoras, se estima que su lanzamiento sera trimestral y seran cumulativos.
  • RUR: Son el nuevo concepto de Oracle en e parcheado, son Release Update Revision , eliminan las mejoras y cambios funcionales del ultimo RU, pero si que aplican los parches.

¿Cual es el cambio mas importante?

Ademas del cambio de nombre que no deja de ser algo anecdotico, el verdadero cambio es que , con el uso de las RU vamos a estar aplicando cada trimestre no solamente los parches sino cualquier fix/mejora que Oracle este introduciendo en el motor.

En caso de que detectemos que este «fix» introduce cambios de comportamiento en el motor ( que la aplicacion va peor), entonces tendremos que añadir el RUR que deshabilita los cambios del RU que hemos aplicado.
En resumen, que Oracle nos esta obligando a subir las funcionalidades de las bases de datos a la ultima version.

Mas informacion en :

Obtener los parches instalados en la base de datos /CBD

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