Discussion :

[toulorrain]

Bonjour,

J'ai dans l'entreprise pour laquelle je travaille (Directeur Adjoint Informatique) une application tournant sur une base SQL. (ERP avec Facturation, GRH, Compta, Stocks etc...)

Cette base implantée depuis 18 mois comporte 3170 tables environ et un peu plus de 10500 index. (Sont-ce des chiffres normaux pour une base de données dans une PME où environ 90 utilisateurs peuvent se connecter et utiliser ?)
Sur ces 10500 index, un peu plus de 1400 ont une fragmentation logique > 30% (beaucoup dépassent même les 90%) (paramètre avg_fragmentation_in_percent de la fonction sys.dm_db_index_physical_stats)

Sont-ce là des chiffres inquiétants, qui pourraient expliqués les lenteurs ressenties par les utilisateurs à l'utilisation du logiciel s'appuyant sur cette base?

Je précise que cette base est fournie avec un ERP acheté et le fournisseur semble avoir du mal à expliquer ces lenteurs et à y remédier.

J'ajoute enfin que les serveurs sont très à l'aise (2 clusters pour le logiciel et 6 lames pour les users) ne dépassant que très rarement les 5% en ressources).

Dois-je demander une réorganisation de la base (voire une reconstruction de certains index) ?

En fait je me demande s'il serait judicieux de faire auditer cette base, au vu des chiffres mentionnés plus haut. Si je ne suis pas clair (ce qui est fort probable) n'hésitez pas à me poser des questions.

Merci de votre attention et de vos éventuelles réponseS.

[SQLpro]

Cette base implantée depuis 18 mois comporte 3170 tables environ et un peu plus de 10500 index. (Sont-ce des chiffres normaux pour une base de données dans une PME où environ 90 utilisateurs peuvent se connecter et utiliser ?)

Non, cela ne semble à priori pas très raisonnable et on peut se demander si le modèle n'est pas en cause. Je me souvient d'un ERP de nom Adonix qui avait l'abominable idée de créer autant de fois chacune des tables que de clients....

Sur ces 10500 index, un peu plus de 1400 ont une fragmentation logique > 30% (beaucoup dépassent même les 90%) (paramètre avg_fragmentation_in_percent de la fonction sys.dm_db_index_physical_stats)

Il est certains que vous n'avez pas mis en place une maintenance d'index adaptée.
Lisez l'article que j'ai écrit à ce sujet et mettez en place la procédure de défragmentation qui y figure, tous les jours aux heures creuses :
http://sqlpro.developpez.com/optimis...ntenanceIndex/

Sont-ce là des chiffres inquiétants, qui pourraient expliqués les lenteurs ressenties par les utilisateurs à l'utilisation du logiciel s'appuyant sur cette base?

Pas inquiétants, mais qui explique une partie des lenteurs.

Je précise que cette base est fournie avec un ERP acheté et le fournisseur semble avoir du mal à expliquer ces lenteurs et à y remédier.

Pour pratiquer l'audit de bases de données relationnelles depuis plus de 15 ans, je puis vous dire que les éditeurs sont légions à ne pas savoir utiliser correctement un SGBDR. Lisez la série d'article que j'ai écrit à ce sujet, elle vous donnera des exemples édifiants...
http://sqlpro.developpez.com/optimisation/

J'ajoute enfin que les serveurs sont très à l'aise (2 clusters pour le logiciel et 6 lames pour les users) ne dépassant que très rarement les 5% en ressources).

Un cluster ne sert a rien en matière de performances, contrairement à une idée fausse très répandue à ce sujet. Il faudrait faire un audit pour savoir si l'organisation de votre système est en adéquation avec la charge et les volumes attendus.
Voir à ce sujet l'article que j'ai écrit sur ce qu'est un audit de bases de données informatique :
http://www.sqlspot.com/L-audit-de-bases-de-donnees.html
http://www.sqlspot.com/sites/sqlspot...eDonnees-3.pdf

Dois-je demander une réorganisation de la base (voire une reconstruction de certains index) ?

Oui et quotidiennement comme indiqué ci avant.

En fait je me demande s'il serait judicieux de faire auditer cette base, au vu des chiffres mentionnés plus haut.

C'est probable, ne serait-ce que pour vous dédouanner des problèmes futur en en faisant reposer la responsabilité sur l'éditeur.

Si je ne suis pas clair (ce qui est fort probable) n'hésitez pas à me poser des questions.

A ce niveau le nombre de question serait trop importante et les investigations trop complexes pour que le forum soit l'endroit le plus adéquat !

A +