IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration Oracle Discussion :

enq: TX - contention


Sujet :

Administration Oracle

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre Expert
    Avatar de LeoAnderson
    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    2 938
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 2 938
    Par défaut 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 :
    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).....
    il ne faut quand même pas qu'il n'y ait aucune transaction pour le passer en lecture seule ????

    Pourtant, d'après la note 34566.1, le "finding blockers"
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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é...
    USN=16 correspond bien à un RBS de l'UNDO mais ça m'avance pas des masses...

    C'est quoi le truc ???

    Version 10.2.0.3 EE, Undo management auto, no garantee.

    Leo.

  2. #2
    Expert éminent
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Par défaut
    ce serait pas le flashback recovery qui pourrait poser problème par hasard ?

    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

  3. #3
    Membre Expert
    Avatar de LeoAnderson
    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    2 938
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 2 938
    Par défaut
    flashback quoi ????

    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)

  4. #4
    Expert éminent
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Par défaut
    ha oui

    et t'as pas la query qui va avec ?

  5. #5
    Membre Expert

    Profil pro
    Inscrit en
    Février 2006
    Messages
    3 437
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 3 437
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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:

    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.

  6. #6
    Expert éminent
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Par défaut
    ha oui en effet... ça se tient avec le SCN

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. problème de enq: TX - row lock contention
    Par fred_04510 dans le forum Administration
    Réponses: 5
    Dernier message: 03/03/2010, 20h24
  2. Provider fournit Int et non Currency, ClientDS pas content
    Par WebPac dans le forum Bases de données
    Réponses: 1
    Dernier message: 24/11/2004, 10h27
  3. Email Content
    Par norior dans le forum Access
    Réponses: 3
    Dernier message: 26/10/2004, 15h42
  4. [Castor] Content is not allowed in prolog.
    Par marsupilamuf dans le forum Format d'échange (XML, JSON...)
    Réponses: 2
    Dernier message: 01/09/2004, 07h59

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo