Discussion :

[bankette]

Bonjour ,

Je dois supprimer un grand nombre de données sur une table dont la clé primaire est ultilisée dans de nombreuse autre tables en tant que clé étrangère.
Pour des raisons de performances afin de gagner du temps je suis obligé de désactiver les contraintes pour faire mon delete. Mais le problème c'est que ensuite je dois de nouveau insérer des données (il n'y a pas de commit entre les deux) puis faire un commit avant de pouvoir reactiver des contraintes.
Ce scénario n'est pas génant si je suis sur des données que je supprime et que j'insère. Mais si je supprime ou insère une mauvaise donnée, je ne peux plus reactiver les contraintes et je ne peux pas me permettre cela.

J'ai essayé de réactiver les contraintes avant le commit mais j'ai une erreur Oracle "NOWAIT specified".

Afin d'éviter ce scénario (ne pas pouvoir reactiver les contraintes) que puis-je faire?
1. coder moi meme un algo qui vérifie que toutes les données sont bonnes avant de faire le commit.
2. Existe-t-il une fonction Oracle/SQL qui vérifie l'intégrité des données?
3. autre solutions?

Merci d'avance.

PS je travaille sur Oracle 10g sur un serveur linux.

[McM]

C'est clair que tu ne peux pas réactiver les contraintes en cours de transaction vu que c'est du DDL.

Faut que tu vérifies avant que tes données supprimées et insérées soient correctes ou que tu fasses une boucle de suppression et d'insertion qui en cas d'erreur fait un log et continue le traitement.

Tout dépend de tes contraintes de développement

[bankette]

Merci McM, parce que je me demandais : avant de reactiver les contraintes, Oracle les vérifies (et refuse de les reactiver si elles sont violées), n'est il pas possible d'executer juste cette vérification sans reactiver la contrainte? A ce moment la je peux vérifier avant le commit et faire un rollback si nécessaire.

Merci.

[laurentschneider]

au lieu de désactiver les contraintes, il serait plus simple de les déférer

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
40
41
42
43
44
45
46
47
48
49
50
51
SQL> create table lsc_t(x number constraint lsc_t_pk primary key deferrable initially deferred);
 
Table created.
 
SQL> set constraints all deferred;
 
Constraint set.
 
SQL> insert into lsc_t(x) values (1);
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> set constraints all deferred;
 
Constraint set.
 
SQL> select * from lsc_t;
 
         X
----------
         1
 
SQL> insert into lsc_t(x) values (2);
 
1 row created.
 
SQL> insert into lsc_t(x) values (3);
 
1 row created.
 
SQL> insert into lsc_t(x) values (3);
 
1 row created.
 
SQL> commit;
commit
*
ERROR at line 1:
ORA-02091: transaction rolled back
ORA-00001: unique constraint (TGPOWNER.LSC_T_PK) violated
 
 
SQL> select * from lsc_t;
 
         X
----------
         1

[McM]

Voila une commande que j'ai du voir une fois dans les docs il y a longtemps..
Comme quoi, on en apprend tous les jours.

Merci Laurent et désolé Bankette d'avoir mal répondu.

[bankette]

Yes merci beaucoup !!!
Et au niveau temps d'éxecution on y gagne par rapport aux contraintes non différées?
Et doit on executer la requete a chaque fois? Ou bien faut il la désactiver apres avoir fais le commit?