ésolu )Voilà mon pb :
J'ai une requête pour un curseur qui au départ fonctionne très bien. Même si elle est assez longue ( jusqu'à une demi-heure avant le résultat ), elle fonctionne.
Sauf que lorsque je la fait executer plusieurs fois de suite ( en fait, en changeant un paramètres à chaque fois, mais ça ne change rien au volume à récupérer ), elle finit par rester bloquer ad vitam eternam et je n'ai jamais mon résultat !
Obligé de killer la session au bout 20heures au dernier essai ...  
y aurai t'il un vieux DBA de la première guerre qui aurai déjà eu ce type de pb, ou qqun qui aurai des pistes ?

Tu pourrais balancer ton code, steuplé

[#0ef000]

Ben j'ai rien contre, mais ça m'etonnerai que ça aide bcp, etant donné que la requete ne peut être faite autrement ( pour multiple raison, dont la principale est qu'elle est créé par un ETL ( Genio si tu connais )). Mais, bon, la voici !
[SELECT TO_NUMBER(TO_CHAR(G_T2.DATE_ACTION,'YYYY') , DECODE (TO_NUMBER( TO_CHAR(G_T2.DATE_ACTION, 'MM')  , 1  , 1   , 2  , 1   , 3  , 1   , 4  , 2   , 5  , 2   , 6  , 2   , 7  , 3   , 8  , 3   , 9  , 3   , 4  ) ,  
G_T4.COD_RESEAU_THEORIQUE, G_T4.COD_RESEAU_REEL, G_T3.CIBLE_POSITIONNE, G_T2.COD_REGION, G_T2.COD_CAT_SECTEUR,  
G_T2.COD_SECTEUR, G_T4.FLG_HOP_VILLE, G_T6.COD_SPE_DSA, G_T2.COD_ZONE, G_T1.IND_LIEU_EXO,  
COUNT(DISTINCT G_T1.CODE_MÉDECIN_COMPLET)  FROM INFOCLI.TBACM_DW_PROSPECTS G_T1 ,  
INFOCLI.TBACM_ACTIONS G_T2 , INFOCLI.TBSMV_CIBLES G_T3 , INFOCLI.TBSMV_RESEAU G_T4 , INFOCLI.TBACM_CIBLES G_T5 ,  
INFOCLI.TBSMV_SPECIALITE G_T6 WHERE G_T3.NUM_CIBLE = G_T5.NUM_CIBLE  AND G_T3.MAT_SOCIETE = G_T5.MAT_SOCIETE  
AND G_T3.VAL_CIBLE = G_T5.VAL_CIBLE  AND G_T2.TYPNUMIN = G_T5.TYPNUMIN  AND G_T4.COD_CAT_SECTEUR = G_T2.COD_CAT_SECTEUR  
AND G_T4.NUM_SECTO = G_T2.NUM_SECTO  AND G_T4.COD_RESEAU_REEL = G_T3.COD_RESEAU_REEL  AND G_T6.COD_SPECIALITE = G_T1.COD_SPECIALITE  
AND G_T1.CODE_MÉDECIN_COMPLET = G_T2.TYPNUMIN  AND G_T4.FLG_TRAITER = 1   AND G_T2.TYP_ID = 10440    AND G_T1.FLG_ADR_PRINC = 'O'  
AND G_T4.COD_RESEAU_REEL = :1  
GROUP BY TO_NUMBER(TO_CHAR(G_T2.DATE_ACTION,'YYYY')  ,  
DECODE (TO_NUMBER( TO_CHAR(G_T2.DATE_ACTION, 'MM')  , 1  , 1, 2  , 1   , 3  , 1   , 4  , 2   , 5  , 2   , 6  , 2   , 7  , 3   , 8  , 3   , 9  , 3   , 4  )  , G_T4.COD_RESEAU_THEORIQUE , G_T4.COD_RESEAU_REEL , G_T3.CIBLE_POSITIONNE , G_T2.COD_REGION , G_T2.COD_CAT_SECTEUR , G_T2.COD_SECTEUR , G_T4.FLG_HOP_VILLE  
, G_T6.COD_SPE_DSA , G_T2.COD_ZONE , G_T1.IND_LIEU_EXO]
 
Evidement, c'est carement illisible, surtout quand on connait pas le contexte ...
Mais je peux t'assurer que tous les index sont bons, bien présent et utilisés ( je peux te fournir l'explain plan ).

Déjà faudrait voir si le process s'arrête ou s'il tourne dans le vide.
Sur Oracle, je sais pas si y'a un outil de suivi comme le générateur de profils de SQL Server.
En tout cas, avec ce genre d'outil tu peut débugguer l'éxécution du SGBD et voir ou est précisément le problème.

Ouais, j'ai vérifié, et la requête tourne toujours ...
J'ai l'impression qu'il s'agit d'un pb avec le passage de variable ou qq chose dans le genre.

Bon ben finalement, suite à un ajout de rollback segment et augmentation du Temp segment, c'est passé.
Dingue.
Manifestement, ca arrive quand le temp segment est trop petit ( mais il m'a toujours semblé que dans ce cas tu reçois une erreur Oracle ).
 

Truc qui n'a rien à voir : J'adore les "TO_NUMBER(TO_CHAR())" obligatoires après des merdes dans la base faites avec des ALTER sans vérification