RE: Tx lock by SMON on v$lock

  • From: "Ruth Gramolini" <rgramolini@xxxxxxxxxxxxxxx>
  • To: "oracle-l" <oracle-l@xxxxxxxxxxxxx>, <gcuccu@xxxxxxxxxxx>
  • Date: Wed, 26 Jan 2005 12:56:07 -0500

When you break a process in the middle like you did, smon has to rollback
all the changes that were made before the process ended.  Smon has to do his
work,either on shutdown with immediate,transactional, or normal, or on
startup.  Smon has to lock the rows being rolled back,  Just let him do his
thing, there is no other way!


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Giovanni Cuccu
Sent: Wednesday, January 26, 2005 11:32 AM
To: Oracle-l
Subject: Tx lock by SMON on v$lock

Hi all,
        today I faced a strange (at least for me) problem.I had to delete 30k
row from a table containing long raw. the delete (which was espressed as
delete from t where id in (select id from t1)) was running very slow. I
cancelled it and re-run under trace. After waiting for half an hour I
stopped it, I downloaded the trc file and I analyzed it.
The file showed enormous waits on enqueue. After issuing some query to
v$lock and similia I found my session was waiting for a tx lock which
was held by session 5 (SMON in my system). This situation was true even
after retrying the same operation after a db restart.
Now my question is what SMON was supposed to do?
and if the preceding answer was yes does SMON go on with recovery after both
1)shutdown abort
2) startup
(I was expecting that before a startup of the db SMON did a complete
Thanks in advance

P.S. now the TX lock is not anymore on the v$lock and the query is running

Giovanni Cuccu
Sw Engineer@xxxxxxxxxxx
Dianoema S.p.A.
Via de' Carracci 93 40131 Bologna
Tel: 051-7098211   051-4193911
No man does it all by himself,
I said young man,
put your pride on the shelf


Other related posts: