none
[SSIS] arrêt du flux de données sans erreur RRS feed

  • Question

  • Bonjour,

     

    J'ai un gros problème avec SSIS : il m'arrive dans plusieurs packages que le flux de données s'arrête, et ce sans me sortir aucune erreur, SSIS arrête juste toute activité, sans que j'arrive à savoir pourquoi.

    Il n'y a pas de problème de ressources machine (ce qui aurait provoqué une erreur de toute façon), et dans l'onglet "Execution Results" le dernier message pour la tâche en question est juste "Execute Phase is beginning".

    Pour info la tâche est simple (une requête qui retourne environ 20 000 lignes, puis une tâche d'exécution SQL qui fait un update), et le flux s'arrête à 9557 lignes. Mais je rencontre le même problème sur d'autres packages, avec un nombre de ligne auquel SSIS s'arrete qui varie (d'un package à l'autre et même d'une exécution à l'autre).

     

    Si quelqu'un pouvait m'aider, je lui en serais très reconnaissant !

     

    Guillaume.

    jeudi 25 octobre 2007 14:32

Réponses

  • Non les lignes n'étaient pas insérées dans la base destination (dans le cas d'une OLE DB Destination)

    Mais en desactivant le fastload sur la destination, cela fonctionne, apparemment cette fonction avait locké la table en question, d'où l'arrêt du flux puisqu'elle n'était jamais délockée.

    Merci pour cette bonne piste !

    vendredi 26 octobre 2007 08:21

Toutes les réponses

  • Guillaume,

     

    Le fait que le flux fasse une pause au bout de 9557 lignes est "normal". En effet, cela correspond au nombre de lignes que ton dataflow est en mesure de traiter simultanément (propriété DefaultMaxBufferRows de la dataflow task).

    Il suffit normalement d'être quelque peu patient...

     

    Grégory.

    http://sqlserver2K5.blogspot.com

     

    jeudi 25 octobre 2007 14:44
  •  

    Je vois bien une corrélation entre mon problème et la taille du buffer, mais la patience n'y fait rien : en mettant un top 5000 dans ma source de données, la tâche s'exécute en 1 seconde. Mais sans ça j'ai laissé tourner le package toute une nuit sans qu'il débloque des 9557 lignes en question ! y aurait-il un problème lorsqu'il essaye de vider le buffer ? Si oui comment résoudre ce problème ? En tout cas après test, la modification de la taille du buffer ne change rien d'autre que le nombre de lignes au bout duquel ça se bloque.

    jeudi 25 octobre 2007 15:20
  •  

    Quelle type de source de données est interrogée ?

    Que deviennent ensuite ces lignes; elle sont insérées dans une table ?

     

    Grégory.

    http://sqlserver2K5.blogspot.com

    jeudi 25 octobre 2007 15:28
  •  

    En source j'ai une requête sur une source OLE DB, SQL Server 2005.

    Les données sont insérées directement via une destination OLE DB, SQL Server 2005 (mais j'ai le même problème avec un objet OLE DB command : update sur une base SQL Server 2005)

    jeudi 25 octobre 2007 16:42
  • Etrange, jamais rencontré ce type de problème côté SSIS...

     

    Les 9557 lignes sont correctement insérées sur la base en destination ? Tu as activé le fastload sur la destination OleDB ?

    Peut-être un problème de lock sur une des tables...

    Tu peux aussi toujours essayer de lancer un SQL Profiler pour voir ce qui se passe.. 

    vendredi 26 octobre 2007 07:35
  • Non les lignes n'étaient pas insérées dans la base destination (dans le cas d'une OLE DB Destination)

    Mais en desactivant le fastload sur la destination, cela fonctionne, apparemment cette fonction avait locké la table en question, d'où l'arrêt du flux puisqu'elle n'était jamais délockée.

    Merci pour cette bonne piste !

    vendredi 26 octobre 2007 08:21
  •  

    Par contre ça ne résoud pas mon problème pour le cas d'une commande OLE DB...

    J'ai apr exemple le même problème avec un update qui s'arrête aux environs de 70 000 lignes, toujours sans raison apparente. La requête source retourne dans les 250 000 lignes. Peut-il y avoir un blocage car j'ai c'est la table que j'ai en source sur laquelle je veux faire mon update ? SSIS devrait savoir gérer ça non ?

    vendredi 26 octobre 2007 12:16
  • Ca ressemble quand même drôlement à un problème de lock sur la table.

     

    Essaye de lancer sp_who2 sur ton serveur pour le vérifier.

     

    Grégory.

    http://sqlserver2K5.blogspot.com

    vendredi 26 octobre 2007 13:56