enq: TX - contention

Bonjour,

Je veux passer un tablespace en read only (pour faire un TTS)
mais le passage en read only ne se fait pas(ça mouline, mais il ne se passe rien)
En activant la trace, je n'ai que des lignes :

Citation:

---

WAIT #3: nam='enq: TX - contention' ela= 2939497 name|mode=1415053316 usn<<16 | slot=1703955 sequence=4 obj#=-1 tim=20696336943683

---

Alors certes, j'ai bien une transaction qui est en cours dans ma base, mais je ne vois pas pourquoi elle me bloquerait (la session à l'origine de la transaction est sur un autre compte applicatif distinct et qui n'a rien à voir avec le tablespace que je veux passer en lecture)..... 8O
il ne faut quand même pas qu'il n'y ait aucune transaction pour le passer en lecture seule ???? :roll:

Pourtant, d'après la note 34566.1, le "finding blockers"

Code:

---

1 2 3 4 5 6 7

SELECT DECODE(request,0,'Holder: ','Waiter: ')||sid sess, id1, id2, lmode, request, type FROM V$LOCK WHERE (id1, id2, type) IN (SELECT id1, id2, type FROM V$LOCK WHERE request>0) ORDER BY id1, request ;

---

me retourne bien la seule session qui a une transaction mais qui n'a rien à voir...

En plus, avec OBJ#=-1, je suis avancé... :oops:
USN=16 correspond bien à un RBS de l'UNDO mais ça m'avance pas des masses... :oops:

C'est quoi le truc ???

Version 10.2.0.3 EE, Undo management auto, no garantee.

Leo.

ce serait pas le flashback recovery qui pourrait poser problème par hasard ? :koi:

en cherchant "obj#=-1" dans metalink ça semble tourner pas mal autour de logminer, undo et RAC... j'sais pas si ça t'aidera mais bon :mrgreen:

flashback quoi ???? :lol:

il y a soit le flashback database qui est basé sur des flashback logs mais qui n'est pas activé (il n'y a même pas la flash activée sur cette instance)
ou les flashback query, table, version query, et autres qui sont toutes basées sur les infos UNDO. Donc, on revient à la case départ...

LOGMINER => Pas utilisé
RAC => Non, single instance
MTS => Non, DEDICATED exclusivement
Sessions en SQL*Plus (BEQ ou TCP)

ha oui :aie:

et t'as pas la query qui va avec ?

Citation:

---

il ne faut quand même pas qu'il n'y ait aucune transaction pour le passer en lecture seule ????

---

Il semble que c'est bien la cause. J'ai fait un petit test avec 10.2.0.2/EE sur XP. J'ai créé un nouveau tablespace TS et lancé dans une session 1:

Code:

---

1 2 3 4 5 6 7

dev001> create table t(x int) tablespace ts;   Table created.   dev001> insert into t values(1);   1 row created.

---

Dans une session 2:

Code:

---

dev001> alter tablespace users read only;

---

La session 2 attend ... . Si je termine ma transaction dans session 1 par COMMIT, la session 2 est tout de suite débloquée (je n'ai pas vérifié les WAITS) !!!

C'est ce que semble aussi confirmer J. Lewis sans préciser les tablespaces en cause.

C'est aussi comme cela qu'on peut comprendre ce que dit l'Admin. Guide:

Citation:

---

All transactions with smaller start SCN, which indicates an earlier execution, can potentially hold up the quiesce and subsequent read-only state of the tablespace.

---

ha oui en effet... ça se tient avec le SCN :?

la doc dit "can potentially" et pas "will in all case" ;)

mais je trouve ça complètement hallucinant (fonctionnellement) que la copie TTS soit impossible tout simplement parce qu'un type est parti en vacances sans faire commit ! 8O

moi j'trouve ça hallucinant qu'un type puisse partir en vancances sans terminer sa transaction :evilred:

:mouarf: