Discussion :

[weed]

Hello tout le monde,

J'ai lancé un update sur une table et celle-ci prends pas mal de temps.
Pendant ce temps, j'ai voulu changer le nom de 2 champs de table en question (mais ces 2 champs n'étaient pas utilisé dans l'udapte)

Malheureusement Oracle m'a jeté et m'a renvoyé une erreur avec un NOWAIT. C'est une erreur de ma part, mais j'ai l'impression que j'ai bloqué la table

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
select object_name, s.sid, s.serial#, p.spid 
from v$locked_object l, dba_objects o, v$session s, v$process p
where l.object_id = o.object_id and l.session_id = s.sid and s.paddr = p.addr;

OBJECT_NAME;SID;SERIAL#; SPID
TOAD_PLAN_TABLE; 244; 212; 264
LBO_TAB; 209; 1016; 20192
LBO_TAB; 177; 309; 7050

[escartefigue]

Le fait que vos colonnes (et non vos champs) du 2ème update ne soient pas les mêmes que celles du 1er n'a pas d'importance en terme de verrous, si vos 2 ordres update concernent des lignes communes (identifiées par des clefs communes) ou des lignes appartenant à des pages communes et que le niveau de verrouillage est la page, ou encore que votre niveau de verrouillage est la table (peu probable) alors vous avez potentiellement des deadlocks.

[weed]

Le 2ème update n'en était pas un. Il s'agissait de renommer bien des changer, donc un alter table a été fait lorsque j'ai utilisé l'assistant de Toad.

Je ne connaissais le terme deadlock. J'imagine donc ce cas que mon update est bloqué définitivement après une tentative de mon alter.
Il s'agit d'un script sql lancé en sqlplus pour mettre à jour 4 000 lignes. Je sais que cela peut être énormément de temps.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

update bolect.tab set datedmd=to_date('06/02/15' , 'DD/MM/YY') , chp2='2', chp3='2' where idcart=1195986;

[Pomalaix]

...Malheureusement Oracle m'a jeté et m'a renvoyé une erreur avec un NOWAIT. ..

Pour une bonne compréhension, il serait bienvenu que vous indiquiez les commandes exactes exécutées, ainsi que le message d'erreur précis.

[skuatamad]

Malheureusement Oracle m'a jeté et m'a renvoyé une erreur avec un NOWAIT. C'est une erreur de ma part, mais j'ai l'impression que j'ai bloqué la table

C'est normal, vous ne pouvez pas fare de DDL sur une table qui est en cours de modification :
Automatic Locks in DML Operations

