Hit ratio cache buffer

Version imprimable

Bonjour,

J'utilise la requête suivante pour avoir le ratio de données trouvées en mémoire au profit de celles trouvées sur disque.
Code:

1 2 3 4 5 6 7 ttitle center 'Calcul du Cache Hit Ratio' skip 2 SELECT (V2.Value + V1.Value) As "Blocs lus mémoires", V3.Value AS "Blocs lus disques", (1-(V3.value / (V1.value + V2.value))) * 100 AS "Buffer cache" FROM v$sysstat V1, v$sysstat V2, v$sysstat V3 WHERE V1.name = 'db block gets' AND V2.name = 'consistent gets' AND V3.name = 'physical reads';
Résultat

Citation:

Calcul du Cache Hit Ratio

Blocs lus mémoires Blocs lus disques Buffer cache
------------------ ----------------- ------------
279951272 22726306 91,8820494

Je suis un peu étonné des bons résultats sur une base de 700 Go avec un cache de 385 Mo. Valeurs toujours supérieures à 90 même au démarrage de l'instance (script auto toutes les 30 minutes en ce moment pour étudier le bon dimensionnement du buffer cache)
Savez vous comment interpréter les valeurs 'db block gets', 'consistent gets'
'physical reads' ? sont-elles rafraichies régulièrement ?
Merci de vos retours sur le sujet

15/12/2009, 22h50
pachot

Attention, un bon buffer cache hit ratio, c'est signe:
- soit d'une bonne utilisation du buffer cache
- soit de mauvaise requêtes SQL qui vont lire de nombreuses fois toujours les mêmes données

Donc finalement pas très utile...

On peut regarder plutôt l'utilisation de la CPU et les wait events i/o
16/12/2009, 15h19
jkofr

Citation:

Envoyé par pachot

Attention, un bon buffer cache hit ratio, c'est signe:
- soit d'une bonne utilisation du buffer cache
- soit de mauvaise requêtes SQL qui vont lire de nombreuses fois toujours les mêmes données

Donc finalement pas très utile...

On peut regarder plutôt l'utilisation de la CPU et les wait events i/o

Oui, regarde surtout buffer_busy_waits.

Tu peux considérer que si il est important et que dans le même temps les waits au niveau de db_file_sequential_read et db_file_scattered_read ne sont pas importants, alors tu manque de blocks en cache.
Si ils sont importants, alors tes requêtes fonds trop d'IO et il faut optimiser le code SQL.

Jko
16/12/2009, 16h37
laurentleturgez

Si tu veux savoir si ton cache de données a la bonne taille, je te conseillerai plutôt d'aller voir du côté des fonctions de conseils. Donc pour le cache de tampon : veiller à ce que le paramètre DB_CACHE_ADVICE est à ON.

Ensuite, tu attends d'avoir une activité suffisante de ton instance (ne fais pas l'analyse au bout d'une heure !), tu interroges la vue V$DB_CACHE_ADVICE, récupères les valeurs des colonnes SIZE_FOR_ESTIMATE et ESTD_PHYSICAL_READS, tu fais un joli graphique avec Excel et tu détermines la valeur idéale de ton cache située après le point d'inflexion de ta courbe.

Le Cache hit ratio dépend de l'utilisation de ta base (en OLTP, on fera attention à ce cache hit qui devra avoir des valeurs > 90-95%. Sur un datawarehouse, avoir un cache hit ratio de 70-75% n'est pas déconnant !)

Ensuite, tu peux toujours aller voir coté attentes. Mais les Buffer busy waits (BBW) ne sont pas spécifique d'un cache trop petit (tu peux avoir des BBW dans un contexte de hot block par exemple).

Laurent