Mon cache est plus gros que le tien !

», géré par SQL Server, a pour rôle de limiter les lectures physiques.

Une fois la donnée lue, elle est stockée dans le buffer cache et reste à disposition de SQL Server dans l’hypothèse où celui-ci aurait besoin d’y accéder de nouveau. Des mécanismes de purge sont implémentés dans SQL Server pour gérer cet espace mémoire. Le cache au niveau du contrôleur a principalement un rôle dans les accès en écriture.

En effet, au lieu d’attendre que l’information soit effectivement écrite sur disque, l’écriture sera acquittée lorsque la donnée sera écrite dans le cache (write back caching). La seule condition pour utiliser ce mécanisme est de disposer de batteries qui permettront de maintenir l’information stockée dans le cache en cas de panne de secteur. Le cache au niveau du contrôleur a d’autres rôles.

Pour optimiser les accès disques, il pourra également tenter de regrouper des données stockées dans le cache pour écrire des blocs de données plus large et ainsi limiter, dans une certaine mesure, les accès aléatoires. D’autre part, dans le cas de lecture séquentielle, le contrôleur pourra anticiper les lectures sur disques et les stocker en mémoire; on parle de « Read ahead ».

A noter que les effets du « Read ahead » au niveau du contrôleur sur SQL Server sont assez limités. Dans la plupart des cas, les lectures anticipées sont initiées directement par le moteur. Suivant la baie de stockage utilisée, l’administrateur pourra intervenir sur le profil du cache à utiliser (lecture, écriture, taille) en Figure 2 fonction du profil d’activité. Souvent, elle dispose d’un algorithme élaboré qui ajuste, suivant ce profil, l’utilisation et le comportement du cache.