DTS开发记录（5）－－ 挑战增量导出

    增量导出恐怕是DTS系统中最艰难的部分了，我们曾考虑过很多方案，最后都因为需要表大纲做一定的假设而不具备通用性而放弃。有很多效率较高的方案，由于为了追求通用性而无法实现，因为现实的情况比我们理想的要复杂许多。
    下面将列举我们曾考虑的几种主要方案，这些方案乍一看似乎都很有希望，可通过层层分析，最后都因为复杂的现实情况而胎死腹中。

1.触发器
    这是一个非常简单直接的解决方案，我们只需要将DTS引擎驻留在比如windows服务中，该引擎通过数据库的触发器事件获取源表数据更新的所有情况，即增量，然后相应的更新目的表。然而，由谁来创建触发器了？
    我们DTS系统的任务是将数据从一个表迁移到另外一个表，它所拥有的权限是：
（1）读取源表
（2）读写目的表
    我们没有创建触发器的权限，更别说接收触发器的事件了。
    触发器方案马上被否决！

2.查询数据库的增量记录
    触发器方案被否决后，我们退而求其次，我们希望所有的数据库都提供了某种机制，能让我们查询指定表的增量记录。比如，我们给出一个时间段和指定表的名称，调用数据库的某个函数或存储过程或扩展SQL命令，数据库返回一个结果数据集，这个数据集中包含了指定的时间段内，指定表中有哪些数据是新添加的、哪些数据被删除了、哪些数据是更新过的。如果能进行这样的数据库增量查询，那么增量导出也会比较简单。
    为此，我们寻找了相关的资料，主要针对Oracle和SqlServer，到现在为止，还没有发现其中的一个数据库内置了类似的机制。其实，我们可以想想，数据库当然可以实现这样的机制，但是代价可能非常高昂。比如，数据库要记录“删除增量”，如果对应的指定表没有设置主键，数据库该用什么来唯一标志被删除的记录了，可能的办法是使用临时表把被删除的记录完整的记录下来，如果要完整的记录下被删除的记录，那么临时表的大纲就需要与指定表的大纲完全相同。因此，数据库需要为每个表都建一个大纲完全相同的表来存储这些增量记录。随时间流逝，无疑，这些临时表中的数据会越来越多，那么，谁来负责删除这些临时表中的增量记录数据了？该删除哪些增量记录了？
    我们知道，大多数据库都实现了增量备份的功能，如果增量备份不是采用主条记录比对的话，可能就是使用了临时表，这样，增量备份的时刻就是数据库清空临时表的最佳时机。但是对于随机的、可重复性的增量导出来说，还存在清空临时表的时机吗？也许你刚刚清空了临时表的部分记录，而我再一次类似的增量导出可能需要用到你刚清除的那些增量记录。
    看来，我们希望所有的数据库（不仅仅是Oracle和SqlServer）提供一种机制、自动为我们记录所有时间内每个表的增量是不太可能的。该方案被否决。

3.双排序逐条记录比对
    我们再一次退而求其次，采用最笨的逐条记录比对的方法。最笨的方案中也可以用一些效率较高的技巧，我们首先考虑到的是双排序逐条记录比对。
    所谓双排序，只的是对存在于源表中的记录和目的表中的记录都采用主键排序的方式，这样通过主键值相同来识别匹配的记录，然后再比对其余的字段来判断数据是否更新；如果源表中的某条记录在目的表中没有找到匹配，表明这条记录是新增加的。
   如何判断那条记录是删除的？通常的做法是采用反向遍历，即从目标表中选取一条记录，然后遍历源表，如果没有发现这条记录，则表明发现了一个删除增量。
    采用双排序的方法，可以很快的识别删除增量。我们分别为已排序的源记录和已排序的目标记录设置一个指针，这个指针只能单步前进，然后将两个指针指向的记录拿出来进行主键值比较，如果发现相同，则说明发现了匹配，处理该条记录，然后两个指针各前进一步；如果源主键值较小，则说明该条记录是新增加的；如果源主键值较大，则说明目的指针指向的当前记录已经在源表中被删除，这是一个删除增量。
    这种方案似乎是可行的，虽然要逐条比对，但是效率也不会太低。
    可是，如果所操作的表采用的是联合主键了（即，联合主键中的任何一个键的数据都可能是重复的，但是将它们联合起来，在表中却又是唯一的）？我们仍然可以进行实现排序，记录匹配也同样可以进行，只不多前面我们通过主键值相等来进行匹配，这里需要通过多个列的值全相等来进行匹配。
    我们再考虑复杂一点的情况，如果主键进行了分裂，或者参与了合并的情况了？经过排序后，主键的值是有序的，可是主键分裂的值（或者合并后的目标值）却不一定是有序的。这样就没有办法进行双排序操作了。因为当操作源数据中的任意一条记录时，都可能需要遍历目的表中的所有记录。

4.单排序逐条记录比对
    我们现在采用的方法是单排序逐条记录比对，即只对源表记录排序，然后逐条记录处理。这样效率要低得多，但是任务反而变得单纯些。效率最低的地方体现在识别“删除增量”，因为要用到反向遍历操作。我们希望找到更好的方法来替代它。

     在实际的实现中，你可能还会遇到一些困难，比如，我们的源表/目的表中的记录非常多，所以不可能一次将它们读入到内存中，我们需要分页。标准的sql不支持分页，针对不同的数据库有不同的实现方式，特别是当复杂的排序（如联合主键排序）掺杂在其中时，分页操作更为困难。再就是，对BLOB、CLOB、LOB数据的比对，是否要一个一个byte的进行比较来决定其是否为“更新增量”了？
    另外，我们需要对增量导出做更细粒度的控制，比如可以让其选择在增量导出时能分别控制开启或关闭“Add增量”、“Update增量”、“Delete增量”的导出。如果我们确信不需要“Delete增量”导出，那么就可以节省大量的导出执行时间。


转到：DTS开发记录（序）