当我一个运行很长的事务，在事务提交以完后，突然断电了，这时长事务里肯定有没有处理的语句，面对这样情况，一部分已经处理完了，一部还没来得及处理的情况，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数据库置疑和数据不准的情况