oracle死锁

锁是一种机制，一直存在；死锁是一种错误，尽量避免。​ 首先，要理解锁和死锁的概念：​ 1、锁： 定义：简单的说，锁是数据库为了保证数据的一致性而存在的一种机制，其他数据库一样有，只不过实现机制上可能大相径庭。​ 那么，锁的种类有哪些？锁的种类有很多，根据保护的对象不同，Oracle数据库锁可以分为以下几大类：DML锁（data locks，数据锁），用于保护数据的完整性；DDL锁（dictionary locks，字典锁），用于保护数据库对象的结构，如表、索引等的结构定义；内部锁和闩（internal locks and latches），保护 数据库的内部结构。​ 在实际项目中遇到的最多的是DML锁，也可进一步说是行级锁。这些行级锁在程序并发访问的时候会造成程序很慢，或者直接访问不了的情况—这种现象称为阻塞。那么，产生阻塞的原因是什么呢？定义：当一个会话保持另一个会话正在请求的资源锁定时，就会发生阻塞。被阻塞的会话将一直挂起，直到持有锁的会话放弃锁定的资源为止。四个常见的DML语句会产生阻塞： 1）INSERT 2）​UPDATE 3）DELETE ​4）SELECT…FOR UPDATE​ 2、死锁： 定义：当两个用户同时希望持有对方的资源时就会发生死锁。即当两个用户互相等待对方释放资源时，oracle认定产生了死锁，在这种情况下，将以牺牲一个用户为代价，另一个用户继续执行

参考了这篇文章： http://www.cnblogs.com/LBSer/p/5183300.html 《 mysql死锁问题分析 》 写的不错。 如果Mysql死锁，会报出： 1.1 死锁成因&&检测方法 我们mysql用的存储引擎是innodb，从日志来看，innodb主动探知到死锁，并回滚了某一苦苦等待的事务。问题来了，innodb是怎么探知死锁的？ 直观方法是在两个事务相互等待时，当一个等待时间超过设置的某一阀值时，对其中一个事务进行回滚，另一个事务就能继续执行。这种方法简单有效，在innodb中，参数innodb_lock_wait_timeout用来设置超时时间。 仅用上述方法来检测死锁太过被动，innodb还提供了 wait-for graph算法 来主动进行死锁检测，每当加锁请求无法立即满足需要并进入等待时，wait-for graph算法都会被触发。 1.2 innodb隔离级别、索引与锁 1.2.1 锁与索引的关系 假设我们有一张消息表（msg），里面有3个字段。假设id是主键，token是非唯一索引，message没有索引。 id: bigint token: varchar(30) message: varchar(4096) innodb对于主键使用了 聚簇索引 ，这是一种数据存储方式，表数据是和主键一起存储，主键索引的叶结点存储行数据。对于普通索引

先查看哪些表被锁住了 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; OWNER OBJECT_NAME SESSION_ID LOCKED_MODE ------------------------------ -------------------------------------- ------- WSSB SBDA_PSHPFTDT 22 3 WSSB_RTREPOS WB_RT_SERVICE_QUEUE_TAB 24 2 WSSB_RTREPOS WB_RT_NOTIFY_QUEUE_TAB 29 2 WSSB_RTREPOS WB_RT_NOTIFY_QUEUE_TAB 39 2 WSSB SBDA_PSDBDT 47 3 WSSB_RTREPOS WB_RT_AUDIT_DETAIL 47 3 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;

先查看哪些表被锁住了 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; OWNER OBJECT_NAME SESSION_ID LOCKED_MODE ------------------------------ -------------------------------------- ------- WSSB SBDA_PSHPFTDT 22 3 WSSB_RTREPOS WB_RT_SERVICE_QUEUE_TAB 24 2 WSSB_RTREPOS WB_RT_NOTIFY_QUEUE_TAB 29 2 WSSB_RTREPOS WB_RT_NOTIFY_QUEUE_TAB 39 2 WSSB SBDA_PSDBDT 47 3 WSSB_RTREPOS WB_RT_AUDIT_DETAIL 47 3 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;

方法一： １.查哪个过程被 锁 查V$DB_OBJECT_CACHE视图: SELECT * FROM V$DB_OBJECT_CACHE WHERE OWNER = ' 过程的所属用户 ' AND LOCKS != ' 0 ' ; 2. 查是哪一个SID,通过SID可知道是哪个SESSION. 查V$ACCESS视图: SELECT * FROM V$ACCESS WHERE OWNER = ' 过程的所属用户 ' AND NAME = ' 刚才查到的过程名 ' ; 3. 查出SID和SERIAL# 查V$SESSION视图: SELECT SID,SERIAL#,PADDR FROM V$SESSION WHERE SID = ' 刚才查到的SID ' 查V$PROCESS视图: SELECT SPID FROM V$PROCESS WHERE ADDR = ' 刚才查到的PADDR ' ; 4. 杀进程 (1).先杀 ORACLE 进程: ALTER SYSTEM KILL SESSION ' 查出的SID,查出的SERIAL# ' ; (2).再杀操作系统进程: KILL - 9 刚才查出的SPID 或 ORAKILL 刚才查出的SID 刚才查出的SPID 方法二： 1 ） 查找 死 锁 的进程： SELECT s.username,l. OBJECT_ID ,l

先查看哪些表被锁住了 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; OWNER OBJECT_NAME SESSION_ID LOCKED_MODE ------------------------------ -------------------------------------- ------- WSSB SBDA_PSHPFTDT 22 3 WSSB_RTREPOS WB_RT_SERVICE_QUEUE_TAB 24 2 WSSB_RTREPOS WB_RT_NOTIFY_QUEUE_TAB 29 2 WSSB_RTREPOS WB_RT_NOTIFY_QUEUE_TAB 39 2 WSSB SBDA_PSDBDT 47 3 WSSB_RTREPOS WB_RT_AUDIT_DETAIL 47 3 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;

