当前位置:首页 » 数据仓库 » 数据库锁库dbl是什么
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

数据库锁库dbl是什么

发布时间: 2023-08-22 03:35:37

‘壹’ “sql”加锁机制是什么

您好!锁是数据库中的一个非常重要的概念,它主要用于多用户环境下保证数据库完整性和一致性。x0dx0a 我们知道,多个用户能够同时操纵同一个数据库中的数据,会发生数据不一致现象。即如果没有锁定且多个用户同时访问一个数据库,则当他们的事务同时使用相同的数据时可能会发生问题。这些问题包括:丢失更新、脏读、不可重复读和幻觉读。数据库加锁就是为了解决以上的问题。x0dx0a 当然,加锁固然好,但是一定要避免死锁的出现。x0dx0a 在数据库系统中,死锁是指多个用户(进程)分别锁定了一个资源,并又试图请求锁定对方已经锁定的资源,这就产生了一个锁定请求环,导致多个用户(进程)都处于等待对方释放所锁定资源的状态。这种死锁是最典型的死锁形式, 例如在同一时间内有两个事务A和B,事务A有两个操作:锁定表part和请求访问表supplier;事务B也有两个操作:锁定表supplier和请求访问表part。结果,事务A和事务B之间发生了死锁。死锁的第二种情况是,当在一个数据库中时,有若干个长时间运行的事务执行并行的裤拆操作,当查询分析器处理一种非常复杂的查询例如连接查询时,那么由于不能控制处理的顺序,有可能发生死锁现象。x0dx0a 在应用程序中就可以采用下面的一些方法来尽量避胡棚枣免死锁了: (1)合理安排表访问顺序。 (2)在事务中尽量避免用户干预,尽量使一个事务处理的任务少些, 保持事务简短并在一个批处理中。 (3)数据访问时域离散法, 数据访问时域离散法是指在客户机/服务器结构中,采取各种控制手段控制对数据库或数据库中的和手对象访问时间段。主要通过以下方式实现: 合理安排后台事务的执行时间,采用工作流对后台事务进行统一管理。工作流在管理任务时,一方面限制同一类任务的线程数(往往限制为1个),防止资源过多占用; 另一方面合理安排不同任务执行时序、时间,尽量避免多个后台任务同时执行,另外, 避免在前台交易高峰时间运行后台任务。 (4)数据存储空间离散法。数据存储空间离散法是指采取各种手段,将逻辑上在一个表中的数据分散到若干离散的空间上去,以便改善对表的访问性能。主要通过以下方法实现: 第一,将大表按行或列分解为若干小表; 第二,按不同的用户群分解。 (5)使用尽可能低的隔离性级别。隔离性级别是指为保证数据库数据的完整性和一致性而使多用户事务隔离的程度,SQL92定义了4种隔离性级别:未提交读、提交读、可重复读和可串行。如果选择过高的隔离性级别,如可串行,虽然系统可以因实现更好隔离性而更大程度上保证数据的完整性和一致性,但各事务间冲突而死锁的机会大大增加,大大影响了系统性能。 (6)使用绑定连接, 绑定连接允许两个或多个事务连接共享事务和锁,而且任何一个事务连接要申请锁如同另外一个事务要申请锁一样,因此可以允许这些事务共享数据而不会有加锁的冲突。 x0dx0a 总之,了解SQL Server的锁机制,掌握数据库锁定方法, 对一个合格的DBA来说是很重要的。

‘贰’ 数据库锁表是什么意思

oracle数据库 锁表和死锁的区别
死锁指的是a,b两个事务对同一对象进行dml或ddl操作(即修改表结构或者增删改数据),出现了相互等待被锁定的对象的情况,即类似于红绿灯十字路口红灯方向堵住路口,绿灯方向却红灯车辆挡在路口不能过去,这样无论红绿灯如何变化都无法通行。一般像oracle这样的dbms是有死锁检测的,然后把锁定对象抛出来按照预定规则处理或者让程序处理。 锁等待指的是a事务锁定了操作对象,而b事务也要对其进行dml或ddl操作(即修改表结构或者增删改数据)时,需要等待a事务完成。这个和死锁不同,只要a事务完成后,b事务就可以正常进行了。类似于正常的红绿灯十字路口通行状态:红灯方向就是等待锁释放的b事务,绿灯方向就是锁定路口的a事务。待红绿灯互换,则a事务执行完毕,b事务也就可以正常执行啦。
MySQL锁表是什么意思?有什么用?什么情况下用?好处?缺点?
白话解说如下:

