[ORACLE 8.1.7.3] Plus de parse que d'execute ?

Bonjour,

Je suis sous Oracle 8.1.7.3.

Comment interpréter que mon nombre de parse soit plus grand que mon nombre d'execution et de fetch ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

SELECT Dept_rayon.iddepartement_rayon AS iddepartement_rayon , Dept_rayon.Memo_structure AS Memo_structure , Departement.IDdepartement AS IDdepartement , Departement.Departement AS Departement , Rayon.IDRayon AS IDRayon , Rayon.libelle_rayon AS libelle_rayon , Dept_rayon.idholding AS idholding , Dept_rayon.idsociete AS idsociete , Dept_rayon.IDenseigne AS IDenseigne , Dept_rayon.IDEnseigne_departement AS IDEnseigne_departement , Affect_Achet.IDacheteur AS IDacheteur FROM Departement , Dept_rayon , Rayon , Enseigne_depart , Affect_Achet WHERE ( ( ( ( Departement.IDdepartement = Dept_rayon.IDdepartement ) AND ( Rayon.IDRayon = Dept_rayon.IDRayon ) ) AND ( Enseigne_depart.IDEnseigne_departement = Dept_rayon.IDEnseigne_departement ) ) AND ( Affect_Achet.iddepartement_rayon = Dept_rayon.iddepartement_rayon ) )   call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 6 1.72 1.72 6 314 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 6 1.72 1.72 6 314 0 0     SELECT ALL_IND_COLUMNS.INDEX_NAME, ALL_IND_COLUMNS.COLUMN_NAME, ALL_IND_COLUMNS.COLUMN_POSITION, ALL_INDEXES.UNIQUENESS FROM SYS.ALL_IND_COLUMNS,SYS.ALL_INDEXES WHERE ALL_IND_COLUMNS.INDEX_NAME= ALL_INDEXES.INDEX_NAME AND ALL_IND_COLUMNS.INDEX_OWNER=ALL_INDEXES.OWNER AND ALL_IND_COLUMNS.TABLE_OWNER='magali' AND ALL_IND_COLUMNS.TABLE_NAME= 'Magali_service' ORDER BY INDEX_NAME,COLUMN_POSITION DESC     call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 34 0.60 0.61 0 8 0 0 Execute 17 0.00 0.00 0 0 0 0 Fetch 17 0.00 0.00 0 17 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 68 0.60 0.61 0 25 0 0

---

Merci de vos suggestion.

il n'y a pas de ligne donc inutile d'exécuter la récupération des datas et encore moins le fetch... enfin, je ne vois que ça ;)

Il me semblait que la phase de parse est une analyse syntaxique et sémentique de l'ordre SQL.

Comment ORACLE peut-il savoir qu'il n'y a pas de ligne sans au moins faire la phase d'exécution ?

Sinon, j'ai une question subsidiaire : qu'est-ce qui expliquerait que la phase de parse soit très longue alors que ma requête semble simple ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

SELECT IDTransporteur,code_interne,Compta_Code_compta,Code_nationale,nom, adresse,Ville,telephone,numfax,maxi_chargement_poids, maxi_chargement_palette,mini_chargement_poids,mini_chargement_palette, delai_livraison,correspondant_1,mail_correspondant_1,gsm_correspondant_1, tel_correspondant_1,pRenom_correpondant_1,fonction_correspondant_1, jour_enlevement_2,correspondant_2,mail_correspondant_2,gsm_correspondant_2, tel_correspondant_2,prenom_correspondant_2,fonction_correspondant_2, observation,code_postal,idtva,Code_transporteur,IDorigine,jour_enlevement_1, jour_enlevement_3,jour_enlevement_4,jour_enlevement_5,jour_enlevement_6, jour_enlevement_7,ROWIDTOCHAR(ROWID) FROM Transporteur ORDER BY nom     call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 1.09 1.15 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 1 0.00 0.02 1 0 4 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 3 1.09 1.17 1 0 4 0

---

Merci.

si les données sont en cache il ne fait pas le execute si ?

Transporteur n'est pas une vue complexe ? le SELECT ne contient pas de fonction ?

Citation:

---

si les données sont en cache il ne fait pas le execute si ?

---

Je n'en ai aucune idée ...

Citation:

---

Transporteur n'est pas une vue complexe ? le SELECT ne contient pas de fonction ?

---

Transporteur est une table classique. Le SELECT ne contient pas de fonction exceptée la transformation de ROWID vers CHAR.

Quels sont les paramètres ou causes intervenant sur le temps de parsing d'une requête ?

J'ai trouve que mes temps de parsing de façon général sont assez long sur ma base de données.

Merci

Citation:

---

Envoyé par had69

Quels sont les paramètres ou causes intervenant sur le temps de parsing d'une requête ?

---

Deux principalement
Est ce que c'est un Hard Parse ou SOft Parse ?
Est ce que tu as la place dans la library cache ou est ce que tu doit en faire ?

Comment sait-on s'il s'agit d'un hard parse ou soft parse ?

Comment puis-je savoir s'il y avait assez de place dans le library cache ?

Merci

Cette information n'est pas disponible dans la plan , une requête dans la vue v$sql va te permettre de voir si tu effectue à chaque fois un hard parse ou pas ?

Si une requête est soumise à Oracle et que ce dernier s'apercoit que la requête est déja parsé alors dans ce cas là la colonne executions doit être incrémenté

Attention à la colonne invalidations qui peut être symptomatique d'un hard parse récurrent


Jaouad