Humor

Un día en la vida de un DBA: Consultas, Caos y Dudosa Capacidad Técnica (Artículo de HUMOR)

Como DBA de SQL Server, mi día es una mezcla de comedia, drama y suspense, con algunos toques de terror. Aquí os presento cómo transcurrió un día cualquiera en mi vida, repleto de personajes inolvidables, cada uno con su consulta particular y su manera única de contribuir al colapso del servidor. Abrid vuestra mente… y vuestro SQL Server Management Studio.

8:00 AM: Paco “El SELECTor” y la Consulta Infinita

Nada más abrir mi sesión, mi querido compañero Paco, el SELECTor (porque selecciona todo sin filtro), aparece con su ya clásica sonrisa de inocencia. Paco es de los que todavía piensan que SQL Server es algo mágico y que “si no devuelves todas las columnas, seguro te dejas algo importante”.

Me encuentro con su obra maestra, digna de un Anti Premio a la peor consulta del año:

-“¡No entiendo por qué tarda tanto! ¡Si son solo los pedidos del año!”, exclama Paco, mientras agita su taza de café de “No es magia, soy desarrollador”.

Le explico con calma (una vez más) que cada vez que usa SELECT * en producción muere un gatito y que filtrar con funciones como YEAR() no permite que SQL Server use los índices. Con cara de «eso me lo enseñaron en un curso de YouTube», Paco se compromete a mejorar. Mientras tanto, optimizo la consulta:

Optimización: índice + eliminación de funciones

Resultado: Consulta en segundos. Paco asiente con admiración y anota algo en su libreta, probablemente «Pedir más memoria al DBA».

10:00 AM: Toñi “SinWHERE” y el Script Nuclear

Toñi es de esas desarrolladoras que tienen una relación tóxica con el entorno de producción. Tiene un lema: «Si funciona en mi local, funciona en producción». Y hoy, decidió demostrarlo.

Recibo una alerta: «La tabla Employee está vacía». Con el corazón encogido, abro los logs y ahí está el script más temido:

-“¡Uy! Me olvidé el WHERE. Pero no pasa nada, para eso están los backups, ¿no?”, dice Toñi con una sonrisa que desearía no ver nunca más.

Intento explicarle que “no pasa nada” es lo que dice un soldado cuando pisa una mina. Mientras recupero los datos, aplico medidas preventivas:

ATPC. No me fío ni un pelo.

1:00 PM: Manolo “El Shuffle” y el Caos Aleatorio

Manolo, alias “El Shuffle”, es el encargado de los informes y estadísticas. Es fan del “orden aleatorio” porque, según él, “las listas aburren a la gente”. Y claro, cuando quiere algo “aleatorio”, lanza lo siguiente:

-“Es que así queda guay, aleatorio, como mi lista de Spotify”, argumenta Manolo mientras hace girar su silla de oficina cual plato de mesa de mezclas de DJ.

Le explico (otra vez) que NEWID() obliga a SQL Server a generar GUIDs para todas las filas de la tabla y luego ordenarlos. Todas estas operaciones se hacen en memoria y con su maravillosa tabla de 200 millones de registros eso no es una buena idea. Así que le doy una alternativa más eficiente para obtener una muestra aleatoria:

¡Magia! “¿Ves? Es que tú lo complicas todo”, dice con su típica confianza de «yo lo leí en Stack Overflow».

4:00 PM: Javi “El SinÍndices” y la Carga Masiva

Cuando el servidor ya está medio recuperado, aparece Javi, “El SinÍndices”. Su teoría es que los índices ralentizan la carga de datos (y no le falta razón… a medias). Así que en su infinita sabiduría, ha borrado todos los índices de la tabla Invoices para cargar más rápido.

“¡La carga ha ido como un rayo!”, dice orgulloso.

– “¿Y las consultas que dependen de esa tabla? ¿Les has preguntado cómo van?”, respondo yo con una mirada de fuego.

