数据库阻塞的条件有哪些，oracle 锁和堵塞的区别

1，oracle 锁和堵塞的区别

死锁是由于两个对象在拥有一份资源的情况下申请另一份资源，而另一份资源恰好又是这两对象正持有的，导致两对象无法完成操作，且所持资源无法释放。阻塞是由于资源不足引起的排队等待现象。

人家没提死锁，楼上的怎么都喜欢解释死锁呢？锁是oracle的一种资源，无论ddl或者dml，第一个操作的会话都会持有该对象的锁，就是为了防止并发操作导致数据混乱的。比如两个会话都要对一个字段的值做修改，肯定得分个先来后到吧，这种情况下，第一个会话持有锁，第二个会话只能申请锁，等第一个会话提交后它才能持有锁，然后才能进行修改。第二个会话在等待锁的期间，就是被阻塞状态。如果第一个会话持有锁很长时间不提交，可能会导致n多个会话都在申请该对象的锁，都被阻塞，这时很多研发人员就叫嚷：死锁啦！其实不是死锁，就是阻塞而已。

简单可以这样理解吧。（1）阻塞是由于资源不足引起的排队等待现象。（2）死锁是由于两个对象在拥有一份资源的情况下申请另一份资源，而另一份资源恰好又是这两对象正持有的，导致两对象无法完成操作，且所持资源无法释放。

oracle 锁和堵塞的区别

2，如何知道SQL Server 中哪些进程阻塞了如何阻止呢

企业管理器——数据库——管理——进程信息补充：你在进程信息里面，往右边拉，后面就有“阻塞者”和“正在阻塞”字样如果正在阻塞，那么“正在阻塞”的值就是1了

sql server 的内存管理机制是:有可用内存, 则为新需求分配内存无可用内存时, 释放内存来处理新需求.这是sql server 缓冲池的预期行为。默认情况下，在启动 sql server之后，sql server会根据操作系统报告的物理内存数来动态增大或缩小高速缓冲存储器的容量。只要可用物理内存大小保持在4mb到10mb之间，sql server 缓冲池就会继续增大（保留可用物理内存在4mb到10mb之间是为了避免操作系统因为缺少内存而频繁地换页）。如果物理可用内存变得较少的时候，则sql server会将一些内存释放给操作系统。解决方案：1.给操作系统、sql server打最新补丁2.确保不是病毒原因（可能性比较小）3.sql server设计时的要求就是最大可能的减少磁盘的i/o，磁盘i/o是比较消耗资源的，这个磁盘i/o包括了读取数据库文件还有和虚拟内存的页交换。如果还有足够的可用内存它都会毫不吝啬的使用的（没有设置上限），它会根据需要动态获取和释放内存的。你要分析的是这占用的内存开销主要用做了什么？是不是有大型的查询或事务操作。4.如果服务器是专职的数据库服务器，不建议设置最大内存上限。如果还有其它重要的服务在机器上运行，就要考虑它的内存使用是否会影响其它服务的正常的运行和性能。如果你的服务器除了sql服务, 还有其他服务需求, 则需要设置sql server的最大内存限制

如何知道SQL Server 中哪些进程阻塞了如何阻止呢

3，sqlserver存储过程会不会被阻塞

微软自sql 2008以后提供了一个图形化的活动监视器来帮助dba观察"当前的"阻塞现象. 详情请参考 (点击打开链接). dba需要关注如下的信息列去会话 id：是建立连接时分配给每个用户连接的唯一整数 (int)。等待时间(毫秒):此任务等待资源所用的时间（毫秒）。如果任务没有等待，则等待时间为 0。等待类型：最近或当前等待类型的名称。等待资源：所需资源的名称。阻塞者：如果有阻塞会话，则为正阻塞任务的会话的 id。头阻塞程序：如果有阻塞会话，则标识导致第一个阻塞条件的会话。值为 1 表示其他会话的头阻塞程序。

1：速度快、性能好。存储过程是一组已经编译过的SQL脚本，它已经进过解析、编译、优化器优化。调用存储过程可以重复使用它的缓存执行计划。这样节省了解析、分析等所需消耗的CPU资源。时间2：存储过程存储在数据库服务器，可以减少网络通信，减少网络阻塞。调用存储过程只需存储过程名字和参数，从而避免了把长串的SQL语句传送到SQL 服务器，可以大大减轻网络负担。3：业务逻辑封装，可以把相当一部分业务逻辑封装到存储过程中，当业务逻辑变更的时候，只要接口不变，只需修改存储过程内部逻辑就OK了，避免了业务逻辑放在代码层，业务逻辑变动改动大的痛苦。4：安全性参数化的存储过程可以减少SQL Injiection攻击，而且可以通过检验参数、授予对象执行权限提高了安全性。存储过程按类型分为：系统存储过程、扩展存储过程、用户存储过程(包括CLR存储过程)、临时存储过程(其中又分为全局临时存储过程、局部临时存储过程)。系统存储过程一般以SP做前缀开头。扩展存储过程一般以XP为前缀，自定义存储过程命名，我习惯以USP为前缀。

sqlserver存储过程会不会被阻塞

4，一般什么原因会造成死锁怎么解决

一般情况只发生锁超时，就是一个进程需要访问数据库表或者字段的时候，另外一个程序正在执行带锁的访问（比如修改数据），那么这个进程就会等待，当等了很久锁还没有解除的话就会锁超时，报告一个系统错误，拒绝执行相应的sql操作。发生死锁的情况比较少，比如一个进程需要访问两个资源（数据库表或者字段），当获取一个资源的时候进程就对它执行锁定，然后等待下一个资源空闲，这时候如果另外一个进程也需要两个资源，而已经获得并锁定了第二个资源，那么就会死锁，因为当前进程锁定第一个资源等待第二个资源，而另外一个进程锁定了第二个资源等待第一个资源，两个进程都永远得不到满足。

