Problema de disponibilidad del servidor SQL: una consulta grande impide que otras conexiones se conecten

Problema de disponibilidad del servidor SQL: una consulta grande impide que otras conexiones se conecten

Tengo un servidor de alta especificación (multinúcleo, RAID) que ejecuta MS SQL 2008, con varias bases de datos. Tengo un proceso de bajo rendimiento que periódicamente necesita una pequeña cantidad de información de una de las bases de datos y el código parece funcionar bien.

Sin embargo, a veces, cuando uno de mis colegas realiza una consulta enorme en una de las otras bases de datos, veo el uso total de la CPU en la máquina y las conexiones de mi aplicación se agotan.

¿Por qué pasó esto? Habría pensado que los numerosos núcleos y discos duros de alguna manera (junto con el servidor de base de datos inteligentemente escrito) podrían mantener al menos algunos de los recursos libres para otras aplicaciones. Estoy bastante seguro de que no utiliza múltiples conexiones para su consulta.

¿Qué puedo hacer para evitar esto?

EDITAR

No tengo muchos detalles sobre el hardware. Utiliza discos duros normales, raided, con Server 2k3. Es un HP que quizás tenga un par de años. Básicamente, no tiene sentido para mí que el problema sea el hardware, así que pensé que podría haber configurado algo mal.

Respuesta1

Significa que tiene una consulta muy subóptima. Sospechosos de siempre:

  • índices nulos o malos
  • funciones en columnas en la cláusula WHERE (= índices ignorados)
  • conversiones de tipos de datos/precedencia (= índices ignorados)
  • Udfs escalares con acceso a tablas en cláusulas SELECT (= efecto CURSOR)
  • Consulta de vistas/UNIRSE con vistas (una vista es una macro que se expande)

También podría ser un simple problema de recursos: ¿los datos devueltos tocan toda la base de datos, por lo que utilizan demasiada memoria y se genera paginación? ¿O recibe esperas ASYNC_NETWORK_IO, lo que puede significar que el cliente no acepta los resultados tan rápido como debería?

Generalmente, si maximiza un servidor, entonces se trata de un código y/o diseño deficiente, no del motor de base de datos.

Respuesta2

Siempre que esté seguro de haber optimizado lo más posible, es posible que desee revisar su configuración para determinar el paralelismo; el valor predeterminado es usar todos los procesadores para consultas paralelas, puede cambiarlo para maximizar un número menor dependiendo de la cantidad de procesadores que tenga, la consulta puede tardar un poco más en ejecutarse, pero debería dejar suficiente potencia de procesamiento libre para solicitudes de inicio de sesión del servicio. Si el problema se limita a esta consulta, en lugar de realizar un cambio en la configuración de todo el sistema, puede pedirle a su colega que cambie su consulta agregando una opción MAXDOP para ver si ayuda.

información relacionada