Contenciones TempDB

Tenemos una base de datos OLTP activa de 40 GB en SQL Server 2014 SP1. Se encuentra que las consultas son lentas con IO_Completion espera, la longitud de la cola de disco aumenta a 900 y SQL Server deja de responder. Lo que probamos:

1. Reinicie la instancia y con un minuto comienza a comportarse de la misma manera.

2. Después del segundo reinicio, cambiamos el tamaño inicial de cada archivo de datos tempdb (se crean 16 archivos de datos) y comienza a funcionar correctamente.

Nota: Estamos usando variables de tabla para conjuntos de resultados intermedios. Estos conjuntos de resultados son muy pequeños.

Sucedió dos veces en un mes. Cada vez que agrego un poco de espacio manualmente a los archivos de datos, comienza a funcionar normalmente. Lo más interesante es que la misma configuración (mismo hardware, misma carpeta y configuración de archivos, misma carga de trabajo) que tenemos en SQL Server 2008 R2 y SQL Server 2012 está funcionando bien.

Ayúdenos a encontrar una solución permanente.

El tamaño inicial de todos los archivos de datos es de 1000 MB, el actual es de 1500 MB cada uno. Todos son idénticos El crecimiento automático es de 100 MB para cada uno. Antes de esto, enfrentábamos la disputa de páginas PFS y GAM y aumentamos a 16 y el problema se resolvió. Ambas marcas de seguimiento 1117 y 1118 están habilitadas. 24 núcleos en 2 nodos NUMA. Todos los archivos de datos están en el mismo volumen. Disco simple, sin SAN.

La instancia está en una máquina física. Las consultas con Variables de tabla y las consultas con Hash Joins suelen generar esperas IO_Completion.

La respuesta detallada de wBob nos empujó a buscar más en detalle. ¿Cómo lo perdimos antes?

El usuario canceló el crecimiento automático del archivo 'templog' en la base de datos 'tempdb' o se agotó el tiempo de espera después de 7704 milisegundos. Use ALTER DATABASE para establecer un valor de FILEGROWTH más pequeño para este archivo o para establecer explícitamente un nuevo tamaño de archivo.

Esto lo encontramos en el registro cuando se produce este tipo de problema. Estamos moviendo TempDB para separar el disco rápido.

Creo que has fragmentado demasiado tu tempdb y hay una falta de coincidencia entre la CPU del servidor y la configuración del disco, pero recopilemos más información:

Preguntas / Se requiere más información

• Confirme el nombre y el tipo de procesador (básicamente estoy tratando de establecer si es 2 x hex-core con HT). Utilice la información del sistema (por ejemplo, Panel de control> Sistema y seguridad> Sistema en Windows Server 2012 R2) y / o la herramienta sysinternals CoreInfo para confirmar.
• Confirme maxdop del servidor (p EXEC sp_configure 'max degree of parallelism'. Ej .). Si las CPU son de núcleo hexadecimal, el maxdop del servidor debe ser como máximo 6 (según aquí ), o posiblemente más bajo en un sistema OLTP. Normalmente mantengo mis archivos tempdb en línea con mi DOP de servidor a un máximo de 8, pero llegaremos a eso.
• Confirme la memoria total del servidor en la caja y el límite de memoria del servidor SQL (por ejemplo EXEC sp_configure 'max server memory (MB)').
• Confirme si se están ejecutando otros servicios en la caja (por ejemplo, SSIS, SSAS, SSRS, la aplicación, iTunes, etc.)
• Confirme que la inicialización instantánea de archivos esté habilitada para la cuenta de servicio de SQL Server. (Formas de probarlo aquí ).
• ¿Por qué hay una discrepancia tan grande entre la CPU (configuración NUMA de 2 nodos robusta) frente al disco único (PC doméstico)? Considere agregar discos, rayas, SSD para tempdb (aunque evite una reacción exagerada ).
• Agregue un plan de ejecución real para una de las consultas problemáticas. Anonimice con SQL Sentry Plan Explorer si lo desea.

• Hash se une con variables de tabla en un sistema OLTP? Esto sugiere una falta de indexación en la tabla variable, tabla principal o ambas. ¿Está declarando sus variables de tabla de esta manera (sin índices)?

  DECLARE @t TABLE ( x INT )

• No escatime en la definición de la variable de la tabla aunque contenga pequeños conjuntos de resultados. Siempre es mejor darle al optimizador tanta información como sea posible para que sea explícito con nulabilidad, unicidad, ya sea que el índice esté agrupado o no agrupado, p. Ej.

  DECLARE @t TABLE ( x INT PRIMARY KEY )
  DECLARE @u TABLE ( x INT PRIMARY KEY NONCLUSTERED, u INT NOT NULL UNIQUE CLUSTERED, z INT NOT NULL UNIQUE, a CHAR(1) NULL ) -- not sure why you would do this but you can
  DECLARE @v TABLE ( x INT NOT NULL, y INT NOT NULL, PRIMARY KEY ( x, y ) )   -- multi-column primary key

• Publicar el plan de ejecución ayudará a diagnosticar esto.

• Verifique el código que impide el almacenamiento en caché de la variable de la tabla según aquí , aquí . Creo que el SQL dinámico y el proceso ejecutado CON RECOMPILE son los únicos que afectan las variables de la tabla.

  DECLARE @u TABLE ( x INT )
  
  INSERT @u
  EXEC('DECLARE @t TABLE ( x INT ); INSERT INTO @t VALUES ( 1 ); SELECT x FROM @t;' )
  
  SELECT *
  FROM @u

• Verifique el registro de SQL Server (Object Explorer> Management> SQL Server Logs) para ver mensajes, por ejemplo, advertencias de E / S.

• Comprobar el visor de eventos de Windows
• Se han lanzado varias compilaciones desde SP1. Revise las correcciones CU instaladas desde SP1 . Es posible que haya errores en el SP1 corregidos en las CU posteriores, por ejemplo, REVISIÓN: Ordenar los derrames del operador a tempdb en SQL Server 2012 o SQL Server 2014 cuando el número estimado de filas y el tamaño de fila son correctos https://support.microsoft.com/en- nosotros / kb / 3088480
• Establezca que esta es su causa antes de aplicar cualquier revisión, aunque es más importante mantenerse actualizado con las CU con SQL Server 2014, debido a la cantidad de nuevas características (OLTP en memoria, almacén de columnas en clúster).
• Finalmente, la necesidad de un archivo tempdb por núcleo es un mito y, mirando la configuración de su disco, supongo que tempdb está demasiado fragmentado. Tengo la sensación de que tienes una cabeza de disco, tempdb tiene un grupo de archivos, muchos archivos.

Sin embargo, olvida lo que creemos que sabemos; cree una plataforma de prueba que reproduzca su problema y experimente con la reducción de la cantidad de archivos temporales ... comience en 1, 2, 4, 6, etc., recopile la información para tomar una decisión basada en la evidencia. Ahora, esta es la parte más difícil ya que su problema parece intermitente y es posible que no pueda meterse con su configuración tempdb, pero así es como abordaría esto.

Buena suerte. Háganos saber cómo le va.