Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Die Exchange Spill-Ereignisklasse gibt an, dass Kommunikationspuffer in einem parallelen Abfrageplan vorübergehend in die tempdb-Datenbank geschrieben wurden. Dies tritt nur selten auf, wenn ein Abfrageplan mehrere Bereichsscans hat.
Normalerweise weist die Transact-SQL Abfrage, die solche Bereichsscans generiert, viele BETWEEN-Operatoren auf, von denen jeder einen Zeilenbereich aus einer Tabelle oder einem Index auswählt. Alternativ können Sie mehrere Bereiche mithilfe von Ausdrücken wie (T.a > 10 AND T.a < 20) OR (T.a > 100 AND T.a < 120) abrufen. Darüber hinaus müssen die Abfragepläne bestimmen, dass diese Bereiche in einer bestimmten Reihenfolge gescannt werden müssen, entweder weil eine ORDER BY-Klausel auf T.a vorhanden ist oder weil ein Iterator im Plan erfordert, dass die Tupel in sortierter Reihenfolge verarbeitet werden müssen.
Wenn ein Abfrageplan für eine solche Abfrage über mehrere Parallelitätsoperatoren verfügt, werden die Speicherkommunikationspuffer, die von den Parallelismusoperatoren verwendet werden, voll, und eine Situation kann auftreten, in der der Ausführungsfortschritt der Abfrage beendet wird. In dieser Situation schreibt einer der Parallelismus-Operatoren seinen Ausgabepuffer in tempdb (ein Vorgang namens Austauschüberlauf), um Zeilen aus einigen seiner Eingabepuffer zu verarbeiten. Schließlich werden die übergelaufenen Zeilen an den Verbraucher zurückgegeben, wenn der Verbraucher bereit ist, sie zu verbrauchen.
Sehr selten können mehrere Austausch-Überläufe innerhalb desselben Ausführungsplans auftreten, was dazu führt, dass die Ausführung der Abfrage verlangsamt wird. Wenn Sie mehr als fünf Speicherüberläufe innerhalb der Ausführung desselben Abfrageplans bemerken, wenden Sie sich an Ihren Supportmitarbeiter.
Exchange-Überläufe sind manchmal vorübergehend und können bei Änderungen der Datenverteilung verschwinden.
Es gibt mehrere Möglichkeiten, um Austausch-Überlaufereignisse zu vermeiden:
Lassen Sie die ORDER BY-Klausel aus, wenn das Resultset nicht sortiert werden muss.
Wenn ORDER BY erforderlich ist, entfernen Sie die Spalte, die an den Überprüfungen mehrerer Bereiche (T.a im obigen Beispiel) teilnimmt, aus der ORDER BY-Klausel.
Wenn Sie einen Indexhinweis verwenden, erzwingen Sie, dass der Optimierer einen anderen Zugriffspfad in der betreffenden Tabelle verwendet.
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 Konfigurieren des maximalen Grads an Parallelitätsserverkonfigurationsoption und Konfigurieren von Parallelindexvorgängen.
Von Bedeutung
Um zu ermitteln, wo das Exchange-Überlaufereignis auftritt, wenn der Abfrageoptimierer einen Ausführungsplan generiert, sollten Sie bei der Ablaufverfolgung auch eine Showplan-Ereignisklasse aufzeichnen. Sie können eine der Showplan-Ereignisklassen mit Ausnahme der Showplan-Ereignisklassen "Text " und " Uncodiert" auswählen, die keine Knoten-ID zurückgeben. Knoten-IDs in Showplans identifizieren jeden Vorgang, den der Abfrageoptimierer beim Generieren eines Abfrageausführungsplans ausführt. Diese Vorgänge werden als Operatoren bezeichnet, und jeder Operator in einem Showplan verfügt über eine Knoten-ID. Die ObjectID-Spalte für Exchange-Überlaufereignisse entspricht der Knoten-ID in Showplans, sodass Sie bestimmen können, welcher Operator oder Vorgang den Fehler verursacht.
Datenspalten der Exchange-Überlaufereignisklasse
| Datenspaltenname | Datentyp | BESCHREIBUNG | Spalten-ID | Filterbar |
|---|---|---|---|---|
| ApplicationName | nvarchar | Name der Clientanwendung, die die Verbindung mit einer Instanz von SQL Server erstellt hat. Diese Spalte wird mit den Werten aufgefüllt, die von der Anwendung übergeben werden, und nicht mit dem angezeigten Namen des Programms. | 10 | Ja |
| ClientProcessID | Int | Die ID, die der Hostcomputer dem Prozess zuweist, in dem die Clientanwendung ausgeführt wird. Diese Datenspalte wird aufgefüllt, wenn der Client die Clientprozess-ID angibt. | 9 | Ja |
| DatabaseID | Int | Die ID der Datenbank, die durch die USE database -Anweisung angegeben wurde, bzw. die ID der Standarddatenbank, wenn für eine bestimmte Instanz keine USE database -Anweisung ausgegeben wurde. SQL Server Profiler zeigt den Namen der Datenbank an, wenn die ServerName -Datenspalte in der Ablaufverfolgung aufgezeichnet wird und der Server verfügbar ist. Der Wert für eine Datenbank kann mithilfe der DB_ID-Funktion ermittelt werden. | 3 | Ja |
| DatabaseName | nvarchar | Name der Datenbank, in der die Benutzeranweisung ausgeführt wird. | 35 | Ja |
| EventClass | Int | Ereignistyp = 127. | 27 | Nein |
| EventSequence | Int | Sequenz eines bestimmten Ereignisses innerhalb der Anforderung. | 51 | Nein |
| EventSubClass | Int | Der Typ der Ereignisunterklasse. 1=Spielbeginn 2=Ende des Überlaufs |
21 | Ja |
| GroupID | Int | ID der Arbeitsauslastungsgruppe, in der das SQL-Ablaufverfolgungsereignis ausgelöst wird. | 66 | Ja |
| HostName | nvarchar | Der Name des Computers, auf dem der Client ausgeführt wird. Diese Datenspalte wird aufgefüllt, wenn der Hostname vom Client bereitgestellt wird. Verwenden Sie die HOST_NAME -Funktion, um den Hostnamen zu bestimmen. | 8 | Ja |
| IsSystem | Int | Gibt an, ob das Ereignis bei einem Systemprozess oder einem Benutzerprozess aufgetreten ist. 1 = System, 0 = Benutzer. | 60 | Ja |
| LoginName | nvarchar | Name der Anmeldung des Benutzers (entweder SQL Server-Sicherheitsanmeldung oder Windows-Anmeldeinformationen in Form von <DOMÄNE>\<Benutzername>). | 11 | Ja |
| LoginSid | Abbildung | Sicherheits-ID (SID) des angemeldeten Benutzers. Diese Informationen finden Sie in der Syslogins-Tabelle der Masterdatenbank . Die SID ist für jede Anmeldung beim Server eindeutig. | 41 | Ja |
| NTDomainName | nvarchar | Windows-Domäne, zu der der Benutzer gehört. | 7 | Ja |
| NTUserName | nvarchar | Windows-Benutzername. | 6 | Ja |
| ObjectID | Int | Vom System zugewiesene ID des Objekts. Entspricht der Knoten-ID in Showplans. | 22 | Ja |
| RequestID | Int | Die ID der Anforderung, die die Anweisung enthält. | 49 | Ja |
| ServerName | nvarchar | Name der Instanz von SQL Server, die nachverfolgt wird. | 26 | Nein |
| SessionLoginName | nvarchar | Der Anmeldename des Benutzers, der die Sitzung gestartet hat. Wenn Sie beispielsweise mithilfe von Login1 eine Verbindung mit SQL Server herstellen und eine Anweisung als Login2 ausführen, zeigt SessionLoginName "Login1" und "LoginName " "Login2" an. In dieser Spalte werden sowohl SQL Server- als auch Windows-Anmeldungen angezeigt. | 64 | Ja |
| SPID | Int | Die ID der Sitzung, in der das Ereignis aufgetreten ist. | 12 | Ja |
| StartTime | datetime | Zeitpunkt, zu dem das Ereignis begonnen hat (falls vorhanden). | 14 | Ja |
| TransactionID | bigint | Die vom System zugewiesene ID der Transaktion. | 4 | Ja |
| XactSequence | bigint | Das Token, das die aktuelle Transaktion beschreibt. | 50 | Ja |
Siehe auch
sp_trace_setevent (Transact-SQL)
Festlegen von Indexoptionen
ALTER INDEX (Transact-SQL)