Discussion :

[genio]

Re-bonjour... (Oracle 9i sur windows 2000)
Nous avons un petit problème sur une de nos instance de recette (très petite en taille et en données)... en effet, un traitement effectue des millions d'entrées/sorties et dure 7 heures (Je pense qu'il y a un problème applicatif sur le traitement !) mais ma question est la suivante :
1°) Quand je vois ça :

CONSISTENT_GETS : 81 936 142
BLOCK GETS : 12 072 454
PHYSICAL_READS : 14 208 625
HIT RATIO : 84,89

1°) Je ne comprends pas ce que veut dire 'Hit ratio' et 'Consistents gets'... quelqu'un peut-il m'expliquer !

Sur le même traitement, j'ai les locks suivants:

Lock mode= Row-S (SS) TABLE1 lock id =65 477
Lock mode= Row-S (SS) TABLE2 lock id =65 481
Lock mode= Row-S (SS) TABLE3 lock id =65 489
Lock mode= Row-X (SX) TABLE4 lock id =65 680
Lock mode= Row-X (SX) TABLE5 lock id =65 700
Lock mode= Row-X (SX) TABLE6 lock id =65 550

(Tous les locks_request_types sont à 'none' et il n'y a pas de Blocking_locks !)
En même temps... dans le même scripts ... cela ne me semble pas très sain...
2°) Que veux dire les row-S (SS) et row-X (SX) ?
3°) Ne trouvez-vous pas bizarre que toutes ces tables soient lockées ?

Merci pour vos réponses !

PS : je tiens à préciser que les Shared_pool_size, large_pool_size , sort_area_size et sort_area_retained_size sont bien taillées (comme la prod !)

[pifor]

Hit-ratio: mesure le taux d'utilisation du cache: le pourcentage d'opérations qui ont pu utilisé le cache sans faire d'entrée/sortie.

Consistent gets: c'est le nombre de lectures total effectuées par toutes les requêtes.

row-S (SS)= verrou partagé sur une ligne d'une table
row-X (SX) = verrou exclusif sur une ligne d'une table

Je ne pense pas que ces données signifient que les tables soient "lockées" mais que des lignes de tables sont verrouillées. D'où viennent ces données ? Oracle ne verrouille en général pas les tables sauf cas particulier.

81 000 000 de lectures c'est gros: quelle est la taille de la base et la tailles de vos tables ?

[genio]

Merci pour votre réponses...

1°) Donc quand j'ai un Hit ratio à 84,89, cela veut dire que le cache est utilisé à 95 % ... donc c'est bon ?

2°) Quelle différence faites-vous entre des tables 'verouillées' et 'lockées' (Le verrouillage c'est sur la ligne et la lock sur la table ? )

Ma base est petite, c'est à dire qu'elle contient une cinquantaine de tables dont 1 à 90 000 rows
3 entre 20 et 30 000 rows
6 entre 7 000 et 19 000 rows
7 entre 1000 et 2000 rows
Le reste entre 1 et 500 rows !

[pifor]

1. Le hit ratio est à 85%. Il est assez bon.

2. C'est la même chose. C'est juste une question de vocabulaire

Votre base est très petite par rapport aux volumes d'E/S et au temps
d'exécution. A priori, il y a un très gros problème de performance
à moins que votre serveur est un très très très vieux serveur ?
Mais il faudrait aussi en savoir plus sur ce que font les programmes qui tournent.

[genio]

Le serveur n'est pas mis en cause car ils est neuf, et je n'en sais pas plus sur les jobs qui tournent, sauf qu'en prod, ça passe très bien !

Vous me dites :

row-S (SS)= verrou partagé sur une ligne d'une table
row-X (SX) = verrou exclusif sur une ligne d'une table

1°) Mais un verrou partagé sur plusieurs tables n'est pas un verrou, non ?

Quand à ce problème de perf, nous sommes dessus depuis 2 jours, car les explains n'ont pas décelé de grosses aberrations... De plus, la recette étant une copie de la prod, on n'arrive pas à voir ce qui cloche !

Voilà !

[pifor]

Un verrou partagé sur une ligne ou une table ne signifie pas q'il concerne plusieurs lignes ou plusieurs tables mais que d'autres transactions peuvent poser le même type de verrou sur le même objet.
C'est dans ce sens qu'il est partagé: chaque transaction possède ses propres verrous.

[genio]

Donc quand j'ai :

Lock mode= Row-S (SS) TABLE1 lock id =65 477

1°) Cela veut-il dire que TABLE1 est verouillée par plusieurs transactions ? 2°) Et si c'est la cas, Transaction2 est-elle en attente du déverouillage de Transaction1 pour verrouiller à son tour...
2°) Le chffre 65 477 représente-t-il le nombre de verrous sur la table ?


Merci encore pour votre patience !

[pifor]

