Mon Buffer cache hit ratio est en dent de scie !

[PandaConstantin01]

Bonjour tout le monde !
J'ai un problème avec la performance de ma base de données ( sous Oracle 9i).
J'ai fait un calcul du hit ratio qui varie en fonction du temps. D'un moment à l'autre ça bascule de 95% à 70%. Or la bonne donnée doit être > 80% .
Des valeurs de paramètres pour information :

db_block_size = 8M
db_cache_size = 464 M

Pour toute autre information susceptible d'aider pour m'aider je suis en veille .
Merci

[laurentschneider]

Envoyé par PandaConstantin01

Bonjour tout le monde !
J'ai un problème avec la performance de ma base de données ( sous Oracle 9i).
J'ai fait un calcul du hit ratio qui varie en fonction du temps. D'un moment à l'autre ça bascule de 95% à 70%. Or la bonne donnée doit être > 80% .
Des valeurs de paramètres pour information :

db_block_size = 8M
db_cache_size = 464 M

Pour toute autre information susceptible d'aider pour m'aider je suis en veille .
Merci

alors tout d'abord heureusement que ton ratio varie en fonction du temps. Sinon cela voudrait dire qu'il ne se passe vraiment rien sur ta base.

Rien ne dit qu'un ratio de 70% est mauvais

Mais c'est vrai qu'un cache de 464M, c'est bien pour gérer ta collection de timbre, non?

PS: cependant, il est bon d'identifier les commandes sql qui avaient généré plus d'accès disque et de comprendre pourquoi avant d'agrandir le cache.

[orafrance]

que donne le top 5 des events de la base... t'aurais pas du scattered read à gogo par hasard ?

[louping]

Regarde si tu n'aurais pas des select count(*) ou select * dans les top10 et tu auras surement ton explication.

[orafrance]

et pourquoi donc ?

[louping]

Je n'ai pas d'explication, c'est mon expérience qui parle, j'ai remarqué que des select * et select count(*) font des scans de tables complètes, là c'est normal et je suppose qu'Oracle n'utilise pas la même méthode à chaque fois, de plus il monte la table en mémoire, (ou le contenu du select *) et cela hache les Hit des Buffer Cache et Lib cache

[laurentschneider]

c'est vrai que si tu fais beaucoup de select * from t sans condition, alors les données seront directement lues sur le disques, car les full-table-scans ne sont généralement pas en cache. Cela ne veut pas encore dire qu'il y a un problème...

[orafrance]

en effet et c'est pas le SELECT qui pose problème dans ces cas mais le WHERE et les indexes

[laurentschneider]

Un SELECT * FROM T est peut-être exactement ce que l'utilisateur désire. Si je veux la liste de tous mes clients, alors je fais un SELECT * FROM CLIENT, ce n'est pas un "problème".

Il faut d'abord identifier la ou les requêtes qui générent beaucoup d'accès disque, et ensuite seulement on peut se poser la question de savoir si c'est bien ou mal

[orafrance]

oui mais dans ce cas tu peux keeper la table parce qu'il y a des chances que tu sois pas le seul à vouloir le faire

Et là on parle de régler les "problèmes" de cache, donc si l'appli fait que du FTS y'a pas de solution

ce que je voulais dire, c'est que c'est pas les SELECT * ou SELECT count(*) qu'il faut chercher mais les FULL SCAN grace à statspack

[laurentschneider]

Envoyé par orafrance

Et là on parle de régler les "problèmes" de cache

Les problèmes de cache ou le cache hit ratio qui fluctue ?

Peut-être que le ratio descent la nuit lorsque certains gros batch tournent. Ce qui ne veut pas dire qu'il y a un "problème".

Vouloir tuner la base en fonction des ratios n'est pas ma méthode priviligiée

[orafrance]

on dit la même chose