Problème de performance SQL Server 2005

Question

J'ai un environnement de développement et un environnement UAT. Dev est à notre place, UAT est à la place du client. Notre machine DEV est un XEON 4 core @ 2,33GHz, 4Go de RAM avec Windows server 2003 La machine physique UAT est identique, mais une machine virtuelle est utilisée (sous VMWare). Je ne connais pas les paramètres exacts utilisés pour cette machine virtuelle.

Le problème est que le serveur SQL sur la machine dev fonctionne très bien et celui sur l'UAT est très très lent.

L'ouverture de SQL Server Management Studio prend 2 minutes sur l'ordinateur UAT. L'exécution même d'une simple demande de sélection est également très lente. La base de données est relativement petite (6 Go). L'ouverture de toute autre application sur ce serveur fonctionne bien. Donc, nous pensons qu'il y a un problème avec l'instance du serveur sql et je dois enquêter pour trouver la raison.

Voici ce que je vérifié:

configuration du serveur
• est similaire à celui que nous avons sur DEV.
• il y a assez d'espace sur le disque
• processeurs ne sont pas surchargées (10% utilisé est le maximum atteint)
• mémoire semble aussi être OK.
• données et les fichiers journaux sont configurés pour se développer automatiquement
• modèle de récupération SQL Server: FULL

Il semble dans le journal de base de données que cette erreur est survenue au moins une fois (je n'avoir accès à une petite partie) :

2008-10-14 19: 16: 54.84 spid55
Autogrow de fichier 'xxxxx_log' dans la base de données 'xxxxxx' a été annulée par l'utilisateur ou a expiré après 6766 millisec onds. Utilisez ALTER DATABASE pour définir une valeur FILEGROWTH inférieure pour ce fichier ou pour définir explicitement une nouvelle taille de fichier .

Comme il y a assez d'espace sur le disque dur, quelle pourrait être la cause? Pourrait-il être lié à mon problème Perfs? Que dois-je vérifier pour trouver la cause du problème?

Je ne suis pas un expert SqlServer donc si quelqu'un a une suggestion, j'aimerais l'entendre. Merci!

---

Mise à jour 1:
modèle de récupération SQL Server: FULL
La base de données est nouvelle si jusqu'à présent, nous ne l'avons pas effectué une sauvegarde.
Je ne connais pas la taille du fichier journal, je vais vérifier cela.

Mise à jour 2:
Le problème de Management Studio est résolu.

Il est causé par le fait qu'il n'y a pas accès à Internet sur le serveur et que Management Studio semble essayer de se connecter au démarrage: http://weblogs.sqlteam.com/tarad/archive/2006/10/05/13676.aspx

Mais il semble que le problème de perf est pas lié à ce problème. Toujours à la recherche.

Answer 1

Si ce n'est pas un problème de processeur, je me demande si le réseau n'est pas configuré correctement. Si vous essayez plusieurs choses et que vous attendez que les connexions expirent, cela pourrait rendre les choses vraiment pénibles.

Answer 2

Cela ressemble à un problème de machine virtuelle. Lorsque "L'ouverture de SQL Server Management Studio prend 2 minutes sur l'ordinateur UAT" - si vous ne vous connectez pas à un serveur SQL à ce moment-là, l'instance SQL Server a peu de rôle à jouer dans cette lenteur.

Si vous voulez dire qu'il faut 2 minutes pour se connecter au SQL Server local, alors je regarderais la mémoire et les paramètres de la machine virtuelle.

Answer 3

Les extensions de virtualisation du processeur sont-elles activées? Désactiver ceux-ci pourrait entraîner une perte de performance assez.

Answer 4

1/Vérifiez la quantité de RAM consommée par le serveur SQL. Pour une petite base de données sur un serveur RAM de 4 Go, je définirais SQL Server pour ne pas dépasser 1 Go (1024 Mo) de RAM.

2/Je vérifie la taille de la croissance automatique pour les fichiers DB et le fichier LOG. Nous évitons d'utiliser des pourcentages de croissance et utilisons des tailles de croissance MB fixes (comme croître en morceaux de 1 Mo).

3/Assurez-vous que votre sauvegarde de vos transactions se fait régulièrement, sinon elles ne feront que croître et se développer. (Sauvegardez également la base de données complète pendant que vous y êtes!)

4/Quelle est la configuration du disque? Évitez RAID 5 pour les systèmes d'E/S élevés (utilisez des lecteurs de données en miroir), placez vos fichiers LOGS et DATA sur des disques différents, vérifiez que votre matrice RAID est correctement configurée. Y a-t-il d'autres systèmes utilisant les disques?

5/Utilisez SQL Profiler pour examiner ce que fait réellement le serveur. Vous pouvez être surpris de voir à quel point du code SQL peut fonctionner sur une machine occupée (et à quel point cela peut fonctionner sur une machine dédiée).

Bonne chance.