Depuis la version 8, le BUFFER CACHE est divisé en plusieurs segments : DEFAULT, KEEP et RECYCLE.
Contrairement à ce que leurs noms peuvent laisser penser,
ils sont gérés tous les 3 exactement de la même façon, par les même règles LRU (Last Recently Used).
En général, on utilise le buffer KEEP pour y stocker les blocks des tables que l'on interroge souvent;
et le buffer RECYCLE pour des données plus volatiles.
Par exemple, si on a une table de REFERENCE, une table de COMMANDES et une table IMAGE_PRODUIT, on aura intérêt à répartir les tables de la façon suivante :
- COMMANDES sur le buffer pool DEFAULT
- REFERENCE dans le buffer pool KEEP
- IMAGE_PRODUIT dans le buffer pool RECYCLE
En effet, si l'on interroge l'image (volume important), cela va nécessiter de sortir du pool de nombreux blocs de REFERENCE
qu'il faudra recharger ultérieurement alors que les blocs de l'image auront très peu de chance de resservir...
Les noms des buffers pools ne sont qu'une astuce mnémotechnique, car ils pourraient très bien s'appeller A, B et C, cela ne changerait rien !
Remarque : depuis la 9i, il est possible de définir des buffer pools de taille de block différente ( db_nk_cache_size) mais les buffer KEEP et RECYCLE auront forcément comme taille de bloc la taille DEFAULT.
Donc, on a 3 pools de taille par défault et jusqu'à 4 buffers de taille différente, ce qui fait 7 zones buffers indépendantes au maximum !
(mais je vous déconseille vivement d'implémenter un tel système, ça deviendra impossible à administrer/tuner !)
La requête est la suivante :
Attention : avec les multiples buffers pools, il n'est plus possible de monitorer les ratios par la vue
habituellement utilisée (v$SysStat) mais Oracle a implémenté la vue v$Buffer_Pool_Statistics :