Estamos vendo tipos de espera PAGELATCH_EX e PAGELATCH_SH muito altos, além de esperas WRITELOG altas. Diagnostiquei a consulta que está causando a espera do PAGELATCH e posso eliminá-los, reduzindo a taxa de inserção em uma chave primária em cluster ocupada definida com um valor de IDENTITY. Entendo que esse fenômeno é conhecido como contenção de trava de inserção de última página.
No entanto, minha pergunta é: quando um novo registro é inserido, o SQL Server recebe um PAGELATCH_EX exclusivo em uma página de buffer, insere o registro na página de buffer, grava o registro no log de transações e libera o PAGELATCH_EX exclusivo como https detalhado : // www.microsoft.com/pt-br/download/details.aspx?id=26665 Página 24. Ou ele grava o registro no log de transações primeiro antes de usar o PAGELATCH_EX como detalhado "Resolvendo a contenção do PAGELATCH em cargas de trabalho INSERT" - Informações de base SQLCAT's Guide to: Relational Engine
Se o registro for gravado para fazer logon fora do mecanismo de travamento, posso descartar gravações lentas no disco como causa de altas esperas do PAGELATCH. Mas se a trava for mantida até que o registro seja mais difícil de registrar, provavelmente eu devo levar o WRITELOG em consideração.
Além disso, ter vários índices não agrupados em cluster faria com que a trava PAGELATCH_ * fosse mantida por mais tempo, isto é, se uma tabela tiver um cluster e vários índices não agrupados em cluster fossem adicionadas e liberadas para cada uma das páginas do buffer de índice simultaneamente?
Atualização 1 Depois de ler o slide dois confio-sql-server-writelog-wait e a arquitetura geral do WAL. Agora entendo que a etapa "Registrar uma entrada de log que a linha foi modificada", detalhada nos dois white papers, refere-se ao SQL Server registrando uma alteração no cache do log de transações, não no disco. Depois que a transação é concluída ou o buffer está cheio, todos os registros são imediatamente liberados para o disco.