Discussion :

[molarisapa]

Bonjour,

J'ai une table COMMANDE avec une clé primaire composé de 3 champs :CETAB, NO_COMMANDE, CTIERS
J'ai mis ces 3 champs car unitairement ils ne sont pas uniques. Seule le couple de ces 3 valeurs peut être unique.

J'ai activé les logs, et j'ai pu constater que la requete suivante est tres gourmande en CPU:

select distinct(C_CTIERS),C_TMODIFICATION from COMMANDE where C_NO_COMMANDE=nnnnn and C_CETAB=xxxxxxxxx

Je précise que la table contient un peu plus de 2 millions d'enregistrements.
Dans les traces j'obtiens un CPU variable entre 38000 et 39000 alors que les autres requetes sont en général entre 10 et 300 grand max.

J'ai essayé en plus de ma triple clé primaire, d'ajouter un index sur CETAB, NO_COMMANDE et CTIERS, j'ai pu ainsi faire descendre la composante "read" du tiers dans les logs, mais je reste à 38000 et 39000 pour CPU.

Est-ce que quelqu'un pourrai m'aider à optimiser ma table pour faire déscendre en cout CPU ma requete.

Merci de votre aide
olivier

[SQLpro]

C'est votre clef, dont la conception est mahabile, qui est la cause de très mauvaises performances...
Inconvénient d'une primary key composite :
1) les statistiques ne sont collectées que sur la première colonne
2) les recherches ne peuvent se faire que par vectorisation des colonnes
3) l'index CLUSTER sous jacent à la clef va être TRES fragmenté.
4) les efforts de jointure avec une telle clef sont sans commune mesure avec une clef reposant sur une unique colonne dont le type est voisin de la taille du mot du processeur;

La meilleure solution consiste à revoir votre modélisation et implanter une clef primaire de type auto incrément et passer, si besoin est, votre clef composée en contrainte d'unicité.

C'est ce que je montre par exemple dans mon cours d'optimisation des bases de données sous MS SQL Server, notamment à Orsys...
=> http://www.orsys.fr/pdfCours/SQO.pdf

A +

[molarisapa]

Merci pour cette réponse.

Je me suis trompé en faite les 37000-38000 c'est dans la colonne "reads". Et j'ai d'ailleur pu constater que ca pouvait descendre à 20000. Bref ca c'est que des chiffres

j'ai importé ma table de "PROD" vers une base de "TEST" pour faire des essais d'optimisation.

Voici les résultats:
http://kielive.ifrance.com/analyseSQL.JPG

En ajoutant des indexs en plus de la triple clé primaire (pourtant des indexes sur ces champs composite de la clé primaire) => je fais baisser le read de 17000 à 8000.

j'ai tester aussi avec une clé primaire automatique pour enlever ma triple clé primaire. Sans indexes ont obtiens logiquement un read elevé : 20000

En rajoutant les 3 indexes, on obtiens les meilleurs perf : read à 7000. Donc on gagne 10% de perf par rapport a la triple clé primaire.

Par contre en CPU et en duration, je n'arrive pas vraiment à améliorer les résultats...