SQL Server

13
Oct
2025

Final de año de comunidad: eventos, charlas y oportunidades

Se acerca el final del año y, como suele pasar, nos entra la prisa por encajar en el calendario todo lo que no hicimos en primavera. Resultado, el último trimestre está cargado de eventos, meetups, conferencias y saraos varios. Y no me quejo, al contrario. Es ahora cuando se ve quién está realmente comprometido con la comunidad técnica y quién solo se apunta cuando hay camisetas gratis.

Este artículo no va de SQL Server (aunque aparecerá, no os preocupéis). Va de comunidad. De compartir conocimiento, de subirse al escenario a contar lo que uno ha aprendido a base de picar piedra. Y, sobre todo, va de animar a más gente a participar. Así que si eres de los que siempre dicen “me gustaría dar una charla algún día” o simplemente nunca antes te has animado a venir de público a un evento… este trimestre tienes varios “algún día” a tiro.

Vamos al lío. Os dejo el calendario de eventos clave para lo que queda de año, algunos de los cuales tengo el placer de participar directamente.

Power BI & Fabric Days (Barcelona, 17 y 18 de octubre)

Este viernes y sábado se celebra en Barcelona una de las citas clave para los que trabajamos con tecnologías de datos de Microsoft.

En mi caso, estaré dando una charla sobre Power BI Report Server (PBIRS), ese gran olvidado que sigue teniendo hueco (y sentido) en muchos entornos corporativos. Pero no vengo solo, hay un montón de sesiones, talleres prácticos y espacio para hacer networking del bueno. Ya sabes ese networking que empieza con “¿y tú qué haces en tu curro?” y acaba en “te paso el script que usamos para eso”.

Eventos BCN talleres
Eventos BCN Charlas

El evento es gratuito, con registro previo y plazas limitadas. Si estás en Barcelona o puedes desplazarte, no hay excusa. Consigue aquí tu entrada para los talleres o para las charlas.

Optimización de SQL para Power Platform (Online, 30 de octubre)

El jueves 30 de octubre tengo sesión online para la comunidad de Power Platform Madrid. Vamos a hablar de SQL, claro, pero desde la óptica que cada vez más nos piden: ¿cómo optimizar lo que hay detrás de nuestros reportes en Power BI y Fabric?

Spoiler: Muchas veces, lo que falla no está en la nube, sino en ese SELECT * que alguien pensó que era inocente.

Eventos Online PPM

Será una sesión práctica, sin más PowerPoints del imprescindible, pensada para quienes están sufriendo con conectores lentos, tablas compartidas con medio planeta y consultas que tardan más que una reunión de status. Regístrate aquí para no perdértelo.

NetCoreConf Madrid (14 de noviembre)

Evento veterano donde los haya, NetCoreConf vuelve a Madrid con una edición presencial que promete. Aunque el call for speakers aún está abierto, ya se sabe que este evento es terreno fértil para desarrolladores de nivel, sesiones técnicas de verdad y, cómo no, muchas charlas sobre datos, arquitectura y rendimiento.

Yo pienso estar allí, veremos si como ponente o no. Porque aunque vayas solo de oyente, siempre se aprende algo. O al menos descubres cómo están resolviendo otros lo que tú estás parcheando como puedes.

Si estás pensando enviar sesión, aún llegas. Y si no, al menos resérvate el día en el calendario.

Data Saturday Madrid (27 al 29 de noviembre)

Este es el evento. Así, sin más.

Data Saturday Madrid es la cita principal de la comunidad de datos en España. Y este año viene con tres días completos: dos días de talleres intensivos y un día de conferencias con ponentes de primera línea, tanto nacionales como internacionales.

La agenda aún no está publicada (a fecha de escribir esto), pero no hace falta verla para saber que el nivel será alto. Si vienes, tráete libreta y preguntas. Y si no vienes… bueno, luego no digas que no te enteras de las tendencias del sector.

Estaré por allí seguro. Y si te cruzas conmigo, saluda. Siempre es buen momento para desvirtualizar a gente que lleva años sufriendo los mismos deadlocks que tú.

Corre y consigue aquí tu entrada antes de que se acaben (el año pasado mucha gente se quedó fuera por Sold Out)

Non-Profit Community Day Spain (Madrid, 4 de diciembre)

Este es un evento distinto, y eso es lo que lo hace especial. El Non-Profit Community Day Spain se celebra en las oficinas de Microsoft en Madrid y está centrado en ONGs, fundaciones y proyectos sin ánimo de lucro.

Habrá charlas técnicas, casos de uso reales y mucho foco en cómo la tecnología puede aportar valor social. No hay agenda todavía cerrada porque el Call for Speakers sigue abierto, pero si tienes una historia que contar (y todos tenemos alguna), aquí tienes un escenario ideal.

Tecnología con propósito. Y en un entorno que suele estar infrarrepresentado en nuestros circuitos habituales.

Christmas Power Platform (12 y 13 de diciembre, online)

Seguimos con las causas solidarias. 

La segunda edición de este evento benéfico tiene todos los ingredientes que deberían movernos a participar: es online, es para una buena causa (recaudación para una ONG que trabaja con niños hospitalizados) y está abierto a todos.

Las charlas son de 20 minutos, formato ligero, y cubren cualquier tema relacionado con datos, Power Platform, IA, automatización o BI. Si alguna vez has dicho “yo no tengo nivel para hablar en público”, este es el sitio perfecto para empezar. Nadie te va a juzgar, y todos vamos a aprender algo. Animate y presenta tu sesión aquí.

Y si no te animas a presentar sesión, al menos conéctate y aporta con tu presencia, con una donación o simplemente dando difusión. A veces, ser comunidad también es esto, estar cuando no hay regalos ni sorteos, pero sí mucho corazón.

Comunidad SQL Server Español (14/10 y cada segundo martes del mes)

No podía cerrar esta agenda sin mencionar los eventos online de la comunidad SQL Server Español, que organizo junto a Cristina y que cada mes reúnen a decenas de profesionales con algo en común: siguen trabajando con SQL Server y quieren hacerlo mejor.

Este martes 14 de octubre (sí, mañana si estás leyendo esto el lunes), contaremos con Jorge Perona, que nos hablará de cómo administrar entornos on-prem desde la nube usando Azure Arc. Una charla muy oportuna, especialmente para quienes andan en entornos híbridos donde lo único constante es el caos de licencias, políticas y versiones mezcladas. Consigue tu entrada totalmente gratis aquí.

Y como cada mes, nos volveremos a ver el segundo martes de noviembre y el segundo martes de diciembre. Aún no puedo adelantaros las ponencias que serán, pero como siempre, serán sesiones técnicas de verdad. Nada de postureo. Aquí venimos a hablar de índices, de rendimiento, de administración real.

Si trabajas con SQL Server, hablas español y aún no te has pasado por uno de estos eventos, no sé a qué esperas.

Conclusión

El calendario está lleno. Hay eventos en todas las modalidades: presenciales, online, técnicos, sociales, de comunidad pura y de divulgación. No todos te interesarán, y no pasa nada. Pero si te interesa mejorar como profesional, hacer contactos más allá de LinkedIn y aprender de gente que ya ha pasado por lo mismo que tú… no hay mejor inversión de tiempo.

Además, si llevas tiempo pensando en dar una charla, enviar un paper o simplemente aparecer por un evento y escuchar, este último tramo del año es tu oportunidad. Entre sesiones mensuales, eventos solidarios y conferencias de alto nivel, el menú no puede ser más completo.

Y ya sabes: quien no se mueve, no sale en la foto. Nos vemos en los eventos.

PD: Si quieres hacerte con uno de mis libros o ya lo tienes y quieres una dedicatoria vente a uno de estos eventos y avísame.

Publicado por Roberto Carrancio en Otros, 0 comentarios
10
Oct
2025

Cuando un LEFT JOIN se convierte en INNER. SQL Server Basics

Lo has visto. Lo has sufrido. Y si aún no te ha pasado, enhorabuena, pero no te relajes, tu día llegará. Me refiero al clásico caso del LEFT JOIN que acaba comportándose como un INNER JOIN porque alguien decidió, en un momento de inspiración, colocar un filtro donde no debía. Y claro, la consulta no devuelve lo que se espera, o peor: devuelve justo lo que se espera, pero está mal.

Hoy vamos a hablar de un problema que se cuela en muchos desarrollos y auditorías de código: el efecto de los filtros en un LEFT JOIN, y cómo una mala ubicación puede cambiar radicalmente el comportamiento de tu consulta. Así que prepara café, que vienen curvas.

El LEFT JOIN que no era

Un LEFT JOIN debería, en teoría, devolver todos los registros de la tabla izquierda, aunque no haya coincidencia en la tabla derecha. Hasta aquí, todo bien. Pero esto solo se cumple si no saboteas la lógica desde el WHERE.

Veamos un ejemplo simple pero revelador:

SELECT c.ClienteID, c.Nombre, f.FacturaID
FROM Clientes c
LEFT JOIN Facturas f 
 ON c.ClienteID = f.ClienteID
WHERE f.Fecha >= '2025-01-01'

A simple vista parece correcto. Queremos todos los clientes y, si tienen facturas a partir de 2025, las mostramos. Pero no. Lo que acaba devolviendo esta consulta es únicamente aquellos clientes que tienen facturas desde 2025. ¿Y los que no tienen ninguna factura? Fuera del resultado. Despedidos.

¿Por qué? Porque estás aplicando un filtro sobre una columna de la tabla derecha (Facturas) después del JOIN, pero en el WHERE, que se evalúa después del JOIN, cuando los NULL ya están presentes. Y claro, NULL >= ‘2025-01-01’ es FALSE. El motor hace su trabajo, y tú te quedas sin clientes sin facturas.

¿Dónde va el filtro entonces?

En el ON. Sí, ese que muchos usan como si fuera una casilla para emparejar claves primarias con foráneas y poco más. Pero el ON tiene un papel más interesante aquí, si metes el filtro ahí, estarás condicionando el JOIN, no el resultado final.

Así que la versión correcta sería:

SELECT c.ClienteID, c.Nombre, f.FacturaID
FROM Clientes c
LEFT JOIN Facturas f
 ON c.ClienteID = f.ClienteID AND f.Fecha >= '2025-01-01'

Ahora sí, todos los clientes aparecen. Los que tienen facturas desde 2025 las verán en su fila. Los que no, tendrán NULL en FacturaID. Tal y como un LEFT JOIN debe comportarse.

¿Y si necesito más filtros?

Buena pregunta. No es raro que quieras filtrar también por condiciones de la tabla izquierda. ¿Qué pasa entonces? Pues ahí sí puedes usar el WHERE, con criterio.

Por ejemplo:

SELECT c.ClienteID, c.Nombre, f.FacturaID
FROM Clientes c
LEFT JOIN Facturas f 
 ON c.ClienteID = f.ClienteID AND f.Fecha >= '2025-01-01'
WHERE c.Activo = 1

Esto funciona como debe. El filtro en Clientes actúa después del JOIN, pero como no anula la lógica del LEFT, todo sigue su curso. Los clientes activos salen todos, tengan o no facturas desde 2025. Así sí.

¿Y si necesito filtrar por una columna de la derecha, pero sólo cuando no sea NULL?

Aquí empieza el juego sucio. Lo que quieres, probablemente, es quedarte con clientes que tengan facturas desde 2025, pero también mostrar los que no tienen ninguna factura. En ese caso, tienes que pensar en lógica condicional.

Una forma válida sería:

SELECT c.ClienteID, c.Nombre, f.FacturaID
FROM Clientes c
LEFT JOIN Facturas f 
 ON c.ClienteID = f.ClienteID
WHERE  f.Fecha >= '2025-01-01' OR f.FacturaID IS NULL

Esto ya es más decente. Estás diciendo: «dame los clientes que tienen facturas desde 2025, o los que no tienen ninguna factura». Y eso se respeta.

Pero seamos sinceros, si tienes que hacer esto a menudo, algo en tu modelo de consultas no huele bien. O tu reporting, o tu forma de pensar los datos. En esos casos, es mejor plantearte si necesitas un LEFT JOIN, unas vacaciones o modificar la lógica entera de la consulta.

No es un detalle menor

Aquí no estamos hablando de una microoptimización ni de una virguería SQL. Estamos hablando de lógica rota. El tipo de error que pasa todos los entornos, llega a producción, y luego nadie entiende por qué los informes no cuadran con la realidad.

Y lo peor, es un error silencioso. No da fallo. No lanza excepciones. Simplemente te da datos incorrectos con cara de datos correctos. Lo cual, en nuestro mundo, es el infierno.

En auditorías de rendimiento y revisiones de lógica de negocio, me encuentro este patrón con una frecuencia desesperante. Muchas veces me dicen: «Pero es que es un LEFT JOIN, ¿por qué no salen todos?». Y la respuesta es casi siempre la misma: porque tú mismo has convertido ese LEFT en un INNER, sin darte cuenta.

¿Qué pasa con los ORMs?

Sí, los ORMs. Esos grandes generadores de consultas elegantes como un campo minado. Hay ORMs que optimizan mal los JOIN, o que aplican los filtros fuera del ON por defecto. Y luego te toca a ti arreglar el entuerto porque el modelo “no da para más”.

Así que si estás usando Entity Framework, Hibernate o cualquier ORM moderno, revísalo tú a mano. No confíes en que el generador de consultas haya entendido tus intenciones como tú las entiendes.

Y ya que estamos, un apunte sobre MERGE

Sí, ya sé que esto va de LEFT JOIN, pero la confusión entre el WHERE y el ON en MERGE también merece un recordatorio. Porque ahí también es fácil liarla. En un MERGE, el ON es la condición de emparejamiento, no de filtrado. Si lo usas mal, puedes terminar haciendo UPDATE a registros que no deberías tocar, o insertando cosas que ni sabías que existían.

Lo dejo ahí, pero si te interesa, en el blog ya hablé en profundidad sobre los problemas de MERGE.

Conclusión

Si vas a usar un LEFT JOIN, asegúrate de entender cómo funciona y dónde colocar los filtros. No es un tema de estilo, es un tema de lógica. Un WHERE mal puesto no solo degrada el rendimiento: rompe la semántica de tu consulta.

Así que la próxima vez que revises una query con LEFT JOIN, pregúntate si realmente está haciendo lo que debería. Y si no, ya sabes dónde mirar primero: el WHERE. Porque sí, puedes hacer un LEFT JOIN que se comporte como un INNER, y también puedes correr con los cordones desatados. Ambas cosas acaban mal.

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! 

Publicado por Roberto Carrancio en Cloud, SQL Server, 3 comentarios
08
Oct
2025

Funciones inline en SQL Server.

Si vienes del artículo anterior sobre procedimientos almacenados vs funciones, ya sabes que no todas las funciones son iguales ni todas son igual de bienvenidas en producción. Hoy vamos a entrar en el terreno de las que sí merecen un sitio en entornos serios, las funciones inline con valores de tabla, o inline TVF.

Porque sí, en SQL Server también hay funciones que se comportan bien, no matan el rendimiento y hasta pueden ser aliadas del optimizador. Eso sí, como siempre en SQL Server, hay letra pequeña. Y no es precisamente corta.

¿Qué es exactamente una función inline?

Una función inline con valores de tabla es un objeto de base de datos que devuelve una tabla como resultado, definida a partir de una única instrucción SELECT. La sintaxis es clara: no hay BEGIN…END, no hay tablas variables intermedias ni lógica procedural. Solo una expresión SELECT que define el resultado.

Un ejemplo básico:

CREATE FUNCTION dbo.UltimosPedidos (@ClienteID INT)
RETURNS TABLE
AS
RETURN (
    SELECT TOP 10 *
    FROM dbo.Pedidos
    WHERE ClienteID = @ClienteID
    ORDER BY FechaPedido DESC
);

