Requetes SQL Serveur saturent mon disque dur, je ne sais plus quoi faire :-(

Bonjour,

Je viens de réinstaller un nouveau serveur, pour remplacer l'ancien bien trop lent, et j'ai exactement les mêmes problèmes de lenteur sur la nouvelle machine.
Je suis complètement perdu, j'ai vraiment besoin d'un coup de pouce.

A chaque fois que je lance des requêtes (notamment lecture) que ce soit depuis l'intranet, depuis une application et même depuis SQL Manager mon observateur de performances de windows place la jauge de la Longueur Moyenne de File d'Attente du disque à fond pendant l’exécution de(s) requête(s)

Je ne trouve pas d’où vient ce problème ... et c'est pas faute d'avoir chercher.

J'utilise SQL Server 2000 sur un Windows Server 2003

Help me :cry:

Vous avez un goulet d'étranglement au niveau des I/O disques.

Ça peut être une taille de RAM sous-dimensionnée.
Une mauvaise indexation, des statistiques qui ne sont pas à jour.

Il faudrait voir les requêtes, avoir des informations sur la volumétrie et étudier les plans d’exécution, le type de stockage (SAN, RAID, NAS xD).

D'autre applications tournent peut-être en même temps sur le serveur ? Du type anti-virus, etc.

Merci beaucoup pour ta réponse :ccool:

Pour la RAM je pense que c'est bon car il y a 12G

Les indexation sont faites régulièrement, mais comment savoir si c'est mal indexé ?
Comment savoir si les stats ne sont pas à jour ?

Même les requetes simple font monter la compteur. Juste le fait d'ouvrir une base dans le SQL Manager fait stresser le disque.
Tu vois quoi par plan d'exécution ?

Le type de stockage est un RAID 5.

Oui il y a un antivirus qui tourne mais je n'arrive pas à l'arreter (Sophos)

Désolé j'ai pas un gros niveau en SQL.

Il faut prendre un exemple de requête lente et afficher le détail de l'exécution. Par exemple sous management studio:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

set statistics time on GO set statistics io on GO SELECT ..... GO   set showplan_text on GO SELECT ... GO set showplan_text off GO   set statistics time off GO set statistics io off GO

---

et nous renvoyer tout ça avec cardinalité des tables impliquées (nb de lignes)

Bon, j'ai un peu plus d'info la dessus.
Ca ne viendrait pas forcement de SQL Server car même un copié collé d'un gros fichier (100Mo) fait stresser la machine.
Par exemple ici le temps que le fichier se copie ces 2 courbes reste au plafond, sur d'autres machines les courbes montent et fluctuent mais jamais ne plafonnent.
http://img5.imageshack.us/img5/1922/sansre3z.jpg

En fait ce problème est arrivé du jour au lendemain après le crash d'un DD du raid. Depuis un rien fais stresser la machine. Et ce même sur ce nouveau serveur.

Je ne comprends plus rien ...

Est-ce que le disque dans la grappe en échec a été resynchronisé depuis ? Si tu es en RAID 5 et si le disque est toujours en défaut dans le tiroir, chaque IO doit être recomposée avec la parité correspondante. Qu'est-ce que c'est comme stockage, des disques internes, un SAN ?

Je rejoins David. Concentrez-vous sur les couches basses problématiques avant de tenter de trouver une explication au niveau de la base.

Il n'y a rien à dire : un SGBDR sans disque, CPU ou sans mémoire, ça marche vraiment pô bien :calim2: