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 usa 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 usar 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 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 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 clúster 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 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 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 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 usa el mismo número de subprocesos hasta que la operación se completa. El 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 los dinámicos 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 usar 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 usar 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 usados por una operación con los de los usuarios simultáneos. Establecer la opción max degree of parallelism en 0 permite a SQL Server usar todos los procesadores disponibles hasta un máximo de 64 procesadores en la ejecución de un plan paralelo. Establecer MAXDOP en 0 para las consultas y los índices permite a SQL Server usar todos los procesadores disponibles hasta un máximo de 64 para las consultas o los índices dados en la ejecución de un plan paralelo.