目前，我们已经探讨了许多关于数据库锁的问题，锁能够有效地解决并发的问题，但这也带来了一个严重的缺点，那就是死锁。 死锁在操作系统中指的是两个或两个以上的进程在执行的过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或者系统产生了死锁，这些永远在互相等待的进程称为死锁进程。 在操作系统中，死锁的处理是一个重要的话题，也已经有较为成熟的解决方法，如银行家算法等，在这边我们就不再阐述，只讨论数据库中的死锁。 数据库中常见的死锁原因与解决方案有： 1. 事务之间对资源访问顺序的交替 出现原因： 一个用户A 访问表A（锁住了表A），然后又访问表B；另一个用户B 访问表B（锁住了表B），然后企图访问表A；这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B才能继续，同样用户B要等用户A释放表A才能继续，这就死锁就产生了。 解决方法： 这种死锁比较常见，是由于程序的BUG产生的，除了调整的程序的逻辑没有其它的办法。仔细分析程序的逻辑，对于数据库的多表操作时，尽量按照相同的顺序进行处理，尽量避免同时锁定两个资源，如操作A和B两张表时，总是按先A后B的顺序处理， 必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源 2. 并发修改同一记录 出现原因：主要是由于没有一次性申请够权限的锁导致的。参考： 记录一次死锁排查过程

在联机事务处理(OLTP)的数据库应用系统中，多用户、多任务的并发性是系统最重要的技术指标之一。为了提高并发性，目前大部分RDBMS都采用加锁技术。然而由于现实环境的复杂性，使用加锁技术又不可避免地产生了死锁问题。因此如何合理有效地使用加锁技术，最小化死锁是开发联机事务处理系统的关键。 死锁产生的原因 在联机事务处理系统中，造成死机主要有两方面原因。一方面，由于多用户、多任务的并发性和事务的完整性要求，当多个事务处理对多个资源同时访问时，若双方已锁定一部分资源但也都需要对方已锁定的资源时，无法在有限的时间内完全获得所需的资源，就会处于无限的等待状态，从而造成其对资源需求的死锁。 另一方面，数据库本身加锁机制的实现方法不同，各数据库系统也会产生其特殊的死锁情况。如在Sybase SQL Server 11中，最小锁为2K一页的加锁方法，而非行级锁。如果某张表的记录数少且记录的长度较短(即记录密度高，如应用系统中的系统配置表或系统参数表就属于此类表)，被访问的频率高，就容易在该页上产生死锁。 容易发生死锁的几种情况如下: 1>不同的存储过程、触发器、动态SQL语句段按照不同的顺序同时访问多张表; 2>在交换期间添加记录频繁的表，但在该表上使用了非群集索引(non-clustered); 3>表中的记录少，且单条记录较短，被访问的频率较高； 4>整张表被访问的频率高(如代码对照表的查询等

1. 什么是数据库事务 1.1 数据库事务是指作为单个逻辑工作单元执行的一系列操作（SQL语句）。这些操作要么全部执行，要么全部不执行。 1.2 通过ACID实现数据库事务模型 1.2.1 原子性(Atomicity)：事务是数据库的逻辑工作单位，它对数据库的修改要么全部执行，要么全部不执行。 1.2.2 一致性(Consistemcy)：事务执行前后，数据库的状态都满足所有的完整性约束。 1.2.3 隔离性(Isolation)：并发执行的事务是隔离的，保证多个事务互不影响。如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。通过设置数据库的隔离级别，可以达到不同的隔离效果。 1.2.4 持久性(Durability)：一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。 1.3 事务运行的三种模式 1.3.1 自动提交事务：默认事务管理模式。如果一个语句成功地完成，则提交该语句；如果遇到错误，则回滚该语句。 1.3.2 显式事务：以BEGIN TRANSACTION显式开始，以COMMIT或ROLLBACK显式结束。 1.3.3 隐性事务：当连接以此模式进行操作时

转自： http://blog.csdn.net/missmecn/archive/2008/10/06/3019798.aspx 相关文章: my sql 数据库锁 ORACLE里几种锁模式 推荐圈子: Pipboy 更多相关推荐 对 锁机制 的研究要具备两个条件： 1．数据量大 2．多个用户同时并发 如果缺少这两个条件，数据库不容易产生死锁问题。研究起来可能会事倍功半。如果这两个条件都有，但你还是按数据库缺省设置来处理数据，则会带来很多的问题，比如： 1）丢失更新 A,B两个用户读同一数据并进行修改,其中一个用户的修改结果破坏了另一个修改的结果 2）脏读 A用户修改了数据时,B用户也在读该数据,但A用户因为某些原因取消了对数据的修改,数据恢复原值,此时B得到的数据就与数据库内的数据产生了不一致 3）不可重复读 B用户读出该数据并修改,同时，A用户也在读取数据，此时A用户再读取数据时发现前后两次的值不一致 SQL SERVER 作为多用户数据库系统，以事务为单位，使用锁来实现并发控制。 SQL SERVER 使用“锁”确保事务完整性和数据一致性。 一、锁的概念 锁（LOCKING）是最常用的并发控制机构。是防止其他事务访问指定的资源控制、实现并发控制的一种主要手段。锁是事务对某个数据库中的资源（如表和记录）存取前，先向系统提出请求，封锁该资源，事务获得锁后，即取得对数据的控制权