Discussion :

[Donpi]

Salut à tous,
comme certains le savent j'accuse de gros problèmes de performances dans mon système. Et ne trouvant pas de causes évidentes je commence à élaborer des théories de moins en moins logiques.

J'aimerais des avis sur celle qui suit :

On a une base de données SQL Server 2008 et 2012 qu'on accède via des applications windev et un accès natif.
Pour ceux à qui ça parle, nous n'avons pas d'accès direct au tables. Nous n'utilisons pratiquement que des variables de type sources de données remplies avec des résultats de requêtes SQL.

Bref, quand j'ai commencé à travailler à mon post actuel, tout les SELECT étaient suivi d'un WITH(NOLOCK) et les UPDATE d'un WITH(ROWLOCK).

A ce moment là, c'était indispensable pour que ça fonctionne. Car il n'y avait pas de Lock-Timeout du coup chaque requête sur une table lockée retournait directement une erreur sans attendre la moindre seconde.

Après un peu de recherche j'ai ajouté un lock timeout de 30 secondes ce qui fait que mes requêtes attendent 30 secondes avant de me retourner une erreur le cas échéant.

Je me demande si mes performances ridicules ne viendrais pas du fait que comme tout les select ont un With(Nolock) il n'ont pas besoin d'attendre que les ressources soient libérées et peuvent être tous traités en même temps.
Ce qui ferait saturé Sqlserveur quand trop de gens lancent des requêtes en même temps sur les mêmes ressources. Ce matin au pire moment j'avais ~200 locks sur mes tables.

Si vous avez lu jusqu'ici, encore un petit effort pour donner votre avis

[SQLpro]

Salut à tous,
comme certains le savent j'accuse de gros problèmes de performances dans mon système. Et ne trouvant pas de causes évidentes je commence à élaborer des théories de moins en moins logiques.

J'aimerais des avis sur celle qui suit :

On a une base de données SQL Server 2008 et 2012 qu'on accède via des applications windev et un accès natif.

Malheureusement Windiv est connu pour n'exploiter que très faibelement les capacité des SGBDR de type Client/serveur et cela peut être afin de tenter de "vendre" sa base de données Hyperfile dont il se vante d'être 10 fois plus rapide (que quoi ??? on sait pas)

Pour ceux à qui ça parle, nous n'avons pas d'accès direct au tables. Nous n'utilisons pratiquement que des variables de type sources de données remplies avec des résultats de requêtes SQL.

C'est bine là que le bât blesse !

Bref, quand j'ai commencé à travailler à mon post actuel, tout les SELECT étaient suivi d'un WITH(NOLOCK) et les UPDATE d'un WITH(ROWLOCK).

1) ce n'est pas parce que vous mettez de tels "hints" que SQL Server vous obéira
2) NOLOCK est très dangereux car il peut lire deux fois les mêmes lignes ou sauter des lignes

A ce moment là, c'était indispensable pour que ça fonctionne. Car il n'y avait pas de Lock-Timeout du coup chaque requête sur une table lockée retournait directement une erreur sans attendre la moindre seconde.

Après un peu de recherche j'ai ajouté un lock timeout de 30 secondes ce qui fait que mes requêtes attendent 30 secondes avant de me retourner une erreur le cas échéant.

Je me demande si mes performances ridicules ne viendrais pas du fait que comme tout les select ont un With(Nolock) il n'ont pas besoin d'attendre que les ressources soient libérées et peuvent être tous traités en même temps.
Ce qui ferait saturé Sqlserveur quand trop de gens lancent des requêtes en même temps sur les mêmes ressources. Ce matin au pire moment j'avais ~200 locks sur mes tables.

