oracle产生死锁怎么处理
原因:
1、事务之间对资源访问顺序的交替,两个用户相互访问了被对方锁住的表产生死锁;
2、两个用户并发修改同一记录产生死锁;
3、执行了一条不满足条件的语句,索引不当导致全局扫描产生死锁。
oracle死锁的原因是什么
数据库是一个多用户使用的共享资源,当多个用户并发地存取数据时,在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据,破坏数据库的一致性。加锁是实现数据库并发控制的一个非常重要的技术。在实际应用中经常会遇到的与锁相关的异常情况,当两个事务需要一组有冲突的锁,而不能将事务继续下去的话,就会出现死锁,严重影响应用的正常执行。
锁类型:
1、共享锁(Share Locks,即S锁):加了共享锁的数据对象可以被其他事务读取,但不能修改。数据库利用这两种基本的锁类型来对数据库的事务进行并发控制。
2、排它锁(Exclusive Locks,即X锁):当数据对象被加上排它锁时,其他的事务不能对它读取和修改。
3、独占锁:在共享锁的基础上,升级为独占锁。
4、更新锁:所有用户都可以读,但我将来可能会做更新操作,我已经获取了从共享锁(用来读)到排他锁(用来更新)的资格。一个事物只能有一个更新锁获此资格。
出现原因:
1、事务之间对资源访问顺序的交替:一个用户1 访问表A(锁住了表A),然后又访问表B;另一个用户2 访问表B(锁住了表B),然后企图访问表A;这时用户1由于用户2已经锁住表B,它必须等待用户2释放表B才能继续,同样用户2要等用户1释放表A才能继续,这就死锁就产生了。 解决方案:程序逻辑问题、注意表的调用顺序
2、并发修改同一记录:用户1查询一条纪录,然后修改该条纪录;这时用户2修改该条纪录,这时用户1的事务里锁的性质由查询的共享锁企图上升到独占锁,而用户2里的独占锁由于1有共享锁存在所以必须等1释放掉共享锁,而1由于2的独占锁而无法上升的独占锁也就不可能释放共享锁,于是出现了死锁 :
3、索引不当导致全表扫描:事务执行了一条不满足条件的语句执行了全表扫描或表数据量非常大索引建的过少或不合适的时候
解决方案:SQL语句中不要使用太复杂的关联多表的查询并建索引进行优化
注:
1、oracle 查看死锁并释放死锁
>>> select sess.sid, sess.serial#, lo.oracle_username, lo.os_user_name, ao.object_name, lo.locked_mode from v$locked_object lo, dba_objects ao, v$session sess where ao.object_id = lo.object_id and lo.session_id = sess.sid;
>>>> alter system kill session '738,1429'; --释放资源
2、mysql 查看死锁并释放死锁
>>> show processlist --查看数据库中各个进程的运行状态
>>> select * from information_schema.innodb_trx ---查询正在运行的事务
>>> kill id
其他常用操作
1、检查数据库确定 是否 真实存在死锁,若有 哪台机器哪个程序。
select username, lockwait, status, machine, program
from v$session
where sid in (select session_id from v$locked_object);
--Username:死锁语句所用的数据库用户;
--Lockwait :死锁的状态,如果有内容表示被死锁。
--Status :状态,active表示被死锁
--Machine :死锁语句所在的机器。
--Program :产生死锁的语句主要来自哪个应用程序。
2、确定死锁后,还可以检查是哪个语句产生死锁等待。
select sql_text
from v$sql
where hash_value in
(select sql_hash_value from v$session where sid in (select session_id from v$locked_object));
3、查询未提交事务的SQL,大概率是其引起。
select s.sid,
s.username,
s.osuser,
s.program,
to_char(s.LOGON_TIME, 'yyyymmdd hh24:mi:ss') as LOGON_TIME,
to_char(t.START_DATE, 'yyyymmdd hh24:mi:ss') as START_DATE,
s.status,
(select q.SQL_TEXT from v$sql q where q.LAST_ACTIVE_TIME = t.START_DATE
and rownum <= 1) as SQL_TEXT
from v$session s,
v$transaction t
where s.sADDR = t.SES_ADDR;
4、若找不到对应的User,则可以通过kill掉死锁的session进程
SELECT l.SESSION_ID, l.OS_USER_NAME, s.USERNAME, l.OBJECT_ID, l.ORACLE_USERNAME
FROM v$locked_object l,
v$session s
WHERE l.SESSION_ID = s.SID;
5、根据SessionID查询锁表语句
select sql_text
from v$sql
where hash_value in
(select sql_hash_value from v$session where sid in (208));
6、查看死锁
select sess.sid, sess.serial#, lo.oracle_username, lo.os_user_name, ao.object_name, lo.locked_mode, SESS.machine
from v$locked_object lo,
dba_objects ao,
v$session sess
where ao.object_id = lo.object_id
and lo.session_id = sess.sid;
7、对v$locked_object被锁对象进行查询:
SELECT l.session_id sid,
s.serial#,
l.locked_mode,
l.oracle_username,
l.os_user_name,
s.machine,
s.terminal,
o.object_name,
s.logon_time
FROM v$locked_object l, all_objects o, v$session s
WHERE l.object_id = o.object_id AND l.session_id = s.sid
ORDER BY sid, s.serial#;

