Infra

Sep

2025

Canalizaciones por nombre (Named Pipes) en SQL Server

Durante años, las canalizaciones por nombre (Named Pipes) han sido uno de esos protocolos de red que viven en las sombras de TCP/IP. Están ahí, aparecen en las configuraciones del SQL Server Configuration Manager, y de vez en cuando algún alma valiente pregunta si debería activarlas “por si acaso”. Y no, por si acaso no es un argumento válido en administración de sistemas, y mucho menos en bases de datos. Vamos a analizar qué son exactamente, cómo funcionan y en qué escenarios podrían tener sentido… si es que alguno queda en 2025.

¿Qué demonios son las canalizaciones por nombre?

Antes de decidir si las activamos o las dejamos durmiendo el sueño de los justos, conviene entender qué son. Las canalizaciones con nombre son un mecanismo de comunicación interprocesos (IPC) heredado del glorioso mundo de Windows NT. Permiten que dos procesos, incluso en máquinas diferentes, se comuniquen a través de una ruta virtual. En SQL Server, representan uno de los protocolos disponibles para aceptar conexiones de cliente.

Mientras que TCP/IP utiliza direcciones IP y puertos, Named Pipes utiliza una sintaxis como \\.\pipe\sql\query, y en red sería algo tipo \\Servidor\pipe\sql\query. Esta vía de comunicación puede ser más rápida en entornos muy controlados y locales (léase: conexión directa entre un cliente y un servidor dentro de la misma LAN y sin cuellos de botella), pero en la práctica actual… hay que hilar muy fino para justificar su uso.

TCP/IP vs Canalizaciones por nombre: ¿por qué seguimos hablando de esto?

La realidad es que TCP/IP es el protocolo estándar y recomendado para conexiones SQL Server, tanto en producción como en desarrollo. Es más robusto, más flexible, y más preparado para escenarios reales con múltiples capas de red, firewalls, balanceadores, NATs y demás fauna moderna.

Entonces, ¿por qué SQL Server sigue ofreciendo Named Pipes como opción? Por compatibilidad. Porque aún hay sistemas legacy que las usan. Y porque a Microsoft le cuesta soltar lastre tanto como a cualquiera que aún mantiene SQL Server 2008 en alguna esquina de su datacenter “temporal”.

Hay entornos donde, por motivos históricos o arquitecturas muy específicas, se configuraron conexiones a SQL Server utilizando Named Pipes. En esos casos, sí, deshabilitarlas podría romper algo. Pero esa es la excepción, no la norma.

¿Cuándo tienen sentido las Named Pipes?

Vale, no todo es blanco o negro. Hay escenarios, pocos pero existentes, donde las canalizaciones por nombre pueden tener cierta ventaja:

Conexiones locales (cliente y servidor en la misma máquina): En algunos benchmarks internos de Microsoft (de hace más de una década nada menos), se observó que el rendimiento de Named Pipes en conexiones locales era ligeramente superior al de TCP/IP. Pero, francamente, si ese es tu cuello de botella, tienes problemas mayores.
Autenticación integrada en entornos Windows puros: Las canalizaciones por nombre pueden simplificar ciertos escenarios de autenticación integrada en entornos totalmente controlados por Active Directory. Pero otra vez: TCP/IP también lo hace sin problemas.
Entornos legacy que no quieres (o puedes) tocar: Si tienes una aplicación que explícitamente se conecta usando np: o configuraciones hardcoded de canalizaciones con nombre, y no puedes modificarla… entonces no queda otra que habilitarlas.
Solución de problemas puntuales: En algunos casos, cuando el acceso por TCP/IP falla misteriosamente (DNS, puertos bloqueados, fuegos en el CPD…), usar Named Pipes puede servir para diagnosticar si SQL Server sigue vivo y coleando.

Pero si tu escenario no cae en alguno de estos puntos, las Named Pipes sobran.

Cómo funcionan realmente las canalizaciones por nombre

Cuando habilitas Named Pipes en SQL Server, el motor escucha en una canalización concreta: \\.\pipe\sql\query por defecto. El cliente debe conectarse utilizando ese nombre. Lo que muchos no saben es que esto no solo requiere que el cliente conozca la sintaxis, sino también que la resolución de nombres esté bien configurada (en red), y que no haya firewalls bloqueando el tráfico correspondiente.

Además, en entornos remotos, el protocolo puede comportarse de forma bastante torpe: mayor latencia en la negociación, más complejidad en el tráfico de red, y más exposición a errores difíciles de diagnosticar. Si te suena a dolor de cabeza… es porque lo es.

¿Qué pasa si dejo las canalizaciones por nombre activadas “por si acaso”?

Esto es como dejar todas las ventanas de casa abiertas por si te olvidas las llaves. En teoría podría ayudarte, pero en la práctica te estás exponiendo innecesariamente. Habilitar las canalizaciones por nombre sin necesitarlas abre un vector de ataque innecesario (sí, también hablamos de superficie de ataque), complica el troubleshooting de conexiones, y puede provocar que clientes mal configurados intenten conectar usando este protocolo en lugar de TCP/IP.

Por si fuera poco, cuando están activadas, SQL Server puede priorizarlas en la cadena de protocolos, lo que lleva a situaciones surrealistas como que un cliente tarde más de la cuenta en conectarse porque está intentando usar Named Pipes antes que TCP/IP.

Lo peor de todo es que, en redes modernas, usar Named Pipes puede ralentizar la conexión en lugar de mejorarla. Así que eso de activarlas para “ganar velocidad” es un mito que ya deberíamos haber dejado atrás con el disquete.

¿Y si las necesito, cómo las activo (o desactivo)?

Si a pesar de todo necesitas activar Named Pipes, el proceso es sencillo, pero no inmediato. Desde SQL Server Configuration Manager, accede al protocolo correspondiente bajo SQL Server Network Configuration, y ahí puedes habilitarlas o deshabilitarlas. Necesitarás reiniciar el servicio SQL Server para que los cambios tengan efecto.

Además, si vas a usarlas, asegúrate de configurar también correctamente la cadena de conexión en el cliente, usando el prefijo np: para forzar que se utilicen Named Pipes.

Y, por supuesto, monitoriza. No asumas que todo va mejor solo porque te conectaste. Comprueba latencias, errores, y la experiencia real del usuario. Porque los milagros no vienen de las canalizaciones.

¿Qué protocolo prioriza SQL Server?

El orden de los protocolos es importante. SQL Server Native Client (o el driver OLE DB / ODBC que uses) sigue un orden al intentar conectar, salvo que lo fuerces. Ese orden se define también en SQL Server Configuration Manager, y puedes modificarlo.

Si dejas Named Pipes activado y en primer lugar, el cliente intentará primero por ahí antes de probar TCP/IP. Si Named Pipes no está disponible o hay problemas de red, el tiempo de espera puede incrementarse de forma absurda. ¿Te suenan esas conexiones que tardan 20 segundos solo en conectar? Pues eso.

Conclusión

Las canalizaciones por nombre son como el fax, aún existen, aún funcionan, y hay quien defiende que tienen utilidad. Pero en la mayoría de escenarios modernos con SQL Server, no hay ninguna razón técnica sólida para tenerlas activadas si no se están usando.

No aportan ventaja real frente a TCP/IP, complican el diagnóstico, abren superficie de ataque, y pueden ralentizar la conexión. Si tu entorno las requiere, adelante, pero hazlo con conocimiento de causa. Si no sabes para qué las necesitas, es que no las necesitas.

Apaga las Named Pipes, reinicia tu SQL Server y duerme tranquilo sabiendo que has reducido complejidad innecesaria.

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 LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Sep

2025

El libro de SQL Server que estabas esperando

Después de más de una década trabajando con SQL Server y ahora compartiendo contenido en SoyDBA, estoy escribiendo un libro pensado para profesionales que quieren ir más allá de la documentación oficial. Un libro técnico y muy didáctico.

Más de 40 capítulos en 7 partes, desde los fundamentos del modelo relacional hasta las herramientas de diagnóstico más avanzadas. Un recorrido completo, pensado para DBAs, analistas y desarrolladores que quieren entender cómo funciona SQL Server de verdad.

El prólogo lo firma Fernando G. Guerrero, pionero y referente en nuestra comunidad. La contraportada, Juanjo Luna, MVP de Access y más apasionado de SQL de lo que quiere reconocer. Os dejo aquí el texto de la contraportada:

No os voy a engañar; comercialmente, este libro va a ser un fracaso. Escribir más de 200 hojas hablando de un tema que no es de uso práctico, es algo que nadie quiere hoy en día.

Su propia portada ya lo indica: La no guía práctica …

En medio de una sociedad en la que lo que vende es el producto rápido de consumo inmediato, con soluciones mágicas; pretender sacar un producto de este tipo significa ser un… Déjame que busque la palabra… ah sí: MVP

Leyendo el libro, me venía a la cabeza que tenía entre manos el test de la ITV de los DBAs. Si no dominas lo que pone en el libro y gestionas servidores y/o bases de datos, tienes un problema.

¿Por qué deberías leer este libro?

Si eres un neófito del tema, que tan solo consume servicios de datos, sin saber lo que hace, este libro es un itinerario fantástico para saber cómo adentrarte en el mundo de los DBAs.

Para el ya iniciado es el test perfecto para descubrir todo lo que le falta por saber. Cuánto habría dado hace años por tener algo así para poder elegir como progresar, de manera independiente en la gestión de mis servidores de datos.

Si por el contrario, eres realmente un experto, el mero hecho de compartir conocimientos con Roberto Carrancio, es un disfrute que solo los grandes entendidos pueden comprender.

Seas el tipo que seas, el libro que tienes entre manos, no te hará experto en nada; pero te abrirá las puertas para que puedas llegar a serlo.

Escribir este libro justo ahora en el que todo el mundo busca cómo utilizar la IA para que haga las cosas sin necesidad de entenderlas es un error absoluto….

O TAL VEZ NO.

Si quieres conseguirlo corre a Amazón.

El libro está disponible en Amazon en formato papel y Kindle en todo el mundo.

Consigue el libro aquí

Mantente al día de las novedades con mi newsletter gratuita

Sep

2025

Backups en SQL Server Always On y novedades en SQL Server 2025

Llevamos años con Always On sobre la mesa, vendiéndolo como la solución de alta disponibilidad y recuperación ante desastres por excelencia en entornos SQL Server. Cuando alguien monta un Availability Group por primera vez, suele pensar que ya tiene resuelta la alta disponibilidad, la recuperación ante desastres, los backups, el estrés y la hipoteca. Y no es mentira, pero tampoco es magia. Quienes lo gestionamos sabemos que montar un AG (Availability Group) es fácil en demos, pero bastante más delicado en producción. Always On resuelve cosas, sí, pero también introduce otras que hay que entender, especialmente cuando hablamos de estrategias de backup.

Y es que, hasta ahora, hacer backups en réplicas secundarias era poco más que un “parche”. Con SQL Server 2025, Microsoft ha introducido una mejora que, aunque llega tarde, se agradece: la posibilidad de hacer backups completos, diferenciales y de logs directamente sobre una réplica secundaria. Vamos a ver qué cambia exactamente y cómo podemos (por fin) diseñar estrategias de backup decentes en entornos Always On.

¿Dónde se hacen los backups en un Availability Group?

Empecemos con lo básico, que no es tan obvio como parece. En un AG, todas las réplicas tienen una copia de la base de datos, pero no todas son iguales ni sirven para todo. A la hora de hacer backups, SQL Server nos permite controlar el comportamiento a través de dos configuraciones clave:

AUTOMATED_BACKUP_PREFERENCE: una propiedad del Availability Group que indica en qué réplica se deben lanzar los backups automáticos (es decir, los lanzados mediante SQL Server Agent, Maintenance Plans, etc.). Esta propiedad puede tomar los valores:

PRIMARY: sólo se hacen backups en la réplica primaria.
SECONDARY_ONLY: sólo se hacen en las réplicas secundarias.
SECONDARY: se prefiere una secundaria, pero se usa la primaria si no hay otra disponible.
NONE: no hay preferencia definida, el agente decide.

BACKUP_PRIORITY: una propiedad individual de cada réplica que define su peso relativo a la hora de ser elegida para realizar los backups, si hay varias candidatas disponibles según la preferencia anterior.

Con estas dos configuraciones combinadas, SQL Server decide en qué réplica ejecutar los backups cuando se utilizan herramientas automatizadas. Pero ojo: si ejecutas el backup manualmente (T-SQL, PowerShell, etc.), se lanza en la réplica donde estés conectado. Lo de la preferencia solo aplica en los automatismos.

Tipos de backups permitidos hasta SQL Server 2022

Ahora bien, no todos los tipos de backup están permitidos en todas las réplicas. Hasta SQL Server 2022 (incluido), las reglas eran bastante limitantes.

Los backups completos (FULL) sólo están permitidos en la réplica primaria, salvo que sean COPY_ONLY, en cuyo caso sí se pueden hacer en réplicas secundarias. Los backups diferenciales (DIFFERENTIAL) tienen el mismo “problema”, únicamente se pueden hacer en la primaria. Por el contrario, los backups de log (TRANSACTION LOG) si se pueden hacer en cualquier réplica (primaria o secundaria), siempre que esté en estado sincronizado o aceptable. Y son válidos como parte de la cadena de recuperación.

En resumen, solo los logs son realmente “migrables” a réplicas secundarias de forma productiva. El resto, si no es COPY_ONLY, requiere pasar por la primaria. Y como ya sabemos, los COPY_ONLY no afectan a la cadena de backups, por lo que no sirven como parte del plan de recuperación principal.

Este escenario genera el clásico problema, la carga de los backups importantes (full y diff) sigue recayendo en la réplica primaria, justo la que está ejecutando cargas de producción críticas. Y claro, luego vienen los lloros por I/O, CPU y ventanas de mantenimiento.

¿Qué cambiará en los backups de AG con SQL Server 2025?

Aquí llega la buena noticia. A partir de SQL Server 2025 (en preview), Microsoft amplía por fin el soporte de backups en réplicas secundarias. Y esta vez de verdad: Ya se podrán hacer backups FULL, DIFFERENTIAL y LOG en réplicas secundarias. Y no en modo COPY_ONLY, sino como parte activa de la cadena de recuperación.

Esto significa que podremos rediseñar completamente nuestra estrategia de backups en entornos Always On. Por ejemplo, podremos mover el backup completo diario a una secundaria, programar los diferenciales en otra y dejar los logs en una tercera. Todo sin tocar la primaria.

Y lo mejor es que no habrá que cambiar nada en la configuración actual del AG. Si ya tenemos configurado AUTOMATED_BACKUP_PREFERENCE = SECONDARY_ONLY y hemos definido prioridades con BACKUP_PRIORITY, esas mismas reglas se aplicarán también a full y diferenciales. Lo único que cambia es lo que SQL Server permitirá hacer técnicamente en cada réplica.

Cómo configurarlo (y cómo comprobarlo)

La configuración es la misma de siempre, para ver el valor actual de la preferencia de backups del AG podemos usar:

SELECT automated_backup_preference_desc FROM sys.availability_groups;

Para ver la prioridad de backup por réplica:

SELECT replica_server_name, backup_priority FROM sys.availability_replicas;

Y, si necesitas modificar la preferencia:

ALTER AVAILABILITY GROUP [NombreDelAG]
SET (AUTOMATED_BACKUP_PREFERENCE = SECONDARY_ONLY);

Y podrás seguir usando la vista sys.dm_hadr_backup_is_preferred_replica para determinar en tiempo real cuál es la réplica preferida según la configuración actual. Ideal para integrarlo en scripts de backup personalizados.

Consideraciones importantes y limitaciones

Como todo cambio de este tipo, hay que tener claro qué implica antes de correr a modificar tus scripts. La réplica secundaria debe estar sincronizada y en estado ONLINE. No sirve una réplica desactualizada o en SUSPENDED. Por supuesto, el backup de log seguirá necesitando una cadena coherente. Como hasta ahora, puedes hacer logs desde réplicas secundarias, pero asegúrate de que tu estrategia de restauración tiene en cuenta su procedencia.

El restaurado no cambiará, si haces un FULL en una secundaria, un DIFF en otra y LOGs en una tercera, tendrás que restaurarlos todos en orden, desde sus respectivas ubicaciones. Esto requiere un buen control del sistema de almacenamiento y del catálogo de backups.

Por último, el rendimiento de las réplicas secundarias importa. No pienses que es buena idea mandar todos los backups a una secundaria con discos lentos y CPU de museo. Es posible, sí. Recomendable, no.

¿Cómo adaptar tu estrategia de backups?

Con esta mejora, por fin podremos plantear una estrategia de backups moderna para Always On, que de verdad aproveche la arquitectura del AG. Algunas ideas:

Mueve los FULL y DIFF a réplicas secundarias bien dimensionadas.
Mantén los LOGs distribuidos según disponibilidad, pero con control estricto del histórico.
Diseña tus planes de mantenimiento con tolerancia a failover: si una réplica cae, otra puede asumir su rol.

Eso sí, no pierdas de vista que toda esta flexibilidad requiere más disciplina. El seguimiento de los backups, la monitorización y la política de retención deben estar muy claros. Porque ahora no hay excusas: puedes repartir la carga, pero también puedes complicarte la vida si no lo haces bien.

Conclusión

SQL Server 2025 traerá una mejora largamente esperada. Por fin podremos hacer backups completos y diferenciales en réplicas secundarias, de forma nativa y como parte del plan de recuperación. No es un parche ni una opción limitada, es un cambio real en cómo el motor entiende las responsabilidades de cada réplica.

Y si aún haces todos los backups desde la primaria, empieza a preguntarte por qué. Porque a partir de ahora, no es que se vaya a poder evitar: es que deberías.

Sep

2025

Novedades sobre el libro

Después de meses de trabajo, revisiones y mucha paciencia, puedo compartir tres novedades clave del libro SQL Server: La NO guía práctica de optimización:

El prólogo lo firma Fernando G. Guerrero, pionero en SQL Server y miembro histórico de la comunidad. Además de escribir unas palabras introductorias, ha contribuido en la revisión técnica.
Aquí está el índice completo, con los más de 40 capítulos organizados en 7 partes.
Y sí: la fecha de lanzamiento ya es oficial. El libro estará disponible a mediados de septiembre. Pronto os diré el día exacto

Índice completo

Parte 1 – Fundamentos del modelo relacional y la arquitectura
Desde la definición de base de datos relacional hasta la estructura física de páginas y archivos. El punto de partida sólido para entender qué hay detrás de cada consulta.

Parte 2 – T-SQL y construcción de consultas eficientes
SELECT, INSERT, UPDATE y DELETE como base, y a partir de ahí subconsultas, CTEs, funciones de ventana, vistas, procedimientos y ejecución de consultas. Todo lo que necesitas para escribir SQL que funcione en producción.

Parte 3 – Transacciones, concurrencia y aislamiento
Propiedades ACID, niveles de aislamiento, bloqueos, deadlocks y el nuevo modelo de bloqueos optimizados. Una sección clave para quien de verdad administre entornos críticos.

Parte 4 – Internals, configuración y mantenimiento
TempDB, almacenamiento, memoria, CPU, cardinalidad, parametrización, índices, estadísticas y particionado. La cocina interna del motor y cómo configurarlo sin hipotecar el rendimiento.

Parte 5 – Backup, recuperación y disponibilidad
Modelos de recuperación, estrategias de backup, restore, Log Shipping, Database Mirroring y Availability Groups. Todo lo que sostiene la continuidad de un entorno SQL Server serio.

Parte 6 – Seguridad y control de acceso
Principales, usuarios, roles, permisos y técnicas avanzadas de seguridad. Desde lo básico hasta RLS, cifrado y enmascaramiento de datos.

