DOP Feedback en SQL Server 2022: optimización adaptativa del paralelismo

En el ámbito del Business Intelligence y la gestión de almacenes de datos, el paralelismo es un arma de doble filo. Si bien permite procesar grandes volúmenes de información en tablas de Ventas o Hechos dividiendo la carga entre varios hilos, un exceso de paralelismo (Over-parallelism) puede ser devastador. Hasta ahora, los consultores nos veíamos obligados a ajustar el Max Degree of Parallelism (MAXDOP) a nivel de instancia o de base de datos, basándonos en reglas generales que no siempre se adaptaban a la variabilidad de las consultas analíticas. Con la llegada de SQL Server 2022 y la característica DOP Feedback, el motor de base de datos adquiere la capacidad de aprender de su propia experiencia.

DOP Feedback forma parte de la familia de características de Intelligent Query Processing (IQP). Su propósito es sencillo pero potente: identificar consultas que están utilizando demasiados hilos de ejecución sin obtener un beneficio proporcional en tiempo de respuesta, y reducir ese grado de paralelismo de forma automática en ejecuciones futuras. No se trata de una solución mágica que elimine la necesidad de un buen diseño de índices, pero sí es una red de seguridad crítica para evitar el consumo innecesario de CPU que suele lastrar a los servidores con cargas mixtas.

Como consultores, a menudo vemos cómo una consulta mal optimizada, quizás debido a un OR en el WHERE mal planteado, intenta usar todos los núcleos disponibles del servidor, bloqueando al resto de usuarios y saturando los tiempos de espera del sistema. DOP Feedback intenta mitigar este comportamiento errático ajustando el paralelismo de manera quirúrgica, consulta por consulta.

¿Qué problema resuelve exactamente DOP Feedback?

El paralelismo excesivo ocurre cuando el coste de gestionar múltiples hilos (overhead de sincronización, intercambios de contexto y esperas de tipo CXPACKET) supera el ahorro de tiempo que se obtiene al procesar los datos en paralelo. En muchos proyectos de retail o industria, donde las consultas pueden variar desde simples agregaciones hasta joins masivos de 10 tablas, configurar un MAXDOP fijo para todo el servidor es ineficiente.

Si configuramos un MAXDOP de 8, una consulta que solo necesita 2 hilos para ser eficiente podría intentar usar los 8, consumiendo recursos que otros procesos necesitan. DOP Feedback observa el rendimiento de la consulta (tiempo de CPU vs. tiempo de duración total) y, si detecta ineficiencias, reduce el grado de paralelismo. Es un proceso iterativo: el motor prueba con un DOP menor, mide de nuevo y, si el rendimiento mejora o se mantiene consumiendo menos recursos, estabiliza ese nuevo valor.

Es fundamental entender que esta característica requiere que el Query Store esté activo y en modo de lectura/escritura, ya que es ahí donde se almacena la información histórica necesaria para tomar estas decisiones. Sin persistencia de datos de ejecución, el motor no puede comparar si el cambio de DOP ha sido beneficioso o perjudicial.

Cómo habilitar DOP Feedback en SQL Server 2022

Para utilizar DOP Feedback, la base de datos debe estar configurada con el nivel de compatibilidad 160 (el correspondiente a SQL Server 2022). Además, debemos asegurarnos de que el Query Store esté funcionando correctamente. A diferencia de otras funciones de IQP, DOP Feedback está diseñado para ser conservador: solo actúa cuando hay una evidencia clara de regresión por paralelismo.

-- 1. Cambiar el nivel de compatibilidad a SQL Server 2022
ALTER DATABASE [TuBaseDeDatosBI] SET COMPATIBILITY_LEVEL = 160;
GO

-- 2. Asegurarse de que Query Store esté activo
ALTER DATABASE [TuBaseDeDatosBI] SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE);
GO

-- 3. Habilitar específicamente DOP Feedback a nivel de base de datos
ALTER DATABASE SCOPED CONFIGURATION SET DOP_FEEDBACK = ON;
GO

Una vez activado, el motor empezará a monitorizar las consultas. Es importante recalcar que no todas las consultas son candidatas. SQL Server busca patrones repetitivos. Si una consulta de carga de un Data Lakehouse hacia una tabla de Dimensiones se ejecuta una sola vez al mes, es probable que DOP Feedback no tenga datos suficientes para intervenir. Sin embargo, para informes recurrentes de Power BI que atacan directamente al SQL, esta funcionalidad es oro puro.

El ciclo de retroalimentación: Cómo decide el motor

El proceso de ajuste no es instantáneo. Sigue un flujo lógico que garantiza que no se tomen decisiones precipitadas basadas en una ejecución anómala:

• Análisis: El motor identifica consultas candidatas basándose en estadísticas de ejecución almacenadas en Query Store.
• Propuesta: Se genera una sugerencia para reducir el DOP (por ejemplo, de 16 a 8).
• Validación: La consulta se ejecuta con el nuevo DOP. SQL Server compara la métrica de «tiempo de CPU» y «tiempo transcurrido».
• Verificación: Si el cambio reduce el consumo de CPU sin degradar significativamente el tiempo total, la sugerencia se acepta. Si el rendimiento empeora, se descarta y se vuelve al valor anterior.

Para los que estamos acostumbrados a leer planes de ejecución en SQL Server, veremos que estas decisiones aparecen reflejadas en las vistas de sistema. No se modifica el plan de ejecución original de forma permanente, sino que se aplica una sugerencia (hint) persistente que el optimizador utiliza en tiempo de ejecución.

Monitorización y observación de resultados

No podemos limitarnos a activar la opción y olvidarnos. En entornos productivos de alta criticidad, debemos verificar qué está haciendo el motor. La vista de sistema clave para esto es sys.query_store_plan_feedback. Esta vista nos dirá qué consultas están siendo ajustadas, qué valor de DOP se está probando y si la sugerencia ha sido validada.

-- Consultar las sugerencias de DOP Feedback activas
SELECT 
 q.query_id,
 qt.query_sql_text,
 p.plan_id,
 f.feature_desc,
 f.feedback_data,
 f.state_desc,
 f.create_time,
 f.last_updated_time
FROM sys.query_store_plan_feedback AS f
JOIN sys.query_store_plan AS p ON f.plan_id = p.plan_id
JOIN sys.query_store_query AS q ON p.query_id = q.query_id
JOIN sys.query_store_query_text AS qt ON q.query_text_id = qt.query_text_id
WHERE f.feature_desc = 'DOP Feedback';

En el resultado de esta consulta, la columna state_desc es vital. Veremos estados como PendingValidation, ValidationPassed o ValidationFailed. Si vemos muchos fallos de validación, podría indicar que la carga de trabajo es demasiado volátil para que el motor encuentre un patrón estable. En tales casos, un análisis más profundo del plegado de consultas en Power Query o de la estructura de los joins podría ser necesario antes de confiar en el ajuste automático.

Comparativa: DOP Feedback frente a otros métodos de control

Precauciones en sistemas productivos

Aunque DOP Feedback es una mejora sustancial, no está exento de riesgos. En sistemas con una altísima concurrencia y consultas muy cortas, el proceso de monitorización de Query Store puede añadir un ligero overhead. Además, si tu carga de trabajo sufre de un sesgo de datos severo (como analizamos en el artículo sobre estimaciones con datos sesgados), es posible que una consulta funcione bien con DOP 2 para un cliente pequeño, pero necesite DOP 8 para un cliente masivo. DOP Feedback podría verse confundido por esta variabilidad si no se gestionan bien los parámetros.

Otro punto a considerar es que esta característica no soluciona problemas de contención de memoria o de I/O. Si tu servidor está sufriendo por falta de RAM, reducir el paralelismo puede ayudar a bajar la presión sobre la CPU, pero no resolverá la causa raíz del rendimiento pobre. Siempre utiliza herramientas como las que mencionamos en monitorización gratuita de SQL Server para tener una visión holística antes de realizar cambios estructurales.

Errores frecuentes al implementar DOP Feedback

• No tener suficiente histórico: Intentar evaluar resultados tras solo 5 minutos de activación. El motor necesita ciclos de ejecución representativos.
• Ignorar el estado del Query Store: Si el Query Store se llena y pasa a modo READ_ONLY, DOP Feedback dejará de aprender y de aplicar nuevas sugerencias.
• Compatibilidad de base de datos: Olvidar que, aunque el motor sea SQL Server 2022, si la base de datos sigue en nivel 150 (2019) o inferior, la característica no se activará.
• Conflictos con Hints manuales: Si una consulta ya tiene un hint MAXDOP hardcodeado en el T-SQL, DOP Feedback no intervendrá sobre ella.

Conclusión técnica

DOP Feedback representa un cambio de paradigma: pasamos de una administración reactiva y basada en conjeturas a una optimización proactiva basada en telemetría interna. Para cualquier consultor de BI que gestione entornos SQL Server 2022, habilitar esta característica es una recomendación estándar, siempre que se acompañe de una monitorización adecuada de las vistas de Query Store.

Preguntas frecuentes

¿DOP Feedback puede aumentar el paralelismo de una consulta?

No. Su función actual es exclusivamente reducir el paralelismo para evitar el sobreconsumo de recursos. Si una consulta está limitada por un MAXDOP de 2, el feedback no la subirá a 4 automáticamente.

¿Qué ocurre si el rendimiento empeora tras un ajuste?

SQL Server detectará la regresión en la siguiente ejecución comparando las métricas de Query Store. Si el tiempo de respuesta aumenta significativamente, el motor revertirá el cambio y volverá al DOP anterior, marcando la sugerencia como fallida.

¿Es necesario reiniciar el servidor para activar DOP Feedback?

No, los cambios de configuración de base de datos (Database Scoped Configurations) se aplican de forma inmediata y no requieren reinicio del servicio ni afectan a la disponibilidad de la base de datos.

Checklist de implementación

• Confirmar versión SQL Server 2022 (o Azure SQL DB/MI).
• Establecer nivel de compatibilidad de la base de datos a 160.
• Verificar que Query Store está en modo READ_WRITE con espacio suficiente.
• Habilitar DOP_FEEDBACK mediante ALTER DATABASE SCOPED CONFIGURATION.
• Programar una revisión semanal de sys.query_store_plan_feedback para validar el impacto.