Discussion :

[Maximoute]

Bonjour à tous,

je gère l'exploitation d'un serveur hébergeant une application en Access/VB pointant sur une base SQL Server 2000.

Les éditeurs de celle-ci viennent de nous fournir une mise à jour pour notre base de données et nous sommes confrontés à un problème assez étrange :
- sur un NEC VL4 mono-process 1,6 Ghz et 512 de RAM, la mise à jour dure ~ 1 heure.
- sur nos serveurs HP Proliant ML 350 bi-processeur 3 Ghz Intel Pentiuml 4 et 4 Go de RAM, la mise à jour dure 4 heure.

Sur le serveur, le processus de mise à jour ainsi que le processus SQL ne dépasse pas 5% de la CPU.
Nous pensons à un problème de gestion de la CPU. C'est pourquoi dans notre SQL Server, nous avons paramétré qu'un seul processeur pour le même résultat.

Si vous avez une idée, n'hésitez pas, nous commençons à désespérer.

[elsuket]

Bonjour,

Les deux serveurs sont-ils utilisés avec la même intensité ?

Si vous avez un nombre plus important de transactions sur le second serveru, il est normal que cela prenne plus de temps...
Quel est le type de la mise à jour ? une restauration de sauvegarde, un script, ... ?

Beaucoup d'autres raisons existent pour qu'il y ait des différences notables de performances entre deux serveurs

@++

[Maximoute]

La machine NEC n'est pas un serveur, mais un poste de travail standard sur lequel nous avons fait des tests.
Par contre, cette mise à jour dure 4h sur le serveur de production et de RE7 qui sont exactement identique.

Concernant la mise à jour, elle provient d'une société externe qui ne nous donne aucun info.
Tout ce que nous savons, c'est qu'elle travaille sur notre base SQL Server 2000.

En fait, ce que nous aimerions savoir, c'est est-ce qu'il n'y aurait pas de contrainte sur notre matériel. Surtout sur la cohabitation entre notre bi-processeur et le SQL Server.

[elsuket]

C'est difficile à dire sans avoir la machine sous les yeux, mais je ne crois pas à un problème de support de SQL Server sur la machine HP.

Avez-vous fait une petite trace avec le Profiler ?

@++

[lmalta]

Bonjour,

votre serveur de test à t'il été crée à partir de la dernière sauvegarde de votre serveur HP,
si ce n'est pas le cas alors
- soit comme le dit CTEMan une charge importante tourne en même temps sur le HP
- soit un contrôle d'administration de SQL est peut être necessaire (index, statistique, ...)
Suivez via le profiler ou cela "pêche" mais sans info supplémentaire il semble difficile de vous aider

@ +

[Maximoute]

Merci à tous,

en fait, le serveur est toute la semaine en RE7. Donc je ne peux pas y toucher, mais dès que je reprends la main, je tenterai de passer la mise à jour avec le profiler en route.

[SQLpro]

Voyez aussi si votre serveur est en hyper threading. Si c'est le cas, désactivez le car il existe un bug connu et non contournable à ce sujet.

A +

[Maximoute]

Merci à tous pour votre participation.

En effet, l'hyper-threading était activé et nous avons testé en le désactivant.
On y a cru, mais sans résultat.

[SQLpro]

Regardez comment se comporte le journal de transaction : quel volume fait-il, y a t-il des transactions qui durent (DBCC OPENTRAN), sys.dm_tran_active_transactions. Voyez si votre JT est en auto grow ou prétaillé...

A +