数据库的并发控制

Ⅰ 为什么数据库系统要采用并发控制

并发（concurrent）和并行（parallel）这两个概念，在数据库系统的资料中经常出现，然而有关它们的定义和区别却没有明确的说法。这里，我们根据这两个概念在资料中的使用，对它们的不同做一个说明。

并发是指多个任务的同时执行，任务与任务之间没有联系。由于数据库系统要同时为许多用户提供服务，每个用户都可以发出自己的访问请求，一个请求就是一个任务。在一个时间点，数据库系统可能要同时处理多个任务。因此，数据库系统一定要具备并发处理能力。

并行是指将一个任务划分为多个子任务，这些子任务同时执行。在所有子任务处理完成后，将它们的结果进行合并，就得到该任务的最终处理结果。在数据库系统中，如果要执行一个大的数据查询，为了提高速度、降低响应时间，用户可以通过系统配置或者在命令中，要求对该大数据量查询进行并行处理，将该查询划分成多个子查询。这些子查询同时执行，最后系统将所有子查询的处理结果进行合并，作为该查询处理的最终结果。现有的大型数据库系统都支持并行处理。

需要说明的是，并发和并行与数据库系统采用多进程还是多线程体系结构无关。对采用多进程结构的数据库系统，所有的任务、子任务通过进程来处理；而对采用多线程结构的数据库系统，这些工作是由线程来完成。

数据库系统的并发控制，涉及到任务的调度、数据的一致性及可靠性等，而数据库系统的并行处理，主要涉及任务的处理速度、系统性能等方面。

Ⅱ 在数据库中为什么要并发控制并发控制技术可以保证事务的哪些特征

不并发控制的话会带来一系列问题：数据冗余、更新异常、插入异常、删除异常等
并发控制保证事务4个特性，acid：A:原子性(Atomicity) 事务是数据库的逻辑工作单位，事务中包括的诸操作要么全做，要么全不做。C:一致性(Consistency) 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。I:隔离性 (Isolation) 一个事务的执行不能被其他事务干扰。 D:持续性/永久性(Durability) 一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。

Ⅲ 在数据库中为什么要并发控制并发控制技术可以保证事务的哪些特征

不并发控制的话会带来一系列问题：数据冗余、更新异常、插入异常、删除异常等
并发控制保证事务4个特性，acid：A:原子性(Atomicity)
事务是数据库的逻辑工作单位，事务中包括的诸操作要么全做，要么全不做。C:一致性(Consistency)
事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。I:隔离性
(Isolation)
一个事务的执行不能被其他事务干扰。
D:持续性/永久性(Durability)
一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。

Ⅳ 数据库中死锁是什么产生的

数据库操作的死锁是不可避免的，本文并不打算讨论死锁如何产生，重点在于解决死锁，通过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

Ⅳ 在数据库中为什么要并发控制并发控制技术能保证事物的哪些特征

因为并发操作带来了数据的不一致性：
主要有三种：
1 丢失修改
2 不可重复读
3 读“脏”数据
并发控制保证了事务的
一致性 原子性 隔离性 持续性