Heure d'été et serveurs d'heure réseau

L'heure d'été et les serveurs d'heure réseau ont une incidence sur l'heure en cours d'une machine serveur. Les services de transfert de données utilisent des horodatages afin de déterminer à quel moment les serveurs doivent rechercher de nouvelles données et procéder à des transferts de données. Toute modification de l'horloge système a une incidence sur les composants de services de données et les performances constatées.

Une modification manuelle de l'heure de l'horloge système peut également avoir une incidence sur l'heure. Le comportement du système est affecté de la même manière, quelle que soit la méthode utilisée pour modifier l'heure de l'horloge. Des retards non souhaités des services de transfert de données peuvent se produire lorsque l'heure de l'horloge système est retardée. Aucun retard n'est constaté si l'heure de l'horloge système est avancée, même si les composants de services de transfert de données atteignent plus tôt les intervalles planifiés.

Effets possible en cas de modification de l'heure dans les composants

Si l'heure de l'horloge système est retardée, les horodatages internes des composants affectés seront plus éloignés dans le futur. L'horloge système, les horodatages internes ainsi que les paramètres indiquant des intervalles seront affectés par la modification de l'heure de l'horloge système.

Si l'heure de l'horloge système est avancée, les horodatages internes des composants affectés seront retardés par rapport au temps présent et l'horodatage en cours de l'horloge système sera avancé dans le temps. La situation est semblable au comportement normal de l'horloge système ; la différence est que certaines mesures du temps qui impliquent de déterminer une exécution planifiée à venir, ou de déterminer le cycle de vie d'un enregistrement de base de données, seront affectées. Le temps réellement écoulé sera inférieur au temps écoulé calculé.

Exemple : Un enregistrement doit demeurer sur le système pendant 24 heures après être devenu éligible pour suppression. Supposons qu'un enregistrement devienne éligible pour suppression le mardi à 15 heures. A ce stade, en raison de la règle de conservation de 24 heures, l'enregistrement peut être supprimé à tout moment le mardi après 15 heures. Supposons également que le mardi à 15:01 l'horloge système soit avancée au vendredi suivant à 15:01. Dans ce cas, même si 1 seule minute a passé au cours du temps réellement écoulé, le temps écoulé système sera de 3 jours et 1 minute, et la durée de conservation de 24 heures de cet enregistrement aura été observée. Cela signifie qu'en raison de cette modification de l'heure, l'enregistrement peut être retiré plus rapidement que si l'horloge système n'avait pas été modifiée.

Autre exemple : Un composant d'extraction, de transformation et de chargement particulier s'exécute toutes les 24 heures, et immédiatement après son exécution, l'horloge système saute 26 heures. Au lieu d'attendre les 24 heures requises avant sa prochaine exécution, ce composant redémarrera aussitôt que possible. Ceci est dû au fait que le système a calculé qu'au moins 26 heures ont passé depuis la dernière exécution. Dans ce cas, en effet, le fait d'avancer l'horloge a réduit l'intervalle d'exécution du composant. Si aucune autre modification n'est apportée à l'horloge système, le composant reprend son cours d'exécution normal suivant les intervalles préalablement définis.

Les sections qui suivent traitent uniquement des situations susceptibles de se produire lorsque l'horloge est retardée pour des composants déjà en cours d'exécution.

Le composant Capture continue à capturer des modifications pour toutes les tables dont il effectue le suivi. Un calcul permet de déterminer à quel moment ces modifications doivent être validées et rendues disponibles pour le composant Apply et le composant Source Life Cycle. Le composant Capture a probablement marqué en interne un horodatage en vue d'un usage ultérieur. Il ne validera pas la transaction tant que l'horloge interne n'indique pas une heure postérieure à l'horodatage interne marqué, en plus de certains paramètres internes pour l'intervalle entre les validations. Dans ce cas, si l'horloge système est retardée d'une heure, le pire qui puisse se produire est que les transactions qui s'effectuent au cours de l'heure à venir ne soient pas disponibles avant la fin de cette heure. Si l'horloge était retardée d'une année, le système ne reprendrait son cours normal qu'au bout d'un an.
Remarque : Le composant Capture ne valide qu'au bout d'un certain nombre prescrit de transactions (120, par défaut). Il est possible que les données soient disponibles plus tôt que prévu pour les composants Apply et Source Life Cycle.

