Grado de paralelismo
SQL Server detecta de forma automática el mejor grado de paralelismo para cada instancia de una ejecución de consulta en paralelo o de una operación de índice del lenguaje de definición de datos (DDL). Para ello utiliza los siguientes criterios:
Si SQL Server se ejecuta en un equipo que disponga de más de un microprocesador o CPU, por ejemplo, un equipo de multiproceso simétrico (SMP).
Sólo los equipos con más de una CPU pueden utilizar consultas en paralelo.
Si hay suficientes subprocesos disponibles
Cada operación de consulta o índice requiere que se ejecute un determinado número de subprocesos. La ejecución de un plan en paralelo requiere más subprocesos que un plan en serie, y el número de subprocesos aumenta con el grado de paralelismo. Si no es posible cumplir el requisito de subproceso del plan en paralelo para un grado de paralelismo específico, el Database Engine (Motor de base de datos) reduce automáticamente el grado de paralelismo o abandona por completo el plan en paralelo en el contexto de carga de trabajo especificado. Es entonces cuando ejecuta un plan en serie (un subproceso).
El tipo de operación de consulta o índice ejecutado.
Las operaciones de índice que crean o vuelven a crear un índice, o que eliminan un índice clúster o las consultas que utilizan constantemente los ciclos de la CPU, son los candidatos idóneos para un plan de paralelismo. Por ejemplo, las combinaciones de tablas grandes, agregaciones importantes y la ordenación de grandes conjuntos de resultados son buenos candidatos. En las consultas simples, que suelen encontrarse en aplicaciones de procesamiento de transacciones, la coordinación adicional necesaria para ejecutar una consulta en paralelo es más importante que el aumento potencial del rendimiento. Para distinguir entre las consultas que se benefician del paralelismo y las que no, el Database Engine (Motor de base de datos) compara el costo estimado de ejecutar la consulta o el índice de operación con el valor de cost threshold for parallelism. Aunque no se recomienda, los usuarios pueden cambiar el valor predeterminado de 5 mediante sp_configure.
Si hay un número suficiente de filas para procesar.
Si el optimizador de consultas determina que el número de filas es demasiado bajo, no proporciona operadores de intercambio para distribuir las filas. En consecuencia, los operadores se ejecutan en serie. Ejecutar los operadores en un plan en serie evita los escenarios en que el costo del inicio, distribución y coordinación excede las ganancias logradas mediante la ejecución del operador en paralelo.
Si las estadísticas de distribución actuales están disponibles.
Si no es posible establecer el grado de paralelismo más alto, se tienen en cuenta los grados inferiores antes de abandonar el plan en paralelo.
Por ejemplo, cuando sea crea un índice agrupado en una vista, las estadísticas de distribución no se pueden evaluar porque el índice clúster aún no existe. En este caso, el Database Engine (Motor de base de datos) no puede proporcionar el grado de paralelismo más alto para la operación de índice. Sin embargo, algunos operadores, como sorting y scannig, se siguen beneficiando de la ejecución en paralelo.
[!NOTA]
Las operaciones de índices en paralelo están únicamente disponibles en las ediciones Enterprise, Developer y Evaluation de SQL Server.
En tiempo de ejecución, el Database Engine (Motor de base de datos) determina si la carga de trabajo actual del sistema y la información de configuración descrita previamente permiten la ejecución en paralelo. Si se garantiza la ejecución en paralelo, el Database Engine (Motor de base de datos) determina el número óptimo de subprocesos y propaga la ejecución del plan en paralelo a esos subprocesos. Cuando una operación de consultas o índices empieza a ejecutarse en varios subprocesos para la ejecución en paralelo, se utiliza el mismo número de subprocesos hasta que la operación se completa. El Database Engine (Motor de base de datos) vuelve a examinar el número óptimo de decisiones de subprocesos cada vez que se recupera un plan de ejecución de la caché de procedimientos. Por ejemplo, la ejecución de una consulta puede realizarse mediante un plan en serie, una ejecución posterior de la misma consulta puede hacerse mediante un plan en paralelo con tres subprocesos y una tercera ejecución puede ejecutarse en un plan en paralelo con cuatro subprocesos.
En un plan de ejecución de consultas en paralelo, los operadores insert, update y delete se ejecutan en serie. Sin embargo, la cláusula WHERE de una instrucción UPDATE o DELETE, o la parte SELECT de una instrucción INSERT pueden ejecutarse en paralelo. Los cambios reales de los datos se aplican en serie a la base de datos.
Los cursores estáticos y controlados por conjunto de claves pueden llenarse mediante planes de ejecución en paralelo. Sin embargo, el comportamiento de los cursores dinámicos sólo puede proporcionarse mediante la ejecución en serie. El optimizador de consultas siempre genera un plan de ejecución en serie para una consulta que es parte de un cursor dinámico.
Anular grados de paralelismo
Puede utilizar la opción de configuración del servidor max degree of parallelism para limitar el número de procesadores que se utilizarán en la ejecución del plan en paralelo. La opción max degree of parallelism puede anularse para las instrucciones de operaciones de consultas e índices individuales especificando la sugerencia de consulta MAXDOP o la opción de índice MAXDOP. MAXDOP proporciona un mayor control sobre las operaciones de consultas e índices individuales. Por ejemplo, puede utilizar la opción MAXDOP para controlar, mediante la ampliación o la reducción, el número de procesadores dedicados en una operación de índices en línea. De este modo, es posible equilibrar los recursos utilizados por una operación con los de los usuarios simultáneos.