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 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.
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
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%'
-- 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;
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%';
-- 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%';
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;
-- 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
Exemple :
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=COLDDé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.