A. 在数据库中解决死锁的常用方法有哪些
1、要求每个事务一次就将所有要使用的数据全部加锁,否则不能执行。
2、采用按序加锁法.预先规定一个封锁顺序,所有的事务都必须按这个顺序对数据执行封锁。
3、不采取任何措施来预防死锁的发生,而是周期性地检查系统中是否有死锁.如果发现死锁就设法解除。
B. 数据库死锁处理方法
mysql数据库死锁解决方法如下：
1、对于按钮等控件，点击后使其立刻失效，不让用户重复点击，避免对同时对同一条记录操作。
2、使用乐观锁进行控制。乐观锁大多是基于数据版本（Version）记录机制实现。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是 通过为数据库表增加一个“version”字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数 据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。乐观锁机制避免了长事务中的数据 库加锁开销（用户A和用户B操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现。Hibernate 在其数据访问引擎中内置了乐观锁实现。需要注意的是，由于乐观锁机制是在系统中实现，来自外部系统的用户更新操作不受系统的控制，因此可能会造 成脏数据被更新到数据库中。
C. 怎么避免死锁
什么是死锁，如何避免死锁？
线程A需要资源X，而线程B需要资源Y，而双方都掌握有对方所要的资源，这种情况称为死锁（deadlock），或死亡拥抱（the deadly embrace）。
在并发程序设计中，死锁 (deadlock) 是一种十分常见的逻辑错误。通过采用正确的编程方式，死锁的发生不难避免。
死锁的四个必要条件
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
在计算机专业的本科教材中，通常都会介绍死锁的四个必要条件。这四个条件缺一不可，或者说只要破坏了其中任何一个条件，死锁就不可能发生。我们来复习一下，这四个条件是：
互斥（Mutual exclusion）：存在这样一种资源，它在某个时刻只能被分配给一个执行绪（也称为线程）使用；
持有（Hold and wait）：当请求的资源已被占用从而导致执行绪阻塞时，资源占用者不但无需释放该资源，而且还可以继续请求更多资源；
不可剥夺（No preemption）：执行绪获得到的互斥资源不可被强行剥夺，换句话说，只有资源占用者自己才能释放资源；
环形等待（Circular wait）：若干执行绪以不同的次序获取互斥资源，从而形成环形等待的局面，想象在由多个执行绪组成的环形链中，每个执行绪都在等待下一个执行绪释放它持有的资源。
解除死锁的必要条件
不难看出，在死锁的四个必要条件中，第二、三和四项条件比较容易消除。通过引入事务机制，往往可以消除第二、三两项条件，方法是将所有上锁操作均作为事务对待，一旦开始上锁，即确保全部操作均可回退，同时通过锁管理器检测死锁，并剥夺资源（回退事务）。这种做法有时会造成较大开销，而且也需要对上锁模式进行较多改动。
消除第四项条件是比较容易且代价较低的办法。具体来说这种方法约定：上锁的顺序必须一致。具体来说，我们人为地给锁指定一种类似“水位”的方向性属性。无论已持有任何锁，该执行绪所有的上锁操作，必须按照一致的先后顺序从低到高（或从高到低）进行，且在一个系统中，只允许使用一种先后次序。
请注意，放锁的顺序并不会导致死锁。也就是说，尽管按照 锁A, 锁B, 放A, 放B 这样的顺序来进行锁操作看上去有些怪异，但是只要大家都按先A后B的顺序上锁，便不会导致死锁。
解决方法：
1 使用事务时，尽量缩短事务的逻辑处理过程，及早提交或回滚事务； (细化处理逻辑，执行一段逻辑后便回滚或者提交，然后再执行其它逻辑，直到事物执行完毕提交)
2 设置死锁超时参数为合理范围，如：3分钟-10分种；超过时间，自动放弃本次操作，避免进程悬挂；
3 优化程序，检查并避免死锁现象出现；
4 .对所有的脚本和SP都要仔细测试，在正是版本之前。
5 所有的SP都要有错误处理（通过@error）
6 一般不要修改SQL SERVER事务的默认级别。不推荐强行加锁
另外参考的解决方法：
按同一顺序访问对象
如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。例如，如果两个并发事务获得 Supplier 表上的锁，然后获得 Part 表上的锁，则在其中一个事务完成之前，另一个事务被阻塞在 Supplier 表上。第一个事务提交或回滚后，第二个事务继续进行。不发生死锁。将存储过程用于所有的数据修改可以标准化访问对象的顺序。
避免事务中的用户交互
避免编写包含用户交互的事务，因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，例如答复应用程序请求参数的提示。例如，如果事务正在等待用户输入，而用户去吃午餐了或者甚至回家过周末了，则用户将此事务挂起使之不能完成。这样将降低系统的吞吐量，因为事务持有的任何锁只有在事务提交或回滚时才会释放。即使不出现死锁的情况，访问同一资源的其它事务也会被阻塞，等待该事务完成。
保持事务简短并在一个批处理中
在同一数据库中并发执行多个需要长时间运行的事务时通常发生死锁。事务运行时间越长，其持有排它锁或更新锁的时间也就越长，从而堵塞了其它活动并可能导致死锁。保持事务在一个批处理中，可以最小化事务的网络通信往返量，减少完成事务可能的延迟并释放锁。
使用低隔离级别
确定事务是否能在更低的隔离级别上运行。执行提交读允许事务读取另一个事务已读取（未修改）的数据，而不必等待第一个事务完成。使用较低的隔离级别（例如提交读）而不使用较高的隔离级别（例如可串行读）可以缩短持有共享锁的时间，从而降低了锁定争夺。
使用绑定连接
使用绑定连接使同一应用程序所打开的两个或多个连接可以相互合作。次级连接所获得的任何锁可以象由主连接获得的锁那样持有，反之亦然，因此不会相互阻塞。
D. SQL SERVER怎样才能有效避免死锁
你可以采取以下方法将死锁减至最少：
•按同一顺序访问对象。
•避免事务中的用户交互。
•保持事务简短并处于一个批处理中。
•使用较低的隔离级别。
•使用基于行版本控制的隔离级别。
a.将 READ_COMMITTED_SNAPSHOT 数据库选项设置为 ON，使得已提交读事务使用行版本控制。
b.使用快照隔离。
•使用绑定连接。
参考链接： https://technet.microsoft.com/zh-cn/library/ms191242%28v=sql.105%29.aspx?f=255&MSPPError=-2147217396
E. 如何防止插入删除表造成的数据库死锁
当系统使用频繁就会出现插入操作和删除操作同时进行的情况。这个时候插入事务会先将主表A放置独占锁，然后去访问子表B，而同时删除事务会对子表B放置独占锁，然后去访问主表A。插入事务会一直独占着A表，等待访问B表，删除事务也一直独占着B表等待访问A表，于是两个事务相互独占一个表，等待对方释放资源，这样就造成了死锁。
遇到这种情况我听说了二种做法：1
删除A表数据之前，先使用一个事务将B表中相关外键指向另外A表中的另外一个数据（比如在A表中专门建一行数据，主键设置为0，永远不会对这行数据执行删除操作），这样就消除了要被删除的数据在AB两个表中的关系。然后就可以使用删除事务，先删除A表中的数据，再删除B表中的数据，以达到和插入事务表访问一致，避免死锁。2
在外键关系中，将“删除规则”设置为“层叠”，这样删除事务只需要直接去删除主表A，而不需要对子表B进行操作。因为删除规则设置为层叠以后，删除主表中的数据，子表中所有外键关联的数据也同时删除了。以上二个解决办法
1
多了一次更新操作，2还可以
，一般插入时不需要使用事务，删除时用cascade
插入时可能出现的数据不完整，在读取时作验证，不完整数据直接忽略，跑作业定期清理。因为无论插入时使用不使用事务，读取时都要作验证以确保数据正确性而不致程序出错，对应的定期数据清理也是必不可少的，所以并不会因为插入时不使用事务而造成过多的数据库访问。用方法2，并规范相关操作的调用，比如通过权限设定限定删除操作不会被随意执行，更大程度上避免误删。第2种做法是值得推荐的做法，虽然具有一定性能影响，但是从数据的一致性考虑，是最佳的。
察看死锁
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
order
by
ao.object_name
;
清除死锁
alter
system
kill
session
sid,.serial#
F. oracle数据库如何防止死锁问题
你好：这个死锁没办法完全避免，尽量的话在做事物提交的时候，提交完成后在进行其余的同一个表的操作，再就是insert、update等操作尽量能减少就减少。其实正常情况下是很少出现死锁的。
G. 数据库死锁怎么产生，怎样能解决
数据库操作的死锁是不可避免的，本文并不打算讨论死锁如何产生，重点在于解决死锁，通过SQL Server 2005, 现在似乎有了一种新的解决办法。
将下面的SQL语句放在两个不同的连接里面，并且在5秒内同时执行，将会发生死锁。
use Northwind
begin tran
insert into Orders(CustomerId) values(@#ALFKI@#)
waitfor delay @#00:00:05@#
select * from Orders where CustomerId = @#ALFKI@#
commit
print @#end tran@#
SQL Server对付死锁的办法是牺牲掉其中的一个，抛出异常，并且回滚事务。在SQL Server 2000，语句一旦发生异常，T-SQL将不会继续运行，上面被牺牲的连接中， print @#end tran@#语句将不会被运行，所以我们很难在SQL Server 2000的T-SQL中对死锁进行进一步的处理。
现在不同了，SQL Server 2005可以在T-SQL中对异常进行捕获，这样就给我们提供了一条处理死锁的途径：
下面利用的try ... catch来解决死锁。
SET XACT_ABORT ON
declare @r int
set @r = 1
while @r <= 3
begin
begin tran
begin try
insert into Orders(CustomerId) values(@#ALFKI@#)
waitfor delay @#00:00:05@#
select * from Orders where CustomerId = @#ALFKI@#
commit
break
end try
begin catch
rollback
waitfor delay @#00:00:03@#
set @r = @r + 1
continue
end catch
end
解决方法当然就是重试，但捕获错误是前提。rollback后面的waitfor不可少，发生冲突后需要等待一段时间，@retry数目可以调整以应付不同的要求。
但是现在又面临一个新的问题: 错误被掩盖了，一但问题发生并且超过3次，异常却不会被抛出。SQL Server 2005 有一个RaiseError语句，可以抛出异常，但却不能直接抛出原来的异常，所以需要重新定义发生的错误，现在，解决方案变成了这样:
declare @r int
set @r = 1
while @r <= 3
begin
begin tran
begin try
insert into Orders(CustomerId) values(@#ALFKI@#)
waitfor delay @#00:00:05@#
select * from Orders where CustomerId = @#ALFKI@#
commit
break
end try
begin catch
rollback
waitfor delay @#00:00:03@#
set @r = @r + 1
continue
end catch
end
if ERROR_NUMBER() <> 0
begin
declare @ErrorMessage nvarchar(4000);
declare @ErrorSeverity int;
declare @ErrorState int;
select
@ErrorMessage = ERROR_MESSAGE(),
@ErrorSeverity = ERROR_SEVERITY(),
@ErrorState = ERROR_STATE();
raiserror (@ErrorMessage,
@ErrorSeverity,
@ErrorState
);
end
我希望将来SQL Server 2005能够直接抛出原有异常，比如提供一个无参数的RaiseError。
因此方案有点臃肿，但将死锁问题封装到T-SQL中有助于明确职责，提高高层系统的清晰度。现在，对于DataAccess的代码，或许再也不需要考虑死锁问题了。
H. 昆明电脑培训分享在Java程序中处理数据库超时与死锁
每个使用关系型数据库的程序都可能遇到数据死锁或不可用的情况，而这些情况需要在代码中编程来解决;本文主要介绍与数据库事务死锁等情况相关的重试逻辑概念，此外，还会探讨如何避免死锁等问题，文章以DB2(版本9)与为例进行讲解。
什么是数据库锁定与死锁
锁定(Locking)发生在当一个事务获得对某一资源的“锁”时，这时，其他的事务就不能更改这个资源了，这种机制的存在是为了保证数据一致性;在设计与数据库交互的程序时，必须处理锁与资源不可用的情况。锁定是个比较复杂的概念，仔细说起来可能又需要一大篇，所以在本文中，只把锁定看作是一个临时事件，这意味着如果一个资源被锁定，它总会在以后某个时间被释放。而死锁发生在当多个进程访问同一数据库时，其中每个进程拥有的锁都是其他进程所需的，由此造成每个进程都无法继续下去。
如何避免锁
我们可利用事务型数据库中的隔离级别机制来避免锁的创建，正确地使用隔离级别可使程序处理更多的并发事件(如允许多个用户访问数据)，还能预防像丢失修改(Lost Update)、读“脏”数据(Dirty Read)、不可重复读(Nonrepeatable Read)及“虚”(Phantom)等问题。
隔离级别 问题现象
丢失修改 读“脏”数据 不可重复读 “虚”
可重复读取 No No No No
读取稳定性 No No No Yes
光标稳定性 No No Yes Yes
未提交的读 No Yes Yes Yes
表1：DB2的隔离级别与其对应的问题现象
在只读模式中，就可以防止锁定发生，而不用那些未提交只读隔离级别的含糊语句。昆明电脑培训http://www.kmbdqn.com/发现一条SQL语句当使用了下列命令之一时，就应该考虑只读模式了
I. GBase 8s中如何避免死锁问答
锁的问题（锁等待、死锁）大部分由于没有正确理解锁的管理、使用方式导致。要解决锁的问题，我们可以从如下几个方面进行尝试。
1．数据库锁资源的设置
ONCONFIG 参数 LOCKS 设置即为数据库配置数量合适的锁。通过搜索 online 日志是否有动态增加锁的情况：grep 'dynamically allocated' online.log为表设置合理的锁模式、行级锁或者页级锁。
2．应用程序锁使用模式设置
通过 onstat -g sql 查看 SESSION 使用的锁等待模式和隔离级别，要为不同的应用设置合理的隔离级别和锁等待模式。如在应用程序加入如下语句：
set isolation to dirty read;
set lock mode to wait 5;
3．应用程序避免使用不必要的锁
许多应用程序的 SQL 语句由于没有正确地使用索引 INDEX，导致对整个表进行了锁定，导致并发遇到锁的问题。需要通过 SQL 优化和创建合理的索引，避免顺序扫描带来的锁冲突问题。
由于顺序扫描导致的锁等待问题：创建表 test_lock，采用行级锁，并在 c1 字段上创建索引，插入 3 行测试数据。
create table test_lock (c1 int,c2 int,c3 char(10)) lock mode row;
create index idx_test_lock on test_lock(c1);
insert into test_lock values(1,1,'abc');
insert into test_lock values(2,2,'abc');
insert into test_lock values(3,3,'abc');
Session 1 通过索引扫描来修改第 2 行记录：
Begin work;
update test_lock set c3='new' where c1=2;
此时，Session 1 将在第二行记录上加 X 锁。
Session 2 通过 c2 字段以顺序扫描的方式来修改第 3 行记录。
Begin work;
update test_lock set c3='new' where c2=3;
由于 Session 2 采用顺序扫描方式，在扫描过程中发现第 2 行记录加上了 X 锁，故提示锁冲突错误：
244: Could not do a physical-order read to fetch next row.
107: ISAM error: record is locked.
如果在 c2 字段上加上索引，或者通过 c1=3 修改第三行记录，那么就不会出现锁的问题。
4．应用程序优化避免过长占用锁
锁是一个公共资源，需要尽快释放锁资源，减少等待，如果每个事务都可以在微秒级别完成，那么锁就不会是我们关注的问题，减少锁占用的时间也是解决锁问题的关键。我们可以通过避免大事务，把大事务拆分多次提交，这样锁就能尽快释放。另外，优化应用的处理性能，如合理使用索引等，都可以加快事务的处理速度，可无形中解决锁冲突的可能性。
5．设置合理的隔离级别
不同的隔离级别对锁的使用不一样，设置合理的隔离级别，可以提高应用程序的并发性，提高系统的处理能力，减少锁的冲突情况，避免读操作带来的锁问题。