简单说,就是lock table,不让别人动

锁分共享锁和排它锁。

共享锁时,别人能读,不能改变量表数据

排它锁时,别人既不能读,也不能改表数据

根据以上特点,应该就知道何时使用锁了。不想让别人变更数据,对自己产生影响,就加锁。一定要在不用之后,进行锁释放,不然,应历搭用系统会一直因为读取数据而报错。

好处就是,保证数据的原子性,完整性,一致性。 只有加锁者释放了锁,别人才能改变数据。

缺点就是,增加了系统开销,有可能产生锁等待,造成数据库运行异常。这都是不正常的使用锁带来的问题。
什么情况下造成数据库锁表? 如何解决?
./question/180766896
两个SQL的锁表问题
不同的数据库,多版本的实现机制不同,上述语句执行情况也就不一样,下面以oracle为例说明:

1.insert/delete语句可以并发执行,陆慧不会锁等待

2.并发insert不会锁等待

3.并发update,如果不是操作同一条记录,不会锁等待

=================================================

对真实存在的数据进行并发操作才有可能发生写冲突,所以楼主供要把握住这点就可以早烂答判断是否会冲突了。

建议楼主构造简单数据,开两个客户端,在不同的隔离级下去模拟并发操作,理论和实践相结合,你会理解的更透彻。
oracle 数据库 为什么锁表
简单地说,锁是为了保证数据的一致性,锁不止存在于oracle,其他数据库一样有,只不过机制上可能大相径庭。 至于什么样的操作会锁表,其实锁的种类很多,你所说的锁表大概说的是行级锁——也就是事务锁吧
如何将数据库中被锁表解锁
在操作数据库的时候,有时候会由于操作不当引起数据库表被锁定,这么我们经常不知所措,不知怎么给这些表解锁,在pl/sql Developer工具的的菜单“tools”里面的“sessions”可以查询现在存在的会话,但是我们很难找到那个会话被锁定了,想找到所以被锁的会话就更难了,下面这叫查询语句可以查询出所以被锁的会话。如下:

SELECT sn.username, m.SID,sn.SERIAL#, m.TYPE,

DECODE (m.lmode,

0, 'None',

1, 'Null',

2, 'Row Share',

3, 'Row Excl.',

4, 'Share',

5, 'S/Row Excl.',

6, 'Exclusive',

lmode, LTRIM (TO_CHAR (lmode, '990'))

) lmode,

DECODE (m.request,

0, 'None',

1, 'Null',

2, 'Row Share',

3, 'Row Excl.',

4, 'Share',

5, 'S/Row Excl.',

6, 'Exclusive',

request, LTRIM (TO_CHAR (m.request, '990'))

) request,

m.id1, m.id2

FROM v$session sn, v$lock m

WHERE (sn.SID = m.SID AND m.request != 0) --存在锁请求,即被阻塞

OR ( sn.SID = m.SID --不存在锁请求,但是锁定的对象被其他会话请求锁定

AND m.request = 0

AND lmode != 4

AND (id1, id2) IN (

SELECT s.id1, s.id2

FROM v$lock s

WHERE request != 0 AND s.id1 = m.id1

AND s.id2 = m.id2)

)

ORDER BY id1, id2, m.request;

通过以上查询知道了sid和 SERIAL#就可以开杀了

