SSIS Gestion des problèmes externes

Question

J'ai un package SSIS qui fonctionne très bien. Le package fonctionne tous les soirs et prend environ 4 heures. Je suis un newb à SSIS, donc je veux voir ce que mes options. Je ne trouve pas quoi que ce soit sur le web au sujet de ces deux questions, de sorte que tout conseil est grandement apprécié.

1. Que faire quand j'ai un externe émettre comme une puissance échec / redémarrage accidentel. Y a-t-il un moyen d'alerter quelqu'un ou avoir la package commence à nouveau au redémarrage.

2. Il y a deux semaines il y avait un processus qui a obtenu accroché et verrouillé la table, ce qui rend le processus non exécuter. Comment est la meilleure façon de Je manie d'assurer le bon l'accès avant de commencer et si non, obtenir l'accès. Je suis ok avec le meurtre les processus, etc.

Vous cherchez des meilleures infos pratiques. Merci

Answer 1

Pour # 1 - il n'y a pas de mécanisme « de redémarrage » inhérent à SSIS, depuis pour commencer, il n'y a pas de mécanisme « start » inhérente. Vous devrez examiner le processus que vous avez la gestion de l'exécution programmée de vos colis, que je suppose pourrait être l'Agent SQL. Étant donné que, vos options pour déterminer si un travail de l'Agent SQL a échoué, et / ou le redémarrage de ce travail sont les mêmes que le contenu du travail sont des packages SSIS ou non. Il y a bien quelques procédures stockées pour le suivi et l'exécution des requêtes travail et les résultats. Vous pouvez également mettre en œuvre votre propre mécanisme d'enregistrement travail / état de package. SSIS n'offre « points de contrôle » pour vous aider à redémarrer les paquets de certains points, mais le consensus général sur cette caractéristique est qu'elle est limitée dans son application - votre kilométrage peut varier. Personnellement, je toujours inclure une voie d'échec dans mon travail à envoyer un courriel à quelqu'un en cas d'échec du travail et configurer mes emplois et paquets à idempotent - qui est, ils peuvent être recommencée sans crainte de conduire mal deux fois les mêmes opérations. Ils soit « remis à zéro » l'environnement (supprimer et recharger), ou ils peuvent détecter exactement où ils l'avaient laissé.

Point # 2 est une question difficile et dépend en grande partie de votre environnement et 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és à l'échec si des privilèges suffisants ou verrous existent. Ou vous pourriez être en mesure de vous renseigner directement par SPs ou d'autres mécanismes pour déterminer si vous avez besoin de prendre des mesures correctives avant de tenter d'exécuter la viande de votre colis. Contraintes de précédence « en cas d'échec » peut aider à ce genre de logique. Donc, peut Event Handlers.