La clave aquí está en el hecho de que la función no tiene cuerpo procedural. El RETURN devuelve directamente el SELECT, sin necesidad de declarar una variable tipo tabla ni usar bloques de control. Y eso le encanta al optimizador de consultas.

¿Por qué son tan diferentes del resto?

La principal ventaja de las funciones inline es que se expanden dentro del plan de ejecución de la consulta que las llama. Es decir, se comportan como si hubieras escrito el SELECT directamente en la consulta. Esto permite al optimizador generar un único plan coherente, hacer estimaciones de cardinalidad más precisas y aplicar filtros, joins o incluso reescrituras sin perder información.

No hay saltos de contexto, no hay opacidad. Todo se ve. Todo se puede optimizar. Todo fluye.

Esto contrasta brutalmente con las funciones escalares o las funciones con valores de tabla multisentencia, donde el optimizador pierde visibilidad, rompe el plan y acaba tirando de valores fijos o estimaciones aleatorias dignas de una quiniela.

En resumen, si necesitas encapsular lógica reutilizable que devuelve datos en forma de tabla y quieres mantener el rendimiento, la inline TVF es tu opción.

Buenas prácticas: lo que conviene hacer

Usar funciones inline no solo es una cuestión de sintaxis correcta. También hay que saber cómo diseñarlas para que sean eficientes, reutilizables y mantenibles. Aquí van algunas prácticas que realmente marcan la diferencia:

Primero, mantén la lógica centrada en una única operación clara. Si necesitas múltiples pasos, joins complejos, condiciones opcionales o lógica condicional, es probable que estés forzando demasiado el diseño y que deberías estar en un procedimiento o en una vista indexada (si tienes valor para ello).

Segundo, evita usar funciones inline como simples extractores de columnas. Si solo encapsulas un SELECT de una tabla sin añadir valor, estás generando una capa innecesaria que complica los planes y aporta poco. Úsalas cuando encapsules lógica real: filtrados, joins relevantes, condiciones específicas.

Tercero, documenta los parámetros con claridad. SQL Server no impone muchas restricciones, pero el que venga detrás (que probablemente seas tú dentro de seis meses) agradecerá saber qué espera exactamente cada parámetro y cómo afecta al resultado.

Por último, cuidado con los TOP y los ORDER BY. En funciones inline, el ORDER BY solo es válido dentro de un TOP… pero eso no significa que respete el orden en la consulta final. El optimizador puede decidir hacer lo que le venga en gana si no hay ORDER BY explícito en la consulta externa. Que no te sorprenda.

Casos de uso donde brillan

Hay escenarios donde una función inline brilla con luz propia. Uno de los más frecuentes: filtros complejos reutilizables. Supón que tienes una lógica de negocio que define qué pedidos se consideran “activos”, basada en múltiples condiciones, fechas, flags y columnas calculadas. Puedes encapsular esa lógica en una función inline y usarla como si fuera una subconsulta parametrizada.

Otro caso clásico: reportes o dashboards parametrizados. Si usas Power BI o cualquier herramienta de reporting que genere consultas dinámicas, puedes exponer funciones inline como “vistas parametrizadas” que reducen la complejidad del modelo y mejoran el mantenimiento.

Y por supuesto, también son útiles en procesos ETL que necesitan aplicar filtros reutilizables en múltiples pasos sin replicar lógica por todas partes.

Lo que NO debes hacer (aunque la tentación sea fuerte)

El hecho de que las funciones inline se comporten tan bien no significa que sean inmunes al mal diseño. De hecho, hay errores recurrentes que siguen apareciendo incluso entre DBAs con experiencia.

Uno muy común es usar funciones inline con un JOIN interno a una tabla de millones de filas sin tener en cuenta filtros exteriores. Como la función se expande, esa tabla puede aparecer en cada ejecución de forma inesperada y generar planes desastrosos.

Otro clásico, parámetros mal definidos o con valores opcionales que no se gestionan bien. SQL Server no permite parámetros opcionales en funciones, así que muchos intentan simularlo con NULL y condiciones tipo (@Param IS NULL OR Columna = @Param). Esto degrada los planes de ejecución, impide la indexación eficaz y rompe la estimación de cardinalidad. Una joya.

Y uno más, pensar que por ser una función inline, siempre va a ir rápido. Si la lógica interna es compleja, hace joins mal indexados o usa filtros poco selectivos, el plan puede seguir siendo un desastre. El que se vea no significa que sea bueno.

Comparación real: subconsulta vs función inline

Para los escépticos, vamos con un ejemplo sencillo.

Subconsulta tradicional

SELECT c.ClienteID, c.Nombre,
       (SELECT COUNT(*) 
        FROM Pedidos p 
        WHERE p.ClienteID = c.ClienteID AND p.Estado = 'Activo') AS PedidosActivos
FROM Clientes c;

Esto se puede convertir en una función inline así:

CREATE FUNCTION dbo.PedidosActivos (@ClienteID INT)
RETURNS TABLE
AS
RETURN (
    SELECT COUNT(*) AS Total
    FROM Pedidos
    WHERE ClienteID = @ClienteID AND Estado = 'Activo'
);

Y luego usarla así:

SELECT c.ClienteID, c.Nombre, pa.Total
FROM Clientes c
OUTER APPLY dbo.PedidosActivos(c.ClienteID) pa;

¿La diferencia? En un entorno donde se reutiliza la lógica o se combina con otras condiciones, encapsularla en una función inline puede mejorar la legibilidad y el mantenimiento. Y con OUTER APPLY, se comporta como una subconsulta correlacionada, pero con visibilidad total en el plan.

Eso sí, no uses CROSS APPLY si no estás 100% seguro de que todas las combinaciones producirán resultado. Te lo recordarás a las 3 de la mañana.

Conclusión

Las funciones inline son una de esas herramientas que, bien usadas, te hacen la vida más fácil y el código más limpio. Mal usadas, solo complican las cosas sin aportar rendimiento ni claridad. No son la solución a todo, pero en el conjunto correcto de circunstancias, pueden sustituir a vistas, subconsultas o incluso procedimientos ligeros con mucha más flexibilidad.

Y sobre todo, te permiten encapsular lógica sin pagar el peaje que sí tienen otras funciones. Como siempre en SQL Server, no es solo cuestión de saber que existen, sino de saber cuándo y cómo usarlas. Porque sí, hay funciones buenas. Solo hay que reconocerlas.

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! 

Publicado por Roberto Carrancio en Cloud, Rendimiento, SQL Server, 0 comentarios
03
Oct
2025

Procedimientos almacenados y Funciones. SQL Server Basics

En SQL Server, hay ciertos conceptos que uno se encuentra tarde o temprano, tanto si empieza en el mundo de las bases de datos como si ya lleva un tiempo peleándose con entornos reales. Los procedimientos almacenados y las funciones son dos de ellos. Ambos permiten encapsular lógica en T-SQL, ambos pueden reutilizarse y ambos tienen su lugar. Pero no son lo mismo. Y tratarlos como si lo fueran es una fuente constante de confusión, errores y, en muchos casos, de mal rendimiento.

Este artículo no busca hacer una comparativa teórica más. Aquí vamos a ver en qué se diferencian realmente, cuándo conviene usar uno u otro, qué limitaciones tiene cada uno y qué errores son más comunes al trabajar con ellos. Si estás empezando con SQL Server, esto es una base fundamental. Y si ya llevas tiempo en el oficio, probablemente te encuentres con más de una práctica que conviene revisar.

Entendiendo la diferencia de base

Aunque en la teoría tanto procedimientos como funciones son objetos reutilizables de código T-SQL, en la práctica se comportan de forma muy distinta, sobre todo cuando hablamos de rendimiento, transaccionalidad, side effects y cómo se integran en una consulta.

Un procedimiento almacenado (Stored Procedure) es una secuencia de instrucciones T-SQL que se ejecuta como un bloque, puede devolver conjuntos de resultados, manejar errores, abrir y cerrar transacciones y, en general, actuar con bastante libertad. Como un EXEC.