Parte 7 – Control, monitorización y diagnóstico
Herramientas internas y externas: Resource Governor, Activity Monitor, DMVs, Profiler, Extended Events, Query Store y PerfMon. Para que no solo administres, sino que entiendas qué ocurre bajo el capó.

Con este índice ya podéis ver que no es un manual de recetas rápidas, sino una guía estructurada de principio a fin para profesionales de SQL Server.

El lanzamiento será a mediados de septiembre y os avisaré en cuanto esté disponible en Amazon.

Sep

2025

Restringir el acceso a SQL Server por IP

A estas alturas de la película, todos los que llevamos tiempo en esto de la administración de SQL Server hemos recibido la misma pregunta en más de una ocasión: “¿Se puede bloquear el acceso a SQL Server según la máquina desde la que se conecta un usuario?” Spoiler: sí, se puede, pero no de la manera que muchos esperan. Y no, SQL Server no tiene un checkbox mágico para esto. Hay que ensuciarse las manos. Y aquí es donde entramos nosotros.

Lo que SQL Server no puede hacer (al menos por defecto)

No existe, al menos hasta el día de hoy, ninguna opción nativa en SQL Server que permita vincular un login a una IP específica. Ni en el Management Studio, ni en el registro, ni en las opciones avanzadas. No busques, que no está. Y no, tampoco hay un parámetro oculto de configuración que habilite esto.

Así que si lo que esperabas era marcar una casilla para decir “este login solo se conecta desde esta IP”… puedes dejar de leer aquí. Pero si estás dispuesto a ir un poco más allá, porque lo estás, hay una solución elegante (y eficaz): usar un trigger de tipo LOGON.

¿Un trigger de inicio de sesión? Sí, y bien usado

SQL Server permite crear triggers a nivel de servidor que se ejecutan justo cuando un usuario intenta iniciar sesión. Y es ahí donde podemos interceptar la conexión, comprobar desde qué IP se está intentando conectar, y decidir si le damos la bienvenida… o le cerramos la puerta en la cara.

Para obtener la IP del cliente, podemos usar la vista sys.dm_exec_connections, que nos da, entre otros muchos datos, la dirección desde la que se está estableciendo la sesión actual. Esa es la base de todo este invento.

Primer ejemplo: el caso clásico del login sa

Empezamos por el escenario más sencillo: restringir el acceso del usuario sa a una IP concreta (o, mejor aún, solo permitirle conexión desde el propio servidor).

Este es un ejemplo de trigger directo y sin florituras:

CREATE TRIGGER [RestrictSALogin]
ON ALL SERVER
FOR LOGON
AS
BEGIN
    DECLARE @client_ip VARCHAR(48);
    SELECT @client_ip = client_net_address
    FROM sys.dm_exec_connections
    WHERE session_id = @@SPID;

    IF ORIGINAL_LOGIN() = 'sa' AND @client_ip NOT IN ('192.168.101.202','<local machine>')
    BEGIN
        ROLLBACK;
        PRINT 'Acceso denegado para sa desde una máquina no autorizada.';
    END
END;
GO

Y ya está. Este trigger bloquea cualquier intento de conexión con el usuario sa desde una IP que no sea la del propio servidor o la que hayas indicado. Simple, efectivo y… sí, peligroso si no documentas bien la IP que estás autorizando. Porque si te equivocas y te bloqueas a ti mismo, te va a tocar entrar por modo seguro, y no será divertido.

Segundo escenario: múltiples usuarios, múltiples IPs

Ahora, pongámonos serios. No vas a crear un trigger por cada usuario. Ni tú, ni nadie. Para algo tenemos bases de datos. Vamos a externalizar la lógica de IPs permitidas en una tabla, y a hacer que el trigger se alimente de ahí.

Primero, creamos una base de datos auxiliar de configuración, por ejemplo ConfigSeguridad, y dentro, dos tablas: una con los logins permitidos y sus IPs, y otra (opcional) para registrar intentos fallidos de acceso.

CREATE DATABASE ConfigSeguridad;
GO
USE ConfigSeguridad;
GO
CREATE TABLE LoginsPermitidos (
    NombreUsuario NVARCHAR(100) NOT NULL,
    IPPermitida NVARCHAR(48) NOT NULL -- 'TODAS' si no hay restricción
);

Ahora podemos rellenarla con la lógica que queramos. Por ejemplo:

INSERT INTO LoginsPermitidos (NombreUsuario, IPPermitida) 
VALUES 
    ('sa', '192.168.101.225'),
    ('sa', '<local machine>'),
    ('admin', 'TODAS'),
    ('usuario1', '192.168.104.134');

Sí, aquí admitimos la palabra clave ‘TODAS’ como forma elegante de decir “este login puede conectarse desde cualquier parte del mundo, hasta desde el tren si hace falta”.

Y aquí viene el trigger maestro:

CREATE TRIGGER RestriccionLogins
ON ALL SERVER
WITH EXECUTE AS N'sa'
FOR LOGON
AS
BEGIN
    DECLARE @IPCliente NVARCHAR(48);
    DECLARE @NombreUsuario NVARCHAR(100);

    SELECT @IPCliente = client_net_address
    FROM sys.dm_exec_connections
    WHERE session_id = @@SPID;

    SET @NombreUsuario = ORIGINAL_LOGIN();

    IF NOT EXISTS (
        SELECT 1
        FROM ConfigSeguridad.dbo.LoginsPermitidos
        WHERE NombreUsuario = @NombreUsuario
          AND (IPPermitida = @IPCliente OR IPPermitida = 'TODAS')
    )
    BEGIN
        ROLLBACK;
        PRINT 'Acceso denegado: Usuario o IP no autorizados.';
    END
END;
GO

Este trigger es mucho más flexible. Puedes dar acceso a múltiples usuarios desde múltiples IPs, sin tener que tocar el código. Solo modificas los datos en la tabla. Que es como debe ser.

Y si, seguro que alguno está levantando la ceja por eso de usar EXECUTE AS ‘sa’ pero, es lo que hay. Es necesario para acceder a vistas como sys.dm_exec_connections si el usuario que se conecta no es sysadmin. No hay vuelta de hoja.

¿Y los errores? ¿Y los logs?

Todo esto está muy bien, pero cuando algo falla queremos saber qué ha pasado. Y sobre todo desde dónde.

Podemos mejorar el sistema añadiendo una tabla de log de errores y registrando ahí los intentos de conexión denegados:

CREATE TABLE LogErroresLogin (
    Fecha DATETIME DEFAULT GETDATE(),
    Usuario NVARCHAR(100),
    IPOrigen NVARCHAR(48),
    Motivo NVARCHAR(255)
);