Le composant Apply utilise également un horodatage interne qui détermine le moment où il doit vérifier la présence de nouveaux enregistrements. Dans un tel scénario, cet horodatage interne doit être postérieur à l'horodatage système en cours. Le composant Apply patiente jusqu'à ce que l'horodatage système atteigne son horodatage interne, même si de nouveaux enregistrements sont disponibles. Une fois l'horodatage en cours atteint, le composant commence à rechercher des enregistrements disponibles pour le transfert de données.

Les horodatages ne déterminent pas les lignes à dupliquer. C'est une valeur interne non affectée par l'horloge système qui s'occupe de déterminer cela. Les composants Source et Target Life Cycle utilisent également des horodatages pour déterminer quand démarrer et les enregistrements prêts pour élagage.

Le composant Source Life Cycle du service de transfert de données de la base de données d'état vers la base de données d'exécution a uniquement recours aux horodatages pour déterminer quand démarrer. Il n'utilise pas d'horodatage pour déterminer les enregistrements à élaguer. Ce composant ne prend pas en charge dans ce service la fonction de stratégie de conservation qui permet aux informations éligibles pour élagage d'exister pendant une certaine période définie par cette stratégie. Néanmoins, cette fonction n'existe pas dans le composant Source Life Cycle du service de transfert de données de la base de données d'exécution vers la base de données d'historique. Certains enregistrements ne répondent pas aux critères de la stratégie de conservation tant que l'horloge système en cours n'a pas atteint l'heure définie. Les composants Target Life Cycle de chacun des services de transfert de données supportent la définition de stratégie de conservation, de sorte que toute modification de l'heure a une incidence sur le moment d'exécution et la nature des enregistrements à élaguer.

Les composants d'extraction, de transformation et de chargement utilisent des horodatages dans le cadre de leur planning interne. Une fois démarrés, ces composants s'exécutent en fonction d'un temps qui va croissant. Si l'horloge système est retardée, cela a une incidence sur le planning d'extraction, de transformation et de chargement et aucune opération n'est effectuée jusqu'à ce que le système atteigne l'heure prévue.

Les scénarios possibles pour l'heure de l'horloge système sont les suivants :

Reprise

Une reprise au cours d'une modification effectuée par un Serveur d'horodatage n'est pas nécessaire car les différences doivent être minimes, de l'ordre de quelques minutes. La seule conséquence est un petit laps de temps pendant lequel rien ne se produit le temps que les composants se réajustent. Au cours d'un changement d'heure, en raison du passage à l'heure d'été, si l'heure est retardée, les composants interrompent la réplication pendant une heure, puis doivent se réajuster au système. Cela peut constituer ou non un incident suivant le système.

Cette attente peut être importante dans le cas où une erreur s'est produite et que l'heure système est avancée assez loin dans le temps alors que les serveurs de composant sont en cours d'exécution. Ensuite (que les serveurs soient lancés ou non), l'heure en cours est restaurée. Dans ce cas, les horodatages internes des composants ont été avancés mais ils s'exécutent dans le temps en cours. Un long laps de temps peut s'écouler peut se passer avant que les processus de service de transfert de données ne reprennent le traitement de lignes. Ce laps de temps peut provoquer une accumulation sur le système et avoir une incidence sur le temps de reprise. L'administrateur doit alors prendre des mesures correctives.

Mesure corrective

