Grado de paralelismo
SQL Server 2005 detecta automáticamente el mejor grado de paralelismo para cada instancia de una ejecución de una consulta en paralelo o lenguaje de definición de datos de índices (DDL). Para ello utiliza los siguientes criterios:
- Si SQL Server se ejecuta en un equipo con 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 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 actual. 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 agrupado 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, SQL Server compara el costo estimado de ejecutar la consulta 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.
En las versiones anteriores de SQL Server, el motor de base de datos dejaba de lado los planes en paralelo si las estadísticas disponibles impedían al motor de base de datos proporcionar el mayor grado posible de paralelismo. En SQL Server 2005, si el grado de paralelismo más alto no es posible, 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 agrupado 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 índice en paralelo sólo están disponibles en SQL Server 2005 Enterprise Edition.
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 utiliza 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 de conjuntos 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.
Vea también
Conceptos
Establecer las opciones de configuración del servidor
max degree of parallelism (opción)
Procesar una consulta en paralelo
Operaciones de índice en paralelo
Otros recursos
sp_configure (Transact-SQL)
Query Hint (Transact-SQL)