Discussion :

[lper]

Bonjour,

j'ai un gros problème sur l'environnement de production que je n'arrive pas à reproduire sur l'environnement de développement, je soupçonne donc un conflit avec d'autres transactions sur la base de données.

Le traitement qui est lancé à travers un script unix en batch (avec la commande at ...) est fortement ralenti lors de la lecture d'un curseur de ce style :

CURSOR CUR_cre_fact (
p_aff_deb AFFILIES.AFF_NAFF%TYPE,
p_aff_fin AFFILIES.AFF_NAFF%TYPE,
p_ANNEE AFF_COMPTA_LPP.COA_ANNE%TYPE,
p_PEIO AFF_COMPTA_LPP.COA_PEIO%TYPE,
p_debut_fact VARCHAR2,
p_type_fac IP_METIER_ID_NUMERO_METIER.TYPE_FACTURATION%TYPE)
IS
SELECT a.uuid_consolide,
a.metier_id,
NVL (b.montant_annuel, 0) montant_annuel,
c.type_facturation,
d.aff_sequ,
d.aff_no,
d.aff_dlrd
FROM table_a a
JOIN table_b b
ON b.parent_send_mont_fact_uuid = a.uuid
JOIN table_c c
ON c.metier_id = a.metier_id
JOIN table_d d.aff_no = c.numero_metier
WHERE a.TRAITE IS NULL
AND d.aff_no BETWEEN p_aff_deb AND p_aff_fin
AND a.module_name = 'IIII'
AND a.type_objet_facturable = 'OBJET_FACT_UB_FACTURATION'
AND b.debut_facturation LIKE p_debut_fact
AND c.type_Facturation = p_type_Fac
GROUP BY a.uuid_consolide,
a.metier_id,
b.montant_annuel,
c.type_facturation,
d.aff_sequ,
d.aff_no,
d.aff_dlrd
ORDER BY d.aff_no

dans une boucle :

FOR row_cre_fact IN cur_cre_fact (p_aff_deb,
p_aff_fin,
p_annee,
p_peio,
v_debut_fact,
p_type_Fac)
LOOP
--traitement d'audit

Le traitement est pratiquement stoppé en début de lecture, j'ai mis un traitement d'audit juste dans le premier passage (lecture du premier record) qui ne se fait pas.

Ce qui est très surprenant, c'est que lorsque :
-> je lance ce batch sur l'environnement développement, le résultat est inférieur à la minute.
-> j'exécute la requête sql du curseur dans TOAD, le résultat est aussi très rapide sur l'environnement de production, je ne vois aucun blocage.
-> je lance l'exécution du package dans TOAD, le résultat est aussi inférieur à la minute sur l'environnement de production !


La méthode pour se connecter à la base oracle depuis le script unix :

sqlplus -S /nolog << _EOF
connect $LOGNAME/$HOT_PH_PASS@$ORACLE_SID;

DECLARE
P_AFF_NAFF_DEB NUMBER;
P_AFF_NAFF_FIN NUMBER;
P_COA_ANNE NUMBER;
P_COA_PEIO NUMBER;
P_DATE_FAC DATE;
P_DATE_ECH DATE;
P_TYPE_FAC VARCHAR2(255);
P_USE_VISA VARCHAR2(200);
P_PRINTER VARCHAR2(30);

BEGIN
P_AFF_NAFF_DEB := TO_NUMBER($P_AFF_NAFF_DEB);
P_AFF_NAFF_FIN := TO_NUMBER($P_AFF_NAFF_FIN);
P_COA_ANNE := TO_NUMBER($P_COA_ANNE);
DB.PCK_MYPACKAGE.P_MA_PROCEDURE ( P_AFF_NAFF_DEB, P_AFF_NAFF_FIN, P_COA_ANNE,..);

END;
/
_EOF

Il m'est impossible de monitorer en production pour l'instant, je ne suis pas le dba (qui est quelque peu occupé en ce moment).
Donc merci d'avance si vous avez quelques pistes pour peut-être configurer le même mode d'exécution entre le batch et le TOAD (transaction, autres?), voire si vous avez d'autres idées.

[vanagreg]

Bonjour,

AWR est-il installé en Prod?
Il faut a minima capturer le plan d'exécution de la requête pendant que le traitement tourne pour voir s'il est correct.

[skuatamad]

Comment est réalisé l'audit ? Insertion dans une table de log via transaction autonome ou affichage via dbms_output ?

Y a-t-il des locks quand le traitement est lent ?
https://asktom.oracle.com/ords/askto...ons-on-locking

Qu'est ce que ça donne de se connecter à sqlplus depuis le serveur où est placé le script, puis d'exécuter le package ?

[lper]

Bonjour,

merci pour vos réponses, je vais encore vérifier le plan d'exécution mais ça n'explique tout de même pas la différence de performance selon les modes d'exécution.

Comme je n'ai pas accès à la prod, ça m'est difficile de tester, je vais quand même trouver une solution avec notre DBA pour prendre un moment pour contrôler le déroulement.

[Michel.Priori]

Bonsoir,

Si je résume :
* le traitement est rapide en interactif
*** sur la DEV
*** sur la PROD
* le traitement est lent lors de sa planification

N'y aurait-il pas conflit avec la fenêtre de maintenance ?