SQL Server 2005 如何实现ACID事务机制

爱是王道

当我一个运行很长的事务，在事务提交以完后，突然断电了，这时长事务里肯定有没有处理的语句，面对这样情况，一部分已经处理完了，一部还没来得及处理的情况，SQL Server 2005 数据库是如何保证事务的持久性和一致性？　　
　　以上的情况，查一般的SQL Server 2005资料是很难有答案的，这段时间在学Oracle时，了解了其事务是如何保证事务的acid ,后来在SQL Server 2005测试了一下。数据库的事务机制都有点类似。以下是SQL Server 2005测试例子。
　　建立测试表：   
　　

CREATE TABLE [dbo].[[zping.com]]](
    [id] [varchar](32) NOT NULL,
    [content] varchar(20) null,
    [flag] [int] NULL
) 　　
　　插入测试数据：   

insert into [dbo].[[zping.com]]](id,flag)
select replace(newid(),'-',''),2
union
select replace(newid(),'-',''),1
union
select replace(newid(),'-',''),1　　查看数据: select * from dbo.[[zping.com]]]   
　　

id                                                     content    flag
45BB5807C9B74A48A6600260FDFE6323    NULL       1
8380DB764CCA4A398A4DFC948585BF70    NULL      1
BDDBB3446E884540A57D94D1B1A42135    NULL      2　　执行以下语句:   

begin tran
  update dbo.[[zping.com]]] set content='zping.com' where flag=1　　
　　打开新窗口执行以下语句:
　　

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
select * from dbo.[[zping.com]]]　　结果如下：

id                                                      content             flag
45BB5807C9B74A48A6600260FDFE6323    zping.com           1
8380DB764CCA4A398A4DFC948585BF70    zping.com          1
BDDBB3446E884540A57D94D1B1A42135    NULL                  2　　
　　这里我们设置未提交读，我们可以看到脏数据，其实事务还没有提交。
　　这时我们重启SQL server 2005数据库，在查询数据：

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
select * from dbo.[[zping.com]]]　　发现数据是更新之前的数据。原来数据在启动时候时自动将未提交的事务回滚掉。
　　   
　　   SQL server 是如何保证ACID：
　　    1,事务正在运行，还未提交：
　　        这时突然断电，下次数据库重启后，自动回滚未提交的事务。
　　    2，事务已经提交，但没执行完（事务比较长）
　　        这时突然断电，数据库在下次启动时，会通过事务日志来继续执行事务，至到事务完成。
　　    3，数据库备份
　　       当SQL server 2005数据备份时，数据库会把数据和日志文件一起备份起来，
　　       而在还原数据库时，系统会提示你是否回滚未提交的数据
　　      如下图：如果备份时没有日志，数据事务的ACID就不能保证。这时数据就可能出现sql server数据库置疑和数据不准的情况