DMO: technical background

[Boris_Rubarth]

The following sequence explains the technical procedure of the database migration option (DMO). As a prerequisite, you should read the introductionary document about DMO: Database Migration Option (DMO) of SUM - Introduction

DMO will update and migrate your SAP system to the SAP HANA DB, so before starting DMO we need:

• Source database with application data and (productive) repository on source release
• Primary Application Server (PAS; fka central instance) with kernel on the SAP source release
• SAP HANA DB as target database on a separate host (as an appliance)
• Software Update Manager (SUM) on PAS host (SAPup is covering the ABAP part)
• SAP Host Agent on PAS host (updated to enable DMO communication)
• Browser on frontend to display user interface

In the web browser, we open the respective URL which sends an HTTP request to SAP Host Agent. After we have provided credentials, the request is forwarded to SAPup which is started on PAS host (Browser request not shown).

Uptime processing means the SAP system is still running and end users can work productively with the system. Still the SUM is preparing the system update by creating a shadow system: a shadow instance on the PAS host, and a shadow repository (on the new SAP release). The shadow instance is based on the shadow kernel, which is the new kernel (new SAP release) for the old (source) database.

(Note the legende concerning the color for the parts that are on the target release)

After the shadow repository was created on the source database (without influencing the productive use of the system), the shadow repository is copied onto the SAP HANA database. For this, the tool R3load is used which is part of the kernel. The shadow instance is no longer required. So the target repository is created on the SAP HANA DB, as it is already on the new SAP release, and on the target database.

Now the system is being shut down, and the downtime processing starts. During this phase, the application data are migrated from the source to the target database. Like for a classical migration, the tool R3 load is used. R3load pairs are doing the export and import. The first R3 load (part of the shadow kernel) is exporting the data, the second R3load (part of the target kernel) is importing the data into SAP HANA DB.

Both R3loads are running in parallel on the same host. No export files (dump files) are created because the data transfer between the R3load pair happens throught the main memory of the host. This R3load option is called memory pipes.

ℹ Note that this procedure requires to have two additional kernel sets: shadow kernel (new release for source DB) and target kernel (new release on target DB). They will have to be selected manually during use of Maintenance Optimizer (MOpz).

After the migration of the application data is done, SUM will provide the target kernel for the PRD instance (kernel switch). the application data are still on the source release. The system is switched on, but it can't be used by endusers as the procedure is not finished yet (technical downtime).

Then the application tables are updated (e.g. XPRAS), and when the procedure is finished, the system is available, running on SAP HANA DB and on the new SAP release.

ℹ Note that during the complete procedure, the source database continues to run and is not changed. In case of any reason to return to the source database, a simple reset procedure offered by SUM can be used, and the state before shutting down the system is restored (without the need for a manual database restore). The SUM will deleted the data from SAP HANA DB, will restore the old kernel, and will delete the shadow repository.

(Blog was updated on march 28th reflecting more precise pictures).

[former_member185382]

Hello Boris,

Beautiful explanation on how DMO works technically. Thanks a Ton.

Regards,

Ravi A

[princekjose]

Thanks Boris for the detailed technical background of DMO. This seems to be a very resource intensive option when someone try to do Upgrade, Unicode conversion and migration together .. So does SAP provide any kind of source system hardware recommendations ( cpu, memory etc ) for DMO option ? Can DMO support parallel export/import and is it possible to distribute R3LOAD to different AS servers ?

[Boris_Rubarth]

Hi Prince,

well, the procedure is as resource intensive as an update - same recommendations apply. And like in a standard maintenance, you can adjust the number of processes used in parallel, and even adjust it during runtime.

The R3load pair doing the export&import is one pair, and setting R3load number of parallel processes to e.g. 60 means 30 pairs are running in parallel.

It is not possible to distribute the R3load processes to different Application Servers. customer experience has shown that the R3load processes are not critical.

Regards, Boris

[princekjose]

Thanks Boris. It seems all the procedure/recommendations used in Upgrade and Migration are still valid for DMO as well .

Thanks

Prince

[Former Member]

Hi Boris

Thank you for your great documentation.

I have done my UPG/MIG with SP10.

I have one question.

As you wrote, we can "reset" to the original DB between DMO procedure.

IF unexpected problem occurs after the completion of Migration, can I reset to the original DB with SUM function?

After completion, SUM doesn't exist & I can't click "reset" bottom.

(Application data will be role back before downtime. That's OK.)

Thanks

Yoh

[Boris_Rubarth]

Hi Yoh,

a prerequisite for the reset is always that you keep the SUM folder, even after the DMO procedure finished successfully. That way, all the information that the SUM requires are available, and you can start SAPup with option gr=scroll:

/usr/sap/<sid>/SUM/abap/bin>./SAPup gt=scroll

SAPup will then offer the option to reset the procedure. (You will have to provide passwords for some users.)

And as you say: from business perspective, you have to know what you are doing, especially if it is OK to discard the data updates on the system after the procedure finished.

Regards, Boris

[Former Member]

Hi Boris

Thank you for your answer!

Best Regards.

Yoh

[Former Member]

Hi Boris,

for migration to HANA there are specific requirements in terms of of release and support package stack (eg. for BW 7.31, sps 5 is required). Are there specific requirements also for use DMO? I don't find anything in guides or note.

Eg. to use DMO you must have at lease NW x.xx sps xx / kernel x.xx.

Thank you in advance

Regards,

Walter

[Former Member]

Hi Walter

if you mention about migration of SoH, you can find on SAP Note 1875197 - Using DMO of SUM for SAP Business Suite systems

BR

Yoh

[Former Member]

Hi You,

you're right, and for BW there is this note: 1799545 - Using DMO of SUM for SAP BW systems

If I have a ERP 6.0 system and I want to migrate it to HANA, the normal procedure is:

• upgrade ERP 6.0 to minimal release/sps stack (or highger) that allow migration on HANA.
• Perform the system copy to HANA

With DMO instead:

• upgrade to minimal release/sps stack or higher and migrate to HANA at the same time. This is possible because the source release is DMO compatible.

Right?

Thank you in advance for clarification!

Thanks

Walter

http://service.sap.com/sap/support/notes/1799545

[Former Member]

Hi Walter

You are right.

(don't forget to check that your source system meets the system requirement listed on SAP note. like SAP BASIS sp17 and above)

BR

Yoh Maekawa

[Former Member]

hi Boris,

We are planning to migrate from Oracle to HANA and upgrade BW using the DMO process, is there any specific tweaking needed on the source DB side(like increasing the PSAPTEMP, log buffers , memory,cpu etc) .

Thank you

Jonu Joy

[Boris_Rubarth]

Hi Jonu Joy,

as the DMO procedure includes an update procedure, the same aspects apply as for a standard SUM use case. It is mentioned in the SUM guide, and the SUM will check the prerequisites.

Regards, Boris

[francois_keen]

Hi Boris

I couldn't see in the SUM DMO HTML5 UI something like in the classic SUM Alert > Alert info where we can enter a script which is triggered when SUM is waiting for input.

Is it hidden somewhere or if the feature is not available with SUM DMO, would you plan to add this?

In the meantime I got a cron scanning for upalert.log in abap/tmp

Thanks

Francois

[Boris_Rubarth]

Hi Francois,

good question, sad answer: during DMO we currently do not have something yet for notifying the user. We are aware of this requirement, but I cannot provide any details yet.

Regards, Boris

[nicholas_chang]

Hi Boris,

Also, the pre-requisite to rollback to its source db after completion is hdb connection must still valid and working, and my question is, after rollback, schema of source db (application data + repo) will be erased from HDB?

If yes, is there a way to keep the migrated data on hdb?

Thanks,

Nicholas Chang

[Boris_Rubarth]

Hi Nicholas,

there is no way to keep the migrated data on hdb if you choose the reset option in DMO.

Yes, the reset will delete the created data and schema from SAP HANA DB, and it is required that the source database is still available. If SUM was stopped, the tool may ask you for connection details to reach the source database.

Regards, Boris

[nicholas_chang]

Hi Boris,

Thanks for clearing the doubts. And again, thanks for the detailed info.

Cheers,

Nicholas Chang

[Former Member]

hi Boris, Is there a limitation on the number of R3load which we can use for the export/import and will adding more CPU/RAM help expedite the transfer process . Currently we are using 60 R3load process on  a 6CPU 36G Ram.

Thank you / Jonu

[Boris_Rubarth]

Hi Jonu,

there is no limitation, and experience has shown that the number of processes is typically not the bottle neck, even with number above 100 or much more. We had an issue on windows (not more than 60 processes possible) which was solved meanwhile.

Regards, Boris

[Former Member]

Hi Boris,
we planned to use DMO to update&migrate from DB2 to HANA. The source DB and target DB are located in different data center. How communicate the R3load processes, via pipes ? Is it possible to use DMO or the classic method (export - transfer - import ) only ? An other possibility could be to migrate with DMO and then to made systemcopy.

Best Regards / harald

[Boris_Rubarth]

Hi Harald,

the R3load processes communicate via pipe mode (for non-windows platforms), see DMO: comparing pipe and file mode for R3load. In any case, the R3load processes all run on the application server on which you start the SUM/DMO procedure.

Running DMO in such a remote scenario may work from a technical perspective, but definitely not from the expected duration. For migrations into the SAP Cloud (SAP HANA Enterprise Cloud), we use a specific DMO procedure which is only internally available for SAP projects. So I guess you will have to use the classical migration (export - transfer - import).

Best Regards, Boris

[former_member184682]

Hi Boris

would it be ok to share at high level how the internal SAP DMO procedure is a bit different. how the internal DMO procedure works better for the migration into HEC

Thx

[Boris_Rubarth]

"DMO to SAP Cloud" is able to handle the work required on the source system (customer landscape) and on the target system (SAP Cloud infrastructure) separately.

Regards, Boris

[Former Member]

Hi Boris,

this seems very intresting solution to migrate to Hana on cloud but I cannot find any information!

Is "DMO to SAP Cloud" a particoular product/tool or a special option of SUM? Where is it possible to find information about it?

Thank you

Regards,

Mark

[Boris_Rubarth]

Hi Mark,

this procedure is only used SAP-internally, that is why you do not find public information on it - sorry to disappoint your curiosity.

Regards, Boris

[Former Member]

Ok Boris!! 🙂

Do you know if the road map of "DMO to SAP Cloud" plans to make it public and when?

Thank you

Regards,

Mark

[Boris_Rubarth]

[edited on Jan 17 2018]: procedure is meanwhile available as "DMO with System Move", described in the DMO guide.

Regards, Boris

[Former Member]

Dear boris.rubarth

We did a SUM reset of production system due to some issue, system were reset to original state but i still see all folders exists under SUM directory, i can even see the shadow system directories, we even did a cleanup step in the DMO.

Now we are starting the SUM again for migration, can we run from the same SUM directory or rename existing SUM directory and extract SUM again ?

Please let me know

Thanks,

Ravi

[Boris_Rubarth]

Dear Ravi,

after the reset and the cleanup (that is proposed by SUM), you may use the same SUM folder for the next run.

Regards, Boris

[Former Member]

Dear boris.rubarth

Thanks a lot for the immediate response, i really appreciate it.

My concern is that since we have all the files in the SUM directory (migration task files, command files, lmport files, shadow system files) will SUM create them again ?  We had issues with two tables , after the downtime migration table count was mismatching and only few entries were migrated. Development team suggested to maintain a add list for these two tables with nosplit option.

I hope there wont be any impact starting from the same SUM directory again?

Thanks again

Ravi

[neeta_patel2]

Dear Boris,

We are planning a migration from Oracle to SAP HANA and upgrade from ECC 6.0 to SAP EHP7 SPS3 using SUM DMO . The source system is running RHEL 5. We are confused about the kernel versions required in the download are of SUM. The current version of the kernel that is running on the source system is V7.21 latest patch level:

1) Shadow kernel - V7.21 for the source DB oracle.

2) Target Kernel for the target DB HANA- V7.21 .

Since the export and import are running on PAS of the source system, is there any additional kernel versions required? SAP EHP7 is based in NW7.4 which requires SAP Kernel 7.41. However 7.41 will not work on RHEL 5.

Thanks!

Neeta

[Former Member]

Hello Boris,

I just want to know the criteria on how many r3load and r3trans, SQL, ABAP, parallel phase processes do we need to allocate for DMO?

Regards,

Manuel

[Boris_Rubarth]

Hi Neeta,

for the migration, SHD kernel and TGT kernel (see figure above) both have to be on the target software level, in your case probably 7.41. The R3load pairs executing the migration have to have the same software level - we always recommend them to have the same patcht level. So V7.21 is wrong in your list, both for source kernel (ORA) as well as for target kernel: as you state, EHP 7 requires SAP kernel 7.41. This is the kernel used for the migration as well as for the target system running EHP 7 on HANA.

If your OS (e.g. RHEL 5) does not support 7.41, then you need an update of your host software. See SAP Note 1813548 on DMO:

"Restrictions regarding databases and operating systems: The operating system of the application server(s) have to be supported for the target SAP release according to PAM."

Regards, Boris

[Boris_Rubarth]

Hi Manuel,

the most relevant parameter is the R3load for downtime migration. Criterion is: high enough that the migration is fast, and as high as the performance of your application server allows. You will have to run a test and adapt the number of R3load processes while monitoring the performance of your host.

