一般数据库增量更新方法--假增量

1     说说假增量

我们都知道，对于BW来说，很多ECC的标准数据源自带了增量更新功能，每天各种凭证产生的增量数据会自动堆积到增量队列里，然后BW端做一个增量信息包按天把这些增量抽取到数据仓库里，非常轻松自然，对于客户和顾问，都是透明的自动的容易实施的，这也是上过ECC的企业数据仓库采用SAP BW的一个优势所在。

但是对于非ECC的一般数据库或者ECC的自定义数据源，做增量更新就苦了。对于ECC的自定义数据源，SAP给了一种标准方案，我们看看这种方法：用一个时间字段或数字字段标记增量，当这个字段在表里的数值变化时，就认为是增量，把这条记录作为增量记录，增量信息包会挑出这些记录传送上去。这种方法的问题是显而易见的，不管是时间还是数字字段，我们都需要ABAP工作者额外编程去控制这个字段的变化，这样才能正确让系统选择出增量（用表中的凭证创建日期等字段作为时间字段去控制是不可行的，因为你不能保证今天不会修改昨天的数。）对于非ECC的一般数据库连接，SAP很干脆的说，不支持增量（06年是这么讲的，以后支不支持不晓得）

    总结一下，在不同的数据源下，对增量的支持是这样的：

   
 

    因此，对于不支持或不好实现增量的情况，我们比较推荐的方法是，使用带选择条件的完全抽取信息包，每一次定期抽取之前N个月的数据（前提是客户保证，不修改N之前月的数据），然后上传到DSO中，如果这N个月的数据没有变化，则会被覆盖掉，系统当什么事都没发生；如果有变化，则会把变化部分覆盖DSO相同主键的数据，然后记录到DSO的更改日志表，再往CUBE中传变化部分（当然：DSO到CUBE的DTP要设置成增量DTP），这样，就以比较小的抽取时间的代价（每天只要抽最近N个月，N尽量小的数据），换来了增量抽取的几乎全部优点（每次抽取时间比较短，数据量小，传到CUBE也同样只传增量部分）。这种做法，SAP 官方教材极力推荐，见下图（取自教材350增量更新一章最后一节），BW江湖人送外号假增量即是此种方法。

比如说，每天抽取最近两个月的数据，在信息包里我们可以这么写例程去控制（时间选择字段为T_DATE）：

data: l_idx like sy-tabix.
        data: tmp_date type d.
        read table l_t_range with key fieldname = 'T_DATE'.
        l_idx = sy-tabix.
        tmp_date = sy-datum - 60.
        l_t_range-high = sy-datum.
        l_t_range-low = tmp_date.
        l_t_range-sign = 'I'.
        l_t_range-option = 'BT'.
        modify l_t_range index l_idx.
        p_subrc = 0.

这样最近两个月的数据每天抽取，每天覆盖，再利用DSO的更改日志表，就实现了“假增量”。

如果数据源对应的不是DSO，是CUBE，那么就无法使用更改日志表，BW也给我们一种实现假增量的方式，见下图：

解释一下这个图，CUBE里的数据是不能覆盖的，所以，如果要每天抽取部分数据的话，必须要把上次相同抽取条件（比如：今年）的数(请求)给删掉，这个我们可以在处理链里设置：删除信息块中的重叠请求：

 

一般来说，数据源都是先把数传递到DSO再到CUBE，每次删除重复请求感觉上也不是很安全，所以上述方法使用的不多。

先到DSO再到CUBE，每一次用程序抽取最近N个月数据的这种假增量方法看似比较完美，其实背后隐藏了一个极大的问题，即用户在源系统物理删除的那部分记录如何在BW也每天自动删除掉。原系统物理删除掉的记录，BW在抽取过程中是无法自动识别的，在DSO的更改日志里当然也体现不出来，CUBE端肯定也不会自动删除掉，这个如何处理？放任不管是肯定不行的，在这次首钢项目的开始，项目组就提出了这个问题，要求给出合适的解决方案。

 

2     让客户最偷懒的，解决物理删除问题的假增量方案

解决方案经过研究，可以有以下两种主要思路。第一种，由开发源系统的客户方维护人员，在视图里增加一个删除标记，每一次数据删除了，都打上这个标记，BW抽取上来后，在报表里设置条件，凡是有这个标记的数据，就不显示出来。这种方案的问题在于客户必须要修改它那边源系统的代码，很多时候，客户想偷个懒，不太愿意改，这种方案需要客户配合，也不是标准的解决方案。第二种方法，在BW这边识别，并在抽取时自动进行处理，这样客户什么也不需要做，相当舒服，但是BW这边如何能尽量方便的处理，就得综合考虑一些问题了。

 

问题一： BW如何找出被物理删除的记录？

可以在开始例程里统一判断，即把开始例程的SOURCE_PACKAGE和DSO中相关记录进行比对，DSO中有，而SOURCE_PACKAGE找不到的记录，即可认为是删除，例程如下：

  SELECT * FROM /bic/az3pp_o0900 INTO TABLE it_dso

    where stat_date 在60天内 （假如报表每次抽取最近两个月的数的话).

LOOP AT it_dso INTO st_dso.

      READ TABLE SOURCE_PACKAGE INTO st_source WITH KEY STAT_DATE =

      st_dso-calday.

      IF sy-subrc <> 0.

         “ 确认删除，此处开始处理问题二

      ENDIF.

   ENDLOOP.

   需要注意上述例程粗体部分，选择DSO数据到内表的那个时间范围必须也要和InfoPackage的数据抽取时间范围一致，否则无法正确比对（系统会把DSO中之前的历史数据也认为是已删除数据）。

 

问题二： 找到被删除记录后，怎么能让DSO的更改日志知道这条记录被删除了？

我们知道，DSO的更改日志会自动把这一次的数据和上一次的数据进行比对，把差异记录在日志表里，再传递到CUBE中，因此，我们可以考虑，手工把被删除数据的关键值统一设置为0，这样，假设原来关键值是15的话，DSO会被覆盖成0，DSO的更改日志表会变成-15，再传到CUBE中就是15 +（-15）= 0了。这样等于针对删除记录自动产生了反冲记录，可以同时保证DSO和CUBE数据的准确性了（DSO和CUBE该记录都为0了），例程如下：

    LOOP AT it_dso INTO st_dso.

      READ TABLE SOURCE_PACKAGE INTO st_source WITH KEY STAT_DATE =

      st_dso-calday.

      IF sy-subrc <> 0.

        st_source-STAT_DATE = st_dso-calday.

        st_source-L4_FACILITY_ID = st_dso-plant.

        st_source-L4_WORKCENTER_ID = st_dso-workcenter.

 

        st_source-EQPT_OUT = 0.

        st_source-EQPT_SCRAP = 0.

        st_source-SACRPT_HRM_INPUT = 0.

        st_source-SALE_OUT = 0.

        st_source-SALEMAT_HRM_INPU = 0.

 

 

        st_source-record = tmp_record.

        APPEND st_source TO SOURCE_PACKAGE.

      ENDIF.

ENDLOOP.

注意，上述例程中非关键值要设置成和原先一样，关键值都要设置成0.

完整例程如下：

DATA it_dso TYPE TABLE OF /bic/az3pp_o0900.

    DATA st_dso TYPE /bic/az3pp_o0900.

    DATA st_source TYPE _ty_s_sc_1.

    DATA tmp_record TYPE  rsarecord.

 

SELECT * FROM /bic/az3pp_o0900 INTO TABLE it_dso

where stat_date 在60天内（假如报表每次抽取最近两个月的数的话).

    READ TABLE SOURCE_PACKAGE INTO st_source INDEX 1.

    tmp_record = st_source-record.

    CLEAR st_source.

 

    LOOP AT it_dso INTO st_dso.

      READ TABLE SOURCE_PACKAGE INTO st_source WITH KEY STAT_DATE =

      st_dso-calday.

      IF sy-subrc <> 0.

        st_source-STAT_DATE = st_dso-calday.

        st_source-L4_FACILITY_ID = st_dso-plant.

        st_source-L4_WORKCENTER_ID = st_dso-workcenter.

 

        st_source-EQPT_OUT = 0.

        st_source-EQPT_SCRAP = 0.

        st_source-SACRPT_HRM_INPUT = 0.

        st_source-SALE_OUT = 0.

        st_source-SALEMAT_HRM_INPU = 0.

 

 

        st_source-record = tmp_record.

        APPEND st_source TO SOURCE_PACKAGE.

      ENDIF.

ENDLOOP.

这样的方案，我们每一次都只需把数据源到DSO的转换增加一个类似的开始例程，所有物理删除的问题就可以得到统一的解决了。以后有少数字段调整，修改起来也比较方便。对源系统那端的开发人员，工作量=0，对BW顾问，工作量也不大：）

还有一种更简便的方案，找到要删除记录后，手工把该记录的RECORDMODE字段设置成D，这样也能实现全部的反冲机制，而且代码更精简，更好的益处是：原先的方案，是把关键值都设置成0，覆盖新值后产生负数的反冲记录，再更新后序模型中的数据。这样原DSO中的数并不会实际删除，只是把关键值设置为0。如果从CUBE出报表没问题，如果直接从DSO出报表，数据仍然会显示一条为0的，让客户莫名其妙。

例程示例为：

LOOP AT it_dso INTO st_dso.

      READ TABLE SOURCE_PACKAGE INTO st_source WITH KEY STAT_DATE =

      st_dso-calday.

      IF sy-subrc <> 0.

        st_source-STAT_DATE = st_dso-calday.

        st_source-L4_FACILITY_ID = st_dso-plant.

        st_source-L4_WORKCENTER_ID = st_dso-workcenter.

 

        st_source-RECORDMODE = ‘D’.

 

        st_source-record = tmp_record.

        APPEND st_source TO SOURCE_PACKAGE.

      ENDIF.

ENDLOOP.

写了这么多，总结一下，用户物理删除（无删除标记的）的假增量方案，也就是如下两步而已：

1） 每次抽取最近几个月的数据到标准DSO再到CUBE，

2）从数据源到DSO的转换增加一个开始例程，把每次传输源系统删除的数据找出来，以关键值为0的形式或者RECORDMODE为D的形式更新到后续的数据目标中。