Ich habe ein SSIS-Paket - zwei Datenflussaufgaben, jeweils 8 Komponenten, Lesen aus zwei Flatfiles, nichts Spektakuläres. Wenn ich es in BIDS ausführe, dauert es ungefähr 60 Sekunden. Ich habe einen Sandbox-DB-Server, auf dem das Paket in einem Job ausgeführt wird, der ebenfalls zuverlässig 30-60 Sekunden dauert. Auf meinem Produktionsserver dauert ein Auftrag mit demselben Paket zwischen 30 Sekunden und 30 Sekunden12 Stunden.

Wenn die Protokollierung für das Paket aktiviert ist, scheint es - zumindest anfangs - in der Phase vor der Ausführung der einen oder der anderen (oder beider) Datenflusstasks hängen zu bleiben. Ich kann aber auch sehen, wie die Daten langsam in Stücken eingehen, sodass ich denke, dass sie später von dort weitergehen. Das E / A-Subsystem wird überlastet, und SSIS generiert viele große temporäre Dateien (im Wert von ca. 150 MB - meine Eingabedatendateien bestehen nur aus ca. 24 MB) und liest und schreibt kräftig aus diesen Dateien (Thrashing?).

Hinweis: Wenn ich meine BIDS-Instanz des Pakets auf den Produktionsserver zeige, dauert die Ausführung nur etwa 60 Sekunden. Es muss also etwas mit dtexec laufen, nicht die DB selbst.

Ich habe bereits versucht, mein Paket zu optimieren und die Größe der Eingabezeilenbytes zu verringern, und die beiden Datenflusstasks wurden nicht parallel, sondern seriell ausgeführt - ohne Erfolg.

Auf beiden DB-Servern wird MSSQL 2008 R2 64-Bit mit demselben Patch-Level ausgeführt. Beide Server sind VMs auf demselben Host mit derselben Ressourcenzuordnung. Die Auslastung des Produktionsservers sollte derzeit nicht viel höher sein als auf dem Sandbox-Server. Der einzige Unterschied, den ich sehen kann, ist, dass der Produktionsserver ausgeführt wirdWindows Server 2008, während sich die Sandbox unter Windows Server 2008 befindetR2.

Hilfe!!! Alle mögliche Ideen, zum zu versuchen, sind willkommen, was diese enorme Diskrepanz verursachen könnte?

Anhang A

So sieht mein Paket aus ...

Der Steuerungsablauf ist denkbar einfach:

Der Datenfluss sieht folgendermaßen aus:

Die zweite Datenflusstask ist genau dieselbe, nur mit einer anderen Quelldatei und Zieltabelle.

Anmerkungen

Die Beendigungsbeschränkung im Kontrollfluss dient nur dazu, die Tasks seriell auszuführen, um zu versuchen, gleichzeitig benötigte Ressourcen zu reduzieren (nicht, dass dies zur Lösung des Problems beigetragen hätte). Es besteht keine tatsächliche Abhängigkeit zwischen den beiden Tasks.

Ich bin mir potenzieller Probleme mit blockierenden und teilweise blockierenden Transformationen bewusst (kann nicht sagen, dass ich sie vollständig verstehe, aber zumindest etwas), und ich weiß, dass die Aggregat- und Merge-Verknüpfungen blockieren und Probleme verursachen können. Dies alles funktioniert jedoch auch in allen anderen Umgebungen, mit Ausnahme des Produktionsservers, problemlos und schnell. Was gibt es also?

Der Grund für den Merge Join ist, dass die Task darauf wartet, dass beide Zweige des Multicasts abgeschlossen sind. Der rechte Zweig ermittelt die minimale Datumszeit in der Eingabe und löscht alle Datensätze in der Tabelle nach diesem Datum, während der linke Zweig die neuen Eingabedatensätze zum Einfügen enthält. Wenn der rechte Zweig also vor dem Zusammenfassen und Löschen fortgesetzt wird, werden die neuen Datensätze gelöscht gelöscht werden (dies ist passiert). Mir ist kein besserer Weg bekannt, dies zu handhaben.

Die Fehlerausgabe von "Datensätze löschen" ist immer leer - dies ist beabsichtigt, da ich eigentlich keine Zeilen aus diesem Zweig in der Zusammenführung haben möchte (die Zusammenführung dient nur dazu, die Fertigstellung zu synchronisieren, wie oben erläutert).

Siehe nachstehenden Kommentar zu den Warnsymbolen.