Qu'est ce qui fait des insert dans ma table!?

**mina** · 28/11/2007, 12h40

Je suis sous oracle 9i avec une application qui s'apelle Génerix, et depuis une semaine il ya je ne sais pas quel truc qui tourne et qui m'insert quelques 40milles lignes...!! je ne comprend plus rien, en plus c'est la table des tarifs et tout le monde en a besoin... et ce truc m'insert des doublons de lignes qui existent déja, donc ça me fait des prix de ventes doublés voir triplé ou plus...

Ma question est : point de vue oracle, comment je pourrait intercepter ce processus qui me fait ça, devrais je mettre en place un trigger? et si oui comment le faire!!!

**orafrance** · 28/11/2007, 13h44

un trigger ou l'audit. Vérifie aussi que tu n'as pas un job qui traine (dba_jobs) ou une tâche dans un scheduler.

**mina** · 28/11/2007, 14h09

Je vais me documenter sur l'audit, car il n'ya rien dans les jobs, et puis pour le scheduler vous parlez de l'application, c'est à dire autre chose qu'oracle, et bien je pense avoir vérifier tout ce qui tourne dans cette machine, mais j'avoue que l'application ne m'est pas très familère donc je ne suis pas sure de moi, c'est pour ça que je voudrai un moyen 'oracle'...
Merci pour votre réponse, je vais creuser l'histoire de l'audit!

**LBO72** · 28/11/2007, 14h11

Comme l'a dit Grand Maître OraFrance

, tu peux passer par un trigger :

1) Tu crées d'abord une table de flicage(une fois pour tout) :

Code :

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

1
2
3
4
5
create table TMP_INSERTS  (
                  NUMBADGE           VARCHAR2(08),
                  DATEMIGRATION      DATE,
                 TERMINAL           VARCHAR2(10),
                 REQUETE            VARCHAR2(500)   );

2) En suite ton trigger:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
CREATE or REPLACE TRIGGER serveillance_table_Generix
   BEFORE INSERT on  Generix    -- ta table à surveiller

   DECLARE
      v_numbadge varchar2 (8);
      v_terminal varchar2(30);  

   BEGIN                   
       select osuser, terminal  into v_numbadge, v_terminal from v$session
                where   status = 'ACTIVE' and type = 'USER';      

      INSERT INTO TMP_INSERTS 
            values ( v_numbadge,
                         sysdate,
                         v_terminal,
                        (ora_sysevent ||' ' || ora_dict_obj_type || ' ' || ora_dict_obj_name) );                             

    EXCEPTION when others then
         v_numbadge := 'XXXXX';                               
END;
/

J'espère que cela répond à ton besoin.

LBO72.

**mina** · 28/11/2007, 14h16

Merci de ta réponse LBO72, je te tiens au courant de la démarche que je vais suivre dès que je me documente un peu sur l'audit!

**mina** · 28/11/2007, 15h38

J'ai voulu me documenter sur l'audit mais ça m'a semblé trop compliqué, alors j'ai opté pour la deuxieme, je vais créer la table et le trigger comme tu me l'as dis LBO72,
Je vous tiendrai au courant!

**mnitu** · 28/11/2007, 17h20

Salut LBO72,

Je sais que c'est un exemple, mais

il faut toujours éviter les inserts non nommé
le bloc d'exception c'est fait un peu trop vite

**mina** · 30/11/2007, 10h31

J'ai crée le trigger et la table ...j'ai re mes doublons dans ma table mais aucune ligne n'est insérée dans la table témoin!!!!!!!!!! je ne sais plus quoi faire!!!

**orafrance** · 30/11/2007, 10h58

quel est le code du trigger

**LBO72** · 30/11/2007, 11h32

Bonjour Maitre OraFrance, le code du trigger est au dessus ...

Le pb vient du fait que le select ramene plusieurs lignes pour toi mina

Code :

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

1
2
select osuser, terminal  into v_numbadge, v_terminal from v$session
                where   status = 'ACTIVE' and type = 'USER';

Essaye de modifier le select pour ne ramemer qu'une seulle ligne.

LBO72.

**LBO72** · 30/11/2007, 14h10

Je confirme, le pb venait du select qui ramène plusieurs lignes. Pour que ça marche, il faut s'assurer que ton select ne ramene q'une seule ligne.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
CREATE or REPLACE TRIGGER serveillance_table_Generix
   BEFORE INSERT on  Generix    -- ta table à surveiller

   DECLARE
      v_numbadge varchar2 (8);
      v_terminal varchar2(30);  

   BEGIN                   
       select osuser, terminal  into v_numbadge, v_terminal from v$session
                where   status = 'ACTIVE' and type = 'USER' and SCHEMANAME <> 'SYS';      

      INSERT INTO TMP_INSERTS 
            values ( v_numbadge,
                         sysdate,
                         v_terminal,
                        (ora_sysevent ||' ' || ora_dict_obj_type || ' ' || ora_dict_obj_name) );                             

    EXCEPTION when others then
         v_numbadge := 'XXXXX';                               