Para evitar futuros desastres, le tatuo en el antebrazo que si vuelve a borrar índices no respetaré los derechos humanos y recurriré a la tortura en nuestra próxima interacción.

6:00 PM: El Jefe “Sin Backup no Hay Paraíso”

Justo cuando creo que puedo irme, mi jefe aparece con cara de preocupación:

– “¿Tenemos backup de todo esto, verdad?”.

Le muestro mi carpeta de backups, replicados hasta en la luna si es necesario. Porque si algo tengo claro después de años de sufrimiento es que sin backup, no hay DBA que sobreviva.

Conclusión: La vida del DBA es un Reality Show

Un día más salvando a Paco, Toñi, Manolo y Javi de ellos mismos. Un día más optimizando consultas, corrigiendo scripts desastrosos y asegurando que el servidor no arda en llamas. La próxima vez que escuches «¿pero qué hace un DBA?», recuérdales que sin nosotros, el caos reinaría en el mundo de los datos.

Y si alguno de estos personajes te suena… ¡ánimo! Seguro que en tu día a día también te encuentras con alguno de ellos.

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.

Publicado por Roberto Carrancio en Otros, 1 comentario

Cómo ser DBA y no morir en el intento (Artículo de HUMOR)

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.

Publicado por Roberto Carrancio en Otros, 0 comentarios

Las preguntas más absurdas que un DBA puede escuchar en una entrevista de RRHH (Artículo de HUMOR)

Quienes trabajamos como administradores de bases de datos (DBA) hemos pasado por entrevistas laborales que podrían calificarse como una experiencia de alto riesgo. Más que evaluar nuestras competencias técnicas, a menudo parecen un test de paciencia. Y no, no estamos hablando de preguntas como “¿Cuáles son las diferencias entre un índice clustered y non-clustered?”. Nos referimos a joyas del absurdo que solo un departamento de RRHH puede lanzar con total tranquilidad. Antes de seguir, un pequeño disclaimer, todo lo que vas a leer a continuación es pura ficción y una exageración, lo que no quiere decir que, en ocasiones, la realidad supere la ficción.

El examen de «personalidad» camuflado de absurdo

Algunos reclutadores no entienden del todo qué hace un DBA, no les culpo, no es su trabajo. El problema viene cuando deciden que, ya que no tienen ni idea de lo que hablamos lo mejor que pueden hacer es recurrir a particulares test de personalidad. Y no, no estoy hablando del test de MBTI, me refiero a preguntas mucho más absurdas que sacan lo peor (o mejor) de nosotros

Si fueras una tabla de SQL, ¿qué nombre tendrías y por qué?

Es aquí cuando miras al entrevistador con cara de ¿en serio? mientras piensas: «Esta pregunta viene con un CROSS JOIN de desconcierto y absurdidad». Pero, como eres un profesional, te pones creativo:

«Sería dbo.Entrevista_RRHH porque, al igual que en esta sala, hay muchos campos innecesarios que ralentizan el proceso». Y si estás inspirado: «Y, por supuesto, con una clave primaria, porque si algo me define es que siempre mantengo la integridad referencial».

El entrevistador sonríe y toma notas. No entiende ni una palabra, pero le parece bien.

¿Te consideras más un trigger o un procedimiento almacenado?

Aquí la cosa se complica porque sabes que cualquier respuesta va a derivar en algún análisis de personalidad de esos que llenan PowerPoints con diagramas de colores. Piensas en algo como: «Un trigger, porque reacciono rápido cuando algo va mal y siempre ejecuto la acción adecuada. Aunque, a diferencia de los triggers mal diseñados, no me cargo el rendimiento del sistema». Si ese día te has levantado con el pie izquierdo igual lo que te nace es algo mucho más irónico, como: «Un procedimiento almacenado, claro, porque en mi trabajo, igual que en los procesos bien optimizados, todo está planificado y nadie tiene que revisar los logs de errores inesperados.» 

