BEST_PRACTICES: Buenas prácticas para el DBA
- 1. REL-302 BEST PRACTICES: Buenas prácticas para el DBA RUBÉN GARRIGÓS Mentor –Área Motor Relacional MCP – MCAD – MCSD – MCTS – MCT - MCITP rgarrigos@solidq.com
- 2. Objetivos de la sesión α Buenas prácticas β Documentación β Monitorización β Esperas y latencias β Backups e integridad β Rolling upgrades
- 4. 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
- 5. Buenas prácticas Documentación α 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
- 6. Buenas prácticas Monitorizació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
- 7. Buenas prácticas Tendencias α 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
- 8. Buenas prácticas Correlación α 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
- 9. Buenas prácticas Esperas y latencias α 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
- 10. Buenas prácticas Esperas de entrada/salida α 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é
- 11. Buenas prácticas Esperas de ejecución α 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
- 12. Buenas prácticas Esperas de compilació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
- 13. Buenas prácticas Backups α 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
- 14. Backups + restore + ¿checkdb? Añadir espejado, restore sin checksum, modificaciones de página no detectadas?
- 15. Buenas prácticas Comprobaciones de integridad α 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
- 16. 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
- 18. Buenas prácticas Rolling upgrades α 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%
- 19. 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.
- 20. 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
- 21. Conclusiones α Buscar conseguir la excelencia α Mejora continua α Aplicar/definir buenas prácticas α Prepararse para lo peor α Imagen del departamento de IT
- 22. 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/