Roberto Carrancio

Mi nombre es Roberto Carrancio y soy un DBA de SQL server con más de 10 años de experiencia en el sector. Soy el creador del blog soydba.es donde intento publicar varios artículos a la semana (de lunes a viernes que los fines de semana me gusta estar con mi gente y disfrutar de mi moto) Espero que disfrutes leyendo este blog tanto como yo disfruto escribiendo y que te sea de utilidad. Si tienes alguna sugerencia, pregunta o comentario, puedes dejarlo al final de cada entrada o enviarme un correo electrónico. Estaré encantado de leerte y responderte. ¡Gracias por tu visita! Mi principal interés es compartir mi conocimiento sobre bases de datos con todo el que quiera aprenderlo. Me parece un mundo tan apasionante como desconocido. Fuera de lo profesional me encanta la cocina, la moto y disfrutar de tomar una cervecita con amigos.
Mi nombre es Roberto Carrancio y soy un DBA de SQL server con más de 10 años de experiencia en el sector. Soy el creador del blog soydba.es donde intento publicar varios artículos a la semana (de lunes a viernes que los fines de semana me gusta estar con mi gente y disfrutar de mi moto) Espero que disfrutes leyendo este blog tanto como yo disfruto escribiendo y que te sea de utilidad. Si tienes alguna sugerencia, pregunta o comentario, puedes dejarlo al final de cada entrada o enviarme un correo electrónico. Estaré encantado de leerte y responderte. ¡Gracias por tu visita! Mi principal interés es compartir mi conocimiento sobre bases de datos con todo el que quiera aprenderlo. Me parece un mundo tan apasionante como desconocido. Fuera de lo profesional me encanta la cocina, la moto y disfrutar de tomar una cervecita con amigos.
06
Oct
2025

Guía para reclutar perfiles SQL sin morir en el intento. Manual para RRHH

¿Alguna vez has tenido que cubrir un puesto relacionado con bases de datos SQL y has sentido que el perfil parecía más un conjuro que una oferta de empleo? Tranquilo, no estás solo. Lo de “buscamos un DBA que también sepa de Power BI, Python, backups, modelado de datos, administración de Azure, tuning de consultas, y que además tenga skills de comunicación” no es una exageración. Es literalmente lo que me he encontrado más de una vez. Y no, no es viable.

Este artículo no es para criticar (bueno, solo un poco), sino para ayudar. Está dirigido a profesionales de selección de personal que, sin ser técnicos, tienen que enfrentarse al reto de reclutar a alguien que sí lo es. Alguien que, además, trabaja con eso tan abstracto y escurridizo que es “el mundo SQL”.

Vamos a dejar claras las diferencias entre los principales perfiles de datos que tocan SQL, porque no todos hacen lo mismo, y desde luego no se les puede tratar como si fueran intercambiables. También repasaremos un glosario básico de términos que no hacen falta dominar, pero sí reconocer para no quedar en evidencia durante una entrevista.

Todos tocan SQL, pero no son lo mismo

Lo primero que hay que entender es que “saber SQL” no define un perfil. Es como decir que alguien que sabe escribir puede ser novelista, abogado, periodista o copywriter. Todos escriben, pero no tienen el mismo rol ni se enfrentan a los mismos problemas.

El DBA (Database Administrator)

El DBA es el responsable de que la base de datos funcione. Y no me refiero solo a que “funcione”, sino a que sea segura, estable, rápida y que no explote cuando más falta hace. Hay varios tipos de DBAs: los hay de infraestructura (montan y configuran el servidor, las instancias, se pelean con el almacenamiento), de rendimiento (se dedican a afinar consultas, crear índices, revisar planes de ejecución), y también los que cubren todo y sobreviven a base de café y alerts.

No confundas un DBA de SQL Server con uno de Oracle, ni con uno de PostgreSQL. No, no son equivalentes. Los conceptos se parecen, pero los comandos, herramientas, modos de operar y hasta las buenas prácticas cambian.

El desarrollador SQL o de BI

Este perfil sí escribe SQL todos los días, pero con un objetivo muy distinto al del DBA. Se dedica a generar consultas, crear procedimientos almacenados, hacer informes, alimentar modelos de datos o integrar fuentes externas. Suele moverse en entornos de reporting, ETL o modelado. Si sabe hacer backups, probablemente es porque un día le tocó hacerlo a él y no había nadie más.

El analista de datos

Aquí la confusión es habitual. El analista suele consumir datos, no gestionarlos. Sabe lanzar consultas (normalmente sencillas), trabajar con herramientas de visualización como Power BI o Tableau, y generar conclusiones. No se le puede pedir que optimice un índice ni que diseñe un modelo físico de base de datos. Es otro rol.

El ingeniero de datos

Este perfil está más cerca de la infraestructura moderna, los pipelines, la automatización y las arquitecturas distribuidas. Sabe de SQL, pero también de Spark, Azure Data Factory, Synapse, Databricks y similares. Le puedes hablar de particionamiento, de lag en streaming y de integración con data lakes, pero probablemente no sabe mucho de tuning en SQL Server.

Y sí, la tecnología importa

Cada sistema gestor tiene sus peculiaridades. Un experto en MySQL no puede entrar mañana a administrar SQL Server sin un mínimo periodo de adaptación. Ni los comandos son los mismos, ni las herramientas de administración, ni el enfoque. Que todos hablen SQL no significa que hagan lo mismo.

Errores frecuentes al redactar una oferta de trabajo técnica con SQL

Si has cometido alguno de estos, no te preocupes. A todos nos ha pasado. Pero aquí van unas cuantas cosas que conviene evitar:

  1. Mezclar perfiles incompatibles. Pedir un “DBA que también haga ETLs y reporting” es como buscar un fontanero que repare calderas y además pinte retratos al óleo. Existen, pero no son baratos, y no es razonable esperarlo por defecto.
  2. Lista de tecnologías sin criterio. SSIS, Airflow, Glue, Informatica, Talend… todos en el mismo párrafo. Sin contexto. Como si fueran toppings de pizza. A veces da la sensación de que la lista la ha hecho alguien buscando palabras clave en LinkedIn.
  3. Pedir cosas que no existen. Sí, me han preguntado por experiencia en “Azure SSMS”. No existe. También he visto peticiones de “conocimiento en procedimientos triggers” (¿?) o “optimización de tablas SQL BI” (lo que quiera que eso signifique).
  4. No diferenciar versiones ni entornos. SQL Server 2008 no es lo mismo que SQL Server 2019. Trabajar on-prem no tiene nada que ver con gestionar instancias en Azure SQL Database. Acláralo en la oferta. Y si no lo sabes, pregunta.

Glosario básico para RRHH sin miedo a SQL

Aquí tienes una lista de términos que deberías reconocer, aunque sea para no pronunciar mal en una entrevista. No hace falta que los expliques, pero sí que te suenen:

  • SQL: Es el lenguaje universal de consultas en las bases de datos relacionales.
  • SQL Server: Es el servidor de bases de datos relacionales de Microsoft. Otros servidores de bases de datos son Oracle, MySQL o PostgreSQL. No son lo mismo aunque hacen más o menos lo mismo. Gestionar bases de datos.
  • Índice: estructura que acelera la búsqueda de datos. Como un índice en un libro. Si no lo hay, todo va más lento.
  • Consulta / Query: es el código SQL que se lanza para obtener o modificar datos. “SELECT * FROM…” es un clásico.
  • Stored Procedure: código SQL almacenado en la base de datos, que encapsula lógica de negocio o consultas complejas.
  • Backup / Restore: copia de seguridad y su recuperación. Sin esto, todo lo demás da igual. Pregunta por esto siempre.
  • Job: tarea programada que se ejecuta en el servidor de base de datos. Sirve para automatizar procesos.
  • ETL / ELT: extracción, transformación y carga de datos. Básico en entornos de integración y reporting.
  • T-SQL: dialecto de SQL propio de Microsoft SQL Server. No es igual que PL/SQL (Oracle) ni que el de PostgreSQL (PG/SQL).
  • Instancia / Servidor / Motor: conceptos que conviene no confundir. Una instancia es una instalación del motor de base de datos, que puede convivir con otras en el mismo servidor físico o virtual.
  • Alta disponibilidad (HA): técnicas para asegurar que la base de datos siga funcionando aunque haya fallos.
  • Licenciamiento: aquí es donde empieza el dolor. SQL Server se licencia por núcleo, y en la nube cada modelo cambia.
  • On-prem / Cloud / Híbrido: dónde vive la base de datos. En tu infraestructura, en la nube, o una mezcla.
  • Monitorización: observar en tiempo real qué pasa en la base de datos. Métricas, alertas, salud del sistema.
  • Tuning / Plan de ejecución: afinar consultas lentas, revisar cómo se ejecutan internamente y optimizarlas.
  • Always On: Es una solución de Alta Disponibilidad avanzada propia de SQL Server.

Cómo no hacer el ridículo en una entrevista técnica

Muchas veces me ha pasado que me llama un reclutador al que han dado una lista de deseos y se ve que es la primera vez que lee alguno de los términos. Es que hasta se traban al leer las palabras técnicas raras. No se trata de fingir que sabes. Eso se nota. Pero tampoco de leer la oferta delante del candidato y esperar que te la explique. Aquí algunos consejos:

  • Haz preguntas abiertas. Por ejemplo: “¿Qué tareas asumías como DBA en tu anterior puesto?”, en vez de recitar tecnologías.
  • Escucha palabras clave. Si te dicen que hacían backups, mantenimiento, planes de ejecución… vas por buen camino.
  • No interrumpas con tecnicismos que no manejas. Si el candidato menciona un término que no conoces, anótalo y consulta después. Preguntar “¿y eso es como un Excel, pero en la nube?” no ayuda.
  • Si hay técnico en el equipo, involúcralo. Un screening técnico a tiempo evita semanas de procesos mal encaminados. 
  • Entiende lo que buscas. No se trata de que seas un experto pero lee antes la oferta, busca en google los conceptos que no entiendas. No tienes que profundizar pero, por lo menos que te suene de qué va la cosa.
  • Y sobre todo, no improvises. Si el perfil es muy técnico y no sabes por dónde empezar, reconoce tus límites. No es debilidad. Es profesionalidad.

Conclusión

Buscar talento técnico sin entender lo que se busca no solo alarga el proceso, sino que lo devalúa. Quien sabe del tema nota al vuelo cuándo quien lo entrevista no ha leído ni entendido la mitad del puesto. Si el candidato es bueno, se irá. Y si no se va, pregúntate por qué.

Este artículo no pretende convertirte en DBA, ni falta que hace. Pero sí ayudarte a no tratar a todos los perfiles SQL como si fueran lo mismo. Porque no lo son. Y porque si seguimos publicando ofertas imposibles, al final lo único que vamos a reclutar… es silencio.

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 Otros, 0 comentarios
03
Oct
2025

Procedimientos almacenados y Funciones. SQL Server Basics

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

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

Entendiendo la diferencia de base

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

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

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

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

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

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

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

Funciones: elegantes, encapsuladas… y peligrosas

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

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

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

Principales diferencias técnicas y funcionales

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

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

Rendimiento: el gran elefante en la sala

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

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

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

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

Casos de uso típicos (sin liarla)

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

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

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

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

La trampa de la reutilización mal entendida

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

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

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

Conclusión

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

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

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

Sargabilidad: el arte de no cabrear al optimizador

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

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

Qué es la sargabilidad (de verdad)

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

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

Un ejemplo básico:

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

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

Las funciones son el enemigo (cuando no sabes usarlas)

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

Veamos otro clásico:

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

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

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

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

Sargabilidad 2

ISNULL y COALESCE: los rompeíndices silenciosos

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

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

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

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

Sargabilidad 3

ISNULL(): sorprendentemente sargable

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

DisplayName = 'Juan' OR DisplayName IS NULL

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

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

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

COALESCE(): aquí sí se complica

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

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

El OR: ese sospechoso habitual

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

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

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

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

Las columnas calculadas como tabla de salvación

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

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

Puedes añadir una columna calculada persistente:

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

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

El caso especial del LIKE

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

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

Esta no:

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

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

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

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

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

Mira este caso donde CreationDate es un campo DATETIME:

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

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

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

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

Porque si haces esto:

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

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

Sargabilidad 5

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

JOINs y sargabilidad: el otro lado del desastre

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

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

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

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

Cómo detectar consultas no sargables

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

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

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

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

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

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

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

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

Conclusión

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

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

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

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

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

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

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

Junior no es sinónimo de becario

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

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

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

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

Logo SoyDBA

Únete a la newsletter de SoyDBA

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

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

Senior no es el junior que lleva más tiempo

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

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

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

Las horas que se cuentan (o no se cuentan)

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

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

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

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

El mito del experto

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

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

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

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

¿Y los niveles intermedios?

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

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

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

La falacia de la experiencia acumulada

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusión

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

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

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

Opciones de Quorum para un clúster Always On

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

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

El Quorum no es una opinión

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

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

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

Tipos de Quorum en WSFC

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

Node Majority (Mayoría de nodos)

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

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

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

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

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

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

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

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

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

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

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

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

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

No Majority: Disk Only (Solo disco)

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

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

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

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

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

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

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

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

Always On y el testigo olvidado

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

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

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

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

Casos típicos y cómo configurarlos bien

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

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

Conclusión

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

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

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

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

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