Discussion :

[grouhan]

Bonjour,

lors d'une mise à jour d'une colonne de table à partir d'un sous-select, est-ce qu'il y a un intérêt à ajouter une condition EXISTS pour vérifier si la jointure retourne quelque chose.

Est-ce qu'il y a un impact performance à l'utilisation de la clause exists dans ce cas de figure ? Et si oui lequel ?

Code :

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

1
2
3
4
5
6
7
Update perf_tab1 t0
set
t0.object_type = (select t1.object_type from perf_tab2 t1 where
t1.object_id = t0.object_id) where
exists (select 1 
from perf_tab2 t1 where
t1.object_id = t0.object_id);

[vanagreg]

Bonjour,

Oui bien sûr qu'il y a un intérêt. Sans clause WHERE toutes les lignes de la table seront mises à jour. Donc si ton sous-select ne ramène rien pour certaines id, alors tu mettras NULL dans object_type. Si c'est le but recherché, alors en effet la condition EXISTS n'est pas nécessaire.
Quand je dois faire une mise à jour de données pour lesquelles j'ai besoin des données source pour la mise à jour, j'utilise un MERGE, moins coûteux car données source lues qu'une fois (et syntaxe plus souple aussi);

[Waldar]

Et merge fusionne des mini-index avec les index de la cible à la fin au lieu de les mettre à jour ligne à ligne.

[grouhan]

Merci pour vos retour

J'avais été au plus simple mais la table mise à jour est bien conditionné ppour ne mettre à jour que certains enregistrements (ici j'ai ajouté pour l'exemple object_type = 'TABLE').

Dans ce cas de figure, les lignes de ma table t0 qui n'ont pas de correspondances dans t1 seront mises à jour avec Object_type à null si je ne mets pas de clause EXISTS ?

Code :

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

1
2
3
4
5
6
7
8
9
10
Update perf_tab1 t0
set
t0.object_type = (select t1.object_type from perf_tab2 t1 
where
t1.object_id = t0.object_id) 
where
exists (select 1 
from perf_tab2 t1 where
t1.object_id = t0.object_id)
and t0.object_type = 'TABLE';

Si je suis en mesure de garantir qu'il y a un correspondance, du coup il ne faut mieux pas utiliser EXISTS ? J'ai bon ?

Pour l'utilisation avec MERGE j'ai essayé avec ces instructions,

Code :

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

1
2
3
4
5
MERGE INTO perf_tab1 t0
  USING perf_tab2 t1
  ON (t0.object_id = t1.object_id) 
  WHEN MATCHED THEN
    UPDATE SET t0.object_type = t1.object_type WHERE t0.object_type = 'TABLE';

[grouhan]

Les tests effectués sont sans appel :

Ecoulé : 00:00:00.415 avec l'utilisation du merge
Ecoulé : 00:06:33.682 avec update classique sans utilisation du EXISTS
Ecoulé : 00:06:38.002 avec update et utilisation du EXISTS

Les tests confirment bien une mise à jour à null si pas de correspondance trouvé entre la table mise à jour et a table de référence.

@WALDAR : Peux-tu STP préciser "Et merge fusionne des mini-index avec les index de la cible à la fin au lieu de les mettre à jour ligne à ligne."

[vanagreg]

Tu vois que le MERGE est non seulement plus pratique, mais il est plus rapide ici.
J'utilise UPDATE uniquement quand je dois mettre à jour avec des valeurs en dur, par exemple:

Code :

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

1
2
3
UPDATE t
set status = 2, modification_date = sysdate
WHERE ....

Si les valeurs servant à la mise à jour proviennent d'autres tables, alors j'utilise MERGE, comme dans ton exemple.

[Mohamed.Houri]

Les tests effectués sont sans appel :

@WALDAR : Peux-tu STP préciser "Et merge fusionne des mini-index avec les index de la cible à la fin au lieu de les mettre à jour ligne à ligne."

Lorsque le MERGE peut se faire en "direct path load" (via l'utilisation du hint append par exemple) les indexes sont maintenus en bulk à la fin du MERGE (ou de l'INSERT)

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
 
MERGE /*+ append */ INTO t2  
    USING (SELECT * FROM t1) h
    ON (t2.n1 = h.n1)
  WHEN MATCHED THEN
    UPDATE SET t2.d1 = h.d1
  WHEN NOT MATCHED THEN
    INSERT (n1, d1)
    VALUES (h.n1, h.d1);
 
10 rows merged.
 
SQL> select * from t2;
select * from t2
              *
ERROR at line 1:
ORA-12838: cannot read/modify an object after modifying it in parallel

Dans le modele que j'ai présenté plus haut les 10 lignes mergées l'ont été via un INSERT. Et comme je ne peux pas séléctionner de la table t2 avant de commiter cela veut dire que l'INSERT a bien été fait en "direct path load". Et dans ce cas la maintenance des indexes est plus performante.

Bien Cordialement
Mohamed