ODI如何通过logminer技术从oracle 数据库中抽取增量数据

ODI 从oracle 数据库中抽取增量数据

海量Oracle资料下载，请收藏

https://www.360docs.net/doc/7115101032.html,

Oracle Data Integrator简介

ODI(Oracle Data Integrator)是Oracle在2006年10月收购Sunopsis公司后，整合Sunopsis Active Integration Platform而推出的一款数据集成工具，现在是Oracle Fusion Middleware的组件。和Oracle自己的OWB(Oracle Warehouse Build)相比，ODI支持更多的异构数据源，支持SOA，支持Jython，和OWB正好互补。ODI和OWB都是所谓的ELT工具，和通常所见的ETL工具不同，它们不是采用独立的引擎而是采用RDBMS进行数据转换。做为领先的RDBMS供应商，Oracle选择ELT而不是ETL不是没有道理的。

ODI的主要组件包括模块知识库，图形模块和执行引擎，都是基于java编写，所以运行ODI需要有JDK的支持。另外还有一个基于J2EE的元数据导航器(Metadata Navigator)。

知识库

ODI所有模块的信息都保存在一个叫做Master Repository的中心知识库中。Master Repository通过Master Repository Creation Wizard创建，这也是安装完ODI后应该做的第一个任务。

除了Master Repository，还需要为不同的任务创建Work Repository。Work Repository中的信息包括模块信息，项目信息和运行期信息。

图形模块

Designer 用于定义数据转换逻辑，这是最常用的开发工具，大部分的开发任务，包括data store的定义，interface(数据映射关系)和package（相当于workflow）的创建等，都是在Designer中完成。

Operator用于管理和监控数据转换任务的执行情况，在设计阶段，也可用于调

试(debugging)

Topology Manager用于定义物理和逻辑基础架构，如work repository的创建

和管理等。

Security Manager用于管理用户权限

运行期组件

Schedule Agent计划代理，用于调度执行数据转换任务。计划代理同时也带有

一个数据转换引擎，但是ODI采用E-LT架构，所以基本上计划代理只是将任务传递给目标库，其数据转换引擎很少用到。

附：安装完ODI后默认用户名为SUPERVISOR，密码为SUNOPSIS，大小写敏感。

ODI 从oracle 数据库中抽取增量数据

最近做的几个项目，都碰到了ODI从oracle9i或者10g数据库中抽取增量数据的情况，那么ODI如何从数据库中抽取增量数据呢，ODI针对Oracle数据库的抽取，提供了3类知识模块：

Oracle Simple

Oracle Consistent

Oracle 9i/10g/11gConsistent (LOGMINER)

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方式进行变化数据捕捉，需要首先做一些基本工作：

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=3600 scope=BOTH;

JOB_QUEUE_PROCESSES (current value) + 2

PARALLEL_MAX_SERVERS (current value) + (5 * (the number of change sets planned))

PROCESSES (current value) + (7 * (the number of change sets planned))

SESSIONS (current value) + (2 * (the number of change sets planned))

Open_cursors一定要大一点（建议1000以上），尤其是10.2.0.4之前的版本。

2.数据库必须在归档模式下，在sqlplus下执行：

SQL> select log_mode from v$database;

LOG_MODE

------------

ARCHIVELOG

如果返回如上，恭喜您，不用做这一步了，否则要执行：

SQL>conn /as sysdba

Connected.

SQL>shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL>startup mount

ORACLE instance started.

Total System Global Area 301989888 bytes

Fixed Size 1267140 bytes

Variable Size 163580476 bytes

Database Buffers 130023424 bytes

Redo Buffers 7118848 bytes

Database mounted.

SQL>alter database archivelog;

Database altered.

SQL> alter database force logging;

Database altered.

SQL> alter database add supplemental log data;

SQL> alter database open;

Database altered.

且记，如果是生产系统，一定不要在工作时间做这样的事情，而且做前一定和管理员和其它用户沟通好，如果您不小心将生产系统弄瘫了，临被干掉前别说俺没提醒过您。

3.在数据库系统里面为ODI的变化数据准备存储空间，为了避免对现有生产系统产生影响，建议单独为其建立一个表空间。

表空间的大小和您的业务量以及您存储多长时间的变化数据有关，具体场景最好在您的测试环境里面先试试，当然了，如果空间不是很紧张，尽量大一点。

4.为变化数据捕捉建立一个用户，该用户将被ODI用来连接数据库，并获取变化数据。

CREATE USER cdcadmin

IDENTIFIED BY cdcadmin

DEFAULT TABLESPACE TS_ODI

TEMPORARY TABLESPACE temp

为了配置和获取变化数据，该用户需要以下权限：

-- system privs

GRANT create session TO cdcadmin;

GRANT create table TO cdcadmin;

GRANT create sequence TO cdcadmin;

GRANT create procedure TO cdcadmin;

GRANT create any job TO cdcadmin;

