Pour # 1 - il n'y a pas de mécanisme de "redémarrage" inhérent dans SSIS, car pour commencer, il n'y a pas de mécanisme de "démarrage" inhérent. Vous devrez regarder le processus que vous avez géré l'exécution programmée de vos paquets, ce que je suppose pourrait être l'Agent SQL. Par conséquent, les options permettant de déterminer si un travail SQL Agent a échoué et/ou de redémarrer ce travail sont les mêmes, que le contenu du travail soit ou non un package SSIS. Il existe quelques procédures stockées pour surveiller et interroger l'exécution des tâches et les résultats. Vous pouvez également implémenter votre propre mécanisme d'enregistrement du statut du travail/du paquet. SSIS offre des "points de contrôle" pour vous aider à redémarrer les paquets à partir de certains points, mais le consensus général sur cette fonctionnalité est qu'elle est limitée dans son applicabilité - votre kilométrage peut varier. Personnellement, j'inclue toujours une route d'échec dans mon travail pour envoyer un e-mail à quelqu'un en cas d'échec du travail et configurer mes jobs et packages pour qu'ils soient idempotents, c'est-à-dire qu'ils peuvent être réexécutés sans crainte. Ils "réinitialisent" l'environnement (supprimer et recharger), ou ils peuvent détecter exactement où ils se sont arrêtés.
Le point 2 est une question difficile et dépend grandement de votre environnement et de votre scénario. Vous pouvez utiliser des tâches simples comme une tâche d'exécution SQL pour exécuter des commandes "test" qui sont testées pour échouer si des privilèges ou des verrous suffisants existent. Vous pouvez également vous renseigner directement auprès des fournisseurs de services ou d'autres mécanismes afin de déterminer si vous devez prendre des mesures correctives avant d'essayer d'utiliser la viande de votre emballage. Utilisation des contraintes de priorité "en cas d'échec" peut aider avec ce type de logique. Donc, les gestionnaires d'événements peuvent.
très belle réponse, merci! –