单位最近有一些需求,我在做一些设计.其中有一些想法想和大家讨论一下看看实现的难度和可行性.
总体目标:将400上的PF在PC平台实现数据同步,不需要实时同步,日同步可以了.
数据量:目前基本上400 PF的最高数据量是在百万级的,部分PF每日增量在万级,日后增长量会增加但不会到10万级.
目前的解决方案,使用SQL,FTP等技术直接实现数据筛选,然后进行抽取同步,带来的问题是由于业务逻辑的问题,抽取后同步时无法做到数据完全一致.同时一些使用SQL更改或插入的数据是无法利用业务逻辑完成的.
所以我考虑使用日志做为新的解决方案.这个方案应该是一个比较通用的解决方案了现在一些双机热备都是使用这样的方案.,不过不好意思的说我还没做过这样的项目,有些技术细节还请大家帮忙.
1.如何解析400的日志信息.解析这部分信息是必须在400处理还是可以在PC端解决.关于日志的部分看哪本书里介绍的比较全.
2.如果可以在PC端解析,那么日志的分拆和下传如何实现
现在好多东西还都是有想法没方案,知道可以做不知怎么做,还请大家给些概念.
jance 回复于：2006-08-07 14:03:10
我不会，但是希望你能在最终实施之后，弄个文档，传上来，让我学习学习，呵呵，先谢谢了并祝你成功！
xuguopeng 回复于：2006-08-07 14:30:52
我们是在每天批次作业完毕后,利用SQL SERVER的DTS将400的数据抽取下来,但我们抽取的数据量不是很大,所以没有过一夜也传不完的情况.
读取日志到不难,主要是如何分析并传送.............期待高见.....
子樵 回复于：2006-08-07 14:49:39
其实不是量大小的问题.而是1.有些业务不是单独增加的,修改的记录如何用业务逻辑同步是很容易出错的.2.后台认为使用的SQL的一些操作很难通过PF识别出来,这个会造成同步异常,所以才想到用日志.
blogliou 回复于：2006-08-07 15:05:39
把400上日志传到PC机备份,需要时再把日志从PC传回400恢复,这是可以的,上海某公司就有这么一个现成产品. 至于要把数据解析出来写到PC的表上,关键看物理表的RRN是否对应.
[ 本帖最后由 blogliou 于 2006-8-7 15:06 编辑 ]
qingzhou 回复于：2006-08-07 17:02:10
目前这边对于DB2/400与SQL2000同步的问题，是使用了第3方软件DBMOTO for NT来实现，可以做到几乎是实时，价格应该不贵，比较省事去折腾同步。
仅给个建议。
子樵 回复于：2006-08-07 17:58:39
谢谢各位了.很久没露头了,最近比较闲,可以关心些技术问题了.过几天就又该潜水了.呵呵.
说实话这个问题想了很久了,第三方软件也是考虑的,只是一直觉得解析日志和根据日志同步应该是个比较成熟的技术了.热备的卖点其实是是如何及时恢复处理,这个虽然是核心但如果对时效要求不高应该可以试试.
其实说实话这块我也不会 :em15:.
qingzhou 回复于：2006-08-08 15:17:10
有个疑问，通过FTP成功定时将JRN传输到PC端了，对于400，是可以识别这些JRN，也可以通过RMVJRNCHG来恢复数据达到近似同步点；但是，传递到PC端的SQL2000、ORACLE，这些数据库是否也可以解析400的JRN呢，是否也可以RTV数据出来？
为了减轻传输的压力，可以先在400端过滤、筛选出符合条件的记录单独放在新表中，然后用SQL2000带的DTS来尝试定时、直接传输DB2/400—>SQL2000中。
关于DBMOTO的介绍，可以浏览参考：
http://www.hitsw.com/products_services/dbmoto/dbmoto.html
xuguopeng 回复于：2006-08-08 16:20:00
我觉得不应该是把JRN复制到PC,而应该是在400端对JRN ENTRY分析完后的结果传到PC上,然后执行相应的增删改操作.这样难度应该会小一些吧
大胆假设一下:
先RTVJRNE,然后根据JRN的操作CODE来判断是什么操作,然后根据更新前后的数据对比来生成SQL语句并传到SQL SERVER,最后在SQL SERVER执行更新
关键是分析JRN ENTRY,这块难度应该不小........
这些想法只针对于数据的操作,对OBJ的增删改是不起作用的........
而且LZ所说的只是单向的同步? 还是双向的?
[ 本帖最后由 xuguopeng 于 2006-8-8 16:21 编辑 ]
zyzng 回复于：2006-08-08 16:55:57
用trigger可以吗？比如sql server或db2/400每新加一笔就同步对方
子樵 回复于：2006-08-08 19:17:09
目前的设计只是简单的单向数据同步.我需要将400上的业务数据提供给下面的数据仓库使用.一般情况下从PC向400同步是很少的,因为这种数据插入必须是经过业务逻辑验证后的,否则很难解决数据关联问题.
日志这块我技术上不过关,说个想法.
在400上分拆日志记录,并过滤解析(这个是现在最头痛的根本就不懂),然后一定的格式存入PF(这点和GUOPENG 的想法有点不同),FTP 此PF到PC,
PC端根据PF的记录在对应的DATA SET中处理记录.PC的DATA SET和400上的同步PF的格式和数据顺序应该是一致的.
xuguopeng 回复于：2006-08-09 10:00:42
存入PF我觉得不是太好,只要记录JRN ENTRY的sequence number号做为CHECK POINT就好了,如果存入PF势必会对性能造成很大影响,而且这个PF将无比巨大.
如果是按照这种做法的话,根本就没有必要用JRN去实现了,只要机器够强,干脆给所有PF加上触发器, 这样就不用费劲去琢磨怎么分析JRN ENTRY了
如果用JRN去实现,其实我觉得关键是怎么读取实际的数据,我用DSPJRN找到UPDATE前后的ENTRY,进入根本看不到实际的数据(有的是看不懂,有的是乱码),但却能用他进行恢复,400系统可以识别这些ENTRY,但PC肯定就不行了..........
这里没有对MIMIX或OMS比较熟的人么? 出来讲解一下
zyzng 回复于：2006-08-09 13:48:47
journal里看到的是一个record的内容，所以如果定义一个data structure和pf一样就可以用move，eval来抓取journal
xuguopeng 回复于：2006-08-09 15:00:59
楼上的实际实验过么? JRN ENTRY里可以看到英文或数字的数据,中文是不行的.
zyzng 回复于：2006-08-09 15:22:41
那可能要看hex格式才可以了
xuguopeng 回复于：2006-08-09 15:40:46
那总不能以16进制在PC端保存吧?
也不知道在400上能否把16进制转成汉字? 开发我不在行,子樵看看如何
zyzng 回复于：2006-08-09 16:19:52
我觉得可以这样。比如说一个pf.有3个fields.record length 是50.
首先在program中定义一个temp field为５０的char类型。再定义一个data structure和pf一样结构。
从journal中接收到的放到temp field中去，再用move,eval移到data structure。接着用write写到file里
xuguopeng 回复于：2006-08-09 16:38:24
只要能从JRNE中取出数据,那问题就应该不大了.
只要弄清楚各个JRN CODE和TYPE的作用就可以了
子樵 回复于：2006-08-10 09:44:17
zyzng 的答复,让我信心大增.
一直觉得比较头疼的是如何去获得JRN ENTRY中的信息,并把他转为可用.
blogliou 回复于：2006-08-10 12:40:59
引用：原帖由 xuguopeng 于 2006-8-9 15:00 发表
楼上的实际实验过么? JRN ENTRY里可以看到英文或数字的数据,中文是不行的.
用WRKMBRPDM选一个文件用5看到的东西与JRN ENTRY里的内容就是一样的/
大肥肥 回复于：2006-08-10 14:16:12
引用：原帖由 子樵 于 2006-8-10 09:44 发表
zyzng 的答复,让我信心大增.
一直觉得比较头疼的是如何去获得JRN ENTRY中的信息,并把他转为可用.
我感觉从JRN ENTRY里面获得的信息，很难完全解析。你不但需要After image的JRN, 还需要Before image的
JRN, 否则如果纪录被删除了， After image的jrn entry里面是没有什么内容可查的。。。。。。
davis1220 回复于：2006-08-10 15:01:25
我不太懂这些，但我感觉有一个软件可以data mirror的transfer server
hanyu 回复于：2006-08-10 19:02:35
如果是每天批量同步解决方案很多 odbc jdbc ftp dts ....
但如果是实时同步，
国内实现400的数据实时同步到PC数据库的有 data mirror 和 data bridge ，都是利用jrn 实现的，
大概的思路是：
首先通过odbc,jdbc 在PC端建对应400的表格。
批量同步一次，让PC同步400到某一日志序号前的状态。
读取400日志接收器后的数据
简化一下，如果不考虑效率问题，jrn 的MINENTDTA 用 *none ,那么日志Entry 就包含完整的纪录hex 表示。
如果PC数据库支持用纪录顺序号RRN操作，就很简单了，日志Entry包含完整纪录顺序号和文件的after image
直接读取日志，转码，传PC，同步操作PC数据库。
如果PC数据库不支持用纪录顺序号操作。。。。
同步文件需要有唯一索引，必须登记before image
对于update ,delete 操作，需要读取before image ，把索引字段解析出来，把增删改组成sql语句，一起传下去，PC数据库同步执行sql语句。
hanyu 回复于：2006-08-10 19:13:12
补充一下，如果是同步到另一台400上，是可以直接用日志序号写的，还不用转码，所以实时同步PC比同步400更复杂，如果用索引同步，大数据量的情况下，对PC的性能要求极高。
|
