cloud

Nov

2025

El hardware se abarata, el licenciamiento de SQL Server no

Hace poco me compré un portátil nuevo. Un equipo serio, de esos con más núcleos que sentido común y potencia suficiente para levantar sin despeinarse un entorno de desarrollo completo con SQL Server, BI y lo que se le ponga por delante. Vamos, lo que necesito para las demos en los eventos. Precio: unos 2000€. Hasta aquí, todo bien.

Pero al mirar los procesadores disponibles (Ryzen con 16 o 24 núcleos, Intel con 20 y más RAM que la que tenía tu último servidor físico en producción) no pude evitar pensar: si alguien quiere usar esto para algo serio, ¿cómo lo licencia?

Y ahí es donde empieza el problema. Porque el precio del hierro ha bajado, pero el coste del licenciamiento de SQL Server sigue atascado en 2012. O antes.

El espejismo de la democratización

Nos han vendido la moto de que la informática se ha democratizado, que cualquiera puede montar un sistema potente por poco dinero, que digitalizarse es barato. Y en parte es verdad… hasta que levantas la alfombra del licenciamiento.

Cualquier pyme, autónomo o pequeño despacho que hoy quiera informatizar su gestión (pongamos que por exigencias tan poco opcionales como VERIFACTU) probablemente lo hará con lo que tiene a mano: un PC sobremesa moderno, o a lo sumo una torre decente con componentes actuales. Las pequeñas empresas no tienen presupuesto para servidores.

El problema es que hoy incluso un sobremesa “modesto” puede tener un procesador de 16 núcleos físicos y 128 GB de RAM por menos de 1500€. Y en ese momento SQL Server te sonríe… con su sonrisa de tiburón.

SQL Server Standard: paga por core, sufre por diseño

Si quieres usar SQL Server Standard en producción, aunque sea solo para almacenar facturas y cuatro tablas más, y te vas al modelo de licenciamiento por núcleo, prepárate: cada core te cuesta unos 2000 dólares. Sí, da igual que tu software solo use un hilo. Pagas por el número de núcleos visibles al sistema operativo, no por el uso real.

Y aquí viene lo bueno: en un PC moderno que no sea una patata, lo normal es que haya 12, 16 o 24 núcleos físicos (con el doble de vCores). Haz números. Eso son 24.000, 32.000, 48.000 o más euros solo en licencias, sin contar soporte, copias, backups, ni nada más.

Lo que iba a ser una digitalización económica se convierte en un agujero financiero. Y claro, muchos acaban optando por soluciones “temporalmente tolerables” como usar la versión Express… hasta que chocan de frente con sus limitaciones.

Express Edition: demasiado limitada para tomársela en serio

Sí, SQL Server Express es gratuita. Pero su techo de 10 GB por base de datos, 1 GB de RAM utilizable por instancia y uso de un único core lógico la hacen útil para pruebas, no para operar un negocio que mínimamente se tome en serio sus datos.

¿Que quieres hacer informes? Prepárate para sufrir. ¿Que tienes un CRM o un ERP que genera logs o almacena históricos? En dos años estarás exportando datos a Excel para aligerar. ¿Que necesitas rendimiento? Olvídalo.

La Express está bien para entornos de aprendizaje o microproyectos. Pero no está pensada para escenarios empresariales reales, por pequeños que sean.

La trampa del licenciamiento Server + CALs

Aquí algunos intentan una vía alternativa: el modelo de licenciamiento Server + CALs. Y sí, puede ser más asequible si solo tienes unos pocos usuarios y no quieres pagar por cada core.

Pero Microsoft te pone dos límites claros con SQL Server Standard bajo este modelo:

Máximo 24 núcleos virtuales visibles.
Máximo 128 GB de RAM utilizables.

Y aquí volvemos al drama. Porque un PC de 2025, sin ser nada del otro mundo, puede traer más de 12 núcleos físicos que son 24 virtuales (vCores) fácilmente. Y cuando eso pasa, no puedes usar Server + CALs legalmente. Te obligan a licenciar por core, aunque no necesites ni el 10% de los recursos. Maravilloso, ¿verdad?

Y no, no puedes decir “bueno, entonces limito el uso de cores desde el BIOS o desde el sistema operativo”. Eso no es legalmente vinculante para Microsoft. Si la CPU física tiene 32 núcleos, los vas a pagar todos. Así funciona el modelo de licencias.

En la nube también duele: SQL Server frente a PostgreSQL

Alguien podría pensar: “Vale, el licenciamiento físico es duro, pero si me voy al cloud me quito ese problema de encima, ¿no?”. Bueno… no exactamente. En la nube sigue siendo caro, y en algunos casos, directamente ridículo.

Vamos con cifras reales y actuales, para no caer en sensaciones vagas:

En Azure, una base de datos SQL con 8 vCores cuesta unos 893 dólares al mes. En el mismo entorno, una base de datos administrada de PostgreSQL con 8 vCores cuesta 123 dólares al mes. No es una diferencia. Es un abismo. Con lo que pagas por SQL puedes montar 7 PostgreSQL distintos y aún te sobra para un par de backups con redundancia geográfica.

Y si nos vamos a AWS, el panorama no mejora. Una instancia RDS de SQL Server con 16 vCores y 64 GB de RAM (db.m5.4xlarge) cuesta alrededor de 7.100 dólares mensuales. Sí, has leído bien: más de siete mil dólares al mes. Mientras tanto, la misma configuración con PostgreSQL cuesta 2.423 dólares mensuales. Casi tres veces menos.

Lo importante aquí no es solo el número. Es lo que implica: SQL Server no escala bien en costes. A mayor capacidad, mayor diferencia, y no precisamente a favor. PostgreSQL, en cambio, mantiene un coste racional y predecible, lo que lo hace mucho más viable en entornos que necesiten crecer sin hipotecarse.

Esto deja muy claro por qué tantos arquitectos de datos y CTOs están migrando workloads al open source. No porque les guste complicarse la vida, sino porque el presupuesto manda. Cuando el coste de mantener una base de datos supera al de todo el resto de la arquitectura, hay un problema, y no es técnico.

¿Qué opciones de licenciamiento tiene una pyme? Pocas, y ninguna es buena

Después de todo lo dicho, lo razonable es preguntarse: “¿Qué hago si necesito SQL Server, tengo un hardware moderno y no quiero fundirme el presupuesto en licencias?”

Pues no tienes muchas alternativas, realmente no hay una opción buena, solo algunas menos malas.

Primera opción de licenciamiento: SQL Express

Esta es la más obvia, SQL Express es gratis, sí, pero está muy limitada. Para empresas pequeñas con muy pocos datos puede ser una opción pero siempre con la vista puesta en sus límites. No solo hablo del hardware, que ya impone unos límites considerables (solo usa 4 vCores, 1 Gb de RAM y las bases de datos no pueden superar los 10Gb), sino que le faltan muchas características como el agente de SQL Server, SSIS, SSAS, etc…

Aunque también es cierto que seguramente no necesites las aplicaciones de ETL o analítica y que la limitación del agente la puedas salvar ejecutando SQLCMD con tareas programadas en el programador de tareas de windows.

Segunda opción de licenciamiento : Licencias Server + CAL

La segunda opción es licenciar tu SQL Server Standard por Server + CALs… si puedes. Esto solo aplica a SQL Server Standard y si tienes un número limitado de usuarios bien controlado. Y no se aplica a entornos públicos, web apps o APIs abiertas. Si tu escenario es cerrado y sabes exactamente cuántos usuarios acceden, podría salirte más barato, unos 900€ la licencia del servidor SQL Server. Pero cuidado, porque CALs también cuestan y hay que contarlas bien, cada usuario que se conecte necesitará su CAL de aproximadamente 200€.
Pero recuerda, esta opción solo es posible si tu máquina tiene menos de 24 vCores. Y si te preguntas si puedes crear una máquina virtual con menos vCores para ahorrar dinero tengo una mala noticia, no es tan sencillo.
Para el licenciamiento de máquinas virtuales Microsoft exige licenciar todos los vCores de la máquina física así que estaríamos en las mismas. Por suerte hay un clavo ardiendo al que puedes agarrarte, es posible licenciar solo los vCores de la máquina virtual si, y solo si, contratas Software Assurance (SA). Este servicio es una suscripción de pago anual que te da derecho, además de a pagar solo por los vCores de la VM, a actualizaciones de versiones de SQL Server. Lo malo es que aquí no podemos hablar de precios, Microsoft no los comparte y tendrás que negociarlos con tu partner de licencias (suele costar anualmente entre un 20 y un 30% del coste de las licencias).

Tercera opción de licenciamiento: Cloud y pago por uso

Ya hemos visto que el coste de la nube no es barato, aun así, el pago mes a mes puede ser más fácil de asumir que el desembolso total de las licencias de una sola vez. Además, si tienes pocos requisitos de recursos, en Azure hay bases de datos sin servidor desde 5€/mes, con unos recursos muuuuy limitados, claro.

Quedaría otra opción, abandonar SQL Server y mirar a la competencia pero eso ya no es tan sencillo, al menos para proyectos o desarrollos existentes. Oracle no es una opción, su coste por licencia es también por core y cuesta más del doble que SQL Server, pero no es la única alternativa.

PostgreSQL, MariaDB, o incluso SQLite: la fuga silenciosa

Cada vez más desarrolladores están abandonando SQL Server. No porque no funcione bien (que lo hace maravillosamente bien), ni porque no tenga features potentes (que las tiene geniales). Sino porque ya no es viable para ciertos escenarios.

PostgreSQL y MariaDB no imponen estas barreras. No cobran por core. Tampoco limitan la RAM. No te obligan a licenciar el procesador entero si solo usas dos hilos. Y, sinceramente, para el 80% de los casos de uso en empresas pequeñas, hacen el trabajo igual.

Eso si, que PostgreSQL o MariaDB no cobren por licencias no significa que sea gratis.

Porque cuando eliges PostgreSQL o MariaDB, te llevas el motor, pero no el soporte. Ni la monitorización. Ni el clúster. Tampoco la estrategia de backups. Ni la restauración en caliente. Todo eso hay que construirlo, mantenerlo… o pagarlo a una tercera empresa que lo haga.

Y aquí es donde muchas veces la factura no es tan diferente a SQL Server. Solo que el dinero no se va a Microsoft, sino a consultoras especializadas, soporte de terceros o a una inversión de tiempo interno brutal que acaba saliendo más cara de lo previsto.

También hay que reconocerlo, PostgreSQL tiene una curva de aprendizaje considerable, sobre todo si vienes de SQL Server. Lo que antes resolvías con Management Studio ahora implica línea de comandos, pg_dump, systemd, y a menudo, búsqueda en foros. Y que no te dé por hacer un clúster HA sin una herramienta externa, porque ahí es donde empiezas a pagar con sangre o con suscripciones.

Así que sí, hay motivos para migrar. Pero que no te vendan que todo es gratis. Porque no lo es. Y a veces, cuando te das cuenta, ya estás hasta el cuello de migración, y ni puedes volver atrás ni puedes pagar el camino nuevo.

Conclusión

La paradoja sigue ahí. El hardware moderno ha democratizado el acceso a CPUs potentes, pero SQL Server sigue licenciado como si cada core fuese un diamante. El resultado: una tecnología excelente, pero cada vez más difícil de justificar fuera de entornos que puedan asumir ese coste sin pestañear.

Las PYMEs, los autónomos y cualquier organización que pretenda informatizarse en serio sin vaciar su cuenta bancaria se topan con un muro invisible: el licenciamiento. Un muro que no distingue entre portátil, sobremesa o servidor, y que tampoco afloja si te mudas a la nube.

Y sí, SQL Server 2025 está en puertas, con la Release Candidate ya disponible. Pero no parece que el modelo de licencias vaya a cambiar. Ojalá me equivoque y Microsoft suba ese límite absurdo de 24 vCores para el Server + CAL. Pero no creo.

Mientras tanto, PostgreSQL y compañía siguen ganando terreno. No por ideología, sino por supervivencia económica.

