Discussion :

[grosFab]

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 :

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
 
    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 ?

[grosFab]

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

[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

[grosFab]

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

[McM]

C'est normal l'UPDATE sans WHERE ?

Code :

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

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...

[remi4444]

C'est normal l'UPDATE sans WHERE ?

ah oui j'avais pas vu!

[grosFab]

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

[orafrance]

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

[remi4444]

[...]
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.