数据库事务隔离级别

事务是指对系统进行的一组操作，为了保证系统的完整性，事务需要具有ACID特性如下：
1. 原子性（Atomic）
    一个事务包含多个操作，这些操作要么全部执行,要么全都不执行。实现事务的原子性，要支持回滚操作，在某个操作失败后，回滚到事务执行之前的状态。回滚实际上是一个比较高层抽象的概念，大多数DB在实现事务时，是在事务操作的数据快照上进行的（比如，MVCC），并不修改实际的数据，如果有错并不会提交，所以很自然的支持回滚。而在其他支持简单事务的系统中，不会在快照上更新，而直接操作实际数据。可以先预演一边所有要执行的操作，如果失败则这些操作不会被执行，通过这种方式很简单的实现了原子性。
2. 一致性（Consistency）
    一致性是指事务使得系统从一个一致的状态转换到另一个一致状态。事务前后，数据库的状态都满足所有的完整性约束。

3. 隔离性（Isolation）

并发事务之间互相影响的程度，比如一个事务会不会读取到另一个未提交的事务修改的数据。在事务并发操作时，可能出现的问题有：

<一>脏读：事务A修改了一个数据，但未提交，事务B读到了事务A未提交的更新结果，如果事务A提交失败，事务B读到的就是脏数据。事务A：张三妻子给张三转账100元。事务B：张三查询余额。事务A转账后（还未提交），事务B查询多了100元。事务A由于某种问题，比如超时，进行回滚。事务B查询到的数据是假数据。脏读本质上是读写操作的冲突，解决办法是写完之后再读。

<二>幻读：A事务读取了B事务已经提交的新增数据。注意和不可重复读的区别，这里是新增，不可重复读是更改（或删除）。这两种情况对策是不一样的，对于不可重复读，只需要采取行级锁防止该记录数据被更改或删除，然而对于幻读必须加表级锁，防止在这个表中新增一条数据。一个事务两次读取一个范围的记录，两次读取的记录数不一致。事务A：张三妻子两次查询张三有几张银行卡。事务B：张三新办一张银行卡。事务A第一次查询银行卡数的时候，张三还没有新办银行卡，第二次查询银行卡数的时候，张三已经新办了一张银行卡，导致两次读取的银行卡数不一样。幻象读本质上是读写操作的冲突，解决办法是读完再写。

<三>不可重复读：A事务读取了B事务已经提交的更改（或删除）数据。比如A事务第一次读取数据，然后B事务更改该数据并提交，A事务再次读取数据，两次读取的数据不一样。在不可重复读出现的原因就是事务并发修改记录，要避免这种情况，最简单的方法就是对要修改的记录加锁，这回导致锁竞争加剧，影响性能。另一种方法是通过MVCC可以在无锁的情况下，避免不可重复读。一个事务两次读取同一个数据，两次读取的数据不一致。事务A：张三妻子给张三转账100元。事务B：张三两次查询余额。事务B第一次查询余额，事务A还没有转账，第二次查询余额，事务A已经转账了，导致一个事务中，两次读取同一个数据，读取的数据不一致。不可重复读本质上是读写操作的冲突，解决办法是读完再写。

<四>第一类丢失更新:A事务撤销时，把已提交的B事务的数据覆盖掉。

<五>第二类丢失更新:A事务提交时，把已提交的B事务的数据覆盖掉。<三>的特例

事务的隔离级别从低到高有：

Read Uncommitted：最低的隔离级别，什么都不需要做，一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。

Read Committed：只有在事务提交后，其更新结果才会被其他事务看见。解决脏读问题。

Repeated Read：在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读。

Serialization：事务串行化执行，隔离级别最高，牺牲了系统的并发性。可以解决并发事务的所有问题。通常，在工程实践中，为了性能的考虑会对隔离性进行折中。

4. 持久性（Durability）事务提交后，对系统的影响是永久的

*********************************分页符*************************************

事务隔离级别：

为了解决数据库事务并发运行时的各种问题,数据库系统提供四种事务隔离级别：
1. Serializable 串行化        2. Repeatable Read 可重复读
3. Read Commited 可读已提交4. Read Uncommited 可读未提交

并发控制：

