Y aurait-il des pertes de mémoires dans SQL Server?

Bonjour,
Ce comportement est normal, il est du a la gestion de la mémoire.
Je suppose que tu as laissé la configuration pardéfaut qui est dynamique et
que tu n'as pas défini de valeur pour Max Memory
Si SQL a besoin de memoire il l'alloue mais ne la libere que dans certaine
conditions (var l'extrait du BOL ci dessous)
En fait, il prefere allouer la memoire et la blibéré en cas de besoin
uniquement, cela evite les allocations/ déallocations de memoire.

Pour être sur tout de même qu'il n'y a pas de memory leak, tu peux fixer le
paramêtres MAX MEMORY à 500 Mo et vérifier qu'il n'est pas dépasser.

Richardp


Gestion dynamique de la mémoire sous Windows NT et Windows 2000
Lors du fonctionnement sous Microsoft® Windows NT® ou Windows® 2000, le
comportement par défaut de la gestion de la mémoire du moteur de base de
données de SQL Server n'est pas d'acquérir un volume de mémoire spécifique,
mais plutôt d'acquérir un volume de mémoire maximal sans pour autant générer
un excès d'E/S de pagination. Le moteur de base de données réalise cette
opération en occupant un maximum de mémoire disponible, tout en laissant
suffisamment de mémoire libre pour éviter au système d'exploitation de
devoir échanger de la mémoire.

Lors du démarrage d'une instance SQL Server, il acquiert généralement de 8 à
12 Mo de mémoire pour réaliser le processus d'initialisation. Lorsque
l'instance est initialisée, il n'acquiert plus de mémoire jusqu'à ce que des
utilisateurs se connectent et commencent à générer de la charge de travail.
L'instance continue alors à acquérir de la mémoire comme l'exige la prise en
charge de la charge de travail demandée. Au fur et à mesure que des
utilisateurs se connectent et lancent des requêtes, SQL Server acquiert la
mémoire supplémentaire nécessaire à la prise en charge de cette demande.
L'instance continue à acquérir de la mémoire jusqu'à ce que sa limite
d'affectation de mémoire soit atteinte et ne libèrera de la mémoire qu'après
avoir atteint cette limite inférieure.

Afin d'acquérir autant de mémoire que possible sans générer un excès d'E/S
de pagination, chaque instance SQL Server se fixe une limite d'acquisition
de mémoire jusqu'à ce que la mémoire physique disponible sur l'ordinateur
soit comprise entre 4 et 10 Mo. Cette plage a été choisie parce que des
tests ont montré que Windows NT et Windows 2000 effectuaient un échange de
mémoire minimal tant que les allocations de mémoire correspondaient à la
mémoire physique disponible, moins 4 Mo. Une instance SQL Server qui traite
une charge de travail intense conserve la mémoire physique libre à
l'extrémité inférieure de la plage (4 Mo) ; une instance qui traite une
charge de travail légère conserve la mémoire libre à l'extrémité supérieure
de la plage (10 Mo).

Une instance SQL Server fait varier cette limite en fonction des variations
de la charge de travail. Lorsque des utilisateurs supplémentaires se
connectent et générent plus de travail, l'instance tend à acquérir plus de
mémoire afin de maintenir la mémoire libre disponible à la limite inférieure
de 4 Mo. Lorsque la charge de travail diminue, l'instance adapte sa limite
vers les 10 Mo d'espace libre, et libère de la mémoire pour le système
d'exploitation. Cette quantité d'espace libre évite à Windows NT ou à
Windows 2000 d'effectuer des échanges excessifs et permet à SQL Server de
disposer du cache de tampons le plus grand possible, sans échange
supplémentaire.

La spécification de la limite de mémoire pour une instance dépend de la
demande de pages dans le pool de tampons de la base de données par rapport à
la taille du pool disponible. À tout moment, la demande globale de pages de
tampons est déterminée par le nombre de pages de données nécessaires pour
satisfaire toutes les requêtes en cours d'exécution. Si la demande de pages
de données est importante par rapport au nombre de pages situées dans le
cache des tampons, chaque page qui se trouve actuellement dans le tampon est
susceptible d'être remplacée par une nouvelle page dans un délai
relativement court. Cette opération est mesurée par le compteur de
performances d'espérance de vie d'une page de l'objet Gestionnaire de
tampons. Lorsque la demande est élevée et que la taille du cache des tampons
est relativement faible, il en résulte une espérance de vie courte, l'effet
net étant une augmentation des E/S car les pages tendent à être réécrites
avant de pouvoir être référencées par plusieurs lectures logiques. Le moteur
de base de données peut alléger ce processus en acquérant plus de mémoire
afin d'augmenter la taille du cache des tampons. Le moteur de base de
données fixe une limite de mémoire disponible à la valeur supérieure (10 Mo)
lorsque l'espérance de vie de la page est longue, et à la valeur inférieure
(4 Mo) lorsque l'espérance de vie de la page est courte.

Étant donné que d'autres applications sont démarrées sur l'ordinateur
exécutant une instance SQL Server, elles consomment de la mémoire et la
quantité de mémoire physique disponible descend en dessous de la cible de
SQL Server. L'instance SQL Server libère alors suffisamment de mémoire de
son espace d'adressage pour libérer la mémoire et la réattribuer à la cible
SQL Server. Si une autre application est arrêtée et que de la mémoire se
libère, l'instance SQL Server augmente la taille de son allocation de
mémoire. SQL Server peut libérer et acquérir plusieurs mégaoctets de mémoire
chaque seconde, permettant ainsi un ajustement rapide aux variations
d'allocation de mémoire.






"ThunderMusic" <NOdanylat@sympatico.caSPAM> wrote in message
news:eBOo3StgDHA.616@TK2MSFTNGP11.phx.gbl...

Bonjour,
Pourquoi lorsque je démarre mon SQL Server, le processus de

SQL

Server prend environ 200 mb de mémoire RAM. Après quelques jours (3-4
jours), la mémoire utilisée est de 550 mb de RAM. Pourquoi cette si grande
différence? Serait-ce causé par une perte de mémoire (Memory Leak)?
J'utilise la version 7.

Merci

ThunderMusic