ORACLE里锁有以下几种模式:
0：none
1：null 空
2：Row-S 行共享(RS)：共享表锁，sub share
3：Row-X 行独占(RX)：用于行的修改，sub exclusive
4：Share 共享锁(S)：阻止其他DML操作，share
5：S/Row-X 共享行独占(SRX)：阻止其他事务操作，share/sub exclusive
6：exclusive 独占(X)：独立访问使用，exclusive
数字越大锁级别越高, 影响的操作越多。
1级锁有：Select，有时会在v$locked_object出现。
2级锁有：Select for update,Lock For Update,Lock Row Share
select for update当对话使用for update子串打开一个游标时，所有返回集中的数据行都将处于行级(Row-X)独占式锁定，其他对象只能查询这些数据行，不能进行update、delete或select for update操作。
3级锁有：Insert, Update, Delete, Lock Row Exclusive
没有commit之前插入同样的一条记录会没有反应, 因为后一个3的锁会一直等待上一个3的锁, 我们必须释放掉上一个才能继续工作。
4级锁有：Create Index, Lock Share
locked_mode为2,3,4不影响DML(insert,delete,update,select)操作, 但DDL(alter,drop等)操作会提示ora-00054错误。
00054, 00000, "resource busy and acquire with NOWAIT specified"
// *Cause: Resource interested is busy.
// *Action: Retry if necessary.
5级锁有：Lock Share Row Exclusive
具体来讲有主外键约束时update / delete ... ; 可能会产生4,5的锁。
6级锁有：Alter table, Drop table, Drop Index, Truncate table, Lock Exclusive
以DBA角色, 查看当前数据库里锁的情况可以用如下SQL语句：
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进程并不能彻底清除锁的问题。
| crazybaw 回复于：2003-09-22 19:09:57 |
这种操作只适合有用户会话的，假设在USERNAME字段中是空的呢，这样做的时候ORACLE会报错，提示“会话不是用户会话”，请问该如何处理
操作和结果如下：
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
结果：
username为空 ，sid为5， serial#为1， logon_time为一3天前的时间
，然后执行alter system kill session '5,1#'; ORACLE报错，提示“会话不是用户会话”，无法删除。
|
crazybaw 回复于：2003-09-22 19:16:46 |
请问我执行查询：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
得到的结果如下：
owner=SYS，OBJECT_NAME=FET$,SESSION_ID,LOCKED_MODE=3，请问该如何处理？字段OBJECT_NAME=FET$和LOCKED_MODE=3表示什么？LOCKED_MODE=3是否表示Row-X 行独占(RX)：用于行的修改，sub exclusive？
|
rollingpig 回复于：2003-09-23 08:54:49 |
alter system kill session '5,1';
|
wxx 回复于：2003-09-23 10:41:35 |
这种问题在Oracle8i中会比较常遇到，特别是在本地网计费项目中，因为当时Oracle狂推OPS，但是许多集成商的OPS的使用能力实在有限，所以常常会因为OPS导致许多问题，特别是在销账高峰期常常会出问题：数据库被挂死，一个节点的Instance出问题，另外一个也就被挂死了。 这些问题的解决关键要设置好OPS的相关参数，以及相关库表的存储参数才能解决问题，而且在销账高峰期要尽量避免想其他的大事务操作，否则因为都要操作数据字典也会带来一些问题。
|
crazybaw 回复于：2003-09-23 11:24:02 |
[quote:1a0cf9cf18="rollingpig"]alter system kill session '5,1';[/quote:1a0cf9cf18]
呵呵，我用的就是alter system kill session '5,1'，只不过在上面的帖子手误而已。
|
crazybaw 回复于：2003-09-23 11:30:38 |
[quote:da7fe0de27="wxx"]这种问题在Oracle8i中会比较常遇到，特别是在本地网计费项目中，因为当时Oracle狂推OPS，但是许多集成商的OPS的使用能力实在有限，所以常常会因为OPS导致许多问题，特别是在销账高峰期常常会出问题：数据库被挂死，?.........[/quote:da7fe0de27]
出现该情况的条件很多，电信上面的确暴露的比较明显
|
rollingpig 回复于：2003-09-23 11:30:58 |
呵呵
那就郁闷了
|
peterking 回复于：2003-09-23 11:48:20 |
交易通过CICS调用ORACLE的，一般不应该直接kill session。应该找出session 对应的process id，在操作系统中kill -9 pid，锁可以自动释放。
|
zhaoyang 回复于：2003-09-26 21:50:15 |
|
flysnowpp 回复于：2003-09-27 09:36:23 |
用9i的RAC就好多了，锁的问题解决了不少。
[quote:5e5ba27208="wxx"]这种问题在Oracle8i中会比较常遇到，特别是在本地网计费项目中，因为当时Oracle狂推OPS，但是许多集成商的OPS的使用能力实在有限，所以常常会因为OPS导致许多问题，特别是在销账高峰期常常会出问题：数据库被挂死，?.........[/quote:5e5ba27208]
| |
转自http://www.dbonline.cn/source/oracle/20031217/BACKUP_unsafe%20factor%20and%20illuminate%20of%20oracle8i.html
作为对象关系型数据库的杰出代表，Oracle无疑是最具实力的。无论是在数据库的规模，多媒体数据类型的支持，SQL操作复制的并行性还是在安全服务方面，Oracle均比SYBASE、Informix强许多，加上其最新版本Oracle8.0.4更是增强了这方面的特性，而且还引入了一些新的特性，比如：数据分区(Data Partitioning)、对象关系技术(Object Relational Technology)、唯索引表(Index only tables)、连接管理器(Connection Manager)[NET8特性]、高级队列(Advanced Quening)等，所以有一种说法：Oracle8是适用于如Peoplesoft，SAP和Baan等封装式应用系统最好的数据库引擎。
虽然Oracle8有许多的优点，但正如微软的WINDOWS系统也会死机一样，任何再好的软件也有他的缺陷，一个优秀的软件不可能就是十全十美，他只是避免了大多数常见的或者可能被考虑到的问题，而一些不容易被发现却非常致命的问题往往会被疏忽掉。Oracle8也同样存在着不安全的因素，许多正在想尽快升级到Oracle8的Oracle7.1、Oracle7.2、Oracle7.3用户不能不考虑到这个因素。当然，这个不安全因素并不是一下子就发现的，而是我们在对一个非常庞大的表进行管理时发现的，这种隐患在使用Oracle创建的小型或者中型数据库中可能不会出现或根本无法发现，因为Oracle8独有的特性已经将这种隐患降低到最低的程度，你大可放心你的数据库系统的安全。
问题
我们安装的Oracle8数据库是工作于主机-终端方式下的，系统主机采用的是四台HP-9000小型机、1.5G的内存。建库初期时设定的最大事务数是按Oracle8的默认取值[这也是Oracle7的默认取值]取的：块值为2K，事务数为32（对于一个要处理非常庞大的数据库时，一般我们设定的块值要大于2K，至少应为4K或者16K，当然这还与主机的CPU能力和I/0能力值有关），并在建库时没有进行分区建表，这也许就为以后数据库出问题留下了隐患。由于日访问数据库的用户非常多，而且对同一表操作的用户数量太大，致使那个表经常被锁住，不断有用户抱怨他们进不了系统，主机发送的数据包太慢，经常报ORA-600的错误。起初我们以为是系统网络问题，但这种可能性比较小，因为我们发现系统CPU峰值经常在90%多，空闲很小，数据库资源太忙，同时有十多个人锁住一个大表进行操作，自然一部分用户就无法进入系统，对此我们写了如下的SQL语句对锁表用户进行监控：
SELECT OBJECT_ID,SESSION_ID,SERIAL#,
ORACLE_USERNAME,OS_USER_NAME,S.PROCESS
FROM V$LOCKED_OBJECT A,
V$SESSION S WHERE A.SESSION_ID=S.SID;
也许有的人会问为什么不用如下的SQL语句进行查询：
SELECT a.username,a.sid,a.serial#,b.id1,
c.sql_text from v$session a,
V$lock b,v$sqltext c where a.lockwait=b.kaddr and
a. sql_address=c.address and a.sql_hash_value=c.hash_value;
以上两个SQL语句都会查询返回当前被锁住的用户列表，但第二个SQL语句由于加入了sql_text从而使这个查询变得非常的慢长，特别是在有许多用户同时对数据库进行操作时，建议不用，第一个SQL 语句会在很短的时间内查询出是谁在锁表，从而有利于对数据库的管理，一但有用户进入不了，我们就马上杀死其锁进程[SID，SERIAL#]，SQL语句如下：ALTER SYSTEM KILL SESSION ‘SID，SERIAL#'，但这并不是解决问题的根本方法，只能暂时缓解一下；另外我们还发现回滚段时常有“online”与“offline”的现象，于是我们又考虑是否是回滚段引起的问题：因为我们一但对大的回滚段进行操作，马上就会有用户反映无法进入。我们知道回退段的大小直接依赖于数据库的活动状态，而每一个EXTENTS都应具有相同的值（Oracle的推荐）[INITIAL EXTENTS的值可以从2K（32）、4K（69）、8K（142）、16K、32K等列表中选择]，这将保证你删掉一个区的时候，你可以重新使用它的空间而不会造成浪费，另外MINEXTENTS应设为20，这将不会使回退段扩展另一个EXTENT时用到正在被活动的事务所使用的空间，因而我们就可以据此来确定回退段大小，查出数据库正常运行时所需回滚段的尺寸,为此我们重新设置了回退段的OPTIMAL参数[事实是OPTIMAL的值并不足引起数据库出错]，增大了OPTIMAL的值，使用命令SET TRANSACTION USE ROLLBACK SEGMENT为系统指定了一个大的回退段[注意OPTIMAL参数要足够大以使ORACLE不需经常回缩和重新分配EXTENTS，如果设得小于最小覆盖值，性能将由于额外的段重设置而下降，对于一个要执行长查询的系统，OPTIMAL应设成足够大以避免ORA-1555，“Smapshot too old”的错误，而对于运行小的事务，OPTIMAL应设得小一些，使回退段足够小以便放于内存中，这将提高系统性能。]，但我们发现这样做后，ORA-600的错误依然出现，而且锁表越来越严重；我们又考虑暂时锁住这个表，不让用户进入，先把用户的锁进程全部杀完再看，由于一开始就采用了主机-终端的工作方式，因而根本就无法清除得完，除非断掉外部的所有网络连接，但那样无疑是重启数据库，最终我们选择了重启数据库。
重启数据库后系统资源一下子得以释放，用户明显感觉速度上来了，能够保证正常使用，就在我们认为系统可能是因为长期没有DOWN机，用户登录数过多造成数据库死锁的时候，一个非常严重的问题出现了，那个表中的一个数据无法进行UPDATE，一UPDATE就报ORACLE内部代码错误，当时我们并没在意，但是不久，我们又发现另一表中编号有重复的现象，根据ORACLE8的数据唯索引表性，这种现象应该根本不会存在，因为我们在这个表中只建立了唯一索引，于是我们电话询问ORACLE公司的技术工程师，也许ORACLE的技术工程师们也是第一次遇到这种问题，他们的回答是数据字典太老，数据索引坏掉，建议重建索引，并把问题向亚太反映。在ORACLE公司的技术工程师的指导下，我们重建了该表，并重新建立了索引，在重建索引过程中，开始几次都不成功，而且无法DROP掉先前的表，经过仔细的查找，我们发现ORACLE8中的确有索引重复的现象，一个表中有两条重复的索引，直接导致数据库HANG，不能访问，但查看系统状态、进程、LISTENER却都正常，从日志文件来看，文件过小（7MB），CHECK POINT频繁，影响到了系统的性能，通过以上调整后，数据库问题暂时缓解了，可以做UPDATE，但是ORACLE的内部代码错误却依然存在，只是暂时还不会影响到我们对数据库的使用，而回滚段开始出现“online rollback segment”的问题，更加令人不解的是数据库居然出现了自动DOWN机的现象，于是我们再次询问ORACLE公司的技术工程师，他们的答复是ORACLE已经注意到了ORACLE8.0.4版本的一些问题，他们将会给数据库打PATCH，希望能够解决到这些问题，但是考虑到给数据库打一个PATCH，将会把所有的数据都要EXPORT出来，这将是一个非常危险的操作，而且所有主机上的程序都要重新编译一到，没有一个星期的时间是无法做好的，而那是根本不可能的事情，因而我们现在还在等待ORACLE公司一个更好的解决办法。
说明
以上问题可能是ORACLE的一个BUG，但任何软件都有它不完善的一面，否则又何必出什么补丁了，有了补丁肯定会比没有补丁强，但是我们在设计一个系统时也一定要考虑到以下的一些方面：
1、 主机系统的CPU能力与I/0能力：HP偏重于I/0能力，CPU能力不强，你的数据库就应该尽量避免让CPU占用率太大；DEC偏重于CPU能力，I/0能力不强，你的数据库就可以考虑适当增大某些占用CPU参数的设置；SUN的CPU能力与I/0能力差不多，你的数据库就应该考虑平衡参数，过大过小都不好。
2、 增大日志文件的SIZE，至少不会低于8MB，日志文件过小会导致CHECK POINT频繁，从而影响到系统的性能。
3、 回滚段最好保持一个比较合理的值，对一些较大的回滚段可适当增加MINEXTENTS，并设置OPTIMAL，保证一般事物处理无需经常动态分配空间与及时回收空间。
4、 要充分利用CPU系统资源及提高CPU的命中率，可适当增大log_simultaneous_copies,db_block_latches,db_writes的设置。
5、 适当增加db_block_buffera与share_pool_size的SIZE，以提高BUFFER值，增加内存，尽快提高BUFF及SQL的命中率。
6、 主机-终端方式尽管可以便于数据维持，但主机-终端方式却造成主机负荷太重，建议采用客户-服务端方式建系统。
怎样快速查出Oracle 数据库中的锁等待
时间: 2004-05-31
摘自《计算机世界日报》(文/赵华良)
---- 在大型数据库系统中，为了保证数据的一致性，在对数据库中的数据进行操作时，系统会进行对数据相应的锁定。
---- 这些锁定中有"只读锁"、"排它锁"，"共享排它锁"等多种类型，而且每种类型又有"行级锁"（一次锁住一条记录），"页级锁"（一次锁住一页，即数据库中存储记录的最小可分配单元），"表级锁"（锁住整个表）。
---- 若为"行级排它锁"，则除被锁住的该行外，该表中其它行均可被其它的用户进行修改(Update)或删除(delete)操作，若为"表级排它锁"，则所有其它用户只能对该表进行查询(select)操作，而无法对其中的任何记录进行修改或删除。当程序对所做的修改进行提交(commit)或回滚后(rollback)后，锁住的资源便会得到释放，从而允许其它用户进行操作。
---- 但是，有时，由于程序中的原因，锁住资源后长时间未对其工作进行提交；或是由于用户的原因，如调出需要修改的数据后，未及时修改并提交，而是放置于一旁；或是由于客户服务器方式中客户端出现"死机"，而服务器端却并未检测到，从而造成锁定的资源未被及时释放，影响到其它用户的操作。
---- 因而，如何迅速地诊断出锁住资源的用户以及解决其锁定便是数据库管理员的一个挑战。
---- 由于数据库应用系统越来越复杂， 一旦出现由于锁资源未及时释放的情况，便会引起对一相同表进行操作的大量用户无法进行操作，从而影响到系统的使用。此时，DBA应尽量快地解决问题。但是，由于在Oracle 8.0.x 中执行"获取正在等待锁资源的用户名"的查询语句
select a.username, a.sid, a.serial#, b.id1
from v$session a, v$lock b
where a.lockwait = b.kaddr
---- 十分缓慢，（在 Oracle 7.3.4中执行很快)，而且，执行"查找阻塞其它用户的用户进程"的查询语句
select a.username, a.sid, a.serial#, b.id1
from v$session a, v$lock b
where b.id1 in
(select distinct e.id1
from v$session d, v$lock e
where d.lockwait = e.kaddr)
and a.sid = b.sid
and b.request = 0
---- 执行得也十分缓慢。因而，往往只好通过将 v$session 中状态为"inactive"（不活动）并且最后一次进行操作时间至当前已超过 20 分钟以上(last_call_et>20*60 秒)的用户进程清除，然后才使得问题得到解决。
---- 但是，这种方法实际上是"把婴儿与脏水一起泼掉"。因为，有些用户的进程尽管也为"inactive"，并且也已有较长时间未活动，但是，那是由于他们处于锁等待状态。
---- 因而，我想出了一个解决办法。即通过将问题发生时的 v$lock，v$session视图中的相关记录保存于自己建立的表中，再对该表进行查询，则速度大大提高，可以迅速发现问题。经实际使用，效果非常好。在接到用户反映后，几秒钟即可查出由于锁住资源而影响其它用户的进程，并进行相应的处理。
---- 首先，以 dba 身份（不一定为system）登录入数据库中，创建三个基本表:my_session，my_lock, my_sqltext，并在将会进行查询的列上建立相应的索引。语句如下： rem 从 v$session 视图中取出关心的字段，创建 my_session 表,并在查询要用到的字段上创建索引，以加快查询速度
drop table my_session;
create table my_session
as
select a.username, a.sid, a.serial#,
a.lockwait, a.machine,a.status,
a.last_call_et,a.sql_hash_value,a.program
from v$session a
where 1=2 ;
create unique index my_session_u1 on my_session(sid);
create index my_session_n2 on my_session(lockwait);
create index my_session_n3 on my_session(sql_hash_value);
---- rem 从 v$lock 视图中取出字段，创建 my_lock 表，并在查询要用到的字段上创建索引，以加快查询速度
drop table my_lock;
create table my_lock
as
select id1, kaddr, sid, request,type
from v$lock
where 1=2;
create index my_lock_n1 on my_lock(sid);
create index my_lock_n2 on my_lock(kaddr);
---- rem 从 v$sqltext 视图中取出字段，创建 my_sqltext 表，并在查询要用到的字段上创建索引，以加快查询速度
drop table my_sqltext;
create table my_sqltext
as
select hash_value , sql_text
from v$sqltext
where 1=2;
create index my_sqltext_n1 on my_sqltext ( hash_value);
---- 然后，创建一个 SQL 脚本文件，以便需要时可从 SQL*Plus 中直接调用。其中，首先用 truncate table 表名命令将表中的记录删除。之所以用 truncate 命令，而不是用delete 命令，是因为delete 命令执行时，将会产生重演记录，速度较慢，而且索引所占的空间并未真正释放，若反复做 insert及delete,则索引所占的空间会不断增长，查询速度也会变慢。而 truncate命令不产生重演记录，速度执行较delete快，而且索引空间被相应地释放出来。删除记录后，再将三个视图中的相关记录插入自己创建的三个表中。最后，对其进行查询，由于有索引，同时由于在插入时条件过滤后，记录数相对来说较少，因而查询速度很快，马上可以看到其结果。
---- 此时，若发现该阻塞其它用户进程的进程是正常操作中，则可通知该用户对其进行提交，从而达到释放锁资源的目的；若为未正常操作，即，其状态为"inactive"，且其last_call_et已为较多长时间，则可执行以下语句将该进程进行清除，系统会自动对其进行回滚，从而释放锁住的资源。
alter system kill session 'sid, serial#';
---- SQL 脚本如下：
set echo off
set feedback off
prompt '删除旧记录.....'
truncate table my_session;
truncate table my_lock;
truncate table my_sqltext;
prompt '获取数据.....'
insert into my_session
select a.username, a.sid, a.serial#,
a.lockwait, a.machine,a.status,
a.last_call_et,a.sql_hash_value,a.program
from v$session a
where nvl(a.username,'NULL')< >'NULL;
insert into my_lock
select id1, kaddr, sid, request,type
from v$lock;
insert into my_sqltext
select hash_value , sql_text
from v$sqltext s, my_session m
where s.hash_value=m.sql_hash_value;
column username format a10
column machine format a15
column last_call_et format 99999 heading "Seconds"
column sid format 9999
prompt "正在等待别人的用户"
select a.sid, a.serial#,
a.machine,a.last_call_et, a.username, b.id1
from my_session a, my_lock b
where a.lockwait = b.kaddr;
prompt "被等待的用户"
select a.sid, a.serial#,
a. machine, a.last_call_et,a.username,
b. b.type,a.status,b.id1
from my_session a, my_lock b
where b.id1 in
(select distinct e.id1
from my_session d, my_lock e
where d.lockwait = e.kaddr)
and a.sid = b.sid
and b.request=0;
prompt "查出其 sql "
select a.username, a.sid, a.serial#,
b.id1, b.type, c.sql_text
from my_session a, my_lock b, my_sqltext c
where b.id1 in
(select distinct e.id1
from my_session d, my_lock e
where d.lockwait = e.kaddr)
and a.sid = b.sid
and b.request=0
and c.hash_value =a.sql_hash_value;
---- 以上思路也可用于其它大型数据库系统如 Informix, Sybase,DB2中。通过使用该脚本，可以极大地提高获取系统中当前锁等待的情况，从而及时解决数据库应用系统中的锁等待问题。而且，由于实际上已取出其 program 名及相应的 sql 语句，故可以在事后将其记录下来，交给其开发人员进行分析并从根本上得到解决。