update et insert

bonjour;

je voudrais mettre en place du code pl/SQL pour réaliser des inserts lorsque je ne trouve pas l'occurence recherchée et donc le cas échéant controler si l'occurence est toujours valide par rapport aux données en paramètres

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

BEGIN SELECT * INTO v_acquereur FROM ACQUEREUR WHERE ACQUEREUR.ORGANISME_ACQUEREUR_ENVOYE_CAP = saa_evt_obj.ORGANISME_ACQUEREUR_ENVOYE_CAP;   IF v_acquereur.BANQUE_REFERENCE != saa_evt_obj.BANQUE_REFERENCE OR v_acquereur.CODE_PAYS_ACQUEREUR != saa_evt_obj.CODE_PAYS_ACQUEREUR THEN UPDATE ACQUEREUR SET ACQUEREUR.BANQUE_REFERENCE = saa_evt_obj.BANQUE_REFERENCE, ACQUEREUR.CODE_PAYS_ACQUEREUR = saa_evt_obj.CODE_PAYS_ACQUEREUR; END IF;   EXCEPTION WHEN NO_DATA_FOUND THEN INSERT INTO ACQUEREUR (ORGANISME_ACQUEREUR_ENVOYE_CAP, BANQUE_REFERENCE, CODE_PAYS_ACQUEREUR) VALUES (saa_evt_obj.ORGANISME_ACQUEREUR_ENVOYE_CAP, saa_evt_obj.BANQUE_REFERENCE, saa_evt_obj.CODE_PAYS_ACQUEREUR); END ;

---

je me demande si c'est bon, normalement le select leve une exception si l'instruction ne renvoie rien donc je ne fais pas l'update.
y a a t-il une méthode plus optimisé ? un code plus clair ?

déja je pense que le test pour savoir s'il est nécéssaire d'updater est couteux, il faut updater à chaque fois.

pris comme ça, je pense que c'est optimisé au max (c'est pas le cout d'un test qui va peser bien lourd par rapport aux requêtes...)

Cependant, tu ne décrit pas comment du récupère ton record saa_evt_obj. C'est peut etre avec cette action que tu peux capitaliser des traitement.

Pour les update/insert il y a le merge qui parait-il est le plus éfficace (j'ai jamais pu le tester sur des gros volumes).

Sinon y'a une autre méthode qui consiste à faire l'update, récupérer le SQL%ROWCOUT et faire l'insert si ce dernier est à 0.

Mais dans le cas que tu montres, ce n'est pas le même critère dans ton select et dans ton update, donc je vois pas trop comment améliorer

Citation:

---

Envoyé par remi4444

pris comme ça, je pense que c'est optimisé au max (c'est pas le cout d'un test qui va peser bien lourd par rapport aux requêtes...)

Cependant, tu ne décrit pas comment du récupère ton record saa_evt_obj. C'est peut etre avec cette action que tu peux capitaliser des traitement.

Pour les update/insert il y a le merge qui parait-il est le plus éfficace (j'ai jamais pu le tester sur des gros volumes).

Sinon y'a une autre méthode qui consiste à faire l'update, récupérer le SQL%ROWCOUT et faire l'insert si ce dernier est à 0.

Mais dans le cas que tu montres, ce n'est pas le même critère dans ton select et dans ton update, donc je vois pas trop comment améliorer

---

je me corrige l'update est extrement couteux il m'a diminué mes perfs * 10
je suis en train de tester avec les IF pour éviter l'update
Ensuite je testerais en éliminant le SELECT avec un RETURNING sur l'update

C'est normal l'UPDATE sans WHERE ?

Code:

---

1 2 3

UPDATE ACQUEREUR SET ACQUEREUR.BANQUE_REFERENCE = saa_evt_obj.BANQUE_REFERENCE, ACQUEREUR.CODE_PAYS_ACQUEREUR = saa_evt_obj.CODE_PAYS_ACQUEREUR;

---

Sinon question perfs, ça veut dire quoi le diminué par 10 ?
Combien d'enregistrements, quels temps, etc...

Citation:

---

Envoyé par McM

C'est normal l'UPDATE sans WHERE ?

---

8O ah oui j'avais pas vu!

Citation:

---

Envoyé par remi4444

8O ah oui j'avais pas vu!

---

correction ca me fait baisser les perfs que par deux en rajoutant le where que j'avais oublié

1 millions d'enregistrement sur une table
500 sur une autre
1 millions sur une dernière

7 millions sur la table qui référence en FK les trois premières (que des inserts sur celle ci)

77 champs répartis dans toutes les tables

200 intégrations de messages par seconde en moy
210 en max, 186 en min
pour une injection de messages 300 / s

180 000 messages intégrés

je pense qu'un MERGE serait le bienvenu pour remplacer tout ça non ?

Citation:

---

Envoyé par grosFab

[...]
1 millions d'enregistrement sur une table
500 sur une autre
1 millions sur une dernière

7 millions sur la table qui référence en FK les trois premières (que des inserts sur celle ci)

77 champs répartis dans toutes les tables
[...]

---

Je trouve que tu reste un peu trop général, c'est impossible de donner une solution optimisée de manière générale. Dans ton cas précis, Il y a une seule table qui est concernée, c'est ACQUEREUR. Combien fait-elle de lignes, quelles sont les colonnes indexées? quelle est exactement la clause WHERE que tu avais oublié ? Est-tu sur de ne pas faire trop d'update à chaque fois (testes-tu le SQL%ROWCOUNT apres chaque update ?)

A priori, et étant donné que sur l'exemple que tu montre, une seule table est concernée, je tenterais 2 requêtes ensemblistes (à l'aide des EXISTS/NOT EXISTS), une pour l'update, et une pour l'insert.