Cómo responder por qué de repente necesitamos índices o consultas que deben cambiarse

Soy junior DBA con 3 años de experiencia. Nuestro trabajo es ajustar las consultas o aconsejar a los desarrolladores que se debe volver a escribir un código en particular o que se necesitan índices.

Una pregunta simple que el equipo de desarrollo hace con frecuencia es: "Ayer funcionó bien, ¿qué cambió de repente?" y se nos pedirá que verifiquemos el lado de la infraestructura. La primera reacción ante cualquier problema siempre parece ser echarle la máxima culpa a la infraestructura, que siempre es lo primero que se valida.

¿Cómo deberíamos responder a las preguntas de "qué cambió" por parte del equipo de desarrollo? ¿Alguna vez se enfrentaron a la misma situación? Si es así, por favor, comparta su experiencia.

¿Cómo responder a la pregunta cambiada por dev?

Esta es una pregunta muy común no solo con DEV, sino que se aplica a todos los equipos de TI y negocios.

Qué cambió ? ==> puede ser respondido por hechos y cifras.

Los hechos se refieren por ejemplo

• aumentar la cantidad de usuarios que acceden a la base de datos?
• ¿Algún cambio en el parámetro de configuración del servidor?
• Mantenimiento de la base de datos: ¿actualizar estadísticas, reorganizar / reconstruir índices que no se realizan? ¡Debido a esto, los planes se están generando incorrectamente!
• La cantidad de datos ha aumentado?
• Se realizaron cambios en el lado de la red, se parchó el SO y / o se implementó un nuevo service pack o CU para el servidor sql, ¿ sin hacer una prueba de regresión completa del ciclo comercial de su aplicación ?
• ¿La SAN subyacente se ha vuelto repentinamente lenta?

Las cifras se pueden derivar si tiene datos para mostrar. Por ejemplo :

• La línea de base de su servidor es crítica durante esta situación. Esto aliviará el juego de la culpa ya que puedes respaldar los hechos con cifras sólidas.
• Comience a recopilar datos utilizando DMV o sp_whoisactive para una tabla, de modo que los datos se conserven después de reiniciar el servidor sql.

(tiene que entrenar en función de su entorno y necesidades, de la frecuencia con la que recopilará los datos / qué datos recopilará y cuánto será el período de retención) o (puede invertir en un software de terceros como sqlsentry o el administrador de diagnóstico de idera que hará el trabajo anterior para usted) .

Bueno, podrías estar obteniendo un plan diferente porque:

• el plan podría haber sido desalojado de la memoria caché debido a:
  • un reinicio del servicio
  • borrado manual de la caché del plan
  • un reinicio del servicio o conmutación por error
  • un cambio inadvertido, por ejemplo, ciertos sp_configurecambios pueden vaciar el caché
  • algún cambio en los objetos subyacentes, índices, estadísticas u otras dependencias desencadenó una recompilación
• podría estar obteniendo un plan diferente al de los otros usuarios o invocaciones anteriores porque:
  • el texto de la consulta puede no ser idéntico (esto incluye mayúsculas y minúsculas , no importa columnas diferentes, criterios de combinación, filtros, etc.)
  • la consulta podría ser ejecutada por diferentes usuarios con diferentes opciones de configuración (o diferentes esquemas predeterminados, si algún objeto en el plan no tiene un nombre completo, incluido el esquema )
• la consulta y el plan podrían ser los mismos, pero podría obtener un rendimiento diferente porque:
  • el plan se almacenó en caché utilizando diferentes parámetros, y ese plan no es óptimo para el conjunto actual de parámetros (esto se conoce comúnmente como "análisis de parámetros")
  • la cantidad de datos basada en los parámetros o simplemente debido al cambio de datos mientras tanto es significativamente diferente
  • los datos han cambiado lo suficiente como para alterar la forma más eficiente de acceder a los datos, pero no lo suficiente como para desencadenar actualizaciones estadísticas o recompilaciones (busque problemas clave ascendentes y algoritmos de estadísticas automáticas)
  • los datos se han desalojado del grupo de búferes y ahora deben leerse desde el disco
  • Existe una mayor concurrencia, bloqueo u otras tensiones en los recursos necesarios para satisfacer la consulta

Veo muchos de estos con más detalle aquí:

• Planes múltiples para una consulta "idéntica"

Si estos se ejecutan en diferentes entornos, entonces tengo toda una serie de cosas para verificar aquí:

• Planes diferentes para servidores "idénticos"

Además, es importante tener en cuenta que crear un índice o cambiar la consulta podría no ser la razón directa por la cual una consulta de repente funciona mejor, a veces es solo porque esos cambios realmente generaron un nuevo plan y / o invalidaron el que ya existía. .

Como de costumbre, Aaron Bertrand y Kin proporcionaron excelentes respuestas. Sin embargo, ambas respuestas contienen un hilo común. Si analiza cualquiera de las respuestas, verá que la razón por la cual XYZ no funciona como funcionó ayer no se debe a algo que hicieron ellos / ellos / la persona X. La razón por la cual las cosas cambiaron es porque la base de datos decidió hacer las cosas de manera diferente debido a razones XYZ.

Una base de datos es una entidad viviente que respira . Las bases de datos tomarán decisiones y cambiarán de opinión debido a una combinación de supuestos, estadísticas y otras herramientas heurísticas. Esto es dramáticamente diferente a la mayoría de la programación de la capa de aplicación (el aprendizaje automático es una excepción notable).

_{Voy a usar algunas referencias militares porque no puedo pensar en algo mejor en este momento. Se apreciaría una metáfora más general (sin juego de palabras).}

En la mayoría de las aplicaciones, el programador actúa como un instructor de perforación. Le dicen a la computadora exactamente qué hacer, en qué orden y, a veces, durante cuánto tiempo. Programar una base de datos es más como actuar como un oficial al mando. Le dice lo que quiere que haga a un alto nivel y le ofrece orientación cuando sea necesario. La base de datos se encarga de descubrir la mejor manera de ejecutar el plan en función de la inteligencia actual, como los oficiales subalternos y suboficiales.

Al hacer esta distinción clara en las mentes de los otros programadores, con suerte comenzarán a ver que no tienes poderes de dictadura como ellos tienen sobre su entorno. Está guiando la base de datos a la solución y ocasionalmente la base de datos se desvía por buenas o malas razones. Recuérdeles que al final no importa por qué * la base de datos se desvió, sino qué podemos hacer para recuperarla.

_{* Reconozco que "por qué" es muy valioso para la prevención, el aprendizaje, etc. en el futuro, pero parece que el OP se enfrenta a la resistencia de personas que no están tratando de aprender o ayudar con el problema.}