Cambio horario y servidores horarios de la red

El cambio horario y los servidores horarios de la red afectan a la hora actual de la máquina servidor. En servicios de movimiento de datos, las indicaciones de la hora se utilizan para determinar cuándo los servidores comprueban si hay datos nuevos y cuándo efectúan el movimiento de datos. Los cambios en el reloj del sistema afectan a los componentes de servicios de datos y a su rendimiento aparente.

El movimiento manual del reloj del sistema también afecta a la hora. El comportamiento del sistema se ve afectado del mismo modo, independientemente del método utilizado para mover el reloj. Se producen retrasos no deseados en los servicios de movimiento de datos cuando se retrasa el reloj del sistema. No se producen retrasos cuando el reloj del sistema se adelanta, aunque los componentes de servicios de movimiento de datos obtendrán antes los intervalos planificados.

Efecto de cambiar la hora en los componentes

Si el reloj del sistema se atrasa, las indicaciones de la hora internas se establecerán en una hora futura en los componentes afectados, pero el reloj del sistema se establecerá en una hora pasada. El cambio en el reloj del sistema afectará a sí mismo, a las indicaciones de la hora internas y a los parámetros que indican intervalos.

Si el reloj del sistema se adelanta, las indicaciones de la hora internas se establecerán en una hora pasada en los componentes afectados y la indicación de la hora actual del reloj del sistema se establecerá en una hora futura. Esto es parecido al comportamiento normal del reloj del sistema; la diferencia es que se verán afectadas algunas medidas horarias que incluyen la determinación de la siguiente ejecución planificada o la determinación del ciclo de vida de un registro de base de datos. El tiempo transcurrido actual será inferior al tiempo transcurrido calculado.

Ejemplo: un registro debe permanecer en el sistema durante 24 horas una vez cumple las condiciones para ser suprimido. Supongamos que un registro cumple las condiciones para ser suprimido a las 3 de la tarda del jueves. En este momento, debido a la política de retención de 24 horas, el registro puede suprimirse en cualquier momento a partir de las 3 de la tarde del miércoles. Además, suponga que a las 3:01 de la tarde del martes el reloj del sistema se adelanta a las 3:01 de la tarde del viernes siguiente. De este modo, aunque sólo haya pasado 1 minuto de tiempo real transcurrido, el tiempo transcurrido en el sistema será 3 días y 1 minuto y se habrá cumplido el período de retención de 24 horas para ese registro. Esto significa que debido al cambio horario, el registro se puede eliminar más rápidamente que si no se hubiera cambiado el reloj del sistema.

Otro ejemplo: un componente concreto ETL se ejecuta cada 24 horas e, inmediatamente después, el reloj del sistema se adelanta 26 horas. En lugar de esperar el requisito previo de 24 horas en tiempo real antes de la próxima ejecución, el componente ETL se iniciará nuevamente lo más pronto posible. Esto se debe a que el sistema calcula que han pasado al menos 26 horas desde la última ejecución. Efectivamente, al adelantar el reloj ha disminuido el intervalo de ETL en este caso. El componente ETL se reanudará normalmente después de esta ejecución al intervalo definido siempre que no se efectúen otros cambios en el reloj del sistema.

Los apartados siguientes se centran sólo en retrasar el reloj después de que los componentes hayan estado en ejecución antes de retrasar el reloj.

El componente Capture seguirá capturando los cambios realizados en cualquier tabla que se esté rastreando. Se utiliza un cálculo de tiempo para determinar cuándo deben comprometerse estos cambios y hacerlos disponibles para los componentes Apply y Ciclo de vida fuente. El componente Capture probablemente ha marcado internamente una indicación futura de la hora. No se comprometerá la transacción hasta que el reloj interno sea mayor que la indicación interna de la hora marcada, además de algunos parámetros internos para el intervalo entre compromisos. En este caso, si el reloj del sistema se ha retrasado 1 hora, el peor resultado es que cualquier transacción que se produzca en la nueva hora no estará disponible hasta que haya transcurrido esa hora. Si el reloj se estableciera en 1 año en el pasado, el sistema tardaría un año en ponerse al corriente.
Nota: el componente Capture se confirma tras un número preestablecido de transacciones; el valor predeterminado es 120. Es posible que los datos estén disponibles para los componentes Apply y Ciclo de vida fuente antes de lo definido.

