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_TIMEFLOOD_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.
No hay comentarios:
Publicar un comentario
Te agradezco tus comentarios. Te esperamos de vuelta.