1.数据库系统采用不同的锁类型来实现以上四种隔离级别，具体的实现过程对用户是透明的。用户应该关心的是如何选择合适的隔离级别。
    2.对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed，它能够避免脏读，而且具有较好的并发性能。
    3.每个数据库连接都有一个全局变量@@tx_isolation，表示当前的事务隔离级别。JDBC数据库连接使用数据库系统默认的隔离级别。
    4.在Hibernate配置文件中可以显示地设置隔离级别。每一种隔离级别对应一个正整数。
    5.需要注意的是，在受管理环境中，如果Hibernate使用的数据库连接来自于应用服务器提供的数据源，Hibernate不会改变这些连接的事务隔离级别。在这种情况下，应该通过修改应用服务器的数据源配置来修改隔离级别。

6.当数据库系统采用Red Committed隔离级别时，会导致不可重复读和第二类丢失更新的并发问题。可以在应用程序中采用悲观锁或乐观锁来避免这类问题。

悲观锁
　　正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
　　一个典型的依赖数据库的悲观锁调用：select * from account where name=”Erica” for update这条 sql 语句锁定了 account 表中所有符合检索条件（ name=”Erica” ）的记录。本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。悲观锁，也是基于数据库的锁机制实现。
　　在Hibernate使用悲观锁十分容易，但实际应用中悲观锁是很少被使用的，因为它每次发送的SQL语句都会加上"for update"用于告诉数据库锁定相关数据，限制了并发性.
乐观锁
　　相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（Version）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个"version"字段来实现。
　　乐观锁的工作原理：读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
Hibernate为乐观锁提供了3中实现：
1. 基于version  Hibernate中通过版本号检查来实现后更新为主，这也是Hibernate推荐的方式。在数据库表中加入一个version(版本)字段，在读取数据时连同版本号一起读取，并在更新数据时比较版本号与数据库表中的版本号，如果等于数据库表中的版本号则予以更新，并递增版本号，如果小于数据库表中的版本号就抛出异常  

2. 基于timestamp

*********************************分页符*************************************

窗体顶端

