Transaction sous oracle

Bonjour à tous,

j'ai une question sur la gestion des transactions sous oracle. supposant que je lance une commande select (premiere transaction) et je recupere une valeur X, je fais un update X+1, et je relance un deuxieme select (3ieme transation) ,et là la valeur que je recupere normalement est toujours X car je n'ai pas fait un commit sur le update. mais le pb c'est que si je fais ça sous toad, lors du deuxieme select j'aurai le (X+1) comme resultat, c'est comme si le update est validé, hors que sous toad l'auto commit est off.

Je veux une explication svp.

Merci

Bonjour,


Ce sont 3 requêtes dans une même transaction, et non pas 3 transactions.
une transaction commence par la première reqête, et se termine par:
- commit
- ou rollback
- ou un DDL (qui fait un commit implicite)
- fun anormale de la session (qui fait un rollback implicite)

Donc si tu ne fait pas de commit sur l'update, ta transaction courante voit X+1
Mais une autre session verra X tant que tu n'as pas commité.

Cordialement,
Franck.

La façon dont toad gère ses transactions est paramétrable.
Soit une transaction par connexion soit une par onglet...

Citation:

---

Envoyé par pachot

une transaction commence par la première requête, .

---

En fait une transaction commence avec la première requête qui écrit dans la base:

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

SQL> select count(*) from v$database;   COUNT(*) ---------- 1   SQL> select count(*) from v$transaction;   COUNT(*) ---------- 0   SQL> create table tx(x int);   Table creee.   SQL> insert into tx values(1);   1 ligne creee.   SQL> select count(*) from v$transaction;   COUNT(*) ---------- 1

---

Bonjour pifor,

Désolé ce n'est pas une preuve...

On sait que LOCK TABLE fait partie d'une transaction (puisqu'il verouille une table pour toute la transaction), et pourtant:

Code:

---

1 2 3 4 5 6 7 8 9 10

SQL> SELECT count(*) FROM v$transaction; COUNT(*) ---------- 0 SQL> lock table test in exclusive mode; Table(s) Locked. SQL> SELECT count(*) FROM v$transaction; COUNT(*) ---------- 0

---

;)

Et une preuve que la transaction a pourtant bien commencée, j'enchaine avec:

Code:

---

1 2 3

SQL> alter session set isolation_level=serializable; ERROR: ORA-01453: SET TRANSACTION must be first statement of transaction

---

;);)

Donc transaction pas encore enregistrée dans v$transaction, mais pourtant bien commençée !

Cordialement,
Franck.

Je ne crois pas que LOCK TABLE écrit dans la base. Quant au libellé du message d'erreur de ALTER SESSION, il n'est peut-être pas si fiable que ça.

Je me réfère à ce qu'écrit Tom Kyte dans Expert Oracle Database Architecture page 256:

Citation:

---

A transaction implicitily begins with the first statement that modifies data (the first statement that get a TX lock).

---

Citation:

---

Envoyé par pifor

Je ne crois pas que LOCK TABLE écrit dans la base.

---

Justement, il n'écrit pas dans la base, pas de TX lock. Et pourtant il s'agit d'une transaction puisque la table est vérouillée pour toute la transaction.

isolation_level=serializable est aussi un début de transaction puisque il détermine le début d'un ensemble d'opération qui doivent être isolées des transactions concurrentes.

Je pense que Tom Kyte fait référence à une transaction active (au sens de la définition de v$transaction qui est ' lists the active transactions in the system') et qui s'enregistre à la premiere modif (lorsque du rollback est généré) accompgné d'un TX lock.

Et si on regarde start_time dans v$transaction:

Code:

---

1 2 3 4 5 6 7 8 9 10

07:05:20 KARMA_DEV01_AF> host sleep 60 07:06:20 KARMA_DEV01_AF> lock table test in exclusive mode; Table(s) Locked. 07:06:20 KARMA_DEV01_AF> host sleep 60 07:07:20 KARMA_DEV01_AF> delete from test; 1 row deleted. 07:07:20 KARMA_DEV01_AF> select ses_addr , start_time , sysdate from v$transaction; SES_ADDR START_TIME SYSDATE ---------------- -------------------- --------- 00000000BD2B2918 04/28/09 07:06:18 28-APR-09

---

La transaction n'est visible qu'à partir du delete, mais son heure de début est bien celle du lock table et non du delete...

Cordialement,
Franck.

Je pense que LOCK TABLE fait partie de la transaction si et seulement si une opération d'écriture suit: sinon il n'y a pas de transaction. Autrement dit, l'instruction LOCK TABLE ne démarre pas de transaction en elle-même: c'est bien la première écriture qui démarre la transaction et non la première requête SQL: dans ce cas, LOCK TABLE est bien rattaché à la transaction qui démarre.

Comme le dit Tom Kyte:

Citation:

---

everything is reflected in v$transaction -- the very INSTANT you start a transaction, it is reflected

---

Oui, formulé comme ça je suis d'accord :D.
D'ailleurs, quand on fait commit, la statistique 'user commits' n'est incrémentée que s'il y a eu une vrai modification.
Cordialement,
Franck.