Regards, Boris

[Former Member]

Hello Boris,

Are there any statistics test validations available which says pipe method is more effective that file method ? For big tables (having columns more than 100 and rows more than 500 million), import of table into HANA can take many hours. Is there any documentation released for preferred method for handling such big tables whether pipe or file method ?

Thanks.

Regards,

Ankit

[Boris_Rubarth]

Hello Ankit,

we assume the pipe mode to be more effective in all cases - no compression takes place, and pipe communication is expected to more more effective than file I/O. This is independent on the number of rows or the database size, as the R3load pairs are always working on a specific part only, called bucket. No further documentation or details are offered. We are looking forward to use the pipe mode for windows in future as well.

Regards, Boris

[Former Member]

Hello Boris,

Thanks. I understood your point. In some cases, I have seen BW tables being exported and imported were having more than 500 million rows and around 100 columns. I couldn't see any files which shows if such tables were split as part of DMO. Normally, we don't need to split manually as it is done by DMO internally. R3load works on bucket but is there any mechanism to parallelize R3load import for particular table ? (Assuming multiple buckets for 1 table running in parallel).

Regards,

Ankit

[former_member184709]

Apologies if this has already been answered or is already listed somewhere obvious.

Do we need a particular certification to get the migration key to use SUM/DMO to convert over to HANA?

I already have the OS/DB Certification and have done a few OS/DB projects including one with CU&UC, and Distribution Monitor, but nothing on HANA yet. So hoping to re-use any existing certs or get new ones if necessary.

This DMO tool looks pretty solid, looking forward to using it.

Thanks !

Derek

[Former Member]

Hello Derek,

You do not need any other certifications to generate the migration key, you should be able to do it.

DMO doesn't need any certification or OS/DB migration check technically.

Thanks,

Ravi

[Former Member]

Hello Derek ,

You dont need any certification to get the migration key , it can be requested from SMP exactly the same way for other migration.

DMO is an option in SUM and if you have already used SUM - you can use the same knowledge to carry on migration.

Thanks

Dev

[former_member184709]

Hi guys!

Thanks for your super fast answers.

It does look like we don't need a cert to get the migration key online.

Though I did just learn that to use the TDI (Tailored Data Center Integration) option for HANA that the customer does need to have someone with “SAP Certified Technology Specialist – SAP HANA Installation” (E_HANAINS141).

But from what I understand you don't need that for the appliance version of HANA because the hardware vendor is already certified and is covering the assurance portion of the solution.

I got this information from a presentation from SAP at SAP Insider conference last week.

This test does not look as difficult in comparison with TADM70 though.

Derek

[Former Member]

Folks,

Any of you know where DMO stores the user inputs?

Thanks,

Les

[Boris_Rubarth]

Hi Les,

can you please describe your scenario for us to think what a possible answer is?

Thanks, Boris

[Former Member]

Hello Boris,

I have the situation as below

Customer has a non unicode ERP 6.0 with EHP7 which is already compatible to run on HANA. Here I understand that its a straight forward Unicode Migration.

Can we use DMO in this situation for Unicode activities and also for R3load to use the Memory pipe concept for a quicker migration?

Regards,

Venkat.

[Boris_Rubarth]

Hello Venkat,

if I understand your scenario correct, you want to use DMO without having any maintenance (SP change) of your SAP software. This is not supported, see SAP Note 1813548 on DMO:

"DMO includes a system update, so a stack.xml is always required."

Regards, Boris

[Former Member]

Thanks Boris,

so if I include an SP change then I should be able to use DMO right?

i.e current version ERP 6.0 EHP7 with SPS6 running on some OS and anyDB (DMO compatible) and the target version is ERP 6.0 EHP7 with SPS7 to run on HANA.

this should work with DMO right?

Regards,

Venkat.

[Boris_Rubarth]

yes, this should work.

Regards, Boris

[Former Member]

Thanks a lot Boris, This is awesome.

Regards,

Venkat.

[former_member185260]

Hello Boris and many thanks for this,

I read some system copies and DMO migration documentation and from now what I understood is that we cannot do an Hana migration + OS/DB migration + Upgrade in 1 single step. The OS/DB + Hana migration has to be done with a certain SP level (NW 7.4 min).

Here is my problem for one of my customer :

- Source: Win2003 and MSSql 2005 - SAP ECC6 / Ehp2

- Target: Hana => Hana DB + Linux.

Sory asking again but can you confirm that I can use DMO in 1 single step to go from my source system to Hana ?

Thanks and best regards,

Yannick.