SQL Server: blocage sur les ressources du tampon de communication de verrouillage
Quelle pourrait être la raison possible de ce type de blocage? (pas une impasse en général)
Verrouiller les ressources du tampon de communication
Ce système indique-t-il que la mémoire est faible et que le nombre de tampons est hors limite?
Erreur détaillée:
La transaction (ID de processus 59) a été bloquée sur les ressources du tampon de communication de verrouillage avec un autre processus et a été choisie comme victime du blocage. Relancez la transaction
Le message complet qui est généralement vu:
La transaction (ID de processus 53) a été bloquée sur le verrou | des ressources de tampon de communication avec un autre processus et a été choisie comme victime de l'impasse. Relancez la transaction.
Ce type de verrou est généralement utilisé avec les requêtes de blocage que SQL Server a exécutées en parallèle, parfois appelées "blocages parallèles intra-requête". J'ai vu quelques déclarations selon lesquelles cela indique également que les ressources système sont faibles, ce qui, je suppose, pourrait être impliqué dans une faible mesure.
Une directive générale que j'ai remarquée pour déterminer s'il s'agit d'un blocage parallèle est que lorsque vous tirez le graphique de blocage XML (ce qui peut être fait avec la session system_health en 2008 et supérieure), vous remarquerez différents ID de processus montrant le même bit de code dans le pile d'exécution.
De plus, en regardant la liste des ressources du graphique de blocage et en notant le type d'événement de serveur. Ils afficheront le plus souvent "e_xxxxxx", ou quelque chose comme ça peut-être:
<waiter-list>
<waiter event="e_waitPipeGetRow" type="consumer" id="process821d828" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process8209198" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process3827c18" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process3809eb8" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process8226b08" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process9acb6d8" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process6188d7828" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process381cef8" />
</waiter-list>
Pour essayer de résoudre le problème, différents chemins à suivre sont proposés en ligne et dans les livres. Je commence généralement par regarder le plan d'exécution de la requête/procédure et je me concentre sur les zones qui montrent une exécution parallèle. Ensuite, essayez d'abord de régler la requête, puis en dernier recours, commencez à utiliser des conseils de requête.
L'astuce de requête la plus courante que vous verrez mentionnée pour résoudre ces blocages consiste à implémenter MAXDOP 1. Cependant, avant de faire cela, vous pouvez vérifier ce que le niveau de serveur MAXDOP et le seuil de coût sont définis. Le seuil de coût est généralement défini sur 5 par défaut et j'aime le porter à 35 ou 40 pour commencer, si la requête en question a un faible coût pour cette section de code, il n'est peut-être pas nécessaire qu'elle s'exécute en parallèle. Je n'aime pas beaucoup utiliser les conseils de requête MAXDOP, mais cela ne signifie pas qu'ils n'ont pas leur place et leur objectif. juste mon avis.