¿Por qué las consultas causan derrames a tempdb?

Fondo

Estoy en el proceso de migrar una base de datos de 160 gb de MSSQL 2008 (estándar) en un servidor Win 2008 con 48 gb de RAM a un nuevo servidor que ejecuta MSSQL 2012 (edición web de 64 bits) en Win 2012 con 64 gb de RAM. El antiguo servidor está activo y bajo carga; El nuevo servidor no está en producción. El nuevo servidor tiene 8 archivos tempdb (4 GB cada uno).

Problema

En las pruebas en el nuevo servidor, veo pasos en numerosas consultas que provocan alertas que mencionan "el operador usó tempdb para derramar datos durante la ejecución". He podido evitar algunos tipos reescribiendo algunas de las consultas, pero esto realmente no está solucionando el problema. Las mismas consultas en el servidor anterior no causan derrames. He leído que los derrames ocurren cuando MSSQL no puede completar una operación en la memoria y tiene que derramar / página en tempdb. ¿Debería preocuparme por los derrames?

Ejemplos

ingrese la descripción de la imagen aquí

He ejecutado sp_updatestats en la base de datos, por lo que las estadísticas deben estar actualizadas, pero notará que existen algunas discrepancias entre el número estimado y real de filas.

Preocupación de la memoria

He establecido una configuración de memoria máxima para MSSQL de 58 de 64 gb. Actualmente, MSSQL ha consumido alrededor de 35 gb de esta memoria, pero tiene un conjunto de trabajo de solo 682 mb. El antiguo servidor (aunque en producción, manejo de carga) tiene 44 gb de memoria comprometida con MSSQL, de los cuales 43.5 gb están en su conjunto de trabajo.

ingrese la descripción de la imagen aquí

No sé si los derrames podrían estar relacionados con una configuración de memoria. ¿Alguien tiene alguna idea? MSSQL actualmente tiene acres de RAM de sobra, entonces, ¿por qué se está derramando en tempdb para algunos tipos y coincidencias hash?

sql-server sql-server-2012

— Andy W
fuente

La alerta en el plan de ejecución es nueva en 2012. ¿Ha verificado que no se estaba derramando todo el tiempo en el servidor anterior? ¿Estabas monitoreando esto?

— Martin Smith

@ MartinSmith ah, no me di cuenta de que la alerta era nueva. No estaba monitoreando los derrames en el antiguo servidor. Investigará eso.

Punto ligeramente tangente, pero estoy sentado frente a una unión de 10 mesas que, de manera predeterminada, utiliza principalmente combinaciones de fusión con muy buenas estimaciones de filas que provocan derrames de nivel 0 tempdb y 25 segundos de tiempo de ejecución. Forzar uniones hash (y orden) elimina los derrames y se ejecuta en 9 segundos. Me pregunto si es la fusión vs hash o el derrame que causa la diferencia y si el optimizador está ponderando adecuadamente el efecto de un próximo derrame aparentemente conocido (porque las estimaciones de las filas son muy buenas).

— crokusek

El nuevo servidor tiene hardware numa?

— stacylaray

Hay varias preguntas diferentes aquí:

P: ¿Por qué no se estaban derramando las consultas antes?

Lo fueron, pero SQL Server Management Studio no lo consideró un error claro antes de SQL 2012. Es un gran ejemplo de por qué cuando realiza ajustes de rendimiento, debe ir más allá del plan de ejecución gráfico.

P: ¿Por qué las consultas se derraman al disco?

Porque SQL Server no les otorgó suficiente memoria para completar sus operaciones. Quizás el plan de ejecución subestimó la cantidad de memoria requerida, o quizás la caja está bajo presión de memoria, o son solo grandes consultas. (Recuerde, SQL Server usa memoria para tres cosas: almacenamiento en caché de páginas de datos sin procesar, almacenamiento en caché de planes de ejecución y espacio de trabajo para consultas. Esa memoria del espacio de trabajo termina siendo bastante pequeña).

P: ¿Cómo puedo reducir los derrames?

Al escribir sentencias T-SQL sargable, tener estadísticas actualizadas, poner suficiente memoria en el servidor, construir los índices correctos e interpretar los planes de ejecución cuando las cosas no funcionan de la manera esperada. Consulte el libro de Grant Fritchey SQL Server Query Performance Tuning para obtener explicaciones detalladas de todos ellos.

— Brent Ozar
fuente