Luchando contra el reloj

Recientemente recibí el llamado de uno de mis clientes, con respecto a que su flamante base de datos estaba mostrando una hora adelantadaMe indicó que habían verificado la zona horaria de la base de datos y la del servidor y que estaba todo en orden.

Afortunadamente este escenario ya lo he visto algunas veces y es fácil resolución, por lo que pusimos manos a la obra!

El problema

Empezamos por comprobar que las aplicaciones mostraban un adelanto de 5 horas.

Al ingresar al computador en el que opera la base de datos, se verifica que la hora es la correcta, al igual que la zona horaria (estamos en Lima, Perú).

[root@node1 ~]# timedatectl
      Local time: Sun 2024-08-25 18:07:48 -05
  Universal time: Mon 2024-08-25 23:07:48 UTC
        RTC time: Sun 2024-08-25 18:07:48
       Time zone: America/Lima (-05, -0500)
     NTP enabled: yes
NTP synchronized: yes

La causa

Durante la instalación de Grid Infrastructure, Oracle guarda la información de la zona horaria en un archivo, y lo que contenga este archivo es a lo único a lo que le hace caso, de allí que el sistema operativo pueda ser configurado con una nueva zona horaria, pero el software Oracle siga operando con la zona horaria original, causando las discrepancias en las aplicaciones.

Revisamos el contenido de este archivo y bingo! Encontramos que la zona horaria que está usando Grid Infrastructure es en realidad: UTC (ver línea 19).

[root@node1 ~]# cd $ORACLE_HOME/crs/install

[root@node1 install]# cat s_crsconfig_node1_env.txt
#########################################################################
#This file can be used to set values for the NLS_LANG and TZ environment
#variables and to set resource limits for Oracle Clusterware and
#Database processes.
#1. The NLS_LANG environment variable determines the language and
#   characterset used for messages. For example, a new value can be
#   configured by setting NLS_LANG=JAPANESE_JAPAN.UTF8
#2. The Time zone setting can be changed by setting the TZ entry to
#   the appropriate time zone name. For example, TZ=America/New_York
#3. Resource limits for stack size, open files and number of processes
#   can be specified by modifying the appropriate entries.
#
#Do not modify this file except as documented above or under the
#direction of Oracle Support Services.
#########################################################################
TZ=UTC
NLS_LANG=AMERICAN_AMERICA.AL32UTF8
CRS_LIMIT_STACK=2048
CRS_LIMIT_OPENFILE=65536
CRS_LIMIT_NPROC=65536
TNS_ADMIN=

La solución

El primer paso consiste en editar el archivo, registrando la zona horaria correcta, que para nuestro caso viene a ser: America/Lima.

[root@node1 install]# grep 'TZ=' s_crsconfig_node1_env.txt
TZ=UTC

[root@node1 install]# sed -i 's/TZ=UTC/TZ=America\/Lima/' s_crsconfig_node1_env.txt

[root@node1 install]# grep 'TZ=' s_crsconfig_node1_env.txt
TZ=America/Lima

Lamentablemente hay que reiniciar los servicios de Grid Infrastructure, pero es necesario porque el archivo que acabamos de modificar es leído solamente al momento de arrancar.

[root@node1 ~]# crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'node1'
CRS-2673: Attempting to stop 'ora.crsd' on 'node1'
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on server 'node1'
CRS-2673: Attempting to stop 'ora.qosmserver' on 'node1'
CRS-2673: Attempting to stop 'ora.chad' on 'node1'
. . .
CRS-2673: Attempting to stop 'ora.gpnpd' on 'node1'
CRS-2677: Stop of 'ora.gpnpd' on 'node1' succeeded
CRS-2677: Stop of 'ora.gipcd' on 'node1' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'node1' has completed
CRS-4133: Oracle High Availability Services has been stopped.

[root@node1 ~]# crsctl start crs
CRS-4123: Oracle High Availability Services has been started.

Finalmente, comprobamos que la aplicación ya muestra la hora correcta, no hay más diferencias.

¿Estuvo fácil no? Desde luego todo esto se hubiera evitado si, en primer lugar, se hubiese verificado que la zona horaria del computador era la correcta, antes de iniciar la instalación y configuración de Grid Infrastructure.

Para complementar lo aquí mostrado, les recomiendo la lectura de las notas:

1209444.1How To Change Timezone for Grid Infrastructure
1390015.1Incorrect SYSDATE shown when connected via Listener in RAC
¿Te pareció interesante este artículo?, ¿te quedaron algunas dudas?, ¿quieres sugerirme un tema a tratar?, pues déjame tus comentarios o ¡contáctame ahora mismo!

Una respuesta

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Posts Relacionados

Aprenda a resolver y evitar el error ORA-01017 cuando tenga implementado Oracle Data Guard con wallet.
Aprenda a identificar la fila involucrada en la ocurrencia del evento de espera "enq: TX - row lock contention"
Aprenda a resolver el error CRS-2304 GPnP profile signature verification failed al iniciar una base de datos 11.2 en un cluster 19c.

¿Necesitas Ayuda?

Completa estos datos y estaré en contacto a la brevedad.