Explication sur un tkprof [Fait]

[genio]

Bonjour à tous...
J'ai deux traitements identiques qui tournent sur deux machines UNIX identiques => OK =>
les deux instances ont été reorganisées =>
Le select consommateur des deux traitements utilisent un Hint /*+ OREDERD */ pour déterminer l'ordre des tables à accéder => OK =>

Cependant, un des traitement dure 2 minutes et l'autre 5 heures alors que les chemins d'accès sont identiques (grâce au /* ORDERER */) ...
J'ai fait un tkprof et sur la machine qui fonctionne et voici ce qu'il donne :

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- -------
Parse 1 100.00 57.48 0 0 0 0
Execute 1 400.00 489.66 0 0 0 0
Fetch 1 4200.00 7508.17 3095 3160 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ------
total 3 4700.00 8055.31 3095 3160 0 0

Sur celle qui ne fonctionne pas voici ce que ça donne :

call count cpu elapsed disk query rows
------- ------ -------- ---------- ---------- ---------- ---------
Parse 1 0.00 47.69 0 0 0
Execute 1 400.00 396.01 0 0 0
Fetch 49323 8069608 5800623.82 219544 1873787 49323
------- ------ -------- --------- ---------- ---------- ---------
total 49325 8070008 5801067.52 219544 1873787 49323

1°) Pourquoi le 'parse' est-il de 1 et la 'cpu' de 100, dans la machine qui fonctionne et de 1 et zéro sur celle qui ne fonctionne pas ?
2°) Le nombre de fetch est impressionnant sur la machine qui ne fonctionne pas ... cela peut-il être dù à ce que les datas de cette machine ne sont pas lues en mémoire ? et si oui, pourquoi ? serait-ce un paramètre d'initialisation qui serait défaillant... ou une zone mémoire trop petite par rapport à la quantité selectée ?
Merci pour vos réponses

PS : J'ai oublié de vopus dire que la database qui ne fonctionne pas ciontient 52 000 000 de lignes et celle qui fonctionne 26 000 000 de lignes... soit deux fois moins... Faut-il retailler les zones mémoires ?

[pifor]

Si le contenu des tables est différent, la même requête ne retourne pas forcément le même résultat et les comparaisons sont difficiles

Le fetch correspond à la récupération par le client d'une partie du résultat d'un SELECT. La paramètrage de l'API utilisée coté client peut expliquer des différences: c'est le mécanisme de l'array fetch qui permet de grouper des envois de résultats.

Précisez la version d'Oracle coté client et coté serveur.

[genio]

Merci Pifor pour votre réponse...
Côté seveur 9.2.0.5.0
Côté client 9.2.0.1.0
Mais les applis sont exécutées à partir d'Oraclle Appli 11i...
J'ai une question : Pourquoi le paramétrage de l'

[genio]

Merci Pifor pour votre réponse...
Côté seveur 9.2.0.5.0
Côté client 9.2.0.1.0
Mais les applis sont exécutées à partir d'Oraclle Appli 11i...
J'ai quelques questions
1°) Je ne vois pas pourquoi le paramétrage de l'appli côté client pourrait jouer sur les performances car le 'select' est exécuté sur le serveur... là, j'avoue ne pas comprendre !
Moi je voyais plutôt un problème de mémoire...

2°) Pouvez-vous en 2 mots m'expliquer l'array fetch ?

3°) Pouvez-vous m'expliquer :
Parse count=1 et cpu=100.00 sur la machine qui fonctionne
Parse count=1 et cpu=000.00 sur celle qui ne 'fonctionne' pas ?

merci encore pour vos réponses...

[ZashOne]

Salut

1 - Tes stats sont elle correctement calculees sur les deux machines et de la meme maniere via DBMS_STATS?

2 - Si tu veux de l aide ici il faut aue tu poste la requette , l explain plan et le schema des tables sinon c est un peu flou

3 - Pour avoir plus d informations tu devrai creer un rapport statspack sur les deux machines et les compares.

4 - pour ton parse a 0 / 100 . JE dirai en premier hypothese que vu l absence de bonne stat sur la base qui ne fonctionne pas , aucun temps de calcul de l explain plan n est necessaire donc le temps est a 0.....

[genio]

Bonjour...
Le stats des deux bases sont identiques car, nous avons effectué une campagne de mise en place des mêmes stats sur toutes les caisses...
Nous avons réorganisé les index sur la plus grosse table (50 000 000 de lignes !) mais cela n'a rien changé...
Je dois dire aussi que les volumétries entre les deux caisses ne sont pas les mêmes mais que les stats sont identiques (voir début de mon post)
En fait, dans la caisse qui fonctionne, le 'parse' est effectué, il prends 100 de cpu et 57.48 d'elapsed... sur celle qui ne fonctionne pas, le 'parse' est aussi à 1, mais la cpu est à zéro et (et c'est encore une question que je me pose) l'elapsed' est à 47.69...
Comment se fait-il que la cpu du parse soit à 0.00 et l'elapsed à 47.69 ?
Est-ce parce qu'Oracle ne trouve pas de qoi parser mais cherche quand même une solution ?

