Discussion :

[BIOoOAG]

Bonjour à tous,

Je ne comprend pas trop pourquoi Orcale me ressort une erreur dans ce code :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
MERGE INTO INF_CMD B
USING W_CMD S
ON 		(S.INTERN_NUM = B.INTERN_NUM
       AND S.ETS    = B.ETS
       )
WHEN MATCHED THEN 
DELETE  
WHERE (B.REMFIN_COD = 'I')
;

Est-ce que vous avez une idée?

[al1_24]

Quel message d'erreur ?
Avec quelle version d'Oracle ?

Est-ce là toute la requête ?
Sinon pourquoi ne pas exécuter celle-ci :

Code :

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

1
2
3
4
5
6
7
8
9
delete from INF_CMD B
where   B.REMFIN_COD = 'I'
    and exists
        (   select  null
            from    USING W_CMD S
            where   S.INTERN_NUM = B.INTERN_NUM
                and S.ETS        = B.ETS
       )
;

[skuatamad]

C'est mieux de mettre le message d'erreur.
Il est nécessaire de préciser l'UPDATE pour réaliser le DELETE.
Une simple recherche google vous donne les précisons nécessaires :
MERGE
DELETE in the MERGE statement

Mais si vous souhaitez juste faire un DELETE, ben codez simplement un DELETE (WHERE EXISTS), pas besoin de MERGE.

[BIOoOAG]

Merci pour vos réponses!
Effectivement j'avais essayé avec l'update, mais je trouvais ça tellement bizarre de faire un update avant le delete..



Et le problème est que le delete est très très lent, (1h30)
et j'ai remarqué que parfois le merge était beaucoup plus rapide.

La table contient 8 millions de lignes et 22 index et faire un DELETE comme ça dessus c'est pas très beau, ni performant.
Donc j'essaye de trouver une solution


J'ai bien entendu regardé si il y avait un INDEX sur REMFIN_COD, INTERN_NUM, ETS (dans les 2 tables) et c'est bien le cas.


Est-ce que vous avez des idées/solution pour ce genre de cas de DELETE sur des grosses tables avec plein (trop) d'index?
(Je peux créer un nouveau sujet si jamais)

[skuatamad]

MERGE peut être plus rapide pour l'UPDATE dans les cas où il y a une sous-requête pour le SET et une pour le test d'existance.
Pour le DELETE, je ne vois pas trop pourquoi il y aurait un gain.

Combien de lignes sont à supprimer, et quel est le DDL de l'index sur REMFIN_COD, INTERN_NUM, ETS ?

Une approche possible est de DISABLE les index non utiles pour la requête et de les REBUILD après le DELETE.

[BIOoOAG]

Merci pour votre aide.

Donc j'ai changé les flux vendredi dernier et effectivement ça marche déjà mieux sans index!
Bon après j'ai un eu lock plus tard après le delete! Mais ça c'est une autres histoire surement dû à la suppression des index.

Question bête : il vaut mieux disable/rebuild ou DROP/CREATE les index? (sous oracle 11g)

[Waldar]

Il n'y a pas de raison logique que le delete soit plus lent que le merge, dans les deux cas il y a autant d'index à mettre à jour.

Il faut comparer les plans d'exécution afin de comprendre les lenteurs de la suppression.
Mon petit doigt me dit que vous faites la suppression sans parallélisme avec mise à jour des index au fil de l'eau versus un merge en parallèle avec mise à jour des index à la fin du traitement.

[BIOoOAG]

Pouvez-vous détailler un peu plus cette phrase stp :
"Vous faites la suppression sans parallélisme avec mise à jour des index au fil de l'eau versus un merge en parallèle avec mise à jour des index à la fin du traitement."

Je ne suis pas sûr de bien comprendre.

[philcero]

Personnellement je tenterais tout simplement un DELETE en mode PARALLEL forcé du genre :

Code :

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

1
2
3
4
5
<DISABLE INDEXES : Sauf PK>
 
delete /*+ PARALLEL(INF_CMD) */ ... 
 
<REBUILD INDEXES : Tous>

Sur ce genre d'opération je laisse toujours la PK accessible.

Le MERGE est plus là pour faire du Multi-DML en un, côté I/O je ne pense pas qu'il accélère quoi que ce soit.

Il faudrait voir les divers plans d'exécution pour comprendre pourquoi ici il semblerait plus rapide.