辽宁网站制作公司,大同网站建设,诸暨北京网站制作公司有哪些,网站建设程序有哪些关于client copy 请教问题目前这里生产系统数据大概300G不到#xff0c;但是要从生产机到测试机做client copy 要很长时间#xff0c;一 次用scc3开启任务#xff0c;足足copy了3天才copy了17%的表数据#xff0c;这个是什么原因阿#xff1f;哪位大侠说说看, 谢谢啦但是要从生产机到测试机做client copy 要很长时间一 次用scc3开启任务足足copy了3天才copy了17%的表数据这个是什么原因阿哪位大侠说说看, 谢谢啦 楼主其实本身的操作没有讲清楚首先SCC3应该不是启动Client Copy的事务吧只是大家从你说 的“生产机到测试机”的Client Copy大家推测你可能是做了Remote Client CopySCC9这 恰恰是系统间Client Copy不推荐的一个方案Remote Client Copy往往只适用的数据量较小复 制期间源系统数据变化较少业务操作较少生产系统能行的场合 Remote Client Copy是个同步复制方案源系统读取数据→传输数据→目标系统写入数据→响应 源系统。这样的过程重复重复再重复正有如yishenglww坛友指出的你可以想像得出完成每批 数据复制的过程受影响的因素可真不少啊碰上一些大表估计你们系统里超过10G的表也应该有 甚至也不少了yishenglww坛友客户地说了说最大表不用最大就够费力了数据库层面还要 准备Rollback这可真是大量的系统开销啊想快也很难啊可怜的硬盘啊 如果Remote Client Copy持续的时间过长是非常容易产生数据不一致的比如说VBAK是在KNA1 后复制的这样就可能在复制完KNA1后新创建了一个客户并且在复制VBAK前建了对该客户的 SO这样复制过去的目标系统里就奇怪了看得到SO但是SO中的客户就不知道哪来的了这样 系统就不一致了 而且Remote Client Copy还有一个致命的毛病如果源系统和目标系统中的某一个数据库表对象 不用多一个就行的数据结构不一样测试机也不能就保证一定和生产机完全一样该表 的复制就失败了而且会连累整个Client Copy失败汗呐辛苦了半天可能一个小小差异就整 个儿失败了想想就头大吧能不用就不用吧 idhly坛友建议的Client Export/Import是常用的Client Copy的方法这个则是一个异步复制方 案源系统SCC8导出Client生成传输文件→目标系统Client传输导入(STMS)→目标系统导入后后 继处理SCC7这个方案相对于Remote Client Copy对源系统影响较小源系统在Client Copy的过程中无需等待目标系统的复制完成性能完全取决源系统的性能我不知道你的系统情 况但是我去年有印象的一个120G左右的系统导出花了大概6个小时的样子相对于Remote Client Copy那是好得多了你们300G的系统Export的话我也不知道你们的硬件情况下是怎样 的一个速度……而且注意Export生成传输文件是需要存储资源的SAP的压缩做得还不 错15:1也许是有的你就得考虑至少20G的传输目录自由空间DIR_TRANS)给Export别因为空 间不够最后还是白导了。导出的期间如果很长也是一样的有可能产生数据的不一致 另外对于目标系统这个导入的工作可就费事了要写这么多的数据库记录进来哈哈苦死 了临时表空间、回滚空间、日志无一不是陷阱这路也不好走啊不过试试总归可以没准 属于能接受的范围呢 最后其实不是最后不过就算今天的最后吧Basis钟爱的大招来了System CopySystem Refresh/Homogeneous System Copy/Heterogeneous System Copy)哎这真是个粗暴的方案啊 前面那些Client Copy不就一个一个数据库表复制嘛太费力了得我给你来个狠的把你整 个数据库都复制过来那些表还不在话下无语了真的是很快很暴力啊基本是就是数据库数 据文件复制/恢复的时间这可是顺序写啊比起Client Copy的随机写那强的不是1、2倍啊 不过呢目标系统目标系统原来的环境就彻底88了整个儿数据库都变成人源系统的什么 Client、用户、业务数据和生产系统那是一模一样啊自个儿原来的什么都没了你觉得行那 就下手吧不过这个真是个粗暴的活在你的Landscape允许的情况下再着手吧 转载于:https://www.cnblogs.com/diyang00242/archive/2009/03/11/1408606.html