Y si esto te parece exagerado, revisa tu próxima factura de Azure o AWS. O tu presupuesto para licencias on-prem. Verás que la exageración no está en el artículo. Está en el modelo.

Oct

2025

Especial Halloween. El marrón que todo DBA ha sufrido

¿Qué Halloween da miedo? Será para los que no han tenido que restaurar un backup en producción y estaba corrupto, con el jefe respirándoles en la nuca y un SLA expirando más rápido que el café enfriándose.

Los verdaderos horrores no salen en películas. Se ejecutan en nuestros servidores.

Si el año pasado nos pusimos nostálgicos para hablar del problema de Halloween original, hoy vamos a hablar de jobs fallidos, bloqueos eternos, desarrolladores con acceso a sysadmin, y scripts “probados en otro entorno”. Marrones que un DBA conoce muy bien. Marrones que no se borran con un ROLLBACK.

Definición técnica

MARRÓN (noun)

Término operativo usado en entornos técnicos para describir cualquier tarea, incidente o requerimiento que:

No estaba prevista.
Nadie quiere hacer.
Tiene alta visibilidad y cero documentación.
Requiere acción inmediata (generalmente ayer).
Y suele implicar que el culpable eres tú, aunque no tengas ni idea de qué ha pasado.

Roles asociados:

Enmarronador (BrownDispatcher): Individuo que asigna el marrón con una sonrisa, un café en la mano o un “esto es rápido”. Suele tener cargo, pero no responsabilidad.
Enmarronado (Browned): Víctima del proceso de asignación. También conocido como “el de SQL” o “el que sabe”. No necesariamente tiene culpa, pero sí marrón.
Buscamarrones (BrownFinder): Persona que se ofrece voluntaria “para aprender” o “echar una mano”. A menudo desaparece misteriosamente cuando el marrón explota.
Comemarrones (BrownEater): DBA veterano que se ha comido tantos marrones que ya solo le quedan dos emociones: resignación y café.

Importante:

Una vez asignado, el marrón es de tu propiedad exclusiva. No importa si lo originó otro, si viene sin especificaciones o si “funcionaba en dev”. El sistema ha hablado. Eres el enmarronado.

El marrón flotante: la petición que no llega (pero llegará)

Es lunes y alguien menciona “tenemos que mirar lo del rendimiento del ERP” mientras tú estás con otras 40 cosas. Nadie lo documenta, nadie lo asigna, pero ya sabes lo que va a pasar. Lo oyes flotar.

Un día (viernes a última hora, seguro) alguien abre un ticket con prioridad alta y asunto ambiguo: “Problema con SQL”. Ni reproducible, ni claro. Y para cuando llega a ti, ya eres el responsable. Del ERP. Del rendimiento. De todo.

Este marrón huele a cursores usados alegremente por algún genio que ha leído un blog equivocado. Y te va a tocar explicarlo. Otra vez.

El marrón fulminante: el «¿qué ha pasado?» a las 8:00

Son las 7:58. Te conectas. Parece que todo está tranquilo. Hasta que alguien grita por Teams: “¡la base de datos está caída!”

Miras los logs. Alguien reinició el servicio de SQL Server durante la noche. ¿Motivo? “Estaba lento y pensé que eso lo arreglaría, luego el servicio no se paraba y reinicié el servidor”.

No sabemos qué ha pasado, solo tenemos aplicaciones paradas y usuarios locos por los pasillos.

Y tú, desayunando con una base de datos de 25 Tb en recuperación.

Este es el marrón que se instala sin pedir permiso. Lo único que puedes hacer es ponerte los guantes de forense, y rezar para que pase cuanto antes.

El automarrón: lo hiciste tú, y lo sabes

Hay veces que el marrón no viene de fuera. Te lo cocinas tú solito.

Aceptaste esa migración “sencilla” de SQL Server 2012 a 2022. Te dijeron que solo había que mover “un par de bases”. Ahora estás descubriendo jobs con código T-SQL del pleistoceno, linked servers a dominios que ya no existen, y stored procedures que funcionan por magia negra.

Y todo tiene que estar listo este fin de semana. Por supuesto.

Es el automarrón. Y el problema no es el marrón. Es tu optimismo que te llevó a no mirar dos veces.

El marrón pata negra: ese proyecto que recordarás siempre

Hay marrones, y luego está ese proyecto que te cambió la vida. El que te hizo cuestionarte tus decisiones vitales.

Un data warehouse mal diseñado que hay que “reoptimizar”. Con cientos de tablas de millones de registros sin índices, y vistas anidadas que ya tienen su propio ecosistema. Con consultas que tardan horas y desarrolladores que te juran que “antes iba rápido”.

Es el marrón pata negra. No se arregla. Se sobrevive. Y si logras salir de ahí, probablemente acabarás con un tic nervioso… y un máster en tuning sin quererlo.

El marrón de última hora: el clásico de viernes tarde

Viernes, 14:59. Recoges. Cierra sesión. Y entonces… “oye, una cosilla antes de que te vayas”.

Spoiler: no es una cosilla.

Es un cambio en producción. Un script que nadie ha revisado. Un MERGE que te juran que va bien “porque lo hemos probado en dev”. Unos índices que hay que “crear rapidito” porque el CTO ha leído en LinkedIn que eso mejora el rendimiento.

Y tú, con el abrigo puesto, ejecutando con miedo un script que viene de un Excel. Bienvenido al marrón invocado. No saldrás antes de las 21:00. Si sales.

El marrón mutante: el que cambia cada día

Te asignan un problema de rendimiento. Miras. Optimización sencilla. Pones un índice. Va mejor.

Pero luego cambia el plan de ejecución. Luego te enteras de que han cambiado el MAXDOP sin avisarte. Luego la tabla crece un 300% de un día para otro. Y el problema vuelve. Peor.

El marrón mutante nunca termina. Hoy es CPU, mañana IO, pasado bloqueos. Intentas aplicar parches, pero no hay final. Es como dar soporte a una base que se autodestruye a diario y se recompone… peor.

Vives en un entorno hostil.

El marrón sonda: el disfrazado de consulta inocente

