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).

[Boris_Rubarth]

Hi Yannick,

sorry to tell you that there are cases in which DMO is not a real one-step procedure, if we consider al aspects like OS of Primary Application Server (PAS; fka CI) host. DMO is an inplace-procedure, so it keeps the application server host (and OS) stable. Your issue is that windows 2003 is not supported for 7.40 kernel.

[Edited on may 5th: deleted the paragraph on additional application server]

As you need the PAS with supported (target software level) kernel after the migration anyhow, the recommendation is to update the PAS OS beforehand or switch the PAS to an appropriate server.

Best regards, Boris

[murray_lahn]

We are wanting to do a trial migration from ECC/SQL Server to HANA.  What we'd LIKE to do is have the ECC system remain up and running in our own datacentre and have a migrated version running on HANA located in the Amazon AWS Cloud.  We don't want to lose the original ECC system in the end.

A couple of questions related to that...

1) Does the DMO option of SUM allow for migrating the APP side of things over to the cloud, or just the database.

2) How would it be possible to have both systems up and running (for comparison and for retry purposes)?

Thanks in advance!

[Boris_Rubarth]

Hi Murray,

a datacenter move is not supported with DMO. (We have an SAP-internal DMO flavor for the migration to SAP HANA Enterprise Cloud - HEC - but this is only for SAP colleagues, and only for target HEC)

1) The DMO option does not allow to migrate the application server..

2) This should be possible with the classical migration (using the Software Provisioning Manager)

Regards, Boris

[Mofizur]

Hello Boris,

I was doing ERP EHP6 to EHP7 upgrade + SQL Server 2014 to HANA DB (rev 91) migration using DMO.But unfortunately during phase EU_CLONE_MIG_DT_RUN HANA DB crashed.Now when I try to

bring it UP manually it does not come up. What are the options we do have now?

Thanks,

Mofizur

[Former Member]

Hi Boris,

We have a situation were we want to keep the source system ECC/MSSQL intact and have the migrated version running on HANA(Different location). As the DMO option does not allow to migrate the application server what is the workaround to avoid classical migration?

1) can we restore the old kernel and profiles to start the source system on original version?
2) on the target system (HANADB) can we install the CI separately and start the system to work?
3) We would like to install the SAP Application(CI) directly on HANADB server after the DMO execution is complete, is this supported?

Thanks !

[Former Member]

Hello Syed ,

1. You can use your source DB by putting up the same version of CI on top.

2. Yes - you can install CI separately on target DB after migration and system will work.

3. Yes - it is fully supported.You can use system copy option from SWPM and provide SAP<sid> credentials(SAP Schema user created during migration).

Thanks

Dev

[Former Member]

Hello Boris,

Can you please comment on Zahoor Syed's question above?

[Boris_Rubarth]

Hi Zahoor Syed,

After the DMO run, we do not have a source system any longer, only a source database with content from the start release. The application server uses the new kernel and adapted profiles and is connected to the target database, SAP HANA.

1) You can't change kernel and profiles to restore the original version. As mentioned by Dev, you may try to install an application server (Primary Application Server: PAS, formerly know as central instance: CI) that connects to the source database, but not sure if this is officially supported concerning technical and license aspects.

2) The target SAP HANA database already has a PAS after the DMO run, and it is already working. You may consider to change the landscape architecture to switch the PAS, but this is manual activitiy, and after DMO.

3) Please check SAP Note 1953429.

Regards, Boris

[Former Member]

Hello Boris

It has been very useful blog. Thank you very much for sharing this details with us all.

One of the recommendation that I see in the DMO procedure is to use the latest R3load, R3ldctl versions of the tools. While providing all the kernel etc in the download directory, how do we provide the very latest R3* tools to the DMO procedure. In addition to providing the latest Kernel (both for the shadow source system and the target), if we put the latest R3ldctl, R3load etc in the download folder itself, will the DMO procedure take the new versions immediately when it extracts the EXEs and use them automatically on top of the ones that are in the exe and exe2 folders ?

Regards

Raj

[Boris_Rubarth]

Hello Raj,

thank you for your feedback.

Concerning your question: yes, it is indeed as simple as that: you just put all the kernel and R3load / R3ldctl archives into the download folder, and during the DMO procedure, the SUM tool will consider the latest versions.

Even if the tool tells you to during the checks that it needs a newer version, you just put the newer version into the download folder and repeat the step - no need to know which SUM subfolder is relevant for which kernel type.

Regards, Boris

[Former Member]

Boris

Appreciate your response and clarifications. Thanks

Raj

[former_member184576]

Hi Boris,

Such a wonderful explanation of DMO !! most of my doubts got cleared from comments section. :smile:

We have a requirement of migrating our servers to HEC environment. I read your comments that DMO to cloud is for SAP internal use only. My understanding is as below, correct me if I am wrong.

