La tâche de flux de données SSIS se bloque lors de l'exécution de la phase de pré-exécution
J'ai une tâche de flux de données qui est suspendue à l'exécution.
Le flux est simple, effectue deux requêtes sur différentes tables (les deux avec quelques jointures), trie et fusionne ensuite les otuput par un identifiant commun, ajoute une colonne statique à tous les enregistrements, enregistre le nombre de lignes dans un utilisateur. variable pour une utilisation ultérieure et finalement insère dans une table sur une autre base de données. Nous utilisons OLE les sources et destinations de base de données. La source est MSSQL 2000 et la destination est MSSQL 2012.
Symptômes:
Informations: 0x40043006 à la table de chargement Sandbox, SSIS.Pipeline: la phase de préparation à l'exécution commence.
Information: 0x40043007 dans la table de chargement de bac à sable, SSIS.Pipeline: la phase de pré-exécution commence .
Et rien de plus jusqu'à ce que l'exécution soit arrêtée .
Solutions échouées:
SET FMTONLY OFF;
SET NOCOUNT ON;
ajouté au début.
Bits supplémentaires:J'espère vraiment que quelqu'un pourra m'aider. Je suis assez nouveau sur SSIS, c’est la première fois que je l’utilise. Je travaille habituellement avec Pentaho pour mon ETL, mais le client a besoin de la solution pour être mise en œuvre sur SSIS. Je me bats avec ce problème depuis quelques jours maintenant et je commence à manquer d’idées pour le résoudre.
Lorsqu'il est exécuté en ligne de commande, il reste bloqué et le résultat suivant s'affiche:
Progress: 2013-03-19 14:36:26.21
Source: Load Sandbox Table
Validating: 0% complete
End Progress
Progress: 2013-03-19 14:36:26.21
Source: Load Sandbox Table
Validating: 12% complete
End Progress
Progress: 2013-03-19 14:36:26.22
Source: Load Sandbox Table
Validating: 25% complete
End Progress
Progress: 2013-03-19 14:36:26.22
Source: Load Sandbox Table
Validating: 37% complete
End Progress
Progress: 2013-03-19 14:36:26.23
Source: Load Sandbox Table
Validating: 50% complete
End Progress
Progress: 2013-03-19 14:36:26.25
Source: Load Sandbox Table
Validating: 62% complete
End Progress
Progress: 2013-03-19 14:36:26.25
Source: Load Sandbox Table
Validating: 75% complete
End Progress
Progress: 2013-03-19 14:36:26.25
Source: Load Sandbox Table
Validating: 87% complete
End Progress
Progress: 2013-03-19 14:36:26.25
Source: Load Sandbox Table
Validating: 100% complete
End Progress
Warning: 2013-03-19 14:36:26.26
Code: 0x80047076
Source: Load Sandbox Table SSIS.Pipeline
Description: The output column "ITEM_OID (1)" (47) on output "Merge Join Outp
ut" (28) and component "Merge Join" (11) is not subsequently used in the Data Fl
ow task. Removing this unused output column can increase Data Flow task performa
nce.
End Warning
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 0% complete
End Progress
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 12% complete
End Progress
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 25% complete
End Progress
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 37% complete
End Progress
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 50% complete
End Progress
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 62% complete
End Progress
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 75% complete
End Progress
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 87% complete
End Progress
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 100% complete
End Progress
Progress: 2013-03-19 14:36:26.31
Source: Load Sandbox Table
Pre-Execute: 0% complete
End Progress
Progress: 2013-03-19 14:36:26.31
Source: Load Sandbox Table
Pre-Execute: 12% complete
End Progress
Progress: 2013-03-19 14:36:26.31
Source: Load Sandbox Table
Pre-Execute: 25% complete
End Progress
Progress: 2013-03-19 14:36:26.34
Source: Load Sandbox Table
Pre-Execute: 37% complete
End Progress
Progress: 2013-03-19 14:36:45.69
Source: Load Sandbox Table
Pre-Execute: 50% complete
End Progress
Après cela, il gèle à nouveau.
SOLUTION(En affichant ceci ici parce que je ne peux pas répondre à ma propre question avant 5 heures supplémentaires, je le ferai quand j'aurai le droit.)
Je l'ai finalement eu.
Il s'avère que la validation pose un problème, mais ce ne sont pas seulement les éléments SSIS qui subissent cette validation, comme indiqué dans la quatrième solution manquée de la question.
Les CONNECTIONS sont également validées et possèdent leur propre propriété de validation de retard, qui doit être définie sur true.
Après cela, le temps d’exécution est passé de plus de 40 minutes ou plus à moins d’une minute pour le processus complet (il s’agit simplement d’une étape d’un processus beaucoup plus important)
J'espère que les personnes ayant le même problème trouveront facilement cette solution car beaucoup de personnes se heurtent à ce problème et quasiment aucune solution n'est en ligne.
En un mot: Vérifiez que tous les éléments impliqués dans la tâche, y compris les connexions à la base de données, ont la propriété Vérification du délai définie sur True.
Je l'ai finalement eu. Il s'avère que la validation pose un problème, mais pas seulement les éléments SSIS passent par cette validation, comme indiqué dans la quatrième solution ayant échoué à la question . Les connexions sont également validées et possèdent leur propre propriété de validation du retard. , qui doit être défini sur true. Après cela, le temps d’exécution est passé de plus de 40 minutes ou plus à moins d’une minute pour l’ensemble du processus (il s’agit simplement d’une étape d’un processus beaucoup plus important) J'espère que les personnes ayant le même problème pourront le trouver solution facilement parce que beaucoup de gens se heurtent à ce problème et quasiment aucune solution mise en ligne.
En un mot: Vérifiez que la propriété Vérification du délai de tous les éléments impliqués dans la tâche, y compris les connexions à la base de données, est définie sur True.
J'ai eu les mêmes symptômes mais définir la validation du délai sur True sur chaque composant n'a pas résolu mon problème.
Je l'ai résolu en remplaçant la méthode OLE DB de table ou de vue par commande SQL.
cordialement.
Correction de mon problème en changeant le mode d'accès aux données sur Commande SQL et en collant ma vue dans le texte de la commande SQL dans la source de base de données OLE.
Je sais que c'est vieux, mais je viens de trouver un lien à ce sujet qui pourrait aider. Personnellement, j'utilise une vue pour simplement exporter des données vers une base de données externe, et la validation des données prend trop de temps pour valider la vue.
la partie importante de ceci est la réponse de Microsoft
Publié par Microsoft le 28/04/2008 à 14h45
C'est un problème connu et le résultat de la conception actuelle.
Il existe 2 façons d'extraire des données d'une vue dans la source de base de données OLE:
Utiliser la méthode d'accès "Table ou vue"
Utilisez la méthode d'accès "Commande SQL" et entrez une requête "select * from ***"
Un plan d'exécution différent est généré dans les deux approches.
Celui utilisé dans le premier n’est pas aussi efficace que le dernier.
Si vous rencontrez des problèmes de performances lorsque vous utilisez la première approche, vous pouvez passer à la seconde comme solution de contournement.
Nous avons également blogué ce numéro -> http://blogs.msdn.com/sqlperf/archive/2007/04/29/set-up-ole-db-source-to-read-from-view-efficiently. aspx .
Comme il s'agit d'un élément "de conception" et que nous pensons qu'il existe un moyen de contourner le problème, nous ne fournirons aucun changement pour le moment. En conséquence, nous fermons le dossier associé à votre soumission. Si vous n'êtes pas d'accord, n'hésitez pas à soumettre à nouveau.
Nous apprécions votre temps, vos efforts et votre soutien envers SSIS.
J'espère que ça aide quelqu'un. J'essayais d'utiliser cette source de base de données OLE pour exécuter un SP avec un paramètre. Je n’en ai pas eu besoin pour retourner quoi que ce soit, alors j’ai laissé cette partie de côté. Mais il ne m'a pas laissé faire, il a crié "aucune information de colonne n'a été renvoyée par le SQL". Donc configuré une instruction SQL factice dans mon SP, que je mets à jamais vrai. Mais elle n’a jamais eu cette colonne en sortie et le travail a été suspendu à la phase de pré-exécution. J'ai donc changé ce test pour qu'il soit toujours vrai, il a renvoyé la colonne et hop. Je ne fais rien avec la colonne, mais je suppose que c'est nécessaire là-bas.
Nos validations différées étaient déjà définies sur True et ne pouvaient/ne voulaient pas le changer en une instruction SQL.
Je suis tombé sur ValidateExternalMetadata dans les flux de données que j'ai changé en False et qui semble fonctionner comme un champion.
J'ai vérifié les étapes de OP et il mentionne qu'ils l'ont fait à l'étape 5
Une autre chose à essayer, apparemment, est de cocher la case "Utiliser le runtime 32 bits" - c’est-à-dire si vous voyez le problème lorsque vous exécutez le package en tant que travail sur votre serveur de base de données (qui est en 64 bits). moins, SQL Server 2008R2). Allez au travail, cliquez avec le bouton droit de la souris sur> Propriétés…> Étapes> cliquez avec le bouton droit de la souris sur l’étape de votre package SSIS> Propriétés…> Général> Options d’exécution (onglet)> Utiliser le runtime 32 bits.
Je voyais ce problème, mais seulement une fois que j'ai déployé le paquet sur le serveur (un fournisseur de journalisation était activé pour que je puisse le voir bloqué après la phase de "pré-exécution"). Il a toujours fonctionné correctement dans BIDS (et correct sur un autre serveur, curieusement… je ne sais toujours pas pourquoi).
Un fil ici m'a informé de cette solution qui semble fonctionner - bien que mon problème se manifeste de façon intermittente, donc YMMV. Il existe également d'autres solutions possibles dans ce fil.
Ce problème est toujours actif avec SQL Server 2012/2014.
Aucune des solutions mentionnées ci-dessus n'a aidé. En fait, rien ne modifiait le délai de validation, ni la configuration de la destination OLD DB Destination ou de la connexion OLE DB.
Lecture du fil à partir de ce lien: https://social.msdn.Microsoft.com/Forums/sqlserver/en-US/35a484c7-4850-4f86-b14a-5dfb50491ab2/long-duration-preexecute-preexecute-phase?forum=sqlintegrs
il est suggéré que le problème vient du plan d'exécution.
Cela était vrai pour mon cas et l'ajout d'une condition 1 = 1 à ma OLE configuration de base de données a forcé le serveur SQL à générer un nouveau plan d'exécution qui corrigeait le problème pour moi.
J'ai rencontré le même problème il y a quelques minutes et les suggestions ci-dessus ne m'ont pas fonctionné (la validation du délai = true semble être la solution idéale). Nous avons récemment découvert quelques problèmes liés au reniflage de paramètres et une fois que j'ai résolu ce problème dans mes procédures stockées, mon package a été exécuté en moins d'une minute. Pensez à vérifier vos procédures stockées pour voir si cela peut en être la cause.