alter system kill session 'sid,SERIAL#';
怎么知道数据库表已经锁表了
通过查询结果中的object_id,可以查询到具体被锁的对象再给你看看我查到的一些关于锁的资料:锁有以下几种模式: 0:none 1:null 空 2:Row-S 行共享(RS):共享表锁 3:Row-X 行专用(RX):用于行的修改 4:Share 共享锁(S):阻止其他DML操作 5:S/Row-X 共享行专用(SRX):阻止其他事务操作 6:exclusive 专用(X):独立访问使用数字越大锁级别越高, 影响的操作越多。一般的查询语句如select ... from ... ;是小于2的锁, 有时会在v$locked_object出现。 select ... from ... for update; 是2的锁。当对话使用for update子串打开一个游标时,所有返回集中的数据行都将处于行级(Row-X)独占式锁定,其他对象只能查询这些数据行,不能进行update、delete或select...for update操作。 insert / update / delete ... ; 是3的锁。没有mit之前插入同样的一条记录会没有反应, 因为后一个3的锁会一直等待上一个3的锁, 我们必须释放掉上一个才能继续工作。创建索引的时候也会产生3,4级别的锁。 locked_mode为2,3,4不影响DML(insert,delete,update,select)操作, 但DDL(alter,drop等)操作会提示ora-00054错误。有主外键约束时 update / delete ... ; 可能会产生4,5的锁。 DDL语句时是6的锁。以DBA角色, 查看当前数据库里锁的情况可以用如下SQL语句: select object_id,session_id,locked_mode from v$locked_object; select t2.username,t2.sid,t2.serial#,t2.logon_time from v$locked_object t1,v$session t2 where t1.session_id=t2.sid order by t2.logon_time; 如果有长期出现的一列,可能是没有释放的锁。我们可以用下面SQL语句杀掉长期没有释放非正常的锁: alter system kill session 'sid,serial#'; 如果出现了锁的问题, 某个DML操作可能等待很久没有反应。当你采用的是直接连接数据库的方式,也不要用OS系统命令 $kill process_num 或者 $kill -9 process_num来终止用户连接,因为一个用户进程可能产生一个以上的锁, 杀OS进程并不能彻底清除锁的问题。
如何实现数据库锁表及解锁
锁表:

LOCK TABLES tablename WRITE;LOCK TABLES tablename READ;解锁

UNLOCK TABLES;
数据库中如何释锁表进程
锁表查询的代码有以下的形式:

select count(*) from v$locked_object;

select * from v$locked_object;

查看哪个表被锁

select b.owner,b.object_name,a.session_id,a.locked_mode from v$locked_object a,dba_objects b where b.object_id = a.object_id;查看是哪个session引起的

select b.username,b.sid,b.serial#,logon_time from v$locked_object a,v$session b where a.session_id = b.sid order by b.logon_time;杀掉对应进程

执行命令:alter system kill session'1025,41';

其中1025为sid,41为serial#.
怎么知道数据库表已经锁表了
先回答你的问题:

select *from v$locked_object;

可以获得被锁的对象的object_id及产生锁的会话sid。

通过查询结果中的object_id,可以查询到具体被锁的对象

再给你看看我查到的一些关于锁的资料:

锁有以下几种模式:

0:none

1:null 空

2:Row-S 行共享(RS):共享表锁

3:Row-X 行专用(RX):用于行的修改

4:Share 共享锁(S):阻止其他DML操作

5:S/Row-X 共享行专用(SRX):阻止其他事务操作

6:exclusive 专用(X):独立访问使用

数字越大锁级别越高, 影响的操作越多。

一般的查询语句如select ... from ... ;是小于2的锁, 有时会在v$locked_object出现。

select ... from ... for update; 是2的锁。

当对话使用for update子串打开一个游标时,

所有返回集中的数据行都将处于行级(Row-X)独占式锁定,

其他对象只能查询这些数据行,不能进行update、delete或select...for update操作。

insert / update / delete ... ; 是3的锁。

没有mit之前插入同样的一条记录会没有反应,

因为后一个3的锁会一直等待上一个3的锁, 我们必须释放掉上一个才能继续工作。

创建索引的时候也会产生3,4级别的锁。

locked_mode为2,3,4不影响DML(insert,delete,update,select)操作,

但DDL(alter,drop等)操作会提示ora-00054错误。

有主外键约束时 update / delete ... ; 可能会产生4,5的锁。

DDL语句时是6的锁。

