对开发人员来说，SQL Server 中的一个难题是跟踪数据库中哪些数据发生了更改。但更大的挑战是设计出一套既不会严重影响工作负荷性能，又不难创建、实现和管理的简单解决方案。那为什么要这么大费周章跟踪更改呢？跟踪更改真的值得下这么多功夫吗？两个经常引用的典型示例是：支持数据仓库的更新，以及支持异构、偶尔连接的系统进行同步处理。

　　数据仓库通常具有 Online Transaction Processing (OLTP) 数据库中表的某些表示，但是表架构实际上可能截然不同。这表示需要有 ETL（提取、转换、加载）过程将数据从 OLTP 数据库移动到数据仓库。

　　观看 Paul Randal 向您演示如何使用 SQL Server 2008 中全新的“更改数据捕获”功能来跟踪数据库中的更改。

　　我可以考虑用三种方法执行此操作。第一种是定期刷新整个数据仓库。显然，如果数据量太大，这种方法是不切实际的，而且也意味着对数据仓库的更新并不连续。第二种方法是在 OLTP 数据库中使用分区架构，只对自上次 ETL 过程以来添加的数据执行 ETL 过程。此方法只能用于数据插入的工作，不能用于更新或删除工作，而且需要复杂的机制来管理分区边界定义和切换分区。第三种方法是跟踪对 OLTP 数据的更改，并且只使用已更改的数据来执行 ETL 过程。就数据量来说，这是最有效的方法。

　　移动设备在如今的企业环境中无所不在，换句话说，处理偶尔连接的系统是必要的。就数据库系统来说，问题在于如何有效地更新不常连接的设备上的数据存储，特别是当数据存储本身可能很小而且架构可能与主数据库截然不同时。

　　假设有一名移动销售代表，她负责超大型产品目录的一部分。她每晚都会将自己的手持设备连接到主数据库来下载最新的数据 — 对该部分产品目录的所有更改，经过简化以便存储在手持设备上。数据传输应该尽可能高效。

　　您可以让数据库系统准备要下载到设备的整个产品目录的相关部分，并且让设备进行下载。换句话说，每次设备连接时都会下载所有数据，即便数据没有更改也一样。这显然是效率低下的方法。

　　另一种方法是让数据库系统跟踪产品目录的相关部分发生的更改。然后在手持设备连接时，它会要求获得自上次连接以来发生更改的数据。在这种解决方案中，数据库系统只需要准备数据的子集，而且下载也尽可能高效。

　　跟踪更改的另一个原因是要支持审核，这在当今是必不可少的。审核除了跟踪所做的更改之外，还会跟踪更改时间和更改者。这对于完整审核记录的持久性、安全性和正确性都有严谨的规范，无疑将事情提升到了另一个级别。

　　SQL Server 2008 中针对跟踪数据更改而设计的技术并非旨在支持审核，然而，SQL Server 2008 提供的一项名为 SQL Server Audit 的新功能则是专为审核而设计的。在 2008 年 4 月出版的《Technet 杂志》中，Rick Byham 发表了“SQL Server 2008：安全性”一文，讨论了 SQL Server 审核功能（文章的地址为 technet.microsoft.com/magazine/cc434691）。

　　您可以看到，跟踪数据的更改有很多吸引人的理由。因此，重要的问题是进行跟踪的最佳方法是什么？

　　如何在 SQL Server 2005 中跟踪更改

　　SQL Server 2005 及其早期版本中并没有简单、内置的解决方案。所以，对于这些平台，开发人员必须为应用程序创建自定义解决方案，通常包括时间戳列、DML（数据操作语言）触发器和其他表。但这些解决方案导致了各种潜在问题。例如：

　　添加时间戳列会使表架构发生更改（从而在存储过程和其他代码中产生连锁影响）。

　　DML 触发器是事务的隐含部分（事务中包含的 DML 可以触发该触发器），因此它的执行时间会增加事务的长度。触发器越复杂，执行所花的时间越长，对工作负荷性能就越不利。用于跟踪更改的 DML 触发器必须处理插入和删除的表，以搜集所有更改，然后将其插入另一跟踪表。

　　跟踪表必须以某种方式来管理，才能避免增长失控，而这可能需要您创建类似于代理作业的内容来定期删除旧数据。

　　在 SQL Server 2008 中跟踪更改的更简单方法

　　SQL Server 2008 引入了两种新技术，使得跟踪数据更改更加容易：更改跟踪和更改数据捕获。这两种功能都可以跟踪发生更改的数据（也可以使用插入、更新或删除作业来准确跟踪数据的更改过程），而且有了它们，完全不需要自定义解决方案。除了这些相似性之外，这两种功能的机制和具体的跟踪内容其实大相径庭。

　　更改数据捕获使用的是异步机制，可以跟踪表（或是表中一组定义的数据列）发生的所有更改，包括列值本身。这是专为我先前介绍的数据仓库 ETL 过程等情形设计的。