El componente Apply también mantiene una identificación interna de la hora que determina cuándo se comprobará si existen registros nuevos. En este escenario, esta identificación interna de la hora será mayor que la identificación actual de la hora del sistema. El componente Apply espera hasta que la identificación de la hora del sistema alcanza la identificación interna de la hora, aunque haya registros nuevos disponibles. Cuando se alcance la identificación actual de la hora, este componente empezará a buscar registros disponibles para el desplazamiento de datos.

Las indicaciones de la hora no determinan qué filas se van a duplicar. Esto viene determinado por un valor interno que no se ve afectado por el reloj del sistema. Los componentes Ciclo de vida fuente y Ciclo de vida destino también utilizan indicaciones de la hora para determinar cuándo deben iniciarse y qué registros se pueden podar.

El componente Ciclo de vida fuente en el servicio de movimiento de datos de estado a tiempo de ejecución sólo utiliza indicaciones de la hora para determinar cuándo debe iniciarse. No utiliza indicaciones de la hora para determinar qué debe podarse. Este componente en este servicio no da soporte a la característica de política de retención que permite que la información que puede podarse exista durante un cierto período de política de retención. Sin embargo, esta característica existe en el componente Ciclo de vida fuente del servicio de movimiento de datos de tiempo de ejecución a histórica. Algunos registros no cumplen con los criterios de la política de retención hasta que el reloj del sistema actual se pone al corriente. Los componentes Ciclo de vida destino en ambos servicios de movimiento de datos dan soporte a la definición de la política de retención para que cualquier cambio horario afecte al momento en que se ejecutan y a lo que podan.

Los componentes ETL utilizan indicaciones de la hora como parte de su planificación interna. Una vez iniciados, estos componentes esperan que aumente el tiempo. Cuando el reloj del sistema se atrasa, la planificación ETL se ve afectada y no se lleva a cabo ninguna operación ETL hasta que el sistema se pone al corriente.

Los escenarios posibles para la hora del reloj del sistema son:

Recuperación

No debería ser necesario efectuar una recuperación durante un cambio efectuado por un servidor horario porque los diferenciales horarios deberían ser muy pequeños, sólo unos minutos. El efecto será un pequeño período de tiempo en el que no pasa nada mientras los componentes se ponen al corriente. Durante un cambio horario, debido al cambio al horario de verano, retrasar la hora provoca que los componentes detengan la duplicación durante una hora, tras la cual los componentes necesitarán ponerse al corriente con el sistema. Esto puede ser un problema o no según el sistema.

Un escenario en el cual esta espera podría ser significativa es cuando la hora del sistema se adelanta mucho por equivocación mientras se ejecutan los servidores del componentes. A continuación (independientemente de si los servidores están en ejecución), la hora se restaura a la hora actual. En este caso, los componentes habrían establecido sus indicaciones internas de la hora en el futuro, pero se ejecutarán en el período de tiempo actual. Habrá una larga demora antes de que el servicio de movimiento de datos procese filas nuevamente. Esta demora podría provocar una modificación del sistema que podría afectar al tiempo de recuperación. El administrador podría tener que adoptar una acción correctora.

Acción correctora