以DBA角色, 查看当前数据库里锁的情况可以用如下SQL语句:

select object_id,session_id,locked_mode from v$locked_object;

select t2.username,t2.sid,t2.serial#,t2.logon_time

from v$locked_object t1,v$session t2

where t1.session_id=t2.sid order by t2.logon_time;

如果有长期出现的一列,可能是没有释放的锁。

我们可以用下面SQL语句杀掉长期没有释放非正常的锁:

alter system kill session 'sid,serial#';

如果出现了锁的问题, 某个DML操作可能等待很久没有反应。

当你采用的是直接连接数据库的方式,

也不要用OS系统命令 $kill process_num 或者 $kill -9 process_num来终止用户连接,

因为一个用户进程可能产生一个以上的锁, 杀OS进程并不能彻底清除锁的问题。

记得在数据库级别用alter system kill session 'sid,serial#';杀掉不正常的锁。

这里还讲了一些:

......>>

‘叁’ oracle--对锁机制的理解-

1 引言—数据库锁的基本概念
为了确保并发用户在存取同一数据库对象时的正确性(即无丢失修改、可重复读、不读“脏”数据),数据库中引入了锁机制。基本的锁类型有两种:排它锁(Exclusive locks记为X锁)和共享锁(Share locks记为S锁)。
排它锁:若事务T对数据D加X锁,则其它任何事务都不能再对D加任何类型的锁,直至T释放D上的X锁;一般要求在修改数据前要向该数据加排它锁,所以排它锁又称为写锁。
共享锁:若事务T对数据D加S锁,则其它事务只能对D加S锁,而不能加X锁,直至T释放D上的S锁;一般要求在读取数据前要向该数据加共享锁,所以共享锁又称为读锁。
2 Oracle 多粒度封锁机制介绍
根据保护对象的不同,Oracle数据库锁可以分为以下几大类:
(1) DML lock(data locks,数据锁):用于保护数据的完整性;
(2) DDL lock(dictionary locks,字典锁):用于保护数据库对象的结构(例如表、视图、索引的结构定义);
(3) internal locks 和l a t c h es(内部锁与闩):保护内部数据库结构;
(4) distributed locks(分布式锁):用于OPS(并行服务器)中;
(5) PCM locks(并行高速缓存管理锁):用于OPS(并行服务器)中。
本文主要讨论DML(也可称为data locks,数据锁)锁。从封锁粒度(封锁对象的大小)的角度看,Oracle DML锁共有两个层次,即行级锁和表级锁。
2.1 Oracle的TX锁(行级锁、事务锁)
许多对Oracle不太了解的技术人员可能会以为每一个TX锁代表一条被封锁的数据行,其实不然。TX的本义是Transaction(事务),当一个事务第一次执行数据更改(Insert、Update、Delete)或使用SELECT… FOR UPDATE语句进行查询时,它即获得一个TX(事务)锁,直至该事务结束(执行COMMIT或ROLLBACK操作)时,该锁才被释放。所以,一个TX锁,可以对应多个被该事务锁定的数据行。
在Oracle的每行数据上,都有一个标志位来表示该行数据是否被锁定。Oracle不象其它一些DBMS(数据库管理系统)那样,建立一个链表来维护每一行被加锁的数据,这样就大大减小了行级锁的维护开销,也在很大程度上避免了其它数据库系统使用行级封锁时经常发生的锁数量不够的情况。数据行上的锁标志一旦被置位,就表明该行数据被加X锁,Oracle在数据行上没有S锁。
2.2 TM锁(表级锁)
2.2.1 意向锁的引出
表是由行组成的,当我们向某个表加锁时,一方面需要检查该锁的申请是否与原有的表级锁相容;另一方面,还要检查该锁是否与表中的每一行上的锁相容。比如一个事务要在一个表上加S锁,如果表中的一行已被另外的事务加了X锁,那么该锁的申请也应被阻塞。如果表中的数据很多,逐行检查锁标志的开销将很大,系统的性能将会受到影响。为了解决这个问题,可以在表级引入新的锁类型来表示其所属行的加锁情况,这就引出了“意向锁”的概念。
意向锁的含义是如果对一个结点加意向锁,则说明该结点的下层结点正在被加锁;对任一结点加锁时,必须先对它的上层结点加意向锁。如:对表中的任一行加锁时,必须先对它所在的表加意向锁,然后再对该行加锁。这样一来,事务对表加锁时,就不再需要检查表中每行记录的锁标志位了,系统效率得以大大提高。
2.2.2 意向锁的类型
由两种基本的锁类型(S锁、X锁),可以自然地派生出两种意向锁:
意向共享锁(Intent Share Lock,简称IS锁):如果要对一个数据库对象加S锁,首先要对其上级结点加IS锁,表示它的后裔结点拟(意向)加S锁;
意向排它锁(Intent Exclusive Lock,简称IX锁):如果要对一个数据库对象加X锁,首先要对其上级结点加IX锁,表示它的后裔结点拟(意向)加X锁。
另外,基本的锁类型(S、X)与意向锁类型(IS、IX)之间还可以组合出新的锁类型,理论上可以组合出4种,即:S+IS,S+IX,X+IS,X+IX,但稍加分析不难看出,实际上只有S+IX有新的意义,其它三种组合都没有使锁的强度得到提高(即:S+IS=S,X+IS=X,X+IX=X,这里的“=”指锁的强度相同)。所谓锁的强度是指对其它锁的排斥程度。
这样我们又可以引入一种新的锁的类型
共享意向排它锁(Shared Intent Exclusive Lock,简称SIX锁) :如果对一个数据库对象加SIX锁,表示对它加S锁,再加IX锁,即SIX=S+IX。例如:事务对某个表加SIX锁,则表示该事务要读整个表(所以要对该表加S锁),同时会更新个别行(所以要对该表加IX锁)。
这样数据库对象上所加的锁类型就可能有5种:即S、X、IS、IX、SIX。
具有意向锁的多粒度封锁方法中任意事务T要对一个数据库对象加锁,必须先对它的上层结点加意向锁。申请封锁时应按自上而下的次序进行;释放封锁时则应按自下而上的次序进行;具有意向锁的多粒度封锁方法提高了系统的并发度,减少了加锁和解锁的开销。

