ODI经典案例分析三

ODI经典案例分析（三）
经典案例九
关于表空间数据文件的自动扩展研究
案列介绍：
事件的缘由是南京师范大学，研究生系统的表空间数据文件无法自动扩展，导致ODI 无法与各个系统之间进行数据同步，系统页面显示异常等各种问题。

上海剑桥学院也出现表空间无法自动扩展的事件，导致ODI所有的接口都停在了第一步drop work table，无法继续执行下去。

案例分析：
现在我们主要利用到的是控制用户所占表空间的额度大小。

在一些的数据库应用中，我们需要控制某个用户或者某一组用户其所占用的磁盘空间，防止硬盘资源被耗尽。

所以，在数据库中，我们也需要限制用户所可以使用的磁盘空间大小。

为了达到这个目的，我们就可以通过表空间来实现。

表空间的数据文件大小维护可以选择手动添加数据文件，也可以设置数据文件自动扩展。

手动添加可以更好控制磁盘空间，更有利于对数据库的维护。

而自动扩展好处是，无需人员频繁去管理，减少工作量。

缺点是，自动扩展的数据文件不可控，数据文件的无限扩张可能超出系统限制从而出现故障。

但是在我们对ODI的主存储库与工作资料库的用户一般是选择使用数据文件自动扩展的功能，更方便于ODI的使用。

一般创建一个可以自动扩展的表空间，使空间在使用完毕之后不影响ODI正常运行自动扩展100M，语句如下：
create tablespace TS_ODI_D datafile '+DATADG/urpdb/datafile/ts_odi_d.dbf' size 3072M autoextend on next 100M MAXSIZE UNLIMITED;（注意：表名与路径要与数据库中已存在的一致）
若无法自动扩展，首先查看表空间是否开启了自动扩展：
Select tablespace_name,file_name,autoextensible from dba_data_files where tablespace_name = 'T_ODI_D';
发现autoextensible的状态为NO，即是关闭了自动扩展的功能，需要设置为YES，以启用自动扩展的功能。

若表空间没有设置自动扩展的功能，用以下语句实现：
ALTER TABLESPACE T_YJS_APP ADD
DA TAFILE '+DATADG/urpdb/datafile/usr_odi_d.dbf' SIZE 2048M AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED；
案例总结：
总的来说，表空间的自动扩展的优势是，不会出现因为没有剩余空间导致数据无法写入；把人工维护量缩减到最低。

但如果任其扩展的话，在数据量不断变大的过程中会导致某个数据文件异常的大，若无人管理，造成很严重的后果。

所以就算是表空间设置了自动扩展，也需要人工进行例行的巡检，以确保数据文件大小不会失控，造成更大的损失。

经典案例十
增量同步应该注意的事项
案列介绍：
起因是东华大学ODI人事数据增量同步报错。

我们知道，ODI在做数据量较大的数据表之间的数据集成时，使用增量集成相比全量集成可以大大增加接口的执行效率，缩减执行时间。

所以在做数据量较大的集成时，我们一般会做一个简单的增量集成。

但东华大学增量集成的同步报错，反映了增量集成也许注意一些细节。

案例分析：
现在主要做的是通过触发器方式，通过在数据源上建立触发器，然后通过触发器来记录数据源上的变化数据，再将变化了的数据集成到目标库中，而没有任何变化的数据不做同步，触发器方式要求业务系统数据库赋予数据集成用户在数据源上建立触发器及视图的权限。

简单性增量集成是利用触发器做增量集成的一种，简单性是指每个表的变化都是独立捕获的，不需要考虑多张存在主外键引用关系的表之间的数据一致性。

通过与东华大学的老师沟通发现，因为业务需要，为了增加某个字段的映射关系，必须先进行一次全量同步，而此接口正在进行的增量同步，因此需要先将接口进行一次全量同步，之后才能进行增量同步。

在进行接口设计时的时候，将只同步日记记录的数据选项的勾去掉如图（1），然后执行接口，进行数据同步，数据可以正常进行集成！然后再把仅以进行日记记录的数据，图（1）中红色框中的内容勾选上，最后将方案重新生成一下，完成增量集成！
图（1）
案例总结：
在做过增量集成之后，增量同步是建立在全量同步基础之上的，所以在进行增量同步之前必须要进行一次全量同步！在表结构改变或者映射改变之后，进行全量集成，必须注意步骤。

经典案例十一
关于临时表的重名问题的解决
案列介绍：
我们在做数据集成时，通常会遇到多个数据源的数据都需要向同一个目标数据库的表进行数据同步时，在执行期间，会导致目标数据库的临时表产生冲突。

导致接口执行卡死或者报错，无法正常进行数据的同步。

案例分析：
这种情况类似因为你在执行存储过程之前已经创建了一个#Test表执行存储过程时又创建一个#Test，这时候创建是不成功的，所以#Test里的列名只有A，而没有B在存储过程中向#Test表的B列插入数据，当然插不进去，因为B列不存在。

经过分析设计，如果将目标表同名的接口，放在同一个包里面执行，这样就避免了临时表冲突的问题，因为他们就会有一个先后执行的顺序，尽量避免让它们在一个未执行结束之前执行另外的数据，再设置合理的执行计划和周期，以避免由于同名的目标表导致临时表的冲突。

案例总结：
遇到类似问题，先进入数据库查询有没有同名的临时表，若存在同名的临时表，先进性删除，然后单独执行各个接口。

尽量设置接口在同一个包里面，制定合理的执行计划，以避免由临时表重名引起的冲突。

经典案例十二
本地图片文件的集成方案
案列介绍：
案例讲解的主要内容是为了实现在实施过程中出现的“本地图片文件集成至Oracle Blob 字段”的需求。

案例分析：
做ftp上多个图片文件集成到oracle的blob字段，用到的IKM是IKM Binary File to Oracle BLOB Local，如图（2）所示：
图（2）
做一个测试接口T_BD_BLOB_ZP_TEST（如图3），目标表是T_BD_ZP，本地存放图片的文件夹是：D:/TEST，文件夹下的照片类型全都是.jpg。

图（3）
KM的选择如图（4），注意SRC_DIR的值的选择，必须是d:/test而不是d:\test
图（4）
案例总结：
采用IKM Binary File to Oracle BLOB_ftpbatchimage做ftp图片文件的集成，须保证ODI、ORACLE数据库服务器、本地存放图片的临时文件夹这三者在同一台Server上。

在集成进行之前，要对IKM进行修改，如ftp的IP地址，登录名、密码、文件名后缀、路径。

要注意目标表的user的权限，看是否有CREATE ANY DIRECTORY的权限。

对ftp的一些处理方法可以查看%odi_home%\oracledi\lib\scripting\Lib\snpsftp.py文件。

文档中的IKM Binary File to Oracle BLOB_ftpbatchimage保存在当前目录的KM文件夹中。

木香果旗舰店
提供。