Discussion :

[apprentie2011]

Bonjour,
Je suis en train de faire différents tests avec SQL Server pour élaborer un comparatif entre SQL Server 2005 et 2008 et à ma grande surprise, SQL Server 2008 R2 se révèle beaucoup plus lent que 2005.
Même environnement, même requête.
J'obtiens les résultats suivants. J'avais pensé que le KeyLookup pouvait expliquer cette différence de performance mais cette fonctionnalité est incluse dans SQL Server 2005 SP2 (qui est plus rapide) alors...je n'arrive pas à comprendre d'où peut venir la perte de performance.

Comme 2 avis valent mieux qu'un, je demande votre aide.
colonne 1 = Syst. exploitation
colonne 2= serveur SQL
colonne 3 = temps de réponse du serveur requete 1 (avec un index et un order by)
colonne 4 = temps de réponse du serveur requete 2 (sans index ave un order by)
colonne 5 = temps de réponse du serveur requete 3 (avec index sans order by)
colonne 6 = temps de réponse du serveur moyenne des 3 requetes.


Win 2008 64 bits 2005 4ms 15ms 29ms 13ms
Win 2008 64 bits 2008 140ms 46ms 31ms 93ms
Win 2003 64 bits 2005 15ms 125ms 31ms 46ms
Win 2003 64 bits 2008 156ms 15ms 15ms 89ms
Win 2003 32 bits 2005 15ms 109ms 46ms 42ms
Win 2003 32 bits 2008 156ms 15ms 15ms 89ms

PS: C'est la même base de donnée (donc les index/fragmentation est la même) installée sur des machines virtuelles. Le tableau est un résumé des statistiques du serveur (include client statistics).

merci !

[mikedavem]

Bonsoir,

Est ce que vous tester avec la même configuration hardware pour les serveurs ? Je vois que vous êtes sur une configuration virtualisée ... donc mêne chose niveau config virtuelle ?

Avez vous testé également sur les serveurs en mettant à jour les statistiques et réindexant vos tables ? Vu que l'optimiseur a un comportement différent de 2000 à 2005 et de 2005 à 2008 ... histoire d'avoir les plans d'exécutions générés correctement entre les différentes versions ..

++

[apprentie2011]

Merci pour ta réponse.
Oui c'est la même config virtuelle.

Les index ne sont pas fragmentés mais même avec n rebuild\reorganize, on gagne à peine quelques dizaines de secondes lors de l'exécution mais on est toujours très loin des performances de 2005.

exemple:

en 2005
client processing time 1051 ms
total execution time 1054 ms
wait time ons erver replies 3 ms

en 2008
client processing time 3328 ms
total execution time 3499 ms
wait time ons erver replies 171 ms

D'autres idées sont les bienvenues

[mikedavem]

Ok .. déjà si vous êtes à plat sur la config .. on peut comparer des patates avec des patates comme on dit. Ce genre de problème est d'ailleurs difficile à résoudre à distante du fait de sa complexité ...

A tout hasard pourrais t'on avoir un exemple d'une requête qui pourrait poser problème sur 2008 avec

- le plan d'exécution des 2 requêtes
- les informations relatives à l'activation des options SET STATISTICS IO ON et SET STATISTICS TIME ON

++

[sevyc64]

Question bête, la base sous 2008R2 provient d'un backup de celle de 2005. Tu l'as conservée au format 2005 (v9.0) ou tu l'a basculée au format 2008R2 (v10.5) pour profiter de toutes les avancées de 2008R2 ?

[SQLpro]

Et recalculé TOUTES LES STATISTIQUES ? Pas du rorganize, mais bien
UPDATE STATISTICS ...


En sus la virtualisation plombe les performances. par exemple si la machine virtualisée 2005 est plus sollicité que celle de 2008, par exemple par ce que c'est la prod, alors le système de virtualisation lui donnera un peu plus de ressources parce qu'il y a plus de sollicitations, surtout sur les 2 VM sont sur la même machine phyisque.

En tout cas un bench en MV, c'est hautement stupide !

A +

[mikedavem]

Il est vrai que maintenant on peut dédier les ressources d'un hôte virtuel par rapport d'autres pour empêcher ce partage des ressources justement.

Autre chose que les admin "virtualisations" oublient avec les serveurs de bases de données virtualisées ... dédier le stockage au serveur et ne pas partage par exemple les datastore entre plus hôtes virtuels ...

Mais globalement je suis de l'avis de SQLPro ... le benchmarking de 2 serveurs SQL reste compliqué du fait de leur dépendance à l'environnement virtuel qui les héberge.

++