BEST PRACTICES: Buenas prácticas para el DBA

RUBÉN GARRIGÓS

REL-302

Mentor –Área Motor Relacional

MCP – MCAD – MCSD – MCTS – MCT - MCITP

rgarrigos@solidq.com

α Buenas prácticas β Documentación

β Monitorización

β Esperas y latencias

β Backups e integridad

β Rolling upgrades

Objetivos de la sesión

Buenas prácticas

α Como profesionales debemos buscar conseguir la excelencia en nuestra actividad

β Mejora continua y sed de conocimiento

α Las buenas prácticas aglutinan la experiencia acumulada β Podemos introducir nuevas prácticas o mejorar las existentes

β Hay que considerarlas como una base no como dogmas de fe

α En general los departamentos de IT tienen una mala imagen dentro de las corporaciones

β Pérdida de disponibilidad

β Poca visibilidad

β Falta de alineación

β Gasto excesivo

Buenas prácticas

α Suele dejarse para último lugar

α En muchas ocasiones la documentación es inexistente o está desactualizada (que es peor a veces…)

α Una buena documentación reduce el coste total β Menos errores, especialmente trabajando bajo presión

β Menos costes para formar al personal

β Más productividad, permite realizar más tareas con menos coste

β Debe formar parte de nuestro ciclo de desarrollo

α El enfoque de la documentación es importante β Concisa y no ambigua

β Orientada a procesos / modelos

β Basada en plantillas reutilizables

α Estadísticamente más del 90% de «desastres» son debidos a fallos humanos que podían haber sido evitables

Buenas prácticas Documentación

α Es habitual encontrar herramientas de terceros para la monitorización

β Herramientas nativas se quedan cortas en este aspecto

α Se tiende a infravalorar situaciones que, sin ser críticas, sí pueden indicar un problema

β Desviaciones en los tiempos de ejecución

β Oscilaciones en los tiempos de respuesta

β Aumento en el número de usuarios concurrentes

α Es importante añadir también monitorización específica de nuestro negocio

β Pedidos procesados por minuto

β Duración de procesos de importación

α Toda la información almacenada en un DW de monitorización común para nuestros servidores

β Informes consolidados

Buenas prácticas Monitorización

α Con el tiempo el rendimiento suele irse degradando β Errores de diseño/codificación

β Falta de mantenimiento

β Aumento del volumen de datos

β Nuevas funcionalidades añadidas Self-BI

β Saturación de recursos

α El análisis de tendencias nos permite tomar acciones preventivas y no reactivas

β Series temporales

β Medias móviles

β Líneas de tendencia

β Correlaciones entre métricas

α Necesitamos tener una línea base de rendimiento para tener una referencia del punto en el que estamos y donde necesitamos llegar

Buenas prácticas Tendencias

α En ocasiones las tendencias de los valores absolutos o porcentuales de las métricas no aportan mucha información por si solas

α Si hay un aumento de CPU, es importante saber si está correlacionado con un aumento en las operaciones por segundo

β Hilando más fino, deberíamos ver si el aumento se ha producido de forma global o solo en algunas operaciones

β La línea base evita que vayamos a ciegas cuando encontramos estos escenarios

α En un sistema que escale adecuadamente un aumento en las peticiones por segundo no implicará un aumento del tiempo de respuesta de la misma proporción

β Ojo con los bloqueos cuando aumenta la concurrencia stress tests

Buenas prácticas Correlación

α Forma parte de un análisis típico desde el punto de vista de rendimiento percibido

β SQL Server WAITSTAT & IOSTATS

α El usuario no percibe si la consulta ha requerido X ms de CPU o ha movido X MB/s por la red tiempo de respuesta

α Busca reducir aquellos tiempos «muertos» donde no se realiza «trabajo útil»

β Esperas de entrada/salida a disco y red

β Esperas por contención en el acceso a una tabla

α En base a nuestra experiencia β Esperas de entrada/salida

β Esperas de compilación

β Esperas de ejecución

Buenas prácticas Esperas y latencias

α Se suelen considerar como algo «normal e inevitable» β ¿Realmente estamos en valores normales?

β ¿Podemos hacer algo para mejorarlos?

α Entrada/salida de red β Informe ejecuta en 1 segundo en red local y tarda 20 en remoto

β Mejorar el ancho de banda/latencia de las comunicaciones

β Aplicar compresión ad-hoc / hardware / software

α Entrada/salida de disco β Escrituras en el log de transacciones

β Abuso de tempdb

β Memoria RAM insuficiente

β Añadir más discos / caché

Buenas prácticas Esperas de entrada/salida

α Muchos motivos diferentes β Falta/exceso de indexación

β Estadísticas incorrectas

