Discussion :

[atporfi]

Bonjour!
Je travaille en ce moment sur une base 9.2.0 production et je suis entraine de lancer des scripts d'informations sur lesdatafiles ei j'ai executé cette requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
select substr(name,1,50), phyrds, phywrts 
from v$datafile df, v$filestat fs 
where df.file# = fs.file# 
order by phyrds

J'ai constaté qu'il ya des datafiles dont phyrdset tres eleve est normal si c non que dois_je faire !

Technicienne Oracle (nouvelle en dba)

[lapincretin]

Salut,

Je ne connais pas trop la vue v$filestat, mais je vais tenter de donner mon avis.

Je déduis que phyrds est le nombre de lecture physique dans les datafiles.
Je ne sais pas non plus si on peut juger de l'intensité de la lecture ... Cela dépend depuis combien de temps la base est ouverte, et surtout comment peut on comparer cet indicateur ? Nous n'avons aucunes références !
Cependant, afin de savoir si il n'y a pas trop d'E/S sur ton systeme, tu peux peut etre faire un tour du coté des stats de la SGA et de la PGA ...

Pour la PGA, vérifie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SQL> select * from v$pgastat where name = 'cache hit percentage';

Le but étant de se rapprocher des 100%, sinon essaye d'augmenter la taille de la PGA.

Pour la SGA je ne sais pas trop ... Perso j'utilise des graphs intégré a l'interface java d'entreprise manager 9.

[orafrance]

c'est pas anormal de lire dans les datafiles si tu as beaucoups de données à récupérer. Maintenant il faut surtout voir si le cache est bien utiliser (buffer hit ratio)

[13thFloor]

Jettes plutôt un oeil dans un report récent de statspack pour voir le volume d'IO sur une période (et aussi le top des requêtes en IO, les principales attentes et les types d'accès). C'est plus efficace que de taper directement dans v$filestat qui est une vue cumulative, donc qui va te donner les valeurs depuis le démarrage de l'instance.
C'est tout à fait normal qu'il y ait des physical reads, toutes les données ne peuvent tenir en mémoire et après le startup, les 1ers blocs demandés sont lus à partir des disques.

[atporfi]

Cela fait une semaine que j'observe le phyrds de maes datafiles et je constate que j'ai un datafile dont le nombre phyrds augmente le plus souvent !
Pour la requête que vous avez proposé elle me donne approxima 86,07 %.
Est ce que c necessaire de faire des chgt et c à quel niveau ?datafile ,sga etc....
Merci pour votre aide !

Salut,

Je ne connais pas trop la vue v$filestat, mais je vais tenter de donner mon avis.

Je déduis que phyrds est le nombre de lecture physique dans les datafiles.
Je ne sais pas non plus si on peut juger de l'intensité de la lecture ... Cela dépend depuis combien de temps la base est ouverte, et surtout comment peut on comparer cet indicateur ? Nous n'avons aucunes références !
Cependant, afin de savoir si il n'y a pas trop d'E/S sur ton systeme, tu peux peut etre faire un tour du coté des stats de la SGA et de la PGA ...

Pour la PGA, vérifie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SQL> select * from v$pgastat where name = 'cache hit percentage';

Le but étant de se rapprocher des 100%, sinon essaye d'augmenter la taille de la PGA.

Pour la SGA je ne sais pas trop ... Perso j'utilise des graphs intégré a l'interface java d'entreprise manager 9.

[lapincretin]

Comme tu peux le constater 86% peut etre perfectible, le but étant de mettre en cache mémoire un maximum d'informations.

Tu peux essayer d'augmenter la taille de ta PGA, en fonction de la capacité mémoire maximale de ton serveur ...

Pour plus d'aide il nous faudra plus d'infos :
* RAM embarqué dans le serveur
* Taille actuelle de la PGA
* Version de la base
* Sessions simultanées sur la base

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
select count(*) from v$session;

[orafrance]

Attention, cela doit être amélioré QUE si c'est nécessaire. On peut très bien "taper" sur le disque simplement parce qu'une la requête extrait beaucoup de bloque et que c'est la 1° à passer après le démarrage de la base. Le ratio n'est qu'un indicateur. Pour connaitre les contentions, il n'y a qu'une valeur sur les waits. l'amélioration du ratio ne peut pas être un objectif en soit

