Classe d'événements Exchange Spill

La classe d'événements Exchange Spill indique que les tampons d'un plan de requête parallèle ont été temporairement écrits dans la base de données tempdb. Cet événement intervient rarement, seulement lorsqu'un plan de requête inclut de multiples plages d'analyses.

Normalement, la requête Transact-SQL qui génère de telles plages d'analyses comprend de nombreux opérateurs BETWEEN, chacun d'entre eux permettant de sélectionner une plage de lignes à partir d'une table ou d'un index. Vous pouvez également obtenir de multiples plages via des expressions telles que (T.a > 10 AND T.a < 20) OR (T.a > 100 AND T.a < 120). De plus, les plans de requête imposent que ces plages soient analysées de façon ordonnée, dans la mesure ou une clause ORDER BY est spécifiée sur T.a, ou parce qu'un itérateur du plan demande que les lignes qu'il consomme soient triées.

Lorsque le plan de requête d'une telle requête contient plusieurs opérateurs Parallelism, les tampons de communication utilisés par ces opérateurs Parallelism sont saturés et il se peut que la progression de l'exécution de la requête soit stoppée. Dans cette situation, l'un des opérateurs Parallelism écrit sa mémoire tampon de sortie dans la base de données tempdb (une opération appelée vidage d'échange), de manière à pouvoir consommer des lignes en provenance de certains de ses tampons d'entrée. Éventuellement, les lignes vidées sont retournées à l'opérateur demandeur lorsqu'il est prêt à les utiliser.

Très rarement, de multiples vidages d'échange peuvent intervenir au sein du même plan d'exécution, ce qui entraîne la requête à s'exécuter lentement. Si vous remarquez plus de cinq vidages d'échange au sein de la même exécution de plan de requête, contactez votre service d'assistance.

Les vidages d'échange sont parfois transitoires et peuvent disparaître lorsque la distribution des données change.

Il existe plusieurs façons d'éviter les vidages d'échange :

• Omettez la clause ORDER BY si vous n'avez pas besoin d'avoir le jeu de résultats ordonné.

• Si ORDER BY est requis, éliminez la colonne impliquée dans les multiples plages d'analyses (T.a dans l'exemple ci-dessus) de la clause ORDER BY.

• L'utilisation d'une option d'index force l'optimiseur à choisir un chemin d'accès différent à la table en question.

• Réécrivez la requête pour produire un plan d'exécution de la requête différent.

• Forcez l'exécution séquentielle de la requête en ajoutant l'option MAXDOP = 1 à la fin de la requête ou de l'opération d'index. Pour plus d'informations, consultez Option Degré maximum de parallélisme et Configuration d'opérations d'index parallèles.