Discussion :

[had69]

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 :

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

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.

[orafrance]

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

[had69]

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 :

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

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.

[orafrance]

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 ?

[had69]

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

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

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.

[had69]

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

[Jaouad]

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 ?

[had69]

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

[Jaouad]

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