Discussion :

[didoo91]

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.

[escartefigue]

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 ?

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 ?

[didoo91]

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.

[escartefigue]

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

[didoo91]

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.

[escartefigue]

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