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.
Respostas:
Você deve observar que a trava protege apenas a integridade física da página enquanto estiver na memória; portanto, a trava seria realizada quando a página estiver na memória. Suponha que um registro esteja sendo inserido e que essa página precise ser buscada. Primeiro, a página seria bloqueada e trazida para a memória, depois seria trancada e a informação seria gravada. O processo depois disso seria
Gerar registro de log
Página de atualização LSN para corresponder à do registro de log
Alterar dados (suja a página)
Trava de liberação
Confirmar início da transação
FlushToLSN de confirmação
Liberar bloqueios
Confirmar transação concluída
Para obter mais detalhes e explicações sobre as etapas acima, leia o blog de apresentação de E / S de Bob Dorr.
As esperas de pagelatch * não são de E / S e vi na maioria das vezes que essas esperas são proeminentes devido à contenção de alocação. Meu palpite é que isso tem a ver com como
tempdb is configured. Então, como o seu tempdb está configurado ?, quantos arquivos de dados estão presentes? Verifique se eles têm o mesmo crescimento automático e o mesmo tamanho. Quando uma nova página é criada, as páginas do sistema, como as páginas GAM, SGAM e PFS, precisam ser atualizadas ou acessadas e quando o SQL Server encontra contenção ao acessar essas páginas, essa espera entra em cena.fonte