Trabajar de DBA de SQL Server es un oficio lleno de misterio, expectativas y, por qué no decirlo, frustraciones. Para empezar, nadie fuera del departamento técnico sabe realmente qué hacemos. La frase «oye, ¿y eso no lo hace Excel?» ya la hemos oído más veces que el «hola» de nuestra madre. Y es que la vida del DBA no es fácil. Somos los héroes olvidados del backend, los guardianes de las consultas bien escritas, los que nos mantenemos despiertos mientras el servidor dice «timeout expired».
El Ritual del SELECT TOP 1
El primer mandamiento del DBA es: «No harás un SELECT * sobre producción». ¿Lo hemos hecho? Más veces de las que admitiremos públicamente. Nos han pillado… Una vez. Desde entonces, siempre usamos el sagrado TOP 1 como si fuera un amuleto de buena suerte.
Y claro, cuando el jefe nos pregunta si la consulta es rápida, respondemos con la calma del que sabe que su CTE tiene 15 niveles de recursión: «Depende de cuántas JOINS a tablas tenga».
Mi job de mantenimiento es tu pesadilla
Hay dos tipos de personas en el mundo: las que confían ciegamente en sus backups y las que aún no han sufrido una catástrofe. Un DBA vive cada día en ese delgado filo entre la tranquilidad y el infarto. Si CHECKDB devuelve errores, la presión sanguínea sube más rápido que un autoincremental en una tabla de log. Y, por supuesto, siempre está el compañero de «¿para qué necesitamos índices? El SQL Server ya lo resuelve solo».
Amigo, si piensas eso, espero que te guste el café frío y las noches de insomnio porque tú y los deadlocks vais a ser mejores amigos.
El cliente que cambia las reglas del juego
Todos hemos tenido ese momento glorioso cuando un desarrollador dice: «es que necesitaba agregar una columna con un VARCHAR(MAX) para meter más datos«. Claro, porque meter más datos no tiene ningún impacto en el rendimiento… spoiler alert: sí lo tiene. El resultado suele ser que la tabla pasa de «normalita» a «más ancha que la autopista de circunvalación».
Y ahí estamos nosotros, intentando convencerles de que VARCHAR(100) ya era suficiente. Pero no, necesitamos ser «future-proof». Lo único proof aquí es el dolor de cabeza que nos deja el nuevo plan de ejecución.
El Optimizer: Nuestro juez implacable
La vida de un DBA también gira en torno a una relación tóxica: nosotros y el Optimizer. Esa entidad invisible que, por algún motivo, decide que el seek es aburrido y prefiere hacer un table scan como si estuviera buscando las llaves del coche en un descampado. ¿La causa? Quizás fue el parameter sniffing, la luna llena o simplemente un lunes.
Cuando el Execution Plan se vuelve contra nosotros, tenemos dos opciones: optimizar o sacar la carta prohibida del HINT. Porque, seamos sinceros, a veces un OPTION (RECOMPILE) nos salva más que un paracetamol.
El usuario de «Es solo una consulta»
Si trabajas de DBA, habrás oído la temida frase: «es solo una consulta rápida, ¿puedo lanzarla en producción?«. «Solo una consulta rápida» significa que va a tardar 45 minutos, tirar el servidor y llevarse puestos otros procesos en el camino. No falla.
Es más, cuando el usuario aparece en nuestra bandeja de entrada con el ASAP, ya sabemos que no será ni rápido ni sencillo. El «as soon as possible» no aplica en SQL Server si hay un WHERE mal puesto y un índice invisible que clama venganza.
Conclusión: Ser DBA es un oficio heroico
Al final del día, seguimos aquí. Porque aunque SQL Server sea un pequeño tirano, nos encanta domarlo. Amamos ver cómo un plan de ejecución mejora, cómo los backups funcionan cuando los necesitamos y cómo ese usuario que decía que «la base de datos está lenta» acaba reconociendo que el problema estaba en su código.
La próxima vez que un compañero te pregunte si el problema es del servidor, responde con un guiño: «¿Y has revisado tu código?«. Porque, amigos, el DBA no culpa… solo observa.
¡Larga vida a la optimización de consultas y que los CHECKDB estén siempre de vuestro lado!
Espero que este artículo te haya resultado divertido y ameno. Si tienes alguna duda o comentario, no dudes en contactarnos en Twitter o por mail o dejarnos un mensaje en los comentarios de aquí abajo. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir.