Donc votre commande alter a été rejeté, je ne vois pas pourquoi votre table resterait lockée (si votre script commit ), ou pourquoi vous rencontreriez un deadlock (plus d'info nécessaire pour ce cas)

Utilisez ces requêtes pour voir si une session est bloquée :
Questions on Locking

[weed]

Il commit une fois ou 2 sur les 4 000 upadate.


Pomalaix, c'était une erreur de ma part de faire un alter et je n'ose plus relancer la requête pour voire exactement l'erreur.
La seule chose est que cela fait plus de 3 heures que mon script d'update tourne. Je vais laisser tourner toute la nuit et je vais voir ce que cela donne.


skuatamad, cela me rassure si tu me dis qu'un alter est juste rejetté mais ne bloque pas la table inutillement.
Parmi les requetes cité dans ton lien, on voit bien mon sid qui pose problème (comme la requête de mon premier post qui utilise $locked_object)

[weed]

Je viens de trouver un site interessant présentant les différents lock.

Normalement comme la première opération est le lancement d'une série d'update via sqlplus, le type de lock serait
Niveau de verrouillage => Verrouillage ligne (row level locking) : on vérouille ligne par ligne
Mode de verrouillage => X - Exclusive lock mode

Je peux continuer à faire un select sur la table, donc normalement si j'ai bien compris, la table entièrement n'est pas bloqué.

J'essairais de lancer la vue comme préconisais pour avoir la situation des locks meme si cela m'aidera pas plus que cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT SUBSTR(TO_CHAR(session_id),1,5) "SID",
       SUBSTR(lock_type,1,15) "Lock Type",
       SUBSTR(mode_held,1,15) "Mode Held",
       SUBSTR(blocking_others,1,15) "Blocking?"
FROM dba_locks

La chose la plus rassurante est que le deadlock se manifesterai par une erreur de ce style :

ORA-00060: deadlock detected while waiting for resource

Je me souviens clairement lorsque j'ai fais mon alter table pour tenter de renommer mes champs que je n'ai pas eu ce type d'erreur avec le mot clef deadlock. Je m'en serrai appercu.
Donc tout ce qui est pas deadlock, le processus fautif est supposé finir sa transaction à un moment donné.

[mnitu]

Un des meilleurs article sur le verrouillage que j'ai lu est celui de Franck Pachot publié pour le Swiss Oracle user group. Comme je ne trouve plus le lien d'origine je vais poster un autre (fichier pdf) mais qui couvre la même problématique.
Lisez le et revenez avec vos remarques et questions.

[skuatamad]

Je peux continuer à faire un select sur la table, donc normalement si j'ai bien compris, la table entièrement n'est pas bloqué.

Vous pouvez toujours faire un SELECT, même sur les lignes en cours de modification.
Lisez par exemple Data Concurrency and Consistency

Le lock exclusif sur les lignes ne concerne que d'autres commandes de modification (UPDATE, MERGE, DELETE, SELECT FOR UPDATE)

[weed]

Merci à vous tous.

Je viens de trouver l'erreur que j'avais eu dans l'historique de Toad (dans la fenetre "Output"

Pour une bonne compréhension, il serait bienvenu que vous indiquiez les commandes exactes exécutées, ainsi que le message d'erreur précis.

15:12:00 Error: ORA-00054: ressource occupée et acquisition avec NOWAIT (pas d'attente) indiquée

@mnitu, merci pour ta doc qui vient en complément avec la mienne que j'avais repéré
http://www.sqlpac.com/referentiel/do...ocks.htm#L1160


J'avais comme dans l'exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SESSION1> select * from dba_locks where session_id=13

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SESSION_ID LOCK_TYPE    MODE_HELD  MODE_REQUESTED  LOCK_ID1 LOCK_ID2 LAST_CONVERT BLOCKING_OTHERS
---------- ------------ -------------- ------------ -- -------- -------- ------------ -----------------
        13 DML          Row-X (SX)           None   723764     0                   1 Not Blocking
        13 Transaction  Exclusive            None   24303      43037               1 Not Blocking

Donc en effet j'avais un lock par ligne en mode exclusif pour que Oracle puisse mettre à jour sans que l'on puisse le perturber. Si j'avais fait un simple select, Oracle aurait posé un verrou partagé par ligne Row-Share (RS)
Si j'ai bien compris,les verrous sont posé sous forme de transaction, d'ou les 2 lignes.


J'utilise le passé, parce que c'est enfin résolu. J'ai du mal à le comprendre par contre.
Toad m'indiquait de manière régulière l'erreur suivante :

Cannot create file "C:\Users\user\AppData\Roaming\Quest Software\Toad for Oracle\11.0\User Files\CONNECTIONS.INI". Le processus ne peut pas accéder au fichier car ce fichier est utilisé par un autre processus

Je me suis dis du coup, fermons l'instance de Toad. Au moment, de le fermer, Toad m'informe que j'ai des transactions en cours, pending. J'ai le droit à 2 boutons commit ou rollback. Je commit bien sur.
Juste après, sur ma fenètre DOS dans laquelle j'avais lancé mon script d'update avec SQL Plus, je vois que enfin le script se déroule et je vois "1 ligne mise à jour" défillé.

Je suis surpris que Toad m'est demandé de Rollbacké ou de Commité alors que je n'ai pas lancé les opérations d'update dessus mais via SQL Plus.

Le scénario que j'avais fait :
- lancement d'un script de 4 000 update sous SQL Plus
- lancement quelques minutes plus tard d'un alter table pour renommer 2 champs de la dite table
- 24h plus tard (ou je m'en suis pas trop appercu avant peut être), Toad me génére une erreur
- je ferme mon instance Toad et sur le moment Toad m'informe qu'il y a une session en cours et me propose soit de rollback ou de commité
- je commit
- les update défilent.

Yououuuu


@skuatamad, okay, c'est noté

[Pomalaix]

... Si j'avais fait un simple select, Oracle aurait posé un verrou partagé par ligne Row-Share (RS) ...

Un SELECT ordinaire ne pose aucun verrou ; le RS n'apparaît qu'avec un SELECT FOR UPDATE.

[mnitu]

...
@mnitu, merci pour ta doc qui vient en complément avec la mienne que j'avais repéré
http://www.sqlpac.com/referentiel/do...ocks.htm#L1160


J'avais comme dans l'exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SESSION1> select * from dba_locks where session_id=13

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SESSION_ID LOCK_TYPE    MODE_HELD  MODE_REQUESTED  LOCK_ID1 LOCK_ID2 LAST_CONVERT BLOCKING_OTHERS
---------- ------------ -------------- ------------ -- -------- -------- ------------ -----------------
        13 DML          Row-X (SX)           None   723764     0                   1 Not Blocking
        13 Transaction  Exclusive            None   24303      43037               1 Not Blocking

...

Comme je vous ai dit c'est un des meilleurs article que j'ai lu. Prenez votre exemple et la citation suivante (de votre lien):

Lorsqu'un process place un verrou ligne sur un enregistrement :
◾1. Premièrement, un verrou de manipulation de données (DML Lock) est placé sur la ligne. Ce verrou empêche les autres sessions de manipuler ou verrouiller cette ligne. Le verrou est relâché seulement lorsque le process bloquant annule ou valide la transaction.
◾2. Ensuite un verrou DDL (data dictionary language, DDL Lock) est placé sur la table pour empêcher les altérations de structure de la table. Ce verrou est relâché également seulement lorsque le process bloquant annule ou valide la transaction.

Maintenant essayez de identifier le "DML Lock" et le "DDL Lock". Comme vous pouvez le constater votre requête vous affiche DML et Transaction!
Donc qui est DDL et qui est DML ?

[mnitu]

Si vous avez le temps lisez aussi "How Oracle Locking Works"