División de TempDB en archivos múltiples igual al número de CPU

El artículo SQL Server tempdb Best Practices Increase Performance sugiere que debería dividirme tempdben una cantidad de archivos igual a la cantidad de núcleos. Entonces, para 4 núcleos obtienes 4 archivos.

Al tener la mayor cantidad de archivos, puede aumentar la cantidad de operaciones físicas de E / S que SQL Server puede insertar en el disco en cualquier momento. Mientras más E / S pueda SQL Server empujar al nivel del disco, más rápido se ejecutará la base de datos. Con bases de datos estándar, SQL Server puede almacenar en caché una gran cantidad de datos que necesita en la memoria. Debido a la naturaleza de alta escritura de tempdb, los datos deben escribirse en el disco antes de que puedan volver a almacenarse en la memoria caché.

Aunque suena bien en teoría, ¿es realmente tan bueno como una optimización general? ¿Es algo que solo puede aplicarse a sistemas específicos donde la IO es muy alta?

Una relación de 1/4 a 1/2 veces el número de archivos de datos TempDB a núcleos de máquina ha sido la recomendación desde hace mucho tiempo ...

Pero ahora hay una orientación aún mejor. En PASS en 2011, mi buen amigo Bob Ward, quien es el mejor hombre en Soporte de productos SQL, adoptó una nueva fórmula: si tiene menos de 8 núcleos, use #files = #cores. Si tiene más de 8 núcleos, use 8 archivos y si está viendo contención en memoria, agregue 4 archivos más a la vez. [enlace]

La última oración siempre ha sido relevante. Si no está viendo contención, ¿por qué agregar archivos adicionales? Para jugar de forma segura, la mayoría agregará 2-4 archivos como punto de partida para la mayoría de las compilaciones, pero más allá de eso, mida y reaccione.

Como la mayoría de las pautas generales , es una simplificación excesiva en su luz más positiva. En el mejor de los casos, es un buen punto de partida (siempre que no esté manteniendo la relación 1: 1 núcleo: archivo de datos con una gran cantidad de núcleos).

No hay sustituto para el diseño adecuado y el seguimiento adecuado y la línea de base . La razón detrás de tener múltiples archivos de datos para tempdb es reducir y mitigar la contención de la página de asignación. Existen numerosas publicaciones publicadas sobre cómo monitorear esta disputa y tomar medidas en consecuencia. A continuación hay algunos recursos:

Desglosando la contención de TempDB (Parte 1)
Desglosando la contención de TempDB (Parte 2)
Análisis de la contención de Tempdb
Optimización de la configuración de tempdb con SQL Server 2012 Extended Events

Pero para responder a su pregunta, no, esto no es una parte difícil y rápida de configurar y olvidar de tempdb .