“Una duda rápida sobre un procedimiento que tarda un poco…”

Error. Ya estás dentro.

Empieza como una duda. Luego te piden revisar el plan. Luego optimizar. Luego reescribir. Luego hacer un informe. Luego… estás haciendo tú todo.

Los marrones sonda son los peores porque son invisibles. Te atrapan por empatía. No porque puedas decir que no, sino porque ya estás en medio. Y claro, ya que estás…

El pressing brown: presión en estéreo

Cliente cabreado. Jefe nervioso. Equipo de desarrollo esperando. Todos preguntan. Todos presionan.

Y tú, el DBA, recibiendo por todos lados. Con logs, sin contexto, y con el “esto no puede estar fallando, si no hemos tocado nada” como único diagnóstico.

Es el pressing brown. Nadie lo admite, pero todos lo han hecho: tirar el marrón al de bases porque “seguro que es algo del SQL”.

Y a ti te toca arreglarlo. Sin información. Sin culpa. Sin gloria.

El brown shower: todo cae a la vez

Backup corrupto. Alerta de disco. AG desincronizada. Login bloqueado. Limpieza de datos que ha borrado datos de más (a quien se le ocurre poner las FK con borrado en cascada…). El entorno ha dicho basta. Y todo a la vez.

Eso no es un marrón. Es un brown shower.

Cuando pasa, no arreglas. Contienes. Priorizas, sobrevives, y rezas porque el clúster no decida reiniciarse. Y si alguien pregunta cómo va todo, solo di: “controlado”, mientras lloras por dentro.

Conclusión: el terror real se ejecuta en SQL

Que sí, que Halloween da miedo. Pero no tanto como ejecutar un DELETE sin WHERE en la base de producción, o que el backup del FULL no incluya las bases más críticas.

Nosotros no necesitamos sustos. Ya los trae el trabajo.

Y recuerda: si un jefe te dice “es una tarea rápida”, asegúrate de tener a mano tu última copia del CV actualizado. Y una linterna. Porque se viene noche larga.

Feliz Halloween, compañeros de marrones. Que los browners pasen de largo… o al menos os pillen con un buen plan de contingencia.

Oct

2025

OPTIMIZED SP_EXECUTESQL: Novedad de SQL Server 2025

Con la llegada de SQL Server 2025, Microsoft introducirá una serie de mejoras orientadas a optimizar el rendimiento del motor. Una de ellas es la nueva configuración OPTIMIZED_SP_EXECUTESQL, pensada específicamente para entornos que hacen uso intensivo de SQL dinámico a través de sp_executesql. En este artículo profundizo en su funcionamiento, cómo activarla, qué impacto tiene en la caché de planes y cómo se comporta bajo carga concurrente.

Contexto: el problema con sp_executesql y el plan cache

Cuando ejecutamos consultas dinámicas con sp_executesql, especialmente en entornos con alta concurrencia, SQL Server puede compilar múltiples planes para lo que, conceptualmente, es la misma consulta. Aunque el texto del lote (batch text) sea idéntico y se usen parámetros, el compilador no siempre consigue identificarlo como la misma ejecución, lo que termina generando entradas repetidas en la plan cache.

Esto da lugar a varios problemas conocidos:

Bloat en la plan cache, con decenas o cientos de planes similares almacenados.
Consumo innecesario de CPU por compilaciones redundantes.
Contención en la compilación, cuando múltiples sesiones intentan compilar la misma consulta al mismo tiempo.

Con OPTIMIZED_SP_EXECUTESQL, SQL Server introduce un nuevo mecanismo para mitigar estos efectos.

¿Qué es OPTIMIZED SP_EXECUTESQL?

Se trata de una configuración a nivel de base de datos que se encuentra desactivada por defecto y que puede activarse mediante ALTER DATABASE SCOPED CONFIGURATION. Su objetivo principal es optimizar la forma en que SQL Server gestiona la compilación y almacenamiento en caché de planes asociados a ejecuciones de sp_executesql.

Cuando se activa esta opción, el comportamiento cambia significativamente:

La primera ejecución de un lote dinámico mediante sp_executesql compila el plan normalmente.
Otras sesiones concurrentes que ejecutan el mismo lote esperan a que finalice la compilación.
Una vez compilado, todas las sesiones reutilizan el mismo plan, del mismo modo que lo harían si fuera un procedimiento almacenado.

Requisitos y dependencias

Lo primero, obviamente, es tener SQL Server 2025 y tu base de datos en un nivel de compatibilidad 170. Además, si en tu base de datos tienes activada la opción de actualización automática de estadísticas, Microsoft recomienda habilitar también ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITY (más bien es un requisito pero, ¿has visto qué bien me ha quedado lo de “Microsoft recomienda”?). Esto asegura que el nuevo comportamiento no introduzca contención innecesaria durante las actualizaciones estadísticas, en escenarios de alta concurrencia.

Cómo activarlo

Para habilitar la funcionalidad, puedes ejecutar el siguiente bloque:

USE [TuBaseDeDatos];
GO
ALTER DATABASE SCOPED CONFIGURATION SET ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITY = ON;
GO
ALTER DATABASE SCOPED CONFIGURATION SET OPTIMIZED_SP_EXECUTESQL =ON;
GO

Recuerda, necesitas estar en nivel de compatibilidad 170 (SQL Server 2025) para que la opción sea válida.

Puedes comprobar el estado actual de la configuración con:

SELECT name, value, value_for_secondary
FROM sys.database_scoped_configurations
WHERE name IN ('OPTIMIZED_SP_EXECUTESQL', 'ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITY');

Demostración práctica

Vamos a ejecutar una serie de pruebas en una base de datos StackOverflow (modo de compatibilidad 170) para observar el impacto real de esta configuración en la plan cache.

Paso 1: Asegurar que la opción está desactivada

USE StackOverflow2010;
GO
ALTER DATABASE SCOPED CONFIGURATION SET ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITY = OFF;
GO
ALTER DATABASE SCOPED CONFIGURATION SET OPTIMIZED_SP_EXECUTESQL = OFF;
GO

Paso 2: Limpiar la caché de planes