1)Je ne pense pas: il s'agit d'un verrou sur une ligne dans une table et non sur la table en elle même.
2) Une transaction n'est en attente sur une autre que si elle demande un verrou incompatible avec celui détenu par une autre transaction sur la même ressource, dans notre cas, la ligne d'une table.
Dans votre cas, 65 477 représente probablement un identifiant interne (lock-id) de verrou plutôt qu'un nombre.

[pifor]

Pour vos problèmes de performances, je vous suggère de comparer votre base de production et votre base de recette:
- même type de machine
- paramètres du init.ora
- gestion d'espace des tablespaces et des objets
- schéma: tables, index, volumes des tables
- les statistiques sont elles à jour sur la base de recette ?
- les traitements sont-ils les mêmes ?
- comparer les plans d'exécutions des grosses requêtes

Si vous avez plusieurs dizaines de millions d'E/S avec des "petites" tables,
les premiers suspects sont les index, les statistiques et les plans d'exécutions.

[genio]

Merci Pifor pour vos réponses...
- Les stats sont bonnes (je les effectue après chaque Import !)
- Le init.ora et les machines qui sont identiques...
ça, je l'avais vérifié avant (ben oui hein, je passe de 'minuscule' scarabée à 'très petit' scarabée !) ...
J'ai remarqué aussi une chose... mon scripts est presque toujours en status 'INACTIF'... c'est bizarre non ?
En téléphonant à l'éditeur du logiciel, il m'a dit de retirer la valeur DISPACHER 'Protocol=TCP' du init.ora (ainsi que d'augmenter la valeur d'open_cursor et de processes... ça OK !)... et effectivement, le script à l'air de passer la plupart de son temps avec le status 'ACTIVE'...
1°) Pouvez-vous me dire ce qu'apporte le mode DISPACHER du init.ora(en fait j'ai pas très bien compris sur la doc !)

Merci encore pour vostre réponse !

[pifor]

Le paramètre DISPATCHER signifie que la base de données fonctionne en mode serveur partagé: plusieurs clients vont se connecter à un même processus serveur dit partagé par opposition au mode serveur dédié où chaque client a son processus serveur dit dédié (pour Oracle, le mode serveur dédié est le mode par défaut).

Fonctionner en mode serveur partagé est surtout intéressant lorsqu'on beaucoup (>150) de connections simultanées sur la base pour réduire le nombre de processus serveurs Oracle.

Pour lancer des gros traitements batchs, cela n'a sans doute pas d'intérêt car le batch est souvent sérialisé: 1 seule connection à la base à la fois.

Je suis curieux de savoir si votre traitement sera nettement plus rapide car cela ne changera ni le nombre de lectures dans le cache ni le nombre d'E/S qui doivent être la cause principale de vos problèmes de performances.

[genio]

Je ne sais pas si c'est + rapide mais je constate que mon traitement qui passait 90 % de son temps en status 'INACTIVE' est passé de l'autre côté de la force et passe maintenat à 90 % de son temps 'ACTIVE'...

1°) D'après vous, le fait maintenant que le process passe + de 90 % de son temps en status ACTIVE, est-il lié à notre DSPACHER (Je vous rappelle qu'entre les deux j'ai modifié l'init.ora : augmentation de open_cursos, du process et finito le dispacher)... ...

Vous dites :

Fonctionner en mode serveur partagé est surtout intéressant lorsqu'on beaucoup (>150) de connections simultanées sur la base pour réduire le nombre de processus serveurs Oracle.

1°) Est-ce parce qu'en mode partagé, les process qui se connectent à l'instance, s'auto-détruisent (on croirait 'Mission impossible') après utilisation...

2°) Où est-ce qu'en mode partagé, le nombre maxi de process est immuable, et les process qui arrivent après le nombre défini, sont mis en attente...

3°) Est-ce que ça veut dire aussi que les process en mode dédiés, naissent avec la première connexion utilisateur de la journée et restent indéfiniment accrochés à l'instance, jusqu'à ce que l'on arrête la base où que l'utilisateur se déconnecte ?

4°) Est-ce que j'ai rien comris et qu'il faut que j'enfile la camisole ?

Merci encore

PS : Je vous ferai part, bien sûr, des nouveaux résultats !

[pifor]

1)° je ne sais pas
ACTIVE= exécution SQL en cours
INACTIVE = pas d'exécution SQL en cours

1)° en mode partagé, les processus ne s'auto-détruisent pas
2)° oui ou peut-être échec de connexion
3) oui, les processus dédiés naissent à la première connexion et disparaissent à la déconnexion de l'utilisateur
4°) non, attendez au moins les résultats

[genio]

Merci pour tout...
en fait, je crois de + en plus à un problème de logique de programmation... En effet, le script que j'ai lancé hier, tourne encore, et arbore fièrement ses 850 millions de lectures pour .... 8000 écritures !
Pas mal le truc hein ?

Et j'ai remarqué aussi qu'il y a un SELECT appelé des millions de fois, qui ne ramène pas de ligne !

Le problème je pense, vient de chez eux... d'ailleurs, j'ai envoyé le dump de notre base de recette !

Voilà... à bientôt pour la suite de l'aventure !