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:

Plataformando el sistema operativo con Ansible

Hoy vamos a recuperar la entrada de como preparar el sitema operativo (en este caaso un OEL 7)para una instalacion de Oracle.

Para esto vamos a usar el role so_check del que podemos encontrar la ultima version en nuestro GitHub

Este Playbok no hace nada del otro mundo, ya que simplemente traslada a Ansible los pasos que llevamos a cabo una y otra vez cada vez que preparamos un servidor, como vereis lo mas complicado del mismo es la sintaxsis.

Veamos el codigo completo y luego lo analizaremos por partes

[code lang=»py»]
# Pamplona 2019
# Playbook which checks if teh hosts has all the requested prereequisites
#
# requires
# env: name of the server which should be in the inventory
# vars/oracle_standard.yaml configuration file with all the deppartment values
# vars/so_[version]_requisites.yaml configuration file with the packages required for this version of the software

– hosts: "{{env}}"
remote_user: ansible
become: yes
become_user: root
tasks:
– fail: msg="Error no server definied, please define the env variable in the job"
when: env is not defined

– name: "Including standard variables"
include_vars:
file: "vars/oracle_standard.yaml"

– name: "Including So {{version}} requisites"
include_vars:
file: "vars/so_{{version}}_requisites.yaml"

– name: Chequeamos the group
group:
name: "{{oracle_group}}"
gid: "{{oracle_gid}}"
state: present
tags: oragroup

– name: Check the oracle user
user:
name: "{{oracle_user}}"
uid: "{{oracle_uid}}"
group: "{{oracle_group}}"
shell: /bin/bash
tags: orauser

– name: check required packages
yum:
name: "{{package_name}}"
state: latest
tags: packages

– name : Kernel values
sysctl:
name: "{{ item.name }}"
value: "{{item.value}}"
state: present
ignoreerrors: yes
sysctl_file: /etc/sysctl.d/30-oracle.conf
with_items: "{{kernel_values}}"
tags: sysctl

##We execute Huge Pages separately
– name: Huge Pages
sysctl:
name: vm.nr_hugepages
value: "{{huge_pages}}"
sysctl_set: yes
state: present
sysctl_file: /etc/sysctl.d/30-oracle.conf
ignoreerrors: yes
tags: huge_pages

– name: Limits para el usuario
pam_limits:
domain: oracle
use_max: yes
limit_type: "{{ item.tipo }}"
limit_item: "{{ item.name }}"
value: "{{item.value}}"
dest: /etc/security/limits.d/30-oracle.conf
with_items: "{{limits}}"
tags: limits

– name: Disable firewall
service:
name: firewalld
state: stopped
enabled: no
tags: firewall

– name: disabling SElinux
selinux:
policy: targeted
state: disabled
tags: SELinux
[/code]

Comprobamos usuarios y grupos

Lo primero que hacemos es la comprobacion de que tenemos los usuarios y grupos que necesitamos.
En nuestro taller usamos la configuracion mas basica , que es oracle:dba para toda la instalacion

Comprobamos los paquetes del sistema operativo

En este bloque comprobamos los paquetes del sistema operativo.
Para ello usuaremos el modulo yum de Ansible con una lista de los paquetes, esta lista los vamos a leer de un fichero de variables en el que tendremos reflejado todo lo necesario para la plataformacion de un servidor para la version especifica de Oracle que tenemos.

El conenido de este fichero refrente a los paquetes es una simple lista
[code lang=»py»]
package_name :
– binutils
– oracleasm
– oracleasm-support
– compat-libcap1
– compat-libstdc++-33
– elfutils-libelf-devel
– fontconfig-devel
– glibc
– glibc-devel
[/code]

Valores del Kernel

El siguiente paso es el configurar los parametros del kernel que queremos.
Para este paso vamos a usar el modulo sysctl, aplicando tantos valores como queramos de nuestro fichero de requerimientos
La sintaxsis de estos requerimientos es

[code lang=»py»]
kernel_values:
– { name: fs.file-max, value: 6815744 }
– { name: kernel.sem, value: "250 32000 100 128" }
– { name: kernel.shmmni, value: 4096 }
[/code]

Huge Pages

Las Huge pages es un parametro del kernel como cualquier otro, podriamos haberlo incluido dentro de los kernel parameters pero a mi personalmente me gusta tenerlo separado .
En nuestro caso no estamos dandole un valor fijo, sino que le asignamos el 60% del total del servidor

[code lang=»py»]
#60 percent huge pages
huge_pages: "{{((0.6 * ansible_memtotal_mb)*1024/2)|round|int }}"
[/code]

Limites

