¿Cuándo usar sort_in_tempdb al reconstruir índices?

Estamos debatiendo si usar la opción SORT_IN_TEMPDB para nuestras tablas DW. Tengo entendido que hay más escrituras al usar esta opción, aunque son más secuenciales. Tenemos una SAN (que a veces ha sido notoriamente lenta), por lo que en nuestro caso queremos limitar el número de escrituras tanto como sea posible. Creo que tempdb está en un LUN (conjunto de discos) separado.

Tenemos mucho espacio en disco en nuestro archivo de datos y en nuestro archivo tempdb. En este caso, ¿nos beneficiaría usar SORT_IN_TEMPDB?

Una cosa que me llamó la atención fue este comentario en esta respuesta

Al reconstruir un índice, necesitaría el doble del espacio del índice + 20% para la clasificación. Entonces, en general, para reconstruir cada índice en su base de datos, solo necesita el 120% de su índice más grande en su base de datos. Si usa SORT_IN_TEMPDB, solo gana un 20%, aún necesita un 100% adicional en su archivo de datos. Además, usar sort in tempdb aumenta drásticamente su carga de E / S, ya que en lugar de escribir el índice una vez en el archivo de datos, ahora lo escribe una vez en tempdb y luego lo escribe en el archivo de datos. Entonces eso no siempre es ideal.

Definitivamente no queremos aumentar nuestra carga de E / S con nuestra SAN lenta / posiblemente mal configurada.

¿Cuál sería la mejor manera de probar esto? ¿Simplemente reconstruyendo la tabla con y sin la opción y registrando los tiempos?

Editar : Tenemos 8 archivos tempdb, cada uno de 15GB. Tenemos banderas TF 1117/1118 establecidas e IFI está habilitado. Actualmente hacemos una mezcla de reconstrucción con la opción sort_in_tempdb y sin ella.

¡Gracias!

SQL Server 2012 Enterprise

SORT_IN_TEMPDBsignifica que el servidor SQL lo usará tempdbpara asignar el espacio temporal en lugar de asignar espacio en la base de datos de usuarios cuyo índice se está reconstruyendo. Esto significa que necesitará menos espacio libre en su base de datos de usuario durante una operación de reconstrucción de índice y más espacio libre en tempdb.

Le da una mejor ventaja cuando tempdb está en un conjunto diferente de discos (LUN) de la base de datos del usuario.

Desde la opción SORT_IN_TEMPDB - BOL :

Si la opción SORT_IN_TEMPDB está configurada en ON y tempdb está en un conjunto separado de discos del grupo de archivos de destino, durante la primera fase, las lecturas de las páginas de datos se producen en un disco diferente de las escrituras en el área de trabajo de clasificación en tempdb. Esto significa que las lecturas de disco de las claves de datos generalmente continúan más en serie en todo el disco, y las escrituras en el disco tempdb también son generalmente en serie, al igual que las escrituras para construir el índice final. Incluso si otros usuarios usan la base de datos y acceden a direcciones de disco separadas, el patrón general de lecturas y escrituras es más eficiente cuando se especifica SORT_IN_TEMPDB que cuando no lo está.

Asegúrese de leer los requisitos de espacio en disco cuando SORT_IN_TEMPDB está activado .

SAN lento / posiblemente mal configurado

Ya sabes el punto de dolor. ¿Por qué no trabajas con tu administrador de SAN para solucionarlo? Una SAN mal configurada o lenta causará todo tipo de problemas, como la lentitud .

Algunos puntos importantes a tener en cuenta:

• Use MAXDOP = 1 cuando realice una reconstrucción de índice en línea ; de lo contrario, aumentará la fragmentación.
• Reorganice / reconstruya de forma inteligente sus índices según el nivel de fragmentación y los fragmentos de página.
• Lea la experiencia de SQLFool con la creación de un índice de 60 GB
• Asegúrese de haber configurado tempdb correctamente: TF 1117 (CRECER TODOS LOS ARCHIVOS EN UN FILEGROUP IGUALMENTE) y 1118 (SOLO EXTENSIONES COMPLETAS) y tener más archivos de datos tempdb .

¿Cuál sería la mejor manera de probar esto?

Sí, debe probarlo analizando las estadísticas de espera cuando reconstruye el índice con y sin SORT_IN_TEMPDB. Mida el tiempo de ejecución también y cuando lo haga en PROD, asegúrese de hacerlo durante una ventana de mantenimiento o menos actividad del servidor. También verifique sus datos de lectura / escritura y la latencia de registro .

No estoy seguro de que tenga una inicialización instantánea de archivos , pero se beneficiará al restaurar, durante el crecimiento automático de los archivos de datos y al crear una nueva base de datos (solo mencionando la integridad).