Current environment : ECC 6.0 700 SP 28, Win 2003, SQL 2005

1. Use DMO to Cloud option to create the export.

2. Manually Move the Export from On-Premise to the HEC environment.

3. HEC colleagues will take over the migration process and finish the migration.

4. what is the process for HEC migration if we use classic approach instead of DMO?

I read that, in HEC os should be Linux flavour. Is this correct?

BR,

Phani.

[Boris_Rubarth]

Hi Phani,

thank you for your feedback.

And thanks for your interest in "DMO to SAP Cloud" - the SAP colleagues involved in your project will be able to give you more insight into the procedure.

Best regards, Boris

[Former Member]

Great Blog!!

Considering the fact that the PAS will be running both R3load export and R3load import processes in parallel, are there any specific sizing recommendations for the PAS? Is there any ratio we should follow for setting the number of export and import R3load processes?

BR

Antonio

[Former Member]

Hi Boris

Thanks for all the useful tips on effective use of DMO procedure.

1. When we deal with very large databases, typically DMO picked up large tables and uses all of the CPU capacity as much as it can. Towards the end, the workload goes down and that is ok too. One of the issue, I see here an issue. If one very long running table or a table split fails, we had to wait for the whole DMO downtime phase to complete and then for the DMO to pick up the error. In case of migmon, distmon we were able to manipulate the state properties file and get the failed packages also completed while other small packages are running. In DMO, is it possible to reexecute a failed bucket (package) instead of waiting for the end of the phase ? That would help not to loose further time, in long running DMO processes.

2. As this uses the PIPE, which is basically communicating with the import R3load and importing data into HANA. Is there a possibility of this slowing down the export ? For any reason, if there is a performance issue on the HANA import side, say it is going slow, will that make the export process go slower. On the other hand, will the export performance be the same when we dump the export to disk, instead of using the pipe ? I believe it should actually be better as it does not have to write a lot of export contents to disk. I noticed that the export was slow compared to my other OS/DB migration experiences. Sure, I did not compare it here yet, by doing the same DMO R3load to save the export to disk.

3. We had an issue of a Broken pipe (in fact when I looked at the log, the import was failing on a large data as it said it hit a non-numeric value for a numeric column) and that in turn caused or forced the export to stop. So, here I am not sure it is the 'broken pipe' error on the export that left 'in-complete' contents in the pipe, causing the import to fail or the import caused the export to fail, due to it aborting. There is an sap note that talked about -decluster and HDB_MASSSIMPORT likely causing this issue and suggesting a new R3load version. I did re-try the same with the same R3load and it went ok. So, this eliminates the possibility of an R3load version issue. Question is, could the workload (say 100s of R3loads) could cause 'Broken pipe' or could there by anything on the network between the DMO and the HANA that can possibly be causing the 'export to fail', as it is supposed to be writing only to the export pipe, very local to the DMO server ?

Please let me know your input on them..

Thanks and always appreciate you sharing details with us all.

Regards

Raj

[Stefan_Kienzle]

Hi,

could I use differend SID for the targed HANA system?

Best regards

Stefan

[Boris_Rubarth]

Hi Stefan,

the SID of the ABAP system is not changed with DMO.

The SAP HANA database has it's own SID which is different from the ABAP system SID.

Best regards, Boris

[Stefan_Kienzle]

Hi Boris,

does it mean the target skeleton ERP system must be installed with the same SID like the SID from the source system or will the import step of DMO override the SID?

Best regards

Stefan

[Boris_Rubarth]

Hi Stefan,

no installation at all required for DMO.

You have your source system (with the existing SID), which is updated by the DMO procedure, and you have the application server(s) that remain. "Only" the database content is migrated to the target database.

Best regards, Boris

[Harald_Stevens]

Hi Stefan,

per default DMO does not change the SID of the system during the migration process. If you want to end up with a system with a different SID (e.g. for creating a test/sandbox system) you would have to go through the SID renaming process after the migration. Also, you would to provide application servers for both systems (if you want to keep both). However, you have to be careful to keep source and target systems isolated until the renaming is through (interfaces shutdown, ...) so that you don't end up with two active systems with the same SID.

This is not the standard DMO procedure, so there might be other pitfalls involved...

Kind regards

Harald

[Former Member]

Hi Boris,

During an MTE for an EHP7 upgrade SAP presented some statistic about average uptime and downtime.

Do you have the same for migration to HANA?

Another question is that usually an EHP7 upgrade is not influenced much by the size of the database. I suppose it is different for HANA migration?

Regards,

Adel

[Boris_Rubarth]

Hello Tanmay,

not sure what you mean with

Basis Capgemini wrote:

We don't do file splitting using DMO.

my recommendation is to check the following blog:

Optimizing DMO Performance

Regards, Boris

