SQL Server

03
Oct
2025

Procedimientos almacenados y Funciones. SQL Server Basics

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

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

Entendiendo la diferencia de base

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

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

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

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

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

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

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

Funciones: elegantes, encapsuladas… y peligrosas

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

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

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

Principales diferencias técnicas y funcionales

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

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

Rendimiento: el gran elefante en la sala

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

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

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

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

Casos de uso típicos (sin liarla)

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

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

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

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

La trampa de la reutilización mal entendida

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

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

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

Conclusión

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

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

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

Sargabilidad: el arte de no cabrear al optimizador

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

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

Qué es la sargabilidad (de verdad)

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

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

Un ejemplo básico:

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

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

Las funciones son el enemigo (cuando no sabes usarlas)

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

Veamos otro clásico:

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

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

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

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

Sargabilidad 2

ISNULL y COALESCE: los rompeíndices silenciosos

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

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

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

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

Sargabilidad 3

ISNULL(): sorprendentemente sargable

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

DisplayName = 'Juan' OR DisplayName IS NULL

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

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

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

COALESCE(): aquí sí se complica

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

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

El OR: ese sospechoso habitual

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

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

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

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

Las columnas calculadas como tabla de salvación

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

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

Puedes añadir una columna calculada persistente:

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

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

El caso especial del LIKE

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

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

Esta no:

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

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

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

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

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

Mira este caso donde CreationDate es un campo DATETIME:

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

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

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

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

Porque si haces esto:

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

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

Sargabilidad 5

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

JOINs y sargabilidad: el otro lado del desastre

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

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

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

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

Cómo detectar consultas no sargables

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

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

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

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

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

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

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

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

Conclusión

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

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

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

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

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

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

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

Junior no es sinónimo de becario

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

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

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

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

Logo SoyDBA

Únete a la newsletter de SoyDBA

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

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

Senior no es el junior que lleva más tiempo

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

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

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

Las horas que se cuentan (o no se cuentan)

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

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

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

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

El mito del experto

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

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

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

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

¿Y los niveles intermedios?

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

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

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

La falacia de la experiencia acumulada

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusión

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

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

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

Opciones de Quorum para un clúster Always On

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

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

El Quorum no es una opinión

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

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

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

Tipos de Quorum en WSFC

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

Node Majority (Mayoría de nodos)

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

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

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

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

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

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

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

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

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

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

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

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

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

No Majority: Disk Only (Solo disco)

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

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

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

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

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

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

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

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

Always On y el testigo olvidado

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

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

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

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

Casos típicos y cómo configurarlos bien

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

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

Conclusión

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

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

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

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 0 comentarios
24
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!

Publicado por Roberto Carrancio en SQL Server, 0 comentarios
22
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.

Portada Libro

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

Logo SoyDBA

Únete a la newsletter de SoyDBA

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

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

Publicado por Roberto Carrancio en Alta Disponibilidad, Cloud, Índices, Rendimiento, SQL Server, 0 comentarios
19
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.

Logo SoyDBA

Únete a la newsletter de SoyDBA

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

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

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.

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!

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