As gravações no TempDB sempre resultam em uma gravação física real no disco ou as gravações do TempDB são armazenadas em cache pelo SQL Server para gravação atrasada, como no cache do sistema de arquivos do Windows?
Eles sempre? Definitivamente não. Eles já? Sim, mas não como resultado do mecanismo típico. A referência aqui é O que o ponto de verificação faz para o tempdb? .
Em um sistema "bem comportado", as gravações em um arquivo de banco de dados do usuário ocorrem no ponto de verificação. Em um sistema mal comportado, as gravações também ocorrerão quando o lazywriter precisar liberar páginas do buffer pool para liberar espaço para outras páginas.
Um ponto de verificação é feito apenas para tempdb quando o arquivo de log tempdb atinge 70% de sua capacidade - isso evita que o log tempdb cresça se possível (observe que uma transação de longa duração ainda pode essencialmente manter o refém do log e impedir que ele seja limpo , assim como em um banco de dados do usuário).
Mas não há necessidade de liberar o tempdb para o disco, pois a recuperação de falhas nunca é executada no tempdb, é sempre recriada na inicialização.
O tempdb não é recuperado no caso de uma falha e, portanto, não há necessidade de forçar páginas temporárias sujas para o disco, exceto no caso em que o processo do lazywriter (parte do buffer pool) precise liberar espaço para páginas de outros bancos de dados.
Isso notavelmente (foi uma surpresa para mim) é o único mecanismo pelo qual as páginas tempdb serão gravadas no disco. Se houver pressão no conjunto de buffers, as páginas tempdb poderão ser descarregadas para o disco. Se não houver, não deve ocorrer.
Editar: discutível se "mal comportado" é uma descrição apropriada para um banco de dados do usuário que está escrevendo páginas fora do ponto de verificação. Incomum, atípico, ou simplesmente não ideal, talvez?
Edição adicional (após comentários / bate-papo com @PaulWhite):
A omissão flagrante acima é que as tabelas temporárias não são a única fonte de tráfego tempdb. Citação de Noções básicas sobre eventos de hash, classificação e troca de derramamento :
Certas operações de execução de consulta do SQL Server são calibradas para ter melhor desempenho usando uma quantidade (um pouco) grande de memória como armazenamento intermediário. O Query Optimizer escolherá um plano e estimará o custo com base nesses operadores usando este bloco de rascunho de memória. Mas isso é, obviamente, apenas uma estimativa. Na execução, as estimativas podem se mostrar erradas e o plano deve continuar, apesar de não ter memória suficiente. Nesse caso, esses operadores se espalham para o disco.
Eu assumi incorretamente que o mecanismo por trás de uma gravação física para uma operação de derramamento era exatamente o mesmo descrito anteriormente, ou seja, o preguiçoso forçando as páginas do tempdb para o disco como resultado da pressão no buffer pool (causada pelo vazamento).
@PaulWhite explicou onde eu estava errado (obrigado Paul!):
Acho que você está se perguntando por que a atividade física do tempdb ocorre quando uma consulta excede sua concessão de memória da área de trabalho, em vez de apenas usar o tempdb-in-memory. subvenções em primeiro lugar.
Derramamentos são realmente especiais na escrita até o armazenamento. A atividade física do tempdb é vista em um derramamento, mesmo diante de grande quantidade de memória livre e pressão zero no tempdb.
Paul também me indicou sua postagem no blog Advanced TSQL Tuning: Why Internals Knowledge Matters, que inclui scripts de exemplo para demonstrar derramamentos, para aqueles que desejam se aprofundar mais.
