Hace unos días atrás experimenté un error poco común.
El Alert de la base de datos mostraba la siguiente información:
adrci> show alert
ADR Home = /opt/app/oracle/diag/rdbms/cdb/cdb:
*************************************************************************
Output the results to file: /tmp/alert_10232_1404_cdb_1.ado
adrci> exit
Errors in file /opt/app/oracle/diag/rdbms/cdb/cdb/trace/cdb_vktm_14835.trc (incident=128072) (PDBNAME=CDB$ROOT):
ORA-00800: soft external error, arguments: [Set Priority Failed], [VKTM], [Check traces and OS configuration], [Check Oracle document and MOS notes], []
Incident details in: /opt/app/oracle/diag/rdbms/cdb/cdb/incident/incdir_128072/cdb_vktm_14835_i128072.trc
Error attempting to elevate VKTM's priority: no further priority changes will be attempted for this process
Al observar la información de referencia de los incidentes, los mismos mostraban el contenido a continuación:
adrci> show incident
ADR Home = /opt/app/oracle/diag/rdbms/cdb/cdb:
*************************************************************************
INCIDENT_ID PROBLEM_KEY CREATE_TIME
-------------------- ------------------- ----------------------------------------
128072 ORA 800 2026-05-27 03:47:30.907000 -06:00
133193 ORA 800 2026-05-27 03:55:48.114000 -06:00
2 rows fetched
adrci> show incident -mode brief
ADR Home = /opt/app/oracle/diag/rdbms/cdb/cdb:
*************************************************************************
**********************************************************
INCIDENT INFO RECORD 1
**********************************************************
INCIDENT_ID 128072
STATUS ready
CREATE_TIME 2026-05-27 03:47:30.907000 -06:00
PROBLEM_ID 9
CLOSE_TIME
FLOOD_CONTROLLED none
ERROR_FACILITY ORA
ERROR_NUMBER 800
ERROR_ARG1 Set Priority Failed
ERROR_ARG2 VKTM
ERROR_ARG3 Check traces and OS configuration
ERROR_ARG4 Check Oracle document and MOS notes
ERROR_ARG5
ERROR_ARG6
ERROR_ARG7
ERROR_ARG8
ERROR_ARG9
ERROR_ARG10
ERROR_ARG11
ERROR_ARG12
SIGNALLING_COMPONENT background_proc
SIGNALLING_SUBCOMPONENT
SUSPECT_COMPONENT
SUSPECT_SUBCOMPONENT
ECID
IMPACTS 0
**********************************************************
INCIDENT INFO RECORD 2
**********************************************************
INCIDENT_ID 133193
STATUS ready
CREATE_TIME 2026-05-27 03:55:48.114000 -06:00
PROBLEM_ID 9
CLOSE_TIME
FLOOD_CONTROLLED none
ERROR_FACILITY ORA
ERROR_NUMBER 800
ERROR_ARG1 Set Priority Failed
ERROR_ARG2 VKTM
ERROR_ARG3 Check traces and OS configuration
ERROR_ARG4 Check Oracle document and MOS notes
ERROR_ARG5
ERROR_ARG6
ERROR_ARG7
ERROR_ARG8
ERROR_ARG9
ERROR_ARG10
ERROR_ARG11
ERROR_ARG12
SIGNALLING_COMPONENT background_proc
SIGNALLING_SUBCOMPONENT
SUSPECT_COMPONENT
SUSPECT_SUBCOMPONENT
ECID
IMPACTS 0
2 rows fetched
En bases de datos Oracle, el proceso VKTM (Virtual Keeper of Time) es un proceso en segundo plano que actúa como el "reloj maestro" de la instancia. Se encarga de publicar y sincronizar la hora (tanto en segundos como en alta resolución) para evitar llamadas repetitivas al sistema operativo y garantizar un rendimiento óptimo.
En dicho servidor, habíamos experimentado serios problemas de rendimiento con un proceso pesado de cierre nocturno, dejándo el mismo por decirle de alguna manera inciclado. Los jobs de la base de datos no levantaban automáticamente ni manualmente. La primera acción, fue reiniciar el contenedor de base de datos. Cuando aplicamos el procedimiento "clásico" de todo informático, el proceso de cierre de día, concluyó sin inconvenientes y los jobs volvieron a arrancar por cuenta propia sin errores.
Durante la noche de ese mismo día, volvió a repetirse el escenario de la noche anterior. Los jobs estaban abajo nuevamente y no levantaban manualmente.
Para complicar más el tema, los jobs que consumían un dblink a otra base de datos, dejaban bloqueados los objetos involucrados en el proceso, provocando también que los EOD del otro servidor fallaran en su intento por concluir.
El problema se había duplicado.
Revisando nuevamente el alert, revise el detalle de los errores que previamente había visto, pero que no había tenido tiempo para investigar.
Con lo que encontré en el ALERT, procedí a consultar en el MOS y este apuntaba a 2 posibles causas del error.
La menos probable es que existiera un problema con los permisos de un archivo binario en el $ORACLE_HOME con el nombre oradism.
oradism es una utilidad especializada en segundo plano de Oracle Database en sistemas Unix/Linux que permite al software de Oracle realizar operaciones del sistema operativo que requieren privilegios como el usuario "root", principalmente bloquear/desbloquear la memoria del Área Global del Sistema (SGA) y establecer prioridades de ejecución más altas para procesos críticos
[oracle@asrv_001 ~]$ less /opt/app/oracle/diag/rdbms/cdb/cdb/incident/incdir_128072/cdb_vktm_14835_i128072.trc
[oracle@asrv_001 ~]$ ls -l $ORACLE_HOME/bin/oradism
-rwsr-x---. 1 root oinstall 147848 Apr 17 2019 /opt/app/oracle/product/19c/bin/oradism
[oracle@asrv_001 ~]$ ps -ef | grep vktm
oracle 13493 25178 0 09:32 pts/0 00:00:00 grep --color=auto vktm
oracle 17437 1 0 03:55 ? 00:00:02 ora_vktm_cdb
Lo segundo me dice la nota es que verificara la configuración de un parámetro a nivel de sistema operativo: cpu.rt_runtime_us.
Este es un parámetro del kernel Linux relacionado con la planificación (scheduler) de procesos de tiempo real (Real-Time Scheduling).
Su función es limitar cuánto tiempo de CPU pueden consumir los procesos con políticas de planificación de tiempo real (SCHED_FIFO y SCHED_RR) para evitar que monopolizen completamente los CPUs y bloqueen los procesos normales del sistema.
[oracle@asrv_001 ~]$ exit
logout
[opc@asrv_001 ~]$ sudo -s /bin/bash
[root@asrv_001 opc]# cat /sys/fs/cgroup/cpu,cpuacct/user.slice/cpu.rt_runtime_us
0
El valor "0" indica que los procesos de tiempo real NO pueden ejecutar tiempo de CPU. Sin embargo, en la práctica Oracle Database no utiliza procesos RT, por lo que probablemente no notarás ningún impacto directo, pero ...
Revisando otras publicaciones, encontré que otras personas habían experimientado un problema parecido y habían resuelto seteando el parámetro a un valor de 950000 que por lo general es el valor de facto en servidores con Oracle Database.
Lo hice en caliente primero para ver si sucedía algo malo.
Como no encontré problemas, procedí a configurar un servicio que se encargará de registrar el cambio cada vez que el sistema reiniciara.
[root@asrv_001 opc]# echo 950000 > /sys/fs/cgroup/cpu,cpuacct/user.slice/cpu.rt_runtime_us
[root@asrv_001 opc]# ls -lat /usr/local/bin/
total 24
drwxr-xr-x. 2 root root 49 Mar 17 2023 .
-rwxr-xr-x. 1 root root 6404 Mar 17 2023 coraenv
-rwxr-xr-x. 1 root root 6823 Mar 17 2023 oraenv
-rwxr-xr-x. 1 root root 2445 Mar 17 2023 dbhome
drwxr-xr-x. 12 root root 4096 Sep 25 2022 ..
[root@asrv_001 opc]# cat /sys/fs/cgroup/cpu,cpuacct/user.slice/cpu.rt_runtime_us
950000
[root@asrv_001 opc]# cat /usr/local/bin/set_oracle_rt
#!/bin/bash
echo 950000 > /sys/fs/cgroup/cpu,cpuacct/user.slice/cpu.rt_runtime_us
[root@asrv_001 opc]# vi /usr/local/bin/set_oracle_rt
[root@asrv_001 bin]# cat /etc/systemd/system/oracle-rt.service
[Unit]
Description=Oracle RT Runtime Fix
After=network.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/set_oracle_rt
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
[root@asrv_001 bin]#
[root@asrv_001 opc]# cd /usr/local/bin/
[root@asrv_001 bin]# ls -lat
total 28
drwxr-xr-x. 2 root root 70 May 27 09:40 .
-rw-r--r--. 1 root root 82 May 27 09:40 set_oracle_rt
-rwxr-xr-x. 1 root root 6404 Mar 17 2023 coraenv
-rwxr-xr-x. 1 root root 6823 Mar 17 2023 oraenv
-rwxr-xr-x. 1 root root 2445 Mar 17 2023 dbhome
drwxr-xr-x. 12 root root 4096 Sep 25 2022 ..
[root@asrv_001 bin]# chmod +x set_oracle_rt
[root@asrv_001 bin]# ls -lat
total 28
drwxr-xr-x. 2 root root 70 May 27 09:40 .
-rwxr-xr-x. 1 root root 82 May 27 09:40 set_oracle_rt
-rwxr-xr-x. 1 root root 6404 Mar 17 2023 coraenv
-rwxr-xr-x. 1 root root 6823 Mar 17 2023 oraenv
-rwxr-xr-x. 1 root root 2445 Mar 17 2023 dbhome
drwxr-xr-x. 12 root root 4096 Sep 25 2022 ..
[root@asrv_001 bin]# vi /etc/systemd/system/oracle-rt.service
[root@asrv_001 bin]# systemctl daemon-reload
[root@asrv_001 bin]# systemctl enable oracle-rt.service
Created symlink from /etc/systemd/system/multi-user.target.wants/oracle-rt.service to /etc/systemd/system/oracle-rt.service.
[root@asrv_001 bin]# systemctl start oracle-rt.service
[root@asrv_001 bin]# systemctl status oracle-rt.service
● oracle-rt.service - Oracle RT Runtime Fix
Loaded: loaded (/etc/systemd/system/oracle-rt.service; enabled; vendor preset: disabled)
Active: active (exited) since Wed 2026-05-27 09:42:27 CST; 38s ago
Process: 16295 ExecStart=/usr/local/bin/set_oracle_rt (code=exited, status=0/SUCCESS)
Main PID: 16295 (code=exited, status=0/SUCCESS)
May 27 09:42:27 asrv_001 systemd[1]: Starting Oracle RT Runtime Fix...
May 27 09:42:27 asrv_001 systemd[1]: Started Oracle RT Runtime Fix.
[root@asrv_001 bin]# cat /usr/local/bin/set_oracle_rt
#!/bin/bash
echo 950000 > /sys/fs/cgroup/cpu,cpuacct/user.slice/cpu.rt_runtime_us
[root@asrv_001 bin]#
Resultado obtenido, desde que configuré el servicio con el seteo del parámetro, no he vuelto a registar el error en la bitácora de la base de datos, ni he tenido problemas con el desempeño del EOD, ni con la inicialización de los JOBS.
Así, que si tienes algo parecido, quizás esta sea la solución.