发现是一个很简单的select句子死锁。
SELECT category_id, category_name FROM mail_address_category ;
就是查询一个id,一个name,简单的表一个。领导让我看看是怎么回事引起的死锁,我看了好几遍程序,感觉没有什么地方可以优化的了。数据只有500多行。多人并发查询。到底能是什么原因引起的?请高手帮帮忙。在线等!!!

解决方案 »

  1.   

    select b.sql_text text,a.sid sid ,a.serial# sria#,a.username username, c.type type,a.machine machine
    from v$session a ,v$sqltext b ,v$access c
    where c.object=upper('&1')
    and c.type in ('TABLE','PACKAGE','PROCEDURE','FUNCTION','PACKAGE BODY')
    and a.sid=c.sid
    and b.address = a.sql_address
    and b.hash_value = a.sql_hash_value
    order by a.sid,a.serial#,b.piece;按照提示输入表的名字,看看是什么sql锁的表。
      

  2.   

    SELECT category_id, category_name    FROM mail_address_category    WHERE user_id = :1就是这句锁的呀。
      

  3.   

    我想问一下,select操作会引起锁表么?我看了有关的资料,好像不会引起锁表的。
      

  4.   

    首先能不能肯定是发生了死锁,还是只是程序运行太慢
    其次死锁的话好像alert_SID.log文件里有记录的吧
      

  5.   

    不带for update的select 语句是不锁表的
    lz可通过tgm78(shop34161266.taobao.com)给出的脚本查一下是否真的出现锁表了
      

  6.   

    select b.sql_text text,a.sid sid ,a.serial# sria#,a.username username, c.type type,a.machine machine
    from v$session a ,v$sqltext b ,v$access c
    where c.object=upper('&1')
    and c.type in ('TABLE','PACKAGE','PROCEDURE','FUNCTION','PACKAGE BODY')
    and a.sid=c.sid
    and b.address = a.sql_address
    and b.hash_value = a.sql_hash_value
    order by a.sid,a.serial#,b.piece;请问这样回出现什么样的情况呢,怎么样才是死锁呢,那里可以表现出呢
      

  7.   

    死锁是不可能的.既然是这么一样简单的语句.
    这么强大的并发.可能是lath
    在事发时查查v$session_wait
    看到底是在等待啥.
      

  8.   

    查log文件和udump下的trc文件。