β Parameter sniffing

β Funciones escalares

β Triggers

β Claves ajenas no confiables

β Mal uso de DISTINCT, GROUP BY, IN…

β Niveles de aislamiento excesivos

β Transacciones largas y/o muy bloqueantes

β Uso inapropiado de hints

β Cursores / Bucles en T-SQL

Buenas prácticas Esperas de ejecución

α La compilación es un proceso complejo y pesado que debemos tratar de minimizar si queremos buen rendimiento

β No es tan escalable como la ejecución

β Mucho consumo de memoria y CPU

β SET STATISTICS TIME ON

α Consultas parametrizadas / procedimientos almacenados

α Auto-parametrización β Simple

β Forzada

α Simplificación de consultas β Tener en cuenta el modelo e intentar guiar al optimizador si hints

β No olvidar que en ocasiones es más costoso compilar que ejecutar

β Abusar de vistas anidadas/profundas puede ser un problema

Buenas prácticas Esperas de compilación

α Tan importante es hacer backup como ser capaces de recuperar dicho backup

α Media sets espejados β Nos protege de un fallo añadiendo redundancia

β Disco SATA típico 1 fallo irrecuperable cada 1015 bits

β Una base de datos de 10TB 10% probabilidades

β Cinta + Cinta o Disco + Disco

α Checksum β Comprobación del checksum de página si existe

β Checksum adicional

α Compresión β Añade checksum automáticamente

β En caso de fallo, el impacto será mayor

Buenas prácticas Backups

Backups + restore + ¿checkdb?

Añadir espejado, restore sin checksum, modificaciones de página no detectadas?

α Son necesarias de forma periódica para asegurarnos que no hemos sufrido de corrupción

α El largo camino de una operación de entrada/salida β SQL Server NTFS Driver HBA Firmware HBA Firmware

Switch Fibra Firmware controladora frontend Software de la SAN Firmware controladora backend firmware del disco

α Los errores de este tipo suelen aparecer bien con el tiempo o bien en picos de muy alta utilización

β Es importante realizar pruebas de stress al hardware antes de ponerlo en producción

α La monitorización puede quedar lejos de nuestro alcance como DBAs

β Contadores de la cabina

β Contadores de los switches

Buenas prácticas Comprobaciones de integridad

α Impacto de la corrupción puede ser muy variable β Página no utilizada

β Página de índice no clustered

β Página de índice clustered / heap

β Página de tabla de sistema

β Páginas de la cabecera del fichero

β Log de transacciones

α Msdb.dbo.Suspect_pages

α Log de errores de SQL Server

α Logs de windows

Buenas prácticas Comprobaciones de integridad

Corrupción no reparable

α Se introdujeron en SQL Server 2008 β Relativamente poco utilizado

α Reduce mucho el downtime β 1 failover vs 1 instalación offline

β Cluster de N nodos 1 failover

α Sigue siendo una operación delicada β Compatibilidad de aplicaciones

β Previsión de vuelta atrás

β Es importante tener entornos de staging realistas

γ No siempre es posible simular al 100%

Buenas prácticas Rolling upgrades

α Pasos para la puesta en producción: 1. Eliminar el nodo o nodos a actualizar de la lista de posibles owners

de la instancia correspondiente. Mantener al menos 2 nodos si es posible.

2. El siguiente paso será aplicar el upgrade al nodo o nodos que hemos eliminado de la lista de posibles owners.

3. Añadir los nodos actualizados a la lista de posibles owners de la instancia actualizada en este proceso.

4. Realizar el failover desde el nodo activo a uno de los nodos ya actualizados y comprobar que todo funciona correctamente.

5. Eliminar los nodos no actualizados de la lista de owners de la instancia y realizar su actualización.

6. Comprobar, si es posible, que la instancia funciona correctamente en todos los nodos realizando los N-1 failovers necesarios.

Buenas prácticas Rolling upgrades

α Una vez llegados al paso 4 hemos pasado la parte más crítica del proceso

α Si todo ha ido bien, continuamos

α Si tenemos problemas β Intentar realizar un failover a uno de los nodos no actualizados

β Mantendremos los nuevos nodos excluidos de la lista de owners

α Si seguimos con problemas β Recomendamos intentar actualizar «hacia adelante» si existe alguna

versión más nueva que la que estamos instalando

β Desinstalar el CU

Buenas prácticas Rolling upgrades

α Buscar conseguir la excelencia

α Mejora continua

α Aplicar/definir buenas prácticas

α Prepararse para lo peor

α Imagen del departamento de IT

Conclusiones

Si quieres disfrutar de las mejores sesiones de

nuestros mentores de España y Latino América,

ésta es tu oportunidad.

http://summit.solidq.com/madrid/