Una función (Function), por otro lado, devuelve siempre un valor. Puede ser escalar (un solo valor) o con valores de tabla (inline o multisentencia). Se puede usar dentro de consultas como si fuera una expresión más. Y ahí empiezan los problemas.

Procedimientos almacenados: el «hombre para todo» de SQL Server

Los procedimientos almacenados llevan décadas siendo el núcleo de la lógica de negocio en la base de datos. Y aunque ahora todo el mundo quiere microservicios, orquestadores y que “la lógica viva fuera del SQL”, lo cierto es que los procedimientos siguen siendo una herramienta potentísima.

Pueden contener lógica compleja, trabajar con múltiples tablas, ejecutar DML (INSERT, UPDATE, DELETE), manejar cursores (sí, también hay gente que todavía los usa), y lo más importante: pueden tener efectos secundarios. De hecho, están pensados para eso.

Además, permiten declarar variables, manejar errores con TRY…CATCH, lanzar mensajes de error personalizados con RAISERROR o THROW, abrir transacciones, hacer ROLLBACK, hacer COMMIT, y todo esto mientras devuelven múltiples conjuntos de resultados si hace falta. No es elegante, pero es potente. Como un martillo neumático.

Funciones: elegantes, encapsuladas… y peligrosas

Las funciones escalar (Scalar-valued Functions, SVF) son atractivas. Parecen limpias, reusables, encapsulan lógica, se integran perfectamente en consultas… y luego te destruyen el rendimiento. Así, sin más.

El problema es que las SVF tradicionales se evalúan por cada fila de la consulta donde se usan. Y no, no se «inlinean» automáticamente (al menos no hasta SQL Server 2019 con INLINE y aún así, con limitaciones). Esto significa que si tienes una tabla con 10 millones de filas y usas una función escalar en el SELECT, estás ejecutando esa función… 10 millones de veces. Lo que se dice un plan brillante.

¿Y las funciones con valores de tabla? Aquí hay dos tipos: las inline TVF (Returns Table) y las multisentencia (Returns @Table con BEGIN…END). Las inline funcionan como una vista parametrizada, y eso está bien. Se comportan bien con el optimizador. Las multisentencia, en cambio, generan estimaciones de cardinalidad basura y planes horribles, porque el optimizador no tiene ni idea de lo que pasa dentro. Pero tú tampoco, así que estáis empatados.

Principales diferencias técnicas y funcionales

A nivel práctico, aquí van algunas diferencias que conviene no olvidar cuando te enfrentas al dilema función vs procedimiento:

  • Un procedimiento no se puede usar en un SELECT. No devuelve un valor directamente. Se ejecuta con EXEC.
  • Una función no puede tener side effects: no puede modificar datos (excepto si es una CLR, que eso es otra historia). Tampoco puede llamar a procedimientos, usar TRY…CATCH, ni realizar cambios en el estado de la base de datos.
  • Las funciones escalar tradicionales matan el paralelismo de las consultas y generan estimaciones de coste que parecen salidas de un generador aleatorio.
  • Los procedimientos pueden devolver múltiples conjuntos de resultados. Las funciones no.
  • El plan de ejecución de una función escalar no se ve dentro del plan de ejecución de la consulta (hasta SQL Server 2019 sin INLINE). Así que diagnosticar problemas es como hacer cirugía a ciegas.
  • Las funciones inline TVF sí se comportan bien en los planes de ejecución, porque se expanden como si fueran vistas. Y eso las hace usables en entornos serios.

Rendimiento: el gran elefante en la sala

Nadie crea funciones para que vayan lentas, pero casi todas acaban siéndolo. La causa es bien conocida: cada ejecución de una función escalar es un contexto separado. Si haces un SELECT que usa una función escalar sobre una tabla de millones de filas, estás pidiendo al motor que salte de contexto millones de veces. En vez de vectorizar el acceso, va fila a fila. Y sí, esto se nota.

En cambio, un procedimiento bien diseñado que trabaje con conjuntos puede procesar la misma lógica de forma mucho más eficiente. Y, sobre todo, puedes verlo venir en el plan de ejecución. No te lo oculta como si fuera un secreto de Estado.

Desde SQL Server 2019 se introdujo la inlining de funciones escalares (Scalar UDF Inlining) para funciones marcadas como SCHEMABINDING, sin lógica demasiado compleja y sin referencias a objetos no deterministas. Pero si la función tiene más de una variable o usa GETDATE(), ya estás fuera del juego.

Así que sí, puedes confiar en la mejora… pero más te vale leer la letra pequeña.

Casos de uso típicos (sin liarla)

Entonces, ¿cuándo usar uno y cuándo otro? Vamos al grano.

Usa procedimientos almacenados cuando necesitas lógica compleja, efectos secundarios, manejar errores, o quieres ejecutar bloques de operaciones que se comporten como transacciones. Ideal para llamadas desde aplicaciones, cargas ETL, tareas programadas, o cualquier situación donde el código no esté embebido en un SELECT.

Usa funciones inline con valores de tabla cuando necesites lógica reutilizable que se integre en consultas y no afecte negativamente al rendimiento. Si puedes expresarlo como una única SELECT y devolver una tabla sin BEGIN…END, adelante. Son tus amigas.

Evita funciones escalares tradicionales en cualquier sitio donde importe el rendimiento. O al menos, haz pruebas serias antes de meterlas en producción y que te explote todo el lunes por la mañana.

La trampa de la reutilización mal entendida

Una de las razones por las que se abusa de las funciones es el deseo de reutilizar lógica. Loable, pero mal ejecutado. Si una función contiene una consulta pesada que se va a ejecutar por cada fila, lo que tienes no es reutilización, es una trampa mortal.

A veces es mejor duplicar una expresión compleja dentro de dos consultas que encapsularla en una función escalar. Lo segundo parece más limpio, sí. Pero cuando empiecen las quejas de rendimiento, lo primero será más fácil de optimizar.

La clave está en saber cuándo sacrificar limpieza por control. Y no siempre la opción «bonita» es la correcta.

Conclusión

La diferencia entre procedimientos almacenados y funciones no es solo cuestión de sintaxis, sino de mentalidad. Si quieres control, potencia y libertad, usa procedimientos. Si necesitas expresividad dentro de consultas y sabes lo que estás haciendo, usa funciones inline. Pero si tu objetivo es reutilizar lógica sin entender el coste, acabarás con un sistema lento, opaco y lleno de problemas difíciles de rastrear.

Y si aún dudas, recuerda esto: un procedimiento bien hecho es un aliado; una función escalar mal usada es una bomba de relojería con apariencia de buen código. Tú decides qué prefieres tener en tu entorno.

Publicado por Roberto Carrancio en Cloud, SQL Server, 0 comentarios
01
Oct
2025

Sargabilidad: el arte de no cabrear al optimizador

En SQL Server hay conceptos que separan al junior entusiasta del profesional que ha pasado noches enteras mirando planes de ejecución con el ceño fruncido. La sargabilidad es uno de ellos. Es esa palabra fea que no encontrarás en la RAE, pero que puede hacer que tus consultas vuelen… o se arrastren como un SELECT * sin índice por una tabla de 500 millones de filas.

Si llevas tiempo escribiendo T-SQL y nunca te has parado a pensar en si tus consultas son sargables o no, probablemente estés dejando rendimiento encima de la mesa. Y si trabajas con datos en serio, sabes que eso es inaceptable.

Qué es la sargabilidad (de verdad)

Sargabilidad viene del acrónimo SARG: Search ARGument-able. Es decir, que el motor de base de datos puede usar un índice para resolver la consulta de forma eficiente, sin escanear toda la tabla como si no hubiera mañana.

En SQL Server, una consulta es sargable cuando el predicado (la condición del WHERE, JOIN, HAVING, etc.) puede aprovechar un índice para filtrar datos directamente, sin tener que procesar fila por fila. En otras palabras: si el optimizador ve que puede usar un índice de forma directa, lo hará. Si no, te prepara un bonito Index Scan o Table Scan con aroma a cuello de botella.

Un ejemplo básico:

  • Sargable
SELECT COUNT(1) FROM USERS WHERE DisplayName = 'Juan';
  • No sargable
