Discussion :

[mainecoon]

J'exécute une procédure stockée, et ma PS tourne en rond... Je vois par contre deux autres sessions sous mon identifiant :

Avec comme current statement :

/* Formatted on 2007/02/12 17:05 (Formatter Plus v4.8.5) */
DECLARE
program DBMS_DEBUG.program_info;
BEGIN
program.namespace := :namespace;
program.NAME := :NAME;
program.owner := :owner;
program.dblink := :dblink;
program.libunittype := :libunittype;
program.entrypointname := :entrypointname;
:retval :=
DBMS_DEBUG.get_line_map (program,
:maxline,
:numentrypts,
:linemap
);
END;

Et

/* Formatted on 2007/02/12 17:05 (Formatter Plus v4.8.5) */
DECLARE
program DBMS_DEBUG.program_info;
BEGIN
program.namespace := :namespace;
program.NAME := :NAME;
program.owner := :owner;
program.dblink := :dblink;
program.libunittype := :libunittype;
program.entrypointname := :entrypointname;
:retval :=
DBMS_DEBUG.get_line_map (program,
:maxline,
:numentrypts,
:linemap
);
END;

C'est quoi ça ?

C'est fou, j'arrive à lancer ma requête SQL à la main, mais quand je lance la PS qui contient la requête, ça semble ne rien faire...

[mainecoon]

J'ai remarqué qu'en modifiant la procédure stockée, en remplaçant les binds variables, par des valeurs arbitraires en dure, ça fonctionne !!!

Je ne comprends pas là...

J'ai d'autres PS qui ressemble à celle-ci et ça marche...

[orafrance]

tu serais pas sous PL/SQL par hasard ? T'es session reste active ? C'est quoi le wait dans v$session_wait ?

[Yorglaa]

tu ne serais pas par hasard sous TOAD et en train d'effectuer un debug "en live" de ta procédure ?

dans ce cas Toad communique avec des sessions séparées pour pouvoir te fournir les valeurs des variables et autres infos pendant que ta procédure est suspendue (mode pas-à-pas)...

j'imagine que les autres logiciels de développement qui proposent ce mode de débug fontionnent de manière similaire.

[mainecoon]

Bonjour,

je travaille avec Toad (version 8 je crois) et des procédures stockées PL/SQL dans Oracle 9iR2.
(En prod, j'attaque avec une application .NET (FWK 1.1) avec la classe OracleClient.)

Le problème c'est que je n'ai pas lancé de Debug...

Par contre, avant de quitter le boulot, j'ai remarqué quelque chose.

Si je mets des valeurs en dur dans la requête SQL INSERT de la procédure (plus aucun intérêt pour la procédure, mais c'est juste pour le test !), ça marche, et en plus j'ai remarqué qu'il ne construit pas le même plan d'exécution !
Pour info, ma requête récupère les données d'une vue basée sur deux tables en UNION ALL.

Valeurs en dure : il fait un FULL TABLE SCAN des deux tables, et là dans Toad, je vois bien la barre de progression évoluer dans l'onglet LONG OPERATION.

Par contre en laissant des variables ou binds variables en passant par un EXECUTE IMMEDIATE (je pensais que ça venait de là, mais non), il me change le plan d'exécution et utilise un INDEX (sur la date), et là plus de barre de progression, et ça ne bouge pas (ou alors faut attendre longtemps ?? Mais ça dépasse le temps normal du test avec les valeurs en dur).

J'ai essayé de forcer le FULL TABLE SCAN en ajoutant le HINT FULL TABLE dans ma requête INSERT en pointant sur la vue. Et là, j'ai eu les barres de progression ! Mais faut que je vois ce matin, car je n'ai pas pu rester pour voir la fin.
Ah oui, ma requête est un INSERT qui fait un agrégat sur toute une période par exemple sur 6 MOIS, donc faut bien qu'il fasse un FULL TABLE, non ? Car je ne recherche pas des valeurs précises de dates.

Pour le v$session_wait, je regarderai ce matin si ça le fait encore.
Sinon à quoi correspond ce paramètre ?

Merci pour votre aide.

[mainecoon]

Voici précisément le hint utilisé : FULL(ma vue)

Ce qui donne :

SELECT /*+ FULL(PSCM.VPAMPVENTES) */ a.champ1, a.champ2 ...

Ainsi, il évite de se taper toutes les lignes de l'index sur_date et parcourt directement les tables, vu que 50% des enregistrements correspondent aux critères (sur une période de 12 mois glissants - sur 24 mois de la vue).
Par contre, j'avais un gros doute sur son emplacement vu (sans jeux de mots ) qu'il s'agit d'une vue basée sur deux tables.

Deux choix :
1°/ Je le place dans ma requête qui appelle la vue (ce que j'ai fais).
2°/ Je place deux fois le hint pour chaque table constituant la vue directement dans le script de création de la vue. Mais problème, car parfois, je peux utiliser cette vue pour chercher une date (enfin, je pense, mais dans le doute...), alors si je fais un FULL pour chercher une ligne...


Je ne pensais pas que le 1°/ marchait, mais on dirait que oui... Je viens de réessayer, et ça semble bien marcher... Après pourquoi Oracle passe par un FULL TABLE quand je lançe directement la requête et par les index sur date quand j'utilise des paramètres ou bind variables, je ne sais pas !