Discussion :

[SQLpro]

Ca ne me dit pas pourquoi j'ai une différence entre les serveurs, mais je n'aurai plus ce problème.

La concurrence des utilisateurs en prod n'est certainement pas la même que sur votre serveur de test ! Or chaque utilisateur pompe des ressources. De la même manière chaque utilisateur verrouille les tables même pour de simples lectures....

NOTA : il y a certainement moyen de mieux optimiser votre requête. Lisez les articles que j'ai écrit sur l'optimisation :
http://sqlpro.developpez.com/cours/quoi-indexer/
http://sqlpro.developpez.com/optimis...ntenanceIndex/
http://sqlpro.developpez.com/optimisation/
http://sqlpro.developpez.com/optimisation/indexation/
http://sqlpro.developpez.com/optimisation/mediane/
et aussi sur l'utilisation des tables de temps :
http://sqlpro.developpez.com/cours/gestiontemps/

Mais l'une des meilleurs optimisation consiste à gérer un vrai modèle relationnel et non une table fourre tout. Le nombre des colonnes de votre table, me laisse à penser que vous n'avez pas conçu de modèle conceptuel de données. C'est la pire des choses en matière de performances....

A +

[Shuret]

La concurrence des utilisateurs en prod n'est certainement pas la même que sur votre serveur de test ! Or chaque utilisateur pompe des ressources. De la même manière chaque utilisateur verrouille les tables même pour de simples lectures....

Justement, ce n'est pas vraiment une appli client/serveur, juste de la génération de reporting et un peu de consultation. J'ai un serveur sur lequel se connectent 4 utilisateurs maxi et un autre où il n'y en a aucun (serveur d'intégration). Pourtant les 2 sont aussi lents. Et sur le serveur de test, qui a autant de charge que celui d'intég (c'est à dire que dalle), ça marche bien.

Mais l'une des meilleurs optimisation consiste à gérer un vrai modèle relationnel et non une table fourre tout. Le nombre des colonnes de votre table, me laisse à penser que vous n'avez pas conçu de modèle conceptuel de données. C'est la pire des choses en matière de performances....

Je n'ai pas conçu ce modèle et c'est vrai qu'il y aurait pas mal d'améliorations à faire à ce niveau là... Ce n'est cependant pas une table fourre-tout. Je pense que certains champs sont maintenant obsolètes, mais la plupart sont nécessaires.

[SQLpro]

Dans mes audits, dès qu'une table dépasse 20 colonnes, je cogne ! Il faut une sacré justification des plus de 20 colonnes pour que je dise OK. A ce jour et malgré une bonne centaines d'audit, je n'ai jamais retenu comme valable un seul argument !

Bien évidemment en dessous de 20 (entre 12 et 20) je regarde aussi.

Et pour lestables dont les lignes dépasse 30% de la taille de la page (8Ko) je regarde aussi.

A +