Problème de performances sous SQL Server 2000

Citation:

---

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 +

Citation:

---

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.

Citation:

---

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.

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 +