Degré de parallélisme

SQL Server détecte automatiquement le meilleur degré de parallélisme pour chaque instance d'une exécution de requête en parallèle ou d'une opération DDL (Data Definition Language) d'index. Cette détection se fait sur la base des critères suivants :

1. SQL Server fonctionne sur un ordinateur doté de plusieurs microprocesseurs ou UC, tel qu'un ordinateur à multitraitement symétrique (SMP, symmetric multiprocessing).

   Seuls les ordinateurs dotés de plusieurs UC peuvent utiliser des requêtes en parallèle.

2. Le nombre de threads disponibles.

   Chaque requête ou opération d'index requiert un certain nombre de threads. Pour être exécuté, un plan parallèle nécessite plus de threads qu'un plan série, le nombre de threads nécessaires allant de pair avec le degré de parallélisme. Lorsque les threads disponibles sont insuffisants pour un certain degré de parallélisme, le Moteur de base de données diminue automatiquement le degré de parallélisme ou abandonne complètement le plan parallèle dans le contexte de charge de travail spécifié. Ensuite, il exécute le plan série (un thread).

3. Le type de requête ou d'opération d'index exécutée.

   Les requêtes qui utilisent fortement les cycles microprocesseur et les opérations d'index qui créent ou reconstruisent un index, ou qui suppriment un index cluster, sont les candidates idéales pour un plan parallèle. Par exemple, les jointures de grandes tables, les agrégations importantes et le tri d'ensembles de résultats volumineux s'y prêtent bien. Pour les requêtes simples, typiques des applications de traitement de transactions, il s'avère que la coordination supplémentaire nécessaire à l'exécution d'une requête en parallèle n'est pas rentabilisée par l'augmentation potentielle des performances. Pour faire la distinction entre les requêtes qui tirent profit du parallélisme et les autres, le Moteur de base de données compare le coût estimé de l'exécution de la requête ou de l'opération d'index à la valeur cost threshold for parallelism. Bien que ce ne soit pas recommandé, les utilisateurs peuvent modifier la valeur par défaut de 5 à l'aide de la procédure stockée sp_configure.

4. Le nombre de lignes à traiter.

   Si l'optimiseur de requête détermine que le nombre de lignes est trop faible, il n'introduit pas les opérateurs d'échange qui servent à distribuer les lignes. Par conséquent, ces opérateurs sont exécutés en série. L'exécution des opérateurs dans un plan série permet d'éviter que les coûts de démarrage, de distribution et de coordination dépassent les bénéfices d'une exécution en parallèle.

5. Disponibilité des statistiques de distribution actuelles.

   Si ce niveau ne peut être atteint, le moteur de base de données envisage de passer à un degré inférieur avant d'abandonner totalement le plan parallèle.

   Par exemple, lorsque vous créez un index cluster sur une vue, les statistiques de distribution ne peuvent pas être prises en compte étant donné que l'index en question n'existe pas encore. Dans ce cas, le Moteur de base de données est incapable de garantir le degré de parallélisme le plus élevé pour l'opération d'index. Toutefois, certains opérateurs, tels que le tri et l'analyse, peuvent malgré tout bénéficier de l'exécution en parallèle.

Lors de l'exécution, le Moteur de base de données détermine si la charge de travail actuelle du système et les informations de configuration décrites ci-dessus permettent une exécution parallèle. Si c'est le cas, le Moteur de base de données détermine le nombre optimal de threads et répartit l'exécution du plan parallèle parmi ces derniers. Lorsqu'une requête ou une opération d'index commence à s'exécuter en parallèle sur plusieurs threads, un nombre identique de threads est utilisé jusqu'à ce que l'opération soit terminée. Le Moteur de base de données re-examine le nombre optimal de threads chaque fois qu'un plan d'exécution est récupéré du cache de procédures. Par exemple, la première exécution d'une requête peut nécessiter l'utilisation d'un plan série, la deuxième d'un plan parallèle et de trois threads, et la troisième exécution d'un plan parallèle et de quatre threads.

Dans un plan d'exécution parallèle de requêtes, les opérateurs insert, update et delete sont exécutés en série. Cependant, la clause WHERE d'une instruction UPDATE ou DELETE, ou la partie SELECT d'une instruction INSERT peut être exécutée en parallèle. Les modifications réelles des données sont ensuite appliquées en série à la base de données.

Les curseurs statiques et les curseurs pilotés par jeux de clés peuvent être complétés par des plans d'exécution parallèle. Cependant, le comportement des curseurs dynamiques ne peut être fourni que par une exécution en série. L'optimiseur de requête génère toujours un plan d'exécution en série pour une requête qui fait partie d'un curseur dynamique.