‘肆’ 数据库中的封锁机制是什么的主要方法

可分为如下三类:
1、内部级封锁
内部级封锁是用于保护ORACLE内部结构,由系统内部实现,用户不能访问,因此我们不必对此做过多的了解。
2、DDL级封锁(字典/语法分析封锁)
DDL级封锁也是由ORACLERDBMS来控制,它用于保护数据字典和数据定义改变时的一致性和完整性。它是系统在对SQL定义语句作语法分析时自动地加锁,无需用户干予。字典/语法分析封锁共分三类:
(1)、字典操作锁:用于对字典操作时,锁住数据字典,此封锁是独占的,从而保护任何一个时刻仅能对一个字典操作。
(2)、字典定义锁:用于防止在进行字典操作时又进行语法分析,这样可以避免在查询字典的同时改动某个表的结构。
(3)、表定义锁:用于一个SQL语句正当访问某个表时,防止字典中与该表有关的项目被修改。
3、DML级封锁
DML级封锁用于控制并发事务中的数据操纵,保证数据的一致性和完整性,其封锁对象可以是表或行。
对用户的数据操纵,Oracle可以自动为操纵的数据进行封锁,但如果有操纵授权,则为满足并发操纵的需要另外实施封锁。DML封锁可由一个用户进程以显式的方式加锁,也可通过某些SQL语句隐含方式实现。
DML锁有如下三种封锁方式:
(1)、共享封锁方式(SHARE)
(2)、独占封锁方式(EXCLUSIVE)
(3)、共享更新封锁(SHARE UPDATE)
其中SHARE,EXCLUSIVE用于表封锁,SHARE UPDATE用于行封锁。

‘伍’ Oracle数据库锁的常用类型有哪些

Oracle数据库的锁类型

根据保护的对象不同,Oracle数据库锁可以分为以下几大类:DML锁(data locks,数据锁),用于保护数据的完整性;DDL锁(dictionary locks,字典锁),用于保护数据库对象的结构,如表、索引等的结构定义;内部锁和闩(internal locks and latches),保护数据库的内部结构。

