Is OK to kill an ORACLE process?

[Randy Hagedorn]

Hi,

I'm a bit of a nervous Nellie, when it comes to killing processes in HP-UX. But it appears that I may have a run-away ORACLE process that is consuming 100% of one of our 4 processors in a K460 system, and I was wondering if I could safely kill it.

The Oracle Instance is called 'ORD' and the process in the ps -ef command is 'oracle 20610 1 255 16:59:20 ? 316:52 oracleORD (LOCAL=NO)'.

I'm thinking that this is a just an ORACLE connection from someplace.

Can anyone confirm my thoughts about being able to kill this?

Thanks in advance,
Randy

[RAC_1]

ps -ef|grep "process" If the process's priority is the range 128-153, the process is in kernel mode and can be killed. If it is not in kernel mode, you can kill as follows.

kill "pid"
kill -1 "pid"
kill -2 "pid"
kill -3 "pid"
kill -11 "pid"
If everything above failes, use -9 signal.
Do not use -9 signal to start with.

Anil

[Randy Hagedorn]

Maybe I should clarify my question, as "If I were to kill this process, would the ORACLE database be affected adversely?".

Thanks,
Randy

[Fred Ruffet]

I would prefer to kill it first from Oracle. It would be clean. If you can't, then go through Anil's process of OS kill. Oracle background processes will ensure rollback of the session (CPU and IO comsumption may not stop right after killing).

Regards,

Fred

[Rick Garland]

ORACLE itself would not be adversely affected but you could be stepping on somebody who might be running a report.

I would double check with the DBA for more insight into the process you are looking at. The DBA should be able to associate the UNIX PID with the ORACLE process and tell you what that ORACLE process is and if it safe to kill.

[Jean-Luc Oudart]

Hi,

Oracle is robust enough to recover from a killed process.

as mentioned in other post, you should kill the session with the oracle console.
alter system kill ','

Then Oracle will have to rollback the transaction, and this may take sometimes.
Therefore, you may 1st check what this transaction is all about.

Check the size of rollback segment.


Regards
Jean-Luc

[Steven E. Protter]

If its a runaway process it might be doing damage to the databae by letting it run.

It's likely to trigger an automatic recovery. You may need to do a shutdown abort, bring up the database and then down again to get it to run normally after such and event.

Oracle is pretty robust and survives sudden failures or process kills reasonably well. If you have a major write operation going on, see about stopping that prior to doing a process kill.

SEP

[Jean-Luc Oudart]

Also check Metalink Note:161794.1 :
Should Sessions be Killed in OS or Using Alter System Kill Session?

Regards
Jean-Luc

[Patti Johnson · Accepted solution]

A couple comments from a DBA. It's ok to kill user processes (LOCAL=YES or LOCAL=NO) but don't kill a background process - dbwr, lgwr, pmon - Oracle will crash and recovery can be time consuming.
Before killing the processess you can find out who the owner is and it if is truly a run-away process, or just a very long month end report.
From sqlplus you can run this script to get more information on the process.

select spid, s.sid, p.serial#, s.terminal , pid, machine, s.program, osuser,
p.program, w.event from v$session s, v$process p,
v$session_wait w where addr = paddr and (spid like '%&&OSID%' or
process like '%&&OSID%')
and w.sid(+) = s.sid;

OSID is your unix process id. This will give you information to kill the process in Oracle before killing the unix process, or to contact the owner to see what they are running. You can also use the sid to query the v$session_wait table to determine the resource that the process is waiting on. A good indicator of a runaway process is that the seconds_in_wait time in v$session_wait is growing, but the wait event is not changing. I've hit a few bugs that behaved this way and the only option is to kill the processes.

Patti

[KapilRaj]

Hello,

What I would prefer is to use lsof to get the remote or local socket address. Then using lsof find the batch program or the sql process which has created this oracle process. I would stop if possible else kill it.

lsof -p # Note down the socket and host name

On that hostname, lsof -i tcp:

will tell me the process id of the batch or the sql script.

Regds,

Kaps

[twang]

one more thing add to above, if you use "kill" to remove oracle core process, ou may need to remove the shared memory belongs to oracle as well. Otherwise you may see the error "ORA-7306 Unable to Restart an Instance After a Crash
To see the current usage of shared memory & semaphores:
"ipcs -b"
Or you may need to remove using "ipcrm"

[John Flanagan]

Do not kill the oracle process if you can shut it down properly.

If you want to backup the database you will have to restart it and then shut it down again properly.

John.

[Yogeeraj_1]

hi,

this is modified script as per Patti's suggestion above:

select b.sid SID,b.serial# "Serial#", c.spid "srvPID", b.osuser, b.username, b.status, b.client_info from v$session b, v$process c where b.paddr = c.addr and c.sPID = &OSPID


hope this helps too!

regards
Yogeeraj

[Randy Hagedorn]

WOW, what a response from everyone!

I ended up using Oracle OEM to kill the SID in question, and marked it as KILLLED. Then I killed the PID from the HP-UX side and it all went away. Now, the script provided above doesn't show the SID being a problem any more.

The processor board that was running at 100% usage dropped off to about 15% usage.

Thanks again,
Randy