200 verrous c'est ridicule... Vous auriez parlé de 100 000 c'était déjà un peu couteux... Mais tour dépend de la granularité du verrous. Le fait d'avoir forcé un verrous de ligne est aussi stupide que de dire, pour tout transporter je vais prendre une camionnette..... Par exemple pour transporter un airbus, il vous faudra utiliser 0987654567890 camionnettes après avoir démonté pendant 45678909876 heures votre airbus. Est-ce une bonne pratique ? Non. SQL Server est auto adaptatif sur le verrouillage et lui avoir interdit est absurde...

Si vous avez lu jusqu'ici, encore un petit effort pour donner votre avis

70% des problèmes de perf viennent du modèle de données
Avec Windev, vous ne pouvez que très difficilement utiliser le meilleur du meilleur, c'est à dire les procédures stockées.

Commencez par me lire :
1) optimisation de MS SQL Server (5 chapitres) : http://sqlpro.developpez.com/optimisation/
2) table obèses et petites bases : http://blog.developpez.com/sqlpro/p1...ances-petites/
3) indexation : http://sqlpro.developpez.com/cours/quoi-indexer/

A +

[Donpi]

70% des problèmes de perf viennent du modèle de données

J'en suis intimement persuadé, mais je peu pas débarqué et dire a mes collègues "Votre modèle de données est tout moisi." Je suis obligé d'emballer un peu et soigner un peu les différentes sensibilités. Je conçois bien que quand un gars de 60 ans vient dire "Les clé primaire ça ne sert a rien" c'est pas des gants en velours qu'il faut prendre mais plutôt des gants de chantier et commencer a abattre des mures... ou des gens...

Avec Windev, vous ne pouvez que très difficilement utiliser le meilleur du meilleur, c'est à dire les procédures stockées.

Je le sais bien. J'ai développez pendant 10 ans en Windev, donc se suis bien placé pour savoir que cette outil, en plus d'être bugé et mal fini, pousse le développeur à faire un travail cochon. On passe plus de temps a lutter contre les limites et les bugs de l'ide qu'a développer.
Mais bon en l'état changer d'outil est juste impensable.

Commencez par me lire

Déjà lu

[SQLpro]

Conclusion :
1) j'augmente les ressources du serveur, mais solution de facilité très limitée : facteur de perf entre 1,2 et 3...
2) je remodélise la base, tout au moins les 20% des tables qui causent 80% des problèmes de perf et là je gagne entre 10 et 100000...

Il n'y a pas d'autre alternative !

Ce que vous pouvez déjà diagnostiquer c'est :
1) toutes les tables ont-elles des clefs primaires ?
2) la taille des clefs primaires des tables est-elle inférieur à 4 octets (32 bits), 8 octets (64 bits) ?
3) les tables sont-elles liées par l'intégrité référentielle ?
4) toute les tables ont-elle un index clustered ?
5) l'index clustered des tables est-il inférieur à 4 octets (32 bits), 8 octets (64 bits) ?

Ensuite viendra :
- le nombre de colonnes par table (qui doit rester en principe inférieur à 20)
- la longueur moyenne des lignes (qui doit rester en principe inférieur à 2000 octets)
...

A +

[Donpi]

...
- le nombre de colonnes par table (qui doit rester en principe inférieur à 20)
...

Sur le principe je suis pas contre, mais pour quel raison le nombre de colonnes doit être inférieure a 20 ?

[Sergejack]

Sur le principe je suis pas contre, mais pour quel raison le nombre de colonnes doit être inférieure a 20 ?

C'est un nombre arbitraire au delà duquel SQL Pro pense qu'il y a probablement des colonnes dont la moindre fréquence d'utilisation pourrait justifier qu'elles soient mises à part (voire qu'elle soit indicatrice d'une non normalisation).

[xian21]

(...)
2) NOLOCK est très dangereux car il peut lire deux fois les mêmes lignes ou sauter des lignes200 verrous c'est ridicule (...)

Bonjour,

Ok la dessus mais bon apres la dangerosite depend de l'application qui attends les donnees. Certaines applications prefereront un temps de reponse plus cours avec des donnees moins fiable... Ce qui est le cas avec l'erp sur lequel je travaille...