DML锁的目的在于保证并发情况下的数据完整性,本文主要讨论DML锁。在Oracle数据库中,DML锁主要包括TM锁和TX锁,其中TM锁称为表级锁,TX锁称为事务锁或行级锁。

当Oracle执行DML语句时,系统自动在所要操作的表上申请TM类型的锁。当TM锁获得后,系统再自动申请TX类型的锁,并将实际锁定的数据行的锁标志位进行置位。这样在事务加锁前检查TX锁相容性时就不用再逐行检查锁标志,而只需检查TM锁模式的相容性即可,大大提高了系统的效率。TM锁包括了SS、SX、S、X等多种模式,在数据库中用0-6来表示。不同的SQL操作产生不同类型的TM锁。如表1所示。

在数据行上只有X锁(排他锁)。在 Oracle数据库中,当一个事务首次发起一个DML语句时就获得一个TX锁,该锁保持到事务被提交或回滚。当两个或多个会话在表的同一条记录上执行DML语句时,第一个会话在该条记录上加锁,其他的会话处于等待状态。当第一个会话提交后,TX锁被释放,其他会话才可以加锁。

当Oracle数据库发生TX锁等待时,如果不及时处理常常会引起Oracle数据库挂起,或导致死锁的发生,产生ORA-60的错误。这些现象都会对实际应用产生极大的危害,如长时间未响应,大量事务失败等。

TX锁等待的分析

在介绍了有关地Oracle数据库锁的种类后,下面讨论如何有效地监控和解决锁等待现象,及在产生死锁时如何定位死锁的原因。

监控锁的相关视图 数据字典是Oracle数据库的重要组成部分,用户可以通过查询数据字典视图来获得数据库的信息。和锁相关的数据字典视图如表2所示。

TX锁等待的监控和解决在日常工作中,如果发现在执行某条SQL时数据库长时间没有响应,很可能是产生了TX锁等待的现象。为解决这个问题,首先应该找出持锁的事务,然后再进行相关的处理,如提交事务或强行中断事务。

死锁的监控和解决在数据库中,当两个或多个会话请求同一个资源时会产生死锁的现象。死锁的常见类型是行级锁死锁和页级锁死锁,Oracle数据库中一般使用行级锁。下面主要讨论行级锁的死锁现象。

当Oracle检测到死锁产生时,中断并回滚死锁相关语句的执行,报ORA-00060的错误并记录在数据库的日志文件alertSID.log中。同时在user_mp_dest下产生了一个跟踪文件,详细描述死锁的相关信息。

在日常工作中,如果发现在日志文件中记录了ora-00060的错误信息,则表明产生了死锁。这时需要找到对应的跟踪文件,根据跟踪文件的信息定位产生的原因。

如果查询结果表明,死锁是由于bitmap索引引起的,将IND_T_PRODUCT_HIS_STATE索引改为normal索引后,即可解决死锁的问题。

表1 Oracle的TM锁类型
锁模式 锁描述 解释 SQL操作
0 none
1 NULL 空 Select
2 SS(Row-S) 行级共享锁,其他对象只能查询这些数据行 Select for update、Lock for update、Lock row share

3 SX(Row-X) 行级排它锁,在提交前不允许做DML操作 Insert、Update、Delete、Lock row share

4 S(Share) 共享锁 Create index、Lock share
5 SSX(S/Row-X) 共享行级排它锁 Lock share row exclusive
6 X(Exclusive) 排它锁 Alter table、Drop able、Drop index、Truncate table 、Lock exclusive

表2 数据字典视图说明
视图名 描述 主要字段说明
v$session 查询会话的信息和锁的信息。 sid,serial#:表示会话信息。

program:表示会话的应用程序信息。

row_wait_obj#:表示等待的对象。

和dba_objects中的object_id相对应。

v$session_wait 查询等待的会话信息。 sid:表示持有锁的会话信息。

Seconds_in_wait:表示等待持续的时间信息

Event:表示会话等待的事件。

