Discussion :

[mbsl1]

Bonjour,

j'aurai souhaité un avis extérieur sur les statistiques renvoyées sur une de nos tables SQL. (Script d'analyse trouvé sur votre site et résultat dans le fichier xlsx en pièce jointe ; également le résultat d'un DBCC SHOWCONTIG).

Un plan de maintenance est réalisé toutes les nuits :
- deux reconstructions sont effectuées par semaine et les autres jours une réorganisation.

L'indice de fragmentation reste haut mais le nombre de page est faible.

La primary key de la table est un bigint unique.

Plusieurs requêtes portant sur la PK de celle-ci sont désormais plus longue depuis que la volumétrie a augmenté.

Merci de votre retour.

[SQLpro]

Postez la structure de votre table et la cardinalité de celle-ci.

A +

[mbsl1]

Est-ce-que celà suffit ?

[SQLpro]

Pourquoi votre PK est non clustered ?

[iberserk]

Postez les requètes "lentes" ainsi que leur plan d'execution...

[mbsl1]

Bonjour, en parcourant plusieurs sources, je m'aperçois effectivement de notre erreur par contre, j'ai plusieurs interrogations :

- Une PK de type clustered implique-t-elle un ralentissement au moment de l'ajout de la données (étant donné que la donnée doit être replacée au bon endroit ; nous avons sur certaines de nos tables, un besoin tout particulier de performance à l'ajout.) ?

- Quelles sont les exception à cette règle décrite dans la msdn http://msdn.microsoft.com/fr-fr/library/ms186342.aspx ? (À quelques exceptions près, chaque table doit posséder un index cluster.Outre le fait qu'il améliore les performances des requêtes, un index cluster peut être reconstruit ou réorganisé à la demande pour contrôler la fragmentation de la table.)

- Toutes nos PK sont de types bigint et séquentielles. Si nous passons sur des PK Clustered, a-t-on intérêt à créer des index trier par ordre décroissant au niveau des clés étrangères sur les autres tables faisant référence à cette PK ?

Merci pour vos réponses.