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

上传人:b****8 文档编号:9883384 上传时间:2023-02-07 格式:DOCX 页数:18 大小:721.43KB
下载 相关 举报
ODI如何通过logminer技术从oracle 数据库中抽取增量数据.docx_第1页
第1页 / 共18页
ODI如何通过logminer技术从oracle 数据库中抽取增量数据.docx_第2页
第2页 / 共18页
ODI如何通过logminer技术从oracle 数据库中抽取增量数据.docx_第3页
第3页 / 共18页
ODI如何通过logminer技术从oracle 数据库中抽取增量数据.docx_第4页
第4页 / 共18页
ODI如何通过logminer技术从oracle 数据库中抽取增量数据.docx_第5页
第5页 / 共18页
点击查看更多>>
下载资源
资源描述

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

《ODI如何通过logminer技术从oracle 数据库中抽取增量数据.docx》由会员分享,可在线阅读,更多相关《ODI如何通过logminer技术从oracle 数据库中抽取增量数据.docx(18页珍藏版)》请在冰豆网上搜索。

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

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

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

(一)收藏

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

OracleSimple

OracleConsistent

Oracle9i/10g/11gConsistent(LOGMINER)

Simple方式一般是针对数据库中需要增量复制的表之间没有主外键约束的情况,在这种方式下,表之间的先后复制关系没有影响。

但如果表之间有主外键对照关系,采用simple方式就会出现问题,举个简单的例子,我们需要从源数据库抽取两张表订单和订单明细表的增量数据,其中订单明细表的外键要参照订单表的主键。

1.      我们将订单表中主键从11000-25000的增量数据复制到目标端。

2.      在复制的过程中,源端订单表又插入了两条新数据,主键为25001和25002。

3.      当进行订单明细表的增量数据复制时,与订单表中主键25001和25002对应的明细数据就会在目标端出错,因为刚才复制时,这两条数据没有复制到目标端。

Consistent方式就是专门来解决这个问题的,它在处理父表前首先锁定(注意不是锁住)主表和子表需要复制的记录,在增量数据复制时,插入主表和子表的新增量数据都会被本次抽取过程忽略,放在下次抽取时处理。

因此采用Consistent方式进行增量数据捕获一般需要5个步骤:

1.      扩展窗口(extend_window):

计算主表和子表本次抽取的结果集,并赋予其一个序列号。

2.      锁定订阅者(locksubscriber):

针对变化数据的某个订阅者,确定其需要抽取的序列号范围(一个系统的变化数据可能会被多个系统使用,比如主数据管理系统)。

3.      执行抽取过程,我们通过ODI中的接口程序进行实现。

4.      抽取完成后,解锁订阅者(unlocksubscriber):

记录下本次抽取的最后的序列号,以便于下次使用。

5.      清除增量数据(Purgethejournal):

将已经复制完成的增量数据清楚(这里是指所有的订阅者)。

 

在具体的实现方式上,OracleSimple、OracleConsistent是采用同步方式进行增量数据抽取的,说白了就是在源系统相关表上添加触发器,如下图所示:

 

当源数据库中的交易需要修改相关表时,会调用触发器,将变化数据插入到增量表中,触发器的调用是包含在交易中的,这就决定了变化数据的实时性高,在需要实时变化的场景,非常适用,而且这种方式在数据库非归档状态下也照常运行,其缺点是由于触发器包含在对数据修改的事务中,当系统并发量比较大时,会对原有系统的效率产生一定影响。

很多同事一听说触发器就觉得对源系统影响非常大,其实并不是这样。

这里需要澄清的一点概念是触发器往变化数据表中写的并不是所有变化的数据,而可能只是一个主键或者再加一点额外的信息,其对系统的影响比我们想象的要小得多。

Oracle9i/10g/11gConsistent(LOGMINER)方式可以配置成异步方式,基于Oracle数据库的onlineredolog进行变化数据的捕捉(这里要特别提醒的是目前ODI只支持Hotlog方式),说的更白一点就是oraclestream技术,变化的数据通过logminer技术从在线日志中获取。

如下图所示:

 

这种方式基于异步的策略,一般变化数据的获取会有1秒到几分钟的数据延迟,当然对数据仓库系统来讲,这点时间也不算啥。

但是由于其从日志中抽取变化数据,对原有的生产系统影响很小,而且该方式在用户原来的schema上除了一个读权限外,不需要额外的权限要求,因此大多数用户都愿意采用这种方式。

但该方式需要对用户有一定的权限要求,而且数据库必须运行在归档模式下。

具体的配置我们下次再说。

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

(二)收藏

在ODI中通过logminer方式进行变化数据捕捉,需要首先做一些基本工作:

1.      修改数据库启动参数:

altersystemsetglobal_names=TRUEscope=BOTH;(如果您的系统里有dblink也可以不修改,到时候修改ODI的也可以)。

altersystemsetjob_queue_processes=6scope=BOTH;

altersystemsetopen_links=4scope=SPFILE;

altersystemsetstreams_pool_size=200Mscope=BOTH;