[Boris_Rubarth]

Hello Tanmay,

I never heard of such concept "STALL", if you have details please send me a direct message on this, thanks.

DISTMON cannot be used, all R3load processes will run on the application server on which the SUM is started.

The blog referenced above discusses all techniques to speed up the migration process.

Regards, Boris

[Olj]

Hi Boris,

can you help me?

We need to migrate/update BPC system from:

NW 7.4 + Oracle11    installed on HP-UX OS   to

NW 7.5 + HANA        installed on SUSE OS

I know that DMO can migrate DB and update system in one step, but it can't migrate application server to another server(os).

What is the best way to migrate application server?

1. Standart system copy, export system from HP-UX os, then import to SUSE with target database HANA, then use SUM to update to NW7.5

2. Use DMO with HANA on SUSE server, then export from HP-UX    --> import to SUSE os (where HANA is already migrated via DMO)

3. Use DMO, then shutdown application server on HP-UX, then install new application server on SUSE and connect to HANA (not sure that it's possible).

Or may be another scenario?
Thanks in advance ...

Original post:

Migration DB and Application server to HANA server with different OS

[premsukh_bishnoi]

I think, PAS would be migrated along with DMO. for the  Rest of application server, you need to reinstall or adopt modification as per HANA env. for standard way, you can use SWPM to uninstall/install application instance(excluding PAS).
non-std way, you can modify the profiles and env variable to connect to HANA server.

[Olj]

Hi Prem,

where you got infromation that PAS can be migrated via DMO to another os?

I read lot of guides, and there is no information about PAS.

[Former Member]

Hello Daulet ,

DMO will not migrate any of the application servers.(PAS/AAS).

If you need to migrate those what you can do is make use of system copy option via SWPM  and give HANA schema user details which got created during DMO for ex: SAPSID - by this from your new OS , you have the application server running on HANA.

Ofcourse it will involve minimal effort with respect to adapting OS related files - depends on your scenario.

[Olj]

Hi Devpriy,

thanks.

Also we need to upgrade NW 7.3->7.5, so DMO is more convenient tool.

What about scenarion 3:

Use DMO(migration, upgrade), then shutdown application server on HP-UX, then install new application server on SUSE and connect to HANA (already migrated by DMO).

Is it possible?

[mike_han2]

1, At which time point does DDIC Activation happen?

2, At which time point does Distribution happen?

3, At which time point does Move Nametab happen?

4, At which time point does Conversion happen?

[Boris_Rubarth]

Hello Mike,

thank you for your gentle request.

The shadow repository is been build up on the source system, with all the steps like in a standard update/upgrade (SUM without DMO) like DDIC import, activation, distribution, ... . The only difference is that after these steps, the repository is been migrated to the target database.

Kind regards, Boris

[mike_han2]

Hi Boris,

Thank you very much for the quick response. So to my understanding, the Move Nametab and Conversion will happen on HANA database during the downtime. Is my understanding correct?

Best regards,

Mike

[Boris_Rubarth]

Hi Mike,

correct: the application content is first migrated to the target database, and afterwards updated to the target software release (including Move Nametab and Conversion), as written in the last figure.

This way, the application content is not changed on the source database, which allows the easy reset feature of DMO.

Kind regards, Boris

[mike_han2]

Hi Boris,

Thank you very much for the reply. It is clear for me now. Thank you.

Best regards,

Mike

[mike_han2]

Hi Boris,

In this article, you mentioned that the export and import (migration) by R3load pairs run in pipe mode on non-Windows hosts.

But my question is, on Windows host, what mode does it use? Is it file mode?

Best regards,

Mike Han

[mike_han2]

Hi Boris,

I find the following hint in another article (

DMO: comparing pipe and file mode for R3load

) by you as below.

• For windows OS, the pipe mode is enabled starting with SUM SP13 (available since April 28th 2015)

So I have got the answer. Please ignore my question. Thanks.

Best regards,

Mike Han

[Boris_Rubarth]

Hi Mike,

thanks for the question, I have updated the blog now (removed the restriction of pipe mode for non-windows).

Best regards, Boris

[sanjaysahita1]

Hi Boris,

Thank you for the excellent blog!

Can you please help me with a couple of questions : -

1) What is the procedure to restart a failed package while other

packages are still ongoing; For e.g if one package failed due to some

connection error due to CPU 100% situations, etc; how do I rerun it now

in middle of DMO Migration ongoing?

2) What is the correct procedure in DMO approach to ignore a failed

package; as it looks bit different here than SWPM Export/Import as

.TSKs are empty and .TSK.bck are the one's in err state in .TSK.bck files.

3) Are the duration XML files in SUM SP14 only possible when the entire DMO run is error-free and otherwise not possible to use them? Any other methods to generate those manually after a completed errors-fixed DMO run to reuse for future system migrations.

Since these are not documented at all in DMO SUM Guide; So I kindly

request if you can please provide answer to these so I can continue my

current migration run smoothly then.

Best Regards,

Sanjay S

[Former Member]

Hi All,

I´m in the situation where i need to migrate a production ERP system with DMO to HANA.

In the actual enviornment we have one PAS/CI and two application servers/Dialog intances.

1. How these application servers/Dialog instances are treated/managed by DMO?

2. I need to install the HANA client manually in each application server/DI?

3. Do i need to unisntall and install them back in HANA?

I saw some posts here where the hosts of the application servers/DI were being moved to another host/operating system which is not my case. The host will keep the same for the Dialog Instances.

Thanks in advance.

Br,

Jim

[Former Member]

Hi Jim,

1. Dialog Instances/App servers have to be reinstalled SUM(DMO) doesnot have option to update/migrate application servers/Dialog instances

2. HANA Client can be installed locally or if all the dialog instances are sharing the common mount point then it can be installed centrally too..

3. I could not follow this " Do I need to uninstall and install them back in HANA".. did you mean re-installation of application servers?  if so yes you have to re-install them.

Regards,

Avinash

[Former Member]

Thanks Avinash! is clear now how Dialog instances/appliation servers should be managed when useing DMO.

Br,

Jim

[jay_cramblet]

How much space do we need for the shadow repository in the source database? Is there a calculation for that?

[nicholas_chang]

SUM-DMO will smart enough to tell you in "check" phase.

[jay_cramblet]

That's great. But what if I want to ensure that I have sufficient space before I do my first test migration? Isn't there some way to calculate (or at least estimate) the amount of space required for the repository beforehand?

I don't want to wait until I start my testing to arrange for sufficient space in my source database.

[Boris_Rubarth]

The shadow system is not only used for DMO but for a standard maintenance with SUM. So see SUM Guide:

"Space requirements in the database: The Software Update Manager calculates the space requirements for the database. The free space required is in the range from 50 to 200 GB."

Regards, Boris

[jay_cramblet]

Excellent.  Thank you.

[Former Member]

Boris,

This is the best explanation of the technical process of DMO I found so far. Thank you for this.

I am planning perform a transition from ERP 6.0 EHP7 on MSSQL 2012 with PAS&DB on Windows 2008 R2

The target is S/4HANA.

At first I was under the impression that SUM(DMO) makes this possible with one step, but if I understand this correctly, it is not.

What is the best technical process for me to transition from the above source to S/4 on HANA?

Classic SWPM export/Import migration over to the Linux HANA host (PAS & DB) and then followed by SUM to transition the ERP 6.0 EHP7 PAS to S/4 on the target?

This seems to be a two step process with considerable downtimes of both steps are performed consecutively. This project is imminent so I am very much interested to hear more about options.

Thank you!

Alex

[Boris_Rubarth]

Hi Alex,

thanks for the feedback.

I wonder what made you think that the system conversion will not work from your source release, any particular reason for this?

Not sure if you had a look at my introductory blog on the system conversion using SUM:

System Conversion to SAP S/4HANA: SUM is the tool

Kind regards, Boris

[Former Member]

Thank you for the quick answer Boris. Yes I read he System Conversion to SAP S/4HANA blog. What I took from that blog is:

If the source is not on HANA then DMO of SUM is the tool to use. With exception of non-unicode sources, two steps for non-unicode. I was not thinking this through properly at the time.

What I missed after reading it is that DMO does not move your PAS for you which means that if you are coming from a non-HANA Operating System then you cannot perform this in one step using DMO of SUM because your PAS will stay behind on Windows.

Of course, without the blogs it would take me longer to arrive at this understanding which I hope is now correct.

Best Regards,

Alex

[Boris_Rubarth]

Hi Alex,

thanks for pointing out your investigation path.

Well, yes: the PAS remains with DMO, and it may remain on Windows - why not?

As far as I know, the PAM does not exclude windows for the application server hosts of SAP S/4HANA, agree?

Best regards, Boris

[sanjaysahita1]

Hi Boris,

I have a query relevant to Windows 2008 R2 possibility to use DMO migration of ERP to EHP8+HANA. Since as per PAM Windows 2008 R2 is not supported for ERP EHP8 onwards in matrix.

Our Source system PAS is currently on Windows 2008 R2 and MSSQL DB. Source is ERP EHP6 Unicode.

We are migrating to HANA DB + EHP8 Upgrade in one go via DMO approach.

However; EHP8 needs Windows 2012 R2; So can we use DMO in this case on AAS without disturbing the existing setup on source side or you see its a must to move PAS first go to Windows 2012 R2 and then only DMO will support one step migration to HANA + EHP8 Upgrade in one go ?

Thanks a ton for your kind help with this.

Best Regards,

Sanjay Sahita