IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

DB2 Discussion :

DB2 z/OS Index et performances


Sujet :

DB2

  1. #1
    Membre habitué
    Profil pro
    Inscrit en
    Mars 2009
    Messages
    124
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2009
    Messages : 124
    Points : 136
    Points
    136
    Par défaut DB2 z/OS Index et performances
    Bonjour,

    petites questions sur les index et leurs fonctionnements.

    J'ai une table avec une cinquantaine de colonnes, et 3 colonnes en primary key.
    La répartition par clé est clé1 : 2 valeurs distinctes, clé2 : 300000 valeurs distinctes, clé3 : 60000 valeurs distinctes et en tout 1500000 rangs.
    J'organise mon index clé2 asc , clé3 asc , clé1 asc.
    A priori pour un accès clé1 = a and clé2 = b and clé3 = c, c'est le meilleur index possible (d'après les recommandations firstkeycard/fullkeycard doit être le plus grand possible).

    - Sachant que je ne peux avoir que des accès avec clé1 = a and clé2 = b puis clé3 = c ou clé3 >= c ou clé3 <= c, ne faudrait il pas plutôt faire un index clé2, clé1, clé3 ?

    - Sachant que mon applicatif affiche toujours à mes occurrences suivant des curseurs order by clé1, clé2, clé3 optimize for 1 row, avec un where sur les 3 clés ; avoir un index clé2, clé3, clé1 est il finalement plus pénalisant que dans l'ordre clé1, clé2, clé3 pour obtenir la prochaine clé ?

    - Faut il créer un index descending pour la pagination arrière ? Je vois partout ajouter REVERSE SCAN pour l'index, mais à priori, ça n'existe pas sur DB2 z/OS 9 .

  2. #2
    Membre expert
    Homme Profil pro
    Retraité
    Inscrit en
    Octobre 2005
    Messages
    1 473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 473
    Points : 3 283
    Points
    3 283
    Par défaut
    Citation Envoyé par keskidi Voir le message
    ...
    - Sachant que je ne peux avoir que des accès avec clé1 = a and clé2 = b puis clé3 = c ou clé3 >= c ou clé3 <= c, ne faudrait il pas plutôt faire un index clé2, clé1, clé3 ?

    - Sachant que mon applicatif affiche toujours à mes occurrences suivant des curseurs order by clé1, clé2, clé3 optimize for 1 row, avec un where sur les 3 clés ; avoir un index clé2, clé3, clé1 est il finalement plus pénalisant que dans l'ordre clé1, clé2, clé3 pour obtenir la prochaine clé ?
    Pour moi et en supposant qu'il s'agit d'une interrogation TP ( CICS, IMS/TM autre ? ) c'est l'ORDER BY qui doit déterminer l'ordre des colonnes dans l'INDEX et d'ailleurs en cohérence avec 'OPTIMIZE'. Il s'agit bien ici d'éviter la matérialisation de la table résultante surtout si une partie seulement de ce résultat est ramenée sur le poste de l'utilisateur. Est-ce le cas d'ailleurs ?

  3. #3
    Membre habitué
    Profil pro
    Inscrit en
    Mars 2009
    Messages
    124
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2009
    Messages : 124
    Points : 136
    Points
    136
    Par défaut
    Citation Envoyé par Luc Orient Voir le message
    Pour moi et en supposant qu'il s'agit d'une interrogation TP ( CICS, IMS/TM autre ? ) c'est l'ORDER BY qui doit déterminer l'ordre des colonnes dans l'INDEX et d'ailleurs en cohérence avec 'OPTIMIZE'. Il s'agit bien ici d'éviter la matérialisation de la table résultante surtout si une partie seulement de ce résultat est ramenée sur le poste de l'utilisateur. Est-ce le cas d'ailleurs ?
    Oui, tout à fait, c'est pour du CICS.

    Et donc ? Il est préférable d'utiliser un index clé1, clé2, clé3 ? Même si c'est une catastrophe au niveau performance pour un accès direct à un rang connu ?

  4. #4
    Membre expert
    Homme Profil pro
    Retraité
    Inscrit en
    Octobre 2005
    Messages
    1 473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 473
    Points : 3 283
    Points
    3 283
    Par défaut
    Citation Envoyé par keskidi Voir le message
    ... Et donc ? Il est préférable d'utiliser un index clé1, clé2, clé3 ? Même si c'est une catastrophe au niveau performance pour un accès direct à un rang connu ?
    Même si clé1 est peu discriminant, je vois mal DB2 choisir un autre chemin d'accès que l'index sur une requête avec un prédicat clé1 = ... AND clé2 = AND clé3 = ... et là l'accès est très rapide.

    De toutes façons, c'est comme tout, l'idéal pour trancher c'est de faire différentes simulations ( EXPLAIN voire traces ) sur une table avec une volumétrie proche de celle de production et là on verra bien ...

    Enfin, dernier point, définir cet index comme CLUSTER améliorera encore les choses pour l'accès paginé en TP puisque les lignes consécutives à retourner ont de grandes chances d'être dans la même page sur une table pas trop désorganisée bien sûr ...

  5. #5
    Membre habitué
    Profil pro
    Inscrit en
    Mars 2009
    Messages
    124
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2009
    Messages : 124
    Points : 136
    Points
    136
    Par défaut
    Citation Envoyé par Luc Orient Voir le message
    Même si clé1 est peu discriminant, je vois mal DB2 choisir un autre chemin d'accès que l'index sur une requête avec un prédicat clé1 = ... AND clé2 = AND clé3 = ... et là l'accès est très rapide.

    De toutes façons, c'est comme tout, l'idéal pour trancher c'est de faire différentes simulations ( EXPLAIN voire traces ) sur une table avec une volumétrie proche de celle de production et là on verra bien ...

    Enfin, dernier point, définir cet index comme CLUSTER améliorera encore les choses pour l'accès paginé en TP puisque les lignes consécutives à retourner ont de grandes chances d'être dans la même page sur une table pas trop désorganisée bien sûr ...
    Alors, j'ai du mal à comprendre cette discussion dans laquelle un certain Luc Orient spécifie que mettre une cle1 peu discriminante est très mauvais.

    Je comprend bien pour les tests, mais si quelqu'un avait déjà fait plusieurs tests du même genre, ça serait quand même plus simple, je trouve plein de documentation dans lesquelles il est également spécifié qu'avoir un index avec une FIRSTKEYCARD à 2 et une FULLKEYCARD à 1500000, c'est une connerie au niveau performance, et qu'il vaut mieux dans le cas présent avoir 300000 en FIRSTKEYCARD, d'autant que je le répéte dans 100% des cas les select seront sur clé1 = a and clé2 = b (et clé3 avec accès variables =, >, >=, <=, <), c'est pourquoi je pensais qu'un index clé2, clé1, clé3 était optimal, malgré le order by clé1, clé2, clé3.

    D'autre part, en ce qui concerne l'index descending, faut il le créer ? ou est-ce implicite dans DB2 for z/OS 9 ?

  6. #6
    Membre expert
    Homme Profil pro
    Retraité
    Inscrit en
    Octobre 2005
    Messages
    1 473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 473
    Points : 3 283
    Points
    3 283
    Par défaut
    Citation Envoyé par keskidi Voir le message
    Alors, j'ai du mal à comprendre cette discussion dans laquelle un certain Luc Orient spécifie que mettre une cle1 peu discriminante est très mauvais.
    Justement, relisez précisément ce que j'ai indiqué. Le problème de la colonne peu discriminante en première position est principalement un problème de détermination du chemin d'accès. En effet, en standard , DB2 n'a des informations sur le nombre de valeurs distinctes des colonnes d'un index multi-colonnes que pour la première colonne (FIRSTKEYCARDF) et pour la totalité des colonnes (FULLKEYCARDF). Il lui manque des informations pour les autres combinaisons possibles. Si dans votre cas, la recherche avec le prédicat d'égalité porte sur la totalité des colonnes de la clé c'est bien l'information portée par FULLKEYCARDF qui devrait être prise en compte.

    Et pour compliquer tout cela, sachez que depuis la V5, il est possible d'obtenir des informations complémentaires sur ces combinaisons intermédiaires avec l'option facultative KEYCARD de l'utilitaire RUNSTATS de collecte des informations statistiques. Mais là, ça dépend de la politique choisie et appliquée sur votre site en cette matière.

    Encore une fois, l'inconvénient d'avoir une première colonne non discriminante pour un index multi-colonnes, c'est surtout de risquer de disqualifier cet index lorsque l'optimiseur de DB2 cherchera à déterminer le chemin d'accès d'une requête donnée.

    Dans votre cas, et en fonction des éléments que vous avez indiqués ce risque m'apparaît faible voire nul, et surtout, à mettre en balance avec le gain espéré sur l'interrogation paginée en TP.

    Enfin et pour terminer, la réflexion théorique sur la meilleure façon de déterminer un index doit toujours s'accompagner d'une simulation (là les modalités peuvent varier) destinée à confimer ou infirmer les hypothèses de départ et on a parfois de drôles de surprises en ce domaine. Je vous encourage donc vivement à vous mettre en rapport avec un DBA sur votre site, et si ce dernier n'est pas totalement débordé, il devrait pouvoir vous aider à réaliser ces simulations.

  7. #7
    Membre habitué
    Profil pro
    Inscrit en
    Mars 2009
    Messages
    124
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2009
    Messages : 124
    Points : 136
    Points
    136
    Par défaut
    Ok, merci, on va donc tester de l'autre sens pour voir.

  8. #8
    Membre actif
    Inscrit en
    Juin 2008
    Messages
    154
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : Juin 2008
    Messages : 154
    Points : 225
    Points
    225
    Par défaut
    Avec quelques semaines de retard (longue absence...), je me permets d'ajouter une réponse d'autant plus que j'avais participé à la discussion citée en référence.

    DB2 ne connait pas que le fullkeycardf et le firstkeycardf. Si les runstats ont la bonne option, DB2 connait également les valeurs intermédiaires comme il est précise dans les différents échanges. Mais surtout, ne pas oublier qu'il existe une colonne COLCARDF dans la SYSCOLUMNS, que cette colonne donne toutes les infos nécessaires à DB2 et que l'optimiseur en tient compte.

    En conclusion, si tous les accès sont réalisés avec un prédicat d'égalité sur C1 et C2 et un prédicat aléatoire sur C3 et si les tris se font toujours dans l'ordre C1, C2, C3, alors le bon index est automatiquement C1, C2, C3. Il permet d'accéder à la table en matchcols 3, dans par l'arborescence complète de l'index et il permet de résoudre le tri donc de ne renvoyer que les lignes nécessaires sans être obligé de lire toutes les autres avec un fetch first n row only.

    Seul souci de cet index : pour une requête avec un simple prédicat sur C1, si DB2 décide de passer par l'index, ce sera très moyen, puisque cela renverra la moitié des lignes de la table. Autant faire un scan. Mais, si on est certain d'avoir toujours C1 et C2 renseigné, alors pas de souci, DB2 choisira toujours cet index et ce sera le bon.

    Bonne utilisation.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Performance DB2 Merge et index
    Par poutrelle dans le forum DB2
    Réponses: 2
    Dernier message: 20/03/2013, 08h26
  2. [optimisation] Reconstruction d'index et performances
    Par jenesuispasunrobot dans le forum Oracle
    Réponses: 6
    Dernier message: 03/02/2011, 15h31
  3. Index et performance
    Par rivsc dans le forum Ruby on Rails
    Réponses: 3
    Dernier message: 19/09/2009, 12h38
  4. [DB2] Question sur les index et les vues
    Par ahoyeau dans le forum DB2
    Réponses: 1
    Dernier message: 14/03/2005, 09h30
  5. [index] performance sur une recherche descendante
    Par jean-jacques varvenne dans le forum Oracle
    Réponses: 16
    Dernier message: 15/01/2005, 11h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo