大多数的DBA都在思考这个问题。在许多数据或表的架构发生巨大变化的时候，确实需要看看在数据变化之前和之后发生了什么。一个精心编写的数据库应用程序可以有自己的日志功能，或者会干脆地设定一种从来不进行数据覆盖的方法。如果没有采取任何措施，你还可以找出备份并与当前版本进行比较，但这意味着是一件令人头痛的事情。然而是否存在原生的SQL Server功能来找出不同之处呢?

　　可用于SQL Server数据保护的技术有：更改跟踪，变更数据捕获，复制和数据库镜像，每种技术都有最适合自己的场合。在这里我不会讨论备份技术，而是讨论如何保存和访问特定对象的历史版本数据，如数据或表的早期版本。

　　更改跟踪

　　SQL Server更改跟踪是一种相当简单的方法。当该功能被启用时，任何时候一个数据操作语言(DML)动作(插入、更新或删除)发生，它就会记录哪张表的哪一行被修改以及事务发生的时间和日期;如果是更新操作还会记录哪些列被修改(前提是已经启用列跟踪)。可以查询sys.dm_tran_commit_table系统视图获得这些跟踪信息，还可以反过来用于从特殊命名的内部表获得给定表的信息，只要你在创建给定表时已经启用更改跟踪。

　　默认情况下，更改跟踪记录保持两天时间。你可以通过ALTER DATABASE命令或SQL Server Management Studio管理工具的数据库属性窗口对保留时间进行修改。最短的时间是一分钟;虽然在理论上没有最大值，但是在一个高访问量的数据库中设置该属性超过两天，我对此持怀疑态度，因为系统对象的增长存在失控的可能性。

　　更改跟踪最大的缺点是：很多关于变化数据和数据模式的信息不会被保留。例如，更改跟踪不保留任何关于给定行在你修改之前它的值是什么的信息。仅有该行最新的数据是什么，就是表本身。如果你删除一张表，所有关于该表的更改跟踪信息也被删除。

　　另一个缺点，但这是次要的，更改跟踪特性只适用于数据库兼容级别在90或更高的。如果小于90，你仍然可以设置更改跟踪选项，但试图通过CHANGETABLE功能获得跟踪信息将会产生错误。

　　为此，更改跟踪不能作为有效的数据保护措施。它是一种有效的收集表统计信息的方式且其变化影响较小。如果你想在一个给定的数据库中获得最多或最少更新的列或表的真实信息，并想在此基础上优化你的数据库设计，采用这个特性就很方便。