Attente WRITELOG élevée sur Azure SQL Database

Aug 18 2020

Mon analyse WaitStats de notre Azure SQL Database montre WRITELOG et HADR_SYNC_COMMIT comme compteur de l'attente la plus élevée. Il s'agit d'une ressource Premium 250 eDTU.

Scénario

SELECT   TOP (10) wait_type,
                  CAST (([wait_time_ms] / 1000.0) AS DECIMAL (16, 2)) AS [WaitS],
                  CAST (100.0 * [wait_time_ms] / SUM([wait_time_ms]) OVER () AS DECIMAL (16, 2)) AS [Percentage]
FROM     sys.dm_db_wait_stats
ORDER BY [Percentage] DESC;

Je ne trouve pas beaucoup d'informations sur la façon de résoudre ce problème dans la base de données AZure SQL.

Toute aide est appréciée.

Merci

Réponses

3 DavidBrowne-Microsoft Aug 18 2020 at 02:56

WRITELOG attend la validation pour que les enregistrements du journal de votre transaction soient renforcés sur le disque, et HADR_SYNC_COMMIT attend la validation pour que les enregistrements du journal de votre transaction soient envoyés sur le réseau à une réplique secondaire et renforcés sur le disque. Ce sont donc des attentes très, très similaires.

Les deux indiquent que votre application engage beaucoup de transactions, peut-être trop.
Et sur Premium, votre fichier journal se trouve sur un lecteur flash local avec une latence très faible, donc subir de nombreuses attentes WRITELOG suggère qu'il y a quelque chose qui doit être corrigé dans votre application.

Si vous avez des processus qui exécutent INSERT, UPDATE ou DELETE de lignes uniques dans une boucle serrée, envisagez de les encapsuler dans une transaction explicite, de sorte que vous n'ayez qu'à attendre que le journal des transactions soit vidé à la fin.

Comme toujours , Query Store est votre ami et peut vous montrer les attentes par requête, et vous pouvez également analyser les attentes par session dans sys.dm_exec_session_wait_stats pour voir quelles parties de votre charge de travail souffrent de ces attentes.

Vous pouvez avoir une meilleure idée du temps d'attente de vos clients en comparant le temps écoulé de la session et le temps CPU aux temps d'attente. PAR EXEMPLE

select s.session_id, 
       w.wait_type, 
       w.wait_time_ms, 
       w.signal_wait_time_ms, 
       s.total_elapsed_time, 
       s.cpu_time, 
       w.wait_time_ms/cast(nullif(s.total_elapsed_time,0) as float) wait_percent_of_elapsed
from  sys.dm_exec_sessions s
join sys.dm_exec_session_wait_stats w
  on s.session_id = w.session_id
where w.wait_time_ms > 0
order by wait_percent_of_elapsed desc