13518219792
DML锁又可以分为，行锁、表锁、死锁
站在用户的角度思考问题，与客户深入沟通，找到西乡网站设计与西乡网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：成都网站设计、网站建设、企业官网、英文网站、手机端网站、网站推广、域名申请、虚拟空间、企业邮箱。业务覆盖西乡地区。
-行锁：当事务执行数据库插入、更新、删除操作时，该事务自动获得操作表中操作行的排它锁。
-表级锁：当事务获得行锁后，此事务也将自动获得该行的表锁(共享锁),以防止其它事务进行DDL语句影响记录行的更新。事务也可以在进行过程中获得共享锁或排它锁，只有当事务显示使用LOCK TABLE语句显示的定义一个排它锁时，事务才会获得表上的排它锁,也可使用LOCK TABLE显示的定义一个表级的共享锁(LOCK TABLE具体用法请参考相关文档)。
-死锁：当两个事务需要一组有冲突的锁，而不能将事务继续下去的话，就出现死锁。
如事务1在表A行记录#3中有一排它锁，并等待事务2在表A中记录#4中排它锁的释放，而事务2在表A记录行#4中有一排它锁，并等待事务1在表A中记录#3中排它锁的释放，事务1与事务2彼此等待，因此就造成了死锁。死锁一般是因拙劣的事务设计而产生。
死锁只能使用SQL下:alter system kill session "sid,serial#"；或者使用相关操作系统kill进程的命令，如UNIX下kill -9 sid,或者使用其它工具杀掉死锁进程。
+DDL锁又可以分为：排它DDL锁、共享DDL锁、分析锁
-排它DDL锁：创建、修改、删除一个数据库对象的DDL语句获得操作对象的 排它锁。如使用alter table语句时，为了维护数据的完成性、一致性、合法性，该事务获得一排它DDL锁。
-共享DDL锁：需在数据库对象之间建立相互依赖关系的DDL语句通常需共享获得DDL锁。
如创建一个包，该包中的过程与函数引用了不同的数据库表，当编译此包时，该事务就获得了引用表的共享DDL锁。
-分析锁：ORACLE使用共享池存储分析与优化过的SQL语句及PL/SQL程序，使运行相同语句的应用速度更快。一个在共享池中缓存的对象获得它所引用数据库对象的分析锁。分析锁是一种独特的DDL锁类型，ORACLE使用它追踪共享池对象及它所引用数据库对象之间的依赖关系。当一个事务修改或删除了共享池持有分析锁的数据库对象时，ORACLE使共享池中的对象作废，下次在引用这条SQL/PLSQL语句时，ORACLE重新分析编译此语句。
什么是死锁
当两个（或多个）用户互相等待被对方加锁的资源时就会发生死锁（deadlock）。死锁将导致相关的事务停止执行。下图演示了产生死锁的两个事务。
如图所示，在时间点 A，两个事务均获得了更新操作所需数据行上的锁，此时两事务均正常，能够继续执行。接下来，两个事务均要更新当前被对方加锁的数据。因此，在时间点 B 将发生死锁，因为此时两个事务都不能获得继续执行或终止所需的资源。无论两个事务等待多久，相互冲突的锁都无法被释放，所以此种情况被称为死锁。
图：产生死锁的两个事务
检测死锁
数据库能自动地检测死锁的情况，回滚造成死锁的某个语句，以便释放冲突的行级锁，从而解决死锁问题。数据库将向执行了语句级回滚的事务返回一个错误信息。
避免死锁
如果两个事务需要访问相同的一组表，那么在两个事务中按相同的顺序对这组表加锁通常能避免多表死锁。例如，如果系统中的一个主表及一个明细表都需要更新时，开发者应该遵从一定的规则，如先对主表加锁，再对明细表加锁。如果能够仔细设计类似的规则并严格执行，就能从根本上杜绝死锁的产生。 如果开发者预先知道需要在同一事务内对一系列资源加锁，那么应考虑首先对排他性最高的资源加锁。
关于数据库死锁的检查方法
一、数据库死锁的现象
程序在执行的过程中，点击确定或保存按钮，程序没有响应，也没有出现报错。
二、死锁的原理
当对于数据库某个表的某一列做更新或删除等操作，执行完毕后该条语句不提
交，另一条对于这一列数据做更新操作的语句在执行的时候就会处于等待状态，
此时的现象是这条语句一直在执行，但一直没有执行成功，也没有报错。
三、死锁的定位方法
通过检查数据库表，能够检查出是哪一条语句被死锁，产生死锁的机器是哪一台。
1）用dba用户执行以下语句
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）用dba用户执行以下语句，可以查看到被死锁的语句。
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))
四、死锁的解决方法
一般情况下，只要将产生死锁的语句提交就可以了，但是在实际的执行过程中。用户可
能不知道产生死锁的语句是哪一句。可以将程序关闭并重新启动就可以了。
经常在Oracle的使用过程中碰到这个问题，所以也总结了一点解决方法。
1）查找死锁的进程：
sqlplus "/as sysdba" (sys/change_on_install)
SELECT s.username,l.OBJECT_ID,l.SESSION_ID,s.SERIAL#,
l.ORACLE_USERNAME,l.OS_USER_NAME,l.PROCESS
FROM V$LOCKED_OBJECT l,V$SESSION S WHERE l.SESSION_ID=S.SID;
2）kill掉这个死锁的进程：
alter system kill session ‘sid,serial#’; （其中sid=l.session_id）
alter system kill session '710,35184'; （其中sid=l.session_id）
3）如果还不能解决：
select pro.spid from v$session ses,v$process pro where ses.sid=XX and ses.paddr=pro.addr;
其中sid用死锁的sid替换: exit
ps -ef|grep spid
其中spid是这个进程的进程号，kill掉这个Oracle进程
from:
select A.SQL_TEXT, B.USERNAME, C.OBJECT_ID, C.SESSION_ID,
B.SERIAL#, C.ORACLE_USERNAME,C.OS_USER_NAME,C.Process,
''''||C.Session_ID||','||B.SERIAL#||''''
from v$sql A, v$session B, v$locked_object C
where A.HASH_VALUE = B.SQL_HASH_VALUE and
B.SID = C.Session_ID
你好：这个死锁没办法完全避免，尽量的话在做事物提交的时候，提交完成后在进行其余的同一个表的操作，再就是insert、update等操作尽量能减少就减少。其实正常情况下是很少出现死锁的。
1、在sql语句后面加上for update可以获得行锁。
2、捕捉返回的sqlcode 和 sqlerrmc 可以得到返回值和错误信息。
---
以上，希望对你有所帮助。
查询锁表
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 获取详细信息。
这种情况叫死锁，与网络质量无关。
最大的可能就是程序的原因。
如A进程修改a表的某条记录，修改完a表后，会继续修改b表的某条记录，然后提交事务。
这个时候，B进程在修改b表的那条记录，修改完后要去修改a表的那条记录，然后提交事务。
这样，当A修改完a尚未修改b，B修改完b尚未修改a的时候，就可能出现B进程等待A进程提交事务，A进程又在等待B进程提交事务，两个进程一直在等。
所以死锁就出现了。
