SQL Server 2016 Enterprise de bajo rendimiento

Lamento ser largo, pero quiero darle la mayor cantidad de información posible para que pueda ser útil para el análisis.

Sé que hay varias publicaciones con problemas similares, sin embargo, ya he seguido estas publicaciones y otra información disponible en la web, pero el problema persiste.

Tengo un grave problema de rendimiento en SQL Server que está volviendo locos a los usuarios. Este problema se prolonga durante varios años, y hasta finales de 2016 fue administrado por otra entidad y desde 2017 llegó a ser administrado por mí.

A mediados de 2017, pude resolver el problema siguiendo las sugerencias de indexación indicadas por los informes del panel de rendimiento de Microsoft SQL Server 2012. El efecto fue inmediato, sonaba como magia. El procesador que estuvo en los últimos días casi siempre en el 100%, se volvió súper sereno y los comentarios de los usuarios fueron rotundos. Incluso nuestro técnico de ERP estaba encantado, ya que generalmente tomaba 20 minutos obtener ciertos listados y finalmente podía hacerlo en segundos.

Con el tiempo, sin embargo, lentamente comenzó a empeorar. Evité crear más índices, por temor a que demasiados índices empeoraran el rendimiento. Pero en algún momento tuve que borrar los que no tenían uso y crear los nuevos que Performance Dashboard me sugiere. Pero sin impacto.

La lentitud que se siente es esencialmente al guardar y consultar, en el ERP.

Tengo un Windows Server 2012 R2 dedicado a SQL Server 2016 Enterprise (64 bits) con la siguiente configuración:

• CPU: CPU Intel Xeon E5-2650 v3 @ 2.30GHz
• Memoria: 84 GB
• En términos de almacenamiento, el servidor tiene un volumen dedicado al sistema operativo, otro dedicado a los datos y otro dedicado a los registros.
• 17 bases de datos
• Usuarios:
  • En el DB más grande están conectados más o menos 113 usuarios concurrentes
  • En otro hay unos 9 usuarios.
  • En dos de ellos son 3 + 3
  • El resto tiene solo 1 usuario cada uno
  • Tenemos una web que también escribe para la base de datos más grande, pero donde el uso es mucho menos regular y debe tener unos 20 usuarios.
• Tamaño de DBs:
  • La mayor de las bases de datos tiene 290 GB.
  • El segundo más grande tiene 100GB.
  • El tercero más grande tiene 20 GB.
  • El cuarto 14 GB
  • El resto son un poco más de 3 GB cada uno

Esta es la instancia de producción, pero también tenemos una instancia de desarrollo que creo que se puede ignorar para este propósito, porque la mayoría de las veces soy el único que se conecta allí, pero este problema ocurre constantemente, incluso cuando no estoy conectado .

El procesador casi siempre es así:

Tenemos rutinas que se ejecutan durante la noche (no problemáticas) y algunas que se ejecutan durante el día.

Los usuarios se conectan a través del Escritorio remoto a otras máquinas configuradas por ODBC 32 para acceder a SQL Server.

El centro de datos donde se encuentran los servidores tiene 100/100 Mbps, así como donde estoy. La mayoría de los sitios están vinculados por MPLS y otros por IPSec (de FO a 4G). El proveedor hizo muchos análisis y el circuito está bien.

La proporción de aciertos de caché es del 99% (tanto solicitudes de usuario como sesiones de usuario)

Las esperas se ven así:

Ya he recopilado datos con Perfmon y tengo los resultados si ayudan con su análisis; personalmente, no obtuve ninguna conclusión del análisis.

Cuento con su apoyo para resolver este problema, estando disponible para proporcionar la información que considere necesaria para la resolución.

Muchas gracias.

Aquí está el descuento de sp_blitz (reemplacé los nombres de las empresas con seudónimos):

Prioridad 1: Fiabilidad :

• Última buena DBCC CHECKDB más de 2 semanas de edad

  • Maestro

  • modelo - Último CHECKDB exitoso: 2018-02-07 15: 04: 26.560

  • msdb - Último CHECKDB exitoso: 2018-02-07 15: 04: 27.740

Prioridad 10: Rendimiento :