SELECT COUNT(1) FROM USERS WHERE LEFT(DisplayName, 4) = 'Juan';
Sargabilidad 1

La diferencia es simple pero letal. En el primer caso, SQL Server puede usar un índice sobre la columna Nombre. En el segundo, como le has puesto una función encima, el optimizador no puede buscar directamente. Tiene que aplicar la función a cada fila y luego comparar. Y claro, eso escala tan bien como un script que hace DELETE sin WHERE.

Las funciones son el enemigo (cuando no sabes usarlas)

El caso anterior ilustra la regla de oro de la sargabilidad: si transformas la columna del predicado, estás condenado a un escaneo. Las funciones como LEFT, SUBSTRING, CONVERT, DATEDIFF, COALESCE o incluso simples operadores matemáticos, rompen la posibilidad de usar índices si se aplican sobre la columna.

Veamos otro clásico:

SELECT COUNT(1) 
FROM Posts 
WHERE YEAR(CreationDate) = 2010

Esto es tan común como ineficiente. Lo correcto sería:

SELECT COUNT(1)
FROM Posts
WHERE CreationDate BETWEEN ‘20100101’ AND ‘20101231’

Y sí, es más feo. Pero el plan de ejecución será infinitamente más feliz. Y tú también, cuando no tengas que explicar por qué la consulta tarda 30 segundos con un índice que, supuestamente, estaba para eso.

Sargabilidad 2

ISNULL y COALESCE: los rompeíndices silenciosos

Uno de esos consejos que se repite como mantra en el mundo SQL es: «no uses funciones en columnas si quieres mantener la sargabilidad». Y, como todo buen mantra, es útil… pero no siempre cierto.

Tomemos el caso de ISNULL() y COALESCE(). Ambos permiten sustituir valores nulos por un valor por defecto. A efectos prácticos:

ISNULL(DisplayName, '') = 'Juan'
COALESCE(DisplayName, '') = 'Juan'

Parecen lo mismo, ¿no? Pero el optimizador de SQL Server no los trata igual. En la demo real que estás viendo, con un índice sobre DisplayName, la diferencia es cristalina.

Sargabilidad 3

ISNULL(): sorprendentemente sargable

Cuando usas ISNULL(DisplayName, ») = ‘Juan’, SQL Server aplica un Index Seek sin despeinarse. No le molesta la función. ¿Por qué? Porque el motor puede predecir exactamente lo que hace ISNULL() en este contexto: evalúa la columna, y si es NULL, la reemplaza por ». Como el predicado sigue siendo evaluable con un valor constante, puede derivarlo internamente como un predicado OR:

DisplayName = 'Juan' OR DisplayName IS NULL

Y esa es la clave. Porque si escribes ese predicado tú directamente, es igual de eficiente y, de paso, más claro:

SELECT COUNT(1) FROM USERS
WHERE DisplayName = 'Juan' OR DisplayName IS NULL;

Mismo Index Seek. Misma eficiencia. Pero sin necesidad de funciones.

COALESCE(): aquí sí se complica

Ahora bien, si usas COALESCE(DisplayName, ») = ‘Juan’, el plan cambia. SQL Server ya no puede garantizar que la expresión sea determinista y sencilla de evaluar. Más que nada porque podría haber más de dos argumentos o que el orden de evaluación tuviera implicaciones semánticas. El resultado: Index Scan.

Así que no, ISNULL() y COALESCE() no son intercambiables en el WHERE (importante esto) cuando te importa el rendimiento. En teoría devuelven lo mismo, en la práctica afectan al plan de ejecución de formas distintas.

El OR: ese sospechoso habitual

Otro rompe-sargabilidad por excelencia es el OR, que puede obligar a escanear incluso si una de las condiciones sí es sargable. Imagina esto:

SELECT * FROM Clientes
WHERE Nombre = 'Juan' OR Apellido = 'García';

A menos que tengas un índice compuesto que cubra ambas columnas, el optimizador suele rendirse y tirar de escaneo. 

Así que ya sabes, si usas con frecuencia este tipo de filtros con OR asegurate de tener un índice compuesto bien creado.

Las columnas calculadas como tabla de salvación

A veces no hay forma humana de evitar una función sobre la columna. En esos casos, una solución decente (aunque no milagrosa) puede ser usar columnas calculadas indexadas. Si sabes que todo el mundo va a seguir escribiendo:

SELECT * FROM Pedidos WHERE MONTH(FechaPedido) = 9;

Puedes añadir una columna calculada persistente:

ALTER TABLE Pedidos ADD MesPedido AS MONTH(FechaPedido) PERSISTED;
CREATE INDEX IX_Pedidos_MesPedido ON Pedidos(MesPedido);

Y ahora sí, el predicado puede ser sargable, porque la función ya se calculó y se indexó. No es magia negra, es simplemente darle al optimizador algo que pueda usar sin pensar.

El caso especial del LIKE

El LIKE también puede ser sargable o no, dependiendo del patrón. Esta es sargable:

SELECT COUNT(1) FROM USERS WHERE DisplayName LIKE 'Juan%'

Esta no:

SELECT COUNT(1) FROM USERS WHERE DisplayName LIKE '%Juan%'
Sargabilidad 4

Si el comodín está al principio, el índice no sirve. No puede buscar «desde» ningún valor. El patrón tiene que permitir una búsqueda por rango, como ‘Juan%’ o incluso ‘J%’. Todo lo demás se traduce en escaneo.

Aquí no hay mucha escapatoria salvo usar Full-Text Search si de verdad necesitas búsquedas internas. O pensar si realmente necesitas buscar así, que a veces el problema no es técnico sino de requisitos mal planteados.

Cuando CONVERT(DATE, datetime) sí es sargable (sí, lo has leído bien)

Aunque llevamos un buen rato diciendo, con razón, que aplicar funciones sobre columnas rompe la sargabilidad, hay una excepción curiosa (y bastante útil) que merece su propio rincón en este artículo: la conversión de un datetime a DATE usando CONVERT o CAST.

Mira este caso donde CreationDate es un campo DATETIME:

SELECT COUNT(*) FROM Posts
WHERE CONVERT(DATE, CreationDate) = '2010-06-05';

Lo lógico sería pensar: “acabo de meterle una función a la columna del WHERE, esto va directo a un Index Scan, ¿verdad?”. Pues no. SQL Server es capaz de usar un Index Seek, incluso con esa conversión.

¿Por qué? Porque el motor es más listo de lo que a veces creemos. Internamente, evalúa que convertir un datetime a date reduce la precisión pero no cambia la semántica de ordenación, y por tanto puede generar un predicado de rango equivalente: desde 2010-06-05 00:00:00.000 hasta justo antes del 2010-06-06. Si hay un índice sobre la columna CreationDate, lo usa. Sin mirar atrás.

Ahora bien: esto no lo convierte en buena práctica universal.

Porque si haces esto:

SELECT COUNT(*) FROM Posts
WHERE CONVERT(nvarchar(10), CreationDate, 103) = '05/06/2010';

El motor no te va a perdonar. Ahí sí hay Index Scan, porque ya estás forzando una conversión de tipo y de formato, y encima con ambigüedad regional. No hay forma de hacer un seek con eso.

Sargabilidad 5

Así que, como en todo, hay que ser precisos: CONVERT(DATE, datetime) es una excepción válida a la regla general, y SQL Server lo optimiza sin necesidad de escanear. Pero eso no quiere decir que cualquier CONVERT o CAST sea seguro.

JOINs y sargabilidad: el otro lado del desastre

La sargabilidad no solo importa en los WHERE. También afecta a los JOIN. Si haces cosas como:

SELECT * FROM A
JOIN B ON LEFT(B.Codigo, 5) = A.Prefijo;

Estás rompiendo toda posibilidad de usar un índice sobre B.Codigo. La función LEFT en el lado derecho del JOIN es como ponerle una venda en los ojos al optimizador. Y luego esperar que encuentre el camino solo. Mejor no.

