Problème de performance dans une procédure stockée de type CLR

**michel61** · 14/04/2014, 11h11

Bonjour

Nous avons développé une procédure stockée de type CLR que nous avons testée sur un PC XP de petite taille (Dualcore 2 Gb RAM) et que nous avons déployée sur un serveur Windows 2008 R2 avec SQL 2008 R2 or cette procédure stockée tourne 2 fois moins vite sur ce serveur que sur le PC

Cette procédure génère des étiquettes à partir de bases locales et les stocke dans une autre base locale, ce n'est donc pas non plus un problème de réseau

Comme le PC utilisait une édition SQL développement, nous avons essayé en changeant la version du serveur pour passer sur une édition Entreprise

Nous avons changé le mode des bases de données de récupération FULL à SIMPLE
Les logiciels sur le serveur ont été mis à jour à la dernière version disponible par Windows Update
Pour info, le PC utilise un backup des bases du serveur sur lequel sont exécuté des scripts de plans de maintenance hebdomadaires alors que rien n'est programmé sur le PC

La charge CPU du serveur reste assez faible et la mémoire consommée par SQL Server, après reboot, ne monte pas

Quelqu'un a-t-il été confronté à une problème semblable et avez-vous trouvé une solution pour améliorer ces performances ?

D'avance merci pour vos réponses

Michel

**elsuket** · 14/04/2014, 12h38

Bonjour,

Comme vous passez de XP (qui n'est d'ailleurs plus supporté par Microsoft depuis le 8 Avril 2014) à Windows Server 2008, je pense immédiatement à :

La version du Framework
Le type de CPU avec lequel vous avez compilé : 32 ou 64 bits

L'édition Developer est identique à l'Enterprise, si ce n'est que le nombre de processeurs que l'on peut utiliser avec la première est limité.
Le mode de récupération n'a rien à voir dans la vitesse d'exécution du code, de quelque nature qu'il soit.

@++

**michel61** · 14/04/2014, 15h16

La compilation en mode 64bits avait été la première modification à être appliquée mais entre temps, nous avons même remplacé le PC du développeur par un Windows 7 nativement 64bits et les performances restent les mêmes sur le PC
La version du Framework avait bien sûr été adaptée entre les 2 environnements

**SQLpro** · 14/04/2014, 17h44

Détaillez ce que fait cette procédure et montrez nous le code.

A +

**michel61** · 15/04/2014, 11h12

J'ai ajouté en pièce jointe le code de la procédure stockée qui génère les étiquettes ainsi que la description des tables (avec index) et fonction utilisées dans la jointure

La variable @champs est remplacée par une énumération des informations à imprimer sur l'étiquette (de l'ordre de 70 dans notre cas)
Les variables @cab et @pdc sont les critères de sélection dans la vue

**SQLpro** · 15/04/2014, 12h05

Vous faites pas de la base de données, là !!! Vous faites du tableur Excel !

[dbo].[TAB_DATA_MAT] => 36 colonnes
avec 4 beaux viols de 1FN :
[DesignationFRA] / [DesignationALL]
[DimensionX] / [DimensionY] / [DimensionZ]
[ColorisExt] / [ColorisInt]
[SensFilExt] / [SensFilInt]

[dbo].[TAB_MES_COLIS] => 36 colonne, clé primaire composée de 6 colonnes (int, int char(3), tinyint, int, cgar(10) !
avec aussi de beaux viols de 1 FN
DimensionColis... DesignationComp1Etiq...

[dbo].[TAB_MES_CPS] => 108 colonnes
Un nombre impressionnant de viols de 1 FN
colonnes se terminant par 1, 2, 3, 4 ou 5 :[ColorisChant1], [EpaisseurChant1], [FormeCpsChant1], [RecouvrementChant1], [TypePercage1]
colonenes IntervaleTolerance... (10 !)

[dbo].[TAB_MES_PDC] => 84 colonnes

Ne vous étonnez pas d'avoir aucune performances....
A lire : http://blog.developpez.com/sqlpro/p1...mances_petites

A +

**michel61** · 15/04/2014, 12h52

Merci pour votre réponse

Je vais voir avec les développeurs et leur demander s'il est possible de revoir l'architecture des tables

**michel61** · 15/04/2014, 13h16

Je reviens malgré tout sur cette réponse en rappelant le problème initial qui est que la même exécution sur un simple PC est plus rapide alors que le serveur sur lequel nous testons est un serveur de pré-production non sollicité