oracle死锁

[zhuan]今天看群里在讨论数据库死锁的问题，也一起研究了下，查了些资料在这里总结下。 所谓死锁 ： 是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。 由于资源占用是互斥的，当某个进程提出申请资源后，使得有关进程在无外力协助下，永远分配不到必需的资源而无法继续运行，这就产生了一种特殊现象死锁。 关于数据库死锁的检查方法 一、数据库死锁的现象 程序在执行的过程中，点击确定或保存按钮，程序没有响应，也没有出现报错。 二、死锁的原理 当对于数据库某个表的某一列做更新或删除等操作，执行完毕后该条语句不提 交，另一条对于这一列数据做更新操作的语句在执行的时候就会处于等待状态， 此时的现象是这条语句一直在执行，但一直没有执行成功，也没有报错。 三、死锁的定位方法 通过检查数据库表，能够检查出是哪一条语句被死锁，产生死锁的机器是哪一台。 1）用dba用户执行以下语句 select username,lockwait,status,machine,program from v$session where sid in (select session_id from v$locked_object) 如果有输出的结果，则说明有死锁，且能看到死锁的机器是哪一台

Oracle死锁查询及处理 转载 2011年08月13日 11:43:37 一、数据库死锁的现象 程序在执行的过程中，点击确定或保存按钮，程序没有响应，也没有出现报错。 二、死锁的原理 当对于数据库某个表的某一列做更新或删除等操作，执行完毕后该条语句不提 交，另一条对于这一列数据做更新操作的语句在执行的时候就会处于等待状态， 此时的现象是这条语句一直在执行，但一直没有执行成功，也没有报错。 三、死锁的定位方法 通过检查数据库表，能够检查出是哪一条语句被死锁，产生死锁的机器是哪一台。 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

