Checkpoints dans SSIS : reprendre un package au point exact de l'échec

Toute équipe qui maintient encore de l'ETL sur SQL Server Integration Services connaît la scène : un package long — extraction lourde, quelques transformations, plusieurs chargements — échoue à l'avant-dernière task. L'option évidente est de réexécuter le package entier. Le problème, c'est que cela réextrait des données déjà en staging, refait un travail qui avait déjà réussi et, dans les chargements nocturnes, menace de faire déborder la fenêtre de traitement.

Les Checkpoints de SSIS existent précisément pour ça : écrire la progression du package sur disque et, à la réexécution, reprendre au point exact où il s'est arrêté. C'est une fonctionnalité ancienne, stable et sous-utilisée — et elle vaut encore beaucoup dans les portefeuilles legacy qui font tourner des opérations critiques.

Comment ça marche en interne

Quand les checkpoints sont activés, SSIS écrit un fichier XML de checkpoint au début de l'exécution. À chaque task du Control Flow terminée avec succès, il enregistre cette progression (et la valeur courante des variables) dans le fichier. Si le package échoue, le fichier reste sur disque. À l'exécution suivante, SSIS lit le fichier, identifie ce qui a déjà été terminé et reprend à partir de la première task qui n'a pas encore terminé avec succès. Quand le package tourne entièrement sans échec, le fichier est supprimé — et recréé à l'exécution suivante.

Notez la portée : le checkpoint opère au niveau du Control Flow, pas du Data Flow. Autrement dit, la granularité de reprise est la task, pas la ligne de données.

Les 3 étapes de configuration

1) Propriétés du package (Control Flow) :

• SaveCheckpoints = True — active l'écriture du checkpoint.
• CheckpointUsage = IfExists — utilise le fichier s'il existe ; sinon, part du début. (Les autres options sont Never et Always ; Always exige que le fichier existe et échoue s'il n'y en a pas.)
• CheckpointFileName = <chemin du fichier> — l'emplacement du fichier de checkpoint.

2) Un chemin stable pour le fichier :

En développement, un chemin local suffit. En production, utilisez un chemin UNC (\\serveur\share\package.chk) accessible par le compte qui exécute le package (généralement le SQL Server Agent). Un chemin local sur le serveur d'exécution casse souvent quand le package est déplacé ou exécuté par un autre nœud.

3) Propriété des tasks critiques :

• FailPackageOnFailure = True sur chaque task qui doit marquer un point de checkpoint. Sans cela, l'échec de la task n'est pas enregistré comme point de reprise.

Des pièges qui valent de l'or

Le Data Flow est atomique pour le checkpoint. Si un Data Flow échoue en cours de route, la reprise se fait au début de ce Data Flow — pas à la ligne qui a échoué. Isolez donc les chargements coûteux dans leurs propres tasks : ainsi un échec plus loin n'oblige pas à répéter l'extraction lourde précédente.

Les containers demandent une attention supplémentaire. Dans un Sequence Container ou des boucles (For Loop, Foreach Loop), configurez FailParentOnFailure = True sur la task et FailPackageOnFailure = True sur le container. Important : SSIS ne reprend pas au milieu d'une boucle — il redémarre l'itération courante depuis le début. Ne comptez pas sur un checkpoint pour reprendre dans un Foreach au fichier 7 sur 10 ; il reviendra au début de la boucle.

Transactions et checkpoints sont deux choses différentes. Le checkpoint contrôle ce qu'il faut réexécuter ; il ne défait pas ce qui a déjà été écrit. Si une task a déjà inséré des données et que vous reprenez après elle, ces données restent là. Combinez le checkpoint avec l'idempotence (des chargements qui peuvent tourner deux fois sans dupliquer) : staging tronquée par exécution, MERGE par clé, ou contrôle par watermark.

Vous avez modifié le package ? Jetez l'ancien checkpoint. Si vous avez édité le Control Flow entre l'échec et la réexécution, le fichier de checkpoint peut ne plus correspondre à la structure du package. Supprimez-le et repartez de zéro.

Quand l'utiliser (et quand non)

Les checkpoints brillent dans les packages longs, séquentiels et coûteux à retraiter — l'ETL nocturne classique, avec une extraction lente suivie de plusieurs chargements. Pour des packages courts, idempotents et bon marché à réexécuter, la complexité supplémentaire ne vaut rarement la peine : tout relancer est plus simple et plus robuste.

Il vaut la peine de rappeler le contexte de 2026 : Microsoft a pratiquement gelé les nouvelles fonctionnalités de SSIS, et la recommandation pour les nouveaux flux est Fabric Data Factory. Mais des milliers de packages SSIS restent en production, et on peut désormais les orchestrer dans Fabric via l'activité Invoke SSIS Package (Preview), en pointant vers le même SSISDB. Autrement dit : bien maîtriser SSIS — y compris la résilience avec les checkpoints — reste de l'argent en poche pendant que le legacy est modernisé à votre rythme.

Résumé

Les checkpoints transforment « le package a échoué, on relance tout » en « le package a échoué, on reprend où il s'est arrêté ». Trois propriétés sur le package, une sur chaque task critique, un chemin de fichier stable — et vous économisez la fenêtre de chargement, réduisez le retraitement et gagnez en résilience sur des pipelines que le métier ne peut pas se permettre de perdre.