Re: Kill Session question #2

Thank You, Anton, for this confirmation.

Maybe I can explain things better now to my manager, why he _cannot_ do what he wants in this case.
And it makes sense. A session that is opened by Oracle itself just after job_queue_processes is altered
is different from normally user opened sessions at a terminal. It would be like killing
the PMON or other background sessions - totally strange idea.

I think this thought only comes up, when you are used to use a GUI-Tool like HORA
(which I use as well, supplementary to my scripts, to supervise all sessions with one button),
only foreground sessions can be seen (derived from v$session), and the job queue session is something between, showing an event 'rdbms ipc message', and being permanently active. This prevents to shutdown the db
normally. And when my manager wanted to shutdown once (some weeks ago, and I was absent),
he was not able to do that because of the active and un-killable job queue session.
And so he finally did ... shutdown abort |-(, fortunately no problems arose from that afterwards ...

O.K. I have learned one more piece of Oracle.

ThanX

Jan=)

"Anton Buijs" <aammbuijs_at_xs4all.nl> schrieb im Newsbeitrag news:3e35670c$0$49100$e4fe514c_at_news.xs4all.nl...
> ALTER SYSTEM SET JOB_QUEUE_PROCESSES = 0; is the only way to *properly*
> prevent jobs to run.
> In fact: this wil stop the snp0, snp1, ... processes. Active processes
will
> stop when the job they are currently running is finished.
> Maybe this is the issue of your manager: setting job_queue_processes=0 is
> not the *only* thing needed to stop jobs *now*. After doing so running
jobs
> must be killed.
>
> You can kill the session, but you will see within the job_queue_interval
> period that the instance recreates the snp0, snp1,.... processes again.
You
> will find in the alert.log that it is happening. And the error count of
the
> job you killed will increase, and the job queue mechanism will retry the
> job, ignoring your interval using longer interval times after every failed
> run until it has tried it 16 times. Then the job gets broken.
>
> | ... So after all:
> | My question is:
> | can this USER session, which is very special, be killed at all in the
> usual
> | way ?
Received on Tue Jan 28 2003 - 01:55:53 CST