END;
/

.

Tu nous tiens informés.... merci
LBO72.

**mnitu** · 01/12/2007, 10h45

Envoyé par LBO72

Je confirme, le pb venait du select qui ramène plusieurs lignes. Pour que ça marche, il faut s'assurer que ton select ne ramene q'une seule ligne...

Mais non, LBO72 le problème vient du block Exception qui cache toutes les anomalies

**mina** · 01/12/2007, 13h04

Je vous tiendrai au courant!!

**LBO72** · 03/12/2007, 08h14

Bonjour,

mnitu
Mais non, LBO72 le problème vient du block Exception qui cache toutes les anomalies

.

C'est vrai que le block exception, ignore toutes les erreurs qui peuvent se reproduire. Le but étant que les inserts du programme appelant se passent toujours bien, qu'on les ai tracées ou pas dans la table de flicage.

Je persiste et signe que le souci pour le pb de mina est que son select ramene plusieurs lignes

LBO72.

**mina** · 03/12/2007, 13h20

Bonjour à tous,
J'ai ajouté la condition sur le schema et j'ai fait deux essais:
Le premier par une requete "insert to tsc (select * from ma_table)" :
Le résultat est que j'ai bien le nom de mon utilisateur, la date, le terminal, mais pas la requête.
L'autre essai, c'est de lancer un job via notre application, (c'est l'application que je suspecte de lancer un batch quelque part) qui me fait des insertions dans la table:
Aucune ligne dans ma table de controle, malgré que j'ai eu deux lignes insérées par ce job.
Je suis paumée.

**LBO72** · 03/12/2007, 14h32

Salut Mina,

Pour te simplfier la tâche et faire fonctionner ton trigger aussi bien en batch qu'en TP, tu peux essayer cela :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE or REPLACE TRIGGER serveillance_table_Generix
   BEFORE INSERT on  Generix for each row   -- ta table à surveiller
   DECLARE
       requete  varchar2(500);
   BEGIN                   
      requete := 'INSERT INTO Generix values( ' || :NEW.champ1 || ', ' :NEW.champ2 || ')'; --- Tu prends tous les champs de ta table
      INSERT INTO TMP_INSERTS 
            values ( ora_login_user,
                         sysdate,
                         null,
                        requete );                            
                                 
END;
/

.
A+
LBO72.

**mnitu** · 03/12/2007, 19h00

Envoyé par LBO72

Bonjour,
.

C'est vrai que le block exception, ignore toutes les erreurs qui peuvent se reproduire. Le but étant que les inserts du programme appelant se passent toujours bien, qu'on les ai tracées ou pas dans la table de flicage.

Je persiste et signe que le souci pour le pb de mina est que son select ramene plusieurs lignes

LBO72.

D'abord si c'est ton intention de toute ignorer dit-le explicitement

dans ton code.

Code :

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

1
2
3
 
When OTHERS Then 
  Null; -- OK j'ignore toutes les exceptions

Mais cella reste presque toujours une mauvais idée.

Ensuite les inserts comme tu la vu ce sont très bien passée, un peut trop

Tertio, peut être que le souci est ailleurs, par exemple impossibilité d'écrire dans la table des traces malgré les droits. Comment fait tu pour le savoir et signer ?

**orafrance** · 03/12/2007, 20h24

en l'occurence il s'agit de tracer les insert et pas de planter l'insert si le trigger a causé une erreur

c'est une excellente pratique lorsqu'on veut ajouter un trigger d'audit en étant sûr de ne pas risquer d'effet de bord désastreux

**mnitu** · 05/12/2007, 14h26

Envoyé par orafrance

...
c'est une excellente pratique lorsqu'on veut ajouter un trigger d'audit en étant sûr de ne pas risquer d'effet de bord désastreux

C’est une excellente pratique que je trouve assez discutable vu qu’il se peut que le but ne pas atteint: effectuer l’audit, et qu’on est dans l’impossibilité de savoir ce qui se passe. Si le plantage de l’insert est impensable des autres méthodes peuvent être employées.

**mina** · 05/12/2007, 16h22

ftrgfgggg

Qu'est ce qui fait des insert dans ma table!?

SQL Oracle

Discussions similaires

Partager

Partager