操作系统中有若干进程并发执行，它们不断申请、使用、释放系统资源，虽然系统的进程协调、通信机构会对它们进行控制，但也可能出现若干进程都相互等待对方释放资源才能继续运行，否则就阻塞的情况。此时，若不借助外界因素，谁也不能释放资源，谁也不能解除阻塞状态。根据这样的情况，操作系统中的死锁被定义为系统中两个或者多个进程无限期地等待永远不会发生的条件，系统处于停滞状态，这就是死锁。产生死锁的原因主要是：（1）因为系统资源不足。（2）进程运行推进的顺序不合适。（3）资源分配不当等。如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。产生死锁的四个必要条件：（1）互斥条件：一个资源每次只能被一个进程使用。（2）请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。（3）不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。（4）循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。死锁的解除与预防：理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和解除死锁。所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态的情况下占用资源。因此，对资源的分配要给予合理的规划

5，线程死锁怎么解决

1，互斥条件 2，请求和保持条件 3，不剥夺条件 4，环路等待条件你把其中一个条件解除了就能解决死锁这道面试题我上次去公司我就是这样回答了过了~

java中几种常见死锁及对策：解决死锁没有简单的方法，这是因为线程产生死锁都各有各的原因，而且往往具有很高的负载。大多数软件测试产生不了足够多的负载，所以不可能暴露所有的线程错误。在这里中，下面将讨论开发过程常见的4类典型的死锁和解决对策。(1)数据库死锁在数据库中，如果一个连接占用了另一个连接所需的数据库锁，则它可以阻塞另一个连接。如果两个或两个以上的连接相互阻塞，则它们都不能继续执行，这种情况称为数据库死锁。数据库死锁问题不易处理，通常数据行进行更新时，需要锁定该数据行，执行更新，然后在提交或回滚封闭事务时释放锁。由于数据库平台、配置的隔离级以及查询提示的不同，获取的锁可能是细粒度或粗粒度的，它会阻塞（或不阻塞）其他对同一数据行、表或数据库的查询。基于数据库模式，读写操作会要求遍历或更新多个索引、验证约束、执行触发器等。每个要求都会引入更多锁。此外，其他应用程序还可能正在访问同一数据库模式中的某些对象，并获取不同应用程序所具有的锁。所有这些因素综合在一起，数据库死锁几乎不可能被消除了。值得庆幸的是，数据库死锁通常是可恢复的：当数据库发现死锁时，它会强制销毁一个连接（通常是使用最少的连接），并回滚其事务。这将释放所有与已经结束的事务相关联的锁，至少允许其他连接中有一个可以获取它们正在被阻塞的锁。由于数据库具有这种典型的死锁处理行为，所以当出现数据库死锁问题时，数据库常常只能重试整个事务。当数据库连接被销毁时，会抛出可被应用程序捕获的异常，并标识为数据库死锁。如果允许死锁异常传播到初始化该事务的代码层之外，则该代码层可以启动一个新事务并重做先前所有工作。当出现问题就重试，由于数据库可以自由地获取锁，所以几乎不可能保证两个或两个以上的线程不发生数据库死锁。此方法至少能保证在出现某些数据库死锁情况时，应用程序能正常运行。(2)资源池耗尽死锁客户端的增加导致资源池耗尽死锁是由于负载而造成的，即资源池太小，而每个线程需要的资源超过了池中的可用资源。假设连接池最多有10个连接，同时有10个对外部并发调用。这些线程中每一个都需要一个数据库连接用来清空池。现在，每个线程都执行嵌套的调用。则所有线程都不能继续，但又都不放弃自己的第一个数据库连接。这样，10个线程都将被死锁。研究此类死锁，会发现线程存储中有大量等待获取资源的线程，以及同等数量的空闲且未阻塞的活动数据库连接。当应用程序死锁时，如果可以在运行时检测连接池，就能确认连接池实际上已空。修复此类死锁的方法包括：增加连接池的大小或者重构代码，以便单个线程不需要同时使用很多数据库连接。或者可以设置内部调用使用不同的连接池，即使外部调用的连接池为空，内部调用也能使用自己的连接池继续。(3)单线程、多冲突数据库连接死锁对同一线程执行嵌套的调用有时出现死锁，此情形即使在非高负载系统中通常也会发生。当第一个（外部）连接已获取第二个（内部）连接所需要的数据库锁，则第二个连接将永久阻塞第一个连接，并等待第一个连接被提交或回滚，这就出现了死锁情形。因为数据库没有注意到两个连接之间的关系，所以数据库不会将此情形检测为死锁。这样即使不存在并发，此代码也将导致死锁。此情形有多种具体的变种，可以涉及多个线程和两个以上的数据库连接。(4)java虚拟机锁与数据库锁冲突这种情形发生在数据库锁与java虚拟机锁并存的时候。在这种情况下，一个线程占有一个数据库锁并尝试获取java虚拟机锁。同时，另一个线程占有java虚拟机锁并尝试获取数据库锁。此时，数据库发现一个连接阻塞了另一个连接，但由于无法阻止连接继续，所以不会检测到死锁。java虚拟机发现同步的锁中有一个线程，并有另一个尝试进入的线程，所以即使java虚拟机能检测到死锁并对它们进行处理，它还是不会检测到这种情况。总而言之，java应用程序中的死锁是一个大问题——它能导致整个应用程序慢慢终止，还很难被分离和修复，尤其是当开发人员不熟悉如何分析死锁环境的时候。