前段时间提到的"sql server 2005 死锁解决探索"，死锁严重，平均每天会发生一次死锁，在解决和处理SQL server2005死锁中查了很多资料和想了很多办法， 对为何出现死锁和怎样较少死锁有了进一步认识，在这里和大家一起分享： sql server 锁类型 在数据库中主要存在两种锁: S(共享锁）和X(排他锁） S(共享锁）：在执行查询数据时，sql server会将行锁定，这时只能查询数据，删，改被阻塞， X(排他锁）：在插入和删除数据时，将行锁定，这时增，删，改都被阻塞 以上两种锁都会引起死锁： 死锁定义：在两个或多个任务中，如果每个任务锁定了其他任务试图锁定的资源，此时会造成这些任务永久阻塞，从而出现死锁 这里模拟一下死锁环境： 建立环境： ----死锁例子,建立表数据 create table [dbo].[[zping.com1]]]( A varchar(2) ,B varchar(2) ,C varchar(2)) --插入数据 insert into [dbo].[[zping.com1]]] select 'a1','b1','c1' union all select 'a2','b2','c2' union all select 'a3','b3','c3' --建立表数据 create table [dbo].[[zping.com2]]] (D

写在前面 这篇文章是在网络上看到其他作者的优秀博文，自己消化理解之后所做的记录。文章基于 MySQL 中的 InnoDB 存储引擎。 原博文地址： 点我 锁 锁知识概览 我们先看一张锁的概览图，方便后续的讲述： 我们的程序在一般情况下还是可以跑得好好的。因为这些锁数据库 隐式 帮我们加了；只在某些特定的场景下，才需要程序员手动加锁。 在执行「查询语句」 SELECT 前，会自动给涉及的所有表加「表级锁」中的 读锁 ；在执行「更新操作」 UPDATE、DELETE、INSERT 前，会自动给涉及的表加「表级锁」中的 写锁 对于 InnoDB ,且 使用了索引 的「更新操作」 UPDATE、DELETE、INSERT 语句；这时 InnoDB 会将「表锁」转换成「行锁」，也就是会自动给涉及数据集加「行级锁」中的 排他锁（X) 注意 ：InnoDB 只有通过「索引」检索数据才使用「行级锁」，否则，InnoDB将使用表锁；也就是说，InnoDB 的 行锁基于索引 。 一种特殊情况 如果我们对表中的某列加的是「普通索引」，那也就意味着： 索引列属性可能重复 。 对于普通索引，当 重复率高 时，MySQL 不会把这个普通索引当做索引，即会造成一个没有索引的SQL，从而 形成表锁 。 锁的分类 从上图中，以锁的粒度出发，我们可以看到锁分为「表级锁」和「行级锁」 『表锁』：开销小，加锁快

1、问题描述： 1.1编译存过时未响应，强行关掉编辑器后，存过死锁了 1.2表死锁，无法进行保存、修改操作 2、问题解决： -- 查询死锁的信息 select object_name,machine,s.sid,s.serial# from v$locked_object l,dba_objects o ,v$session s where l.object_id　=　o.object_id and l.session_id=s.sid; -- 删除死锁 alter system kill session 'sid,serial#'; --例子： alter system kill session '543,13103'; 来源：博客园 作者： shelly双鱼座 链接：https://www.cnblogs.com/shelly0307/p/11818461.html

锁粒度 MySQL 不同的存储引擎支持不同的锁机制，所有的存储引擎都以自己的方式显现了锁机制，服务器层完全不了解存储引擎中的锁实现： InnoDB 存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。 MyISAM 和 MEMORY 存储引擎采用的是表级锁（table-level locking） BDB 存储引擎采用的是页面锁（page-level locking），但也支持表级锁 默认情况下，表锁和行锁都是自动获得的， 不需要额外的命令。 但是在有的情况下， 用户需要明确地进行锁表或者进行事务的控制， 以便确保整个事务的完整性，这样就需要使用事务控制和锁定语句来完成。 不同粒度锁的比较 表级锁 开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。 存储引擎通过总是一次性同时获取所有需要的锁以及总是按相同的顺序获取表锁来避免死锁。 表级锁更适合于以查询为主，并发用户少，只有少量按索引条件更新数据的应用，如Web 应用 行级锁 开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。 最大程度的支持并发，同时也带来了最大的锁开销。 在 InnoDB 中，除单个 SQL 组成的事务外，锁是逐步获得的，这就决定了在 InnoDB 中发生死锁是可能的。 行级锁只在存储引擎层实现

MySQL 就是其中之一，它经历了多个版本迭代。数据库锁是 MySQL 数据引擎的一部分，今天我们就一起来学习 MySQL 的数据库锁和它的优化。 MySQL 锁分类 当多个事务或者进程访问同一个资源的时候，为了保证数据的一致性，就需要用到锁机制。 从锁定资源的角度来看，MySQL 中的锁分为： 表级锁 行级锁 页面锁 表级锁：对整张表加锁。开销小，加锁快;不会出现死锁;锁定粒度大，发生锁冲突的概率最高，并发度最低。 行级锁：对某行记录加锁。开销大，加锁慢;会出现死锁;锁定粒度最小，发生锁冲突的概率最低，并发度也最高。 页面锁：开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间，并发度一般。 在实际开发过程中，主要会使用到表级锁和行级锁两种。既然锁是针对资源的，那么这些资源就是数据，在 MySQL 提供插件式存储引擎对数据进行存储。 插件式存储引擎的好处是，开发人员可以根据需要选择适合的存储引擎。 在众多的存储引擎中，有两种引擎被比较多的使用，他们分别是： MyISAM 存储引擎，它不支持事务、表锁设计，支持全文索引，主要面向一些在线分析处理(OLAP)数据库应用。说白了主要就是查询数据，对数据的插入，更新操作比较少。 InnoDB 存储引擎，它支持事务，其设计目标主要面向在线事务处理(OLTP)的应用。 其特点是行锁设计、支持外键，并支持类似于 Oracle

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

SELECT l.session_id sid, s.serial#, l.locked_mode 锁模式, l.oracle_username 登录用户, l.os_user_name 登录机器用户名, s.machine 机器名, s.terminal 终端用户名, o.object_name 被锁对象名, to_char(s.logon_time,'yyyy-mm-dd hh24:mi:ss') 登录数据库时间 FROM v$locked_object l, all_objects o, v$session s WHERE l.object_id = o.object_id AND l.session_id = s.sid ORDER BY sid, s.serial#; alter system kill session 'sid,serial#'; --（其中sid=l.session_id） 来源： https://www.cnblogs.com/Bokeyan/p/11647513.html

最近正式系统遇到了许多莫名奇妙的问题，定时器突然不跑了，业务流程跑不通。搞得人很崩溃，今天终于找到了原因，数据库中有好多条死锁。大概有100多条。（鬼知道发生了什么）然后赶紧杀了下。下面是sql，记录一下。（需要dba权限） -----查询锁表进程 select sess.sid, sess.serial#, lo.oracle_username, lo.os_user_name, ao.object_name, lo.locked_mode from v$locked_object lo, dba_objects ao, v$session sess where ao.object_id = lo.object_id and lo.session_id = sess.sid; ------查看锁表语句 SELECT b.sid oracleID, b.username 登录Oracle用户名, b.serial#, spid 操作系统ID, paddr, sql_text 正在执行的SQL, b.machine 计算机名 FROM v$process a, v$session b, v$sqlarea c WHERE a.addr = b.paddr AND b.sql_hash_value = c.hash_value -- and b.username = 'SMS' ---