十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
Oracle数据库出现死锁的时候可以按照以下处理步骤加以解决:
成都创新互联主要为客户提供服务项目涵盖了网页视觉设计、VI标志设计、全网整合营销推广、网站程序开发、HTML5响应式网站建设、手机网站开发、微商城、网站托管及成都网站维护、WEB系统开发、域名注册、国内外服务器租用、视频、平面设计、SEO优化排名。设计、前端、后端三个建站步骤的完善服务体系。一人跟踪测试的建站服务标准。已经为成都服务器托管行业客户提供了网站建设服务。
第一步:尝试在sqlplus中通过sql命令进行删除,如果能够删除成功,则万事大吉!但通常情况下,出现死锁时,想通过命令行或者通过Oracle的管理工具删除有死锁的session,oracle只会将该session标记为killed,但无法清除掉,往往需要通过第二步在操作系统层级进行删除!
Connected to Oracle9i Enterprise Edition Release 9.2.0.1.0
Connected as quik
SQL select xidusn, object_id, session_id, locked_mode from v$locked_object; --查死锁的对象,获取其SESSION_ID
XIDUSN OBJECT_ID SESSION_ID LOCKED_MODE
---------- ---------- ---------- -----------
10 30724 29 3
10 30649 29 3
SQL select username,sid,serial# from v$session where sid=29; --根据上步获取到的sid查看其serial#号
USERNAME SID SERIAL#
------------------------------ ---------- ----------
QUIK 29 57107
SQL alter system kill session '29,57107'; --删除进程,如已经删除过,则会报ora-00031的错误;否则oracle会将该session标记为killed状态,等待一段时间看能否会自动消失,如长时间消失不掉,则需要做后续步骤
alter system kill session '29,57107'
ORA-00031: session marked for kill
SQL select pro.spid from v$session ses,v$process pro where ses.sid=29 and ses.paddr=pro.addr; --查看spid号,以便在操作系统中根据该进程号删除进程
SPID
------------
2273286
第二步:进入操作系统进行删除进程,本示例的操作系统是IBM aix。
login: root --录入用户名
root's Password: --录入密码
*******************************************************************************
* *
* *
* Welcome to AIX Version 5.3! *
* *
* *
* Please see the README file in /usr/lpp/bos for information pertinent to *
* this release of the AIX Operating System. *
* *
* *
*******************************************************************************
Last unsuccessful login: Fri Apr 23 14:42:57 BEIDT 2010 on /dev/pts/1 from 10.73
.52.254
Last login: Fri Apr 23 15:27:50 BEIDT 2010 on /dev/pts/2 from 10.73.52.254
# ps -ef|grep 2273286 --查看进程详情
root 2289864 2494636 0 17:07:15 pts/1 0:00 grep 2273286
oracle 2273286 1 0 14:38:24 - 0:21 oracleQUIK (LOCAL=NO)
# kill -9 2273286 --删除进程,小心操作,别写错进程号,如果oracle的关键进程被删,数据库会崩溃的!
# ps -ef|grep 2273286 --再次查看
root 2289864 2494636 0 17:07:15 pts/1 0:00 grep 2273286
For Windows, at the DOS Prompt: orakill sid spid
For UNIX at the command line kill –9 spid
。。。。。。。。。。。。。。。。
看你写的程序有两点建议:
1.不要在存储过程里面使用动态语句,看上去完全没有使用动态语句的必要,动态语句性能要比静态语句差好多。
2.ORACLE里面插入,删除语句并没有什么行锁的概念,除非你显示调用SELECT FOR UPDATE,否则oracle不会锁住行!
建议你先看看下TOM大师的Expert_one-on-one_Oracle ORACLE和SQL SERVER 是有很大差异的!
ORACLE
EBS操作某一个FORM界面,或者后台数据库操作某一个表时发现一直出于"假死"状态,可能是该表被某一用户锁定,导致其他用户无法继续操作
复制代码
代码如下:--锁表查询SQLSELECT
object_name,
machine,
s.sid,
s.serial#
FROM
gv$locked_object
l,
dba_objects
o,
gv$session
s
WHERE
l.object_id
=
o.object_id
AND
l.session_id
=
s.sid;
找到被锁定的表,解锁
复制代码
代码如下:--释放SESSION
SQL:
--alter
system
kill
session
'sid,
serial#';
您可能感兴趣的文章:mysql
事务处理及表锁定深入简析
这种情况叫死锁,与网络质量无关。
最大的可能就是程序的原因。
如A进程修改a表的某条记录,修改完a表后,会继续修改b表的某条记录,然后提交事务。
这个时候,B进程在修改b表的那条记录,修改完后要去修改a表的那条记录,然后提交事务。
这样,当A修改完a尚未修改b,B修改完b尚未修改a的时候,就可能出现B进程等待A进程提交事务,A进程又在等待B进程提交事务,两个进程一直在等。
所以死锁就出现了。
查询锁表
SELECT object_name, machine, s.sid, s.serial#
FROM gv$locked_object l, dba_objects o, gv$session s
WHERE l.object_id = o.object_id
AND l.session_id = s.sid;
2解锁
--释放SESSION SQL:
--alter system kill session 'sid, serial#';
ALTER system kill session '23, 1647';
3锁表原因分析
1.对数据库操作update,insert,delete时候,数据库无法更新,操作等待时长,操作结果不发生改变
2.在程序中,底层(数据访问层)操作时候,不成功,数据库连接超时,无法操作,或者操作等待时长等现象
【加锁的原理】:比如一个操作在进行修改一表,它没完成,另一个操作也操作这张表时候就需要等待,前面操作结束之后才可进行操作。
4锁表分类以及如何避免锁表
Oracle锁表 行级锁 表级锁
---- 行被排他锁定
----在某行的锁被释放之前,其他用户不能修改此行 ----使用 commit 或 rollback 命令释放锁
----Oracle 通过使用 INSERT、UPDATE 和 SELECT…FOR UPDATE 语句自动获取行级锁
SELECT…FOR UPDATE 子句 ―在表的一行或多行上放置排他锁 ―用于防止其他用户更新该行
―可以执行除更新之外的其他操作
―select * from goods where gid=1001 ―for update of gname;
―只有该用户提交事务,其他用户才能够更新gname
FOR UPDATE WAIT 子句 ―Oracle9i 中的新增功能 ―防止无限期地等待锁定的行 ―等待间隔必须指定为数值文字
―等待间隔不能是表达式、赋值变量或 PL/SQL 变量
―select * from goods where gid=1001 for update of gname wait 3 ―等待用户释放更新锁的时间为3秒,否则超时。 •表级锁
―保护表的数据
―在多个用户同时访问数据时确保数据的完整性 ―可以设置为三种模式:共享、共享更新和 排他
语法:lock table table_namein mode; 共享锁 ―锁定表
―仅允许其他用户执行查询操作 ―不能插入、更新和删除
―多个用户可以同时在同一表中放置此锁 ―lock table table_name ―in share mode [nowait];
― rollback 和commit 命令释放锁 ― nowait 关键字告诉其他用户不用等待 共享更新锁
―锁定要被更新的行
―允许其他用户同时查询、插入、更新未被锁定的行
―在 SELECT 语句中使用“FOR UPDATE”子句,可以强制使用共享更新锁 ―允许多个用户同时锁定表的不同行
加锁的两种方法
lock table tab_name in share update mode; select column1,column2 from goods where goods where gid=1001
for update of column1,column2 排他锁
―与其他两种锁相比,排他锁是限制性最强的表锁 ―仅允许其他用户查询数据
―不允许执行插入、删除和更新操作
―在同一时间仅允许一位用户在表上放置排他锁 ―共享锁与此相反
lock table tab_name in exclusive mode; lock table 表名[ 表名]... in share mode [nowait]
lock table 表名[ 表名]... in exclusive mode [nowait] lock table 表名[ 表名]... in share update mode[nowait]
-----------------------------------------------------------------------------------------------
LOCK Name
LOCK — 在事务中明确地锁定一个表 LOCK [ TABLE ] name
LOCK [ TABLE ] name IN [ ROW | ACCESS ] { SHARE | EXCLUSIVE } MODE
LOCK [ TABLE ] name IN SHARE ROW EXCLUSIVE MODE 输入
name
要锁定的现存的表.
ACCESS SHARE MODE
注意: 这个锁模式对被查询的表自动生效。
这是最小限制的锁模式,只与 ACCESS EXCLUSIVE 模式冲突。 它用于保护被查询的表免于被并行的 ALTER TABLE, DROP TABLE 和 VACUUM 对同一表操作的语句修改。
ROW SHARE MODE
注意: 任何 SELECT...FOR UPDATE 语句执行时自动生效。 因为它是一个共享锁,以后可能更新为 ROW EXCLUSIVE 锁。
与 EXCLUSIVE 和 ACCESS EXCLUSIVE 锁模式冲突。
ROW EXCLUSIVE MODE
注意: 任何 UPDATE, DELETE和 INSERT 语句执行时自动生效。
与 SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE 和 ACCESS EXCLUSIVE 模式冲突。
SHARE MODE
注意: 任何 CREATE INDEX 语句执行时自动附加。 共享锁住整个表.
与 ROW EXCLUSIVE,SHARE ROW EXCLUSIVE,EXCLUSIVE 和 ACCESS EXCLUSIVE 模式冲突。这个模式防止一个表被并行更新。
SHARE ROW EXCLUSIVE MODE
注意: 这个模式类似 EXCLUSIVE MODE,但是允许其他事务的 SHARE ROW 锁.
-----------------------------------------------------------------------------------------------
与 ROW EXCLUSIVE,SHARE,SHARE ROW EXCLUSIVE,EXCLUSIVE 和 ACCESS EXCLUSIVE 模式冲突。
EXCLUSIVE MODE
注意: 这个模式同样比 SHARE ROW EXCLUSIVE 更有约束力. 它阻塞所有并行的 ROW SHARE/SELECT... FOR UPDATE 查询。
与 ROW EXCLUSIVE,SHARE,SHARE ROW EXCLUSIVE,EXCLUSIVE 和 ACCESS EXCLUSIVE 模式冲突。
ACCESS EXCLUSIVE MODE
注意: 由语句 ALTER TABLE, DROP TABLE,VACUUM 执行时自动生效。这是最严格的约束锁,它与所有其他的锁 模式冲突并且保护一个被锁定的表不被任何其他并行的操作更改。
注意: 一个不合格的 LOCK TABLE 同样要求这个锁模式 (例如,一条没有显式锁模式选项的命令)。
输出
LOCK TABLE 成功锁定后的返回.
ERROR name: Table does not exist. 如果name 不存在,返回此信息.
描述
LOCK TABLE 控制一次事务的生命期内对某表的并行访问. Postgres 在可能的情况下尽可能使用最小约束的锁模式。 LOCK TABLE 在你需要时提供更有约束力的锁。
RDBMS 锁定使用下面术语:
EXCLUSIVE
排它锁,防止其他(事务)锁的产生.
SHARE
允许其他(事务)共享锁.避免 EXCLUSIVE 锁.
ACCESS
-----------------------------------------------------------------------------------------------
锁定表结构.
ROW
锁定独立的行.
注意: 如果没有声明 EXCLUSIVE 或 SHARE,假设为 EXCLUSIVE.锁存在于事务周期内.
例如,一个应用在 READ COMMITED 隔离级别上运行事务, 并且它需要保证在表中的数据在事务的运行过程中都存在。要实现这个你 可以在查询之前对表使用 SHARE 锁模式进行锁定。这样将保护数据不被 并行修改并且为任何更进一步的对表的读操作提供实际状态的数据, 因为 SHARE 锁模式与任何写操作需要的 ROW EXCLUSIVE 模式冲突,并且你的 LOCK TABLE name IN SHARE MODE 语句将等到所有并行的写操作提交或回卷后才执行。
注意: 当在 SERIALIZABLE 隔离级别运行事务,而且你需要读取真实状态的数据时, 你必须在执行任何 DML 语句 (这时事务定义什么样的并行修改对它自己是可见的) 之前运行一个 LOCK TABLE 语句。
除了上面的要求外,如果一个事务准备修改一个表中的数据, 那么应该使用 SHARE ROW EXCLUSIVE 锁模式以避免死锁情况(当两个 并行的事务试图以 SHARE 模式锁住表然后试图更改表中的数据时, 两个事务(隐含的)都需要 ROW EXCLUSIVE 锁模式,而此模式与并行的 SHARE 锁冲突)。
继续上面的死锁(两个事务彼此等待)问题, 你应该遵循两个通用的规则以避免死锁条件:
事务应该以相同的顺序对相同的对象请求锁。
例如,如果一个应用更新行 R1 然后更新行 R2(在同一的事务里), 那么第二个应用如果稍后要更新行 R1 时不应该更新行 R2(在 同一事务里)。相反,它应该与第一个应用以相同的顺序更新行 R1 和 R2。
事务请求两个互相冲突的锁模式的前提:其中一个锁模式是自冲突的 (也就是说,一次只能被一个事务持有)。 如果涉及多种锁模式,那么事务应该总是最先请求最严格的锁模式。
这个规则的例子在前面的关于用 SHARE ROW EXCLUSIVE 模式取代 SHARE 模式的讨论中已经给出了。 -----------------------------------------------------------------------------------------------
注意: Postgres 的确检测死锁, 并将回卷至少一个等待的事务以解决死锁。
注意
LOCK 是 Postgres 语言扩展.
除了ACCESS SHARE/EXCLUSIVE 锁模式外,所有其他 Postgres 锁模式和 LOCK TABLE 语句都与那些在 Oracle 里面的兼容。
LOCK 只在事务内部使用.
用法
演示在往一个外键表上插入时在有主键的表上使用 SHARE 的锁:
BEGIN WORK;
LOCK TABLE films IN SHARE MODE; SELECT id FROM films
WHERE name = 'Star Wars: Episode I - The Phantom Menace';
-- 如果记录没有返回则回卷
INSERT INTO films_user_comments VALUES
(_id_, 'GREAT! I was waiting for it for so long!'); COMMIT WORK;
在执行删除操作时对一个有主键的表进行 SHARE ROW EXCLUSIVE 锁:
BEGIN WORK;
LOCK TABLE films IN SHARE ROW EXCLUSIVE MODE; DELETE FROM films_user_comments WHERE id IN (SELECT id FROM films WHERE rating 5); DELETE FROM films WHERE rating 5; COMMIT WORK; 兼容性 SQL92
在SQL92里面没有LOCK TABLE ,可以使用 SET TRANSACTION 来声明当前事务的级别. 我们也支持这个,参阅 SET TRANSACTION 获取详细信息。