Attentes PAGELATCH_ * et WRITELOG élevées. Sont-ils liés?

Nous voyons des types d'attente PAGELATCH_EX et PAGELATCH_SH très élevés ainsi que des attentes WRITELOG élevées. J'ai diagnostiqué la requête à l'origine des attentes PAGELATCH et je peux les éliminer en réduisant le taux d'insertion dans une clé primaire en cluster occupée définie avec une valeur IDENTITY. Je comprends que ce phénomène est connu sous le nom de conflit de verrouillage d'insertion de dernière page.

Cependant, ma question est lorsqu'un nouvel enregistrement est inséré, SQL Server prend-il un PAGELATCH_EX exclusif sur une page tampon, insère-t-il l'enregistrement dans la page tampon, écrit-il l'enregistrement dans le journal des transactions , puis libère le PAGELATCH_EX exclusif comme détaillé https: // www.microsoft.com/en-ie/download/details.aspx?id=26665 page 24. Ou écrit-il d'abord l'enregistrement dans le journal des transactions avant de prendre le PAGELATCH_EX comme détaillé "Résolution du conflit PAGELATCH sur les charges de travail INSERT hautement concurrentes" - Informations générales SQLCAT's Guide to: Relational Engine

Si l'enregistrement est écrit pour se connecter en dehors du mécanisme de verrouillage, je peux exclure les écritures lentes sur le disque comme cause d'attentes PAGELATCH élevées. Mais si le verrou est maintenu jusqu'à ce que l'enregistrement soit durci, je devrais probablement prendre WRITELOG en considération.

De plus, le fait d'avoir plusieurs index non clusterisés entraînerait le maintien du verrou PAGELATCH_ * plus longtemps, c'est-à-dire si une table a un cluster et que plusieurs index non clusterisés sont des verrous ajoutés et libérés simultanément dans chacune des pages de tampon d'index?

Mise à jour 1 Après avoir lu confio-sql-server-writelog-wait, diapositive deux et architecture WAL générale. Je comprends maintenant que l'étape "Enregistrer une entrée de journal que la ligne a été modifiée" détaillée dans les deux livres blancs fait référence à SQL Server qui enregistre une modification dans le cache du journal des transactions, pas sur le disque. Une fois la transaction terminée ou le tampon plein, tous les enregistrements sont immédiatement vidés sur le disque.

Cependant, ma question est lorsqu'un nouvel enregistrement est inséré, SQL Server prend-il un PAGELATCH_EX exclusif sur une page tampon, insère-t-il l'enregistrement dans la page tampon, écrit-il l'enregistrement dans le journal des transactions, puis libère l'exclusif PAGELATCH_EX

Vous devez noter que le verrou protège uniquement l'intégrité physique de la page lorsqu'elle est en mémoire, de sorte que le verrou serait pris lorsque la page est en mémoire. Supposons qu'un enregistrement soit inséré et pour cette page doit être récupéré. Tout d'abord, la page serait verrouillée et mise en mémoire, puis elle serait verrouillée et les informations seraient écrites. Le processus après cela serait

• Générer un enregistrement de journal

• Mettre à jour le LSN de la page pour correspondre à celui de l'enregistrement du journal

• Modifier les données (salir la page)

• Déverrouiller le loquet

• Valider le début de la transaction

• FlushToLSN de validation

• Déverrouiller les verrous

• Validation de la transaction terminée

Pour plus de détails et d'explications sur les étapes ci-dessus, veuillez lire le blog de présentation des E / S de Bob Dorr

Les attentes Pagelatch * sont des attentes non E / S et j'ai vu la plupart du temps que ces attentes sont importantes en raison de la contention d'allocation. Mon intuition est que cela doit faire quelque chose avec la façon dont tempdb is configured. Alors, comment votre tempdb est-il configuré?, Combien de fichiers de données tempdb sont présents? Assurez-vous qu'ils ont la même croissance automatique et la même taille. Lorsqu'une nouvelle page est créée, les pages système telles que les pages GAM, SGAM et PFS doivent être mises à jour ou accessibles et lorsque SQL Server trouve des conflits dans l'accès à ces pages, une telle attente apparaît.