在数据库访问时。如果处理并发访问的问题
或者当一个操作员对一个对象作读操作时。另一个操作员对此对象作写操作的时候
如何避免死锁发生窗体底端
/**********  加锁   ***************
设table1(A,B,C)
A    B    C
a1   b1   c1
a2   b2   c2
a3   b3   c3

1）排它锁
新建两个连接
在第一个连接中执行以下语句
begin tran
   update table1
   set A='aa'
   where B='b2'
   waitfor delay '00:00:30'  --等待30秒
commit tran
在第二个连接中执行以下语句
begin tran
   select * from table1
   where B='b2'
commit tran

若同时执行上述两个语句，则select查询必须等待update执行完毕才能执行即要等待30秒

2）共享锁
在第一个连接中执行以下语句
begin tran
   select * from table1 holdlock -holdlock人为加锁
   where B='b2'
   waitfor delay '00:00:30'  --等待30秒
commit tran

在第二个连接中执行以下语句
begin tran
   select A,C from table1
   where B='b2'
   update table1
   set A='aa'
   where B='b2'
commit tran

若同时执行上述两个语句，则第二个连接中的select查询可以执行
而update必须等待第一个连接中的共享锁结束后才能执行 即要等待30秒
3）死锁
增设table2(D,E)
D    E
d1   e1
d2   e2
在第一个连接中执行以下语句
begin tran
   update table1
   set A='aa'
   where B='b2'
   waitfor  delay '00:00:30'
   update table2
   set D='d5'
   where E='e1'
commit tran
在第二个连接中执行以下语句
begin tran
   update table2
   set D='d5'
   where E='e1'
   waitfor  delay '00:00:10'
   update table1
   set A='aa'
   where B='b2'
commit tran
同时执行，系统会检测出死锁，并中止进程
--------------------------------------------------------------
SET IMPLICIT_TRANSACTIONS  ON --用户每次必须显式提交或回滚。否则当用户断开连接时,
                              --事务及其所包含的所有数据更改将回滚

SET IMPLICIT_TRANSACTIONS  OFF --自动提交模式。在自动提交模式下，如果各个语句成功
                               --完成则提交。

---

1:如上
2: 如何锁一个表的某一行
A 连接中执行
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
begin tran
   select * from tablename with (rowlock) where id=3
   waitfor delay '00:00:05'
commit tran
B连接中如果执行
update tablename set colname='10' where id=3 --则要等待5秒
update tablename set colname='10' where id<>3 --可立即执行
2 锁定数据库的一个表
SELECT * FROM table WITH (HOLDLOCK)
注意: 锁定数据库的一个表的区别
SELECT * FROM table WITH (HOLDLOCK)
其他事务可以读取表，但不能更新删除
SELECT * FROM table WITH (TABLOCKX)
其他事务不能读取表,更新和删除
SELECT 语句中“加锁选项”的功能说明
  SQL Server提供了强大而完备的锁机制来帮助实现数据库系统的并发性和高性能。用户既能使用SQL Server的缺省设置也可以在select 语句中使用“加锁选项”来实现预期的效果。 本文介绍了SELECT语句中的各项“加锁选项”以及相应的功能说明。
  功能说明：　
  NOLOCK（不加锁）
  此选项被选中时，SQL Server 在读取或修改数据时不加任何锁。 在这种情况下，用户有可能读取到未完成事务（Uncommited Transaction）或回滚(Roll Back)中的数据, 即所谓的“脏数据”。
  HOLDLOCK（保持锁）
  此选项被选中时，SQL Server 会将此共享锁保持至整个事务结束，而不会在途中释放。
  UPDLOCK（修改锁）
  此选项被选中时，SQL Server 在读取数据时使用修改锁来代替共享锁，并将此锁保持至整个事务或命令结束。使用此选项能够保证多个进程能同时读取数据但只有该进程能修改数据。
  TABLOCK（表锁）
  此选项被选中时，SQL Server 将在整个表上置共享锁直至该命令结束。 这个选项保证其他进程只能读取而不能修改数据。
  PAGLOCK（页锁）
  此选项为默认选项， 当被选中时，SQL Server 使用共享页锁。
  TABLOCKX（排它表锁）
  此选项被选中时，SQL Server 将在整个表上置排它锁直至该命令或事务结束。这将防止其他进程读取或修改表中的数据。

---

--或者自己加锁(控制更灵活)
--锁定记录,只允许单用户修改的例子:
--创建测试环境
--创建测试表--部门表
create table 部门(departmentid int,name varchar(10))
--记录锁定表
create table lock(departmentid int,dt datetime)
go
--因为函数中不可以用getdate,所以用个视图,得到当前时间
create view v_getdate as select dt=getdate()
go
--创建自定义函数,判断记录是否锁定
create function f_chk(@departmentid int)
returns bit
as
begin
declare @re bit,@dt datetime
select @dt=dt from v_getdate
if exists(select 1 from lock where departmentid=@departmentid
and datediff(ss,dt,@dt)<5)
set @re=1
else
set @re=0
return(@re)
end
go

--数据处理测试
if dbo.f_chk(3)=1
print '记录被锁定'
else
begin
--也可以是查询
begin tran
insert into lock values(3,getdate())
update 部门 set name='A' where departmentid=3
delete from lock where departmentid=3
commit tran
end

--删除测试环境
drop table 部门
drop view v_getdate
drop function f_chk

---

如果是死锁可以查一下：

1：sp_who 或 sp_who2

2: Select * from sysprocesses where blocked <> 0

3: 企业管理器－＞服务器－＞管理工具－＞活动－＞当前活动 然后把他kill掉。。。

   进程信息中，如果发现旁边有一个锁状的图标，就表明这个进程是死锁，kill掉

4：SQL事件探查器，监控一下,看主要是那些处理引起的死锁.然后做相应的处理.

用事件探查器new一个trace，监视一下造成你sqlserver停顿的情况。。。

 

最好的办法还是检查一下引起锁的原因，一般是由你的代码引起的。

---

经过根踪调试。我发现问题如下：
1。当一个操作对一张表进行读操作的时候。这时如果另一个表进行读操作没有问题。如果
另一个操作对这个表进行写操作的时候。就会出现这样的情况。在单击保存时。会持续等。
只有另一个读操作的程序。退出读表的界面。这个就会保存成功。
2。如果把同样的环境改到我的笔记本上没有这个问题。如果再放到IBM服务器上就会出现上述所讲的问题。

现有疑问如下：
1。为何笔记本做服务（P41。8CPU。256M）没有问题。面用IBM做服务器有问题？
2。如果我把SQLCA。AUTOCOMMIT=FALSE改为SQLCA。AUTOCOMMIT=TRUE。这个问题就不存在了。但是我想这只是从表面上解决了这个问题。没有从根上解决这个问题。
3。如果是多个工作站。一台用SQLCA。AUTOCOMMIT=TRUE，另一台AUTOCOMMIT=FALSE会有问题吗。？如果我想进行ROLLBACK操作会有问题吗？
4。如果在同一个网段上有两个SQLSERVER2000服务器会有影响吗？