-- role privs

GRANT execute_catalog_role TO cdcadmin;

GRANT select_catalog_role TO cdcadmin;

-- object privileges

GRANT execute ON dbms_cdc_publish TO cdcadmin;

GRANT execute ON dbms_cdc_subscribe TO cdcadmin;

-- streams specific priv

execute dbms_streams_auth.grant_admin_privilege('CDCADMIN');

grant select on any table to cdcadmin(这里其实只要对生产系统需要捕获数据的schema相关表授权即可，这样设有点大，这里只是为了简单)。

Grant dba to cdcadmin(其实这一步可以不要，但为了操作简单，建议您还是加上，在ODI中启动日志完成后，再把其DBA revoke回去即可，说白了只是在ODI启动日志时需要，一旦启动完成，抓取数据不需要)。

如果管理员坚决不能给您DBA权限，那也可以到knowledge module中修改其step即可，将需要DBA权限的步骤在knowledge module中去掉，让管理员

帮忙做一下（其实只有一个步骤需要DBA,也就是这一句话alter database add supplemental log data）。如果管理员连这也不同意，那就没招了，等死吧。

至此，数据库的相关准备工作完成，下面就是ODI的配置工作了，关于ODI repository的配置请参照其随机文档，我们这里假设您的ODI已经做好基本配置了：

1.打开topology manager，在物理体系架构上建立一个物理服务器（这里我们假设oracle数据库中生产数据存储在sh schema上）。在定义上起个名，输入连接数据库的用户名口令：cdcadmin/cdcadmin.

2.点击JDBC TAB页：

3.输入完成后，点击一下右下角的测试，如果通了就ok了。

4.如下图，打开物理服务器下的物理架构，这里我们物理服务器叫sh，逻辑架构也叫sh。

这是非常关键的一步，如上图中我用红色标出的两个椭圆，上面那个是源系统中实际生产数据所在的schema，下面那个是存储临时对象的那个，也就是我们在数据库里定义的存储临时数据的schema，如果这里您用生产数据所在的schema来做工作架构存储临时数据，对您来讲没啥问题，但估计管理员要追着您打了。

5.到topology的逻辑体系架构下，建立一个oracle逻辑服务器，我们这里叫ODI.

启动designer，创建一个项目，我们这里就叫CDC，如下图所示：

右键点击项目名称，选择import->import knowledge module

进入$ODI_INSTALL/oracledi/impexp/目录，然后选择JKM

Oracle10gconsistent（logminer），如果您的数据库是9i或者11g，请选择对应的选项，这里假设源数据库为10g。

导入完成后，您可以打开窗口左手的CDC项目，到knowledge module下查看导入的knowlegemodule是否存在以及其选项。

我们点击左手下面的model标签，创建一个新的model，名字叫odi_cdc，如下图所示：

在reverse标签页中，选择standard（如果选择customized,则需要在项目中导入新的知识模块），context选择dev，然后点击selective reverse标签，如下图：

在该标签页下选择您需要导出元数据的表，最后点击reverse，新的model 就生成了。

最后选择journalizing标签页，journalizing mode选择consistent set，knowledge module选择刚才我们导入的JKM,这里有几个选项，一个是

asynchronous_mode,该选项如果选no，则变换数据捕捉采用基于trigger的方式（隐形trigger，用户见不到trigger的存在），如果选择yes，则采用stream方式，这里我们选择yes。另外一个参数是auto_configuration，该参数如果选择yes，ODI 会自动修改系统参数，以保证stream正常运行，其前提是我们定义的用于连接源数据库的用户具有DBA权限。在生产系统中，不建议打开该参数，具体的配置请参见选项下面的说明。

至此所有的准备工作全部完成，我们下面要做的才是如何配置变化数据捕捉。变化数据步骤可以在model级别上进行，即对一个model中的所有表都进行变化数据捕捉，也可以对model中的一个或者几个表单独配置，这里方便起见，我们在model级上进行配置。

右键点击model窗口的ODI_CDC，选择change data capture->add to CDC,如下图所示：

然后双击model窗口中ODI_CDC,选择journalized tables标签，对变化数据步骤的表排序，对于有主外键关联的表，主表一定放在子表前面。

最后选择start journal，这一步实际上是在源系统中建立变化数据捕捉的过程。

启动后，我们到operator窗口中去监控执行的结果，如果没有什么意外，

一般首次执行会成功，如果出现意外，可以双击出错的步骤，查找出错的原因，然后修改即可，大部分错误都落在以下三类里面：

1.数据库状态不对，如noarchivelog。

2.用户权限不足

3.以前安装过变化数据捕捉，环境没有清理干净。

大家如果感兴趣，可以一步一步分析一下start journal到底在数据库里干了哪些事情。

如果以前start journal没有成功，最好先执行drop journal，然后再start journal，这样可以保证源系统是干净的环境。

最后，要订阅该变化数据捕捉，如下图：