SMON Killed
Kishor Bhalwankar, June 08, 2004 - 4:53 am UTC
Dear Tom,
If I killed PMON then SMON will down the instance...
But If I killed SMON then who will be responsible for cleaning up the processes and to down the instance ?
Thanks
June 08, 2004 - 8:28 am UTC
pmon
killing pmon
Kishor Bhalwankar, June 19, 2004 - 4:41 am UTC
Dear Tom,
Thanks for the reply.
I am new to administration.
Still I have a doubt
I killed pmon then instance was terminated by lgwr(it is supposed to terminate by smon/pmon) and When I killed smon or lgwr then instance terminated by pmon.
Thanks in advance
June 19, 2004 - 8:07 am UTC
as long as the instance was terminated, it doesn't really matter WHO notices and does it.
fast start parallel rollback
Reader, June 19, 2004 - 12:40 pm UTC
From your earlier reply in this thread, <quote> In Oracle8i PMON defers transaction recovery of "killed" sessions
to SMON which may use fast start parallel rollback if necessary. <quote>
I thought fast_start_parallel_rollback is applicable only for the database recovery afer the instance crash to rllback any uncommitted transaction after roll forward is complete. I did not know Oracle uses fast_start_parallel_rollback for "killed" sessions" as well. Thanks.
why rollback takes long when session is killed
A reader, April 26, 2005 - 8:29 am UTC
Hi
Sometimes we kill session and the rollback takes ages but if we reboot the database things recovers much much quicker.
Is it worth to wait rollback for 2 hours when reboot takes 1 minute and everything gets cleanup much faster?
April 26, 2005 - 8:45 am UTC
when you restart (same as killing the session at the os level using kill or orakill), the transaction goes into "fast start recovery" mode -- meaning the data appears to be available but is actually being rolled back as normal and rolled back on demand.
When you kill the session using alter system, it rolls back in the same manner it would have if the user just ctl-c'ed the long running statement or types rollback in. rolling back will take as long or longer to do then the statement to do the work in the first place (in both cases, it is just that in one case, you have a rollback upon demand and overall decreased performance while it is doing this activity).
I would rather question "why am I frequently getting into a situation where I ask myself this question -- once every 50th blue moon, maybe, but frequently enough that I have to ask this?"
We have ways to control things like this, to prevent them from happening in the first place, perhaps that would be a better place to look for an optimization?
a bit confused
A reader, April 26, 2005 - 6:26 pm UTC
Hi can you explain a bit this sentence?
"in both cases, it is just that in one case, you have a rollback upon demand and overall decreased performance while it is doing this activity"
what do you mean rollback on demand? does it happen only when the database is rebooted?
we dont do this sort of thing often, killing sessions but last week we were running a massive batch update in one Data Mart which had to be aborted by killing it the performance was awful but when we rebooted it everything was lightning fast. I mean rebooting wors so good why the normal rollback does not the same as when the database is rebooted? Any draw backs or?
April 26, 2005 - 8:06 pm UTC
something else was the cause of the horrible performance I suspect, and by restarting the server, whatever that was -- was killed.
for you see, you need to recover and rollback regardless. it rolled back in both cases.