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

Version imprimable

28/11/2007, 12h40
mina

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

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!!!:?
28/11/2007, 13h44
orafrance

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.
28/11/2007, 14h09
mina

Audit??

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!

Comme l'a dit Grand Maître OraFrance :D, tu peux passer par un trigger :

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

Code:

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:

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.

28/11/2007, 14h16
mina

Je vais essayer

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!
28/11/2007, 15h38
mina

j'utilise le trigger tout compte fait

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!
28/11/2007, 17h20
mnitu
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 :)
30/11/2007, 10h31
mina

ça n'a pas marché!!!

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!!!
30/11/2007, 10h58
orafrance

quel est le code du trigger :roll:
30/11/2007, 11h32
LBO72
Bonjour Maitre OraFrance, le code du trigger est au dessus ... :D

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

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.

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:

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.

01/12/2007, 10h45
mnitu

Citation:

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 :)
01/12/2007, 13h04
mina

Je vais réessayer lundi!

Je vous tiendrai au courant!!
03/12/2007, 08h14
LBO72

Bonjour,

Citation:

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 :D

LBO72.
03/12/2007, 13h20
mina

ça marche à moitié

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.

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:

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.

03/12/2007, 19h00
mnitu
Citation:

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 :D

LBO72.

D'abord si c'est ton intention de toute ignorer dit-le explicitement :evilred: dans ton code.
Code:

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 ?
03/12/2007, 20h24
orafrance

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

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 ;)
05/12/2007, 14h26
mnitu

Citation:

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.
05/12/2007, 16h22
mina

ftrgfgggg
05/12/2007, 16h25
LBO72

Citation:

Mina
ftrgfgggg

bah alors Mina, tu parles quelle langue ?

ca a merché au fait au pas ?

LBO72.
05/12/2007, 16h32
mina

ça marche!!!!!!!!!

Excusez moi ;-) j'ai du faire un copier coller bidon quelque part!!!
Je ne sais pas ce qui tournait tous les jours (et qui continu de tourner ) mais je me suis rendu compte qu'une contrainte d'integrité n'a pas été recréée suite à mon malhereux 'drop' de cette fameuse table... j'ai recréé les index et tout le tralala mais j'ai pas pensé à la contrainte! donc, j'ai supprimé les lignes en doubles, et j'ai réactivé la contrainte.
Plus de problème, n'empèche que c'est bizarre ce truc qui fait des inserts dans mon dos!!
Voilà, je vous remercie, ça m'a été bien util de lire vos conseils.