ODI如何通过logminer创新发展从oracle数据库中抽取增量数据.docVIP

ODI如何通过logminer技术从oracle 数据库中抽取增量数据（一） 最近做的几个项目，都碰到了ODI从oracle9i或者中抽取增量数据的情况，那么ODI如何从数据库中抽取增量数据呢，ODI针对数据库的抽取，提供了3类知识模块： Oracle Simple Oracle Consistent Oracle 9i/10g/11gConsistent () Simple方式一般是针对数据库中需要增量复制的表之间没有主外键约束的情况，在这种方式下，表之间的先后复制关系没有影响。但如果表之间有主外键对照关系，采用simple方式就会出现问题，举个简单的例子，我们需要从源数据库抽取两张表订单和订单明细表的增量数据，其中订单明细表的外键要参照订单表的主键。 1.??????我们将订单表中主键从11000-25000的增量数据复制到目标端。 2.??????在复制的过程中，源端订单表又插入了两条新数据，主键为25001和25002。 3.??????当进行订单明细表的增量数据复制时，与订单表中主键25001和25002对应的明细数据就会在目标端出错，因为刚才复制时，这两条数据没有复制到目标端。 Consistent方式就是专门来解决这个问题的，它在处理父表前首先锁定（注意不是锁住）主表和子表需要复制的记录，在增量数据复制时，插入主表和子表的新增量数据都会被本次抽取过程忽略，放在下次抽取时处理。因此采用Consistent方式进行增量数据捕获一般需要5个步骤： 1.??????扩展窗口（extend_window）:计算主表和子表本次抽取的结果集，并赋予其一个序列号。 2.??????锁定订阅者（lock subscriber）：针对变化数据的某个订阅者，确定其需要抽取的序列号范围（一个系统的变化数据可能会被多个系统使用，比如主数据系统）。 3.??????执行抽取过程，我们通过ODI中的接口程序进行实现。 4.??????抽取完成后，解锁订阅者（unlock subscriber）：记录下本次抽取的最后的序列号，以便于下次使用。 5.??????清除增量数据（Purge the journal）：将已经复制完成的增量数据清楚（这里是指所有的订阅者）。 ? 在具体的实现方式上，Oracle Simple、Oracle Consistent是采用同步方式进行增量数据抽取的，说白了就是在源系统相关表上添加触发器，如下图所示： ? 当源数据库中的交易需要修改相关表时，会调用触发器，将变化数据插入到增量表中，触发器的调用是包含在交易中的，这就决定了变化数据的实时性高，在需要实时变化的场景，非常适用，而且这种方式在数据库非归档状态下也照常运行，其缺点是由于触发器包含在对数据修改的事务中，当系统并发量比较大时，会对原有系统的效率产生一定影响。很多同事一听说触发器就觉得对源系统影响非常大，其实并不是这样。这里需要澄清的一点概念是触发器往变化数据表中写的并不是所有变化的数据，而可能只是一个主键或者再加一点额外的信息，其对系统的影响比我们想象的要小得多。 Oracle 9i/10g/11gConsistent (LOGMINER)方式可以配置成异步方式，基于Oracle数据库的online redo log进行变化数据的捕捉（这里要特别提醒的是目前ODI只支持Hotlog方式），说的更白一点就是oracle stream技术，变化的数据通过logminer技术从在线日志中获取。如下图所示： ? 这种方式基于异步的策略，一般变化数据的获取会有1秒到几分钟的数据延迟，当然对数据仓库系统来讲，这点时间也不算啥。但是由于其从日志中抽取变化数据，对原有的生产系统影响很小，而且该方式在用户原来的schema上除了一个读权限外，不需要额外的权限要求，因此大多数用户都愿意采用这种方式。但该方式需要对用户有一定的权限要求，而且数据库必须运行在归档模式下。具体的配置我们下次再说。 ODI如何通过logminer技术从oracle 数据库中抽取增量数据（二） 在中通过logminer方式进行，需要首先做一些基本工作： 1.??????修改启动参数： alter system set global_names=TRUE scope=BOTH;（如果您的系统里有dblink也可以不修改，到时候修改ODI的也可以）。 alter system set job_queue_processes=6 scope=BOTH; alter system set open_links=4 scope=SPFILE; alter system set streams_pool_size=200Mscope=BOTH; alter system set undo_retention=3