DBCC FREEPROCCACHE;
GO

Paso 3: Ejecutar carga concurrente

Usaremos SQLQueryStress para lanzar la siguiente consulta, que ejecuta sp_executesql de forma concurrente:

DECLARE @sql NVARCHAR(MAX) = N'SELECT COUNT(*) FROM dbo.Posts WHERE PostTypeId = @PostTypeId AND Score > @Score';

DECLARE @params NVARCHAR(MAX) = N'@PostTypeId INT, @Score INT';

EXEC sys.sp_executesql @sql, @params, @PostTypeId = 1, @Score = 2000;

Parámetros en SQLQueryStress:

Iteraciones por hilo: 10
Número de hilos: 100

Esto generará 1000 ejecuciones concurrentes de la misma consulta dinámica.

Paso 4: Analizar la plan cache

Una vez completadas las ejecuciones, inspeccionamos el número de planes generados:

SELECT 
    qs.plan_handle,
    qs.sql_handle,
    qs.creation_time,
    qs.execution_count,
    st.text AS sql_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
WHERE st.text LIKE '%SELECT COUNT(*) FROM dbo.Posts%'
ORDER BY qs.creation_time DESC;

Resultado esperado (sin optimización): múltiples planes distintos (en pruebas reales, se observan entre 20 y 30 para este escenario), aunque la consulta sea la misma.

Esto evidencia el comportamiento ineficiente por defecto: múltiples planes para la misma carga.

Paso 5: Activar la optimización

USE StackOverflow;
GO
ALTER DATABASE SCOPED CONFIGURATION SET ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITY = ON;
GO
ALTER DATABASE SCOPED CONFIGURATION SET OPTIMIZED_SP_EXECUTESQL = ON;
GO

Paso 6: Limpiar de nuevo la caché

DBCC FREEPROCCACHE;
GO

Paso 7: Ejecutar la misma carga

Volvemos a lanzar los 100 hilos concurrentes con SQLQueryStress, exactamente como antes.

Paso 8: Analizar resultados

Ejecutamos de nuevo la consulta sobre la plan cache:

SELECT 
    qs.plan_handle,
    qs.sql_handle,
    qs.creation_time,
    qs.execution_count,
    st.text AS sql_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
WHERE st.text LIKE '%SELECT COUNT(*) FROM dbo.Posts%'
ORDER BY qs.creation_time DESC;

Resultado esperado (con optimización): una sola entrada en la caché de planes, con una execution_count acumulada de 1000. El compilador ha tratado la consulta dinámica como si fuese un procedimiento almacenado.

Este comportamiento elimina de raíz el bloat en la caché y evita la compilación paralela.

¿Qué hace SQL Server exactamente?

El mecanismo detrás de esta optimización replica el modelo clásico de los procedimientos almacenados:

La primera ejecución de una consulta concreta compila el plan.
El resto de ejecuciones esperan a que ese plan esté disponible.
Una vez compilado, todas las ejecuciones reutilizan ese mismo plan.

Este comportamiento garantiza una mayor eficiencia tanto en uso de CPU como en gestión de memoria. Ya no veremos un plan por cada sesión, sino un único plan compartido y referenciado por todas.

Consideraciones finales

Este cambio solo aplica a sp_executesql. No afecta a EXEC() ni a otros mecanismos de ejecución dinámica.

Las consultas deben ser realmente idénticas (texto y parámetros) para que se detecte la coincidencia.

Si tu aplicación genera SQL dinámico con pequeñas variaciones en los literales o estructura, el beneficio será menor.

La mejora se aprecia especialmente en entornos con alta concurrencia o patrones repetitivos.

Conclusión

OPTIMIZED_SP_EXECUTESQL es una de las mejoras más importantes en la gestión del plan cache que hemos visto en años. Su activación puede suponer una diferencia notable en servidores que sufrían problemas de rendimiento por exceso de compilaciones o saturación de memoria con planes efímeros.

Es una de esas configuraciones que, bien aplicada, no solo mejora el rendimiento, sino que permite aprovechar mejor los recursos existentes. No es una solución mágica, pero sí una herramienta eficaz para un problema conocido.

Si trabajas con aplicaciones que generan SQL dinámico intensivo y tienes pensado actualizar SQL Server 2025 cuando sea estable, este cambio debería estar en tu lista de tareas prioritarias.

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!

Oct

2025

Sinónimos en SQL Server. SQL Basics

No todos los objetos de SQL Server nacieron para ser usados con confianza ciega. Algunos tienen nombre de perfume barato y generan sensaciones parecidas. Hoy hablamos de los sinónimos, esos alias de objetos que pueden facilitarte la vida o clavarte una estaca en mitad de una migración mal hecha.

Los sinónimos (synonyms, si estás leyendo esto con el Management Studio en inglés) son una característica de SQL Server que permite crear un nombre alternativo para referenciar a un objeto, ya sea una tabla, vista, procedimiento almacenado o función. A primera vista suena bien. Evitas tener que escribir nombres de servidores, bases de datos y esquemas cada vez que llamas a algo remoto. Pero como todo en la vida, cuando lo haces demasiado fácil, el problema aparece justo después.

¿Qué es un sinónimo?

Los sinónimos permiten definir un alias a un objeto que puede estar incluso en otro servidor. Esto puede incluir tablas en bases de datos remotas, procedimientos almacenados en otras instancias, funciones en otro universo, etc.

Por ejemplo, puedes tener un sinónimo así:

CREATE SYNONYM ProductoExt 
FOR [ServidorRemoto].[BaseDatosRemota].[dbo].[Producto];

Y desde ese momento puedes hacer:

SELECT * FROM ProductoExt;

Sin preocuparte de toda la parafernalia de nombres largos y cuatro partes. Es cómodo, sí. Pero también estás metiendo debajo de la alfombra varias capas de dependencia, latencia y seguridad implícita.

¿Por qué usar sinónimos?

Vale, vamos a concederle al sinónimo su minuto de gloria. Hay casos en los que puede tener sentido.