分析上图结果:
第1个Session的id为139对LN_DUE进行了锁表操作,
第2个session的id为141对LN_DUE进行了锁表操作,于是死锁产生了。原因为代码中使用了两个Connection,前一个Connection执行完update语句未提交,导致行级锁未释放,
第2个Connection又去对同一个表进行update,于是只能等待前一个connection释放行级锁。
解决办法
alter system kill session '139,6151';
###139是查询结果中的SID字段,6151是查询结果中的SERIAL
附加方式
步骤一、查询主要session_id
select last_call_et,v.event,
s.sql_id,
--- s.SQL_FULLTEXT,
s.SQL_TEXT,
v.inst_id,
V.SID,
V.CLIENT_IDENTIFIER,
v.blocking_session,
v.blocking_session_status,
'alter system kill session ''' || v.sid || ',' || v.serial# || ''' immediate;',
v.USERNAME,
s.CPU_TIME,
s.ELAPSED_TIME,
v.PROGRAM,
'kill -9 ' || p.spid,
v.CLIENT_INFO,
v.SQL_HASH_VALUE,
v.SQL_ADDRESS,
v.MACHINE,
v.TERMINAL, s.DISK_READS,s.BUFFER_GETS,s.SORTS,s.SHARABLE_MEM,s.PERSISTENT_MEM,s.RUNTIME_MEM,s.ROWS_PROCESSED
from gv$session v, gv$process p, gv$sql s
where v.last_call_et > 0
and v.status = 'ACTIVE'
and v.username != 'SYS'
and p.addr = v.paddr
and s.ADDRESS = v.SQL_ADDRESS
and s.HASH_VALUE = v.SQL_HASH_VALUE
order by last_call_et desc;

步骤二、跟进对应的blocking_session值来查询详尽信息,同时给出建议命令
select CLIENT_IDENTIFIER,v.inst_id,v.status,'alter system kill session ''' || v.sid || ',' || v.serial# || ''' immediate;', v.USERNAME, v.CLIENT_INFO,v.SQL_HASH_VALUE,v.SQL_ADDRESS,v.MACHINE,v.TERMINAL from gv$session v where sid='310';

步骤三、跟进18#(上个步骤查询出来的)用nmc去定位具体的触发原因
步骤四、执行杀的操作
alter system kill session '310,24659' immediate;
blocking_session值可能有很多个,所以要根据实际情况,多处理几次,具体次数需要根据实际情况
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐


所有评论(0)