Pero, lo piensas dos veces, si respondes «un trigger», parece que saltas a la mínima. Si dices «un procedimiento almacenado», suena a que necesitas mucha preparación para hacer algo. Así que terminas diciendo que un ROLLBACK y a ver si le cortocircuita el cerebro y sobrevivimos unos minutos más hasta llegar a la siguiente pregunta.

¿Qué tipo de relación tienes con tus compañeros, un INNER JOIN o un LEFT JOIN?

Esta pregunta suena tan profunda como absurda. Te planteas si te has metido sin querer en una sesión de terapia grupal en lugar de una entrevista técnica. Respiras hondo y sueltas:

«Claramente un INNER JOIN, porque con mis compañeros siempre buscamos resultados eficientes y no nos gustan las inconsistencias. Si alguien no aporta, mejor quedarse con un NULL».

Aquí es cuando miras la cara del entrevistador y ves que has acertado, menos mal que no has dicho eso más sarcástico que realmente piensas: «Mis compañeros parecen LEFT JOIN con registros fantasma que solo ocupan espacio y no aportan nada al output.»

¿Cómo gestionarías tu vida personal si fuera una base de datos relacional?

Una de esas preguntas que te dejan boquiabierto y te hacen preguntarte si no habrá cámaras ocultas en la sala. Intentas mantener la compostura: «Primero haría una buena normalización, porque prefiero la eficiencia y no me gusta cargar con datos redundantes. Luego implementaría backups incrementales para cuando las cosas se complican y, por supuesto, borraría las tablas temporales que no aportan nada a mi día a día».

Si el entrevistador parece satisfecho, rematas con una sonrisa: «Y siempre con un buen índice de prioridades, porque la vida es como una query: si no la optimizas, acaba siendo lenta y costosa».

El desafío de lo no técnico

En ocasiones, una vez pasado el dudoso test de personalidad, llegamos a otra fase donde las preguntas parecen sacadas de un test de Rorschach. Para un DBA, acostumbrado a la lógica y la estructura, escuchar estas cuestiones es cómo ejecutar un delete sin WHERE. Me refiero a cosas como estas.

¿Qué harías si te encuentras con una base de datos rebelde?

Aquí intentas contener la risa y respondes algo técnico para sonar serio. Pero, ¿realmente ha dicho una base de datos rebelde? No sabía que la entrevista de trabajo era para trabajar como DBA Jedi en la Estrella de la Muerte.

Si la base de datos falla, ¿te estresarías?

Vuelve al ataque. Tus intentos de evitar la pregunta anterior han sido infructuosos y ahora el entrevistador golpea de nuevo con esta pregunta que parece un ataque directo. Te apetece contestar algo del tipo: “No, en absoluto, me pondría a bailar una jota mientras los usuarios gritan por un downtime. ¿Qué creen que hacemos?” 

Porque, no nos engañemos, cualquier DBA que se respete ha vivido la experiencia traumática de una base de datos caída en producción a las 3 AM. Pero te detienes un instante, meditas y respondes con toda la ironía del mundo:

«¿Estresarme? ¡Para nada! Es una situación maravillosa para practicar mis habilidades de meditación transcendental mientras 300 usuarios esperan que resuelva el desastre».

Si te piden algo más serio, matizas: «Más que estresarme, actuaría. Es como un incendio, no te sientas a filosofar. Buscas el extintor, localizas el backup y vuelves a poner todo en orden.»

Clásicos «RRHH-style» que siempre vuelven

Y no pueden faltar las típicas preguntas genéricas vacías que ningún técnico puede soportar. Ya sabéis a las que me refiero, vamos a verlas.

¿Dónde te ves en 5 años?

Respondes sin pensar. Después de pasar por esta entrevista, cansado y con toda la ilusión por el puesto de trabajo ya perdida no te quedan fuerzas para más. Obviamente es una respuesta con un toque ácido pero que esconde un deseo de que el mundo se convierta en un lugar mejor:

«Me veo liderando un equipo de bases de datos en una empresa que no haga preguntas de terapia psicológica durante las entrevistas. Y, con suerte, trabajando en entornos que no tengan bases de datos heredadas sin documentación. Si no se puede, buscaré la manera de hacer tuning a tu proceso de selección para eliminar estas preguntas inútiles».

Ahora en serio, en el mundo en el que nos movemos todo cambia muy deprisa. Seguramente, tú que me estás leyendo, estás trabajando ahora con cosas que no existían hace 5 años. ¿Cómo quieren que respondamos a esa pregunta? Lo único que tengo claro es que, dentro de 5 años, el ticket ese que tengo pendiente esperando la respuesta del usuario va a seguir ahí, en el mismo estado.

¿Qué animal te representa mejor en tu trabajo?

Esto sí que es un clásico del manual de RRHH. La tentación de decir «un koala dormido porque mi sistema funciona sin incidentes» es fuerte, pero decides optar por algo más elegante: «Un búho, porque soy nocturno, vigilo todo con precisión y, cuando llega el desastre, actúo con rapidez y sin ruido innecesario. Además, no molesto mientras los demás duermen.”

Conclusión

Las entrevistas con RRHH son una prueba en sí mismas. Si sobrevives a preguntas como “¿qué tipo de JOIN eres?”, te puedes considerar un candidato resistente, optimizado y listo para cualquier desastre en producción. Porque, al final del día, un DBA siempre tiene claro cómo responder a las consultas más difíciles, incluso si vienen de un reclutador armado con un SELECT de preguntas innecesarias e ineficientes.

Si algo nos enseñan las entrevistas con RRHH es a dominar el arte de la diplomacia. Al final, todo se reduce a un simple hecho: por muy absurdo que suene el proceso, seguimos siendo los guardianes de los datos. Así que, estimado entrevistador, la próxima vez, menos triggers emocionales y más consultas bien indexadas.

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.

Publicado por Roberto Carrancio en Otros, 0 comentarios

El día que el servidor dijo «Basta»: Confesiones de un DBA (Artículo de HUMOR)

Todo DBA tiene su límite. Esa delgada línea entre la paciencia infinita y querer estampar el teclado contra la pared. El día del que os hablo fue uno de esos. Un día que empezó tranquilo y terminó en una lucha encarnizada entre el servidor, el Optimizer y mi cordura.

Os cuento lo que ocurrió: un desplome monumental de rendimiento, misterios sin resolver y consultas que me hicieron replantear mi carrera profesional.

9:00 AM: La CPU al 100% y el misterio del índice fantasma

Llego a la oficina con mi café recién hecho y veo las alertas parpadeando como luces de Navidad: “CPU al 100%. El servidor está llorando”.

Abro el Activity Monitor y ahí está. Una consulta devorando recursos como si no hubiera mañana. La autora de semejante hazaña es la tabla Sales.OrderDetail, que por algún motivo ha pasado de ser una tabla tranquila a Satán hecho tabla.

La consulta en cuestión es:

Aparentemente inocente, ¿verdad? Pues no. Esta tabla tiene 50 millones de registros y sin ningún índice útil. Le pregunto al equipo:

– “¿Dónde están los índices?

– “Los quitamos ayer porque ralentizaban las inserciones”, responden orgullosos.

Respirando hondo, les explico que quitar índices no soluciona los problemas de rendimiento. Es como quitar los frenos del coche para ir más rápido: técnicamente es cierto, pero no saldrá bien.

Solución: Creamos un índice adecuado:

Ejecuto la consulta de nuevo y, ¡milagro! La CPU se relaja. El servidor me guiña un ojo en señal de agradecimiento.

11:00 AM: La «Optimización» del Query Planner

Todo iba bien hasta que mi compañero Pepe —que jura que el Query Optimizer es inteligente— decidió lanzar su joyita del día.

– “He usado un HINT para asegurarme de que use el índice correcto”, dice, mientras me enseña esta aberración:

Sí, habéis leído bien: INDEX(0). El equivalente SQL a decirle al Optimizer: «Da igual que lo sepas hacer bien, quiero que me compliques la vida». 

– “Pepe, eso no optimiza nada. Has forzado al Optimizer a usar una estrategia peor”.

Pepe, con cara de no entender nada, me pide una explicación. Así que se la doy:

El Optimizer no es un enemigo, es un colega que necesita que le demos buenos datos. WITH (INDEX(0)) indica al motor de base de datos que no tiene que usar ningún índice. Si la tabla es un HEAP hará un table scan aunque haya índices nonclustered. Si la tabla tiene un cluster jamás hará un seek y siempre hará un scan. Si lo que queremos es que use el índice clustered deberíamos usar WITH (INDEX(1)) que dejará que el motor use lo más eficiente, un seek o un scan, depende del caso. Pero rara vez vas a tener que usarlo, si tus estadísticas están actualizadas y tus índices bien creados, SQL Server tomará la mejor decisión posible.

Actualizo las estadísticas:

Le muestro cómo forzar buenos resultados sin jugar a ciegas con los HINTs:

Resultado: La consulta se ejecuta en 0.2 segundos sin INDEX(0) ni tonterías. Pepe asiente. Creo que hoy hemos ganado una pequeña batalla.

2:00 PM: El Desastre del «Top 1» sin orden

Después de comer, el desarrollador novato —al que llamaremos Juanito— me lanza una consulta de soporte urgente:

– “Necesito el último pedido. Lo he arreglado con un TOP 1”.

Cuando veo la consulta, siento una punzada en el estómago:

– “¿Y dónde está el ORDER BY?” —pregunto yo, temblando.

– “¿Hace falta?”, responde Juanito, con una inocencia que me desarma.

Le explico que TOP 1 sin ORDER BY no garantiza el «último» ni el «primero». Solo devuelve el primero que pille, que puede ser cualquier registro según el orden físico de la tabla.

Solución:

– “¿Y si quiero asegurarme de que sea rápido?”, me pregunta.

– “Pon un índice en OrderDate. Tu servidor te lo agradecerá”.

La consulta ahora funciona como debe. Juanito toma notas en su libreta titulada “SQL para Torpes”.

5:00 PM: El plan de backup olvidado

Pensaba que el día había terminado cuando, de repente, entra en mi despacho el jefe:

-“¿Hiciste un backup esta mañana? Necesitamos restaurar la base de datos de ventas de ayer”.

Aquí el humor negro se hace real. Porque claro, en esta oficina, el backup se convierte en un problema solo cuando hace falta. Le miro fijamente:

– “¿Sabes qué es un backup, jefe?”.

Silencio incómodo. Por suerte, en esta ocasión sí tenemos backup diferencial. Aprovecho para darle una lección. Sin backups no hay paraíso. El desastre es cuestión de tiempo.

Ejecutamos la restauración:

El jefe respira aliviado. Yo termino el día con la satisfacción de que los backups me salvaron el pellejo.

Conclusión: El servidor puede fallar, yo no

La vida de un DBA está llena de desafíos. Desde índices borrados hasta HINTs absurdos y consultas sin ORDER BY. Pero si algo aprendemos con el tiempo es que el desastre no es opcional; la preparación sí lo es.

Cierro mi sesión, guardo los logs y me despido del servidor, que hoy ha sobrevivido gracias a mí. Y mañana… mañana será otro día lleno de misterios.

Como dice el viejo refrán de DBA: «No hay problema en SQL Server que no pueda arreglarse con índices, backups y un buen café«.

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.

Publicado por Roberto Carrancio en Otros, 0 comentarios