altersystemsetundo_retention=3600scope=BOTH;

JOB_QUEUE_PROCESSES(currentvalue)+2

PARALLEL_MAX_SERVERS(currentvalue)+(5*(thenumberofchangesetsplanned))

PROCESSES(currentvalue)+(7*(thenumberofchangesetsplanned))

SESSIONS(currentvalue)+(2*(thenumberofchangesetsplanned))

Open_cursors一定要大一点(建议1000以上),尤其是10.2.0.4之前的版本。

 

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

 

SQL>selectlog_modefromv$database;

 

LOG_MODE

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

ARCHIVELOG

 

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

SQL>conn/assysdba

Connected.

SQL>shutdownimmediate

Databaseclosed.

Databasedismounted.

ORACLE instanceshutdown.

SQL>startupmount

ORACLEinstancestarted.

 

TotalSystemGlobalArea 301989888bytes

FixedSize                 1267140bytes

VariableSize            163580476bytes

DatabaseBuffers         130023424bytes

RedoBuffers               7118848bytes

Databasemounted.

SQL>alterdatabasearchivelog;

Databasealtered.

SQL>alterdatabaseforcelogging;

 

Databasealtered.

SQL>alterdatabaseaddsupplementallog data;

 

SQL>alterdatabaseopen;

 

Databasealtered.

 

 

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

 

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

createtablespaceTS_ODI

 datafile'/uo1/app/oracle/oradata/test/ts_odi.dbf'

  size8192m

  autoextendon

  next32mmaxsize20480m

 extentmanagementlocal;

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

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

CREATEUSERcdcadmin

IDENTIFIEDBYcdcadmin

DEFAULTTABLESPACETS_ODI

TEMPORARYTABLESPACEtemp

 

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

--systemprivs

GRANTcreatesessionTOcdcadmin;

GRANTcreatetableTOcdcadmin;

GRANTcreatesequenceTOcdcadmin;

GRANTcreateprocedureTOcdcadmin;

GRANTcreateanyjobTOcdcadmin;

 

--roleprivs

GRANTexecute_catalog_roleTOcdcadmin;

GRANTselect_catalog_roleTOcdcadmin;

 

--objectprivileges

GRANTexecuteONdbms_cdc_publishTOcdcadmin;

GRANTexecuteONdbms_cdc_subscribeTOcdcadmin;

 

--streamsspecificpriv

executedbms_streams_auth.grant_admin_privilege('CDCADMIN');

 

grantselectonanytabletocdcadmin(这里其实只要对生产系统需要捕获数据的schema相关表授权即可,这样设有点大,这里只是为了简单)。

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

如果管理员坚决不能给您DBA权限,那也可以到knowledgemodule中修改其step即可,将需要DBA权限的步骤在knowledgemodule中去掉,让管理员帮忙做一下(其实只有一个步骤需要DBA,也就是这一句话alterdatabaseaddsupplementallogdata)。

如果管理员连这也不同意,那就没招了,等死吧。

 

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

1.      打开topologymanager,在物理体系架构上建立一个物理服务器(这里我们假设oracle数据库中生产数据存储在shschema上)。

在定义上起个名,输入连接数据库的用户名口令:

cdcadmin/cdcadmin.

 

2.      点击JDBCTAB页:

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

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

 

 

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

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

 

在上下文里我们将其物理架构定义为SH.SH,如果您的系统里没有上下文(context),自己建一个就是了,然后将对应关系配置好即可。

至此,存盘退出topologymanager.

 

ODI如何通过logminer技术从oracle9i或者10g中抽取增量数据(三)收藏

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

右键点击项目名称,选择import->importknowledgemodule

进入$ODI_INSTALL/oracledi/impexp/目录,然后选择JKM Oracle10gconsistent(logminer),如果您的数据库是9i或者11g,请选择对应的选项,这里假设源数据库为10g。

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

 

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

 

在reverse标签页中,选择standard(如果选择customized,则需要在项目中导入新的知识模块),context选择dev,然后点击selectivereverse标签,如下图:

 

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

 

最后选择journalizing标签页,journalizingmode选择consistentset,knowledgemodule选择刚才我们导入的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->addtoCDC,如下图所示:

 

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

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

 

 

启动后,我们到operator窗口中去监控执行的结果,如果没有什么意外,一般首次执行会成功,如果出现意外,可以双击出错的步骤,查找出错的原因,然后修改即可,大部分错误都落在以下三类里面:

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

2.      用户权限不足

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

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

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

最后,要订阅该变化数据捕捉,如下图:

用户名一般为SUNOPSIS,当然您也可以自己定义,但前提是必须在interface中将订阅的默认用户名修改成您自己定义的名称。

刷新整个窗口,我们可以看到定义了变化数据捕捉的表在左上角都有一个绿色的小时钟,这代表目前变化数据捕捉工作正常,如果是黄色,则代表有问题,您可以到operator窗口检查到底哪里出了问题。

至此变化数据捕捉的的配置全部完成,剩下的就是如何使用了。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 其它

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1