PAGEIOLATCH no SQL Server: o que significa e quando é motivo de alerta

PAGEIOLATCH_SH e PAGEIOLATCH_EX são os waits que aparecem quando uma sessão está esperando uma página de dados ser lida do disco (SH, leitura compartilhada) ou escrita nele (EX, escrita exclusiva) pro buffer pool. Diferente de LCK_M_* (lock lógico entre sessões), esse é um wait físico — a espera é pelo disco responder, não por outra transação liberar algo.

Quando é normal

Algum PAGEIOLATCH sempre vai existir — toda leitura que não está em cache no buffer pool precisa esperar o disco. É esperado em picos de carga (relatório grande, ETL, primeira leitura de uma tabela fria depois de um restart) e não é motivo de alerta isolado.

Quando vira problema

• Alto e constante, não só em pico — indica que o disco genuinamente não acompanha o volume de I/O do ambiente.
• Tempo médio de espera por página (wait_time_ms / waiting_tasks_count) subindo ao longo do tempo com o mesmo volume de carga — sinal de degradação do storage, não de aumento de uso.
• Concentrado num único arquivo/filegroup — pode ser um disco específico do array com problema, não o storage inteiro.

SELECT
  DB_NAME(database_id) AS banco, file_id,
  io_stall_read_ms, num_of_reads, io_stall_write_ms, num_of_writes
FROM sys.dm_io_virtual_file_stats(NULL, NULL)
ORDER BY io_stall_read_ms + io_stall_write_ms DESC;

Essa DMV mostra a latência por arquivo físico — cruzar com o wait agregado ajuda a confirmar se é um arquivo específico puxando a média pra baixo ou o storage inteiro.

O codeDB monitora PAGEIOLATCH e a latência por arquivo continuamente, então uma degradação gradual do disco aparece como tendência antes de virar gargalo generalizado.