[Oracle8i][PL/SQL]Probleme de commit ou non ?

Version imprimable

08/08/2006, 15h55
Drizzt [Drone38]

[Oracle8i][PL/SQL]Probleme de commit ou non ?
Bonjour,

J'ai une procedure stockee qui enchaine les deux requetes suivantes:
Code:

1 2 3 4 5 6 7 8 9 UPDATE Table SET indicateur = 2 WHERE <conditions>; UPDATE Table SET indicateur = 3 WHERE indicateur = 2 AND <autre_condition>;
Chez moi ça fonctionne tres bien. Cependant sur un autre environnement, je n'ai jamais mon indicateur à 3 alors que <autre_condition> est validée de nombreuses fois.
La question que je me pose est : est ce le fait qu'il n'y ait pas de commit entre les deux qui peux poser problème ? Et si oui pourquoi ça marche chez moi sans commit ?

Merci d'avance.
08/08/2006, 16h02
davy.g

Cela dépend de l'isolation de la transaction mis en place sur ton autre environnement.
08/08/2006, 16h06
Drizzt [Drone38]

C'est à dire ? Tu peux développer un peu plus s'il te plait.

Merci.
08/08/2006, 16h11
Oraman

dans le deuxieme environnement tu n'est pas en mode autocommit.
tu dois mettre des commit aprés les update ou si tu veux tu peux utiliser aussi savepoint
08/08/2006, 16h12
davy.g

Vois la doc Oracle :

Citation:

Oracle Isolation Levels
Oracle provides these transaction isolation levels.

Isolation Level Description
Read committed
This is the default transaction isolation level. Each query executed by a transaction sees only data that was committed before the query (not the transaction) began. An Oracle query never reads dirty (uncommitted) data.

Because Oracle does not prevent other transactions from modifying the data read by a query, that data can be changed by other transactions between two executions of the query. Thus, a transaction that executes a given query twice can experience both nonrepeatable read and phantoms.

Serializable
Serializable transactions see only those changes that were committed at the time the transaction began, plus those changes made by the transaction itself through INSERT, UPDATE, and DELETE statements. Serializable transactions do not experience nonrepeatable reads or phantoms.

Read-only
Read-only transactions see only those changes that were committed at the time the transaction began and do not allow INSERT, UPDATE, and DELETE statements.
08/08/2006, 16h14
Oraman

essaye la commande suivante :
SQL> show autocommit
08/08/2006, 17h03
Drizzt [Drone38]

Oraman> Dans le premier environnement je ne suis pas en autocommit donc ça ne vient pas de la. Si je ne m'abuse l'autocommit n'intervient pas à ce niveau la.

davy.g> Thx, par contre je dois etre aveugle mais apres avoir parcouru moultes sites sur le sujet, je n'arrive pas à trouver comment visualiser la valeur de ce parametre pour la session en cours. A chaque fois on ne mentionne que comment le changer.
08/08/2006, 20h38
aline
Citation:
Envoyé par Drizzt [Drone38]

Bonjour,

J'ai une procedure stockee qui enchaine les deux requetes suivantes:

Code:

1 2 3 4 5 6 7 8 9 UPDATE Table SET indicateur = 2 WHERE <conditions>; UPDATE Table SET indicateur = 3 WHERE indicateur = 2 AND <autre_condition>;

Chez moi ça fonctionne tres bien. Cependant sur un autre environnement, je n'ai jamais mon indicateur à 3 alors que <autre_condition> est validée de nombreuses fois.
La question que je me pose est : est ce le fait qu'il n'y ait pas de commit entre les deux qui peux poser problème ? Et si oui pourquoi ça marche chez moi sans commit ?

Merci d'avance.
Bonjour,
Si je puis me permettre, vous vous égarez.
Cela veux juste dire que dans ton environnement de production, aucune ligne ne satisfait à tes deux conditions.

Cette requête devrait te donner le nombre de lignes qui seront updatées deux fois:
Code:

1 2 3 4 5 6 7 select count(*) from ( select * from TABLE WHERE <conditions> AND <autre_condition> )

En effet, le niveau d'isolation n'intervient pas si aucune transaction concurrente ne modifie les données (ce qu'on peut supposer sinon le problème n'est pas vraiment reproductible). Que le mode d'isolation soit READ COMMITTED ou SERIALIZABLE, une transaction voit toujours ses propres modifications. Exemple:

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
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
SQL> 
SQL> drop table t;
 
Table dropped.
 
SQL> drop table s;
 
Table dropped.
 
SQL> 
SQL> whenever sqlerror exit failure;
SQL> create table t (i int , j int);
 
Table created.
 
SQL> insert into t values (1, 1);
 
1 row created.
 
SQL> insert into t values (2, 2);
 
1 row created.
 
SQL> insert into t values (3, 3);
 
1 row created.
 
SQL> insert into t values (4, 4);
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> create table s as select * from t;
 
Table created.
 
SQL> 
SQL> create or replace procedure r as
  2  begin
  3   delete t;
  4   insert into t select * from s;
  5  end;
  6  /
 
Procedure created.
 
SQL> show errors
No errors.
SQL> commit;
 
Commit complete.
 
SQL> 
SQL> create or replace procedure u as
  2  begin
  3   r;
  4   update t set i = 2 where j > 2;
  5   update t set i = 3 where i = 2 and j > 1;
  6   end;
  7  /
 
Procedure created.
 
SQL> 
SQL> show errors
No errors.
SQL> commit;
 
Commit complete.
 
SQL> 
SQL> set transaction isolation level read committed;
 
Transaction set.
 
SQL> exec u;
 
PL/SQL procedure successfully completed.
 
SQL> select * from t;
 
         I          J                                                           
---------- ----------                                                           
         1          1                                                           
         3          2                                                           
         3          3                                                           
         3          4                                                           
 
SQL> commit;
 
Commit complete.
 
SQL> 
SQL> set transaction isolation level serializable;
 
Transaction set.
 
SQL> exec u;
 
PL/SQL procedure successfully completed.
 
SQL> select * from t;
 
         I          J                                                           
---------- ----------                                                           
         1          1                                                           
         3          2                                                           
         3          3                                                           
         3          4                                                           
 
SQL> commit;
 
Commit complete.
 
SQL> 
SQL> exit

Le mode d'isolation par défaut est READ COMMITTED http://download-uk.oracle.com/docs/c...cnsis.htm#2689
Il est assez rare qu'il soit changé. Si on le change, la commande SET TRANSACTION doit être la première instruction de la transaction. Et je ne sais pas si on peut consulter le mode pour une transaction donnée (il ne semble pas être dans V$TRANSACTION).

Si l'ensemble des explications données ne résoud pas votre problème, il nous faudrait un test qu'on peut reproduire ;)

09/08/2006, 00h27
remi4444

A tout hasard

Ta table est-elle normale ou est-ce une table organisée en index ?
Parcque moi je suis tombé une fois sur un bug affreux d'oracle 8.1.7.0 qui me prenais que la moitié de ma condition dans une clause where d'un update de table organisée en index...

Sinon tu devrais afficher le SQL%ROWCOUNT dans un dbms_output pour en avoir le coeur net
09/08/2006, 09h21
davy.g

Suis désolé !!! me suis égaré !!! :oops: :oops: :oops:
Je suis rouge de honte !!! Mais la journée d'hier a été longue...

Autant pour moi !
Je vais retourner travailler ... et m'instruire...

:pc:
09/08/2006, 11h10
Drizzt [Drone38]

Pas grave davy, ça m'a permis de voir ce que c'était que ces fameux isolation levels.

Sinon pour mon problème j'ai trouve. Le traitement sur l'autre environnement est parti en erreur à un moment donné ce qui a entrainé des effets de bords dont celui mentionné plus haut à cause de commit et rollback mal placés.

J'ai encore un peu de mal à comprendre exactement ce qui s'est passé (des maj ont été prises en compte apres d'autres non prises en compte, sur mes deux comptes rendus de traitement l'un me dit que tout est OK et l'autre n'a jamais été mis à jour).

Bref c'est le bordel :)

Merci à tous.