Resetting a DMO with System Move for Test Migration Purpose

[ChrisBuzon]

We are looking to use DMO with System Move to migrate ECC Oracle from on-premise to AWS Suite on HANA; we will do a Test Migration before doing a real one. We now know that downtime at the source is inevitable (even for a Test Migration). And a high-level we expect it to be:

1. Run DMO with System Move in Source
2. Proceed in the Downtime Phase
3. Shutdown Source
4. Finish Source Export
5. Copy and Continue SUM at the Target
6. Reset Source
7. Start Source
8. Continue DMO in Target (mock migration)

Question: What's your experience on step (6) above? How long did the reset took, say for a 2TB DB?

From DMO Guide, looks like it is just meant to drop the shadow tables so expect generally shouldn't last more than half an hour. Thoughts?

[Boris_Rubarth · Accepted solution]

Hi Chris,

there will be no "DMO with system move" without the downtime, sorry. Nevertheless the adapted version may have a shorter revert time for the source system, details to be provided as soon as SUM 2.0 SP 08 is out.

Maybe I got this wrong, but for the productive run, the revert time does not count for the technical downtime, as you don't continue business operations on the source system.

And of course you know the general recommendation to run a test on an actual copy of your PRD system, so that the downtime for the test procedure does not hurt the business.

Best,

Boris

[sumitjais]

Hi Christopher,

From the steps 4,5 and 6 in your plan, it seems you are opting for Serial mode of DMO with system move option.

"What's your experience on step (6) above? How long did the reset took, say for a 2TB DB?"

The task of SUM operation finishes on source PAS at phase HOSTCHANE_STOP when you are asked to copy the SUM directory to target PAS and executed there.

(It's not a mandate but you can reset and start SAP application on source once you copied the SUM.)

To do so, you just have go to SUM/abap/bin/ and execute SAPup unlocksys. Moreover,You need to change the UVERS table PUTSTATUS from U to + ( the software components) after unlocking system.

It does not take more than 5 minutes irrespective of the size of data.

" looks like it is just meant to drop the shadow tables"

That's not correct.

The shadow instance is created in preprocessing phase and you copy the SUM in execution phase downtime i.e. after EU_CLONE_MIG_DT_EXP phase (when the contents are exported to SUM directory). So, shadow instance does not impact the duration of unlocking source system.

[ChrisBuzon]

Hi, Sumit.

I am looking for something like https://help.sap.com/viewer/51722278ff794326b18866ebcb6ee053/dmosum20.07/en-US/81d47d962d734b30968ff... to do the reset. Any particular reason you would do this manual procedure over SUM-specific reset?

Best.

chrs

[sumitjais]

Hi Chris,

From the plan you mentioned, I understood that you wish to unlock the source system (for any reason) after the SUM operation is completed at Source and is copied to run in target. In such case, the SUM process won't be running at Source to use Reset option of SUM. If you will reset using SUM just before process completes ( at HOSTCHANGE_STOP), it will reset the entire SUM operations till then ( like a normal reset) and can't be use at target.

If you wish to reset the entire procedure, Reset option of SUM is definitely the best way .

[Boris_Rubarth]

Hi Christopher,

as Sumit has mentioned, it looks as if you follow the serial mode. You should consider using the parallel mode instead, as it will reduce the downtime. On the dialog HOSTCHANGE_STOP, the remaining files to be copied will be less, so a reset will be possible earlier.

If downtime is relevant for you even for the test, it looks like you run the test run on the productive system. Then it is strongly recommended NOT to follow such ideas like Sumit mentioned: editing table UVERS instead of running a clean DMO reset. Manual activities like this may set your system to a state that prohibits updates.

Finally: what is the rough project plan? Maybe it is worth waiting for SUM 2.0 SP 08, expected for mid of June.

Regards, Boris
SAP SE, Product Management SUM

[ChrisBuzon]

Hi, everyone.

boris.rubarth and sumitjais, yes, I was blindly looking at the reset duration that I've overlooked the benefit of parallel mode to reduce the total downtime duration.

We are still at an early stage of planning with a potential customer; however, we are obliged to have an estimate of how long such downtime would take. No firmed schedule for now.

boris.rubarth - what can we look forward on the release? Would we be able to do a "dirty copy" so source system won't have to be shutdown anymore (at least for test migration)?

Best.

chris

[former_member644293]

Chris,

we did the reset for one of the test system. for ~6.1 TB DB it took almost 2.1 hours.

Regards,

[ChrisBuzon]

Hi, Arunkumar.

Thank you for the feedback. Would you mind sharing a rough breakdown of the 2.1 hours? At which point of SUM did you do the reset (I assume during HOSTCHANGE_STOP).

Best.

chris

[former_member644293]

Christopher,

We did twice ie., just after BIND_PATCH and once after the conversion.

Regards,