Une option consiste à simplement forcer les composants Capture et Apply à démarrer ne régénération intégrale, puis à mettre mettre à jour les horodatages internes pour les composants Source Life Cycle, Target Life Cycle et ETL.
  1. Identifiez toutes les bases de données qui s'exécutent sur le serveur ou l'heure a été avancée puis retardée. Deux possibilités : Base de données d'état et d'exécution et base de données d'exécution et d'historique.
  2. Arrêtez tous les serveurs prenant en charge les services de transfert de données sur le système concerné. Au cours de ce processus, vous allez modifier des paramètres internes, et certains composants seront peut-être hors synchronisation si ils sont autorisées à s'exécuter. Pour plus d'informations, reportez-vous à la rubrique relative au démarrage et à l'arrêt du service de transfert de données.
  3. Modifiez les horodatages internes des composants Source Life Cycle et Target Life Cycle.
    Remarque : Cet action est susceptible de modification d'une édition à l'autre.
    1. Mise à jour des horodatages d'élagage du composant Source Life Cycle. Cette opération modifie les paramètres pour tous les composants Source Life Cycle qui servent tous les modèles de mesure métier sur le système.
      Vérifiez les paramètres en cours :
      connect to <source_database>
      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%'
      Remarque : Vérifiez les valeurs de LAST_PRUNED and PRUNE_INTERVAL et CURRENT TIMESTAMP. Décidez si l'élagage doit être effectué immédiatement ou au cours du prochain intervalle.
      --
      Pour une EXECUTION si possible immédiate.
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES)
      WHERE TABLE_NAME LIKE 'APP%';
      -- Pour une EXECUTION au prochain intervalle.
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp)
      WHERE TABLE_NAME LIKE 'APP%';
      connect reset;
    2. Mise à jour des horodatages d'élagage du composant Target Life Cycle.
      CONNECT
      TO <base de données_cible>
      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%';
      Remarque : Vérifiez les valeurs de LAST_PRUNED and PRUNE_INTERVAL et CURRENT TIMESTAMP. Décidez if s'il est souhaitable que l'élagage soit effectué immédiatement ou au cours du prochain intervalle.
      -- Pour une EXECUTION si possible immédiate.
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES)
      WHERE TABLE_NAME NOT LIKE 'APP%';
      -- Pour une EXECUTION au prochain intervalle.
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp)
      WHERE TABLE_NAME NOT LIKE 'APP%';
    3. Mise à jour du planning ETL.
      Remarque : Cette opération a une incidence sur toutes les activités ETL de tous les modèles.
      CONNECT TO <TARGET>
      -- Cette requête indique
      SELECT TARGETTABLE, TGT_RM_SPETL_NAME, ETL_0_MINUTES, NEXTSTARTTIME, LASTUPDATED,
      CURRENT TIMESTAMP as "CURRENT TIMESTAMP" FROM WBIRMADM.RMCONTROL;
      Remarque : Les valeurs ETL_0_MINUTES, NEXTSTARTTIME et LASTUPDATED comparées à CURRENT TIMESTAMP.
      -- Pour une EXECUTION au prochain intervalle.
      UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)=
      (CURRENT TIMESTAMP + ETL_0_MINUTES MINUTES, CURRENT TIMESTAMP);
      -- Pour une EXECUTION si possible immédiate.
      UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)=
      (CURRENT TIMESTAMP,CURRENT TIMESTAMP-ETL_0_MINUTES MINUTES);
      CONNECT RESET
    4. Forcez une régénération intégrale. La façon la plus simple pour forcer une régénération intégrale des serveurs Capture et Apply de réplication consiste à copier et à modifier les scripts StartCapture pour chaque modèle de mesure métier. Recherchez chaque script Capture de démarrage pour chaque modèle déployé sur le système (si vous avez suivi les instructions figurant à la section relative à la consolidation des scripts de démarrage et d'arrêt, recherchez simplement chaque commande asncap), et ajoutez le paramètre : STARTMODE=COLD en fin de ligne de commande.
      Remarque : Une régénération intégrale constitue un cas extrême et peut entraîner de faibles performances tout au long de l'opération. Ceci est dû au fait qu'une régénération intégrale ajoute une surcharge supplémentaire qui n'est pas normalement présente au cours des opérations de services de données. Il est donc important qu'une régénération intégrale soit effectuée lorsque le système n'est pas trop sollicité. Les performances d'une régénération intégrale dépendent en grande partie de la taille des données dans la base de données source d'un service de transfert de données.

      Exemple :

      Avant :
      db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="."
      Après :
      db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="." STARTMODE=COLD
      Démarrez ensuite tous les scripts. En raison de la régénération intégrale, les composants Capture et Apply réinitialisent l'ensemble de leurs horodatages internes, sans que cela n'entraîne un coût supplémentaire pour le déplacement et le retraitement des données. Il est important de prévoir des baisses de performances possibles le temps que le système se réajuste.

Copyright IBM Corporation 2005, 2006. All Rights Reserved.