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.​

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

3. Buenas prácticas

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

17. Corrupción no reparable

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/