Discussion :

[bdmax]

Bonsoir,

Est-il possible de préparer les données de travail en les mettant en cache avant de les manipuler dans une procédure stockée.

Le problème, je dois manipuler des données de 4 tables avec de nombreux appels. Or je souhaite mettre en cache ces tables pour éviter les accès disque pendant mon traitement.

est-ce possible, si oui coment.

Je ne trouve rien sur le net à part que c'est super bien de mettre les données en cache...

[ylarvor]

Les données montent en mémoire ( en cache ) dès lors que vous en avez besoin. C'est automatique! sql serveur travaille en mémoire et non sur disque! Par conséquent, il suffit d'avoir suffisament de mémoire sur votre serveur pour stocker les données de vos 4 tables. Lors du premier appel, ca monte, lors des appels suivant, les données sont déjà!

[bdmax]

En résumé,

pour optimiser les traitements si je fais une requête select sur les 4 tables de travail en limitant l'horizon aux données utilisées, celles-ci vont monter en mémoire.

Lorsque je vais faire mes traitements sur ces tables les requêtes utiliseront le cache et non le disque ?

c'est un peu trop beau...

Ne peut-on pas allouer de l'espace mémoire pour monter des vues en mémoire puis travailler sur ces vues ?

J'ai entendu dire que dans les salles de marché, pour les gros volumes de données les tables étaient montée en mémoire afin d'optimiser les perf.

[ylarvor]

pour optimiser les traitements si je fais une requête select sur les 4 tables de travail en limitant l'horizon aux données utilisées, celles-ci vont monter en mémoire.

Lorsque je vais faire mes traitements sur ces tables les requêtes utiliseront le cache et non le disque ?

c'est un peu trop beau...

vous pouvez faire l'essai.

la premiere execution sera plus longue que les suivante ( chargement depuis le disque ) à condition d'avoir la memoire suffisante sur le serveur.

Ne peut-on pas allouer de l'espace mémoire pour monter des vues en mémoire puis travailler sur ces vues ?

il n'y a aucun mecanisme manuel pour gerer cela, le serveur se debrouille tout seul et c'est plus simple comme cela.

[bdmax]

Que penses-tu de l'instruction

DBCC PINTABLE ?

[ylarvor]

Je ne connaissais pas... Ca me parrait assez dangereux à utiliser, non ? Tu interviens sur les couches systèmes de sql serveur.

Tu indiques qu'une table ne doit pas être nettoyé avec PINTABLE et qu'elle peut être nettoyer avec UNPINTABLE. si tu te plantes, tu cree un fantome en memoire... non ?

d'ailleurs, les avis des dba sur le net, n'ont pas l'air de recommander cet usage...

[SQLpro]

pour optimiser les traitements si je fais une requête select sur les 4 tables de travail en limitant l'horizon aux données utilisées, celles-ci vont monter en mémoire.

Oui, mais ne faites pas cela préventivement. En effet cela risque d'encombrer la mémoire inutilement et faire travailler le serveur pour presque rien.
Les SGBDR comme SQL Server utilisent des algorithmes de gestion de cache basés sur l'utilisation des données. Plus une donnée est utiliseée plus elle restera longtemps en cache... Par analogie, ou mettez vous vos chaussettes et vos affaires de ski ?

Lorsque je vais faire mes traitements sur ces tables les requêtes utiliseront le cache et non le disque ?

Un SGBDR n'utilise JAMAIS le disque pour traiter les requêtes. Il faut que toute les données montent en mémoire pour que la requête puisse être traitée. Il y a pour cela deux moteurs : le moteur relationnel qui traite les requêtes en mémoire et le moteur de stockage qui assure le stockage et l'alimentation de la mémoire (cache).

c'est un peu trop beau...

Cela ne fait que 30 ans que Michael Stonebraker à édicter les principes physiques de fonctionnement des SGBDR qui sont aujourd'hui toujours en vigueur, avec quelques améliorations notables depuis !

Ne peut-on pas allouer de l'espace mémoire pour monter des vues en mémoire puis travailler sur ces vues ?

L'allocation mémoire est par défaut infinie. Le serveur utilisera toutes la RAM s'il en éprouve le besoin. En revanche si des applications autres utilisent de la mémoire, SQL Server piquera la mémoire allouée à ces applications. Il est en effet prioritaire pour l'acquisition de mémoire au détriment de toutes les autres applications.

J'ai entendu dire que dans les salles de marché, pour les gros volumes de données les tables étaient montée en mémoire afin d'optimiser les perf.

Cette méthode ancienne est aujourd'hui dévaluée (on appele cela le PIN TABLE). En effet les algorithmes sont suffisamment puissants pour ce faire. Elle possède en revanche un inconvénient majeur : une fois forcée en cache, la table empêche d'autres données d'être place en mémoire. Si la table forcée occupe une place importante en mémoire elle va obliger le système à faire un roll over des données qui peut devenir très pénalisant. En imaginant le pire : la table forcée occupe 98% de la RAM, il ne reste plus que 2% pour les autres tables ce qui oblige le moteur de stockage à de très nombreux accès disque et donc des performances lamentables. Voila pourquoi cette méthode est dangereuse et a été désactivée dans 2005. (si l'on voulait l'employer il faudrait un DBA qui auditerait tous les 1/4 d'heure l'utilisation de la RAM !)

A +

[bdmax]

Merci,

Donc retour au point de départ.

La seule façon d'optimiser mes temps de traitement c'est de jouer sur les index.

Question bonus:
Si je crée plusieurs vue d'une grosse table (20 colonnes, 12millions de lignes), avec pour chaque vue la clef primaire + 5 colonnes utiles pour traitement.
Et en utilisant l'une ou l'autre des vues selon les colonnes utilisées.

est-ce que je vais gagner en temps de traitement ?

exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
TABLE T_TEST(clef1, clef2, col1,...., col2)

VUE V_TEST1(clef1, clef2, col1, col2, col5, col6)

VUE V_TEST2(clef1, clef2, col7, col8, col9, col10)

select * from V_TEST1

select * from V_TEST2

Théoriquement les résultats devraient être plus rapide que :

select clef1, clef2, col1, col2, col5, col6 from T_TEST
et
select clef1, clef2, col7, col8, col9, col10 from T_TEST

Non ?

Je crée une nouvelle discussion.

[SQLpro]

La seule façon d'optimiser mes temps de traitement c'est de jouer sur les index.

Pas seulement !

1) faire de belles requêtes (essayer différentes stratégie de résolution)
2) repenser son modèle de données afin d'économiser les volumes de données traités.

Lisez l'étude que j'ai donné en exemple. On y passe d'un coût de 32000 à 2...
Au passage on voit toutes ces techniques :
http://sqlpro.developpez.com/optimisation/indexation/

A +

[bdmax]

je parcours l'étude !

Cela semble intéressant en effet.

Merci.