Y dentro del trigger:

IF NOT EXISTS (...) -- como antes
BEGIN
    INSERT INTO ConfigSeguridad.dbo.LogErroresLogin (Usuario, IPOrigen, Motivo)
    VALUES (@NombreUsuario, @IPCliente, 'IP no permitida para este usuario');

    ROLLBACK;
END

De esta forma no solo protegemos, sino que auditamos. Que es justo lo que queremos cuando las cosas se tuercen.

Cuidado con las metidas de pata

Este tipo de trigger tiene mucha potencia, pero también un alto potencial para dejarte fuera como si hubieras olvidado las llaves dentro del coche. Si te bloqueas a ti mismo por error, hay dos formas de volver a entrar en el servidor y recuperar el control.

La primera es iniciar SQL Server en modo de inicio mínimo (-f) o modo de usuario único (-m), y eliminar el trigger desde ahí. Es incómodo, requiere reiniciar servicios, y si lo haces en un entorno en producción, más te vale tener una buena excusa preparada.

La segunda, más limpia y menos traumática, es conectarte a través de DAC (Dedicated Admin Connection). Esta conexión especial está activa en todos los SQL Server, pero ojo: el acceso remoto mediante DAC sí está deshabilitado por defecto. Y eso, en muchos casos, es como si no existiera, porque muchos de nosotros no administramos los servidores desde la consola local del host.

Puedes habilitar el acceso remoto a DAC con esta instrucción:

sp_configure 'remote admin connections', 1;
RECONFIGURE;

Y aquí viene la parte clave, no puedes usar DAC desde el GUI de SSMS. Olvídate de escribir ADMIN:servidor en el cuadro de conexión: eso no funciona. Para conectarte por DAC necesitas usar sqlcmd, ya sea desde la línea de comandos o desde el modo SQLCMD en SSMS (sí, ese modo raro que muchos ignoran hasta que es demasiado tarde).

Desde consola, la conexión se haría así:

sqlcmd -S ADMIN:NombreServidor\Instancia -E

Y desde ahí, puedes desactivar el trigger como si nada hubiera pasado.

Así que, si vas a jugar con triggers de inicio de sesión, valida bien tu tabla de permisos, habilita y prueba DAC remota, y ten sqlcmd a mano. Porque cuando el trigger se ponga tonto, el Management Studio no te va a sacar del apuro. Y cuando eso pase, querrás tener un plan B que no incluya reiniciar producción en hora punta.

Conclusión

Sí, se puede restringir el acceso a SQL Server por IP. No, no es una funcionalidad nativa. Pero con un poco de código y sentido común, se puede controlar quién entra y desde dónde. Es una capa de seguridad adicional que, bien usada, puede salvarte de más de un disgusto. Especialmente si aún sigues permitiendo conexiones con el usuario sa desde equipos de usuarios. Que eso sí que es una mala práctica de campeonato.

El código completo lo tienes en mi cuenta de GitHub, como siempre. Si lo vas a implementar, hazlo con cabeza. Aquí no venimos a jugar con triggers, venimos a proteger entornos que importan.

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!

Sep

2025

Estado del mercado de bases de datos en 2025

Hacer un estudio de mercado sobre tecnologías de bases de datos es una de esas tareas que a primera vista suena a powerpoint corporativo, pero que en manos de técnicos con cicatrices se convierte en una radiografía útil del presente y futuro del sector. Así que vamos a destripar el Top-20 de DB‑Engines de agosto de 2025 sin frases motivadoras ni colorines innecesarios.

TDLR: lo relacional sigue mandando, lo NoSQL crece y lo demás se mueve al ritmo del hype y la nube.

¿Qué es DB‑Engines y por qué lo usamos como termómetro?

DB‑Engines es una iniciativa creada y mantenida por Red-Gate, una empresa especializada en tecnología de bases de datos. No es una asociación, ni un organismo oficial, ni un spin-off académico. Es una plataforma privada e independiente que publica un ranking mensual de sistemas de bases de datos en función de su popularidad.

¿Y qué mide exactamente?

Al contrario de lo que pudiera parecer no mide rendimiento, ni instalaciones reales, ni cuota de mercado. Mide señales públicas de atención y actividad técnica: menciones en foros, frecuencia de búsqueda en Google, apariciones en LinkedIn, preguntas en Stack Overflow, ofertas de trabajo y artículos técnicos publicados. Es decir, mide qué motores generan conversación, formación, interés profesional y visibilidad.

DB‑Engines también publica comparativas entre motores, artículos explicativos y datos históricos. Pero su producto estrella es el ranking mensual, seguido por empresas, arquitectos y responsables técnicos como referencia de tendencia, no como oráculo infalible. Si una tecnología sube, es porque hay más gente hablando de ella. Si baja, puede que siga en producción, pero ya no ocupa tantas portadas ni conferencias.

¿Refleja esto la realidad de los entornos críticos? No siempre. ¿Sirve para entender hacia dónde se mueve la conversación y, por tanto, la demanda de conocimiento? Sin duda. Lo usamos no porque sea perfecto, sino porque es el mejor termómetro disponible para medir la temperatura del mercado.

Relacional manda: sí, todavía

Del TOP 20 del ranking de motores de bases de datos, doce son relacionales puros o “multi-modelo con ADN relacional”. No hablamos solo de Oracle, MySQL, SQL Server y PostgreSQL; también están Snowflake, Db2, SQLite, MariaDB, Microsoft Access (sí, todavía), Azure SQL Database, Hive y BigQuery.

Traducción técnica: si tu carga es OLTP, OLAP o una mezcla de ambas, sigues teniendo un core relacional como referencia. Todo lo demás (documentales, grafos, clave-valor, búsqueda) se consolida como satélite especializado. No es que el NoSQL haya muerto. Es que no ha conquistado el núcleo.

PostgreSQL: el ganador moral

PostgreSQL sube más de 33 puntos en el año. No es casualidad. La comunidad lo adora, los hyperscalers lo ofrecen como servicio gestionado, y se adapta con extensiones que lo vuelven polivalente: pgvector para IA, Timescale para series temporales, FDW para federación, Logical Replication para entornos distribuidos.

¿La clave? Es open source de verdad, no con asterisco. Y satisface a arquitectos que quieren potencia sin vender un riñón por licencia. Es, en muchos proyectos nuevos, la elección por defecto. No por moda, sino por eficacia.

Oracle, MySQL y SQL Server: viejos reyes, nuevos entornos

Oracle sigue el primero, como lleva años. No porque haya ganado popularidad, sino porque sigue incrustado en el ADN de la empresa clásica: banca, seguros, administración pública. Sí, cuesta, pero funciona. Y nadie quiere reescribir 200 procedimientos PL/SQL con dependencias cruzadas.

MySQL pierde más de 110 puntos en un año. Lo usan millones, pero ya no es el chico cool de la fiesta. El stack web se ha fragmentado, y muchos han migrado a PostgreSQL o soluciones más específicas.

SQL Server, por su parte, mantiene el tercer puesto, pero ha perdido más de 60 puntos interanualmente. No es que haya desaparecido, pero la conversación pública se ha desplazado a otras plataformas. SQL Server sigue siendo caballo de batalla en empresas medianas y grandes, especialmente en entornos on-prem y Azure híbrido, donde la integración con Active Directory, SSIS, SSRS y otros clásicos de la casa siguen marcando la pauta.

Eso sí, atención a lo que viene, SQL Server 2025 está ya en preview y apunta maneras. Entre las novedades: mejoras notables en rendimiento, seguridad y compatibilidad híbrida con Azure Arc. También hay nuevos mecanismos de optimización automática, mejoras para entornos con alto volumen de transacciones y más integración con servicios de inteligencia artificial. Aún es pronto para saber si estas mejoras se traducirán en una remontada en el ranking, pero no sería raro que en 2026 viésemos un repunte de visibilidad técnica si la preview convence y la migración se acelera.

MongoDB: menos moda, más estabilidad

MongoDB cae en puntuación, pero sigue como NoSQL más alto. ¿Qué ha pasado? Básicamente, ha dejado de ser “la novedad”. Se ha convertido en una opción seria y estable, y eso le resta ruido en redes. Además, la competencia le viene desde dos frentes: PostgreSQL con JSONB y servicios documentales específicos en cloud (tipo Cosmos DB o DocumentDB).

¿Se sigue usando? Mucho. Pero ya no está en el centro de las conversaciones de arquitectos. Eso sí, en microservicios y aplicaciones event-driven, sigue encajando como un guante.

El ascenso silencioso: Snowflake, Databricks y BigQuery

Aquí es donde empieza el capítulo “analítica en cloud”. Snowflake sube casi 43 puntos en el año. Databricks, más de 31. BigQuery, casi 10. El patrón es claro: DWH y lakehouse se están moviendo a plataformas gestionadas con elasticidad real, integración con IA y modelos de costes más modernos (aunque no siempre más bajos, según el uso).

¿Lo mejor? Que estos motores no están pensados para sustituir tu base OLTP. Vienen a resolver el otro gran problema: consolidar, transformar y explotar datos a gran escala sin montar un zoo de clusters on-prem.

Redis, Cassandra y DynamoDB: NoSQL donde toca

Redis baja levemente, pero sigue siendo imprescindible. Si no lo usas para caché o colas, es probable que tengas un cuello de botella innecesario en tu arquitectura.

Cassandra sube 11 puntos. Sigue sin estar de moda, pero es uno de los pocos motores que realmente escala linealmente sin pedir milagros al throughput del disco.

DynamoDB sube más de 14 puntos. Beneficiado por el lock-in positivo de AWS: si ya estás allí, y quieres serverless con rendimiento decente y costes predecibles, Dynamo es un candidato serio. El patrón es el mismo: NoSQL para lo que NoSQL hace bien.

El nicho útil: Neo4j y los grafos

Neo4j entra en el Top-20 y sube más de 10 puntos. No porque todo el mundo esté modelando grafos, sino porque hay más fraude que nunca, más recomendaciones que nunca y más necesidad de trazabilidad que nunca.

Eso sí, sigue siendo un nicho. No vas a modelar una tienda online en grafo. Pero cuando lo necesitas, no hay sustituto.

Embebido: SQLite

SQLite sube 7 puntos y se mantiene como el motor más invisible y más desplegado del planeta. Está en móviles, navegadores, apps de escritorio… y nadie habla de él. Pero sin él, medio mundo digital colapsaría.

Esto es importante, SQLite es, con diferencia, la base de datos más desplegada del planeta: está en cada móvil Android o iOS, en navegadores, en aplicaciones de escritorio, en coches, en televisores… Es omnipresente y nadie la instala conscientemente. Justo por eso, no aparece en tantos foros, ofertas de trabajo o notas de prensa, y DB-Engines se alimenta de esas señales.

Como SQLite es un motor embebido que funciona en segundo plano y rara vez se administra “como producto”, no genera ruido mediático. Nadie abre un hilo en Stack Overflow con “ayuda, tengo problemas de clúster con SQLite” porque… no hay clúster. Tampoco ves ofertas de trabajo “Buscamos experto senior en SQLite”. Y eso, para DB-Engines, cuenta como “menos popularidad”.

El gran olvidado: Access

Microsoft Access cae (otra vez), pero sigue en el ranking. Y con razón. No diremos nombres, pero todos conocemos una pyme, una universidad o incluso una gran empresa que tiene un .mdb dando soporte a algo que “no se puede tocar hasta que Juan vuelva de vacaciones”. Lo gracioso (o lo trágico, según el día) es que ese Access suele seguir funcionando. Sin actualizaciones automáticas, sin tests, sin pipeline CI/CD… pero ahí está, cumpliendo su papel.

Access tiene una base fiel que lo sigue defendiendo con uñas, dientes y formularios incrustados. Y aunque en muchos casos sería razonable migrar a soluciones más modernas, también hay que reconocer que para cierto tipo de aplicaciones de backoffice, gestión interna o pequeños procesos departamentales, Access fue (y sigue siendo) una navaja suiza. Desactualizada, sí. Limitada, también. Pero a veces suficiente, y eso es más de lo que pueden decir muchos proyectos en la nube con dashboards que fallan cada martes.

Así que sí, sigue cayendo en popularidad… pero no desaparecerá del todo. Y mientras existan ficheros compartidos en una unidad de red llamada \\SERVIDOR-CONTABILIDAD, Access seguirá teniendo un rincón en el ecosistema.

Elasticsearch y Splunk: ¿fin del hype?

Elasticsearch pierde 15 puntos, Splunk 26. El mensaje es claro: la observabilidad está cambiando de cara. Los costes y la complejidad de estas plataformas están siendo desafiados por soluciones cloud nativas, integración con Prometheus, OpenTelemetry, e incluso por modelos de pago más flexibles. Nadie discute su valor técnico, pero ya no son los únicos en la mesa.

¿Qué se puede inferir del informe?

Lo más claro es lo que ya hemos comentado, lo relacional sigue siendo el corazón de la arquitectura de datos. Incluso en entornos modernos, la consistencia, las transacciones y el SQL siguen siendo el pegamento. NoSQL no ha sustituido a nada, simplemente se ha acoplado a lo que le toca.

El desarrollo cloud y la analítica moderna están redefiniendo qué es “popular”, pero los fundamentos no han cambiado. Quien sepa SQL, entienda particiones, y sepa modelar bien, sigue siendo indispensable.

PostgreSQL es la opción sensata si no quieres venderle tu alma a ningún proveedor, y Snowflake, BigQuery o Databricks son opciones serias para analítica avanzada si el Excel se te queda corto (o si necesitas procesar terabytes en vez de fórmulas con SI(CONJUNTO)).

¿Y en España?

No hay datos locales de DB‑Engines, pero los que trabajamos aquí lo sabemos: mucho Oracle y SQL Server en el tejido empresarial clásico, bastante MySQL en web, y cada vez más PostgreSQL en nuevas implantaciones. Y sí, cuando hay presupuesto, Snowflake o BigQuery asoman la cabeza en los RFP de analítica.

Las startups se mueven con PostgreSQL + Redis + alguna solución cloud para IA o analítica. Las grandes, con Oracle + DWH en cloud y Access escondido en una carpeta llamada “no tocar”.

Conclusión

Puedes mirar el ranking todas las semanas, pero si no entiendes qué papel juega cada tecnología en tu stack, no sirve de nada. Las modas cambian, pero las bases siguen siendo las mismas: consistencia, rendimiento, escalabilidad y coste. Y sí, elegir mal la base de datos sigue siendo una forma rápida de complicarte la vida durante años.

Así que, como siempre, elige con criterio técnico, no con pulsaciones de Twitter. Y si estás pensando en migrar algo solo porque “PostgreSQL lo está petando”, más vale que tengas buenos motivos, y no solo un gráfico bonito. Porque lo único más peligroso que una mala arquitectura… es una moda mal entendida.

Sep

2025

¿Cuál es el coste de no optimizar SQL?

La mayoría de las empresas que trabajan con SQL Server no tienen ni la más remota idea de lo que les cuesta no optimizar sus consultas. Y no, no hablo de la típica pérdida de rendimiento que molesta al usuario de vez en cuando. Hablo de dinero. Del que se escapa cada mes por la rendija del servidor porque nadie se molestó en revisar ese SELECT con JOIN cruzado que parece escrito por un algoritmo con ganas de venganza.

Pero vamos por partes. Porque el drama tiene capítulos, y todos salen caros.

Hardware: más coste para hacer lo mismo (o menos)

Cuando una consulta no está optimizada, lo primero que pide el sistema es más CPU. Más RAM. Más disco. Y como somos humanos, y a veces un poco vagos, el primer impulso es escalar verticalmente: poner más hierro. Total, si ya funciona mal, con más recursos irá mejor, ¿no?

Pues sí. Durante un rato. Luego viene otra consulta igual de mala y vuelta a empezar. El patrón es de sobra conocido: base de datos lenta, compras hardware, mejora temporal, vuelve la lentitud, compras más hardware… y cuando te das cuenta, estás alimentando un monstruo que vive de cores, GB y licencias.

Y aquí entra la broma que siempre duele: SQL Server se licencia por core. Así que cada vez que decides “arreglar” un problema de rendimiento añadiendo CPU, estás aceptando voluntariamente pagar más en licencias, que no son baratas. Es como combatir la sed bebiendo agua salada: parece que ayuda, pero en realidad te estás hundiendo más.

El coste real en la nube: «elástico», sí, pero hacia arriba

Muchos creen que al migrar a la nube el problema desaparece. Que Azure SQL, AWS RDS o cualquier plataforma PaaS mágica va a solucionar lo que tu SELECT * no quiso arreglar. Y no, no es así.

En la nube todo se factura. Cada milisegundo de CPU, cada MB de RAM, cada GB de almacenamiento y cada IO de disco. Una consulta ineficiente en Azure no solo es lenta: es cara. Muy cara. Porque, a diferencia de tu servidor físico en el CPD, aquí no tienes un coste hundido. Aquí cada operación se convierte en un apunte contable. Y si te pasas, la factura no perdona.

He visto clientes triplicar su consumo mensual de Azure SQL sin añadir ni un solo usuario más. ¿La causa? Un informe mal diseñado, una vista que arrastra medio millón de registros y un desarrollador con más entusiasmo que criterio.

Una historia real de coste en azure

Y luego están los casos como este. Años atrás, un cliente me llamó porque su Azure SQL Managed Instance con 8 cores (unos 1.355€ al mes) tenía la CPU por encima del 90% casi todo el día, con picos constantes al 100% que parecían avisos de incendio. Lo más grave no era eso, sino que ya habían asumido que la única salida era duplicar recursos y pasar a 16 cores, lo que dispararía la factura a 2.700€/mes. Antes de firmar el salto, decidieron llamarme. Por suerte.

Lo que me encontré era un festival del despropósito. Ni un solo índice clustered, todos los índices nonclustered eran de una sola columna y, por supuesto, sin INCLUDE. Mirando el uso, el 95% de esos índices no se usaban. Y claro, la DMV de índices faltantes parecía la lista de tareas de un becario sin supervisión: infinita, desordenada y sin lógica.

Con un par de días de trabajo serio (revisión de patrones de consulta y una política de indexación con sentido común) no solo evitamos el escalado, sino que redujimos la instancia a 4 cores. El resultado fue sorprendente, CPU estable al 30% incluso en horas pico. Lo que se dice, respirar. Pero además, más de 25.000€ al año de ahorro respecto a la solución que estaban a punto de contratar.

El coste del “Pero si se lanza una vez al año…”

Ya que me he puesto en plan cuentacuentos, déjame contarte otra de esas anécdotas que se graban a fuego.

Un día me encontré con un informe, hecho en Tableau (pero eso es lo de menos), que lanzaban una vez al año y que tardaba en completarse… 22 horas. Bueno, yo lo pillé cuando llevaba 22 horas de ejecución en el SQL Server de producción, a saber cuánto más le quedaba. Cuando lo comenté, me dijeron que no pasaba nada, que solo se lanzaba una vez al año y que solían dejarlo corriendo de un día para otro, como quien pone la olla lenta con garbanzos.

Pero yo lo vi claro. La consulta tenía 47 subconsultas en el SELECT. Si, si, CUARENTA Y SIETE. No índices raros, no estructuras marcianas, solo una estructura de consulta absurda.

¿El cambio? Reescribir con LEFT JOIN bien definidos en lugar de esas subconsultas incrustadas. Nada más. Bueno si, una subconsulta que se repetía bastantes veces muy parecida se persistió como temporal al inicio del proceso. De esa manera los datos se leian y filtraban de una tabla grande una sola vez y se quedaban en una tabla pequeña para consultar el resto de las veces. Pero nada más, ni cambiar índices, ni tocar el esquema. Vamos, sin reformar la casa. ¿El resultado? Menos de 20 milisegundos.

