变更数据捕捉

变更数据捕捉(Change Data Capture, CDC)是SQL Server 2008中推出的一个新的数据跟踪功能，它主要是为数据仓库场景设计的，可以有效的跟踪和获取对用户表所做的数据改动，并使你能够以一种简单的方式来访问变更数据。一般情况下，在一个操作数据库中使用CDC来捕捉变更，以便用于之后转移到数据仓库中。在SQL Server中使用CDC 就不再需要使用插入相关的方法，例如用户触发器、时间戳字段、以及高昂的查询来确定操作系统中什么发生了改变。

与变化数据一起获得的辅助信息使得CDC可以提供许多问题的答案。例如，下面列出了一些CDC可以有效提供答案的问题：
我想获得在12:00 A.M.和12:00 P.M 之间发生改变的所有记录。

我想要知道这个改变是插入、更新、还是删除。
对于一条更新记录，我想知道哪个(些)字段发生了改变。

提取、转换和加载(ETL)场景下最能发挥CDC 的作用。随着数据量的增加以及全局操作所导致的维护窗口的缩减，使得优化ETL处理变得尤为重要。变更数据捕捉为你提供了一个非常有用的方法，在增量基础上提取变更，从而降低整个ETL处理时间。
下图提供了对变更数据捕捉的组件概述。

CDC使用一个捕捉作业从SQL Server事务日志中提取变更信息，生成变更表。CDC API使你可以编写一个应用程序，从变更表中获得信息，也可以在ETL包中使用它。CDC清除作业删除了变更表中不再需要的信息。

最低限度日志记录INSERT

一般情况下，当你往一个数据库中写数据时，必须将对磁盘执行两次写入操作：一次是写到日志，一次是写到数据库中。这是因为数据库系统使用一个undo/redo 日志，所以在需要的情况下可以回滚或重做事务。但在某些重要的情况(涉及插入数据到现有的表中，从而加速你的ETL处理速度的情况)下，可以将数据只写入到磁盘一次。这就是SQL Server 2008中的最低限度日志记录INSERT特性。

最低限度日志记录只记录回滚所不支持的实时恢复的事务所需的信息，它只在批量日志记录和简单恢复模型情况下可用。当一个最低限度日志记录事务提交时，会发布一个检查点用以将脏数据页面发送到磁盘并截断日志。最低限度日志记录通过提高性能和降低所需日志空间大小，从而极大地改进了大规模INSERT操作。特别是，你必须对目标表使用表锁(TABLOCK)。

在SQL 2005中可以采用最低限度日志记录的操作包括批量导入操作、SELECT INTO 、以及索引创建和重建。SQL 2008将之扩展到INSERT INTO…SELECT FROM T-SQL 操作，它在满足任意以下条件的情况下，将大量记录插入到一个已有的表中：
将记录插入到一个具有集群索引而没有非集群索引的空表

插入到一个没有索引但是可以是非空的堆里面

使用最低限度日志记录INSERT的主要场景是：在特定的文件组上创建一个空表，这样就可以控制数据存放的物理位置。然后使用INSERT INTO…SELECT FROM以一种最低限度日志记录的形式来组装它。这样数据将放置在你所希望的地方，并且只将它写到磁盘一次。

数据压缩

在SQL Server 2008中新的数据压缩特性通过以可变长度存储的形式存储固定长度的数据，并减少冗余数据，从而降低了表、索引或其分区的子集大小。能够节省的空间大小取决于架构和数据的分布。我们使用大量数据仓库数据库进行了测试，得到的统计情况是真实的用户数据库的大小最多可以减少87%（7比1的压缩比），但是更多情况下只能降低50-70%（压缩比大约在2比1到3比1之间）。

SQL Server提供了两种压缩类型，如下所示：

行（ROW）压缩能够以可变长度存储格式来存储固定长度类型。所以举例来说，如果你有一个字段数据类型为BIGINT，其固定格式将占据8个字节的存储空间，压缩之后它将使用可变的字节数——从0到8的字节数。由于字段值是以可变长度来存储的，所以在一个记录里每个字段会存储一个额外的4位长度代码。此外，0和NULL值除了这个4位代码之外不占任何存储空间。
页面（PAGE）压缩是建立于行压缩的基础上的。它存储页面上普遍使用的字节格式，然后将这些值引用给各自的字段，通过这种方法将冗余数据的存储降低到最小。字节格式标识是不受类型约束的。在页面压缩中，SQL Server使用两种技术优化页面使用的空间。

第一项技术叫做列前缀（column prefix）。在这种情景下，系统寻找一个通用字节样式作为页面上特定列中所有数值的一个前缀。表或索引的所有列都重复这个过程。计算得来的这个列前缀值作为一个标记存储，数据或索引将这个标记作为公共前缀参考，如果可能的话，每一个字段都这么做。

第二项技术叫做页面级字典（page level dictionary）。这个字典存储行和列的数值，并存储在一个字典中。然后通过修改列来引用改字典。

压缩伴随着额外的CPU消耗。这是在你对压缩数据进行查询或执行DML操作时产生的。行压缩所消耗的CPU要低于页面压缩，但是页面压缩可以提供更好的压缩比。因为有很多种工作负载和数据格式，所以SQL Server 将压缩粒度确定在分区级别。你可以选择压缩整个表或索引或分区子集。例如，在一个数据仓库中，如果CPU负载是你所关注的重点，另外你还想节省一些磁盘空间，那么就可以在不常被访问到的分区上使用页面压缩，而不压缩经常被访问和操纵的分区。这样既降低了CPU总负载，又节约了磁盘空间。如果I/O性能是你所关注的重点，或者你需要提升可用磁盘空间，那么使用页面压缩来压缩所有数据或许是最好的选择。如果频繁涉及的页面的工作集缓存放在主要内存缓冲池中，那么压缩可以将速度提升好几倍，而如果放在内存中则不可以。对一个用来测试SQL Server 2008的大型内部数据仓库查询性能基准的初步测试结果显示，压缩节省了58%的磁盘空间，平均降低了15%的查询时间，另外CPU的平均消耗提高了20%，一些查询的速度甚至提高了七倍。真实结果将取决于你的工作负载、数据库和硬件。

备份压缩

备份压缩帮助你以多种方式节省空间。

降低SQL备份的大小可以节省很多磁盘空间。所有的压缩结果依赖于被压缩的数据本身，压缩到50%是很常见的，甚至可能压缩到更小。这样你可以使用较少的存储以保持备份处于联机状态，或者使用相同的存储保持更多的备份版本处于联机状态。
备份压缩还帮助你节省了时间。传统的SQL备份几乎完全受I/O性能的限制。通过降低备份过程的I/O负载，我们实际上加快了备份和恢复的速度。

当然天下没有免费的午餐，备份在空间和时间上的节省是以耗费CPU为代价的。好的一面是I/O时间的节省弥补了CPU时间的增加，而且你可以利用Resource Governor 控制备份过程所消耗的CPU比例。