Reescribe la lógica o introduce columnas auxiliares si hace falta, pero no pongas funciones en las condiciones de unión. A menos que tu hobby sea revisar planes de ejecución a las tres de la mañana.

Cómo detectar consultas no sargables

El mejor chivato es el plan de ejecución. Si ves Index Scan o Table Scan donde debería haber un Seek, es que tienes un problema de sargabilidad. También puedes usar las estadísticas de ejecución o SET STATISTICS IO ON para ver si se están leyendo más páginas de las que tocan.

Además, en SQL Server 2019+ puedes usar Intelligent Query Processing que, en algunos casos, mitiga errores de diseño como este… pero no es una excusa para escribir mal. Es un parche, no una solución.

Y si quieres una ayuda más visual, herramientas como SQL Sentry Plan Explorer o el propio SSMS con su plan gráfico te permiten ver rápidamente si estás tirando índices a la basura.

Scan no siempre es sinónimo de error (aunque duela admitirlo)

Otro punto clave: un Index Scan no siempre es el villano. Sí, lo hemos demonizado durante años, pero como todo DBA que ha peleado con planes de ejecución sabe, hay ocasiones en las que el escaneo es simplemente lo más eficiente.

Por ejemplo, si tu predicado devuelve un porcentaje alto de filas (pongamos, más del 25-30% de la tabla), al optimizador le puede salir más a cuenta ir a buscar los datos de una vez que intentar ser selectivo con un Seek y acabar con mil Key Lookup de regalo.

Lo mismo pasa cuando el índice cubre poco y el motor tendría que hacer lookups constantes para recoger el resto de columnas. En ese caso, el coste de los seeks individuales más los lookups supera con creces el coste de un buen escaneo. El optimizador no es tonto: elige lo que más conviene a nivel global de coste estimado.

Y aquí viene lo peligroso: si tu consulta está perfectamente escrita y sargable, pero el plan muestra un Scan, no asumas automáticamente que está mal. Revisa el plan, el número de filas estimadas, y el acceso a columnas. Lo que queremos evitar son los scans necesarios por diseño deficiente, no los que el motor elige porque son lo más razonable.

Conclusión

La sargabilidad no es un capricho del optimizador ni un tema menor. Es la base sobre la que se construye el rendimiento de cualquier sistema OLTP que merezca la pena. Ignorarla es como ir a una entrevista con el pantalón del pijama: técnicamente puedes, pero no deberías.

Escribir consultas sargables exige disciplina, conocimiento y cierta humildad. Hay que dejar de pensar en lo que «funciona» y empezar a pensar en lo que escala. Y cuando la diferencia entre una consulta sargable y otra que no lo es se mide en millones de lecturas lógicas… no hay excusa.

Así que la próxima vez que te enfrentes a un WHERE, piensa como el optimizador. No le pongas trabas, no le escondas la columna tras una función, y no le pidas milagros con predicados imposibles. Dale lo que necesita. Y si aún así se queja, entonces sí: culpemos al cardinality estimator.

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! 

Publicado por Roberto Carrancio en Cloud, Índices, Rendimiento, SQL Server, 0 comentarios
29
Sep
2025

¿Junior, Senior o “experto”? El teatrillo de los títulos

Pocas cosas generan más debate en una comunidad técnica que intentar definir qué significa ser junior, senior o experto. Bueno, quizás si un MERGE en producción está justificado… pero eso es otro tema del que ya hablaremos. Hoy vamos a hablar de galones o etiquetas, como queráis llamarlo, de cómo se reparten sin criterio y de por qué seguimos viendo ofertas para “junior con 3 años de experiencia” como si eso tuviera sentido alguno. Y es que para mí no lo tiene.

Junior no es sinónimo de becario

Vamos al grano. Un perfil junior no es alguien que no sepa nada. Es alguien que está empezando, sí, pero con una base ya formada, aunque sea mínima. No es un becario que necesita que le expliquen qué es un JOIN, pero tampoco es alguien que se siente cómodo optimizando una consulta compleja en un entorno con 3.000 conexiones simultáneas.

El problema es que muchas empresas confunden junior con “alguien barato que haga lo que un senior, pero por la mitad del sueldo”. Ahí vienen esas ofertas delirantes que piden de 1 a 3 años de experiencia, conocimiento de media docena de tecnologías, disponibilidad 24/7 y espíritu “proactivo”. Y todo eso, claro, a cambio de un salario que apenas supera al de prácticas. La trampa es evidente: quieren que hagas de todo, cobres poco y no te quejes. Si encima sonríes, mejor.

Pongamos un ejemplo concreto en nuestro terreno. El junior DBA es el encargado de realizar tareas totalmente procedimentadas sin salirse del guión. No se le puede exigir más. Es el que aún lanza un BACKUP DATABASE desde Management Studio, feliz de ver el mensaje de éxito, sin pensar en restaurarlo después para comprobar que realmente sirve. Y cuando falla, su primera reacción es: “pero si la copia terminó sin errores”. Es normal, es parte del camino, pero ahí está la diferencia.

Y ojo, no es que tener 2 o 3 años de experiencia te haga automáticamente senior. Ni mucho menos. Pero llamar junior a alguien que lleva 3 años comiéndose marrones de producción es no entender nada.

Logo SoyDBA

Únete a la newsletter de SoyDBA

Regístrate gratis para no perderte ninguna novedad. Te avisaré de noticias y eventos importantes

¡No hacemos spam! Lee nuestra política de privacidad para obtener más información.

Senior no es el junior que lleva más tiempo

La etiqueta de senior se ha convertido en una medalla que muchos se cuelgan demasiado pronto. Como si el calendario fuera el único juez válido. Y no. Ser senior implica haber visto cosas. Muchas cosas. Implica haber roto entornos, haberlos arreglado, haber tomado decisiones técnicas difíciles y haber lidiado con sus consecuencias. Ser capaz de evaluar el coste de una mala decisión antes de que reviente todo un domingo a las 3AM.

Un ejemplo de DBA senior: sabe que hacer un BACKUP no es suficiente, que hay que automatizar la validación de restauraciones, que conviene pensar en RPO y RTO antes de que el CTO lo pregunte, y que poner todos los backups en la misma SAN que la base de datos es tan útil como poner un extintor dentro del fuego. Además, cuando revisa un plan de ejecución, no se queda en el dibujito bonito: entiende qué decisiones está tomando el optimizador y sabe cuándo necesita una intervención manual.

No necesariamente dará la solución más elegante, pero sí una que funcione, que no comprometa la seguridad y que no mate el rendimiento del sistema. Porque un senior de verdad no solo sabe lo que hace, sino por qué lo hace. Y lo más importante: también sabe cuándo no hacerlo.

Las horas que se cuentan (o no se cuentan)

Aquí entra uno de los mitos más persistentes del sector: las dichosas 5.000 horas para ser senior, y las 10.000 para ser experto. Un concepto que hemos heredado casi como dogma y que muchos repiten como si fuera una verdad revelada. La famosa teoría de la práctica deliberada que, si alguna vez tuvo sentido en el contexto del violín o el ajedrez, se ha degenerado por completo en el mundo técnico.

Porque no, no basta con acumular horas para ser mejor. Si tu jornada consiste en encender el PC, abrir Management Studio y hacer lo mismo que hiciste ayer, anteayer y hace dos años, entonces lo que estás sumando no son horas de experiencia, sino horas de repetición. Y eso no te convierte en senior. Te convierte en alguien que sabe repetir procesos.

La práctica solo te lleva a la maestría cuando es desafiante, consciente y dirigida a mejorar. Si no hay errores, reflexión y aprendizaje, da igual cuántas horas pongas: seguirás en el mismo punto. He visto gente con 2.000 horas de trabajo real, bien guiado, bien sufrido y bien reflexionado, que vale más que otros con 15.000 horas de pulsar “Next” en el asistente de instalación.

Así que si alguien te dice que ya ha superado las 10.000 horas y por tanto es experto, pregúntale si puede explicarte qué hace exactamente el Cardinality Estimator en SQL Server o cómo se comporta el Query Store bajo una carga de lectura intensiva. Si pone cara de “eso no lo he tocado”, ya tienes la respuesta.