Merci pour vos réponses...

[genio]

J'ai aussi une autre question : Pourquoi, dans ma caisse qui ne fonctionnne pas quand j'effectue le tkprof avec 'explain=user/mot de passe', je n'ai pas les chemins d'accès ?

Merci pour vos réponses...

[genio]

J'ai trouvé quelque chose :
Sur la caisse qui fonctionne le Tkprof affiche bien les chemins d'accès =>
Sur celle qui ne fonctionne pas, le tkprof ne me les affiche pas et me rend un code retour :

ORA-00932: inconsistent datatypes: expected NUMBER got DATE

sur le select le + consommateur... et me sort un message :

parse error offset: 2268

Alors que, je vous rappelle, les deux caisses sont identiques...

1°) Je pense que le fait de ne pas afficher les chemins d'accès, sur le tkprof, (dans la caisse qui ne fonctionne pas) doit implique que le 'parse' ne fonctionne pas et que la caisse se traine lamentablement...
1°) Aurais-je un début d'explication ?

2°) Que faut-il rajouter pour que mon ORA-00932 n'apparaisse plus ?
Je vous joins en copie les deux tkprof (bon_kprof et mauvais_tkprof)...

Merci pour vos aides...

[ZashOne]

1 est ce que les parametres NLS sont les memes sur les deux serveurs et sur les client qui lance la requete ?

Ton problrmr provient de TRUNC(:b9) qui gere mal la bind variable b9.

TU doit toujours remplacer TRUNC(:b9) par TRUNC( TO_DATE(:b9,'TON FORMAT DE DATE'))

REgarde ici


http://asktom.oracle.com/pls/asktom/f?p=100:11:0:::11_QUESTION_ID:67082879150052

[genio]

Merci pour votre réponse...
j'avais lu sur Internet le pourquoi du comment du code ORA-00932 et merci pour la réécriture de l'ordre...
Il me reste cependant 3 questions :
1°) pensez-vous que mon analyse est exacte : 'puisque le tkprof n'affiche pas les chemins d'accès => pas de parse => pas de calcul de chemin d'accès => performances complètement dans les choux '

2°) Sur OEM, les paramètres nls_date_format (DD-MON-RR), nls-date-langage, nls-language etc... des deux serveurs sont identiques... mais où trouver les paramètres nls du client ?

3°) Quand j'utilise l'explain de toad (sur les deux caisses !), celui-ci ne fonctionne pas et me rends un ora-00932 ... je suis donc obligé, pour que ça fonctionne, et pour les deux caisses, de mettre un -- devant les ordres TRUNC DATE pour que ça marche
Pouvez-vous me dire alors pourquoi, sur tkprof, les chemins d'accès de la caisse qui fonctionne sont bien là... alors que sur sur la caisse qui ne fonctionne pas j'ai un ora-00932 ... bizarre hein ?

[genio]

personne pour répondre à mes 3 dernières questions ?

[ZashOne]

regarde dans les tuto 'Evitez les erreurs de conversion grâce aux NLS' pour tes nls.

pour le reste change ton trunc et ton explain plan sera normalement ien calcule. pourkoi ca marche sur nue machine et pas sur l autre aucune idee.

[pifor]

Envoyé par genio

Merci Pifor pour votre réponse...
Côté seveur 9.2.0.5.0
Côté client 9.2.0.1.0
Mais les applis sont exécutées à partir d'Oraclle Appli 11i...
J'ai quelques questions
1°) Je ne vois pas pourquoi le paramétrage de l'appli côté client pourrait jouer sur les performances car le 'select' est exécuté sur le serveur... là, j'avoue ne pas comprendre !
Moi je voyais plutôt un problème de mémoire...

2°) Pouvez-vous en 2 mots m'expliquer l'array fetch ?

C'est le client qui récupére les données en général avec une instruction de type FETCH ou NEXT qui dépend du langage et de l'API utilisés: ce qui implique des échanges client/serveur. Un nombre élévé de FETCH a aussi un coût de transfert entre le client et le serveur. L'array fetch est le mécanisme qui permet de grouper les FETCH et d'optimiser le nombre d'échanges entre le client et le serveur. Par exemple, SQL*Plus transfère les résultats par groupe de 15 lignes par défaut mais vous pouvez modifier ce comportement et observer ce qui ce passe comme dans cette discussion sur AskTom.