Discussion :

[fdenis31]

Bonjour,
je suis face à un problème (important) de temps de réponse sur une requête SQL issue d'un générateur B.O.

Nous avons fait évoluer B.O., aujourd'hui sous 2008 R2, et fait suivre ses bases de travail ainsi que la base de données de notre observatoire économique sur SQL Server 2008 R2, anciennement sous SQL 2000.

J'ai lancé la requête dans SQL Server Management studio ;
elle met 39 secondes pour afficher les 294 lignes !

La requête est issue des univers de BO, dans lesquels les liens entre tables visitées ne respectent pas forcément ceux qui existent dans la base.

j'ai donc pris ma requête et l'ai exécutée sur l'ancien serveur de base de données, sous SQL 2000 ; 1 seconde !

J'avoue ne pas comprendre une telle différence.
La requête est en pièce jointe mais je ne pense pas qu'elle soit à l'origine du pb, il me semble que les temps de réponse sur SQL 2000 seraient longs aussi.

Si quelqu'un a eu le problème, ou du moins une idée de son origine, j'avoue être preneur.
Merci d'avance pour vos réponses

[elsuket]

Bonjour,

Est-ce que lorsque vous avez mis en route la base de données sous SQL Server 2008, vous avez forcer le recalcul de toutes les statistiques de colonnes ?

Sans la définition des tables mises en jeu, ou encore mieux du plan de requête réel il sera difficile de vous aider.

Pour le capturer, un petit CTRL + M avant d'exécuter la requête, qui quand elle sera terminée affichera un onglet supplémentaire dans la console, dans lequel de trouve le plan d’exécution.

De là vous cliquez dans une zone vierge de celui-ci, et vous choisissez "sauvegarder le plan en tant que ..." et vous postez ici

Si vous voulez le voir un peu mieux, je vous invite à lire cet article

@++

[fdenis31]

Bonjour, et merci pour votre réponse.

J'ai lancé la mise à jour des statistiques (sp_updatestats), pensant avoir un début de solution mais cela n'a rien fait. je joins le rapport.
Certes des index ont été mis à jour mais sans affecter ni améliorer les temps de réponse.

J'ai relancé la requête avec le plan d'exécution réel, je joins aussi le rapport.

à plus,

[elsuket]

A partir du plan de requête, on voit aisément qu'il y a un problème d'estimation :



Cela est dû au prédicat COMCOD <> '000'.
En effet SQL Server sait grâce aux statistiques de colonne les valeurs qui se trouvent dans la colonne, et à quelle fréquence (statistique) elle s'y trouvent, mais pas quelles valeurs n'y sont pas ...

Donc vous pouvez créer un index filtré avec cette condition; en revanche je ne comprends pas cette différence entre SQL 2000 et SQL Server 2008.
Pourriez-vous donner le plan sous SQL Server 2000 ?

@++

[fdenis31]

Bonjour,

je ne demande pas mieux que de vous fournir mon plan d'exécution, mais sous SQL2000, aucune possibilité ne m'est offerte pour le sauvegarder.

Même sous SQL2005, connecté au moteur de base de données du serveur SQL2000, la sauvegarde est impossible.

Je peux vous fournir le plan sur cette instance SQL2005, mais le problème de temps de réponse y est identique, la requête met 40 s pour afficher les enregistrements de la base créée en compatibilité 2000.

Que faire docteur ?

@+

[Glouferu]

Bonjour fdenis31,

Je n'explique pas la différence d’exécution entre ton Server 2000 et 2005.

Néanmoins, j'ai remarqué que les gens qui réalisent des rapports BO avec des conditions du genre NOT IN, NOT IN ALL, <> (qui correspondent sous Deski à PAS DANS LISTE ... etc) génèrent des requêtes SQL assez compliqués pour le serveur SQL qui n'est pas tout le temps capable de répondre dans des délais raisonnables.
-> Du coup, pour contourner le problème, tu ramènes toutes tes valeurs et tu fais un filtre d'affichage dans ton rapport.
Et l’exécution devient instantané.

Je sais... ce n'est pas glamour, mais ça permet de simplifier les requêtes générés par plusieurs fournisseurs de données imbriqués contenant des PAS DANS LISTE, eux-mêmes croisés avec d'obscur fichiers Excel !

Cdt,

[fdenis31]

Petit plus, j'ai au moins une image de l'écran à proposer.

On y voit bien que les estimations sont très différentes.

36700 correspond bien au nombre de lignes de la table scom au travers de la vue v_commune avec comcod<>'000'

j'ai fait un comptage et la table ACREACESS ne contient aucune ligne, avec la colonne comcod = '000'

La requête exécutée avec cette condition supprimée donne le résultat en 1 seconde .

Pourquoi SQL 2008 ne le gère pas aussi bien que SQL 2000 ?

Je n'ai pas la possibilité d'intervenir sur le générateur de requête de B.O.

N'y a-t-il rien à tenter, du côté des stats ?

@+