¿Las escrituras en TempDB siempre resultan en una escritura física real en el disco, o las escrituras de TempDB se almacenan en caché por SQL Server para escritura retrasada como en la caché del sistema de archivos de Windows?
¿Siempre lo hacen? Definitivamente no. ¿Alguna vez? Sí, pero no como resultado del mecanismo típico. La referencia aquí es ¿Qué hace el punto de control para tempdb? .
En un sistema de "buen comportamiento", las escrituras en un archivo de base de datos de usuario se producen en el punto de control. En un sistema de mal comportamiento, las escrituras también se producirán cuando el lazywriter necesite vaciar las páginas del grupo de búferes para dejar espacio para otras páginas.
Solo se realiza un punto de control para tempdb cuando el archivo de registro tempdb alcanza el 70% de su capacidad; esto es para evitar que el registro tempdb crezca, si es posible (tenga en cuenta que una transacción de larga duración todavía puede retener al registro como rehén y evitar que se borre , al igual que en una base de datos de usuarios).
Pero no es necesario vaciar tempdb en el disco, ya que la recuperación de fallas nunca se ejecuta en tempdb, siempre se recrea en el inicio.
Tempdb no se recupera en el caso de un bloqueo, por lo que no es necesario forzar las páginas sucias de tempdb en el disco, excepto en el caso en que el proceso de lazywriter (parte del grupo de búferes) tenga que dejar espacio para páginas de otras bases de datos.
Este es notablemente (fue una sorpresa para mí) el único mecanismo por el cual las páginas tempdb se escribirán en el disco. Si hay presión de la agrupación de almacenamiento intermedio, las páginas tempdb se pueden vaciar al disco. Si no lo hay, no debería ocurrir.
Editar: Debatable si "mal comportamiento" es una descripción apropiada para una base de datos de usuarios que está escribiendo páginas fuera del punto de control. ¿Inusual, atípico o simplemente no ideal quizás?
Edición adicional (siguientes comentarios / chat con @PaulWhite):
La omisión evidente anterior es que las tablas temporales no son la única fuente de tráfico tempdb. Cita de Comprender los eventos de derrames de Hash, ordenar e intercambiar :
Ciertas operaciones de ejecución de consultas de SQL Server están calibradas para funcionar mejor utilizando una cantidad (algo) grande de memoria como almacenamiento intermedio. El Optimizador de consultas elegirá un plan y estimará el costo en función de estos operadores utilizando este bloc de notas de memoria. Pero esto es, por supuesto, solo una estimación. En la ejecución, las estimaciones pueden resultar incorrectas y el plan debe continuar a pesar de no tener suficiente memoria. En tal caso, estos operadores se derraman al disco.
Asumí incorrectamente que el mecanismo detrás de una escritura física para una operación de derrame era exactamente el mismo que se describió anteriormente, es decir, el lazywriter obliga a las páginas tempdb al disco como resultado de la presión sobre el grupo de búferes (causado por el derrame).
@PaulWhite explicó dónde estaba equivocado (¡gracias Paul!):
Creo que se está preguntando por qué la actividad física de tempdb ocurre cuando una consulta excede su concesión de memoria en el espacio de trabajo, en lugar de usar solo tempdb-in-memory. subvenciones en primer lugar.
Los derrames son realmente especiales en la escritura hasta el almacenamiento. La actividad física de tempdb se ve en un derrame, incluso ante montones de memoria libre y presión cero sobre tempdb.
Paul también me señaló su publicación de blog Tuning TSQL avanzado: Por qué es importante el conocimiento interno que incluye scripts de ejemplo para demostrar derrames, para aquellos que desean profundizar más.
