Discussion :

[slefevre01]

bonjour,
je trace les requêtes qui sont reparsées presque systèmatiquement.
Je ne comprends pas car parmis celles-ci je vois des requêtes qui utilisent les binds variables, hors les binds variables sont sensés éviter le reparsing.

c'est une base 8.1.6 sur sun.

voici un exemple de requête.

Code :

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

SELECT WL0.ACCOUNT_NUMBER, WL0.AGREEMENT_NUMBER_1, WL0.AGREEMENT_NUMBER_2, WL0.COUNTRY, WL0.CREATE_TIMESTAMP, WL0.CREATORS_NAME, WL0.CUSTOM_USE_1, WL0.CUSTOM_USE_2, WL0.CUSTOM_USE_3, WL0.EMAIL, WL0.EXIT_DATE, WL0.FACSIMILE_TELEPHON, WL0.FCE_CARD, WL0.IATA, WL0.ID, WL0.LOCA, WL0.L, WL0.MODIFIERS_NAME, WL0.MODIFY_TIMESTAMP, WL0.OU, WL0.NOE_NUMBER, WL0.OID, WL0.ORGANIZATION_TYPE, WL0.PARENT_ID, WL0.PASSENGER_TYPE, WL0.PAYMENT_TYPE, WL0.PCC_NUMBER, WL0.PORTAL_ID, WL0.POSTAL_CODE, WL0.RIVA_QUEUE_NUMBER, WL0.SATURNE_BUSINESS_RBD, WL0.SATURNE_CODE, WL0.SATURNE_ECONOMIC_RBD, WL0.SATURNE_FIRST_RBD, WL0.SATURNE_RBD, WL0.SIRET, WL0.STATUS, WL0.STREET, WL0.TELEPHONE_NUMBER, WL0.TEST_ORGANIZATION, WL0.TKTOID, WL0.TOUR_OP_ID  FROM ORGANIZATION WL0 WHERE ((WL0.PORTAL_ID = :1) AND (WL0.OU = :2))

EXECUTIONS: 4533
FIRST_LOAD_TIME: 2005-08-04/09:26:08
PARSES 3666
DISK_READS 750772
BUFFER_GETS 1800249

Avez-vous des infos ou idées sur la raison de ces reparsing

voici le requete utilisée pour remonter les parses

Code :

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

1
2
3
4
5
SELECT sql_text, parse_calls, executions,users_executing, FIRST_LOAD_TIME
FROM v$sqlarea
WHERE parse_calls > 500
AND executions < 2*parse_calls
order by executions desc;

[Balises ajoutées par Orafrance]

[Jaouad]

Bonjour et bienvenue sur le forum Oracle ,
Avant tout et pour améliorer la visibilité du code merci d'utiliser les balises Codes .

Enfin ,il faut dire que toutes les requêtes sont parsés , car cela fait partie du processus d'une instruction , aprés il faut savoir si c'est du soft parse

Oracle s’aperçoit qu’une requête similaire existe déjà dans la library cache et il applique le parse précèdent

ou un hard parse :

Cette étape convertit l’instruction SQL en plan d’exécution .Elle vérifie également que l’utilisateur bénéficie bel et bien des autorisations appropriées et que les tables , colonnes et autres objets de référence existent .Il a également une vérification syntaxique

Donc un parse est inévitable , à mon avis tu devrais plutôt chercher les hard parses en tracant ta requête deux fois de suite

Pour précision , il y a un nouveau parse lorsque la requête est invalidé : création d'index , nouvelle stat , pas de bind variable ....

Jaouad