| 关于client copy 请教问题 | ||
| 目前这里生产系统数据大概300G不到，但是要从生产机到测试机做client copy 要很长时间，一 次用scc3开启任务，足足copy了3天才copy了17%的表数据，这个是什么原因阿？哪位大侠说说看, 谢谢啦！ |
||
==========================================================================
楼主其实本身的操作没有讲清楚，首先SCC3应该不是启动Client Copy的事务吧，只是大家从你说
的“生产机到测试机”的Client Copy，大家推测你可能是做了Remote Client Copy（SCC9），这
恰恰是系统间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 Copy（System
Refresh/Homogeneous System Copy/Heterogeneous System Copy)，哎，这真是个粗暴的方案啊，
前面那些Client Copy，不就一个一个数据库表复制嘛，太费力了，得，我给你来个狠的，把你整
个数据库都复制过来，那些表还不在话下？无语了，真的是很快很暴力啊，基本是就是数据库数
据文件复制/恢复的时间（这可是顺序写啊，比起Client Copy的随机写那强的不是1、2倍啊），
不过呢，目标系统，目标系统原来的环境就彻底88了，整个儿数据库都变成人源系统的，什么
Client、用户、业务数据和生产系统那是一模一样啊，自个儿原来的什么都没了，你觉得行？那
就下手吧，不过这个真是个粗暴的活，在你的Landscape允许的情况下再着手吧