Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La classe d’événements Exchange Spill indique que les mémoires tampons de communication dans un plan de requête parallèle ont été temporairement écrites dans la base de données tempdb . Cela se produit rarement et uniquement lorsqu’un plan de requête a plusieurs analyses de plage.
Normalement, la requête Transact-SQL qui génère de telles analyses de plage a de nombreux opérateurs BETWEEN, chacun sélectionnant une plage de lignes à partir d’une table ou d’un index. Vous pouvez également obtenir plusieurs plages à l’aide d’expressions telles que (T.a > 10 AND T.a < 20) OR (T.a > 100 AND T.a < 120). En outre, les plans de requête doivent exiger que ces plages soient analysées dans l’ordre, soit parce qu’il existe une clause ORDER BY sur T.a, soit parce qu’un itérateur dans le plan exige qu’il consomme les tuples dans l’ordre trié.
Lorsqu’un plan de requête pour une telle requête a plusieurs opérateurs parallélisme , les mémoires tampons de communication utilisées par les opérateurs de parallélisme deviennent complètes et une situation peut survenir lorsque la progression de l’exécution de la requête s’arrête. Dans ce cas, l’un des opérateurs Parallelism écrit sa mémoire tampon de sortie dans tempdb (une opération appelée déversement d’échange) afin qu’elle puisse consommer des lignes à partir de certaines de ses mémoires tampons d’entrée. Finalement, les lignes déversées sont retournées au consommateur lorsque le consommateur est prêt à les consommer.
Très rarement, plusieurs débordements d'échange peuvent se produire dans le même plan d'exécution, ce qui ralentit l'exécution de la requête. Si vous remarquez plus de cinq déversements dans l’exécution du même plan de requête, contactez votre professionnel du support technique.
Les déversements d’échange sont parfois temporaires et peuvent disparaître à mesure que la distribution des données change.
Il existe plusieurs façons d’éviter les incidents de fuite lors des échanges :
Omettez la clause ORDER BY si vous n’avez pas besoin que le jeu de résultats soit ordonné.
Si ORDER BY est requis, supprimez la colonne qui participe à des scans de plages multiples (T.a dans l’exemple ci-dessus) de la clause ORDER BY.
À l’aide d’un indicateur d’index, forcez l’optimiseur à utiliser un autre chemin d’accès sur la table en question.
Réécrire la requête pour produire un autre plan d’exécution de requête.
Forcez l’exécution série de la requête en ajoutant l’option MAXDOP = 1 à la fin de l’opération de requête ou d’index. Pour plus d’informations, consultez Configurer l’option de configuration maximale du serveur de parallélisme et configurer les opérations d’index parallèles.
Important
Pour déterminer où se produit l’événement Exchange Spill lorsque l’optimiseur de requête génère un plan d’exécution, vous devez également collecter une classe d’événements Showplan dans la trace. Vous pouvez choisir l’une des classes d’événements Showplan, à l’exception des classes d’événements Showplan Text et Showplan Text (Non codées), qui ne retournent pas d’ID de nœud. Les ID de nœud dans Showplans identifient chaque opération effectuée par l’optimiseur de requête lorsqu’il génère un plan d’exécution de requête. Ces opérations sont appelées opérateurs et chaque opérateur d’un Showplan a un ID de nœud. La colonne ObjectID pour les événements Exchange Spill correspond à l’ID de nœud dans Showplans afin que vous puissiez déterminer l’opérateur ou l’opération à l’origine de l’erreur.
Colonnes de données de la classe d’événements Exchange Spill
| Nom de la colonne de données | Type de données | Descriptif | ID de la colonne | Filtrable |
|---|---|---|---|---|
| ApplicationName | nvarchar | Nom de l’application cliente qui a créé la connexion à une instance de SQL Server. Cette colonne est remplie avec les valeurs passées par l'application plutôt que par le nom affiché du programme. | 10 | Oui |
| ClientProcessID | Int | ID affecté par l'ordinateur hôte au processus dans lequel s'exécute l'application cliente. La colonne de données est remplie si le client fournit l'ID du processus client. | 9 | Oui |
| DatabaseID | Int | ID de la base de données spécifiée par l’instruction USE base de données ou celui de la base de données par défaut si aucune instruction USE n’a été spécifiée pour une instance donnée. Le Générateur de profils SQL affiche le nom de la base de données si la colonne de données ServerName du serveur est capturée dans la trace et que le serveur est disponible. Déterminez la valeur pour une base de données à l'aide de la fonction DB_ID. | 3 | Oui |
| BaseDeDonnées | nvarchar | Nom de la base de données dans laquelle l'instruction de l'utilisateur est exécutée. | 35 | Oui |
| EventClass | Int | Type d’événement = 127. | 27 | Non |
| EventSequence | Int | Séquence d'un événement donné au sein de la demande. | 51 | Non |
| EventSubClass | Int | Type de sous-classe d'événements. 1=Début du déversement 2=Fin du déversement |
21 | Oui |
| groupID | Int | ID du groupe de charges de travail où l'événement Trace SQL se déclenche. | 66 | Oui |
| Nom d’hôte | nvarchar | Nom de l'ordinateur sur lequel le client est exécuté. La colonne de données est remplie si le client fournit le nom de l'hôte. Pour déterminer le nom de l’hôte, utilisez la fonction HOST_NAME . | 8 | Oui |
| IsSystem | Int | Indique si l'événement s'est produit sur un processus système ou sur un processus utilisateur. 1 = système, 0 = utilisateur. | soixante | Oui |
| LoginName | nvarchar | Nom de la connexion de l’utilisateur (connexion de sécurité SQL Server ou informations d’identification de connexion Windows sous la forme domain<>\<username>). | 11 | Oui |
| LoginSid | image | Numéro d'identification de sécurité (SID) de l'utilisateur connecté. Vous trouverez ces informations dans la table syslogins de la base de données master . Chaque connexion possède un SID unique au niveau du serveur. | 41 | Oui |
| NTDomainName | nvarchar | Domaine Windows auquel appartient l'utilisateur. | 7 | Oui |
| NTUserName | nvarchar | Nom d'utilisateur Windows. | 6 | Oui |
| ObjectID | Int | ID affecté à l'objet par le système. Correspond à l'ID de nœud dans Showplans. | 22 | Oui |
| RequestID | Int | ID de la demande contenant l'instruction. | 49 | Oui |
| Nom_serveur | nvarchar | Nom de l’instance de SQL Server en cours de suivi. | 26 | Non |
| SessionLoginName | nvarchar | Nom de connexion de l'utilisateur à l'origine de la session. Par exemple, si vous vous connectez à SQL Server à l’aide de Login1 et exécutez une instruction en tant que Login2, SessionLoginName affiche Login1 et LoginName affiche Login2. Cette colonne affiche à la fois les connexions SQL Server et Windows. | 64 | Oui |
| SPID | Int | ID de la session au cours de laquelle l'événement s'est produit. | 12 | Oui |
| StartTime | datetime | Heure à laquelle a débuté l'événement, si elle est connue. | 14 | Oui |
| TransactionID | bigint | ID affecté par le système à la transaction. | 4 | Oui |
| XactSequence | bigint | Jeton qui décrit la transaction en cours. | 50 | Oui |
Voir aussi
sp_trace_setevent (Transact-SQL)
Définir les options d’index
ALTER INDEX (Transact-SQL)