Y esto amigos, esto no es una mejora. Eso es pasar de enviar la consulta en burro a ponerle un cohete. Y no exagero.

Porque no todo el coste es culpa del desarrollador

No vamos a demonizar. Todos hemos escrito consultas que después nos dieron vergüenza ajena. Y sí, hay veces que las prisas, las entregas y los deadlines te llevan a empalmar un par de subconsultas “de emergencia” con un UNION sin ALL y a mirar para otro lado.

Pero eso no justifica dejar ese código en producción durante años como si fuera parte del mobiliario. Porque esa consulta, aunque solo se ejecute una vez al día, puede ser la responsable de saturar el servidor, disparar el DTU en Azure o arrastrar a otras aplicaciones con ella.

Aquí entra en juego lo que me gusta llamar “el coste invisible de la desidia técnica”. No se ve, no se presupuesta, pero se paga igual. En horas de soporte, en tiempo perdido, en usuarios frustrados, en reputación quemada.

De 10 minutos a 2 milisegundos (sin efectos especiales)

Otra historia real, por si alguien aún cree que exagero.

Me llama un cliente porque un proceso tarda más de 10 minutos. Revisamos el plan de ejecución y canta como un tenor: falta un índice. Literalmente lo está pidiendo a gritos. Un Clustered Index Scan sobre una tabla de 10 millones de registros con 5 campos varchar(max).

Creamos un índice sencillo sobre los dos campos que busca… y bajamos a 20 segundos. Bien, ¿no?

Pero no me conformé. Me di cuenta de que esos campos varchar(max) apenas se usaban y propuse moverlos a otra tabla. Un cambio mínimo de esquema, sin traumas. El resultado: la consulta se resuelve ahora en 2 milisegundos.

Sí, de más de diez minutos a dos milisegundos. Sin comprar licencias, sin añadir cores, sin tirar la casa por la ventana. Solo sentido común.

Consultas eficientes, bases de datos rentables

Optimizar una consulta no es hacer magia negra ni sacrificar cabras sobre el plan de ejecución. Es técnica, análisis y experiencia. A veces basta con añadir un índice. O con quitar un SELECT * y poner solo las columnas que necesitas. O con evitar ese cursor que llevas arrastrando desde hace 10 años como si fuera un trauma sin resolver.

Una consulta optimizada no sólo corre más rápido. Consume menos CPU. Bloquea menos. Permite que más usuarios trabajen al mismo tiempo. Y, lo más importante, reduce directamente tu coste de infraestructura y licenciamiento.

No es filosofía, son matemáticas puras, si una consulta tarda 500 ms y logra pasar a 50 ms, puedes hacer 10 veces más operaciones con los mismos recursos. ¿Te imaginas que tu equipo hiciera 10 veces más tareas al mismo sueldo? Eso es lo que hace una base de datos bien afinada.

El coste del «si funciona, no lo toques»

Una de las excusas más repetidas cuando se habla de optimizar es: “Pero si ya funciona, ¿para qué meternos ahí?” Pues por eso mismo. Porque ahora va, pero mal. Y cada día que pasa, cada usuario que se conecta, cada nuevo informe que se genera, lo hace un poco peor.

La deuda técnica no caduca. Se acumula. Y cuando salta, no lo hace con un error bonito y fácil de arreglar. Lo hace con un rendimiento desastroso en el peor momento: justo antes del cierre contable, durante el Black Friday o cuando el CEO quiere ver “cómo va todo” desde Power BI (todo casos reales).

Si optimizar parece caro, espera a ver cuánto cuesta no hacerlo.

Formación, experiencia y algo de mala leche

Sí, optimizar lleva tiempo. Requiere saber leer planes de ejecución, entender estadísticas, conocer cómo SQL Server decide qué estrategia usar y cuándo. Pero también requiere actitud. Ganas de escarbar. De no conformarse con que funcione “más o menos”.

Y eso, lamentablemente, no lo da ningún botón mágico ni el asistente del Management Studio. Hay que aprenderlo. O contratar a alguien que lo sepa.

Aquí es donde entra mi parte, claro. No solo como autor de este blog, sino también como consultor. Llevo más de 12 años viendo barbaridades que harían llorar al optimizador de consultas. Y ayudando a equipos a entender por qué sus bases de datos son lentas, y cómo hacer que dejen de serlo sin hipotecar la nube ni sacrificar fines de semana enteros en tareas de mantenimiento que no deberían existir.

Y sí, estoy escribiendo un libro

Mi libro se va a llamar “SQL SERVER: La NO guía práctica de optimización”. Y no será el típico tocho con recetas milagrosas genéricas que nadie es capaz de aplicar en producción. Será un manual honesto, directo y realista. Uno que explica cómo optimizar sin morir en el intento, desde la base y comprendiendo el funcionamiento interno del motor de base de datos. Porque ya tenemos demasiadas presentaciones bonitas que no dicen nada.

El libro de SQL Server que estabas esperando… está en camino

Y sí, también haré formación. Y talleres. Y sesiones donde, si hace falta, nos peleamos con los planes de ejecución hasta que canten. Porque se puede. Porque debe hacerse. Y porque seguir pagando licencias por no optimizar… simplemente no tiene sentido.

¿Quieres dejar de pagar por no saber? Hablemos.

Si después de leer esto has pensado en esa consulta que lleva años sin tocar, en ese informe que tarda 12 minutos, o en ese servidor que cada semana pide más cores como si fueran cromos… ya sabes lo que hay.

Puedes seguir ignorándolo, puedes aprender cómo optimizar SQL Server o puedes llamarme y lo miramos juntos.

Tu factura lo va a notar.

Infra

Canalizaciones por nombre (Named Pipes) en SQL Server

¿Qué demonios son las canalizaciones por nombre?

TCP/IP vs Canalizaciones por nombre: ¿por qué seguimos hablando de esto?

¿Cuándo tienen sentido las Named Pipes?

Cómo funcionan realmente las canalizaciones por nombre

¿Qué pasa si dejo las canalizaciones por nombre activadas “por si acaso”?

¿Y si las necesito, cómo las activo (o desactivo)?

¿Qué protocolo prioriza SQL Server?

Conclusión

Backups en SQL Server Always On y novedades en SQL Server 2025

¿Dónde se hacen los backups en un Availability Group?

Únete a la newsletter de SoyDBA

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

Tipos de backups permitidos hasta SQL Server 2022

¿Qué cambiará en los backups de AG con SQL Server 2025?

Cómo configurarlo (y cómo comprobarlo)

Consideraciones importantes y limitaciones

¿Cómo adaptar tu estrategia de backups?

Conclusión

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes