Exchange Spill (Ereignisklasse)

Die Exchange Spill-Ereignisklasse gibt an, dass die Kommunikationspuffer in einem parallelen Abfrageplan vorübergehend in die tempdb-Datenbank geschrieben wurden. Dies tritt nur selten auf, und auch nur, wenn ein Abfrageplan mehrere Bereichsscans hat.

Normalerweise verfügt die Transact-SQL-Abfrage, die diese Bereichsscans generiert, über viele BETWEEN-Operatoren, wobei jeder dieser Operatoren einen Zeilenbereich aus einer Tabelle oder aus einem Index auswählt. Stattdessen können Sie mehrere Bereiche auch mithilfe von Ausdrücken abrufen, beispielsweise (T.a > 10 AND T.a < 20) OR (T.a > 100 AND T.a < 120). Darüber hinaus müssen die Abfragepläne erfordern, dass diese Bereiche der Reihenfolge nach gescannt werden. Dies geschieht aufgrund einer ORDER BY-Klausel für T.a oder weil ein Iterator im Plan erfordert, dass die Tupel in einer bestimmten Reihenfolge verwendet werden.

Wenn ein Abfrageplan für eine solche Abfrage mehrere Parallelism-Operatoren aufweist, werden die von den Parallelism-Operatoren verwendeten Speicherkommunikationspuffer vollständig gefüllt. Das kann dazu führen, dass der Ausführungsfortschritt der Abfrage beendet wird. In dieser Situation schreibt einer der Parallelism-Operatoren seinen Ausgabepuffer in tempdb (dieser Vorgang wird Austauschüberlauf genannt), damit Zeilen aus einigen seiner Eingabepuffer verwendet werden können. Letztendlich werden die übergelaufenen Zeilen wieder an den Consumer zurückgegeben, wenn dieser in der Lage ist, sie zu verarbeiten.

In seltenen Fällen können mehrere Austauschüberläufe innerhalb desselben Ausführungsplans auftreten, wodurch die Abfrage verlangsamt ausgeführt wird. Wenn Sie mehr als fünf Überläufe in der Ausführung desselben Abfrageplans feststellen, wenden Sie sich an einen Supportmitarbeiter.

Austauschüberläufe sind mitunter vorübergehend und sind möglicherweise nach geänderter Datenverteilung nicht mehr vorhanden.

Es gibt mehrere Möglichkeiten, Austauschüberläufe zu vermeiden:

• Geben Sie die ORDER BY-Klausel nicht an, wenn das Resultset nicht sortiert vorliegen muss.

• Wenn ORDER BY erforderlich ist, entfernen Sie die Spalte, die an mehreren Bereichsscans teilnimmt (T.a im oben angeführten Beispiel), aus der ORDER BY-Klausel.

• Durch das Verwenden eines Indexhinweises wird der Optimierer gezwungen, für die betreffende Tabelle eine andere Zugriffsmethode zu verwenden.

• Schreiben Sie die Abfrage neu, um einen anderen Abfrageausführungsplan zu erstellen.

• Erzwingen Sie die serielle Ausführung der Abfrage, indem Sie die Option MAXDOP = 1 am Ende der Abfrage oder des Indexvorgangs hinzufügen. Weitere Informationen finden Sie unter max degree of parallelism (Option) und unter Konfigurieren von Parallelindexvorgänge.

Wichtig

Zur Bestimmung der Stelle, an der das Exchange Spill-Ereignis auftritt, wenn der Abfrageoptimierer einen Ausführungsplan generiert, sollte Sie außerdem eine Showplan-Ereignisklasse in der Ablaufverfolgung sammeln. Sie können jede beliebige Showplan-Ereignisklasse auswählen, außer den Ereignisklassen Showplan Text und Showplan Text (Unencoded), da sie keine Knoten-ID zurückgeben. Knoten-IDs in Showplan-Ereignissen identifizieren jeden Vorgang, den der Abfrageoptimierer ausführt, wenn er einen Abfrageausführungsplan generiert. Diese Vorgänge werden Operatoren genannt, und jeder Operator in einem Showplan verfügt über eine Knoten-ID. Die ObjectID-Spalte für Exchange Spill-Ereignisse entspricht der Knoten-ID in Showplans, sodass Sie bestimmen können, welcher Operator oder Vorgang den Fehler verursacht. Weitere Informationen zu den Showplan-Ereignisklassen finden Sie unter Anzeigen von Ausführungsplänen mithilfe von SQL Server Profiler-Ereignisklassen.