¿Por qué el ajuste del rendimiento de SQL es tan importante para la gestión de bases de datos?
Porque puede ahorrarle mucho dinero. Ten paciencia conmigo y verás cómo.
Ajuste del rendimiento de SQL y administración de bases de datos:conectando los puntos
La mayoría de los profesionales de bases de datos dedican su tiempo a mantener las luces encendidas. Invierten la mayor parte de su esfuerzo en garantizar el tiempo de actividad vigilando recursos como la memoria, el almacenamiento y el rendimiento de la red. Esa es una gran parte de la administración de bases de datos, pero a medida que más empresas trasladan sus bases de datos a recursos en la nube casi ilimitados como AWS y Azure, otros aspectos se vuelven más importantes.
El ajuste del rendimiento de SQL es uno de esos aspectos. Una vez que las luces se mantienen encendidas de manera segura y asciende en la jerarquía de necesidades en la administración de la base de datos, lo siguiente que desea es un mejor rendimiento, y eso requiere ajustes.
Primeras preguntas que hacer cuando se ajusta el rendimiento en SQL
Tarde o temprano, muchos profesionales de bases de datos se encuentran frente a un servidor SQL que no construyeron. No hay muchas guías prácticas para esa situación. El ajuste del rendimiento de SQL es un ejercicio para profundizar, descubrir qué está mal y luego corregirlo iterativamente.
En sus primeras correcciones, es posible que ni siquiera toque las declaraciones SQL. Algunos profesionales de bases de datos comienzan en el nivel de usuario/sesión. Van a donde los usuarios no están contentos, escuchan cómo suenan sus quejas y plantean preguntas.
- ¿Qué pantallas o páginas tardan demasiado en procesarse?
- ¿La aplicación es más lenta cuando crean un nuevo ticket o abren uno existente?
- ¿Lleva mucho tiempo guardar un registro?
- ¿Cuánto tiempo es "mucho tiempo?"
Una vez que tienen esas respuestas, van a ver qué en la base de datos lo está causando.
Eso es mejor que sentarse el primer día y decidir lidiar con algo como la fragmentación, que puede no afectar a los usuarios en absoluto. El punto es comenzar con lo que les importa a los usuarios.
Piense también en el nivel de instancia/base de datos. En el mundo de Microsoft, por ejemplo, los trabajos del Agente SQL Server son un buen lugar para comenzar. Son una serie de acciones que generalmente definen una tarea administrativa que puede monitorear para ver si tiene éxito o si falla. Están destinados a ser convenientes, pero como muchas cosas en la administración de bases de datos, tienden a acumularse a medida que las personas olvidan cómo se originaron y qué hacen.
Puede encontrar varios trabajos haciendo lo mismo, como ejecutar diferentes versiones de un script de índice o, peor aún, trabajar uno contra el otro. Examine los trabajos ya configurados a la luz de dos preguntas:"¿Qué hace este trabajo?" y, lo que es más importante, "Si dejo ese trabajo, ¿pasará algo malo?"
¿Qué factores debe buscar?
Una vez que llega al nivel de SQL de ajuste de rendimiento, toma sus señales de comportamiento de varios factores. Como se describió durante nuestro pregunte a los expertos:transmisión web de la mesa redonda de rendimiento de la base de datos, puede dedicar menos tiempo a ajustar el propio SQL si encuentra e interpreta correctamente factores como estos:
- Bloqueo: Si el servidor se bloquea, es como una bomba de relojería. Supongamos que un script inicia una transacción y no la cierra; eso podría conducir a un archivo de registro que simplemente crece y crece hasta que se agota el espacio. El bloqueo es una mala noticia para el rendimiento, así que búsquelo de inmediato.
- Agentes: A propósito de los trabajos del Agente SQL Server, se sabe que los administradores envuelven sin darse cuenta tareas que perjudican el rendimiento en trabajos. Pueden ejecutar transacciones o reconstruir índices en un trabajo, o reducir la base de datos en una transacción. En un caso como ese, considere deshabilitar el agente temporalmente para cerrar todos los trabajos asociados. Es una técnica agresiva, pero si mejora el rendimiento, sabrá por qué.
- Estadísticas de espera: Pregúntese:"¿Qué está esperando el servidor en este momento?" Las métricas como la esperanza de vida de la página y la longitud de la cola del disco tienen algunas respuestas, pero solo ofrecen una visión limitada. Las estadísticas de espera le muestran todo a través de la lente de los tipos de espera y las categorías de espera, lo que le permite concentrarse en los cinco o más eventos de espera que consumen la mayor parte del tiempo. sp_BlitzFirst de Brent Ozar es un procedimiento almacenado confiable para descubrir qué están esperando sus consultas de SQL Server en este momento. Luego, cuando desee estudiar patrones a largo plazo en las estadísticas de espera de su servidor, busque una herramienta de supervisión del rendimiento.
- Actividad del administrador: Esto también se conoce como "error del piloto", porque algunos problemas de rendimiento surgen debido a lo que usted mismo está haciendo. Suponga que está ejecutando tanto el Monitor de actividad de SQL Server como el Analizador de SQL Server al mismo tiempo, tratando de aprender el Almacén de consultas. No puedes dejar atrás el efecto del observador; cuando realiza un seguimiento de todo eso, solo está pidiendo que la base de datos se ralentice.
- Índices: Para algo que se supone que es beneficioso, los índices seguramente pueden causarle dolor en el cuello. De hecho, se merecen más que una sola bala. Sigue leyendo.
El ajuste del rendimiento de SQL significa analizar detenidamente los índices
En gran parte, el ajuste del rendimiento de SQL se reduce al ajuste del índice. Afortunadamente, si domina eso para la administración de bases de datos locales, sus habilidades se pueden transferir fácilmente a la administración de bases de datos en la nube.
El ajuste de índices está cobrando importancia debido a la evolución de la variedad de índices:agrupados, no agrupados, únicos, filtrados, de almacén de columnas, hash, optimizados para memoria no agrupados, XML, espaciales y de texto completo, por nombrar algunos. Pero una cosa que nunca ha cambiado es la primera columna del índice, que impulsa las decisiones de índice tomadas por el motor de la base de datos.
Muchos proveedores venden e implementan aplicaciones con una gran cantidad de índices bien intencionados que nunca se utilizan o, peor aún, obstaculizan el rendimiento. Si examina los scripts de índice no utilizados o los scripts de consumo de índice en algunos productos de software, encontrará un exceso de índices en una clave externa. Si el producto usa, digamos, 20 claves foráneas, los proveedores pueden enviar hasta 20 índices, más diez índices de una sola columna, más otros diez índices en un índice agrupado único, y así sucesivamente.
Siempre que tenga la opción, la mejor manera de abordar la arquitectura de la base de datos es comenzar con un índice agrupado que crea que representará mejor la tabla. Luego, deje que el sistema se ejecute solo por un tiempo. Si necesita más índices, créelos. Agregar índices es un ejercicio para intercambiar un mejor rendimiento aquí con problemas como llenar el espacio del disco y bloquearse allí. Se vuelve difícil ver cómo cada índice adicional afecta el sistema en general.
De hecho, considere eliminar los índices, de la misma manera que una persona con alergias eliminaría los grupos de alimentos, para ver cómo cambia el rendimiento. Intente colocar todos los índices en su instancia de desarrollo y vea cuáles afectan sus cinco consultas principales.
Ajuste del rendimiento en SQL Server:herramientas que vienen con él
Tenga en cuenta que no está solo en este esfuerzo. SQL Server incluye funciones diseñadas para mejorar el rendimiento.
Las guías del plan le permiten cambiar la forma en que SQL Server ejecuta una consulta determinada y, aunque no es un ajuste de rendimiento de SQL puro, sí afecta el rendimiento. Muchas aplicaciones contienen consultas SQL escritas por un proveedor externo, e incluso si esas consultas provocan un rendimiento deficiente, es comprensible que algunos profesionales de bases de datos se muestren reacios a cambiarlas. Con las guías de planes, puede adjuntar una sugerencia de consulta o un plan fijo a la consulta e influir en cómo se ejecuta.
Sin embargo, la desventaja de las guías de planes es que, aunque no cambian con el tiempo, el entorno que las rodea sí lo hace. Al igual que una hoja de ruta impresa, pueden funcionar bien a corto plazo y volverse obsoletos en poco tiempo, por lo que si va a confiar en ellos, será mejor que los vuelva a visitar de vez en cuando.
Relacionado con las guías de planes está Query Store, una característica de SQL Server que lo ayuda a identificar y ajustar las consultas que consumen la mayoría de los recursos en su sistema. Query Store no está habilitado de forma predeterminada para las nuevas bases de datos de SQL Server y Azure Synapse Analytics (SQL DW). Pero está habilitado de forma predeterminada en las nuevas bases de datos SQL de Azure.
En general, no es difícil habilitar Query Store, pero no todos los SQL Server lo necesitan desde el principio. Algunos administradores no conocen el Almacén de consultas y otros lo conocen, pero aún no se han tomado el tiempo de explorarlo adecuadamente; es mejor dejarlo deshabilitado. Más tarde, cuando entiendan cómo funciona el Almacén de consultas, podrán usarlo para encontrar diferencias de rendimiento causadas por cambios en el plan de consultas.
Finalmente, el Asesor de ajuste del motor de base de datos analiza las cargas de trabajo y recomienda índices o estrategias de partición para mejorar el rendimiento de las consultas. Ejecutar Tuning Advisor en su base de datos es una buena idea; simplemente no lo ejecutes demasiado pronto. Asegúrese de que su base de datos contenga suficientes datos para que las recomendaciones del índice sean válidas. Cuando crea su aplicación por primera vez, es posible que solo tenga mil filas en cada tabla. Las recomendaciones de Tuning Advisor son más útiles una vez que la base de datos ha crecido.
Muéstrame el dinero
Como mencioné al principio, el ajuste del rendimiento de SQL es importante para la administración de la base de datos porque puede ahorrarle dinero. ¿Cómo?
Especialmente en la nube, donde el escalado con tarjeta de crédito es popular, los equipos de TI están descubriendo lo caro que puede ser realmente el almacenamiento mensual. Además, están comenzando a comprender que ejecutar consultas mal escritas y permitir que AWS y Azure administren sus índices aumenta sus costos de computación en la nube. Las consultas lentas y los índices incorrectos le cuestan dinero.
El ajuste del rendimiento de SQL se trata de hacer todas esas cosas bien. De esa forma, ya sea que permanezca en el mundo de los gastos operativos locales o migre al mundo de gastos de capital de la nube, mantendrá el control sobre sus gastos.
