Explication sur un tkprof
Bonjour à tous...
J'ai deux traitements identiques qui tournent sur deux machines UNIX identiques => OK =>:lol:
les deux instances ont été reorganisées => :lol:
Le select consommateur des deux traitements utilisent un Hint /*+ OREDERD */ pour déterminer l'ordre des tables à accéder => OK => :mouarf:
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 :
Citation:
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 :
Citation:
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 ?
