Discussion :

[dyvim]

Bonjour,
je suis intégré à un projet de maintenance d'un système de facturation qui repose sur Oracle 9.2...
Dans le cadre de cette maintenance nous avons entre autre des insertions à faire et on m'a signalé quelque chose que j'ai du mal à comprendre concernant ces insertions...
Si j'insere de façon classique (insert into...) ligne par ligne une grosse quantité de lignes cela peut prendre plusieurs heures (conséquence des triggers et autres contraintes à vérifier)... Alors que si je crée une table temporaire qui contient toutes les lignes que j'ai à insérer et que je l'insère d'un coup les plusieurs heures se transforment en minutes ...
Si quelqu'un pouvait m'expliquer les raisons de ces différences de performance....

[Process Linux]

Voilà , généralement dans les structures financières, ils ont des tables qui contiennent toute l'intelligence du traitement. Pour faire ce travail, on intégre des délencheurs dans ces tables (Déclencheur : un programme qui s'execute automatiquement suite à un évenvement d'insertion,mise à jour ou supression). Donc quand tu inséres dans cette table, Oracle fait tout un traitement en arrière plan (J'ai vu des cas où le délencheur contient plus de 20 pages de code), donc c'est normal que l'insertion prend bcp de temps dans cette table.

Comme solution, ce que font les programmeurs en général, c'est faire des insertion dans une table qui a la même structure, mais n'a pas des déclencheurs, biensur, la vitesse de traitement est nétement superieur, et à la fin de la journée , quand t il n'y a personne en production, on peut programmer une tâche qui s'execute pour faire les insertions de la table temporaire vers la table de production.

[dyvim]

Je comprends bien ce que tu me dis...
Mais au moment où l'insertion dans la table qui a des declencheurs(triggers) se fait, même en venant d'une table temporaire les déclencheurs devraient être exécutés non???
A moins qu'ils n'aient été configurés pour ne pas s'éxécuter lorsque l'on insere à partir d'une table temporaire mais cela me semble très bizarre...

[Process Linux]

Le déclencheur doit fonctionner, quelque soit la source d'insertion (Application ou table temporaire).

La seule différence c'est le type de déclencheur
1- For Each Row : Pour chaque ligne
2- Statement : Pour un lot de donnée

Peut être que quand tu fais des insertions directes, tu utilises le déclencheur sur chaque ligne ( qui est trés couteux) , et dans l'utilisation de la table temporaire , il utilise le délecheur sur statement ( qui est bcp moins couteux)

voilà

[orafrance]

un traitement unitaire :

Code :

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

1
2
3
FOR ... IN (SELECT ...) LOOP 
INSERT INTO...
END LOOP

sera toujours moins performant qu'un INSERT... SELECT c'est normal

[dyvim]

Peut être que quand tu fais des insertions directes, tu utilises le déclencheur sur chaque ligne ( qui est trés couteux) , et dans l'utilisation de la table temporaire , il utilise le délecheur sur statement ( qui est bcp moins couteux)

Ca doit etre çà... Mes collègues n'avaient pas pu m'expliquer mais je pense que la réponse doit se trouver là... Je vais aller jeter un oeil...

Merci...

[dyvim]

un traitement unitaire :

Code :

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

1
2
3
FOR ... IN (SELECT ...) LOOP 
INSERT INTO...
END LOOP

sera toujours moins performant qu'un INSERT... SELECT c'est normal

Pourquoi ??? Par rapport aux triggers je voie bien (cf plus haut) mais tu as l'air de dire que c'est valable dans tous les cas...

[orafrance]

Simplement par qu'Oracle est un SGBD qui se plait bien mieux à travailler avec des ensembles et en terme de traitement, c'est plus rapide de porter un pack de biére de la voiture à la cuisine que les cannettes les unes après les autres

[dyvim]

Simplement par qu'Oracle est un SGBD qui se plait bien mieux à travailler avec des ensembles et en terme de traitement, c'est plus rapide de porter un pack de biére de la voiture à la cuisine que les cannettes les unes après les autres

Joli image... C'est bien pratique pour comprendre...
Enfin là Oracle doit d'abord regrouper les cannettes et construire son pack de bière avant de le porter ... non???

[plaineR]

Oui mais si tu insères les lignes une à une tu as 2 contrôles par lignes (soit 2*n au total) que si tu les insères de façon globale tu n'en qu'un par ligne et un au final (trigger for each row et trigger statement).

=> si tu as beaucoup de lignes et/ou si ton trigger statement fait beaucoup de choses, il y a une chute de perf.

[orafrance]

c'est exactement ça, il regroupe les lignes, prépare la table et injecte le tout

[dyvim]

Oui mais si tu insères les lignes une à une tu as 2 contrôles par lignes (soit 2*n au total) que si tu les insères de façon globale tu n'en qu'un par ligne et un au final (trigger for each row et trigger statement).

=> si tu as beaucoup de lignes et/ou si ton trigger statement fait beaucoup de choses, il y a une chute de perf.

S'agit-il de deux triggers séparés (le "for each row" et le "statement") ?
Ou d'un seul qui est exécuté différemment selon les cas ???
D'après ce que tu me dis le trigger "statement" serait exécuté à chaque fois qu'il y a insert ... que ce soit une ou plusieurs lignes... D'ou l'interet de regrouper les insert d'une seule ligne en un seul insert de plusieurs lignes...


Sinon, merci à tous je pense que j'ai les réponses à mes interrogations...

Je vais me pencher un peu sur les triggers pour voir ce qu'ils font dans les cas d'insertions d'une ligne ou dans celui de plusieurs... Que ce soit dans ma base ou sur le site...

[plaineR]

[quote="dyvim"]

Oui mais si tu insères les lignes une à une tu as 2 contrôles par lignes (soit 2*n au total) que si tu les insères de façon globale tu n'en qu'un par ligne et un au final (trigger for each row et trigger statement).

=> si tu as beaucoup de lignes et/ou si ton trigger statement fait beaucoup de choses, il y a une chute de perf.

Regarde les triggers que tu as sur ta table :
- si la clause "for each row" est spécifiée : le trigger se déclenche pour chaque ligne
- si la clause "for each row" est absente : le trigger se déclenche pour chaque ordre insert

exemple :

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
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
SQL> create table dvp (col1 varchar2(32));
Table created.
 
SQL> create trigger trig1 before insert on dvp
  2  begin
  3  dbms_output.put_line ('trig1');
  4  end;
  5  /
Trigger created.
 
SQL> create trigger trig2 before insert on dvp
  2  for each row
  3   begin
  4   dbms_output.put_line ('trig2');
  5  end;
  6  /
Trigger created.
 
SQL> insert into dvp values ('a');
trig1
trig2
1 row created.
 
SQL> insert into dvp values ('b');
trig1
trig2
1 row created.
 
SQL> select count(*) from matable;
 COUNT(*)
---------
        3
 
SQL> insert into dvp select distinct company from company;
trig1
trig2
trig2
trig2
9 rows created.