文档介绍：;对于数据量大的关键性的动态表(例如basetab表),要求割接当晚全部导出并转换后导入,数据量越大,数据导出,转换,导入所用时间越长,而割接当晚通常需要留一部分时间拨测,以及处理一些其他可能出现的问题,所以割接当晚用在导数据上的时间应该需要尽可能的压缩,这样,使用增量导入的方法,,是指利用前期准备的充裕时间先将大表数据割接过来,建好索引,然后编写脚本(或程序)每天执行一次,,比如可提前1~3天,利用晚上闲时将SDP上basetab_206导出,使用ipload导出时select操作不会锁表,呼叫流程可正常处理basetab_206表,只是分多个文件并行导出时,onpload进程对包括CPU,I/,以后每天执行一次增量导入脚本,以basetab_206表最后使用日期lastusedatetime字段,,不修改basetab_206的lastusedatetime字段,所以不能以该字段做为判断条件,后来在SMP上割接basetab_206表过程中估算当晚在SDP上割接basetab_2061900万数据时所用时间在3个小时左右,时间上可以接受,,也可考虑以下两种方式作为增量导入条件:方式1、以话单文件、密码修改日志表ucs_passwordlog、转帐日志表ucs_transferlog为增量判断条件,对于话单文件可在脚本中增加对stopdatetime字段所在域值进行判断,对于密码修改日志表,先前设定为不记录密码修改,可提前几天在SMAP上设定密码修改需要写入密码修改日志,转帐日志表可按正常情况判断。方式2、新建一个重入触发器trigger,ountleft,pinnumberonbasetab_206foreachrow(updatebasetab_206setlastusedatetime=to_char(current,'%Y%m%d%H%M%S'))针对可能变化的关键字段,触发操作修改lastusedatetime,这样可避规IPT流程不修改lastusedatetime的情况,仍可使用增量导入的方法,只是呼叫量大时,这种foreach操作对业务是否有影响,是否会引发消息间超时,可能需要模拟测试。对于informix的查询机制,有一点值得注意。在前期准备过程中,在执行如下操作:esstellin21<<!!!*frombasetab_206wherelastusedatetime[1,8]>='20021013';!!!由于lastusedatetime字段无索引,将2002年10月13日及其以后改动了的basetab_206卡数据导出过程中,如果其间某张卡的卡号密码鉴权又通过了一次,即lastusedatetime字段又有改动,则查询在顺序扫描整个表时可能出现导出两条、ountnumber相同,lastusedatetime不同的数据。后咨询informix工程师,原因在于:mittedRead(确认读隔离):该级别保证每次读到的都是最近依次提交时的数据。在读完一个记录后,由于再也没有锁加在其上,故其他进程可以删除或修改这个记录。pliant有日志数据库的缺省隔离级别(informixSQL与ANSISQL兼容,但不包括ANSISQL的扩展),此时数据库服务器保证不返回数据库中未确认的行,这个操作可以防止读取未被确认而后又撤消的数据(不存在地数据)。也即2005-06-21第1页,共6页内部资料,请勿扩散大数据量割接总结文档密级是当我们在执行unloadto语句时若没有指定隔离模式,mittedRead隔离级,也即该模式将保证每次读到的都是最近提交的数据,一旦新提交的事务修改了已查询过的行,mittedRead隔离级会保证再次检索该行。所以上述情况的发生就是因为当查询过程中某条记录对应的lastusedatetime字段发生更新,即该字段在对应的物理位置上发生了改变,则数据库会重新检索该where条件字段物理位置上已发生了改动的记录,致使上述情况发生。对于这种数据,ountnumber上的唯一索引致使新状态lastusedatetime对应记录无法导入,若在脚本中进行处理,ountnumber对应lastusedate