• CPU con número impar de núcleos

  • El nodo 0 tiene 5 núcleos asignados. Esta es una muy mala configuración de NUMA.

  • El nodo 1 tiene 5 núcleos asignados. Esta es una muy mala configuración de NUMA.

Prioridad 20: Configuración de archivo :

• TempDB en la unidad C tempdb: la base de datos tempdb tiene archivos en la unidad C. TempDB con frecuencia crece de manera impredecible, lo que pone a su servidor en riesgo de quedarse sin espacio en el disco C y estrellarse con fuerza. C también suele ser mucho más lento que otras unidades, por lo que el rendimiento puede verse afectado.

Prioridad 50: Fiabilidad :

• Errores registrados recientemente en el seguimiento predeterminado
  • master - 2018-03-07 08: 43: 11.72 Error de inicio de sesión: 17892, Severidad: 20, Estado: 1. 2018-03-07 08: 43: 11.72 Error de inicio de sesión para iniciar sesión 'example_user' debido a la ejecución del disparador. [CLIENTE: IPADDR]

(nota: muchos errores como este debido a un activador habilitado que limita las sesiones de usuario, para el control de uso de licencias ERP)

• Verificación de página no óptima

  • DATABASE_A - La base de datos [DATABASE_A] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_B - La base de datos [DATABASE_B] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_C: la base de datos [DATABASE_C] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_D - La base de datos [DATABASE_D] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_E - La base de datos [DATABASE_E] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_F - La base de datos [DATABASE_F] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_G - La base de datos [DATABASE_G] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_H - La base de datos [DATABASE_H] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_I - La base de datos [DATABASE_I] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_Z - La base de datos [DATABASE_Z] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_K - La base de datos [DATABASE_K] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_J - La base de datos [DATABASE_J] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_L: la base de datos [DATABASE_L] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_M - La base de datos [DATABASE_M] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_O - La base de datos [DATABASE_O] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_P - La base de datos [DATABASE_P] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_Q - La base de datos [DATABASE_Q] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_R - La base de datos [DATABASE_R] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_S: la base de datos [DATABASE_S] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_T: la base de datos [DATABASE_T] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_U: la base de datos [DATABASE_U] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_V - La base de datos [DATABASE_V] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

  • DATABASE_X: la base de datos [DATABASE_X] tiene NINGUNO para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

• DAC remoto deshabilitado: el acceso remoto a la conexión de administrador dedicada (DAC) no está habilitado. El DAC puede hacer que la solución remota de problemas sea mucho más fácil cuando SQL Server no responde.

Prioridad 50: Información del servidor :

• Inicialización instantánea de archivos no habilitada: considere habilitar IFI para restauraciones y crecimientos de archivos de datos más rápidos.

Prioridad 100: Rendimiento :

• Factor de relleno cambiado

  • DATABASE_A: la base de datos [DATABASE_A] tiene 417 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_B: la base de datos [DATABASE_B] tiene 318 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_C: la base de datos [DATABASE_C] tiene 346 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_D: la base de datos [DATABASE_D] tiene 663 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_E: la base de datos [DATABASE_E] tiene 335 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_F: la base de datos [DATABASE_F] tiene 1705 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_G: la base de datos [DATABASE_G] tiene 671 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_H: la base de datos [DATABASE_H] tiene 2364 objetos con factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_I: la base de datos [DATABASE_I] tiene 1658 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_Z: la base de datos [DATABASE_Z] tiene 673 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_K: la base de datos [DATABASE_K] tiene 312 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_J: la base de datos [DATABASE_J] tiene 864 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_L: la base de datos [DATABASE_L] tiene 1170 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_M: la base de datos [DATABASE_M] tiene 382 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_O: la base de datos [DATABASE_O] tiene 356 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • msdb: la base de datos [msdb] tiene 8 objetos con factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_P: la base de datos [DATABASE_P] tiene 291 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_Q: la base de datos [DATABASE_Q] tiene 343 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_R: la base de datos [DATABASE_R] tiene 2048 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_S: la base de datos [DATABASE_S] tiene 325 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_T: la base de datos [DATABASE_T] tiene 322 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_U: la base de datos [DATABASE_U] tiene 351 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_V: la base de datos [DATABASE_V] tiene 312 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • DATABASE_X: la base de datos [DATABASE_X] tiene 352 objetos con un factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

  • tempdb: la base de datos [tempdb] tiene 2 objetos con factor de relleno = 70%. Esto puede causar problemas de rendimiento de memoria y almacenamiento, pero también puede evitar divisiones de página.