El mito del experto

Y luego están los expertos. Esa palabra maldita que ha perdido su valor en LinkedIn. Todo el mundo es “experto” en algo. Hay quienes se autodefinen expertos en SQL Server por haber creado 4 procedimientos almacenados, un par de vistas y haber leído la documentación de sp_whoisactive.

Aquí conviene diferenciar. Un experto funcional puede ser brillante operando un entorno concreto: conoce de memoria las rutinas de mantenimiento, maneja la seguridad de usuarios sin pestañear, y sabe cómo lidiar con el sistema en el día a día. Pero un experto técnico va un paso más allá: entiende las tripas, cómo funciona realmente el optimizador de consultas, cómo afectan las estadísticas al plan de ejecución, o por qué tu índice columnstore se viene abajo con ese patrón de inserción masiva.

Ambos perfiles son valiosos, pero no son lo mismo. Y lo que más abunda son los que creen que ser expertos funcionales les convierte en gurús universales. Y no es así.

Un experto de verdad también sabe cuándo callarse y escuchar. Porque cuanto más sabes, más consciente eres de lo que te queda por aprender. Así de simple.

¿Y los niveles intermedios?

Esto es algo que muchas organizaciones siguen sin entender. No todo el mundo entra en la categoría binaria de junior o senior. Hay una progresión natural, pero parece que da miedo nombrarla. Habría que hablar más de perfiles middle, semi-senior, advanced junior o como demonios queramos llamarlos, pero con definiciones claras y expectativas razonables.

Piénsalo en términos prácticos: un middle DBA ya ha gestionado despliegues, se ha peleado con deadlocks y sabe cómo monitorizar correctamente el entorno. No es alguien a quien quieras dejar al mando de una arquitectura distribuida en microservicios con réplicas en 4 regiones de Azure, pero tampoco es el novato que lanza un TRUNCATE en producción sin comprobar antes si hay backup.

La falta de estas categorías intermedias genera frustración. Los juniors que progresan se sienten estancados, y los seniors reales se queman porque tienen que apagar fuegos sin ayuda suficiente. Así que sí, necesitamos más niveles, pero sobre todo, más claridad y menos ego en las etiquetas.

La falacia de la experiencia acumulada

Este es otro punto clave. Tener 5 años de experiencia no significa nada si has pasado esos 5 años repitiendo el mismo trabajo que hacías el primer mes. Lo que tienes entonces no son 5 años de experiencia, sino 1 mes de experiencia repetido 60 veces. Y eso, lo siento, no es lo mismo.

La experiencia que cuenta es la que desafía, la que te obliga a aprender algo nuevo, a tomar decisiones, a equivocarte y mejorar. Si tu trabajo durante años ha sido ejecutar tareas repetitivas en una base de datos que ni siquiera entiendes, difícilmente puedes reclamar el título de senior.

Y sí, esto pasa más de lo que creemos. Entornos donde la innovación técnica es nula, donde todo se hace igual “porque siempre ha funcionado”, y donde el único cambio en cinco años ha sido cambiar de proveedor de café. Luego llega alguien con 2 años en un entorno exigente y en 6 meses demuestra más criterio que tú. Duele, pero es real.

Entonces, ¿cómo se pasa de junior a senior, y de senior a experto?

Pasar de junior a senior requiere algo más que cumplir con lo que te encargan durante mucho tiempo. Hacer backups, monitorizar jobs o ejecutar scripts que te da otro está bien, pero no es suficiente. El salto se produce cuando empiezas a cuestionar lo que haces, a entender por qué se hace de una manera y no de otra, y a proponer alternativas. Un junior ejecuta. Un senior piensa y decide. Ese cambio de chip no viene solo con las horas, viene con iniciativa y curiosidad técnica.

Si eres junior, ten iniciativa. Pégate a los senior y a los expertos, y que te expliquen lo que hacen y por qué. Cuando escales una incidencia, pregunta si puedes participar en la solución. No siempre la carga de trabajo lo va a permitir, pero cuando se pueda, la mayoría de los buenos profesionales estarán encantados de explicarte las cosas. Y créeme: no tengas miedo a preguntar. Nadie que merezca la pena tiene miedo a que aprendas y le quites el trabajo. Al contrario: queremos que mejores para que puedas hacer más cosas tú, y nosotros podamos vivir mejor. Porque un equipo fuerte se construye compartiendo, no guardando secretos como si fueran recetas de la abuela.

Luego está el paso de senior a experto. Aquí la cosa se complica, porque ya no se trata solo de resolver problemas en tu día a día, sino de anticiparlos. El experto sabe detectar patrones, entender tendencias y diseñar sistemas para que el fuego no llegue a prenderse. Y, además, sabe explicarlo a otros. Porque si no eres capaz de transmitir tu conocimiento, tu “expertise” se queda en ego. Un verdadero experto enseña, documenta, comparte. Ahí está parte de la diferencia.

¿Y hace falta dar un “extra” fuera del trabajo? Seamos claros: sí. Si te limitas a lo que ves en tu jornada laboral, avanzarás, pero despacio, muy despacio. El que llega más lejos es el que dedica tiempo a seguir estudiando, probando, rompiendo cosas en entornos de pruebas, leyendo papers, explorando novedades y enfrentándose a problemas que quizás no le toquen aún. La gente que crece es la que tiene curiosidad más allá de su checklist diario.

Ojo, tampoco se trata de romantizar las jornadas interminables de autoestudio como si fueran la única vía. No es sano ni sostenible trabajar 8 horas y estudiar otras 8. Pero la realidad es que los mejores profesionales que he conocido no apagaban el ordenador al terminar de trabajar y se olvidaban de todo. Seguían investigando, aunque fuera con un proyecto personal, un curso puntual o trasteando con la última versión de SQL Server en una máquina virtual.

Con todo esto, ¿qué valor tiene realmente una etiqueta?

La respuesta honesta es, depende de quién la use y para qué. Para muchos reclutadores es simplemente un filtro. Algunos managers se lo toman como una excusa para pagar menos. Para los técnicos, un arma de doble filo: puede abrirte puertas o hacer que te pidan milagros.

Pero hay algo que no cambia: los títulos no te salvan cuando el clúster se cae, cuando hay que restaurar un backup sin dormir o cuando el rendimiento se desploma sin motivo aparente. En esos momentos, solo cuenta lo que sabes hacer. Y lo que sabes transmitir.

Porque si algo he aprendido después de más de una década en este mundo, es que el respeto profesional no se gana con etiquetas, sino con hechos. Con decisiones acertadas bajo presión, con humildad para reconocer errores y, sobre todo, con ganas de seguir aprendiendo aunque tengas el CV lleno de palabras bonitas.

Y aquí viene la idea final: ser junior, senior o experto no es un estado fijo. Es un proceso continuo. Hoy puedes ser senior en SQL Server 2019, pero si dejas de aprender, mañana serás el que se quedó atascado en técnicas de hace una década. El mercado no espera a nadie, y el conocimiento tampoco.

Conclusión

Las etiquetas junior, senior y experto seguirán existiendo, pero lo importante es no tomárselas demasiado en serio. Sirven como orientación, sí, pero no son la verdad absoluta. Mucho menos en un sector donde el conocimiento evoluciona a la velocidad del rayo y donde lo que hoy dominas, mañana está obsoleto.

Así que, la próxima vez que alguien te diga que es senior porque ha superado las 5.000 horas, o experto por las 10.000, recuerda que también hay quien cree que el MERGE bien hecho existe. Nosotros no lo hemos visto. Pero tampoco hemos visto unicornios.

Publicado por Roberto Carrancio en Otros, 2 comentarios
26
Sep
2025

Opciones de Quorum para un clúster Always On

Sí, lo sé. Esto no va de índices columnstore ni de Extended Events sacando fuegos artificiales ni nada propiamente de bases de datos. Esto va de Quorum. Ese componente del clúster de Windows que muchos DBAs miran de reojo con la misma ilusión con la que uno revisa un log de errores a las 6 de la mañana. Pero si te metes en el barro de Always On, más te vale entender cómo funciona. Porque si el Quorum no está bien configurado, tu clúster puede caerse por una tontería. Y no, no da igual poner un disco o un voto más aquí o allá. Aquí no venimos a improvisar.