v$lock 列出系统中的所有的锁。 Sid:表示持有锁的会话信息。

Type:表示锁的类型。值包括TM和TX等。

ID1:表示锁的对象标识。

lmode,request:表示会话等待的锁模式的信

息。用数字0-6表示,和表1相对应。

dba_locks 对v$lock的格式化视图。 Session_id:和v$lock中的Sid对应。

Lock_type:和v$lock中的type对应。

Lock_ID1: 和v$lock中的ID1对应。

Mode_held,mode_requested:和v$lock中

的lmode,request相对应。

v$locked_object 只包含DML的锁信息,包括回滚段和会话信息。 Xisn,xidslot,xidsqn:表示回滚段信息。和

v$transaction相关联。

Object_id:表示被锁对象标识。

Session_id:表示持有锁的会话信息。

Locked_mode:表示会话等待的锁模式的信

息,和v$lock中的lmode一致。

col owner for a12
col object_name for a16
select b.owner,b.object_name,l.session_id,l.locked_mode
from v$locked_object l, dba_objects b
where b.object_id=l.object_id;

select t2.username,t2.sid,t2.serial#,t2.logon_time
from v$locked_object t1,v$session t2
where t1.session_id=t2.sid order by t2.logon_time;

如果有长期出现的一列,可能是没有释放的锁。我们可以用下面SQL语句杀掉长期没有释放非正常的锁:

alter system kill session 'sid,serial# ';

如果出现了锁的问题, 某个DML操作可能等待很久没有反应。

当你采用的是直接连接数据库的方式,也不要用OS系统命令 $kill process_num 或者 $kill -9 process_num来终止用户连接,因为一个用户进程可能产生一个以上的锁, 杀OS进程并不能彻底清除锁的问题

Oracle锁表(死锁) 2011-05-03 17:46:41| 分类: Java技术 | 标签: |字号大中小 订阅 .

数据库与操作系统一样,是一个多用户使用的共享资源。 当多个用户并发地存取数据时,在数据库中就会发生多个事务同时存取同一数据地情况。 若对并发操作不加控制就可能会读取和存储不正确地数据,破坏数据库地一致性。 加锁时实现数据库并发控制地一个非常重要地技术。 在实际应用中经常会遇到地与锁相关地异常情况,当两个事务需要一组有冲突的锁,而不能将事务继续下去的话,就会出现死锁,严重影响应用的正常执行。

在数据库中有两种基本的锁类型:排它锁(Exclusive Locks,即X锁)和共享锁(即S锁)。当数据对象被加上排它锁时,其他的事务不能不能对它读取和修改。加了共享锁的数据对象可以被其他事务读取,但不能修改。数据库利用这两种基本的锁类型来对数据库的事务进行并发控制。

死锁的第一种情况:

一个用户A访问表A(锁住了表A),然后又访问表B; 另一个用户B访问表B(锁住了表B),然后企图访问表A;这时用户A由于用户B已经锁住表B,它必须等待用户B释放表B才能继续,同样用户B要等用户A释放表A才能继续,这就死锁产生了。

解决方法:

这种死锁比较常见,是由于程序的BUG产生的,除了调整程序的逻辑没有其它的办法。仔细分析程序的逻辑,对于数据库的多表操作时,尽量按照同样的顺序进行处理,尽量避免同时锁定两个资源,如操作A和B两张表时,总是按先A后B的顺序处理,必须同时锁定两个资源时,要保证在任何时刻都应该按照相同的顺序来锁定资源。

死锁的第二种情况

用户A查询一条记录,然后修改该条记录;这时用户B修改该条记录,这时用户A的事务里锁的性质由查询的共享锁企图上升到独占锁,而用户B里的独占锁由于A有共享锁存在必须等A释放掉共享锁,而A由于B的独占锁而无法上升到独占锁也就不可能释放共享锁,于是出现了死锁。这种死锁比较隐蔽,但在稍大点的项目种经常发生,如在某项目中,页面上的按钮点击后,没有使按钮立刻失效,使得用户会多次快速点击同一按钮,这样同一段代码对数据库同一条记录进行多次操作,很容易就出现这种死锁的情况。

