Discussion :

[Mehdilis]

Bonjour,

J’ai un problème Oracle 9i2 sur des transactions concurrentes sur la même table Client

Traitement T1

-------à10 H00 CURSOR CCLIENT
SELECT * FROM CLIENT
Open CURSOR + FETCH
(10000 LIGNES numérotées de 1 à 10000)

10H03-------Traitement T2 indépendant de T1
( c’est un autre Batch)
UPDATE Ligne 9999+COMMIT de,
la table client qui a
été déjà , ramenée par le select
du curseur a 10H00.


---à10 H 05 Poursuite Traitement T1
A ce moment la le curseur arrive àtraiter la ligne 9999 pour (l’updater)+commit

*/ PROBLEME ???????? Oracle s’aperçoit que la Ligne 9999 a été changée par rapport ce qu’il a dans son select au moment de son ouverture. Oracle va chercher les données dans le RBS et/ou éventuellement dans les derniers snapshot (retour dans le temps passé) avec le temps undo retentions (seconde) (si j’ai bien compris 9i2).

Question : est ce que oracle revient à l’etat de donnée Ligne 9999 de 10h03 ou celle de 10H00? Si 10H00 est ce que la données de 10H03 est perdue ? expliquez moi svp

Remarque :9I2
Merci pour vos efforts,

[pifor]

A 10h05, Oracle revient à l'état de la ligne 9999 à 10h00 car Oracle ne permet de pas faire des "lectures sales" càd de lire la valeur d'une donnée modifiée par une transaction concurrente lorsque cette transaction est en cours (càd qu'elle ne s'est pas terminée par COMMIT ou ROLLBACK) et pour la même instruction SQL Oracle retourne toujours la valeur d'une donnée par rapport au même état de la base = le moment où l'instruction SQL a démarrée (statement-level read consistency).

Dans ce scénario, la valeur de la ligne 9999 pour 10h03 est perdue car écrasée par la modification de 10h05. Pour éviter ce problème, il faudrait qu'à 10h00, le curseur soit ouvert avec un SELECT FOR UPDATE pour verrouiller les lignes retournées: la transaction de 10h03 serait alors en attente sur celle de 10h00.

Voir le Concepts Guide http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96524/c01_02intro.htm#46633
qui dit en particulier:

Read consistency, as supported by Oracle, does the following:

Guarantees that the set of data seen by a statement is consistent with respect to a single point in time and does not change during statement execution (statement-level read consistency)
Ensures that readers of database data do not wait for writers or other readers of the same data
Ensures that writers of database data do not wait for readers of the same data
Ensures that writers only wait for other writers if they attempt to update identical rows in concurrent transactions

The simplest way to think of Oracle's implementation of read consistency is to imagine each user operating a private copy of the database, hence the multiversion consistency model.

[Mehdilis]

Désolé pour le format, d’autres parts , je vous remercie pour cette réactivité car vous m’avez confirmé mon hypothèse, en plus je vais faire un test et je vous tiendrai au courant, grand merci