En el 2019 decidieron en Chile que el ajuste horario de invierno sería de 5 meses, en lugar de los 3 meses habituales. También Marruecos decidió mover su hora respecto al GMT de +00 a +01.

Estos cambios que quizás pienses que no te afectan lo más mínimo, salvo que vivas en Chile o Marruecos, se deberían aplicar a los sistemas de tiempo de la base de datos. Ten en cuenta que estos cambios NO se instalan en los parches Release Upgrade convencionales, y como intentes hacer expdp/impdp con versiones distintas, te fallará.

DST significa Daylight Savings Time, y supone una complejidad en los sistemas informáticos porque:

  • En un ajuste horario a otoño, la misma hora sucede dos veces.
  • En el ajuste horario de primavera, desaparece una hora.
  • En cada región, estas situaciones pueden darse en distintos momentos (o no suceder).
  • Los cambios en estos sistemas horarios responden a decisiones gubernamentales, políticas o religiosas.

 

Cada año hay alguna novedad en el DST. En la Comunidad Europea se votó a favor de salir del DST, pero en la segunda votación en el Consejo Europeo, la moción fracasó. De haber salido adelante hubiera supuesto un cambio importante en la gestión horaria de todas las aplicaciones europeas. Hay que considerar que actualmente un 60% de los países en el mundo están bajo los ajustes de DST.

¿Cómo se gestiona todo esto en una base de datos Oracle? ¿Qué ocurre cuando el servidor está en una zona horaria, pero los clientes en otra? ¿Cómo es posible manejar distintas gestiones horarias para el mismo instante de tiempo?

Pues, en el caso de que las aplicaciones utilicen columnas de tipo DATE y la función SYSDATE, el valor que manejarán será siempre el del servidor, y toda la casuística de ajuste horario deberá hacerse en la aplicación. De hecho, antes de Oracle9i el lenguaje SQL no es sensible a los husos horarios.

En la actualidad, disponemos de tipos de datos específicos que manejan no sólo la hora con el huso horario, sino que permiten gestionar también el horario local: Se trata de TIMESTAMP WITH TIMEZONE (se almacena internamente como UTC) y TIMESTAMP WITH LOCAL TIMEZONE.

Además, también es posible manejar:

  • La zona horaria del usuario: SESSIONTIMEZONE
  • La zona horaria del servidor: DBTIMEZONE
  • Convertir una fecha de una zona horaria a otra con la función FROM_TZ, o extraer la fecha en UTC (formato Universal) con SYS_EXTRACT_UTC, o utilizar conversiones con CAST(valor AS TIME ZONE … AS TIMESTAMP).

Por lo tanto, si tus bases de datos son utilizadas por varios países, la recomendación es dejar de utilizar SYSDATE para utilizar SYSTIMESTAMP, LOCALTIMESTAMP o CURRENT_TIMESTAMP.

¿Debo migrar el DST de mi base de datos?

Pues la decisión es tuya, pero has de tener en cuenta que actualizar el DST implica hacer un upgrade de la base de datos y requiere parada. Debes tener también en cuenta que los datos de un DST de versión reciente no se podrán exportar/importar a una base de datos que tenga un DST anterior.

Para ayudarte a decidir, también es importante que puedas echar un ojo a aquellas tablas que se van a ver afectadas.

Para ello, cuando se invoca el BEGIN_PREPARE(versión) del paquete DBMS_DST, éste proporciona información en la tabla SYS.DST$AFFECTED_TABLES y ésto nos premitirá evaluar tanto el número de tablas afectadas de cada usuario y el número de filas afectadas.

 

SQL> desc dst$affected_tables
Nombre ┐Nulo? Tipo
----------------------------------------- -------- ----------------------------
TABLE_OWNER   NOT NULL VARCHAR2(128)
TABLE_NAME    NOT NULL VARCHAR2(128)
COLUMN_NAME   NOT NULL VARCHAR2(4000)
ROW_COUNT     NUMBER
ERROR_COUNT   NUMBER

 

En paralelo, podremos obtener más información sobre estos casos en las tablas DST$ERROR_TABLE y DST$TRIGGER?TABLE.

Si lo vemos todo correcto, el procedimiento para migrar el DST es el siguiente:

  • Parar la base de datos, incluyendo todas las instancias si se trata de un RAC.
  • Arrancar en modo UPGRADE.
  • Lanzar el DBMS_DST.BEGIN_UPGRADE(version);
  • Reiniciar la base de datos en modo NORMAL.
  • Lanzar el DBMS_DST.UPGRADE_DATABASE y END_UPGRADE.

Para más información, en esta nota de soporte tienes todos los detalles.

Primary Note DST FAQ : Updated DST Transitions and New Time Zones in Oracle RDBMS and OJVM Time Zone File Patches (Doc ID 412160.1)

Share This