解决方法:

1、对于按钮等控件,点击后使其立刻失效,不让用户重复点击,避免对同时对同一条记录操作。

2、使用乐观锁进行控制。乐观锁大多是基于数据版本(version)记录机制实现。即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库增加一个“version”字段来实现。读取处数据时,将此版本号一同读出,之后更新时,对此版本号加一。此时,将提交的数据的版本数据与数据库表对应记录的当前版本信息进行比对,如果提交的数据版本号大于数据库表当前版本号,则予以更新,否则认为是过期数据。乐观锁机制避免了长事务中的数据库加锁开销(用户A和用户B操作过程中,都没有对数据库加锁),大大提升了大并发量下的系统整体性表现。 Hibernate在其数据访问引擎中内置了乐观锁实现。需要注意的是,由于乐观锁机制是我们的系统中实现,来自外部系统的用户更新操作不受我们系统的控制,因此可能会造成脏数据被更新到数据库中。

3、使用悲观锁进行控制。悲观锁大多数情况下依靠数据库的锁机制实现,如Oracle的select.......for update语句,以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。如一个金融系统,当某个操作员读取用户的数据,并在读出的用户数据的基础上进行修改时(如更改用户帐户余额),如果采用悲观锁机制,也就意味整个操作过程中(从操作员读出数据、开始修改直至提交修改结果的全过程,甚至还包括操作员中途去煮咖啡的时间),数据库记录始终处于加锁状态,可以想见,如果面对成百上千个并发,这样的情况将导致灾难性的结果。所以,采用悲观锁进行控制时一定要考虑清楚。

死锁的第三种情况

如果在事务种执行了一条不满足条件的update语句,则执行全表扫描,把行级锁上升为表级锁,多个这样的事务执行之后,就很容易发生死锁和阻塞。类似的情况还有当表种的数据量非常庞大而索引建的过少或不合适的时候,使得经常发生全表扫描,最终应用系统会越来越慢,最终发生阻塞或死锁。

解决方法:

SQL语句中不要使用太复杂的关联多表的查询;使用“执行计划”对SQL语句进行 分析,对于有全表扫描的SQL语句,建立相应的索引进行优化。

***查询死锁表以及解锁表***

通过select * from v$locked_object

可以获得被锁的对象的object_id及产生锁的会话sid,通过查询结果中的object_id,可以查询到具体被锁的对象。

锁有以下几种模式:
0:none
1:null 空
2:Row-S 行共享(RS / S锁):共享表锁
3:Row-X 行专用(RX / X锁):用于行的修改
4:Share 共享锁(S):阻止其他DML操作
5:S/Row-X 共享行专用(SRX):阻止其他事务操作
6:exclusive 专用(X):独立访问使用
数字越大锁级别越高, 影响的操作越多。

一般的查询语句如select ... from ... ;是小于2的锁, 有时会在v$locked_object出现。

select ... from ... for update; 是2的锁。

当对话使用for update子串打开一个游标时,
所有返回集中的数据行都将处于行级(Row-X)独占式锁定,
其他对象只能查询这些数据行,不能进行update、delete或select...for update操作。

insert / update / delete ... ; 是3的锁。

没有commit之前插入同样的一条记录会没有反应,
因为后一个3的锁会一直等待上一个3的锁, 我们必须释放掉上一个才能继续工作。

创建索引的时候也会产生3,4级别的锁。

locked_mode为2,3,4不影响DML(insert,delete,update,select)操作,
但DDL(alter,drop等)操作会提示ora-00054错误。

有主外键约束时 update / delete ... ; 可能会产生4,5的锁。

DDL语句时是6的锁。

以DBA角色, 查看当前数据库里锁的情况可以用如下SQL语句:

select object_id,session_id,locked_mode from v$locked_object;

select t2.username,t2.sid,t2.serial#,t2.logon_time
from v$locked_object t1,v$session t2
where t1.session_id=t2.sid order by t2.logon_time;

如果有长期出现的一列,可能是没有释放的锁。

我们可以用下面SQL语句杀掉长期没有释放非正常的锁: