Version imprimable
bonjour a tous
Je sais que cette question n'a pas beaucoup de sens mais ça pourrait m'être utile à un moment
ma question est le suivant: sauf le cas de démarrage du serveur , dans quel cas un serveur SGBD subit une action de vidage du cache ??
et ms deuxième question si il est déconseiller de vider la cache pourquoi Microsoft nous propose la commandmerci pour l'aide de nos expertCode:dbcc freeproccache
Hello,
Des entrées du cache sont vidés lorsqu'il existe une pression mémoire sur le serveur (que ce soit une pression externe ou une pression interne - intra caches) ou à cause de l'utilisation de commande comme AUTO_CLOSE.
La commande DBCC FREEPROCCACHE est principalement utilisée pour des tests de performance sur environnement qui n'est pas en production.
En production il est évident que cette commande ne doit pas être utilisée à la légère (voir jamais).
Par ailleurs, cette commande a évolué avec le temps et permet de vider de manière plus granulaires des entrées dans le cache (pour un plan particulier. une requête ou un pool de ressource par exemple)
++
Pour compléter la réponse de Mikedavem, on peut se référer à la documentation de ALTER DATABASE SET, ici :
OFFLINE
READ_WRITE
ONLINE
MODIFY FILEGROUP DEFAULT
MODIFY_NAME
MODIFY FILEGROUP READ_WRITE
COLLATE
MODIFY FILEGROUP READ_ONLY
READ_ONLY
Par ailleurs, le changement de certaines options d'instance peuvent aussi vider le cache de procédures, comme :
cross db ownership chaining
index create memory
cost threshold for parallelism
max degree of parallelism
max text repl size
min memory per query
min server memory
max server memory
query governor cost limit
query wait
remote query timeout
user options
Je ne garantis pas que la liste ci-dessus soit exhaustive.
@++ ;)
bonjour a tous
Merci pour vos réponses
sur la même piste ,je pose cette question
Est ce que une grande lecture volumineuse sur un grand table peuvent entraîner une vidage du cache ?
cordialement
Hello,
Une requête volumineuse peut affecter les différents caches SQL Server. On parlera de pression interne mais il n'y aura pas de "vidage" à proprement dit.
De plus, si le volume de données rapatrié est estimé à + 10% de la taille du buffer cache alors il n'y aura pas d'effet sur ce dernier. En effet, dans ce cas le moteur marque les pages concernées comme défavorisés lorsqu'elles sont lues dans le buffer pool, ce qui entraine un flush de ces dernières en dehors de l'algorithme habituel LRU-K. Celles-ci ne sont donc restent pas dans le cache et permettent de ne pas le polluer (au prix d'une certaine activité IO cependant).
++