Opérateurs qui apparaissent dans l'Explorateur de plan d'accès pour les plans d'accès dans DB2 for Linux, UNIX, and Windows

Ces opérateurs peuvent apparaître dans l'Explorateur de plan d'accès lorsque vous analysez le plan d'accès pour une instruction SQL exécutée sous DB2 for Linux, UNIX, and Windows.
Supprimer

Cet opérateur représente une opération nécessaire. Pour réduire le coût du plan d'accès, concentrez-vous sur d'autres noeuds (tels que les noeuds d'analyse et de jointure) qui définissent l'ensemble de lignes à supprimer.

Suggestions liées aux performances : Si vous supprimez toutes les lignes d'une table, pensez à utiliser l'instruction DROP TABLE ou LOAD REPLACE.

Analyse d'index définie par l'utilisateur
L'analyse utilise les conditions multiples de démarrage ou d'arrêt de la fonction du producteur de plages fournie par l'utilisateur. Cette opération permet de réduire l'ensemble de lignes de qualification avant que l'optimiseur accède à la table de base (en fonction des prédicats).
Suggestions liées aux performances :
  • Dans le temps, les mises à jour de bases de données peuvent entraîner la fragmentation d'un index, ce qui donne plus de pages d'index que nécessaire. Ceci peut être corrigé en supprimant et en recréant l'index ou en le réorganisant.
  • Si les statistiques ne sont pas à jour, mettez-les à jour à l'aide de la commande RUNSTATS.
Extraire
Cette opérateur représente l'extraction des colonnes depuis une table à l'aide d'un identificateur de colonne spécifique (RID).
Filtrer les données
Cet opérateur représente l'application de prédicats résiduels permettant de filtrer les données en fonction des critères fournis par les prédicats.
Générer des lignes de table
Cet opérateur représente une fonction intégrée qui génère une table de lignes en utilisant aucune entrée des tables, index ou opérateurs.
Regrouper par
Cet opérateur représente le regroupement de lignes conformément aux valeurs communes de colonnes ou fonctions indiquées. Cette opération est nécessaire pour créer un groupe de valeurs ou pour évaluer les fonctions définies. Si aucune colonne GROUP BY n'est spécifiée, cet opérateur peut toujours être utilisé si la liste SELECT comprend des fonctions d'agrégation. Leur présence indique que l'optimiseur traite l'intégralité de la table en tant que groupe unique lors de l'exécution de l'agrégation.
Suggestions liées aux performances :
  • Pour réduire le coût du plan d'accès, concentrez-vous sur d'autres noeuds (tels que les noeuds d'analyse et de jointure) qui définissent l'ensemble de lignes à regrouper.
  • Pour améliorer les performances d'une instruction SELECT contenant une fonction d'agrégation unique, mais aucune clause GROUP BY, procédez comme suit :
    • Pour une fonction d'agrégation MIN(C), créez un index croissant sur C.
    • Pour une fonction d'agrégation MAX(C), créez un index décroissant sur C.
Jointure hachée
Cet opérateur représente une jointure hachée pour laquelle les lignes qualifiées des tables sont hachées afin de permettre une jointure directe sans tri préalable du contenu des tables.

Une jointure est nécessaire dès qu'il y a plusieurs tables référencées dans une clause FROM. Une jointure hachée est possible dès qu'il y a un prédicat de jointure correspondant aux colonnes de deux tables différentes. Les prédicats de jointure doivent être exactement du même type de données. Les jointures hachées peuvent également provenir d'une sous-requête ré-écrite, comme c'est le cas pour des jointures de boucle imbriquées.

Une jointure hachée ne nécessite pas que les tables de saisie soient ordonnées. La jointure est effectuée en analysant la table interne de la jointure hachée et en générant une table de recherche en hachant les valeurs de la colonne de jointure. Elle lit ensuite la table extérieure en hachant les valeurs de la colonne de jointure et en enregistrant la table de recherche générée pour la table interne.

Suggestions liées aux performances :

  • Utilisez les prédicats locaux (c'est-à-dire les prédicats faisant référence à une seule table) pour réduire le nombre de lignes à joindre.
  • Augmentez la taille de la mémoire de tri pour la rendre suffisamment grande pour contenir la table de recherche de hachure.
  • Si les statistiques ne sont pas à jour, mettez-les à jour à l'aide de la commande RUNSTATS.
Inser

Cet opérateur représente une opération nécessaire. Pour réduire le coût du plan d'accès, concentrez-vous sur d'autres noeuds (tels que les noeuds d'analyse et de jointure) qui définissent l'ensemble de lignes à supprimer.

Intersection d'index
Cet opérateur représente l'ajout (AND) des résultats de plusieurs analyses d'index à l'aide des techniques Dynamic Bitmap. L'opération permet aux prédicats ajoutés d'être appliqués à plusieurs index afin de réduire au maximum les accès aux tables sous-jacentes.
Cette opération est effectuée pour :
  • Réduire l'ensemble de lignes avant d'accéder à la table de base
  • Regrouper les prédicats appliqués à plusieurs index
  • Regrouper les résultats des semi-jointures utilisées en jointures étoile.
Suggestions liées aux performances :
  • Dans le temps, les mises à jour de bases de données peuvent entraîner la fragmentation d'un index, ce qui donne plus de pages d'index que nécessaire. Ceci peut être corrigé en supprimant et en recréant l'index ou en le réorganisant.
  • Si les statistiques ne sont pas à jour, mettez-les à jour à l'aide de la commande RUNSTATS.
  • En général, les analyses d'index sont les plus efficaces lorsque seules quelques lignes sont qualifiées. Pour évaluer le nombre de lignes de qualification, l'optimiseur utilise les statistiques disponibles pour les colonnes référencées dans les prédicats. Si certaines valeurs apparaissent plus fréquemment que d'autres, il est important de demander des statistiques de distribution en utilisant la clause WITH DISTRIBUTION pour la commande RUNSTATS. Grâce aux statistiques de distribution non uniformes, l'optimiseur peut faire la distinction entre les valeurs apparaissant fréquemment et celles apparaissant rarement.
  • Cette opération peut exploiter au mieux les index de colonne uniques, car les touches de début et de fin sont importantes dans ce cadre.
Analyse d'index
Cet opérateur représente l'analyse d'un index afin de produire un flot réduit d'ID de ligne. L'analyse peut utiliser des conditions de début et de fin facultatives ou peut les appliquer à des prédicats pouvant être indexés faisant référence aux colonnes de l'index.

Cette opération permet de réduire l'ensemble d'ID de lignes de qualification avant d'accéder à la table de base (en fonction des prédicats).

Suggestions liées aux performances :
  • Dans le temps, les mises à jour de bases de données peuvent entraîner la fragmentation d'un index, ce qui donne plus de pages d'index que nécessaire. Ceci peut être corrigé en supprimant et en recréant l'index ou en le réorganisant.
  • Lorsqu'au moins deux tables sont ouvertes, l'accès à la table interne à l'aide d'un index peut être facilité si l'on fournit un index dans la colonne de jointure de la table externe.
  • Si les statistiques ne sont pas à jour, mettez-les à jour à l'aide de la commande RUNSTATS.
  • En général, les analyses d'index sont les plus efficaces lorsque seules quelques ID de ligne sont qualifiés. Pour évaluer le nombre d'ID de lignes de qualification, l'optimiseur utilise les statistiques disponibles pour les colonnes référencées dans les prédicats. Si certaines valeurs apparaissent plus fréquemment que d'autres, il est important de demander des statistiques de distribution en utilisant la clause WITH DISTRIBUTION pour la commande RUNSTATS. Grâce aux statistiques de distribution non uniformes, l'optimiseur peut faire la distinction entre les valeurs apparaissant fréquemment et celles apparaissant rarement.
Jointure par fusion
Une jointure de fusion pour laquelle les lignes qualifiées à partir des tables externe et interne doivent être dans l'ordre jointure-prédicat. Une jointure de fusion est également appelée jointure d'analyse de fusion ou jointure de fusion triée.

Une jointure est nécessaire dès qu'il y a plusieurs tables référencées dans une clause FROM. Une jointure de fusion est possible dès qu'il y a un prédicat de jointure correspondant aux colonnes de deux tables différentes. Elle peut également provenir d'une sous-requête ré-écrite.

Une jointure de fusion requiert une entrée ordonnée dans les colonnes de jointure car les tables sont généralement analysées une seule fois. Cette entrée ordonnée est obtenue en ouvrant un index ou une table triée.

Suggestions liées aux performances :
  • Utilisez les prédicats locaux (c'est-à-dire les prédicats faisant référence à une seule table) pour réduire le nombre de lignes à joindre.
  • Si les statistiques ne sont pas à jour, mettez-les à jour à l'aide de la commande RUNSTATS.
Jointure par boucle imbriquée
Cet opérateur représente une jointure de boucle imbriquée qui analyse la table interne une fois (en général, à l'aide d'une analyse d'index) pour chaque ligne de la table externe.

Une jointure est nécessaire dès qu'il y a plusieurs tables référencées dans une clause FROM. Une jointure de boucle imbriquée n'a pas besoin d'un prédicat de jointure, mais fonctionne généralement mieux avec.

Une jointure de boucle imbriquée est exécutée de l'une des manière suivante :
  • En analysant la table interne pour chaque ligne ouverte de la table externe.
  • En effectuant une recherche d'index sur la table interne pour chaque ligne ouverte de la table externe.
Suggestions liées aux performances :
  • Une jointure de boucle imbriquée est supposée être plus efficace s'il y a un index dans les colonnes de prédicats de jointure de la table interne.

    Une autre façon (moins importante) de rendre la jointure plus efficace consiste à créer un index dans les colonnes de jointure de la table externe de sorte que la table externe soit triée.

  • Si les statistiques ne sont pas à jour, mettez-les à jour à l'aide de la commande RUNSTATS.
Retour
Cet opérateur représente le retour de données d'une requête. Il s'agit de l'opérateur final du plan d'accès et il présente le total des valeurs et coûts cumulés pour le plan d'accès.
Analyse d'identificateur de ligne (RID)
Cet opérateur représente l'analyse d'une liste d'identificateurs de ligne (RID) provenant d'un ou de plusieurs index.
Cette opération est utilisée par l'optimiseur lorsque :
  • les prédicats sont connectés par les mots clés OR ou lorsqu'il y a un prédicat IN. Une technique appelée index ORing peut être utilisée et combine les résultats de plusieurs accès d'index sur la même table.
  • Il est intéressant d'utiliser une lecture anticipée de liste pour un accès d'index unique, car le tri des identificateurs de ligne avant l'accès aux lignes de base rend l'E-S plus efficace.
Extraction de données à distance
Cet opérateur représente l'extraction de données depuis une source de données distante dans un système fédéré.
Trier
Cet opérateur représente le tri des lignes d'une table dans l'ordre d'une ou de plusieurs de ses colonnes, en supprimant éventuellement les entrées en double.

Le tri est obligatoire lorsqu'il n'existe aucun index suivant l'ordre requis ou lorsque le tri est moins onéreux qu'une analyse d'index. Le tri est généralement effectué en opération finale une fois que les lignes requises sont extraites ou pour trier les données avant un tri par jointure ou par groupe.

Si le nombre de lignes est élevé ou si les données triées ne peuvent être dirigées, l'opération requiert la génération onéreuse de tables temporaires.

Analyse de table
Cet opérateur représente une analyse de table (analyse des relations) permettant de récupérer des lignes en lisant toutes les données requises directement à partir des pages de données.
Ce type d'analyse est choisi par l'optimiseur pour une analyse d'index lorsque :
  • La plage des valeurs analysées apparaît fréquemment (c'est-à-dire que la majorité de la table doit être accessible).
  • La table est de petite taille.
  • Le groupement d'index est faible.
  • Aucun index n'existe sur la table.
Table temporaire
Cet opérateur représente le tri de données dans une table temporaire pour permettre la lecture des données pendant une autre opération.
File d'attente de table
Cet opérateur représente une file d'attente de table utilisée pour faire transmettre les données de table d'un agent de base de données vers un autre lorsque plusieurs agents de base de données exécutent une requête. Plusieurs agents de base de données sont utilisés pour traiter une requête lorsque le parallélisme est impliqué.
Union

Cet opérateur représente une opération nécessaire. Pour réduire le coût du plan d'accès, concentrez-vous sur d'autres noeuds (tels que les noeuds d'analyse et de jointure) qui définissent l'ensemble de lignes à supprimer.

Elimination des doubles
Cet opérateur représente la suppression de lignes comportant des valeurs en double pour les colonnes spécifiées.
Update

Cet opérateur représente une opération nécessaire. Pour réduire le coût du plan d'accès, concentrez-vous sur d'autres noeuds (tels que les noeuds d'analyse et de jointure) qui définissent l'ensemble de lignes à supprimer.

Analyse des index sur des données XML
Cet opérateur représente une analyse de plage de tout index associé par rapport aux données XML correspondantes avant l'accès à la table de base. L'opération réduit l'ensemble des ID de lignes de qualification et des ID de noeud XML.
Suggestions liées aux performances :
  • Dans le temps, les mises à jour de bases de données peuvent entraîner la fragmentation d'un index, ce qui donne plus de pages d'index que nécessaire. Ceci peut être corrigé en supprimant et en recréant l'index ou en le réorganisant.
  • Lorsqu'au moins deux tables sont ouvertes, l'accès à la table interne à l'aide d'un index peut être facilité si l'on fournit un index dans la colonne de jointure de la table externe.
  • Si les statistiques ne sont pas à jour, mettez-les à jour à l'aide de la commande RUNSTATS.
Analyse de document XML
Cet opérateur représente la navigation des fragments XML pour évaluer les expressions XPath et extraire les fragments de documents requis.
Ajout d'index XML
Cet opérateur représente l'ajout d'index sur des données XML des résultats de plusieurs analyses d'index utilisé pour évaluer les prédicats complexes d'une requête unique.
Pour que cette opération soit utilisée, les conditions suivantes doivent être remplies :
  • Seuls des prédicats d'égalité sont utilisés.
  • Il n'y a pas de caractère générique dans le chemin de recherche de l'index.
  • Tous les prédicats sont utilisés dans la même colonne XML.

Si l'une de ces conditions n'est pas remplie, c'est l'opération d'intersection d'index qui est utilisé.

Suggestions liées aux performances :
  • Dans le temps, les mises à jour de bases de données peuvent entraîner la fragmentation d'un index, ce qui donne plus de pages d'index que nécessaire. Ceci peut être corrigé en supprimant et en recréant l'index ou en le réorganisant.
  • Si les statistiques ne sont pas à jour, mettez-les à jour à l'aide de la commande RUNSTATS.
  • En général, les analyses d'index sont les plus efficaces lorsque seules quelques lignes sont qualifiées. Pour évaluer le nombre de lignes de qualification, l'optimiseur utilise les statistiques disponibles pour les colonnes référencées dans les prédicats. Si certaines valeurs apparaissent plus fréquemment que d'autres, il est important de demander des statistiques de distribution en utilisant la clause WITH DISTRIBUTION pour la commande RUNSTATS. Grâce aux statistiques de distribution non uniformes, l'optimiseur peut faire la distinction entre les valeurs apparaissant fréquemment et celles apparaissant rarement.

Commentaires