¿Qué es hot spotting en el contexto de agregar archivos a tempdb?

Estoy tratando de averiguar si es posible agregar archivos tempdb a un servidor SQL sin tener que reiniciar el servicio SQL Server. Vi esta respuesta aquí en Administradores de bases de datos:

• Tempdb Agregar archivos requiere reiniciar

Y una respuesta dice:

AGREGAR - no se requiere interrupción. Aunque, como señaló Sean de Microsoft, SQL preferirá usar los archivos con menor relleno. Si va de 1 archivo de datos y agrega más, entonces SQL usará los nuevos por un tiempo, pero su rendimiento no será peor que tener solo un archivo. Sin embargo, si ya tiene 2+ y agrega uno más, entonces se activará con el nuevo y disminuirá el rendimiento.

Sin embargo, un comentario advierte lo siguiente:

Pondría un apéndice en la parte "Agregar": "Agregar: No, pero lo más probable es que esté desequilibrado, por lo que se detectarán puntos críticos que podrían empeorar las cosas".

Tengo las siguientes preguntas sobre ese comentario, pero se me indicó que hiciera esas preguntas en una nueva pregunta propia (esta) en lugar de preguntarle al comentarista a través del comentario en las respuestas de esa pregunta.

Específicamente:

1. ¿Qué es manchado caliente? (Obtuve algo de información a través de Google, pero no en detalle qué sucede con los puntos de acceso en tempdb después de agregar archivos)
2. ¿Qué pasa con las manchas calientes que empeoran las cosas en tempdb?
3. ¿Qué cosas específicas en el DB empeorarían mucho?

1. ¿Qué es manchado caliente?

   "Hot spotting" en este contexto significa que, aunque tempdb tiene varios archivos, todo el trabajo de E / S se realiza en un solo archivo. Si tempdb está lo suficientemente ocupado como para justificar la adición de archivos, el desequilibrio que conduce a la detección de puntos calientes (debido al relleno proporcional ) será de corta duración, por lo que creo que las advertencias pueden ser un poco Chicken Little. En mi experiencia, de todos modos.

2. ¿Qué pasa con las manchas calientes que empeoran las cosas en tempdb?

   Creo que se considera peor en tempdb porque toma la peor parte de la actividad de escritura en la mayoría de las cargas de trabajo. Ciertamente puede sufrir problemas similares en las bases de datos de usuarios, pero como ya está tratando de resolver un problema en tempdb ...

3. ¿Qué cosas específicas en el DB empeorarían mucho?

   Escribir tiempos, principalmente. Imagine que todos intentan usar el mismo cajero automático, incluso cuando hay otros 7 cajeros automáticos cerca. Solo se puede escribir mucho en cualquier momento; todo lo demás tiene que esperar. Con más archivos (y suficientes núcleos para programar el trabajo), la E / S se puede distribuir de manera más uniforme.

   Solo asegúrate:

   • tienes un número par de archivos
   • todos los archivos son del mismo tamaño
   • todos los archivos tienen la misma configuración de crecimiento automático
   • la cantidad de archivos está determinada de alguna manera por la cantidad de núcleos
   • dependiendo de la versión (estas están habilitadas de forma predeterminada en las versiones más modernas de SQL Server ), está utilizando marcas de seguimiento 1117 (crecer todos los archivos de datos a la vez) y 1118 (no use extensiones de asignación mixtas).

1. ¿Qué es manchado caliente?

Aaron tiene razón y no voy a repetir lo que ha dicho anteriormente, sin embargo, no se trata solo del disco IO. La parte principal con la que la mayoría de las personas tiene problemas en TempDB se debe a la contención de ciertas estructuras de seguimiento.

Dado que tener múltiples archivos tempdb permite que los algoritmos de relleno proporcional y round robin tengan lugar de manera efectiva en ser "justos" en todas las asignaciones, agregar un nuevo archivo sin asignaciones lo quita un poco. No estoy de acuerdo con que sea una advertencia de "gallinita" (vea las actualizaciones del producto a continuación) si comienza a ver PAGELATCH_*esperas en dicho nuevo archivo y no muchas o ninguna en otros archivos. Esto generalmente ocurre en sistemas que tienen una alta actividad de TempDB y ya tienen más de un archivo.

Tenga en cuenta que hay opciones en SQL Server 2019 para cambiar algunas de las tablas del sistema subyacentes a tablas en memoria que pueden tener una mejora ya que los objetos en memoria se asignan de manera diferente a las tablas en disco. Las tablas basadas en disco son las tablas tradicionales con las que todos hemos estado trabajando a lo largo de los años. SQL Server 2014 introdujo tablas con memoria optimizada . SQL Server 2019 puede manejar algunos metadatos de asignación en tablas con memoria optimizada.

Se realizó otro cambio en SQL Server 2019 para ayudar con los cambios simultáneos de PFS, que generalmente es lo que la disputa por la estructura en memoria en la asignación está PAGELATCH_*esperando.

2. ¿Qué pasa con las manchas calientes que empeoran las cosas en tempdb?

Nada en mi humilde opinión. Sí, TempDB tiene más elementos que pueden causar escrituras sin ser utilizado directamente, por lo que puede obstaculizar algunos elementos. Sin embargo, una base de datos de usuarios muy ocupada en términos de velocidad de cambio de datos es igual de mala. No se limita solo a TempDB.

3. ¿Qué cosas específicas en el DB empeorarían mucho?

¡Me gusta mucho la analogía de Aaron! Esa es la esencia de lo que está sucediendo. Lo que realmente empeora es la asignación y el seguimiento del espacio para los objetos en la base de datos. Si su base de datos de usuario es mayormente estática (baja tasa de cambio) o su TempDB no se está utilizando realmente, no notará nada. Sin embargo, si es un servidor bastante ocupado, puede iniciar o exacerbar las esperas de bloqueo de página, lo que podría provocar el bloqueo de convoyes.

Aaron ya señaló que en la versión anterior hay marcas de seguimiento para asegurarse de que se usan extensiones uniformes y que todos los archivos en un grupo de archivos crecen juntos (Aaron señala 1117 y 1118 que son NOP en 2016+). La otra cosa que me gustaría señalar nuevamente es que esto no es solo para TempDB sino para cualquier base de datos, y el diseño físico debe pensarse en función de las necesidades.

Esto no es solo para problemas de puntos de acceso, sino que también se aplica a otras partes del sistema, como copia de seguridad / restauración, administración de archivos, fragmentación de metadatos del sistema de archivos, etc., que pueden ayudarse al tener múltiples archivos.

Puede ver la contención de la estructura de asignación buscando un waitresourceen una página PFS (que es la página 1, y luego cada 8088 páginas). Si ve que todo está en el mismo archivo (2: archivo: página), entonces sabe que esto está ocurriendo.