Vérifier les contraintes avant un commit

Version imprimable

22/06/2009, 11h58
bankette

Vérifier les contraintes avant un commit

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.
22/06/2009, 12h14
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
22/06/2009, 12h21
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.

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

Code:

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

22/06/2009, 13h42
McM

:ccool:
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.
22/06/2009, 14h03
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?
22/06/2009, 14h26
laurentschneider

alors tu as le choix :

1) pour chaque transaction

set constraints all deferred

2) pour toute la durée de la session

alter session set constraints=deferred;

3) au niveau de la contrainte (initially deferred au lieu de initially immediate)

alter table lsc_t modify constraint lsc_t_pk initially deferred;

Quant aux performances par rapport à des contraintes supprimées, c'est sûr que le commit va prendre plus de temps vu qu'il doit valider les contraintes, mais c'est bien ce que tu voulais, non?
22/06/2009, 14h39
bankette

Oui cela correspond a ma demande, je vais faire des tests de performances de toute facon.

Mais j'ai encore une derniere question :oops:
Existe-t-il une méthode similaire mais ou l'on ne doit pas faire de

Code:

primary key defferable

Car sur l'environnement ou je travaille je n'ai malheureusement aucun droit sur le modèle de données (pas de alter, ni de choses comme ça) et mes tables n'étant pas correctement définie, le defferable ne fonctionne pas :?.
22/06/2009, 14h47
laurentschneider

hélas non, tu dois supprimer et recréer tes contraintes pour les rendre deferrable
22/06/2009, 14h51
bankette

Ok merci beaucoup, j'ai les réponses a toutes mes questions !!!
Je passes ce topic en résolu.