[atporfi]

RAM embarqué dans le serveur
8 Go

Pouvez vous m'orienter pour avoir la Taille actuelle de la PGA car je trouve bcp de vues v$ qui m'indique l'information et je ne sais pas laquelle je dois prendre

Version de la base
Oracle9i Enterprise Edition Release 9.2.0.3.0 - 64bit Production

Sessions simultanées sur la base
179

[atporfi]

y-a t- il du nouveau parrapport à ma question ?
merci pour votre aide !

[pifor]

D'après le Performance and Tuning Guide la taille courante de la PGA en 9i est donnée par:

> select * from v$pgastat where name like '%total%alloc%';

NAME VALUE
---------------------------------------------------------------- ----------
UNIT
------------
total PGA allocated 92738560
bytes

[pifor]

Le lien évoqué entre le 'cache hit percentage' de la PGA et les E/S sur un fichier de la base ne peut avoir de sens que si le fichier considéré appartient à un tablespace temporaire: est-ce le cas ?

[atporfi]

Bonjour !
1/ le resultat concernant la PGA est de total PGA allocated 368663552 bytes
2/Je n'ai pas bien saisi votre question est ce que vous pouvez la reformuler ?
sinon les E/S que je vérifie souvent c par rapport à tout les datafiles

Merci pour votre collaboration!

[Pomalaix]

Le lien évoqué entre le 'cache hit percentage' de la PGA et les E/S sur un fichier de la base ne peut avoir de sens que si le fichier considéré appartient à un tablespace temporaire: est-ce le cas ?

Bonjour

Je vous trouve bien charitable de formuler cette remarque avec autant de tact !
Le "conseil" donné sur V$PGASTAT n'a tout bonnement ni queue ni tête vis à vis de la question posée.

Et oui, il est courant et généralement normal que certains fichiers subissent plus d'entrées/sorties que d'autres.
Cela reflète notamment le fait que certaines tables sont davantage sollicitées que d'autres. Ca, c'est un fait applicatif et on n'y peut rien.
En revanche, les lectures peuvent être réellement excessives ou trop longues, et ce pour diverses raisons :
- mauvaise répartition des fichiers sur les disques physiques
- mauvaise indexation
- composants de la SGA (DB_CACHE_SIZE) sous-dimensionnés, ce qui conduit à des relectures depuis le disque de données qui n'ont pas pu persister en mémoire
- etc.

Pour identifier le problème, on peut partir d'un rapport statspack et se pencher sur les requêtes les plus gourmandes en entrées/sorties.
Faut-il le préciser, ce n'est pas quelque chose de simple à faire pour un débutant !

[atporfi]

Je confirme que l'une des raisons que vous avez cités est vérifiée concernant
les lectures excessives ou trop longues est c le fait que
-Nos fichiers tous les datafiles *.dbf se trouvent sur un même disque physique

Et même je peux vous dire que l'installation de toute l'application 11.5.9 +database est sur un le m^me disque ce qui n'est pas dutout idéal et conseillé je pense !

Si vous avez une remarque à faire (vu votre experience) ,elle sera sûrement bénéfique !
Merci pour votre aide !

[orafrance]

en effet, faudrait au moins mettre forms et l'APPL_TOP à part

[atporfi]

Je vous remercie pour vos réponses trés instructives et nous y pensenrons pour une éventuelle réorganisation de notre application et base de donnée car je crois dans les prochaines fois nous aurons énormément de surprises concernant les accés disques (lectures/ecritures)!

Merci bien

[orafrance]

Pour bouger l'APPL_TOP et l'appli c'est très simple grâce à l'auto-config

[atporfi]

Bonjour !
Encore une bonne information avez vous une note ou un document qui parle de l'autoconfig ,j'ai déjà travaillé avec mais pour un clonage de prod vers test ,je ne sais pas si c le même principe ?
Merci pour votre aide !

[orafrance]

non, mais dans Metalink il y a une note très précise sur le clonage