best_practices: buenas prácticas para el dba
DESCRIPTION
En esta sesión vamos a revisar algunas de las buenas prácticas que durante nuestro día a día encontramos que no se aplican de forma adecuada. Aunque en nuestro día a día seamos DBAs eficientes es importante que tengamos en cuenta aquellas buenas prácticas que puedan ayudarnos a mejorar nuestros procesos, consiguiendo así minimizar errores y aumentar la disponibilidad de nuestro sistema.TRANSCRIPT
BEST PRACTICES: Buenas prácticas para el DBA
RUBÉN GARRIGÓS
REL-302
Mentor –Área Motor Relacional
MCP – MCAD – MCSD – MCTS – MCT - MCITP
α 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/