Cloud

Dic

2025

Github Copilot en SSMS 22: La IA para los DBAs

Este es el primer artículo para el calendario de adviento de IA organizado por Roberto Navarro y vamos a diseccionar Github Copilot en SSMS.

El día que Microsoft anunció que GitHub Copilot se integraba directamente en SQL Server Management Studio 22, muchos levantaron la ceja. Otros directamente la perdieron. No era para menos: por fin íbamos a tener una IA context-aware en el entorno donde pasamos la mitad de nuestra vida profesional (y no, no hablo de Teams). SSMS, nuestro bastión de queries, procedimientos y dolores de cabeza mal indizados.

Hasta ahora, los que queríamos asistencia de IA teníamos que usar atajos: Visual Studio Code con extensiones, herramientas de terceros, o directamente el Copilot clásico fuera de SSMS. Pero eso suponía sacrificar contexto, perder integración y andar con más ventanas que un becario con TOC. Con SSMS 22, por fin se rompe ese ciclo.

Pero aquí no estamos para aplaudir anuncios. Estamos para ver qué hace, qué no hace, y si de verdad vale la pena o es solo otra ronda de hype para justificar suscripciones. Y lo más importante: compararlo con lo que ya tuvimos antes y que, curiosamente, hacía algunas cosas que ahora han desaparecido.

Vamos por partes.

¿Qué significa tener Copilot en SSMS?

Cuando decimos que GitHub Copilot llega a SSMS, no hablamos de una extensión opcional. Es una integración directa, visible y oficial. No hay que instalar cosas raras ni hacer malabares. Basta con tener SSMS 22 y habilitar la funcionalidad AI Assistance desde el instalador de Visual Studio.

Una vez hecho, aparece un nuevo icono en la parte superior del editor de consultas. Desde ahí puedes iniciar sesiones de chat, generar código, hacer preguntas, recibir explicaciones o incluso pedir refactorizaciones de consultas existentes. Lo más interesante: Copilot tiene acceso al esquema de base de datos activo y a la versión de SQL. No está escribiendo a ciegas.

¿Lo mejor? No necesitas ser suscriptor premium para usarlo. Una cuenta de GitHub válida, con Copilot activo (aunque sea en plan gratuito), ya te da acceso. ¿Lo peor? La funcionalidad todavía está en preview, y eso se nota. Especialmente en detalles como la ausencia, de momento, de autocompletado inline o, la más sangrante aún imposibilidad de uso asociado a una cuenta de Github Empresarial. Pero paciencia: está en camino.

La diferencia principal respecto a usar cualquier IA comercial desde sus aplicaciones propias es que aquí la IA tiene contexto real del entorno SQL. Sabe la versión del motor, el esquema activo, las tablas y sus relaciones. No está generando código desde cero, sino con cierta conciencia del entorno en el que se ejecutará. No es un “completador inteligente”, sino un ayudante que entiende lo que tiene delante. Más o menos.

¿Qué hace (y qué no)? la lista sin adornos

Estas son las funciones que Copilot puede realizar dentro de SSMS. Y cuando digo puede, me refiero a que las he probado yo mismo, no a que lo diga una nota de prensa.

Sí, puede:

Generar consultas con bastante precisión, basándose en datos reales de tus tablas.
Leer el esquema de la base de datos conectada, incluyendo columnas, tipos de datos y claves.
Consultar el Query Store y ayudarte a entender por qué una consulta va lenta, con sugerencias para mejorar el plan de ejecución.
Refactorizar código SQL ya existente, limpiarlo o reescribirlo en versiones más legibles.
Explicar funciones, comandos, errores de sintaxis y diferencias entre cláusulas.
Acceder a datos de configuración, rendimiento y seguridad, analizarlos y sugerir cambios de configuración, hasta te da el script para hacerlo.

No, no puede (o no lo hace bien aún):

Ejecutar sentencias de escritura: no le pidas que realice cambios en los datos. Te da el script para que lo hagas tu pero no lo ejecuta. A diferencia de Copilot en VS Code, aquí no está tan suelto con los INSERT, UPDATE o DELETE.
Cambios de configuración o administración del servidor: no va a activar Query Store, ni cambiar MAXDOP, ni tocar permisos. Igual que con los datos, tampoco va a cambiar configuraciones.
Completar código en tiempo real como lo hace en Visual Studio Code: no hay autocompletado inline (todavía).
Responder rápido: no sé por qué pero el tiempo de respuesta es más lento que en otras versiones de Copilot. Hay lag, y se nota.

Experiencia real: lo que me he encontrado al usarlo de verdad

Probé Copilot en SSMS con una base de datos de desarrollo y estas son mis conclusiones, sin hype ni brocha gorda.

Primero: no cambia nada del entorno, lo cual es tranquilizador para algunos. Puedes pedir lo que quieras, que no va a tocar configuraciones ni hacer ajustes peligrosos. Si esperabas una IA que te optimice el servidor, aguanta en SSMS 21 que su copilot si lo hace.

Segundo: va más lento que Github Copilot en VS Code o Copilot de SSMS 21. Hay una latencia clara entre que haces la petición y recibes la respuesta. No lo hace inútil, pero sí menos fluido. No es para escribir en modo “tormenta de código”.

Tercero: entiende muy bien las tablas y genera consultas potentes. Le pedí un informe con agregados por mes, con filtros, joins y condiciones, y lo clavó. Pero cuando intenté que ejecutara una sentencia UPDATE… me dejó colgado. En VS Code, sí lo hace. Aquí, de momento, no.

Y cuarto: me sorprendió que puede leer del Query Store. Le pregunté por una consulta que estaba yendo lenta, y fue capaz de extraer el historial de ejecuciones y sugerirme mejoras en base a planes previos. Esto sí es diferencial. Aquí no hablamos solo de “escribe código”, sino de “ayúdame a entender el problema”. Y lo hace.

En resumen: útil, sí. Limitado, también. Pero si sabes lo que hace y lo que no, puedes sacarle mucho partido.

Ya tuvimos algo parecido (y hacía más): el Copilot de SSMS 21

Antes de que GitHub Copilot se hiciera un hueco en SSMS 22, Microsoft lanzó un experimento previo con Copilot en SSMS 21. Se quedó en Preview. También con IA generativa. Pero con una diferencia clave: este traía consigo modos de operación explícitos que controlaban qué tipo de sugerencias podía dar el asistente. Me refiero a los famosos comandos:

/ro – Solo lectura: consultas de lectura seguras, sin posibilidad de modificación.
/rw – Lectura y escritura: consultas de lectura y escritura, sin restricciones.
/rwa – Lectura/escritura con aprobación: como el anterior, pero requiriendo confirmación manual antes de ejecutar cambios.

La idea era brillante: si estás en un entorno sensible, puedes limitar el alcance de la IA. Si estás en desarrollo, lo abres todo. Y si estás enseñando a un junior, tienes una capa de seguridad. Más allá de la etiqueta, el asistente podía ejecutar cambios de configuración si el modo lo permitía. Le podías pedir que cambiase opciones de base de datos, configuraciones del servidor, o valores de sesión. Y lo hacía.

Esto, lo digo claro, ya no existe en la versión actual de GitHub Copilot para SSMS 22. No hay ningún modo /ro, /rw o /rwa. No hay control granular del tipo de acciones. Y por ahora, al menos en esta Preview, tampoco realiza cambios de datos, configuración ni operaciones peligrosas.

¿Más seguro? Sí. ¿Más útil para quien sabe lo que hace? No tanto.

¿Esto sustituye a un DBA? Spoiler: no

Ya veo venir la pregunta del jefe de turno: “¿Entonces con esto ya no necesitamos DBAs?”. Y la respuesta es muy sencilla: “Genial, entonces me voy de vacaciones, y cuando el plan de ejecución empiece a escalar a 300 segundos, se lo explicas al copiloto”.

Porque no, Copilot no sustituye a nadie que sepa lo que hace. Ayuda, sí. Mucho. Pero no razona como tú, no entiende tu negocio, no prioriza por impacto ni por SLA. No tiene contexto de aplicación ni de arquitectura. Si no sabes lo que haces, te puede generar código muy bien formado… pero totalmente inútil. Y eso, en SQL, suele doler.

Copilot es una herramienta. Como una moto. Puede hacerte más rápido, pero también matarte si no sabes frenar.

Copilot no sustituye a un DBA. Lo complementa. Lo acelera. Te ayuda a pensar en voz alta y aterrizar ideas complejas. Pero no valida lo que tú no entiendes. Si usas lo que sugiere sin revisarlo, eres tú el problema. Igual que cuando alguien copia un query de StackOverflow sin mirar el WHERE.

Y ojo con la privacidad, según Microsoft, los prompts, respuestas y metadatos de la sesión de Copilot en SSMS no se almacenan ni se usan para reentrenar modelos. Pero si estás en un entorno con datos sensibles, RGPD o paranoia institucional, revisa bien antes de autorizar su uso. La letra pequeña también existe para los entornos corporativos.

Otro aspecto a vigilar es la dependencia. Si todo tu equipo empieza a depender de Copilot para escribir desde SELECT hasta MERGE, corres el riesgo de formar una legión de “copipegas profesionales” que no entienden lo que ejecutan. No es culpa de la IA. Es culpa de no haber puesto límites y de pensar que una sugerencia automatizada sustituye a una formación sólida.

Recomendaciones para el uso en entornos serios

Vale, quieres usar Copilot en tu empresa. Perfecto. Pero hazlo bien.

Empieza en entornos de desarrollo. Crea un entorno de pruebas donde puedas evaluar la calidad del código generado, su rendimiento, y su adecuación a las guías internas. Establece políticas claras sobre lo que se puede y no se puede pedir a la IA (por ejemplo, nada de scripts de borrado o alteraciones sin validación humana).

Forma al equipo. No basta con decir “ahora tenemos Copilot”. Hay que enseñar a pedir bien. Un prompt claro, con contexto, con restricciones, da resultados mucho más útiles que una petición vaga.

Y, sobre todo, exige revisión humana. Todo código generado por Copilot debería pasar por una validación. No porque sea malo (a estas alturas suele ser decente), sino porque aún no hemos llegado al punto en que puedas confiar ciegamente en una máquina que nunca ha pisado producción.

Conclusión: buena idea, pero úsala con cabeza

GitHub Copilot en SSMS 22 no es humo. Es una herramienta que puede cambiar nuestra forma de trabajar como DBAs, desarrolladores y responsables de datos. Nos permite acelerar tareas, explorar soluciones alternativas y reducir el tiempo que dedicamos a repetir siempre lo mismo. Eso sí: como cualquier herramienta potente, puede ser peligrosa en manos poco formadas.

Si sabes lo que haces, Copilot te hará mejor. Si no lo sabes, sólo lo hará más rápido.

Y si alguien en tu empresa sugiere que esto puede sustituir al equipo de bases de datos, pídele que lo active en su entorno… y que pruebe a hacer tuning con la IA cuando caiga la base de datos un viernes a las 23:45.

No hay IA que arregle eso. Pero sí un DBA cabreado que se lo recordará toda la vida.

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

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

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.

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.

Cloud

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes