1. #1
    Nouveau Candidat au Club
    Homme Profil pro
    Développeur décisionnel
    Inscrit en
    février 2017
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur décisionnel
    Secteur : Service public

    Informations forums :
    Inscription : février 2017
    Messages : 3
    Points : 1
    Points
    1

    Par défaut Sybase 15.5 :Index utilisé de temps en temps

    Bonjour,
    J’ai un problème avec une requête paramétrée qui utilise par moment l’index de PK et d’autrefois non.
    J’ai une table de 15 000 000 d’enregistrements de 500 colonnes en Sybase.
    La clé primaire est composée de 5 champs. La première colonne de la Pk est celle où il y a le plus de valeurs distinctes ( environ 150 000 ), les autres champs qui composent la clé n’ont pas plus de 100 valeurs distinctes.

    J’ai créé une boucle qui paramètre une requête sur la colonne 1 de la PK. Il Elle prend des intervalles de valeurs de 2 ou 3000 valeurs à chaque fois.
    La requête est simple dans le sens où c’est un select de 50 champs sur celle seule table.
    Ex :
    Table_Syb avec PK col1 asc, col2 asc, col3 asc, col4 asc, col5 asc

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    Select col1, col2…col50 
    From Table_Syb
    Where col1 between 0 and 1999
    ….
    Boucle suivante :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    Select col1, col2…col50 
    From Table_Syb
    Where col1 between  2000 and 4000
    Chaque boucle retourne un nombre différent de lignes mais ramène entre 50 000 et 1 500 000 lignes.

    Sur certaines boucles, l’index de PK est utilisé, sur d’autres il ne l’est pas, il fait un table scan.
    Depuis quelques temps, le traitement fonctionne de cette manière mais avant il fonctionnait très bien en utilisant systématiquement l’index de la PK.
    Entre ces 2 moments, il y a eu une insertion de 300 000 lignes dans la table.

    Le seul moyen que j’ai trouvé pour qu’il utilise l’index à chaque requête, c’est de spécifier tous les champs de la clé comme ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    Select col1, col2…col50 
    From Table_Syb
    Where col1 between 0 and 1999
    And col2 between 1 and 100
    And col3 between 1 and 100
    And col4 between 1 and 100
    And col5 between 1 and 100
     
    ….
    Boucle suivante :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    Select col1, col2…col50 
    From Table_Syb
    Where col1 between  2000 and 4000
    And col2 between 1 and 100
    And col3 between 1 and 100
    And col4 between 1 and 100
    And col5 between 1 and 100

    Quelqu’un a-t-il déjà rencontré cela ? Est-ce un comportement normal ? et dans le cas contraire quelqu’un a-t-il une solution plus propre ou à une piste à tester?

    Merci d'avance de vos réponses.

  2. #2
    Expert confirmé
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 485
    Points : 5 559
    Points
    5 559

    Par défaut

    Citation Envoyé par didoo91 Voir le message
    J’ai une table de 15 000 000 d’enregistrements de 500 colonnes en Sybase.
    La clé primaire est composée de 5 champs. La première colonne de la Pk est celle où il y a le plus de valeurs distinctes ( environ 150 000 ), les autres champs qui composent la clé n’ont pas plus de 100 valeurs distinctes.
    Bonjour,
    1er constat : la base est très mal modélisée
    - vous auriez du définir une PK technique sur une seule colonne, ce qui aurait permis d'optimiser les filtrage et les jointures
    Si en plus, comme c'est souvent le cas avec le PK multi-colonnes, vos colonnes sont sémantiques, alors c'est la cata potentielle
    Quel est le contenu de ces 5 colonnes PK ?
    - une table avec 500 colonnes est une table obèse, symptomatique du non respect des formes normales, ce qui crée des redondances, des données nulles et qui engendre des problèmes de contention
    Edit : j'oubliais, communiquez le DDL de l'index PK, est il cluster ?

    Citation Envoyé par didoo91 Voir le message
    J’ai créé une boucle qui paramètre une requête sur la colonne 1 de la PK. Il Elle prend des intervalles de valeurs de 2 ou 3000 valeurs à chaque fois.[. . .]
    Quelles sont les conditions de vos tests ? d'autres personnes accèdent elles à cette table, de quelle façon ?

    Edit : et question subsidiaire, y a -t- il eu une réorg et des statistiques depuis l'insertion des 300 000 ?

  3. #3
    Nouveau Candidat au Club
    Homme Profil pro
    Développeur décisionnel
    Inscrit en
    février 2017
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur décisionnel
    Secteur : Service public

    Informations forums :
    Inscription : février 2017
    Messages : 3
    Points : 1
    Points
    1

    Par défaut

    Bonjour,
    Merci de votre réponse.
    Je n'ai pas la possibilité de toucher a la modélisation de la base car celle ci est une base source d'une sorte d'ERP avec un calculateur.
    La Pk est cluster et voici le code :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    CONSTRAINT Table_Syb_PK PRIMARY KEY (Col1 ,Col2, Col3 , Col4, Col5)
    Les données ne sont pas sémantiques. Pour faire court, la première colonne est un Article, la deuxième colonne est une version de l'article, la troisième colonne est un magasin, la quatrième colonne et la cinquième colonne c'est le mois et l'année calendaire . Il y a des redondances car c'est une table d'historisation des photos en fin de mois des articles.
    D'autres personnes accèdent a ces tables via un enquêteur mais en général, ils se positionnent sur 1, 2 ou 3 mois avec une notion d’agrégation. Leur temps de rafraichissement est tout de même long. Il y a plusieurs flux qui se basent sur cette table et le phénomène est le même.

    J'ai effectué les tests via un ETL et via un requeteur de type iSql
    J'ai fait les requêtes normales ( avec le groupement de 2000 ou 3000 articles a chaque fois ), puis j'ai recommencé exactement les mêmes requêtes en spécifiant les valeurs min et max de chaque colonne.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    Ex ANNEE between 2010 and 2017 
         ou MOIS between 1 and 12 ...
    Est-ce que ce comportement des clause where est normal ?

    Il y a une réorg des statistiques avant chaque passage du moteur de calcul. Mais pas après.
    Merci de votre aide.

  4. #4
    Expert confirmé
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 485
    Points : 5 559
    Points
    5 559

    Par défaut

    Une piste possible : le nombre de valeurs distinctes de la colonne 1 serait insuffisant pour que l'index soit pertinent avec cette colonne prise seule

    Examinez, pour les requetes qui sont très longues, quelle est la valeur recherchée pour col1 et combien il y a de lignes en table pour cette même valeur, si grand nombre de lignes, alors passer par l'index est plus pénalisant qu'un table scan.

    Si supposition avérée, analysez la possibilité de modifier l'ordre des colonnes de votre index, en commençant par une colonne discriminante, dont vous pouvez fournir la valeur bien sur

  5. #5
    Nouveau Candidat au Club
    Homme Profil pro
    Développeur décisionnel
    Inscrit en
    février 2017
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur décisionnel
    Secteur : Service public

    Informations forums :
    Inscription : février 2017
    Messages : 3
    Points : 1
    Points
    1

    Par défaut

    La colonne 1 est celle qui a le plus de valeur a peu près 150 000 valeurs différentes. La colonne 2 a peu près 200, la colonne 3 10 valeurs, la colonne 4 5 valeurs et la colonne 5 12 valeurs.
    Si je suit votre raisonnement, il faudrait passer par des groupe de données plus petit pour la colonne 1, 1000 au lieu de 2000 ou 3000 par exemple ?
    Je ne peux malheureusement pas toucher a l'index, ni a l'ordre, ni au sens du tri. Je peux par contre en créer un nouveau.

  6. #6
    Expert confirmé
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 485
    Points : 5 559
    Points
    5 559

    Par défaut

    il est possible que les 150 000 valeurs soient très mal réparties, une répartition non pas en courbe de gauss classique mais en dents de scie par exemple ou en gauss très pointue, ce qui ferait que pour certaines plages le passage par l'index serait peu pertinent.

    Si c'est le cas, je ne vois pas de moyen d'action

    Vu la table particulièrement obèse, essayez quand même de passer les requêtes qui posent souci à des moments où vous êtes seuls sur la table (si possible bien sur) pour en avoir le cœur net
    Une table aussi énorme s'expose à de graves problèmes de contention, même en lecture seule (sauf à poser des verrous UR, ce qui est rare)

    Note : que les perfs soient médiocres au travers d'un ETL n'est pas très significatif, par contre, via requêteur c'est plus inquiétant

Discussions similaires

  1. Réponses: 8
    Dernier message: 26/04/2016, 12h25
  2. Réponses: 9
    Dernier message: 21/01/2012, 00h49
  3. Réponses: 13
    Dernier message: 10/06/2010, 21h38
  4. INDEX utilisé par une Primary Key
    Par Wurlitzer dans le forum Oracle
    Réponses: 2
    Dernier message: 29/06/2006, 12h42

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