Discussion :

[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]

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