WRITELOG e RESOURCE_SEMAPHORE: waits de log e memória

Apesar de aparecerem juntos com frequência em relatórios de wait stats, WRITELOG e RESOURCE_SEMAPHORE não têm nada em comum na causa — um é sobre disco, o outro é sobre memória.

WRITELOG — o log de transação confirmando no disco

Toda transação precisa que sua entrada no log de transação seja gravada em disco antes do COMMIT ser confirmado pro cliente (write-ahead logging). WRITELOG é a espera por essa gravação. Alto e constante aponta quase sempre pro storage físico onde o arquivo .ldf está — latência do disco do log, não do banco de dados em si.

SELECT
  DB_NAME(database_id) AS banco, file_id,
  io_stall_write_ms, num_of_writes,
  io_stall_write_ms * 1.0 / NULLIF(num_of_writes, 0) AS latencia_media_ms
FROM sys.dm_io_virtual_file_stats(NULL, 2) -- file_id 2 = log, por convenção
ORDER BY latencia_media_ms DESC;

RESOURCE_SEMAPHORE — fila por memory grant

Diferente do WRITELOG, esse não é sobre disco: é uma sessão esperando na fila por memória suficiente pra executar uma operação de sort ou hash (memory grant). Aparece quando várias queries com sort/hash grandes competem pela memória disponível ao mesmo tempo, ou quando max server memory está configurado baixo demais pro volume de trabalho.

Tratar os dois como "o servidor está lento" genérico leva a mexer no lugar errado — trocar disco não resolve pressão de memória, e adicionar RAM não resolve latência de log. O codeDB separa os dois automaticamente no histórico de wait stats.