通过系统移动重置DMO以进行测试迁移

2020-08-18 20:27发布

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


我们希望将DMO与System Move一起使用,以将ECC Oracle从本地迁移到HANA上的AWS Suite; 在进行真正的迁移之前,我们将进行测试迁移。 我们现在知道源头的停机是不可避免的(即使对于测试迁移而言)。 我们期望它是一个高层次的系统:

  1. 使用源代码中的系统移动来运行DMO
  2. 进入停机时间
  3. 关闭源
  4. 完成源导出
  5. 在目标位置复制并继续SUM
  6. 重置源
  7. 开始源
  8. 在目标中继续DMO(模拟迁移)

问题:您对上述第(6)步有何经验? 重置花了多长时间(例如对于2TB数据库)?

从DMO指南看来,这只是为了删除影子表,因此通常不应持续超过半小时。 有想法吗?

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


我们希望将DMO与System Move一起使用,以将ECC Oracle从本地迁移到HANA上的AWS Suite; 在进行真正的迁移之前,我们将进行测试迁移。 我们现在知道源头的停机是不可避免的(即使对于测试迁移而言)。 我们期望它是一个高层次的系统:

  1. 使用源代码中的系统移动来运行DMO
  2. 进入停机时间
  3. 关闭源
  4. 完成源导出
  5. 在目标位置复制并继续SUM
  6. 重置源
  7. 开始源
  8. 在目标中继续DMO(模拟迁移)

问题:您对上述第(6)步有何经验? 重置花了多长时间(例如对于2TB数据库)?

从DMO指南看来,这只是为了删除影子表,因此通常不应持续超过半小时。 有想法吗?

付费偷看设置
发送
7条回答
我是小鹏鹏啊
1楼 · 2020-08-18 21:07.采纳回答

嗨,克里斯,

没有停机时间,就不会有"带有系统移动的DMO"。 但是,改编版的源系统可能会缩短还原时间,详细信息将在SUM 2.0 SP 08发布后提供。

也许我错了,但是 对于生产运行,还原时间不计入技术停机时间,因为您不继续在源系统上进行业务操作。

当然,您知道一般建议在测试系统上运行测试 真实的PRD系统副本,以便测试程序的停机时间不会损害业务。

最好,

Boris

lukcy2020
2楼-- · 2020-08-18 21:13

嗨,克里斯

根据您提到的计划,我了解到您希望在Source上完成SUM操作并将其复制并在target中运行后出于任何原因解锁源系统。 在这种情况下,SUM进程将不会在Source上运行以使用SUM的Reset选项。 如果要在处理完成之前使用SUM进行重置(在HOSTCHANGE_STOP处),则它将在此之前重置整个SUM操作(如正常重置一样),并且不能在目标上使用。

如果您想重置整个过程,SUM的Reset选项绝对是最好的方法。

浮生未央
3楼-- · 2020-08-18 21:22

嗨克里斯托弗,

从您计划中的第4、5和6步看来,您似乎选择了带系统移动选项的DMO串行模式。

"您在上述步骤(6)上的经验是什么?对于2TB DB来说,重置花费了多长时间?"

SUM的任务 当系统要求您将SUM目录复制到目标PAS并在此执行时,操作将在HOSTCHANE_STOP阶段在源PAS上完成。

(这不是强制性规定,您可以重置 并在复制SUM之后从源代码启动SAP应用程序。)

为此,您只需转到 SUM/abap/bin/并执行 SAPup 解锁系统。此外,您需要在解锁系统后将UVERS表PUTSTATUS从U更改为+(软件组件)。

无论数据大小如何,它都不会花费超过5分钟的时间。

"看起来只是为了删除影子表"

那是不正确的。

影子实例是在预处理阶段中创建的,并且您在执行阶段停机时间内复制SUM,即在EU_CLONE_MIG_DT_EXP阶段之后(将内容导出到SUM时) 目录)。 因此,影子实例不会影响源系统解锁的持续时间。

暮风yp
4楼-- · 2020-08-18 21:14

Christopher,

我们做了两次,即紧接在BIND_PATCH之后,又进行了一次转换。

此致

callcenter油条
5楼-- · 2020-08-18 21:00

克里斯,

我们对其中一个测试系统进行了重置。 大约6.1 TB的数据库用了将近2.1个小时。

问候

CJones
6楼-- · 2020-08-18 21:21

大家好。

鲍里斯·鲁巴特 Sumit Jaiswal ,是的,我盲目地看着重置时间,而我却忽略了并行模式减少总停机时间的好处。

我们仍处于与潜在客户进行规划的初期阶段; 但是,我们必须估算这种停机时间将花费多长时间。 暂时没有确定的时间表。

鲍里斯·鲁巴特-我们对该发行版有何期待? 我们是否能够进行"脏复制",这样就不必再关闭源系统了(至少对于测试迁移而言)?

最好。

chris

clever101
7楼-- · 2020-08-18 21:13

嗨克里斯托弗,

就像Sumit提到的那样,看起来就像您遵循串行模式一样。 您应该考虑改用并行模式,因为它将减少停机时间。 在对话框HOSTCHANGE_STOP上,要复制的剩余文件将更少,因此可以更早进行重置。

如果即使对于测试而言停机对您来说也很重要,则好像您在运行测试 生产系统。 然后,强烈建议不要遵循Sumit之类的想法:编辑表UVERS而不是运行干净的DMO重置。 这样的手动活动可能会将您的系统设置为禁止更新的状态。

最后:粗略的项目计划是什么? 也许值得等待将于6月中旬举行的SUM 2.0 SP 08。

致敬Boris
SAP SE,产品管理SUM

一周热门 更多>