Version imprimable
Bonjour,
Toujours dans le cadre de l'optimization :
Quand on fait une requête ça prend un temps X
et quand on refait la même requête c'est beaucoup plus rapide.
Et cela vient du fait que SQL Server met la requête dans le cache.
Dans le cadre d'une grosse requête, qui retourne beaucoup de résultats, comment puis-je forcer la mise en cache ?
Déjà est-ce que c'est possible ?
Ou bien lui faire faire une requête dans le vide avec un TOP 1 par exemple ....
Merci
bonjour,
Seul le plan d'exécution est mis en cache, pas les résultats...Citation:
Dans le cadre d'une grosse requête, qui retourne beaucoup de résultats, comment puis-je forcer la mise en cache ?
Schématiquement, toute requête executée est mise en "query cache" pour lui associer un plan d'exécuution.
A l'exécution, les pages lues sont montées dans le buffer cache et à la deuxième exécution les données sont déjà en mémoire donc le temps est plus court.
Donc si votre requête retourne des millions de lignes, il n'y a grand chose à faire à ce niveau là. Il faut surtout regarder le plan d'exécution de cette requête pour voir si des index sont utilisés pour limiter le coût en I/O, l'indicateur principal de performance d'une requête.
si on mettait en cache les données a quoi servirait-il d'avoir une BDD car le cache est parfois suffisant "pour se faire une idée" du type google, mais lorsque l'on demande des infos a une base on veut des données "a jour".
le fait que plus tu exécutes ta requête, plus elle va vite (surtout vrai sous Oracle) vient du fait des statistics et de ce que t'as dis kagemaru; entre la première et la deuxième exécution, en plus, il y a le temps de compilation en moins
En fait, c'est presque ça :
Cela signifie bien que lorsqu'une requête est établie, on l'exécute et ça met un certain temps. Ensuite, elle est mise dans le cache.Citation:
Understanding Results Caching
After the Query Processor executes a query, it returns to the client the data that resulted from query execution. If Liquid Data results caching is enabled, the first time a query is run, Liquid Data saves its results into a query results cache. The next time the query is run with the same parameters, Liquid Data checks the cache configuration and, if the results have not expired, quickly retrieves the results from the cache rather than re-running the query. In this way, for queries that are executed repeatedly with the same parameters, using the results query cache reduces processing time and enhances overall system performance.
Si on la ré-exécute, on va d'abord regarder si c'est la même et que les données n'ont pas changées ! Et alors à ce moment là que l'on gagne du temps !!
Car une requête renvoie toujours les données à jour.
il aurait alors fallu préciser que vous utilisez le produit Liquid Data, ce qui est un cache supplémentaire par rapport à la base de données ...
en fait nan, j'utilise pas Liquid Data ...
J'ai juste trouvé ça sur le net en tapant des bons mots clés sur Google !!
J'utilise SQL Server 2005.
C'est quoi Liquid Data ???
SQL Server possède un cache de données (les lignes des tables :en fait des pages de données) et un cache des procédures.
Toute requête est mise en cache avec son plan associé.
Toute données nécessaire à toute requête est aussi mis en cache...
Le problème est que la cache n'est pas extensible à l'infini puisque c'est la RAM !
Ce qui se passe est simple : les entrées du cache les moins utilisées (données et procédures) sont celles qui dégagent les premières lorsqu'il n'y a plus assez de RAM pour tout mettre en cache.
De ce fait si vous jouez une requête pour la première fois sur une table rarement utilisée les données vont monter en cache (requête à froid) . Si une 2e exécution a lieu juste après, alors les données et le plan de requête étant en cache cela va aller très vite (requête à chaud).
Petit à petit au fur et à mesure de l'utilisation du SGBDR les pages de données de cette table vont disparaître pour laisser place à des nouvelles données nécessaires à d'autres requêtes.
Pour de plus amples informations lisez la série d'articles que j'ai écrit à ce sujet pour SQL Server magazine :
http://www.sqlspot.com/Voulez-vous-optimiser-votre.html
A +