A pesar que aún no se documenta como un BUG en MOS, efectivamente estamos ante uno de ellos.
Les doy una pista: la diferencia no es del sistema operativo, sino de un cambio interno en Oracle Database introducido a partir del RU 19.28
Vamos por partes !!!
Definitivamente existen algunas diferencias importantes entre las versiones de Oracle Linux V7 y V8 y una de ellas es como se gestiona el sistema de archivos /dev/shm y otros sistemas de archivos virtuales.
En un contexto general, /dev/shm es un sistema de archivos de tipo tmpfs que proporcina memoria compartida de POSIX.
POSIX (Portable Operating System Interface for Unix) es un conjunto de estándares que definen como se debe comportar los sistemas operativos tipo UNIX para ser compatibles y portables entre sí. Me siento como en los 90's cuando inicié a estudiar DG/UX. :-)
La memoria compartida es un mecanismo mediante el cual dos o más procesos pueden acceder al mismo segmento de memoria física para intercambiar información sin pasar por el disco ni usar llamadas al sistema de E/S.
Esto la hace extremadamente rápida, ideal para bases de datos, servidores de aplicaciones y sistemas de tiempo real. La memoria compartida POSIX es una implementación estandarizada por POSIX de ese concepto, permitiendo que los procesos, creen, abran, lean, escriban y sincronicen segmentos de memoria compartida.
Estos sistemas utilizan nombres simbólicos que el kernel gestiona dentro de un sistema de archivos virtual, como por ejemplo /dev/shm. En Linux entonces, /dev/shm es la representación en disco de la memoria compartida POSIX.
La gestión de montaje de /dev/shm es distinta en las versiones OL7x y OL8x. En el caso de OL7x, se monta automáticamente por el kernel del sistema operativo y no necesariamente aparece en el archivo /etc/fstab. Mientras que en OL8x, es gestionado por "systemd" mediante la unidad tmp.mount y aparece explícitamente como un sistema montado al listarlo con el comando "mount".
SYSTEMD es el gestor de sistemas y servicios utilizado por OL que reemplaza a los antiguos scripts de inicio en los SYSTEM V. El primer proceso que se inicia en el arranque del sistema es el PID 1 y el último que se ejecutado durante el apagado.
Para la implementación en memoria, en OL7x el funcionamiento de /dev/shm es un enlace simbólico a /run/shm en algunos casos, heredando el comportamiento de "glibc" y del kernel.
Mientras en OL8x, /dev/shm es un montaje directo de tmpfs, no es simbólico.
Debido a lo indicado anteriormente, para OL7x la compilación NATIVA en Oracle Database funciona sin intervención manual, pero en OL8x, el montaje de /dev/shm al hacerse bajo el control del gestor SYSTEMD y por políticas de seguridad que incluye "noexec" rompe la compatibilidad con procesos que ejecutan código temporal como lo hace PL/SQL NATIVE.
Bajo esta primicia, las versiones de Oracle Database 19c/21c/26ai, al compilar código en modo nativo, se van a ver afectadas en OL8x.
Ahora, porque funcionaba bien la compilación con el R.U. 19.27 y ya no en R.U. 19,28 en adelante.?
El comportamiento de la compilación NATIVE en Oracle Database 19c cambió a partir del Release Update (RU) 19.28, y eso explica por qué antes funcionaba aunque /dev/shm estuviera montado con noexec, mientras que desde 19.28 (y en 19.29) empieza a fallar.
Hasta las versiones de Oracle 11g y 12c Oracle Database utilizaba un directorio específico para el compilador cuando se utilizaba la opción NATIVE de PL/SQL.En alguna documentación se encuentra referencias a $ORACLE_HOME/plsql/native, sin embargo, era ajustado según la necesidad específica a través del parámetro PLSQL_NATIVE_LIBRARY_DIR. Durante el proceso, Oracle generaba archivos C y librerías objeto (.so) que luego son enlazadas dentro del $ORACLE_HOME, sin necesidad de ejecutarse directamente desde /dev/shm.
Aunque el runtime de Oracle usaba /dev/shm para ciertas estructuras internas, la ejecución de código binario nativo no ocurría directamente dentro de /dev/shm — solo se almacenaban allí buffers de memoria y estructuras compartidas.
Por tanto, aunque /dev/shm tuviera noexec, no había conflicto con la ejecución del código nativo.
En las versiones 18c en adelante, los parámetros:
- PLSQL_NATIVE_LIBRARY_DIR
- PLSQL_NATIVE_LIBRARY_SUBDIR_COUNT
- PLSQL_NATIVE_C_COMPILER
- PLSQL_NATIVE_LINKER, fueron declarados depreciados y retirados.
En las versiones 19c, el motor de PL/SQL ahora realiza la compilación completamente dentro del motor de Oracle — sin generar archivos C ni invocar al compilador externo.
Es decir, ya no se generan archivos .c ni .so en el sistema operativo.
El código se traduce internamente a un formato nativo binario, almacenado dentro de los mismos segmentos del diccionario de datos, bajo la administración del motor PL/SQL.
Que pasa a partir de RU 19.28?
El cambio llega con mejoras de seguridad y aislamiento del proceso de compilación nativa, introducidas por Oracle para alinearse con las políticas de seguridad del runtime compartido y el manejo de compilación JIT (Just-In-Time) interna, según alguna documentación de referencia.
En concreto:
A partir del RU 19.28, Oracle modificó la estrategia de carga dinámica del compilador NATIVE para utilizar áreas temporales en memoria compartida — principalmente en /dev/shm — antes de mapear las librerías objeto generadas.
Esto busca mayor velocidad y aislamiento en entornos multitenant (CDB/PDB), especialmente cuando hay compilaciones concurrentes. Esto hace que a partir de RU 19.28 exista una dependencia total sobre /dev/shm.
Por tanto, la diferencia no es del sistema operativo, sino de un cambio interno en Oracle Database introducido a partir del RU 19.28, que mueve parte de la compilación nativa al espacio de memoria compartida ejecutable (/dev/shm), lo cual exige que esté montado con exec.
Por eso, la compilación NATIVE deja de funcionar a partir de
RU 19.28 si /dev/shm está con noexec.
SR 3-42843259511 : Error when compiling an object in NATIVE code Oracle Database 19c RU 19.28, por tanto, se encuentra documentado.