• Muchos planes para una consulta: 20763 planes están presentes para una sola consulta en la caché del plan, lo que significa que probablemente tengamos problemas de parametrización.

• Activadores del servidor habilitados: el activador del servidor [connection_limit_trigger] está habilitado. Asegúrese de comprender lo que está haciendo ese disparador: cuanto menos trabajo haga, mejor.

• Procedimiento almacenado CON RECOMPILA

  • master - [master]. [dbo]. [sp_AllNightLog] tiene WITH RECOMPILE en el código de procedimiento almacenado, lo que puede aumentar el uso de la CPU debido a las constantes recompilaciones del código.

  • master - [master]. [dbo]. [sp_AllNightLog_Setup] tiene WITH RECOMPILE en el código de procedimiento almacenado, lo que puede causar un mayor uso de la CPU debido a las constantes recompilaciones del código.

Prioridad 110: Rendimiento :

• Tablas activas sin índices agrupados

  • DATABASE_A: la base de datos [DATABASE_A] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • DATABASE_B: la base de datos [DATABASE_B] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • DATABASE_C: la base de datos [DATABASE_C] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • DATABASE_E: la base de datos [DATABASE_E] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • DATABASE_F: la base de datos [DATABASE_F] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • DATABASE_H: la base de datos [DATABASE_H] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • DATABASE_I: la base de datos [DATABASE_I] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • DATABASE_K: la base de datos [DATABASE_K] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • DATABASE_O: la base de datos [DATABASE_O] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • DATABASE_Q: la base de datos [DATABASE_Q] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • DATABASE_S: la base de datos [DATABASE_S] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • DATABASE_T: la base de datos [DATABASE_T] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • DATABASE_U: la base de datos [DATABASE_U] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • DATABASE_V: la base de datos [DATABASE_V] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • DATABASE_X: la base de datos [DATABASE_X] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

Prioridad 150: Rendimiento :

(Nota: aquí hay muchos consejos, pero no pude incluirlos debido a la limitación de caracteres. Si hay otra forma de compartir, indíquelo).

Nos diste una pregunta larga (y muy detallada). Ahora tienes que lidiar con una respuesta larga. ;)

Hay varias cosas que sugeriría cambiar en su servidor. Pero comencemos con el problema más apremiante.

Medidas de emergencia únicas:

El hecho de que el rendimiento fue satisfactorio después de desplegar los índices en su sistema y el rendimiento que se degrada lentamente es un indicio muy fuerte de que necesita comenzar a mantener sus estadísticas y (en menor grado) cuidar la fragmentación del índice.

Como medida de emergencia, sugeriría una actualización de estadísticas manual única en todas sus bases de datos. Puede obtener el TSQL nessecary ejecutando este script:

DECLARE @SQL VARCHAR(1000)  
DECLARE @DB sysname  

DECLARE curDB CURSOR FORWARD_ONLY STATIC FOR  
   SELECT [name]  
   FROM master..sysdatabases 
   WHERE [name] NOT IN ('model', 'tempdb') 
   ORDER BY [name] 

OPEN curDB  
FETCH NEXT FROM curDB INTO @DB  
WHILE @@FETCH_STATUS = 0  
   BEGIN  
       SELECT @SQL = 'USE [' + @DB +']' + CHAR(13) + 'EXEC sp_updatestats' + CHAR(13)  
       PRINT @SQL  
       FETCH NEXT FROM curDB INTO @DB  
   END  

CLOSE curDB  
DEALLOCATE curDB

Es proporcionada por Tim Ford en su entrada de blog en mssqltips.com y él también se explica por qué la actualización de estadísticas materia.

Tenga en cuenta que esta es una tarea intensiva de CPU e IO que no debe hacerse durante las horas de negocios.

Si esto resuelve tu problema, ¡no te detengas allí!

Mantenimiento regular:

Eche un vistazo a Ola Hallengren Maintenance Solution y luego configure al menos estos dos trabajos:

• Un trabajo de actualización de estadísticas (si es posible todas las noches). Puede usar este código CMD en su trabajo de agente. Este trabajo tiene que ser creado desde cero.

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d MSSYS -Q "EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y', @MaxDOP = 0, @LogToTable = 'Y'" -b

• Un trabajo de mantenimiento de índice. Sugeriría comenzar con una ejecución programada una vez al mes. Puede comenzar con los valores predeterminados que Ola proporciona para el trabajo IndexOptimize.

Hay varias razones por las que sugiero el primer trabajo para actualizar las estadísticas por separado:

• Una reconstrucción de índice solo actualizará las estadísticas de las columnas cubiertas por ese índice, mientras que una reorganización de índice no actualiza las estadísticas en absoluto. Ola separa la fragmentación en tres categorías. Por defecto, solo se reconstruirán los índices altos de categoría.
• Las estadísticas de las columnas no cubiertas por un índice solo serán actualizadas por el trabajo IndexOptimize.
• Para mitigar el problema clave ascendente .

SQL Server actualizará automáticamente las estadísticas si el valor predeterminado se deja habilitado. El problema con eso son los umbrales (menos de un problema con su SQL Server 2016). Las estadísticas se actualizan cuando cambia una cierta cantidad de filas (20% en versiones anteriores de SQL Server). Si tiene tablas grandes, puede haber muchos cambios antes de que se actualicen las estadísticas. Ver más información sobre umbrales aquí .

Dado que usted está haciendo CHECKDB, por lo que puedo decir, puede seguir haciéndolos como antes o usar la solución de mantenimiento para eso también.

Para obtener más información sobre la fragmentación y el mantenimiento del índice, consulte:

Descripción general de la fragmentación del índice de SQL Server

Deje de preocuparse por la fragmentación de SQL Server

Teniendo en cuenta su subsistema de almacenamiento, sugeriría que no se fije demasiado en la "fragmentación externa" porque de todos modos los datos no se almacenan en orden en su SAN.

Optimiza tu configuración

El script sp_Blitz le brinda una excelente lista para comenzar.

Prioridad 20: Configuración de archivo - TempDB en unidad C: hable con su administrador de almacenamiento. Pregúnteles si su unidad C es el disco más rápido disponible para su SQL Server. Si no, pon tu tempdb allí ... punto. Luego verifique cuántos archivos temdb tiene. Si la respuesta es una, arregla eso . Si no son del mismo tamaño, arregle esos dos.

Prioridad 50: Información del servidor - Inicialización instantánea de archivos no habilitada: siga el enlace que le proporciona el script sp_Blitz y habilite IFI.

Prioridad 50: Confiabilidad - Verificación de página no óptima: debe volver a establecer esto en el valor predeterminado (CHECKSUM). Siga el enlace que le proporciona el script sp_Blitz y siga las instrucciones.

Prioridad 100: Rendimiento - Factor de relleno modificado: pregúntese por qué hay tantos objetos con el factor de relleno establecido en 70. Si no tiene una respuesta y ningún proveedor de aplicaciones lo exige estrictamente. Vuelva a configurarlo al 100%.

Esto básicamente significa que SQL Server dejará un 30% de espacio vacío en estas páginas. Entonces, para obtener la misma cantidad de datos (en comparación con el 100% de las páginas completas), su servidor debe leer un 30% más de páginas y ocupará un 30% más de espacio en la memoria. La razón por la que a menudo se hace es para evitar la fragmentación del índice.

Pero de nuevo, su almacenamiento está guardando esas páginas en diferentes partes de todos modos. Entonces lo volvería a configurar al 100% y lo tomaría desde allí.

Qué hacer si todos están felices:

• Vea el resto de la salida de sp_Blitz y decida si los cambia como se sugiere.
• Ejecute sp_BlitzIndex y eche un vistazo a los índices que creó, si se usan o dónde podría haber una oportunidad para agregar / cambiar uno.
• Eche un vistazo a los datos de su tienda de consultas (como lo sugiere Peter). Puedes encontrar una introducción aquí .
• Disfruta de la estrella de rock en vivo que un DBA merece. ;)

