Le curieux cas de HADR_SYNC_COMMIT attend

Nous remarquons une tendance intéressante pour les HADR_SYNC_COMMITattentes dans notre environnement. Nous avons une réplique à trois exemplaires; un principal, un secondaire de synchronisation et un secondaire asynchrone dans un centre de données et nous venons d'ajouter trois répliques ASYNC supplémentaires dans un autre centre de données (à environ 2400 miles d'intervalle).

Depuis lors, nous avons commencé à remarquer une énorme augmentation des HADR_SYNC_COMMITattentes. Lorsque nous regardons les sessions actives, nous voyons un tas de COMMIT TRANSACTIONrequêtes en attente sur la réplique SYNC

À partir de la capture d'écran, nous pouvons clairement voir qu'il y a un saut dans l' HADR_SYNC_COMMITattente le 29 juin, et nous avons finalement supprimé `` deux '' des trois répliques asynchrones dans le centre de données distant dans le courant de midi le 1er juillet. Cela a considérablement réduit les temps d'attente.

Ce que nous avons vérifié jusqu'à présent - File d'attente d'envoi de journaux, file d'attente de rétablissement, dernière heure renforcée et dernière heure de validation sur les répliques distantes. Nous avons des rafales continues de petites transactions pendant les heures ouvrables, et donc les files d'attente d'envoi sont assez petites à un horodatage donné (entre 60 Ko et 1 Mo).
Les réplicas distants sont presque synchronisés, il y a très peu de différence entre le dernier temps de validation et le dernier temps durci pour un lsn individuel sur les répliques.

Le tube réseau est 10G et nous avons modifié la taille du tampon de transmission de 256 mégaoctets à 2 Go, cela a été fait en supposant que le réseau abandonnait les paquets et les retransmettait; de toute façon cela ne semblait pas beaucoup aider.

Donc, je me demande ce que les répliques ASYNC ont à voir avec les HADR_SYNC_COMMITattentes? La réplique SYNC ne devrait-elle pas dépendre seule de ce type d'attente, que me manque-t-il ici?

Tout d'abord, la description de l'événement d'attente concernant votre question est la suivante:

En attente du traitement de validation de transaction pour les bases de données secondaires synchronisées pour durcir le journal. Cette attente est également reflétée par le compteur de performances du délai de transaction. Ce type d'attente est prévu pour les groupes de disponibilité synchronisés et indique l'heure d'envoi, d'écriture et d'accusé de réception du journal vers les bases de données secondaires.

https://msdn.microsoft.com/en-us/library/ms179984.aspx

En creusant dans la mécanique de cette attente, vous avez les blocs de journaux en cours de transmission et renforcés, mais la récupération n'est pas terminée sur les serveurs distants. Dans ce cas et étant donné que vous avez ajouté des répliques supplémentaires, il va de soi que votre HADR_SYNC_COMMIT peut augmenter en raison de l'augmentation des besoins en bande passante. Dans ce cas, Aaron Bertrand a exactement raison dans ses commentaires sur la question.

Source: http://blogs.msdn.com/b/psssql/archive/2013/04/26/alwayson-hadron-learning-series-hadr-sync-commit-vs-writelog-wait.aspx

En fouillant dans la deuxième partie de votre question sur la façon dont cette attente pourrait être liée aux ralentissements des applications. Je pense que c'est un problème de causalité. Vous regardez vos attentes augmenter et une récente plainte de l'utilisateur et tirer la conclusion potentiellement incorrecte que les deux ont une relation alors que ce n'est peut-être pas du tout le cas. Le fait que vous ayez ajouté des fichiers tempdb et que votre application soit devenue plus sensible à moi indique que vous avez peut-être eu des problèmes de contention sous-jacents qui auraient pu être exacerbés par la surcharge supplémentaire de la surcharge implicite du niveau d'isolement d'instantané lorsqu'une base de données se trouve dans un groupe de disponibilité. Cela peut avoir eu peu ou rien à voir avec vos attentes HADR_SYNC_COMMIT.

Si vous souhaitez tester cela, vous pouvez utiliser une trace d'événement étendue qui examine le XEvent hadr_db_commit_mgr_update_harden sur votre réplique principale et obtenir une ligne de base. Une fois que vous avez votre référence, vous pouvez ensuite ajouter vos répliques une par une et voir comment la trace change. Je vous encourage fortement à utiliser un fichier qui réside sur un volume qui ne contient aucune base de données et à définir un roulement et une taille maximale. Veuillez ajuster le filtre de durée selon vos besoins pour rassembler les événements qui correspondent à vos attentes afin de pouvoir dépanner davantage et corréler cela avec les autres équipes qui doivent être impliquées.

CREATE EVENT SESSION [HADR_SYNC_COMMIT-Monitor] ON SERVER  -- Run this on the primary replica 
ADD EVENT sqlserver.hadr_db_commit_mgr_update_harden(
    WHERE ([delay]>(10))) -- I strongly encourage you to use the delay filter to avoid getting too many events back, this is measured in milliseconds
ADD TARGET package0.event_file(SET filename=N'<YourFilePathHere>')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO