可以通过alter system kill session ‘sid,serial#’来杀掉会话 SELECT /*+ rule */ s.username,  decode(l.type,'TM','TABLE LOCK',                'TX','ROW LOCK',                NULL) LOCK_LEVEL,  o.owner,o.object_name,o.object_type,  s.sid,s.serial#,s.terminal,s.machine,s.program,s.osuser  FROM v$session s,v$lock l,dba_objects o  WHERE l.sid = s.sid  AND l.id1 = o.object_id(+)  AND s.username is NOT NULL

解决方案 »

  1.   

    不知做一个job来删除死锁可不可行
      

  2.   

    你说的现象听起来是sql server的锁机制。
    Oracle的select根本不会影响其它同时的对同一个表的修改操作(除非你用select ... for update),Oracle的回退段实现了这个功能。
    Sql server没有回退段,只好在select的过程中也锁表。
      

  3.   


    我想用下面的方法来避免执行update语句时被锁住
        DataBase db=new DataBase();
        Connection conn=null;
        Statement stmt=null;
        int intTemp=0;
        boolean blnTemp=false;
        try{
          conn=db.getConn();
          blnTemp=conn.getAutoCommit();
          conn.setAutoCommit(false);
          stmt=conn.createStatement();
          intTemp=stmt.executeUpdate(strSQL);
          if(intTemp>0){
            stmt.execute("commit");
          }else{
            stmt.execute("rollback");
          }
          stmt.close();
          conn.setAutoCommit(blnTemp);
          conn.close();
        }catch(Exception e){
          return -1;
        }finally{
          try{
            stmt.close();
          }catch(Exception e){}
          try{
            conn.close();
          }catch(Exception e){}
        }这样写是不是可避免在执行update语句时可能存在的被锁定?
    还有就是如果我把stmt.execute("commit")换成conn.commit();把 stmt.execute("rollback");换成conn.rollback();两者会有什么不同吗?
      

  4.   

    学习
    自动解锁
    job+procedure
      

  5.   

    <<这样写是不是可避免在执行update语句时可能存在的被锁定?>>   不能避免。如果你要update的row已经被其它transaction修改而且该transaction未提交,将进入阻塞状态。<<还有就是如果我把stmt.execute("commit")换成conn.commit();把 stmt.execute("rollback");换成conn.rollback();两者会有什么不同吗?>>   没有什么不同
      

  6.   

    为了这个死锁问题,哥么我不知承担了多大的压力,现在各位大佬的热情帮助和我自己的苦心研究下大获成功,现将我的经验表述如下,与各位分享:关与死锁的产生的原因经过分析是这样产生的,当有用户对某个表或某几个表时进行大数据量搜索时这个搜索过程可能要进行几秒甚至更长,当在这个过程中有其它用户对这个表进行update或delete操作时,特别是update,如果不加事务控制,update语句将会被锁死而不能由系统快速释放(我真希望oracle或web容器本身应做到这一点)当死锁越来越多而将几个主要业务表牢牢锁死时,系统也完了,关于这一点我有点不明白,根据文章认为一般的select语句是不能锁定表的,update操作应该是没问题的,只有select * from table for update时才会锁定相关数据,但事实上我并没有采用上面这种select方法,根据我对v$session,v$lock,v$sqltext等表的分析也是如此,看来某些技术文档还是不可靠的,今天我很高兴,经过几天奋战大获成功,目前一个死锁也没出现,希望大家多多发表意见,下午结贴散分!
      

  7.   

    死锁和阻塞是不一样的,oracle的select(不带for update)绝对不会加锁,更不会引发死锁。至于阻塞,发生的几率非常高,需要你对hot表的参数(pctfree/inittrans/maxtrans/freelists)设置好才曾避免,9i的ASSM已经解决了pctfree/freelists的问题。