Una opción consiste en sencillamente forzar que los componentes Capture y Apply inicien una renovación completa y, a continuación, actualicen las indicaciones internas de la hora para los componentes Ciclo de vida fuente, Ciclo de vida destino y ETL.
  1. Identifique todas las bases de datos que se ejecutan en el servidor en el que se ha adelantado la hora y luego se ha retrasado. Hay dos posibilidades: de estado y de tiempo de ejecución o bien de tiempo de ejecución e histórica.
  2. Detenga todos los servidores que den soporte a los servicios de movimiento de datos en los sistemas afectados. Durante este proceso, se modificarán parámetros internos y algunos componentes pueden no encontrarse sincronizados si se permite su ejecución. Si desea obtener más información, consulte el apartado Inicio y detención de un servicio de movimiento de datos.
  3. Modifique las indicaciones internas de la hora de los componentes Ciclo de vida fuente y Ciclo de vida destino.
    Nota: esta acción puede cambiar de un release a otro.
    1. Actualización de las indicaciones de la hora de poda del Ciclo de vida fuente. Esto modificará los valores para todos los componentes del Ciclo de vida fuente que den servicio a todos los modelos de magnitudes empresariales del sistema.
      Verifique los valores actuales:
      connect to <base_datos_origen>
      SELECT PC.TABLE_NAME, PC.RETENTION_IN_MINUTES, PC.LAST_PRUNED, PC.PRUNE_INTERVAL, CURRENT TIMESTAMP as "CURRENT TIMESTAMP"
      FROM WBIRMADM.RMPRUNECTRL PC
      WHERE PC.TABLE_NAME LIKE 'APP%'
      Nota: revise los valores de LAST_PRUNED, PRUNE_INTERVAL y CURRENT TIMESTAMP. Decida si desea efectuar la poda inmediatamente o en el intervalo siguiente.
      -- Para ejecutarse lo antes posible
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES)
      WHERE TABLE_NAME LIKE 'APP%';
      -- Para ejecutarse en el intervalo siguiente
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp)
      WHERE TABLE_NAME LIKE 'APP%';
      connect reset;
    2. Actualización de las indicaciones de la hora de poda del Ciclo de vida destino.
      CONNECT TO <base_datos_destino>
      SELECT PC.TABLE_NAME, PC.RETENTION_IN_MINUTES, PC.LAST_PRUNED, PC.PRUNE_INTERVAL,
      CURRENT TIMESTAMP as "CURRENT TIMESTAMP"
      FROM WBIRMADM.RMPRUNECTRL PC
      WHERE PC.TABLE_NAME NOT LIKE 'APP%';
      Nota: revise los valores de LAST_PRUNED, PRUNE_INTERVAL y CURRENT TIMESTAMP. Decida si desea efectuar la poda inmediatamente o en el intervalo siguiente.
      -- Para ejecutarse lo antes posible
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES)
      WHERE TABLE_NAME NOT LIKE 'APP%';
      -- Para ejecutarse en el intervalo siguiente
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp)
      WHERE TABLE_NAME NOT LIKE 'APP%';
    3. Actualización de la planificación de ETL.
      Nota: esto afectará a todas las actividades de ETL de todos los modelos.
      CONNECT TO <DESTINO>
      -- Esta consulta muestra
      SELECT TARGETTABLE, TGT_RM_SPETL_NAME, ETL_0_MINUTES, NEXTSTARTTIME, LASTUPDATED,
      CURRENT TIMESTAMP as "CURRENT TIMESTAMP" FROM WBIRMADM.RMCONTROL;
      Nota: los valores ETL_0_MINUTES, NEXTSTARTTIME y LASTUPDATED en comparación con CURRENT TIMESTAMP.
      -- Para ejecutarse en el intervalo siguiente
      UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)=
      (CURRENT TIMESTAMP + ETL_0_MINUTES MINUTES, CURRENT TIMESTAMP);
      -- Para ejecutarse lo antes posible
      UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)=
      (CURRENT TIMESTAMP,CURRENT TIMESTAMP-ETL_0_MINUTES MINUTES);
      CONNECT RESET
    4. Fuerce una renovación completa. La manera más sencilla de forzar una renovación completa de los servidores Capture y Apply de duplicación es copiar y modificar los scripts StartCapture para cada modelo de magnitudes empresariales. Busque todos los scripts StartCapture para cada modelo desplegado en el sistema (si ha seguido las instrucciones del apartado de consolidación de los scripts de inicio y detención, sólo tiene que buscar los mandatos asncap) y añada el parámetro: STARTMODE=COLD al final de la línea de mandatos.
      Nota: una renovación completa es un caso extremo y puede ocasionar un rendimiento bajo mientras dure la renovación. Esto se debe a que la renovación completa añade una actividad general adicional que no está presente generalmente durante las operaciones de servicio de datos normales. Por ello, es importante que la renovación completa no se lleve a cabo en períodos de gran utilización del sistema. El rendimiento durante una renovación completa depende en gran manera del tamaño de los datos en la base de datos fuente de un servicio de movimiento de datos.

      Ejemplo:

      Antes:
      db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="."
      Después:
      db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="." STARTMODE=COLD
      A continuación, inicie todos los scripts. Esta renovación completa causará que los componentes Capture y Apply restablezcan todas sus indicaciones internas de la hora, pero incurrirá en un coste adicional debido al desplazamiento y reproceso de los datos. Es importante planificar disminuciones de rendimiento potenciales mientras el sistema se pone al corriente.

Copyright IBM Corporation 2005, 2006. Reservados todos los derechos.