Analyse de transfert de l'exécution sur la base de données fédérée

Pour les requêtes qui doivent être exécutées sur des bases de données fédérées, l'optimiseur effectue une analyse des répercussions pour déterminer si une opération particulière peut être effectuée sur une source de données distante.

Une opération peut être une fonction, telle qu'un opérateur relationnel, ou une fonction système ou utilisateur ; ou bien un opérateur SQL, tel que, par exemple, ORDER BY ou GROUP BY.

Veillez à mettre à jour régulièrement les informations du catalogue local, afin que le Db2® ait accès à des informations précises sur la prise en charge de SQL par les sources de données distantes. Utilisez les instructions DDL (Data Definition Language) Db2 (telles que CREATE FUNCTION MAPPING ou ALTER SERVER, par exemple) pour mettre à jour le catalogue.

Si les fonctions ne peuvent pas être transférées vers la source de données distante, elles peuvent avoir un impact significatif sur les performances des requêtes. Prenez en compte l'effet de la forçage d'un prédicat sélectif à évaluer localement plutôt qu'au niveau de la source de données. Une telle évaluation peut nécessiter que le serveur Db2 extraie l'intégralité de la table de la source de données distante, puis la filtre localement en fonction du prédicat. Les contraintes de réseau et une table de grande taille peuvent nuire aux performances.

Les opérateurs qui ne sont pas transférés peuvent également affecter de manière significative les performances des requêtes. Par exemple, l'agrégation de données distantes par un opérateur GROUP BY en local peut également nécessiter le serveur Db2 pour extraire une table entière de la source de données distante.

Par exemple, considérons le pseudonyme N1, qui fait référence à la table de source de données EMPLOYEE dans une source de données Db2 for z/OS source de données. La table comporte 10 000 lignes, l'une des colonnes contient les noms de famille des employés et l'une des colonnes contient les salaires. L'optimiseur dispose de plusieurs options lors du traitement de l'instruction suivante, selon que les séquences de classement locales et distantes sont identiques:
   select lastname, count(*)  from n1
     where
       lastname > 'B' and
       salary > 50000
     group by lastname
  • Si les séquences de classement sont identiques, les prédicats de requête peuvent probablement être transmis à Db2 for z/OS. Le filtrage et le regroupement des résultats au niveau de la source de données sont généralement plus efficaces que la copie de l'ensemble de la table et l'exécution des opérations localement. Pour cette requête, les prédicats et l'opération GROUP BY peuvent avoir lieu au niveau de la source de données.
  • Si les séquences de classement ne sont pas identiques, les deux prédicats ne peuvent pas être évalués au niveau de la source de données. Cependant, l'optimiseur peut décider d'insérer le prédicat salary > 50000 . La comparaison des plages doit encore être effectuée localement.
  • Si les séquences de classement sont identiques et que l'optimiseur sait que le serveur Db2 local est très rapide, il peut décider que l'exécution de l'opération GROUP BY localement est l'approche la moins coûteuse. Le prédicat est évalué au niveau de la source de données. Voici un exemple d'analyse de transfert de l'exécution sur la base de données associée à l'optimisation globale.
En général, l'objectif est de s'assurer que l'optimiseur évalue les fonctions et les opérateurs des sources de données distantes. De nombreux facteurs déterminent si une fonction ou un opérateur SQL peut être évalué sur une source de données distante, notamment:

Caractéristiques du serveur qui affectent les opportunités de transfert de l'exécution sur la base de données

Certains facteurs spécifiques à la source de données peuvent affecter les opportunités de transfert de l'exécution sur la base de données. En général, ces facteurs existent en raison du dialecte SQL enrichi pris en charge par le produit Db2 . Le serveur de données Db2 peut compenser le manque de fonction disponible sur un autre serveur de données, mais cela peut nécessiter que l'opération ait lieu sur le serveur Db2 .

  • Fonctions SQL

    Chaque source de données prend en charge une variante du dialecte SQL et différents niveaux de fonctionnalité. Par exemple, la plupart des sources de données prennent en charge l'opérateur GROUP BY, mais certaines limitent le nombre d'éléments de la liste GROUP BY ou ont des restrictions quant à l'autorisation d'une expression dans la liste GROUP BY. S'il existe une restriction sur la source de données distante, le serveur Db2 peut être amené à effectuer une opération GROUP BY en local.

  • Restrictions SQL

    Chaque source de données peut avoir des restrictions SQL différentes. Par exemple, certaines sources de données nécessitent des marqueurs de paramètre pour lier des valeurs à des instructions SQL distantes. Par conséquent, vous devez vérifier les restrictions propres aux marques de paramètres pour garantir que chaque source de données prend en charge une telle méthode de liaison. Si le serveur Db2 ne peut pas déterminer une bonne méthode pour lier une valeur à une fonction, cette fonction doit être évaluée localement.

  • Limites SQL

    Bien que le serveur Db2 puisse autoriser l'utilisation d'entiers plus grands que ceux autorisés sur les sources de données distantes, les valeurs qui dépassent les limites distantes ne peuvent pas être incorporées dans les instructions envoyées aux sources de données et toutes les fonctions ou opérateurs impactés doivent être évalués localement.

  • Caractéristiques du serveur

    Plusieurs facteurs entrent dans cette catégorie. Par exemple, si les valeurs nulles d'une source de données sont triées différemment de la manière dont le serveur Db2 les trie, les opérations ORDER BY sur une expression acceptant les valeurs nulles ne peuvent pas être évaluées à distance.

  • Séquence de classement
    L'extraction de données pour les tris et comparaisons locaux diminue généralement les performances. Si vous configurez une base de données fédérée pour qu'elle utilise la même séquence de classement qu'une source de données, puis que vous définissez l'option de serveur COLLATING_SEQUENCE sur Y, l'optimiseur peut envisager de transférer de nombreuses opérations de requête. Les opérations suivantes peuvent être insérées si les séquences de classement sont identiques:
    • Comparaisons de données alphanumériques ou numériques
    • Prédicats de comparaison de plages de caractères
    • Tris

    Toutefois, vous pouvez obtenir des résultats inhabituels si la pondération des caractères nuls est différente entre la base de données fédérée et la source de données. Les comparaisons peuvent renvoyer des résultats inattendus si vous soumettez des instructions à une source de données insensible à la casse. Les pondérations affectées aux caractères I et i dans une source de données insensible à la casse sont les mêmes. Par défaut, le serveur Db2 est sensible à la casse et affecte des pondérations différentes à ces caractères.

    Pour améliorer les performances, le serveur fédéré permet des tris et des comparaisons au niveau des sources de données. Par exemple, dans Db2 for z/OS, les tris définis par les clauses ORDER BY sont implémentés par une séquence de classement basée sur une page de codes EBCDIC. Pour utiliser le serveur fédéré pour extraire les données Db2 for z/OS qui sont triées conformément aux clauses ORDER BY, configurez la base de données fédérée de sorte qu'elle utilise une séquence de classement prédéfinie basée sur la page de codes EBCDIC.

    Si les séquences de classement de la base de données fédérée et de la source de données diffèrent, le serveur Db2 extrait les données dans la base de données fédérée. Etant donné que les utilisateurs s'attendent à voir les résultats de la requête classés par la séquence de classement définie pour le serveur fédéré, l'ordre des données en local garantit que cette attente est satisfaite. Soumettez votre requête en mode passe-système ou définissez la requête dans une vue de source de données si vous avez besoin de voir les données classées dans la séquence de classement de la source de données.

  • Options de serveur

    Plusieurs options de serveur peuvent affecter les possibilités de transfert de l'exécution sur la base de données, notamment COLLATING_SEQUENCE, VARCHAR_NO_TRAILING_ÉBAUCHES et PUSHDOWN.

  • Db2 -Mappage de type et facteurs de mappage de fonction

    Les mappages de types de données locaux par défaut sur le serveur Db2 sont conçus pour fournir un espace de mémoire tampon suffisant pour chaque type de données de source de données, ce qui évite la perte de données. Vous pouvez personnaliser le mappage de type pour une source de données spécifique afin de l'adapter à des applications spécifiques. Par exemple, si vous accédez à une colonne de source de données Oracle avec un type de données DATE, qui par défaut est mappé au type de données Db2 TIMESTAMP, vous pouvez remplacer le type de données local par le type de données DATE Db2 .

Dans les trois cas suivants, le serveur Db2 peut compenser les fonctions qu'une source de données ne prend pas en charge:
  • La fonction n'existe pas sur la source de données distante.
  • La fonction existe, mais les caractéristiques de l'opérande violent les restrictions de fonction. L'opérateur relationnel IS NULL est un exemple de cette situation. La plupart des sources de données le prennent en charge, mais certaines peuvent être soumises à des restrictions, telles que l'affichage d'un nom de colonne uniquement sur le côté gauche de l'opérateur IS NULL.
  • La fonction peut renvoyer un résultat différent si elle est évaluée à distance. Un exemple de cette situation est l'opérateur supérieur à ('>'). Pour les sources de données avec des séquences de classement différentes, l'opérateur "supérieur à" peut renvoyer des résultats différents s'il est évalué localement par le serveur Db2 .

Caractéristiques de pseudonyme qui affectent les opportunités de transfert de l'exécution sur la base de données

Les facteurs spécifiques aux pseudonymes suivants peuvent affecter les opportunités de transfert de l'exécution sur la base de données.
  • Type de données locales d'une colonne de pseudonyme

    Assurez-vous que le type de données locales d'une colonne n'empêche pas l'évaluation d'un prédicat sur la source de données. Utilisez les mappages de types de données par défaut pour éviter tout dépassement de capacité. Toutefois, un prédicat de jointure entre deux colonnes de longueurs différentes peut ne pas être pris en compte au niveau d'une source de données dont la colonne de jointure est plus courte, selon la façon dont Db2 lie la colonne la plus longue. Cette situation peut affecter le nombre de possibilités que l'optimiseur Db2 peut évaluer dans une séquence de jointure. Par exemple, les colonnes de source de données Oracle qui ont été créées à l'aide du type de données INTEGER ou INT sont associées au type NUMBER (38). Une colonne de surnoms pour ce type de données Oracle reçoit le type de données local FLOAT, car la plage d'un entier est comprise entre 2**31 et **31)-1, ce qui équivaut à peu près à NUMBER(9) Db2 est comprise entre 2**31 et ((-2 **31)-1, ce qui est à peu près équivalent à NUMBER(9). Dans ce cas, les jointures entre une colonne Db2 colonne entière et une colonne entière Oracle ne peuvent pas être effectuées dans la source de données (en raison de la longueur de la colonne de jonction) Db2 (en raison de la longueur réduite de la colonne de jointure); cependant, si le domaine de cette colonne d'entiers Oracle peut être pris en charge par le type de données Db2 INTEGER, modifiez son type de données local à l'aide de l'instruction ALTER NICKNAME afin que la jointure puisse avoir lieu dans la source de données Db2 source de données.

  • Options de colonne

    Utilisez l'instruction ALTER NICKNAME pour ajouter ou modifier les options de colonne pour les pseudonymes.

    Utilisez l'option VARCHAR_NO_TRAILING_POSES pour identifier une colonne qui ne contient pas de blancs de fin. L'étape d'analyse du transfert de l'exécution sur la base de données du compilateur prendra ensuite en compte ces informations lors de la vérification de toutes les opérations effectuées sur ces colonnes. Le serveur Db2 peut générer une forme différente mais équivalente d'un prédicat à utiliser dans l'instruction SQL envoyée à une source de données. Vous pouvez voir un prédicat différent évalué par rapport à la source de données, mais le résultat net doit être équivalent.

    Utilisez l'option NUMERIC_STRING pour indiquer si les valeurs de cette colonne sont toujours des nombres sans blancs de fin.

    Le tableau 1 décrit ces options.
    Tableau 1. Options de colonne et leurs paramètres
    Option paramètres valides Valeur par défaut
    NUMERIC_STRING

    Y: indique que cette colonne contient uniquement des chaînes de données numériques. Il ne contient pas de caractères blancs pouvant interférer avec le tri des données de colonne. Cette option est utile lorsque la séquence de classement d'une source de données est différente de celle du serveur Db2 . Les colonnes marquées avec cette option ne sont pas exclues de l'évaluation locale (source de données) en raison d'une séquence de classement différente. Si la colonne contient uniquement des chaînes numériques suivies de caractères blancs de fin, n'indiquez pas Y.

    N: Indique que cette colonne n'est pas limitée aux chaînes de données numériques.

    		 N
    VARCHAR_NO_TRAILING_BLANKS

    Y: Indique que cette source de données utilise une sémantique de comparaison VARCHAR non remplie de blancs, similaire à celle du serveur de données Db2 . Pour les chaînes de caractères de longueur variable qui ne contiennent pas de caractères blancs de fin, la sémantique de comparaison non remplie de blancs de certains serveurs de données renvoie les mêmes résultats que la sémantique de comparaison Db2 . Spécifiez cette valeur si vous êtes certain que toutes les colonnes de table ou de vue VARCHAR d'une source de données ne contiennent pas de caractères blancs de fin

    N: Indique que cette source de données n'utilise pas de sémantique de comparaison VARCHAR non remplie de blancs, similaire à celle du serveur de données Db2 .

    		 N

Caractéristiques de requête qui affectent les opportunités de transfert de l'exécution sur la base de données

Une requête peut faire référence à un opérateur SQL qui peut impliquer des pseudonymes provenant de plusieurs sources de données. L'opération doit avoir lieu sur le serveur Db2 pour combiner les résultats de deux sources de données référencées qui utilisent un opérateur, tel qu'un opérateur d'ensemble (par exemple, UNION). L'opérateur ne peut pas être évalué directement sur une source de données distante.