Discussion :

[phoenix40]

Bonjour à tous et d'avance merci à ceux qui me répondront.

Je n'y connais pas grand chose en SQL et j'essaie d’améliorer le fonctionnement de l'ERP de ma boite.

Suite à une demande de notre part par apport à des lenteurs sur une requete, un prestataire à mis en place des INDEX (et surement fait autre chose, mais pas de détails) qui ont considérablement améliorer le temps de requétage.

Suite à différente recherche, j'ai pu voir que si l'on affiche le "plan d'éxécution estimé" sur une requete, SQL nous propose l'ajout de "non-clustered index".

J'ai fait le test sur un serveur de test avec notre base de prod et effectivement cela améliore le schmilblik (50% au premier coup puis pas grand chose pour les autres).

Par rapport à tout ça je me pose les question suivante :

- l'ajout de ces non-clustered index font-ils grossir la base ???
- impactent t-ils les perf de la base en prod (est-ce que ça gene ou ralentirale fonctionnement du soft car cela "calcule" de nouveaux index ???

Merci à tous pour votre attention.

[SQLpro]

Avez-vous déjà ouvert un ouvrage scientifique (genre livre en papier) ?
En général à la fin il y a un truc appelé INDEX...
Cherchez un mots clé dans le livre.... Préférez vous parcourir toutes les pages et toutes les lignes du livre, ou bien aller chercher dans l'index trié alphabétiquement le mot correspondant qui vous donnera la ou les pages qui le contiennent ?

Alors oui, un index fait grossir le livre...
Alors oui, ça impacte les performances en les améliorant très fortement.... Sur des petites tables, pas beaucoup, sur des gosses, plus qu'indispensable !!! Mais qui sait quelles tables deviendront grosses ???

A +

[escartefigue]

Bonjour phoenix40

Vous informer sur ce forum est une bonne démarche, mais quelques remarques compte tenu de ceci :

Je n'y connais pas grand chose en SQL et j'essaie d’améliorer le fonctionnement de l'ERP de ma boite.

• Les ERP sont souvent protégés par licence et on ne peut pas y toucher sans faire appel à un prestataire agréé par l'éditeur. Ne vous lancez pas dans des modifications sans vérifier ce point.
• De plus, il existe souvent des patchs correctifs proposés par l'éditeur, peut être y en a -t-il un dédié aux performances du traitement incriminé. À vérifier sur le site de l'éditeur.
• À défaut de patch, la démarche habituelle est de signaler le bug à l'éditeur. Selon les cas, le délai de réaction pour l'obtention d'un correctif est plus ou moins important
• Si vous ne connaissez pas les bases de données, il n'est pas normal qu'on vous demande de faire ce travail. Si vraiment on vous le demande et qu'aucun patch n'est disponible, alertez par écrit votre hiérarchie sur le fait que vous n'êtes pas qualifié.

[phoenix40]

Merci escartefigue et je suis déçu de la réponse de SQL Pro que je ne trouve pas très pro et plutôt suffisante.

Bien sur que je sait ce qu'est un Index, mais effectivement je n'ai pas lu assez de livre et pas le VOTRE pour savoir dans quelles proportions les NON-CLUSTERED index vont faire grossir la base.

Concernant toujours ces même "non-clustered" index, il me semble avoir lu parmi les post de ce forum (mais peut-être est-ce valable que dans d'anciennes versions de SQL server) qu'ils pouvait "ralentir" les requêtes car pas possible de lire/comiter en même temps que les index se mettent à jour.

Concernant l'ERP, c'est le produit Y2 de CEGID développé avec les pieds. Les bases de données ne sont que la transcription des fichiers plat utilisé dans l'ancienne version Produflex.
Quant à toucher aux bases cela fait belle lurette que l'on les as "décortiqués" pour connecter notre produit de reporting dessus (reportone). Il m'est même arrivé de restaurer des TABLES (vous lisez bien) sans que le produit en soit perturbé.
Les patchs, n'ont jamais apportés d'amméliorations, voire ct pire aprés car patch plubié le matin et supprimé le lendemain car provoquant un blocage total de l'erp.

Pour tout dire au début nous avions un produit où même l'éditeur ne pouvait pas nous aider car ils n'en avait pas monté une (infrastructure identique à la notre) chez lui !!!!!!!

Concernant le fait d'avertir l'éditeur ou la hierarchie, dans le monde réel il existe encore des boites ou du moment que ça tourne (que le patron touche sa grosse paye et que tout le monde lui cache la vérité : tout vas bien). Juste pour dire toute dépense supérieure à 500 euros doit être visée par le patron. On voit de suite le niveau de confiance (on est dans le domaine de l'aéronautique et on dépense des fortunes en CATIA and co chaque année, cherchez l'erreur).

Voilou, je demandais juste quelques conseils ou infos dans un forum qui me semblait être un lieu d'entraide et non un lieu ou l'on expose sa science et sa supériorité.

Je sais aussi que je me ferais surement banir ou insulté pour ces quelques phrases et j'en suis fort déçu.

Merci escartefigue et longue vie au forum.

[SQLpro]

Désolé d'avoir paru suffisant à vos yeux, mais vous dites vous même :
Je n'y connais pas grand chose en SQL
Et vous posez des question au sujet des index "non clustered"
Les index nonclustered sont la majorité des index de tous les SGBDR.
1) parce que certains SGBDR ne savant faire que cela
2) il ne peut y avoir qu'un seul index clustered par table puisque l'index clustered = la table
3) les propositions d'indexation de SQL Server seront toujours des index non clustered.

Néanmoins vous pouvez créer tous les index demandés par SQL Server an analysant les demandes à l'aide de la vue :
sys.dm_missing_index_details

NOTEZ bien que les index améliorent les temps de réponse pour tous les types de requête, à l'exception des INSERT ou les index non sémantiques sont un frein (les index sémantiques de type clé primaire, ou clé alternative améliore les performances des inserts).
Vous pouvez aussi compressez les index si vous trouvez que cela fait grossir la base.

Néanmoins et paradoxalement cela améliore la mise en cache des données, car moins de scan seront opérés...

A+