Cuando trabajas con entornos donde los nombres de base de datos o incluso los servidores cambian con frecuencia (hola, entornos de desarrollo y preproducción mal organizados), usar sinónimos permite centralizar esos nombres en un solo punto. En lugar de cambiar 58 procedimientos almacenados, cambias un solo sinónimo. Bravo.

También son útiles cuando accedes a objetos remotos y no quieres estar repitiendo la ruta de cuatro partes cada vez. Si el enlace funciona y las credenciales no han caducado, puede parecer magia.

Y por supuesto, si estás trabajando con múltiples bases de datos y necesitas mantener cierto nivel de encapsulamiento o abstracción (palabra que aquí significa “hacer como que lo que depende de otro servidor no depende de él”), un sinónimo puede ayudarte.

Pero no te emociones.

Los problemas empiezan con la transparencia

El gran problema de los sinónimos es que precisamente no parece que estás accediendo a algo remoto.

Tú haces un SELECT * FROM ProductoExt y ni idea de que en realidad estás yendo a otro servidor, otra base de datos, o peor aún, a un servidor vinculado (linked server) que va a dar más vueltas que un sp_executesql dentro de un cursor.

Esa falta de visibilidad genera problemas muy reales:

Latencia inesperada. Estás accediendo a una tabla en otro continente y no lo sabías.
Errores de seguridad. ¿Quién tiene permiso en el objeto real? ¿Qué cuenta usa el servidor vinculado? ¿Tienes doble salto Kerberos bien configurado?
Fragmentación lógica. El código parece limpio, pero la traza de dependencias es un infierno.

Y como cereza del pastel: cuando algo falla, el mensaje de error puede ser tan claro como una excepción de .NET lanzada por un junior con prisa.

Rendimiento de los sinónimos

Vamos a dejar esto claro, usar sinónimos no introduce penalización de rendimiento por sí mismo. No hay sobrecarga, ni resolución dinámica, ni instrucciones mágicas de más. Un sinónimo es un alias, y el plan de ejecución generado es exactamente el mismo que si hubieras usado el nombre completo del objeto original.

Entonces, ¿dónde está el problema?

En que el sinónimo oculta la naturaleza del objeto que estás tocando. Puedes estar accediendo a una tabla local… o a una tabla en otro servidor a través de un Linked Server. Y como el nombre del sinónimo no da pistas, el riesgo es que estés haciendo una SELECT * a 10 millones de registros en remoto sin saberlo.

Esa opacidad puede llevar a errores de diseño y análisis, planificas como si accedieras a una tabla local, pero detrás hay un OLEDB pasando datos entre servidores. Y eso sí que es un problema de rendimiento, de los serios.

Además, al estar encapsulado como alias, el sinónimo puede dificultar el análisis del plan de ejecución, sobre todo cuando hay muchos niveles de indirección. No porque el plan sea distinto, sino porque hay que tirar del hilo hasta encontrar el objeto real.

Y no, los sinónimos no hacen caché de nada. Ni de la resolución del nombre, ni del esquema, ni del servidor remoto. Cada vez que los usas, se resuelve el nombre desde cero. Esto normalmente no es un cuello de botella, pero en entornos de alta concurrencia o con muchas referencias cruzadas, puede notarse. Poco, pero lo justo para volverse molesto.

Así que el sinónimo no penaliza, pero tampoco te avisa. Por eso conviene saber muy bien qué estás llamando, de dónde cuelga, y si realmente necesitas ese acceso encapsulado. Porque cuando el rendimiento se resiente, el sinónimo suele ser el último sitio donde alguien mira… y a veces es justo donde empezó el desastre.

¿Y la seguridad? ¿Qué podría salir mal?

En realidad, poco. O al menos, nada distinto a lo que ya puede salir mal sin sinónimos.

Porque, que quede claro por si no lo he dicho suficiente: un sinónimo es solo un alias. No altera cómo funciona la seguridad en SQL Server. Los permisos que necesita un usuario para acceder a un sinónimo son exactamente los mismos que si accediera directamente al objeto original con su nombre completo.

Si no tienes permisos sobre la tabla, vista o procedimiento al que apunta el sinónimo, obtendrás el mismo error que si usaras [Base].[Esquema].[Objeto] a pelo. Y si los tienes, funcionará. Punto.

Lo mismo aplica si el objeto está en otra base de datos: el login debe tener un usuario definido en esa base, con permisos suficientes. Y si el sinónimo apunta a un Linked Server, el control lo marca la configuración del servidor vinculado. Pero eso pasaría exactamente igual si accedieras con nombres de cuatro partes. No hay atajo, ni puerta trasera, ni cambio de contexto.

Lo único que realmente puede salir mal (y lo hace más de lo que parece) es que el objeto original cambie o desaparezca. El sinónimo no se entera de nada. Si el objeto cambia de esquema, se renombra o se elimina, el sinónimo sigue ahí, inerte, esperando a que alguien lo use… y falle. Porque SQL Server no valida los sinónimos en tiempo de creación, ni en tiempo de despliegue. Solo en tiempo de ejecución.

¿Qué objetos pueden tener sinónimos?

Los sinónimos en SQL Server no son tan versátiles como a veces se cree. No puedes crear alias para “lo que te dé la gana”. Están limitados a objetos individuales y concretos. Vamos a dejar esto bien claro para evitar que alguien pierda una hora pegándose con errores de sintaxis absurdos.

Sí puedes crear sinónimos sobre:

Tablas (locales o remotas, si usas nombres de cuatro partes correctamente).
Vistas.
Procedimientos almacenados.
Funciones definidas por el usuario (escalares o con valores de tabla).

Siempre que el objeto esté definido en un esquema, sea accedible por nombre completo y tenga una representación clara en la metadata, puedes hacerle un sinónimo.

No puedes crear sinónimos sobre:

Tablas temporales (#Local, ##Global).
Triggers. (No me preguntéis por qué alguien lo intentaría).
Constraints (CHECK, DEFAULT, FOREIGN KEY, etc.).
Columnas. Lo de SELECT columna AS alias es otra cosa.
Tipos definidos por el usuario (UDT), reglas (RULE), secuencias (SEQUENCE), ni defaults independientes.
Funciones del sistema (GETDATE(), ISNULL(), etc.).
Objetos CLR o ensamblados .NET.
Índices, particiones, estadísticas o cualquier cosa que no sea “llamable” desde T-SQL por sí sola.
Bases de datos. No puedes hacer un alias de una base de datos entera. Olvídalo.
Esquemas. Tampoco puedes crear un sinónimo para un esquema. Ni para [dbo], ni para ninguno. Si necesitas encapsular el acceso a todos los objetos de un esquema remoto, necesitarás crear un sinónimo por cada objeto. O usar otro enfoque (vistas, procedimientos, sin llorar).

Recuerda: los sinónimos apuntan a objetos, no a contenedores de objetos. Si te estás planteando crear sinónimos para simplificar nombres de base de datos o de esquema, estás intentando que hagan algo para lo que no fueron diseñados. Te toca o escribir más código o usar una capa de abstracción de verdad.

¿Versionado y mantenimiento?

Cuando usas sinónimos para abstraer el acceso a objetos en otras bases de datos, estás añadiendo una capa más que también necesita mantenimiento. Y como suele pasar, se te va a olvidar.

¿Haces despliegues con DACPACs? ¿Tienes control de versiones? ¿Sabes en qué base de datos está realmente cada sinónimo? ¿Cuándo fue la última vez que hiciste un DROP SYNONYM?

Exacto.

Además, los sinónimos no aparecen claramente en muchas herramientas de análisis de dependencias. Ni en algunos generadores de documentación. Son casi como variables globales: parecen útiles hasta que tu entorno tiene más de dos personas y cinco entornos.

¿Y cómo los controlo?

Si has heredado una base de datos con decenas (o cientos) de sinónimos, lo primero es hacer inventario:

SELECT name, base_object_name
FROM sys.synonyms;

Con eso ya puedes empezar a trazar qué objetos están apuntando a qué lugares. Usa sys.sql_expression_dependencies para ver si están en uso, aunque no siempre captura todo.

Haz pruebas. Valida que cada sinónimo realmente apunte a algo válido. Y luego decide si vale la pena mantenerlo o rediseñar esa parte del acceso.

No olvides que puedes hacer scripts automáticos para regenerarlos si decides mover entornos. Pero asegúrate de que esos scripts están bajo control de versiones, como Dios y el sentido común mandan.

Conclusión

Los sinónimos son ese tipo de herramienta que SQL Server te da con una sonrisa pero sin instrucciones. Te ahorran escritura, sí, pero a cambio te introducen opacidad, dependencias ocultas y posibles dolores de cabeza cuando algo deja de funcionar y nadie recuerda de dónde venía ese nombre tan bonito.

No están prohibidos. Pero tampoco deberían ser tu primera opción. Úsalos con mesura, con documentación, y con una pizca de paranoia técnica. Porque el día que falle un sinónimo en producción, nadie va a buscar el problema en ese alias inofensivo… hasta que ya es demasiado tarde.

Oct

2025

Database Snapshots en SQL Server: Ni backup, ni milagro, pero muy útil

Llevábamos ya años con el blog y sin hablar de snapshots. Quizá porque es una de esas funcionalidades que están ahí desde hace años (SQL Server 2005, nada menos), pero que siempre han vivido en esa zona gris de lo útil pero olvidado. Como ese índice XML que alguien creó en 2013 y nadie ha tocado desde entonces. Hoy vamos a remediarlo, no para darles bombo, sino para entender realmente qué ofrecen, qué limitaciones arrastran, y sobre todo, cuándo tiene sentido usarlos… y cuándo no.

¿Qué es un Database Snapshot?

Un Database Snapshot es una copia solo lectura de una base de datos en un punto en el tiempo. No es una copia física, ni tampoco un backup, aunque mucha gente los confunda (mal hecho). Es un mecanismo basado en copy-on-write que permite mantener la imagen original de los datos a medida que la base activa cambia.

No crea una copia completa de los datos. En lugar de eso, guarda las páginas modificadas en un archivo sparse, lo que permite “reconstruir” cómo estaban los datos en el momento del snapshot sin necesidad de duplicar todo el almacenamiento.

Importante: el snapshot depende completamente de la base de datos original. Si la base cae, se corrompe o desaparece, el snapshot no vale absolutamente para nada. Cualquier parecido con un backup es pura coincidencia y mala comprensión técnica.

¿Cómo funciona internamente?

El principio es simple, en el momento en que se crea un snapshot, SQL Server marca todas las páginas como estables. A partir de ese instante, cada vez que una página de datos va a ser modificada en la base de datos original, su contenido anterior se copia en el archivo sparse del snapshot. Esto es el famoso copy-on-write.

Por eso, al consultar un snapshot, SQL Server reconstruye cada página accediendo al archivo sparse solo si esa página ha cambiado. Si no, la lee directamente de la base original. Esta eficiencia hace que los snapshots sean rápidos de crear y razonablemente económicos en almacenamiento… al menos al principio.

Ahora bien, si la base de datos se modifica mucho, los archivos sparse pueden crecer de forma nada despreciable. A efectos prácticos, un snapshot puede acabar ocupando casi tanto como la base original si hay suficiente actividad. No es frecuente, pero tampoco impensable.

Sintaxis básica

Supongamos que tenemos una base de datos llamada MiBase y queremos crear un snapshot. Es así de fácil:

CREATE DATABASE MiBase_Snapshot_20251011
ON 
(
    NAME = MiBase_Data,
    FILENAME = 'D:\Snapshots\MiBase_Snapshot_20251011.ss'
)
AS SNAPSHOT OF MiBase;

Casos reales de uso

Los snapshots tienen usos muy específicos. Aquí van algunos que sí tienen sentido técnico.

1. Restauración rápida tras una operación peligrosa

Antes de hacer un update masivo, un truncate o cualquier otro acto temerario, puedes crear un snapshot. Si algo sale mal, puedes volver al estado anterior usando un revert.

RESTORE DATABASE MiBase FROM SNAPSHOT = 'MiBase_Snapshot_20251011';

Eso sí, este RESTORE elimina todos los cambios hechos desde que se creó el snapshot. Nada de granularidad. Esto es todo o nada.

2. Consultas analíticas en entornos OLTP

A veces necesitas lanzar un informe o validación sin que los datos cambien mientras se ejecuta. Y no, no siempre puedes meter todo en una transacción ni usar niveles de aislamiento elevados sin liarla en el entorno OLTP.

Ahí es donde un snapshot puede tener sentido. El snapshot genera una imagen coherente y estable de los datos en el momento de su creación. Puedes hacer consultas complejas sin riesgo de leer datos a medias ni provocar bloqueos.

Pero que no te vendan la moto, el snapshot no reduce la carga del sistema. Las páginas que no han cambiado desde su creación se siguen leyendo desde la base original. El I/O sigue yendo a los mismos discos. Incluso puedes añadir algo más de carga por el copy-on-write si la base está escribiendo mucho.

¿Quieres estabilidad en tus lecturas? Perfecto.
¿Quieres rendimiento? Haz otra cosa.
Por ejemplo:

SELECT ClienteID, Nombre, Saldo
FROM MiBase_Snapshot_20251011.dbo.Clientes
WHERE Saldo < 0;

Tendrás una lectura coherente, congelada en el tiempo, sin preocuparte de cambios concurrentes. Pero no esperes milagros en los tiempos de respuesta.

3. Comparaciones entre versiones

Ideal si necesitas comparar el estado de los datos antes y después de una carga o transformación. Puedes leer ambos mundos (activo y snapshot) en paralelo, por ejemplo:

SELECT COUNT(*) FROM MiBase.dbo.Facturas;
SELECT COUNT(*) FROM MiBase_Snapshot_20251011.dbo.Facturas;

O comparar registros concretos, detectar cambios en columnas, o revisar cuántos registros nuevos hay que no existían en el snapshot. Todo sin afectar a la base activa.

4. Testing rápido

En entornos de pruebas donde necesitas una copia coherente y estática para validar un proceso, sin necesidad de clonar toda la base.

Limitaciones que no conviene ignorar

Los snapshots no son mágicos. Y como todo lo que parece demasiado cómodo, tienen letra pequeña. Aquí van algunas verdades que conviene tener presentes:

Solo lectura. No se pueden modificar. Olvídate de hacer pruebas de escritura ahí dentro.
Vinculación absoluta a la base original. Si la base cae, se va el snapshot con ella. No es replicable, no es portable, y desde luego, no es “seguro”.
No puedes hacer backup de un snapshot. Ni exportarlo fácilmente. Vive y muere en el servidor que lo contiene.
No están soportados en Azure SQL Database. Aunque sí en SQL Server en Azure VMs. Si estás en PaaS, olvídate.
Limitación de cantidad. No hay una cifra oficial, pero no abuses. SQL Server no está pensado para mantener docenas de snapshots activos a la vez.

Y sí, pueden afectar al rendimiento. Pero esto merece su propia sección…

El coste en rendimiento

Una de las mayores falacias con los snapshots es que «como no copian todos los datos, no afectan al rendimiento». Bueno, sí, y los triggers tampoco afectan si no se disparan nunca. Vamos al grano.

El impacto de los snapshots no está en la creación inicial, eso es casi instantáneo, sino en lo que pasa después, en cuanto la base de datos empieza a cambiar. Cada vez que se modifica una página en la base activa, SQL Server tiene que hacer una copia previa en el archivo sparse del snapshot. Esto añade una operación de escritura adicional por cada modificación.

¿Y eso qué implica? Más I/O. Más presión sobre el subsistema de almacenamiento. Y si no tienes discos NVMe, una SAN generosa o un almacenamiento SSD con margen, vas a notarlo. No al minuto uno, pero lo vas a notar.

En sistemas con alta tasa de escritura (bases OLTP vivas, sincronizaciones frecuentes, cargas masivas…), ese copy-on-write puede convertirse en un cuello de botella silencioso. No suele romper el sistema, pero lo frena. Y lo hace justo cuando menos te interesa: en plena operación intensa.

Lecturas extra, carga extra

Otra consecuencia menos obvia, al hacer lecturas desde el snapshot, SQL Server tiene que reconstruir cada página accediendo a dos ubicaciones posibles (la base original o el archivo sparse). Esto añade complejidad interna a la lógica de lectura, aunque el impacto sea menor que en escritura.

¿Quieres pruebas? Basta con monitorizar I/O cuando un snapshot está activo y tu base de datos empieza a recibir carga. Puedes usar sys.dm_io_virtual_file_stats, perfmon o herramientas de terceros como Redgate SQL Monitor. Verás cómo crece la escritura en el archivo sparse, y con ello, la latencia de las operaciones normales.

Y por supuesto, más archivos significa más trabajo para el planificador de I/O de SQL Server. En entornos con varias bases y múltiples snapshots, el impacto se acumula. No es dramático si lo controlas, pero si te dedicas a crear snapshots como quien colecciona Pokémon, vas a pagar el precio.

En resumen: los snapshots no son gratis. Cuestan I/O, y ese coste crece con el tiempo y con la actividad. Por eso no deben dejarse activos más de lo necesario, ni usarse como sistema “por si acaso”. Ese «por si acaso» puede ser el motivo por el que tus discos van al 90% sin razón aparente.

Conclusión

Los Database Snapshots son útiles. Mucho. Pero solo si se usan con cabeza. No sustituyen backups, no mejoran el rendimiento por arte de magia, y desde luego, no están hechos para vivir en producción de forma indefinida. Son un bisturí, no un martillo.

En manos de un DBA que sabe lo que hace, pueden ser la diferencia entre una operación arriesgada y un desastre. Pero mal usados, solo sirven para saturar discos, ralentizar el I/O y dar una falsa sensación de seguridad.

Así que la próxima vez que pienses en crear un snapshot, hazlo sabiendo por qué lo haces, cuánto tiempo lo vas a mantener, y qué coste estás dispuesto a asumir. Y cuando ya no lo necesites… bórralo. Que no eres un coleccionista.

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

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.

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.

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.

cloud

La SQLCon llega a España

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes