lenteur de base sous SQL 2008 [Résolu]

[tibofo]

Bonjour
J'utilise sur mon PC portable, un serveur SQL 2008 avec qq bases de clients et une base d'essai qui est plutôt petite en taille. (ce sont des bases utilisées dans un logiciel de Gestion SAGE). (donc le tout en local)

De façon aléatoire, j'ai des lenteurs en utilisation de mes bases.
Voici ce que je constate :
J'ouvre ma base (via mon logiciel), elle mets 1 min à s'ouvrir (au lieu d'env 20 sec)
j'ouvre une liste quelconque : env 1 min d'attente (au lieu de quasi immédiat)
et ainsi de suite sur toutes les manipulations

Je quitte ma base et je la relance = idem
je quitte et relance = aucune lenteurs, tout marche à une vitesse normale.

(ce n'est pas toujours la 3ème ouverture que tout marche bien, parfois c'est dés la première, parfois au bout de 5...)

Ce problème de lenteurs semble aléatoire et le fait quelle que soit la base ouverte.

J'ai un doute sur un point peut-être en rapport alors je vous le soumet : ces pb me semblent avoir commencé suite à un passage chez un client. Où pour accèder à son réseau, il m'a demandé de changer mes configs IP en forçant les adresses. Le lendemain, j'avais constaté ces lenteurs. Je m'en suis rappelé et j'ai remis mes IP en automatique. Cela a remarché sur le coup.
Mais depuis c'est la loterie.

auriez-vous une idée de points à contrôler ?
Merci
Thibault

[iberserk]

Votre base est installé sur une instance locale sur votre portable?

N'avez vous pas simplement des contentions de mémoire sur votre portable(SQL SERVER 'vampirise' votre mémoire)?

[tibofo]

oui je suis en instance locale et nommée.

Effectivement SQL Server me mange de la ressource mémoire. Mais cela ne fait pas ramer mon portable. J'ai souvent d'autres applis ouverte en même temps sans ressentir des lenteurs ailleurs.

(il me sert à récupérer des copies des bases clients pour une formation ou autres...)

[SQLpro]

Ce comportement est tout à fait normal vu qu'un SGBDR travaille exclusivement en mémoire. Il lui faut donc monter les données en mémoire. Si d'autres applications ont déjà occupées toute la RAM, il faudra les faire en restituer, ce qui prends du temps.
Conclusion au fur et à mesure que vous utiliser votre BD, la ram est prise par SQL. Si vous relancez plusieurs fois votre SGBDR, la ram prise précédemment n'a sans doute pas le temps d'être accaparée par d'autres logiciels et SQL en profite donc plus vite.
C'est pourquoi en principe un SGBDR doit être installé sur une machine dédiée pour être stable et performant !

A +

[iberserk]

Ce comportement est tout à fait normal vu qu'un SGBDR travaille exclusivement en mémoire. Il lui faut donc monter les données en mémoire. Si d'autres applications ont déjà occupées toute la RAM, il faudra les faire en restituer, ce qui prends du temps.
Conclusion au fur et à mesure que vous utiliser votre BD, la ram est prise par SQL. Si vous relancez plusieurs fois votre SGBDR, la ram prise précédemment n'a sans doute pas le temps d'être accaparée par d'autres logiciels et SQL en profite donc plus vite.
C'est pourquoi en principe un SGBDR doit être installé sur une machine dédiée pour être stable et performant !

A +

J'ajouterais une possible saturation du disque, quel est votre ratio espace disque total/libre?

[mikedavem]

En local si vous avez d'autres applications il faudra penser également à paramétrer l'option de serveur max server memory (MB) pour éviter que votre instance SQL Server accapare l'ensemble de la mémoire au détriment de vos applications.

++

[tibofo]

MErci à vous tous.

J'approche de la saturation de mon DD en effet.
Je tourne entre 1 et 2 go de libre seulement.

Je vais regarder aussi le max server memory

Bye