（代码7.6：对于数据清理在DELETE语句里使用TOP运算符）

?

这些方法在SQL Server 2000,2005,2008的任何版本都可以使用，在数据清理期间最小化事务。

?

但是，如果你的数据库是SQL Server 2005或2008企业版，且经常清理数据，那么清理数据的更好方法是表分区，在列上筛选要删除的数据。这会更小影响事务日志，因为分区包含的数据会从表转出并清理，对SQL Server只是记录区重新分配的操作。

?

管理存档

?

这已经是这个系列文章讨论范围之外了，自动归档方案。但是，一个可能的归档过程涉及分区，表之间的架构复制，允许一个表的一个分区可以转出到另一个。在主要的OLTP表最小化数据的活动部分，但只减少修改的元数据的归档过程。Kimberley Tripp已经写了一份具体的白皮书，叫做SQL Server 2005里的表和索引分区，它谈了划窗技术（sliding window technique）。

?

未提交事务

?

默认情况下，SQL Server会在隐性事务里包裹任何数据修改语句来保证，在灾难事件里，SQL Server可以回滚在故障点已经做出的修改，返回数据到一致的状态。如果修改成功，隐性事务会提交到数据库。和自动发生的隐性事务相比，我们创建显性事务，在代码包裹多个修改在一个事务里，来保证所有的修改通过ROLLBACK命令可以撤销，或者通过COMMIT命令提交让它持久。

?

当恰当使用时，显性事务可以保证多个表之间的数据修改作为一个单位成功完成，或者全部都不修改。当使用不当时，不管怎样，在数据库里孤立的事务还是活跃的，阻止事务日志的截断，这会导致事务日志增长或填满。在SQL Server里有很多孤立事务的原因，这超出了这篇文章详细介绍的范围。但是，一些常见的原因有：

?

长时间运行的事务造成应用程序超时

?

在T-SQL或应用程序代码里错误的错误处理

?

触发器执行期间失败

?

链接服务器失效导致孤立的分布式事务

?

和BEGIN TRANSACTION COMMAND没有对应的COMMIT/ROLLBACK语句

?

?一旦一个事务开始，它会保持活动直到创建的连接，事务触发COMMIT或ROLLBACK语句，或者连接从SQL Server中断（当使用绑定的链接，会允许会话共享锁，这是个异常）。

?

现在的应用程序通常会使用连接池，在池里保持与SQL Server的连接让程序重用，即使当程序代码在连接上调用Close()方法。当对孤立事务进行故障排除是理解最后一点非常重要，因为即使连接在加入或返回到应用程序连接池前被重置，数据库里打开的事务还是继续存在的，如果它们没有正常结束的话。

?

识别活动事务

?

事务相关的DMV提供大量的额外信息，不管当前事务的状态和进行的操作。但是，一些DBA还是使用DBCC OPENTRAN作为识别是否为孤立事务（或只是长时间运行的）为造成日志增长的根源的最快方法。

?

在DBCC OPENTRAN(DatabaseName)格式里会接受数据库名称作为输入参数，数据库名称是用作检查打开事务的数据库名。如果数据库里有活动事务存在，命令会输出类似如下的信息。

?

1 DBCC OPENTRAN ?(FullRecovery)

Transaction information for database 'FullRecovery'.

?

Oldest active transaction:

? ? SPID (server process ID): 56

? ? UID (user ID) : -1

? ? Name ? ? ? ? ?: user_transaction

? ? LSN ? ? ? ? ? : (897:15322:1)

? ? Start time ? ?: Sep 18 2012 ?1:01:29:390PM

? ? SID ? ? ? ? ? : 0x010500000000000515000000fd43461e19525f12828ba628ee0a0000

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

（代码7.7：来自DBCC OPENTRAN的输出信息范例）

?

DBCC OPENTRAN只输出最早的活动事务，但主要表示事务是否为活动的疑问是开始时间。一般来说，未提交的事务是打开很长时间才会是造成事务日志增长的原因。

?

另一个重要的信息是SPID（server process ID；在DMV里这用session_id代替），这用来标识创建打开事务的会话。我们可以通过SPID判断事务是真的孤立还是只是长时间运行的，通过查询sysprocesses视图（在SQL Server 2000里）或者SQL Server 2005及后续版本里的sys.dm_exec_sessions和sys.dm_exec_connections的动态视图，如代码7.8所示。注意sysprocesses视图在SQL Server 2005及后续版本还是可用的，保持向后的兼容性。在运行代码7.8时，在每个查询里，直接用你看到的会话值替换session_id值（我们注释了几列，只是为了简化输出的可读性）。

?

?1 USE master

?2 GO

?3 SELECT ?spid ,

?4 ? ? ? ? status ,

?5 ?-- ? ? hostname ,

?6 ?-- ? ? program_name ,

?7 ?-- ? ? loginame ,

?8 ? ? ? ? login_time ,

?9 ? ? ? ? last_batch ,

10 ? ? ? ? ( SELECT ? ?text

11 ? ? ? ? ? FROM ? ? ?::

12 ? ? ? ? ? ? ? ? ? ? fn_get_sql(sql_handle)

13 ? ? ? ? ) AS [sql_text]

14 FROM ? ?sysprocesses

15 WHERE ? spid = 53

16?

17 USE FullRecovery

18 GO

19 SELECT ?s.session_id ,

20 ? ? ? ? s.status ,

21 ?-- ? ? s.host_name ,

22 ?-- ? ? s.program_name ,

23 ?-- ? ? s.login_name ,

24 ? ? ? ? s.login_time ,

25 ? ? ? ? s.last_request_start_time ,

26 ? ? ? ? s.last_request_end_time ,

27 ? ? ? ? t.text

28 FROM ? ?sys.dm_exec_sessions s

29 ? ? ? ? JOIN sys.dm_exec_connections c ON s.session_id = c.session_id

30 ? ? ? ? CROSS APPLY sys.dm_exec_sql_text(c.most_recent_sql_handle) t

31 WHERE ? s.session_id = 53