Discussion :

[SQLpro]

Il faudra quand même aller chercher les données sur le disque, il me semble ...

Toujours non....

Si votre mémoire a été correctement dimensionnée, moins de 1% du volume des données doit être lu depuis le disque, le reste étant déjà en mémoire...

reprenons ma démo puisque vous ne l'avez pas comprise (je la simplifie volontairement en ne parlant pas des actions entreprises sur le journal de transaction)...

Un utilisateur fait un INSERT via un port réseau. L'insert vient donc bien directement en RAM. La ligne est insérée dans une des pages mémoire de la table. Si la table (ou au moins une de ses pages avec un peu d'espace vide) n'est pas déjà en RAM alors il faudra lire depuis le disque une page ou mettre la ligne... C'est ce fameux 1%...

Au bout d'un certains temps (quelques minutes au maximum) on ira écrire la page dans le fichier contenant les données. Cette technique d'écriture retardée permet deux avantages :
1) faire des salves d'écriture soit par dépassement du temps impartit, soit on iddle du proc
2) regrouper les écritures dans l'ordre de contiguïté physique des pages par rapport au disque et non pas écrire séquentiellement les pages dans leur ordre d'arrivée (Michael Stonebraker avit prévu cela dès les années 70)...
Et donc ainsi de passer le minimum de temps en opérations d'IO disque !

Maintenant je voit que vous avez peu car la donnée n'est présente qu'en mémoire pendant un certains temps... C'est là qu'intervient le journal qui consiste à écrire tout simplement la demande SQL brute de fonderie dans le fichier de journalisation. Mais écrire un fichier "writeAhead" basiquement binaire est quelques chose de très rapide en regard de l'effort à faire pour insérer une ligne d'une table au bon endroit.
Il faut ainsi remarquer que le jorunal est l'un des tout premier point de contention d'un SGBDR.

Vous constaterez donc que les données sont préalablement mises en mémoire et non mise en mémoire suite à la lecture d'un disque !

Mais cette technologie est la conséquence de plus de 30 années de R&D

A +

[fsmrel]

Bonsoir,

Il faudra quand même aller chercher les données sur le disque, il me semble ...

Toujours non....
Si votre mémoire a été correctement dimensionnée, moins de 1% du volume des données doit être lu depuis le disque, le reste étant déjà en mémoire...

Hum... Je suis plutôt d’accord avec Luc Orient. Considérons l’environnement suivant : Mainframe IBM, DB2 for z/OS. Pour avoir passé des nuits à observer au gnagnascope (Detector de Platinum en l’occurrence) et en temps réel le comportement de batchs conséquents du genre "Appels des cotisations", avec lesquels on procède à des jointures de plein de tables comportant entre 10 millions et 100 millions de lignes (sans parler des mises à jour), je n’ai pas constaté que 99% des données étaient déjà présentes en mémoire, très loin s’en faut (même si je n’ai plus les chiffres en tête).

Même si beaucoup de données sont déjà mémorisées, le SGBD est bien obligé d’accéder aux disques à un moment donné pour récupérer ce qui manque et pouvoir garnir ses buffer pools. Certes DB2 sait ce qu'il a déjà en mémoire et à défaut s’il doit lire les pages des disques par rafales rapides plutôt qu’à l’unité (voire basculer en temps réel d’un mode à l’autre), mais quand même. Et surtout, mes batchs ne sont pas seuls à s’activer : simultanément, ils ont plein de copains qui consomment eux aussi les ressources. Si j’ai besoin de 60 GB de mémoire vive pour mes table spaces, index spaces, fichiers de travail, de tri, journaux en tous genres, etc., et si on est une centaine en concurrence, ça m’étonnerait que la Production privilégie mes batchs, quelle que soit sa bonne volonté. Mais si un jour on met à ma disposition une batterie de Z10 à 1,5 TB de mémoire, je serai preneur...

[SQLpro]

un gain de 15 % sur la performance.

C'est un gain nul et idiot. Le database tuning advisor par ses énormité a été supprimé de la version 2000. Même le support officiel MS déconseille de l'utiliser !

Sur la mise en cache. oui 99% des données en cache est un but. Si 95% l'est sur une VLDB, c'est déjà pas mal...

A +