大数据量割接总结.pdfVIP

大数据量割接总结 文档密级 大数据量割接总结 一. 关于增量法 ; 对于数据量大的关键性的动态表 ( 例如 basetab 表), 要求割接当晚全部导出并转换后导入 , 数据量越大 , 数 据导出 , 转换 , 导入所用时间越长 , 而割接当晚通常需要留一部分时间拨测 , 以及处理一些其他可能出现的问 题, 所以割接当晚用在导数据上的时间应该需要尽可能的压缩 , 这样 , 使用增量导入的方法 , 可以尽可能缩短 数据割接时间 . 增量的方法 , 是指利用前期准备的充裕时间先将大表数据割接过来 , 建好索引 , 然后编写脚本 ( 或程序 ) 每天 执行一次 , 用来割接当天改动过的表数据 . 已本次 UCS割接到 ICARD为例, 比如可提前 1~3 天, 利用晚上闲时 将 SDP上 basetab_206 导出, 使用 ipload 导出时 select 操作不会锁表 , 呼叫流程可正常处理 basetab_206 表, 只是分多个文件并行导出时 ,onpload 进程对包括 CPU,I/O 在内的系统资源占用情况需要考虑 . 利用程序 转换后再导入新表 basetab_ccs, 以后每天执行一次增量导入脚本 , 以 basetab_206 表最后使用日期 lastusedatetime 字段 , 以及 UCS转帐日志表 ucs_transferlog 为条件增量导入某时间点以后改动后的卡数 据. 参考脚本见附件 migrate.sh 因 IPT 流程中使用 UCS卡数据时 , 不修改 basetab_206 的 lastusedatetime 字段 , 所以不能以该字段做为判 断条件 , 后来在 SMP上割接 basetab_206 表过程中估算当晚在 SDP上割接 basetab_206 1900 万数据时所用 时间在 3 个小时左右 , 时间上可以接受 , 所以没有使用增量导入的方式 . 实际上若某些流程不修改 lastusedatetime 字段 , 也可考虑以下两种方式作为增量导入条件 : 方式 1、以话单文件、密码修改日志表 ucs_passwordlog 、转帐日志表 ucs_transferlog 为增量判断条件， 对于话单文件可在脚本中增加对 stopdatetime 字段所在域值进行判断， 对于密码修改日志表， 先前设定为 不记录密码修改 , 可提前几天在 SMAP上设定密码修改需要写入密码修改日志，转帐日志表可按正常情况判 断。 方式 2、新建一个重入触发器 trigger ， create trigger ucs_base_update update of accountleft,pinnumber on basetab_206 for each row (update basetab_206 set lastusedatetime=to_char(current,%Y%m%d%H%M%S)) 针对可能变化的关键字段， 触发操作修改 lastusedatetime ， 这样可避规 IPT 流程不修改 lastusedatetime 的情况，仍可使用增量导入的方法，只是呼叫量大时，这种 for each 操作对业务是否有影响，是否会引发 消息间超时，可能需要模拟测试。 对于 informix 的查询机制，有一点值得注意。在前期准备过程中，在执行如下操作： dbaccess tellin21 !!! unload to usedcards_tmp.unl select * from basetab_206 where lastusedatetime[1,8] =; !!! 由于