Este artículo no es tanto de SQL Server como de administración de sistemas, pero es un conocimiento que cualquier DBA serio necesita tener controlado. No porque vayamos a montar los clústeres a mano (que también), sino porque cuando empiecen los problemas, nadie va a buscar al sysadmin de guardia. Primero te van a buscar a ti.

El Quorum no es una opinión

Primero, vamos al grano: ¿qué demonios es el Quorum y por qué nos debería importar?

El Quorum es un mecanismo que usan la mayoría de los clúster, incluido el de Windows Server (WSFC, Windows Server Failover Cluster), para decidir si puede seguir funcionando. No estamos hablando de algo estético. Si el clúster pierde el Quorum, se apaga. Así de simple. O, peor aún, se divide y entra en split-brain, ese estado esquizofrénico donde dos nodos piensan que son los jefes, pero en realidad nadie manda. Un poco como algunas reuniones entre directores de distintos departamentos.

Así que no, el Quorum no es un «detalle más». Es un componente crítico del diseño. Y en el caso de Always On Availability Groups, que se basan en WSFC, ignorarlo es como montar un Ferrari y pasar de los frenos.

Tipos de Quorum en WSFC

Windows Server ofrece varias configuraciones de Quorum. Cada una con sus ventajas, sus pegas y sus peligros ocultos. No son intercambiables ni da igual cuál elijas. Vamos a repasarlas, una a una.

Node Majority (Mayoría de nodos)

Es el más sencillo, cada nodo tiene un voto, y si más de la mitad están activos y comunicados, el clúster sigue funcionando. Normalmente se usa en entornos con número impar de nodos (3, 5…). Es el ideal cuando todos los nodos están en el mismo datacenter o con conexiones fiables.

Su principal ventaja es su simplicidad de configuración, no necesita recursos compartidos adicionales y mantiene la alta disponibilidad mientras haya mayoría.

El inconveniente es que en un clúster con número par de nodos, el riesgo de perder Quorum por una simple caída es real. Además no escala bien para entornos geográficamente distribuidos.

Si montas un clúster de 2 nodos con esta configuración, estás invitando a que se caiga con solo un reboot. Lo llaman “configuración de alto riesgo”.

Node and Disk Majority (Mayoría de nodos y disco testigo)

Aquí añadimos a los nodos un testigo en forma de disco compartido (usualmente un LUN en un SAN), que también vota. Es perfecto para evitar empates en clústeres con número par de nodos. Se usa mayoritariamente cuando tiene clústeres con número par de nodos en el mismo datacenter.

Sigue siendo fácil de configurar si tienes un SAN compartido y evita el split-brain. 

El problema es que el disco es un punto de fallo más. Si falla el disco y un nodo, te vas al suelo. Y si hablamos de Always On con réplicas distribuidas en varios sitios, esta opción no aplica.

¿Un único punto de fallo en una configuración de alta disponibilidad? Brillante.

Node and File Share Majority (Mayoría de nodos y recurso compartido)

En este caso sustituimos el disco testigo por un File Share Witness (FSW), alojado en un servidor accesible por red. No necesita almacenamiento compartido, solo conectividad SMB. Su uso está extendido entre clusters distribuidos o donde no hay almacenamiento compartido disponible.

Es flexible y fácil de montar y, cómo no dependes de un SAN, es ideal para Always On entre sitios.E inconveniente es que el recurso compartido debe estar SIEMPRE disponible y accesible desde todos los nodos. Si cae la conectividad, puede hacer más daño del que parece.

Sí, ese FSW que “nadie sabe muy bien dónde lo pusimos” puede ser lo que decida si tu clúster sobrevive o se apaga. Más vale que esté monitorizado.

No Majority: Disk Only (Solo disco)

Aquí no hay mayoría. El disco decide. Y si el disco falla, adivina qué más falla.

¿Cuándo se usa? La respuesta correcta es NUNCA. O, como mucho, en entornos de laboratorio. No hay excusa para usar esta configuración en producción.

Como ventajas de este tipo de Quorum podríamos destacar NINGUNA y como inconvenientes TODOS: Alta fragilidad, nula tolerancia a fallos. No compatible con Always On.

Si ves esto en un entorno real, haz un RDP al nodo, abre un bloc de notas y escribe tu carta de despido preventivo.

Votos, pesos y cómo romper el clúster sin querer

No basta con elegir el tipo de Quorum. También hay que entender cómo se distribuyen los votos. Cada nodo, por defecto, tiene un voto. Pero puedes ajustar manualmente qué nodos votan. Y también puedes decirle al testigo (FSW o disco) si vota o no.

Esto es útil, pero también peligroso. Quitar votos a la ligera puede provocar que el Quorum se pierda con menos fallos de los que imaginas. Y confiar ciegamente en que “Windows lo ajusta solo” es un camino directo al caos. WSFC puede hacer ajustes automáticos, sí, pero no es infalible. El clúster no tiene bola de cristal.

¿Un ejemplo real? Un clúster de 4 nodos con dos en cada datacenter y un FSW mal ubicado. Si cae la conectividad entre sitios y el testigo queda del lado equivocado, puedes perder todo. Porque, como en las películas malas, gana el lado que tenga más votos. Aunque no tenga la base de datos principal.

Always On y el testigo olvidado

En los grupos de disponibilidad de Always On, mucha gente se obsesiona con los réplicas, los listeners, las rutas de red… y se olvidan del Quorum. Error.

Una réplica en modo síncrono con failover automático NO te sirve de nada si el Quorum no se mantiene en caso de caída. La réplica puede estar perfecta, lista para levantar el grupo, pero si el clúster ha perdido el Quorum, no se produce el failover. Porque el WSFC está abajo. Fin.

Por eso, en entornos con réplicas distribuidas geográficamente, el testigo (FSW) debe estar ubicado estratégicamente. Idealmente, en un tercer sitio con conectividad simétrica. Si no puedes, al menos asegúrate de que el Quorum esté configurado con cabeza.

Y no, no pongas el FSW en uno de los nodos del clúster. No es que vaya a fallar, pero síes una muy mala idea. Es como guardar las llaves de la caja fuerte… dentro de la misma caja.

Casos típicos y cómo configurarlos bien

A modo de ejemplo vamos a repasar las configuraciones más recomendadas en los escenarios más comunes.

  • Clúster de 2 nodos en el mismo datacenter: Node and File Share Majority. FSW en un servidor externo y altamente disponible. Nada de ponerlo en uno de los nodos.
  • Clúster de 3 nodos: Node Majority. Número impar, no hace falta testigo, salvo que tengas paranoia (bien justificada). Si los tres nodos están en ubicaciones distintas, replantéate la estrategia.
  • Clúster con réplicas entre datacenters: Node and File Share Majority. FSW en una tercera ubicación. Y no, “la nube” no es una tercera ubicación si no tienes garantizada la conectividad.

Conclusión

Como muchas cosas en administración de sistemas, el Quorum es esa parte invisible que solo duele cuando falla. Pero cuando falla, duele de verdad. Si gestionas entornos con Always On y no entiendes bien cómo se comporta el Quorum, estás conduciendo a ciegas. Y algún día, te vas a estrellar.

No hace falta que seas un experto en WSFC, pero necesitas saber cómo se configura el Quorum, cómo afecta a la disponibilidad real de tu clúster y, sobre todo, cómo evitar caer en las trampas típicas. Porque no, Always On no lo gestiona “todo solo”. Tú sigues siendo responsable de que el clúster se mantenga vivo. Y para eso, el Quorum es tu piedra angular.

Así que la próxima vez que montes un clúster, o revises uno existente, pregúntate: ¿está el Quorum bien diseñado o estoy viviendo con una bomba de relojería? Porque en producción, el Quorum no perdona.

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! 

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 0 comentarios