执行一个远程更新的job，发现老报“等待 INSERT_GZ_CALLCENTRE_DATA 解锁”超时错误，
于是查看user_jobs:
select job from user_jobs;
JOB
----------
80
81
75
再查看dba_jobs_running 表：
SID JOB FAILURES LAST_DATE LAST_SEC THIS_DATE
---------- ---------- ---------- ---------- ---------------- ----------
THIS_SEC INSTANCE
---------------- ----------
7 67
8 68
49 72
上面的67，68，72 都是已经被删掉的任务，但是居然还是在运行，从而初步估计是死锁的问题。
解决方法如下：
首先去v$session 视图查找sid为 7，8，49 的会话信息：
select sid,paddr,status ,username from v$session where sid=7;
7,A60C8C,active,greatwall
用户名和执行job的用户一致，确定是该用户，再查找v$process 视图，找出对应的后台进程：
select spid from v$process where addr='A60C8C‘；
然后杀掉该进程：
kill spid;
在linux上有可能杀不掉，使用kill -9 spid即可；使用ps -ef|grep oracle,其中oracle是用户 查看进程是否还在（查看PID的值）
注意：还有一种结束会话的方法:alter system kill session ‘sid,serial#’,但是，
这些session的状态又变成了killed，然后就由Pmon进程来慢慢进行清除了，此时并没有解锁，所以当我
用这种方法的时候发现从v$session中查到的会话状态变成killed，
然而想试着删除INSERT_GZ_CALLCENTRE_DATA的时候依然报同样的错。
如果oracle装在windows下，可以用orakill 来杀。
另一中思路：
查询v$locked_object;然后用得到的object_id去dba_objects查找object_name,看是不是job，如果是，
证明job死锁了，利用v$locked_object中的session_id去杀死进程。
--用来查询后台
SELECT RAWTOHEX(paddr) paddr_hex, name FROM v$bgprocess
WHERE RAWTOHEX(paddr) <> HEXTORAW(0)
AND name LIKE 'SNP%';
Trackback: http://tb.donews.net/TrackBack.aspx?PostId=158600