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.
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.
Descripción Gráfica de un DBA Jedi enfrentándose a una Base de datos Rebelde.
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.
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:
SELECT OrderID, SUM(TotalAmount) AS Total FROM Sales.OrderDetail GROUP BY OrderID;
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.
CREATE INDEX IX_SalesOrderDetail_OrderID_TotalAmount ON Sales.OrderDetail(OrderID, TotalAmount);
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:
SELECT * FROM Sales.Customers WITH (INDEX(0)) WHERE Country = 'Spain';
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.
Le muestro cómo forzar buenos resultados sin jugar a ciegas con los HINTs:
SELECT * FROM Sales.Customers WHERE Country = 'Spain' OPTION (RECOMPILE);
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:
SELECT TOP 1 OrderID, TotalAmount FROM Sales.Orders;
– “¿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:
SELECT TOP 1 OrderID, TotalAmount FROM Sales.Orders ORDER BY OrderDate DESC;
– “¿Y si quiero asegurarme de que sea rápido?”, me pregunta.
– “Pon un índice en OrderDate. Tu servidor te lo agradecerá”.
CREATE INDEX IX_Orders_OrderDate ON Sales.Orders(OrderDate);
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:
RESTORE DATABASE SalesDB FROM DISK = 'C:\Backups\SalesDB_Full.bak' WITH REPLACE, NORECOVERY; RESTORE DATABASE SalesDB FROM DISK = 'C:\Backups\SalesDB_Differential.bak' WITH RECOVERY;
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.
Cuando hablamos de Alta Disponibilidad en SQL Server, los Grupos de Disponibilidad Always On suelen ser la opción que se menciona con mayor frecuencia. No es para menos, realmente son la solución de alta disponibilidad más completa que ofrece SQL Server. Sin embargo, existe una idea errónea generalizada: que el modo sincrónico de AlwaysOn garantiza la pérdida cero de datos. A primera vista, esta suposición puede parecer razonable, pero en este artículo explicaré por qué no es necesariamente cierto y analizaremos las implicaciones técnicas detrás de esta afirmación.
El mito de la pérdida cero de datos en Always On
El modo sincrónico en los Grupos de Disponibilidad AlwaysOn está diseñado para garantizar que los datos se escriban en todas las réplicas sincrónicas antes de confirmar una transacción. Esto implica que las transacciones no se considerarán completadas hasta que los datos se escriban tanto en la réplica principal como en las secundarias configuradas en modo sincrónico. A simple vista, parece que este comportamiento elimina cualquier posibilidad de pérdida de datos, pero hay ciertos escenarios en los que esto no es así.
Cómo funciona el Always On en modo síncrono
En el modo síncrono, el proceso sigue estos pasos:
El nodo primario recibe una transacción.
Los datos de la transacción se envían a todas las réplicas secundarias configuradas en modo sincrónico.
Las réplicas secundarias confirman que los datos han sido escritos en su registro de transacciones (log).
Solo después de recibir las confirmaciones de todas las réplicas, el nodo primario completa la transacción. Realmente esto se puede ajustar para que no sea necesario esperar a todas las replicas secundarias con la opción REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT.
Aunque este flujo parece muy robusto, hay ciertas limitaciones y condiciones que pueden comprometer la integridad de los datos.
Excepciones
Todo esto suena muy bonito, precioso diría yo. Y así funciona realmente, excepto cuando algo no va bien. Si la réplica secundaria deja de estar disponible, llámalo reinicio, parcheo o cualquiera de los múltiples otros motivos que puedan surgir dejamos de tener alta disponibilidad. Realmente está contemplado, mirad. Si leemos la documentación nos encontramos con algo que ya no suena tan bien:
«Si la réplica principal y una réplica secundaria determinada se configuran ambas para el modo de confirmación sincrónica, la réplica principal espera a que la réplica secundaria confirme que ha reforzado el registro (a menos que la réplica secundaria no pueda hacer ping a la réplica principal en el período de tiempo de espera de sesión de la principal). Si el período de tiempo de espera de sesión de la réplica principal es superado por una réplica secundaria, la replicación principal pasa temporalmente al modo de confirmación asincrónica para esa replicación secundaria. Cuando la replicación secundaria vuelva a conectarse con la replicación primaria, se reanuda el modo de confirmación sincrónica.«
En resumidas cuentas, y tiene hasta sentido, si la réplica secundaria no está disponible, por el motivo que sea, las transacciones no se detendrán y seguiremos trabajando con normalidad sobre la réplica principal sin notar nada pero no tendremos alta disponibilidad. Cuando la réplica secundaria nuevamente esté disponible empezará a replicar todas las transacciones pendientes y, un failover, antes de que termine, tendrá pérdida de datos.
Casos prácticos donde puede ocurrir pérdida de datos con Always On
Hemos nombrado ya alguno de los escenarios en los que podríamos tener una pérdida de datos con Always On, pero hay más, estos son los más comunes.
Latencia de red alta: Si la red entre las réplicas tiene una latencia significativa, puede aumentar la probabilidad de inconsistencias. En casos extremos, una réplica secundaria podría quedar rezagada y, como dice la documentación, pasar a modo asíncrono hasta que se recupere la normalidad.
Fallos simultáneos en nodos múltiples: En un entorno de clúster, si tanto el nodo primario como las réplicas sincrónicas fallan al mismo tiempo (por ejemplo, por un corte de energía en el data center), se pueden perder datos que no hayan sido escritos en disco.
Problemas en el subsistema de almacenamiento: Si el almacenamiento subyacente es compartido para todos los nodos y experimenta corrupción o retrasos significativos, incluso las transacciones confirmadas podrían estar en riesgo.
Prácticas recomendadas en Always On para mitigar riesgos
Si bien sabemos que no es teóricamente imposible la pérdida de datos, también existen una serie de medidas que, como DBAs, podemos tomar para reducir el riesgo. La primera y más eficaz es configurar múltiples réplicas síncronas. Tener más de una réplica puede reducir las probabilidades de pérdida de datos, ya que sería improbable que todas las réplicas fallen simultáneamente. Recuerda que Always On admite un total de 8 réplicas secundarias.
Las siguientes medidas, aunque imprescindibles, no van a tener un impacto tan directo en la reducción del riesgo, simplemente nos permitirán localizar el problema y tomar medidas antes de que sea tarde. Como habrás adivinado ya, estoy hablando de monitorizar la latencia de replicación: Es crucial monitorizar continuamente la latencia entre el nodo primario y las réplicas y tener un buen sistema de alerta para detectar problemas potenciales. También deberemos realizar pruebas regulares de failover: Realizar pruebas regulares ayuda a garantizar que los nodos secundarios estén configurados correctamente y puedan asumir el rol de primario sin perder datos.
Por último, pero no menos importante deberemos tener una solución de respaldo complementaria. Aunque los Grupos de Disponibilidad AlwaysOn son poderosos, una estrategia de copias de seguridad sólida sigue siendo indispensable. No solo para afrontar fallos de la infraestructura, también porque un borrado o actualización incorrecta se replicará inmediatamente por todas las réplicas y las copias de seguridad serán lo único que nos salve.
Conclusión
Los Grupos de Disponibilidad Always On son una solución robusta para alta disponibilidad y recuperación ante desastres. Sin embargo, como hemos visto, el modo sincrónico no es una garantía absoluta de pérdida cero de datos. Comprender estas limitaciones y diseñar una arquitectura con redundancias adicionales es fundamental para minimizar riesgos y garantizar la integridad de los datos. Siempre debemos complementar nuestras configuraciones con monitorización proactiva, pruebas de failover y estrategias de respaldo adecuadas.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
Always On Availability Groups (AG) es una funcionalidad avanzada de SQL Server que proporciona alta disponibilidad, recuperación ante desastres y replicación. Tradicionalmente, esta tecnología se implementa utilizando Windows Server Failover Cluster (WSFC). Sin embargo, existe una alternativa que elimina la dependencia de WSFC, simplificando la infraestructura en ciertos entornos y adaptándose mejor a escenarios específicos. En este artículo, y a raíz de una petición vuestra en un comentario a uno de mis videos en youtube, os explicaré cómo configurar AG en Windows sin cluster, sus características, limitaciones y casos de uso, además de los scripts necesarios para su administración.
Introducción a Always On sin WSFC
La configuración de Always On sin WSFC, también conocida como grupos de Disponibilidad de Escala de Lectura (Read-Scale Availability Groups, RSAG), es ideal en entornos donde no es posible o necesario implementar un cluster. Esta arquitectura, disponible desde SQL Server 2017, permite que las réplicas de SQL Server funcionen de manera independiente, conectándose directamente entre sí para mantener la sincronización de los datos. A diferencia de la configuración tradicional, no existe una gestión centralizada del Quórum ni un mecanismo de failover automático. En su lugar, los DBA asumimos un papel activo en la supervisión, configuración y administración de los failovers, listeners y otros elementos. Aunque este modelo elimina parte de la complejidad asociada a los clusters, también requiere conocimientos avanzados para garantizar un funcionamiento eficiente y seguro.
Características de Always On sin WSFC
La autonomía de las réplicas es una de las principales características de esta configuración. Cada instancia de SQL Server opera de forma independiente y no depende de un cluster subyacente para coordinar sus roles. El failover, por otro lado, debe realizarse manualmente o mediante scripts personalizados, lo que otorga flexibilidad pero requiere una monitorización constante. Los listeners, que en un entorno con WSFC se configuran automáticamente, aquí deben implementarse manualmente utilizando soluciones externas como balanceadores de carga o DNS, lo que puede agregar complejidad operativa.
En términos de sincronización, esta configuración solo admite el modo asíncrono, lo que prioriza el rendimiento pero, sumado a la falta de balanceo automático, descarta su uso como solución de alta disponibilidad para todos los escenarios. Además, aunque al eliminar la necesidad de WSFC, la infraestructura se simplifica, reduciendo los costes asociados sigue siendo necesario licenciar ambas instancias con una edición Enterprise lo que eleva los costes.
Ventajas y Limitaciones
La eliminación del cluster de Windows en esta configuración aporta beneficios significativos, como la reducción de costes al no requerir licencias adicionales ni configuraciones complejas asociadas a WSFC. Esto hace que sea una solución atractiva para entornos de pruebas y desarrollo. Además, la autonomía de las réplicas facilita la implementación en sistemas más simples, evitando la necesidad de depender de un cluster para mantener la alta disponibilidad.
Sin embargo, esta configuración también tiene limitaciones importantes. La ausencia de un mecanismo de quorum aumenta el riesgo de situaciones de split-brain (ocurre cuando uno o más nodos de un clúster experimentan la desconexión de los otros nodos, lo que resulta en la formación de subclústeres), especialmente en escenarios donde no se monitoriza adecuadamente el estado de las réplicas. Por otro lado, la falta de un listener nativo complica la integración con aplicaciones que dependen de un punto de acceso único para conectarse al nodo activo. La escalabilidad también es más limitada en comparación con un entorno gestionado por WSFC, lo que la hace menos adecuada para infraestructuras complejas o con muchos nodos.
Casos de Uso
Always On sin cluster en Windows es una solución especialmente útil en entornos de pruebas y desarrollo, donde la alta disponibilidad no es crítica pero la replicación de datos es necesaria para realizar simulaciones y validaciones. También es una opción adecuada para aquellos escenarios que no requieren failover automático, pero necesitan una forma de mantener datos sincronizados entre varias instancias para dividir las cargas de trabajo, por ejemplo replicas de solo lectura para análisis en tiempo real.
En sistemas autónomos, donde las réplicas pueden operar independientemente, esta arquitectura también encuentra un buen uso. Asimismo, es una alternativa viable cuando se dispone de soluciones externas avanzadas, como balanceadores de carga o gestión de DNS, que pueden mitigar las limitaciones asociadas a la falta de listeners nativos.
Configuración de Always On sin WSFC
La configuración comienza habilitando Always On en cada instancia de SQL Server desde el Configuration Manager, asegurándose de que las bases de datos estén en modo de recuperación completa. Los endpoints deben configurarse manualmente en cada réplica para permitir la comunicación entre ellas. Una vez configurados los endpoints, se procede a crear el grupo de disponibilidad desde la réplica primaria utilizando T-SQL, definiendo las bases de datos y réplicas participantes, junto con sus modos de sincronización.
En las réplicas secundarias, las bases de datos deben restaurarse en modo de recuperación incompleta (NORECOVERY) antes de añadirlas al grupo de disponibilidad. Finalmente, los listeners deben configurarse manualmente si es necesario, ya sea mediante un DNS dedicado o un balanceador de carga externo, lo que permite redirigir el tráfico al nodo activo.
Gestión y Scripts de Administración
La administración de Always On sin WSFC depende en gran medida de scripts personalizados ya que no dispondremos del dashboard de Always On. Por ejemplo, el estado de sincronización de las réplicas puede verificarse con consultas a las vistas dinámicas sys.dm_hadr_database_replica_states. Además, algunas columnas de esta DMV relacionadas con el clúster pueden mostrar datos sobre un clúster predeterminado interno. Estas columnas son solo para uso interno y se pueden ignorar.
El failover manual, que es una tarea común en esta configuración, se realiza utilizando el comando ALTER AVAILABILITY GROUP … FAILOVER. Además, tras un failover, es necesario reanudar las bases de datos en la nueva réplica primaria con el comando ALTER DATABASE … SET HADR RESUME.
Conclusión
Always On Availability Groups sin cluster en Windows es una alternativa poderosa para entornos específicos, especialmente aquellos donde los costes o la complejidad de WSFC no son aceptables. Aunque su implementación y administración requieren habilidades avanzadas y mayor supervisión, esta configuración ofrece flexibilidad y simplicidad en infraestructura, siendo especialmente adecuada para entornos de pruebas, desarrollo y réplicas de solo lectura. Sin embargo, su uso en producción debe evaluarse cuidadosamente, teniendo en cuenta sus limitaciones en términos de Quórum, failover automático y escalabilidad.
Con una correcta planificación y monitorización, esta arquitectura puede proporcionar una solución eficaz para mantener datos sincronizados en escenarios específicos. Si se implementa correctamente, Always On sin cluster puede ser un recurso invaluable para arquitecturas modernas y simplificadas.
Te invito a seguirnos en el canal de YouTube donde pronto trataré de mostrar la configuración paso a paso de este tipo de Always On.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
ID incrementales o GUID ¿cuál elegir?, esta es la pregunta que me hizo uno de vosotros hace unos días. Y yo también añadiría a la pregunta las secuencias. Vamos a tratar de responder esta duda.
Cuando diseñamos un modelo de datos en SQL Server o cualquier otro sistema de bases de datos relacional, una de las decisiones más importantes es la elección del tipo de identificador principal para nuestras tablas. ID autoincrementales, GUID y secuencias son opciones comunes, cada una con sus ventajas y limitaciones. En este artículo veremos las características de cada enfoque, sus diferencias y cómo afectan al rendimiento y a la fragmentación de índices para tratar de llegar a la respuesta ideal para cada escenario. Porque sí, como pasa siempre con las soluciones de bases de datos, vais a ver que no existe una respuesta única para todos los escenarios.
IDs autoincrementales
Los ID autoincrementales, conocidos como IDENTITY, son probablemente la solución más utilizada. Se generan de manera automática con cada inserción en la tabla, siguiendo un orden secuencial. Este tipo de identificador es ideal para sistemas centralizados donde no se necesita garantizar unicidad global. Su principal ventaja radica en el consumo reducido de espacio y el bajo impacto en la fragmentación de índices clustered, ya que las inserciones se producen siempre al final del índice.
Lo normal para este tipo de IDs es usar valores numéricos del tipo INT (desde -2.147.483.648 hasta 2.147.483.647) o BIGINT (desde – 9.223.372.036.854.775.808 a 9.223.372.036.854.775.807). Porque sí, los valores negativos también existen y son utilizables.
Sin embargo, los ID autoincrementales no están exentos de problemas. Por ejemplo, en sistemas distribuidos o replicados, la generación secuencial puede llevar a conflictos si diferentes nodos intentan generar los mismos valores. Además, al ser fácilmente predecibles, pueden ser problemáticos desde una perspectiva de seguridad.
GUID: ID con unicidad global
Los GUID o identificadores únicos globales son valores generados al azar que garantizan unicidad, incluso entre sistemas distribuidos. Esta característica los hace indispensables en escenarios de replicación o cuando los datos se integran desde múltiples orígenes.
El problema de los GUID radica en su tamaño: 16 bytes por registro frente a los 4 u 8 bytes de un INT o BIGINT respectivamente. Esto aumenta significativamente el tamaño de las tablas y los índices y, en consecuencia, el coste de las consultas. Además, su naturaleza aleatoria introduce fragmentación en índices, afectando negativamente al rendimiento en sistemas con altas tasas de inserción.
Para mitigar estos problemas, SQL Server ofrece la función NEWSEQUENTIALID(), que genera GUID en orden secuencial, reduciendo la fragmentación pero sin eliminarla completamente.
Secuencias: ID compartidos
Las secuencias son una alternativa poderosa introducida en SQL Server 2012. Se definen como objetos independientes a las tablas que generan números únicos bajo demanda, ofreciendo un control total sobre cómo se producen los valores. A diferencia de los ID autoincrementales, las secuencias no están ligadas a una tabla específica, lo que las hace reutilizables en múltiples tablas o contextos. Una de sus ventajas clave es la posibilidad de configurarlas para satisfacer requisitos específicos, como usar valores iniciales personalizados o incrementos distintos de uno. Además, permiten generar identificadores únicos en sistemas distribuidos mediante estrategias como prefijos por nodo.
Sin embargo, las secuencias también presentan limitaciones, como la posibilidad de generar brechas en caso de transacciones fallidas y una configuración inicial más compleja que los ID autoincrementales.
Comparativa: ID autoincrementales, GUID y secuencias
A continuación, os muestro una tabla resumen con una comparación detallada de las tres opciones:
Criterio
Autoincrementales
GUIDs
Secuencias
Tamaño
4-8 bytes (INT, BIGINT)
16 bytes (uniqueidentifier)
4-8 bytes (INT, BIGINT)
Fragmentación
Baja
Alta (aleatoria)
Baja si se utiliza con cuidado
Unicidad global
No
Sí
Sí (configurable)
Flexibilidad
Baja
Alta
Muy alta
Desempeño
Alto
Medio-bajo
Alto
Compatibilidad distribuida
Limitada
Alta
Media-alta
Fragmentación de índices y su impacto
La fragmentación es un factor crucial en el rendimiento de una base de datos. En índices clustered, los valores secuenciales de ID autoincrementales o secuencias generan inserciones ordenadas, minimizando la fragmentación. Por el contrario, los GUID, debido a su naturaleza aleatoria, obligan a reordenamientos constantes en las páginas del índice, aumentando tanto la fragmentación como el coste de mantenimiento.
Para mitigar este problema con GUID, se recomienda usar índices no clustered (no exentos de fragmentación pero con menor impacto) o estrategias como NEWSEQUENTIALID() cuando sea posible. En el caso de secuencias, su comportamiento depende de cómo se configuren, los valores secuenciales preservan el orden, mientras que configuraciones más complejas pueden introducir fragmentación.
Conclusión
No hay una única solución ideal; la elección depende del contexto y los requisitos del sistema. Si el rendimiento y el espacio son prioritarios, los ID autoincrementales son la mejor opción en sistemas centralizados. Para entornos distribuidos donde la unicidad global es crucial, los GUID son indispensables, aunque con un coste en rendimiento y espacio. Finalmente, las secuencias ofrecen una alternativa flexible y controlada que puede adaptarse a múltiples escenarios, especialmente cuando se necesita compatibilidad entre tablas o nodos. En última instancia, el éxito radica en comprender las ventajas y limitaciones de cada enfoque, optimizando su uso según las necesidades específicas del proyecto.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
Existen múltiples alternativas a SQL Server Management Studio (SSMS) que pueden ajustarse mejor a distintas necesidades y presupuestos. Estas opciones incluyen herramientas tanto de Microsoft como de terceros, así como opciones gratuitas y de pago. La elección de una alternativa adecuada a SSMS dependerá en gran medida del contexto de uso, las funcionalidades requeridas y la infraestructura de cada organización. Hoy quiero repasar con vosotros algunas de las principales opciones que vais a poder utilizar y para que casos de uso son más recomendadas.
Azure Data Studio: Una Alternativa Moderna de Microsoft
Una de las alternativas más destacadas la vamos a encontrar en el catálogo de Microsoft y no es otra que Azure Data Studio. De Azure Data Studio ya hemos hablado en alguna ocasión y es una herramienta moderna diseñada para entornos de nube y escenarios híbridos. Azure Data Studio se caracteriza por ser multiplataforma, permitiendo su uso en sistemas operativos Windows, macOS y Linux. Esto lo convierte en una opción versátil, especialmente para desarrolladores y administradores de bases de datos que requieren una interfaz ligera y flexible. Su sistema de extensiones permite personalizar el entorno y añadir funcionalidades específicas, como soporte para Power BI o notebooks interactivos que facilitan la visualización de datos.
Sin embargo, aunque Azure Data Studio admite complementos y se actualiza regularmente, algunas funcionalidades avanzadas de administración de SQL Server todavía no están presentes, lo que limita su uso para tareas puramente administrativas en comparación con SSMS. Además, su enfoque está orientado más hacia el desarrollo que hacia la administración, lo que puede resultar insuficiente para ciertos administradores de bases de datos que necesitan un control total sobre sus instancias.
Aqua Data Studio: Versatilidad y soporte multi base de datos para desarrolladores
Otra opción a considerar es Aqua Data Studio, una herramienta que destaca por su compatibilidad con múltiples sistemas de gestión de bases de datos (SGBD), entre ellos SQL Server, Oracle, MySQL y PostgreSQL. Aqua Data Studio permite a los usuarios administrar, modelar y desarrollar sobre diversas bases de datos en una sola interfaz, lo que la convierte en una opción ideal para entornos con múltiples bases de datos. La herramienta también ofrece funcionalidades avanzadas de visualización de datos, que son útiles para el análisis y la toma de decisiones basadas en datos como por ejemplo poder filtrar y ordenar los resultados de una consulta como si de una tabla de excel se tratase. Para esto, hace uso de los datos ya cargados en local y no vuelve a ejecutar la consulta.
Otras de sus ventajas son la interfaz intuitiva, su soporte para diagramas ER y sus herramientas de depuración de SQL, que facilitan la optimización de consultas. No obstante, Aqua Data Studio es una herramienta de pago, y su coste puede ser elevado para algunos usuarios, especialmente aquellos que solo necesitan una solución específica para SQL Server.
DbForge Studio for SQL Server: Una alternativa para desarrollo y optimización
Siguiendo con las herramientas de terceros, DbForge Studio for SQL Server de Devart es una alternativa robusta, conocida por su enfoque en el desarrollo y optimización de bases de datos. Esta herramienta incluye un editor de SQL avanzado con funcionalidades de autocompletado, refactorización de código y análisis de dependencias, lo cual facilita el trabajo de desarrollo.
Además, ofrece capacidades de perfilado de bases de datos, lo que permite identificar y resolver cuellos de botella en el rendimiento de consultas SQL, y funcionalidades para la comparación y sincronización de bases de datos. Estas características la convierten en una opción poderosa para entornos donde se requiere un control avanzado y optimización. Sin embargo, su precio puede ser una barrera, especialmente en organizaciones con presupuesto limitado, y está disponible únicamente en Windows, lo que limita su uso en entornos que requieren multiplataforma.
DBeaver: Una Alternativa Multiplataforma para Entornos Híbridos
Otra herramienta relevante es DBeaver, una aplicación de código abierto y multiplataforma compatible con diversos SGBD, incluyendo SQL Server. DBeaver es popular en entornos híbridos por su flexibilidad, y su sistema de plugins permite añadir funcionalidades específicas. La versión gratuita de DBeaver incluye funcionalidades básicas, mientras que la edición Enterprise (de pago) añade opciones avanzadas, como la administración de bases de datos y el soporte para control de versiones.
Sin embargo, su interfaz, aunque flexible, puede resultar sobrecargada para quienes buscan un entorno exclusivamente enfocado en SQL Server. Además, al ser una herramienta genérica, carece de integración nativa con algunas soluciones de Microsoft, lo que puede limitar su uso en infraestructuras completamente basadas en el ecosistema de Microsoft.
Toad for SQL Server: Optimización y automatización para DBAs
Toad for SQL Server de Quest Software también es una alternativa sólida, especialmente valorada por sus capacidades de optimización y monitorización. Esta herramientas permite a los administradores de bases de datos automatizar tareas de mantenimiento y administración, así como optimizar consultas SQL con sugerencias basadas en análisis de rendimiento en tiempo real.
Su soporte para control de versiones lo convierte en una excelente herramienta para el trabajo en equipo, permitiendo a los desarrolladores y administradores sincronizar cambios y trabajar colaborativamente en proyectos de base de datos. No obstante, el alto coste de Toad y la complejidad de su interfaz pueden ser barreras para usuarios con menos experiencia o para organizaciones pequeñas con recursos limitados.
SQuirreL SQL: Una alternativa gratuita y multi base de datos
Ya vamos acercándonos al final de este artículo con SQuirreL SQL, una opción de código abierto que, aunque no está especializada en SQL Server, ofrece una solución gratuita y multiplataforma para trabajar con múltiples SGBD. Si necesitamos compatibilidad con diversos motores de base de datos en un solo entorno SQuirreL SQL es la herramienta adecuada. Sin embargo, esta herramienta carece de funcionalidades avanzadas para administración y monitoreo de rendimiento en SQL Server, y su interfaz es menos moderna, lo que puede ser una desventaja para usuarios acostumbrados a herramientas más actuales.
HeidiSQL: Una alternativa portable
HeidiSQL es conocido principalmente por su compatibilidad con bases de datos MySQL y MariaDB, pero también soporta conexiones a SQL Server y PostgreSQL, ampliando su utilidad en entornos multi-SGBD. Es una herramienta liviana, con un diseño intuitivo y que permite gestionar bases de datos sin ocupar mucho espacio ni recursos del sistema. Su naturaleza portable es ideal para administradores y desarrolladores que necesitan acceder a SQL Server ocasionalmente o en situaciones donde no es posible instalar software de forma permanente.
Una de las principales ventajas de HeidiSQL es su facilidad de uso y su enfoque en la administración básica y el desarrollo de SQL. Además, permite realizar tareas como editar y ejecutar consultas SQL, exportar e importar datos, y administrar tablas y vistas. Estas funcionalidades pueden ser suficientes para tareas de mantenimiento diario y desarrollo básico en SQL Server, sin la necesidad de instalar software más pesado como SSMS.
Sin embargo, es importante destacar que HeidiSQL no proporciona las herramientas avanzadas de administración y optimización que se encuentran en SSMS o en alternativas como Toad for SQL Server o DbForge Studio. Esto limita su uso a entornos en los que se requieren operaciones sencillas. Asimismo, su interfaz y opciones están más orientadas a usuarios de MySQL y MariaDB, por lo que algunos aspectos pueden resultar limitados en el entorno de SQL Server.
Conclusión
En conclusión, la alternativa más adecuada a SSMS dependerá de las necesidades específicas de cada equipo o proyecto. Herramientas como Azure Data Studio y Aqua Data Studio ofrecen opciones multiplataforma y flexibles que se integran bien en entornos modernos y de nube, mientras que DbForge Studio y Toad for SQL Server proporcionan funcionalidades avanzadas de optimización y administración, a un coste. DBeaver, SQuirreL SQL y HeidiSQL son opciones gratuitas (con opción de pago) adecuadas para entornos multi-SGBD, aunque con ciertas limitaciones en el ámbito de SQL Server. La elección final debe considerar factores como la funcionalidad necesaria, el presupuesto y el ecosistema tecnológico en el que se desarrollarán las actividades de administración y desarrollo.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
Colabora con nosotros
SoyDBA.es es gratis para ti y siempre va a serlo. Sin embargo, a nosotros si que nos cuesta dinero además de mucho esfuerzo. Puedes colaborar con nosotros con un donativo por PayPal o usando nuestros enlaces de afiliado para colaborar sin que te cueste nada. Tenemos enlace de Amazon y de Aliexpress
Para ofrecer las mejores experiencias, utilizamos tecnologías como las cookies para almacenar y/o acceder a la información del dispositivo. El consentimiento de estas tecnologías nos permitirá procesar datos como el comportamiento de navegación o las identificaciones únicas en este sitio. No consentir o retirar el consentimiento, puede afectar negativamente a ciertas características y funciones.
Funcional
Siempre activo
El almacenamiento o acceso técnico es estrictamente necesario para el propósito legítimo de permitir el uso de un servicio específico explícitamente solicitado por el abonado o usuario, o con el único propósito de llevar a cabo la transmisión de una comunicación a través de una red de comunicaciones electrónicas.
Preferencias
El almacenamiento o acceso técnico es necesario para la finalidad legítima de almacenar preferencias no solicitadas por el abonado o usuario.
Estadísticas
El almacenamiento o acceso técnico que es utilizado exclusivamente con fines estadísticos.El almacenamiento o acceso técnico que se utiliza exclusivamente con fines estadísticos anónimos. Sin un requerimiento, el cumplimiento voluntario por parte de tu proveedor de servicios de Internet, o los registros adicionales de un tercero, la información almacenada o recuperada sólo para este propósito no se puede utilizar para identificarte.
Marketing
El almacenamiento o acceso técnico es necesario para crear perfiles de usuario para enviar publicidad, o para rastrear al usuario en una web o en varias web con fines de marketing similares.
