it-swarm.com.de

Der SSIS-Datenflusstask hängt bei der Ausführung der Phase vor dem Ausführen

Ich habe eine Datenflussaufgabe, die an der Ausführung hängt. 
Der Ablauf ist einfach, stellt zwei Abfragen an verschiedene Tabellen (beide mit ein paar Joins), sortiert und führt die otuputs durch eine gemeinsame ID zusammen, fügt allen Datensätzen eine statische Spalte hinzu und speichert die Zeilenanzahl in einem Benutzer Variable für spätere Verwendung und fügt schließlich eine Tabelle in einer anderen DB ein. Wir verwenden DB-Quellen und -Ziel OLE. Quelle ist MSSQL 2000 und Destination ist MSSQL 2012 

Symptome:

  • Bei der Ausführung erhält der Datenfluss das übliche gelbe "laufende" Symbol. Wenn Sie jedoch doppelt klicken, um den Datenfluss anzuzeigen, haben keine Elemente eine gelbe, rote oder grüne Markierung. 
  • Dies dauert lange, zunächst dauerte es etwa 20 Minuten, danach wurde es länger oder es kam einfach nicht mehr.
  • Ausgabe zeigt:
    Information: 0x40043006 at Load Sandbox Table, SSIS.Pipeline: Die Vorbereitungsphase für die Ausführung beginnt.
    Information: 0x40043007 bei Load Sandbox Table, SSIS.Pipeline: Die Phase vor dem Ausführen beginnt .

    Und nichts weiter, bis die Exekution eingestellt ist .
  • Ja, das hat schon mal geklappt. Und ja, wir haben eine einzige Abfrage (in einer gespeicherten Prozedur) verwendet, um diese ETL auszuführen, aber wir wollten alle Schritte zu SSIS migrieren.
  • Fehlgeschlagene Lösungen:

  • Es gibt keine Suchvorgänge.
  • Die Standardpuffergröße für den Aufgabenfluss wurde auf 40485760 und dann auf 80971520 erhöht. 
  • Die maximalen Pufferzeilen für den Task wurden auf 1000000 gesetzt. 
  • Die Überprüfung der Verzögerung wurde für die Aufgabe auf "True" gesetzt. 
  • Alle Elemente innerhalb der Task wurden für "Externe Daten überprüfen" auf "Falsch" gesetzt. 
  • Beide Anfragen hatten:
    FMTONLY OFF einstellen;
    NOCOUNT EINSTELLEN;

    am Anfang hinzugefügt. 
  • Beide Anfragen hatten MAXDOP auf 1 setzen. 
  • 64-Bit-Laufzeit des Projekts auf "False" setzen. 
  • Geänderte Zielladung von Tabelle oder Ansicht zu Tabelle oder Ansicht - Schnelles Laden ohne Sperren oder Einschränkungen. 
  • Setzen Sie die Zeilen pro Stapel für schnelles Laden auf 1000. 
  • In einigen Workarounds wird vorgeschlagen, den Taskfluss in zwei oder mehr Taskflüsse aufzuteilen. Dies ist jedoch nicht möglich, da wir die Informationen beider Quellenabfragen zusammenführen müssen. 
  • Extra Bits:Ich hoffe wirklich, dass mir jemand helfen kann. Ich bin ziemlich neu in SSIS, dies ist das erste Mal, dass ich es benutze. Normalerweise arbeite ich mit Pentaho für meine ETL, der Client benötigt jedoch eine Lösung, die auf SSIS implementiert werden muss. Ich kämpfe seit ein paar Tagen mit diesem Problem und mir gehen die Ideen aus, um es zu lösen. 


    Wenn ich durch die Kommandozeile gelaufen bin, bleibt es auch hängen und ich erhalte folgende Ausgabe:

    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
    

    Danach friert es wieder ein.

    SOLUTION(Posten hier, weil ich meine eigenen Fragen noch 5 Stunden nicht beantworten kann, ich mache es, wenn ich darf.)
    Ich habe es endlich verstanden. 
    Es stellt sich heraus, dass es ein Problem mit der Validierung gibt, aber nicht nur SSIS-Elemente durchlaufen diese Validierung, wie in der vierten gescheiterten Lösung der Frage angegeben.
    Die CONNECTIONS werden ebenfalls validiert und verfügen über eine eigene Delay Validation-Eigenschaft, die auf true gesetzt werden muss. 
    Danach dauerte die Durchführungszeit von 40 Minuten oder nicht länger als eine Minute für den gesamten Prozess (Dies ist nur ein Schritt eines viel größeren Prozesses).
    Ich hoffe, dass Menschen mit demselben Problem diese Lösung leicht finden können, da viele Leute auf dieses Problem stoßen und fast keine Lösungen online gestellt werden.

    Kurz und bündig: Überprüfen Sie, ob für alle an der Aufgabe beteiligten Elemente, einschließlich für die DB-Verbindungen die Eigenschaft "Delay Verification" auf "True" gesetzt ist.

    23
    Ryoku

    Ich habe es endlich verstanden. Es stellt sich heraus, dass es ein Problem mit der Validierung gibt, aber nicht nur SSIS-Elemente durchlaufen diese Validierung, wie in der vierten gescheiterten Lösung der Frage angegeben .. Die CONNECTIONS werden ebenfalls validiert und haben ihre eigene Delay-Validation-Eigenschaft , die auf true gesetzt werden muss. Danach dauerte die Durchführungszeit von 40 Minuten oder nicht länger als eine Minute für den gesamten Prozess (Dies ist nur ein Schritt eines viel größeren Prozesses). Ich hoffe, dass Leute mit diesem Problem dies finden können Lösung leicht, weil viele Leute auf dieses Problem stoßen und fast keine Lösungen online gestellt werden.

    Kurz und bündig: Überprüfen Sie, ob für alle an der Task beteiligten Elemente, einschließlich der DB-Verbindungen, die Delay-Verification-Eigenschaft auf True gesetzt ist.

    11
    Ryoku

    Ich habe die gleichen Symptome, aber die Verzögerungsüberprüfung für jede Komponente auf "True" gesetzt, konnte mein Problem nicht lösen.

    Ich löste es, indem ich die DB-Methode OLE von Tabelle oder Ansicht in SQL-Befehl änderte.

    grüße.

    4
    Hercule

    Mein Problem wurde behoben, indem der Datenzugriffsmodus in SQL-Befehl geändert wurde und meine Ansicht in den SQL-Befehlstext in der DB-Quelle OLE eingefügt wurde.

    3
    user2389616

    Ich weiß, das ist alt, aber ich habe gerade einen Link darüber gefunden, der helfen könnte. Ich persönlich benutze eine Ansicht, um Daten nur in eine externe Datenbank zu exportieren, und die Validierung von _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Validation der Sicht dauert zu lange.

    https://connect.Microsoft.com/SQLServer/feedback/details/258901/ssis-views-as-data-source-very-poor-performance-or-ssis-hangs

    der wichtige Teil davon ist die Antwort von Microsoft

    Gepostet von Microsoft am 28.04.2008 um 14:45 Uhr

    Dies ist ein bekanntes Problem und das Ergebnis des aktuellen Designs.

    Es gibt zwei Möglichkeiten, Daten aus einer Sicht in der DB-Quelle OLE abzurufen:

    1. Verwenden Sie die Zugriffsmethode "Tabelle oder Ansicht"

    2. Verwenden Sie die Zugriffsmethode "SQL-Befehl" und geben Sie eine Abfrage ein "select * from ***".

    In beiden Ansätzen wird ein unterschiedlicher Ausführungsplan erstellt. 

    Die in der ersteren verwendete ist nicht so effizient wie die zweite.

    Wenn Sie beim ersten Ansatz auf das Leistungsproblem stoßen, können Sie zur Umgehung des zweiten Ansatzes wechseln. 

    Wir haben auch diese Ausgabe mit einem Blog versehen -> http://blogs.msdn.com/sqlperf/archive/2007/04/29/set-up-ole-db-source-to-read-from-view-efficiently. aspx .

    Da dies ein Artikel mit dem Namen "By Design" ist und wir der Meinung sind, dass es eine Problemumgehung gibt, werden wir derzeit keine Änderungen vornehmen. Daher schließen wir den mit Ihrer Einreichung verbundenen Fall ab. Wenn Sie nicht einverstanden sind, können Sie es gerne erneut einreichen.

    Wir bedanken uns für Ihre Zeit, Ihren Einsatz und Ihre Unterstützung für SSIS.

    3
    KySoto

    Hoffe das hilft jemandem. Ich habe versucht, diese DB-Quelle OLE zum Ausführen eines SP mit einem Parameter zu verwenden. Ich brauchte es nicht, um etwas zurückzugeben, also habe ich diesen Teil weggelassen. Aber es würde mich nicht zulassen, es schrie: "Keine Spalteninformationen wurden von der SQL zurückgegeben". Also konfigurierte ich eine Dummy-SQL-Anweisung in meinem SP, die ich nie als wahr definierte. Diese Spalte wurde jedoch nie als Ausgabe ausgegeben, und der Job hing nur vor der Ausführungsphase. Also habe ich diesen Test geändert, um immer wahr zu sein, er hat die Kolumne und Presto zurückgegeben. Ich mache nichts mit der Kolumne, aber ich denke, es wird dort gebraucht. 

    1
    TheBigRedCup

    Wir hatten unsere verzögerten Überprüfungen bereits auf True gesetzt und konnten/wollten dies nicht in eine SQL-Anweisung ändern.
    Ich bin ValidateExternalMetadata in den Datenflüssen begegnet, die ich in False geändert habe und die scheinbar wie ein Champion funktionieren.

    Ich habe die Schritte von OP überprüft und er erwähnt, dass sie das in Schritt 5 getan haben 

    1
    Sam

    Eine andere Sache, die Sie versuchen sollten, ist anscheinend das Kontrollkästchen "32-Bit-Laufzeitumgebung verwenden" zu aktivieren. Dies ist der Fall, wenn Sie das Problem beim Ausführen des Pakets als Job in Ihrem DB-Server (in diesem Fall 64-Bit- und in meinem Fall bei) sehen Zumindest SQL Server 2008R2). Gehen Sie zum Job, klicken Sie mit der rechten Maustaste> Eigenschaften…> Schritte> klicken Sie mit der rechten Maustaste auf den Schritt Ihres SSIS-Pakets> Eigenschaften…> Allgemein> Ausführungsoptionen (Registerkarte)> 32-Bit-Laufzeit.

    Ich habe dieses Problem gesehen, aber nur einmal habe ich das Paket auf dem Server bereitgestellt (ich hatte einen Protokollierungsanbieter aktiviert, damit ich es nach der "Pre-Execute" -Phase feststecken konnte). Es lief immer gut in BIDS (und auf einem anderen Server, seltsam ... immer noch nicht sicher, warum das so ist).

    Ein Thread hier hat mich auf diese Lösung aufmerksam gemacht, die scheinbar funktioniert - obwohl mein Problem zeitweise auftaucht, so YMMV. Es gibt auch andere mögliche Lösungen in diesem Thread.

    1
    S'pht'Kr

    Dieses Problem ist bei SQL Server 2012/2014 weiterhin aktiv. 

    Keine der oben genannten Lösungen hat geholfen. Tatsächlich hat sich nichts geändert, was die Validierung verzögert, und die Konfiguration des ALD DB-Ziels oder der OLE DB-Verbindung ändert. 

    Lesen des Threads von diesem Link: https://social.msdn.Microsoft.com/Forums/sqlserver/en-US/35a484c7-4850-4f86-b14a-5dfb50491ab2/long-duration-preexecute-phase?forum=sqlintegrationservices

    es wird vorgeschlagen, dass das Problem mit dem Ausführungsplan zusammenhängt. 

    Dies war für meinen Fall zutreffend und das Hinzufügen einer Bedingung 1 = 1 zu meiner OLE DB Source-Konfiguration zwang den SQL-Server, einen neuen Ausführungsplan zu generieren, der das Problem für mich behoben hat. 

    0
    Ylli Prifti

    Ich bin vor ein paar Minuten auf das gleiche Thema gestoßen und die obigen Vorschläge haben für mich nicht funktioniert. Wir haben kürzlich Probleme mit dem Parameter-Sniffing entdeckt. Nachdem ich das in meinen gespeicherten Prozeduren behoben hatte, lief mein Paket in weniger als 1 Minute. Prüfen Sie Ihre gespeicherten Prozeduren, um festzustellen, ob dies die Ursache sein kann.

    0
    user2209098