当前位置: 代码迷 >> Oracle管理 >> ora-00031跟oracle中杀不死的锁
  详细解决方案

ora-00031跟oracle中杀不死的锁

热度:112   发布时间:2016-04-24 04:48:16.0
ora-00031和oracle中杀不死的锁
各位大侠:
   好!
 最近小弟遇到了一个oracle中的死锁的问题,不知该怎么解决,向各位高手讨教几招。

问题描述:
   最近我发现数据库中有个过程无法编辑,只要一编辑,数据库就呈现死机的状态。我通过网上查资料得知,这是过程被锁了。

问题的分析: 
一  为了确认是否是过程被锁了,我用了以下的语句:
select *  FROM dba_ddl_locks t
WHERE t.owner='CALNAV'
说明 : calnav就是数据库中用到的用户名
结果如下所示:
 
第6行中的记录中的名字,就是无法编辑的过程名字。

我的疑问一 : 这是否可以说明就是过程被锁了?

二 为了杀死进程,我用了以下的语句.
SELECT A.SID,A.SERIAL#,A.USERNAME,B.TYPE FROM V$SESSION A,V$LOCK B WHERE A.SID=B.SID AND a.USERNAME='CALNAV'
结果如下所示:
 

我的疑问二:
  我知道的锁类型有共享锁(S锁)、排它锁(X锁)、行级共享锁(RS锁)、行级排它锁(RX锁)、共享行级排它锁(SRX锁)。
按照上面显示的结果,’JQ’和’CU’是什么类型的锁呀?

依据上面查出来的sid和serial#,我想杀死这个锁。
然后我用了以下的语句
ALTER SYSTEM KILL SESSION '407,613';

结果让我很是郁闷,报了以下的错误

 
按照网上的说法,此时这些session的状态变成了killed,由Pmon进程来慢慢进行清除了。如果要手动的解锁,此时要找到spid,在操作系统一级杀死进程。
我采用了以下的语句:
 select spid,osuser,s.program
  from v$session s, v$process p
where s.PADDR =p.ADDR and s.SID = '407'

结果如下所示:

 
然后我登陆到服务器端,在控制台中执行了以下的命令:
 orakill 407 8847694

结果显示:
  Orakill不是内部或外部的命令,也不是可运行的程序或批处理文件。

我的疑问三:
下面是ora文件中的数据库的配置信息
HJFXDB_81 = 
  (DESCRIPTION = 
    (ADDRESS_LIST = 
      (ADDRESS = (PROTOCOL = TCP)(HOST = 132.77.127.81)(PORT = 1521)) 
    ) 
    (CONNECT_DATA = 
      (SID = hjfxdb) 
      (SERVER = DEDICATED) 
    ) 
  )
我不知道Orakill中的sid是哪个sid?是不是该换为数据库中的sid?
是不是有应该执行‘orakill hjfxdb 8847694’


 我公司的oracle用的是10g,我在服务器oracle安装目录的bin目录下没有找到orakill.exe程序。我本地的数据库是11g,我在我的本地的bin目录下看了下,发现有orakill.exe文件。这是不是数据库版本的问题?现在问题就出来了,既要用orakill,但数据库中又没有orakill.exe程序。
因为服务器不能停,就不能重启服务器。这时,我是真的没有办法了。恳请各位大侠不吝赐教!
先谢谢了!
死锁 锁进程 oracle

------解决方案--------------------
看看你的环境变量有没有问题
windows环境要设置要用set oracle_sid=xxxx
oracle_sid
还要设置path
oracle_home
oracle_base
------解决方案--------------------
1、过程不会被锁住,只有回被hang住的情形,即该过程需要pin到library cache,而此时包或过程为其它session所持有,导致被hang住。可以参考:PL/SQL 包编译时hang住的处理 
2、Oracle 10g好像没有orakill吧,Windows平台不太熟悉,如果Linux可以参考:
Oracle 彻底 kill session
3、 select instance_name,host_name from v$instance查看你当前连接的是哪个实例和主机
------解决方案--------------------
确认一下:
system_event?
session_wait?
  相关解决方案