Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je travaille avec un moteur 9.3.2 sous Cent-OS 6.5.
J'ai des procédures stockées qui renvoie des curseurs.
J'avais paramétré LOG_MIN_DURATION_STATEMENT à 0 pour tracer les durées de toutes les instructions. Ainsi je voyais :
2015-12-03 07:34:39 CET [28722]: [3331-1] user=toto 127.0.0.1 2015-12-02 10:39:53 CET LOG: duration: 25.174 ms statement: select monschema.maprocedure('FR', 'LENS', '40054',30) as data
2015-12-03 07:34:39 CET [28722]: [3332-1] user=toto 127.0.0.1 2015-12-02 10:39:53 CET LOG: duration: 162.360 ms statement: fetch all in "<unnamed portal 959>"
J'ai aujourd'hui, paramétré LOG_MIN_DURATION_STATEMENT à 100, pour réduire le volume des traces.
Problème, je ne vois plus les appels aux procédures stockées, mais uniquement la durée "du retour du curseur" s'il est supérieur à 100ms :
2015-12-04 10:30:20 CET [26419]: [18068-1] user=toto 127.0.0.1 2015-11-29 06:33:12 CET LOG: duration: 366.774 ms statement: fetch all in "<unnamed portal 5359>"
De ce fait, je ne sais plus quel appel à quelle procédure stockée est "long".
Y-a-t'il un moyen de retrouver cette information sans réactiver la trace de toutes les instructions ?
D'avance merci.
Hors ligne
Non, il faut réactiver la trace de toutes les requêtes.
Guillaume.
Hors ligne
Bonjour Guillaume,
J'avais pensé mettre LOG_MIN_MESSAGE à NOTICE et mettre un RAISE NOTICE 'select monschema.maprocedure(%,%,%,%)',$1,$2,$3,$4; avant le RETURN de mes procédures stockées.
C'est une petite "bidouille" mais pourquoi pas ?
Hors ligne
J'ai tendance à préférer utiliser auto_explain dans ce genre de contexte… ça permet non seulement de tracer la fonction, mais surtout la sous-requête qui merdoie dedans… et les paramètres. (positionner auto_explain.log_min_duration, log_nested_statements).
Marc.
Hors ligne
Pages : 1