El siguiente paso en la plataformacion del sistema operativo es ajustar los soft y hard limits para el usuario Oracle.
Para esto usaremos el modulo pam_limits. El codigo asociado del fichero de variables es muy similar al que usamos en el kernel y, al igual que haciamos con las huge pages obtendremos alguno de estos valores dinamicamente en funcion de los recursos del servidor que vayamos a plataformar

[code lang=»py»]
limits:
– { tipo: ‘soft’ ,name: ‘nproc’, value: 16384 }
– { tipo: ‘hard’ ,name: ‘nproc’, value: 16384 }
– { tipo: ‘soft’ ,name: ‘memlock’, value: "{{ ((0.9 * ansible_memtotal_mb)*1024)|round|int }}" }
– { tipo: ‘hard’ ,name: ‘memlock’, value: "{{ ((0.9 * ansible_memtotal_mb)*1024)|round|int }}" }
[/code]

Desabilitar SElinux y Firewall

Este ultimo paso es mas bien opcional, ya que no deberia de ser un requisito, pero, en la mayoria de las plataformaciones la seguridad suele estar delegada en los elementos de red y el SELinux se deshabilita, por lo que, lo hemos incluido en nuestro playbook

[code lang=»py»]
– name: Disable firewall
service:
name: firewalld
state: stopped
enabled: no
tags: firewall

– name: disabling SElinux
selinux:
policy: targeted
state: disabled
tags: SELinux
[/code]

Como habeis podido ver,como os comentaba al principio no es nada del otro mundo, simplemente es trasladar a lenguaje de ansible los pasos que llevamos a cabo manualmente 1000 veces .

Como siempre, esta entrada es solamente un taller basico, no dudeis en encontrar la ultima y valida version del role en proyecto provisioning e GitHub

Trabajando con Huge pages

A partir de OEL7 deberiammos de chekquear las transparent huge pages

cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]

Igualmente , deberiamos de tenerlo configurado en el grub

sudo cat /boot/grub2/grub.cfg |grep trans
  set kernelopts="root=/dev/mapper/vg_main-lv_root ro console=tty0 no_timer_check biosdevname=0 rd.lvm.lv=vg_main/lv_root net.ifnames=0 transparent_hugepage=never "

Por el contrario, si no las hemos modificado ( situacion no deseada) , aparecera

cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never 

A partir de ahi, para ver las disponibles solo hay que ejecutar

test1$: grep Huge /proc/meminfo
AnonHugePages:    897024 kB
HugePages_Total:     220
HugePages_Free:      220
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

Esto nos indica que teemos 220 paginas de 2048 Kb
Lo que significa que el espacio dedicado sera

Gb = 220*2048/1024/1024

Mas informacion en :

Parametro oculto _query_on_physical

Hoy vamos a ver una de estas entradas que contradicen algunas otras que podemos ver en internet.

Dado lo restrictivo de Oracle con el licenciamiento, seria muy interesante contar con una opcion que nos deshabilitara el Real-Time Query del Dataguard .
Si buscamos por internet, nos encontramos con un parametro oculto llamado _query_on_physical

Si Ejecutamos el comando

alter system set "_query_on_physical"=false scope=spfile;

Deshabilitaremos el Active Dataguard, pero … ¿que dice Oracle de todo esto?
Oracle como siempre dice que nunca debemos de activar parametros ocultos en la base de datos a no ser que sea especificamente recomendado por el equipo de soporte

NOTE: Hidden parameter «_query_on_physical» is NOT an option to prevent Active Data Guard usage. It should NOT be used at all in any version of the Oracle Database.
It is unsupported to be set unless Oracle Support advises it for diagnostic reason

Asi que, ya sabeis, la unica opcion que nos da Oracle para no activarlo es «tener cuidado».

Como siempre, mas informacion en soporte:

  • Which are Supported Methods to Prevent Active Data Guard Usage When License is Not Available? (Doc ID 2269239.1)

kernel.panic_on_oops : Nuevo parametro de la 12c

Hoy vamos a ver otra de estas pequeñas sorpresas de Oracle en las nuevas versiones
En los requisitos de la instalacion de la version 12c de Oracle nos encontramos con la siguiente nota

Note: 
The below Kernel Parameter "panic_on_oops=1" is being Introduced and required
 from 12.1.0.2.0 onwards.
kernel.panic_on_oops=1

Que es lo que hace este parametro del Kernel?
Este parametro simplemente controla el comportamiento del kernec cuando un oops or bug es detectado.

Los valores que puede tomar es:

  • 0: INtenta continuar la operacion
  • 1: Entra en panic , ademas de este panica, si el sysctl es distnto de cero, entonces el servidor se reiniciara

Como veis, un parametro bastante inocuo… hasta que buscamos la causa de por que el servidor se ha reiniciado