Sin ignorar todas sus respuestas que fueron muy útiles y que apliqué o aplicaré, el mayor problema no fue fácil de encontrar.

El problema empeoró en los días posteriores a nuestros últimos mensajes.

Como estamos basados ​​en la nube, ni yo ni la compañía que administra la infraestructura y nos brinda soporte tiene acceso a los hosts físicos.

Algo me hizo preguntarme cuando noté que algunos días el procesador estaba en promedio al 20% y otros días era mucho más alto, más del 60%, cuando la carga de trabajo, aunque nunca exactamente la misma, es similar. Hay la misma cantidad de personas que realizan más o menos el mismo tipo de operaciones.

A principios de esta semana, los usuarios comenzaron a quedarse atascados durante varios minutos y solo el procesador fue estrangulado. Le pedí a varios usuarios que se desconectaran (aquellos que gastaban más recursos pero todavía nada fuera de lo común), apagué varios servicios vinculados a la base de datos y al final nada ha cambiado. Le pregunté al administrador del sistema que nos respalda y que puede comunicarse con los muchachos de nuestra nube para controlar remotamente mi máquina para ver lo que estaba viendo y ayudarme a encontrar algo, porque no podía hacer mejor para encontrar el problema.

El técnico tampoco encontró nada. Finalmente comenzó a darme alguna razón de que algo más tenía que estar causando este problema y fue cuando contactó con la nube. En la nube, no se dieron cuenta de nada, solo porque hay un equilibrio de carga configurado entre los hosts físicos, la VM que admite nuestro servidor SQL se movió varias veces ese día entre los hosts físicos. Afortunadamente, le dije a nuestro técnico exactamente a qué hora comenzaron a ocurrir los problemas ese día, lo que coincidió con el momento en que la VM se trasladó por última vez a uno de los hosts físicos de la que no había salido el resto del día.

Si el técnico no hubiera seguido de cerca este problema, esta sería una de esas veces en las que incluso podría hablar con los chicos de la nube, pero cuando veían muestras de rendimiento, no obtendrían nada, porque una vez más, la nube solo veía muestras con CPU del orden del 40/50%, cuando en realidad era en promedio superior al 80% y a menudo se quedaba al 100%.

Ahora la máquina está de pie en un host físico (no se mueve entre hosts) y aunque todavía no hemos logrado el rendimiento perfecto, todos están trabajando y dando muchos más comentarios positivos, porque la CPU promedio es de aproximadamente el 20% con todos nuestros usuarios y servicios.

Mientras tanto, también pusimos tempdb en otro disco (estaba en el disco del sistema operativo) y aumentamos los archivos, para estar más de acuerdo con el número de núcleos de las CPU.

El número de núcleos también se ajustó según las recomendaciones de sp_Blitz.

También había una rutina automática que se estaba ejecutando todo el día en función de una fecha anterior ... y dado que no terminó en la mañana cuando llegamos, y no tenemos forma de verificar si está funcionando o no, todavía comencé a correr manualmente Pero probablemente el otro todavía estaba corriendo y corría dos veces durante ese tiempo. Hemos cambiado la fecha para reducir el tiempo que lleva, y ahora es tarde en la noche. Pero esta no era la solución, ya que se resolvió antes de muchos problemas que tuvimos como el que se describe aquí.

También logramos que el asistente de ERP programe una reunión con el fabricante, por lo que vamos a mostrar nuestro sistema y buscar sugerencias, así como aclarar algunas dudas, ya que hay recomendaciones en los videos de capacitación que son contrarias a la mayoría recomendaciones, incluido el propio Microsoft, como Priority Boost on y Fill Factor 70%.

Como la aplicación también tiene una pantalla de mantenimiento, buscaré la periodicidad requerida de este mantenimiento y lo que queda por hacer fuera de la aplicación. Mi idea es usar los planes de Ola Hallengren.

Creo que la respuesta de Thomas Kronawitter es absolutamente correcta y la estoy aplicando, sin embargo, creo que esta descripción puede ser importante para otras personas que después de seguir todas las buenas prácticas todavía no pueden solucionar el problema porque puede estar en los hosts físicos . Gracias Thomas