DMO: technical background
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).
Beautiful explanation on how DMO works technically. Thanks a Ton.
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 ?
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.
Thanks Boris. It seems all the procedure/recommendations used in Upgrade and Migration are still valid for DMO as well .
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.)
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:
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.
Thank you for your answer!
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?
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.
Thanks for clearing the doubts. And again, thanks for the detailed info.
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
if you mention about migration of SoH, you can find on SAP Note 1875197 - Using DMO of SUM for SAP Business Suite systems
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:
With DMO instead:
Thank you in advance for clarification!
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)
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) .
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.
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
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.
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
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.
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
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
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
"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.
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?
this procedure is only used SAP-internally, that is why you do not find public information on it - sorry to disappoint your curiosity.
Ok Boris!! 🙂
Do you know if the road map of "DMO to SAP Cloud" plans to make it public and when?
[edited on Jan 17 2018]: procedure is meanwhile available as "DMO with System Move", described in the DMO guide.
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
after the reset and the cleanup (that is proposed by SUM), you may use the same SUM folder for the next run.
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?
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.
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."
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?
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.
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 ?
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.
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).
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.
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.
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 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.
Any of you know where DMO stores the user inputs?
can you please describe your scenario for us to think what a possible answer is?
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?
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."
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?
yes, this should work.
Thanks a lot Boris, This is awesome.
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,
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
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!
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)
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?
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?
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).
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.
Can you please comment on Zahoor Syed's question above?
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 ?
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.
Appreciate your response and clarifications. Thanks
Such a wonderful explanation of DMO !! most of my doubts got cleared from comments section. 🙂
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?
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
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?
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.
could I use differend SID for the targed HANA system?
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
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?
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
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...
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?
not sure what you mean with
my recommendation is to check the following blog:
Optimizing DMO Performance
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.
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 ...
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.
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.
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.
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?
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?
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
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?
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
Thank you very much for the reply. It is clear for me now. Thank you.
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?
I find the following hint in another article (
DMO: comparing pipe and file mode for R3load
) by you as below.
So I have got the answer. Please ignore my question. Thanks.
thanks for the question, I have updated the blog now (removed the restriction of pipe mode for non-windows).
Best regards, 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.
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.
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.
Thanks Avinash! is clear now how Dialog instances/appliation servers should be managed when useing DMO.
How much space do we need for the shadow repository in the source database? Is there a calculation for that?
SUM-DMO will smart enough to tell you in "check" phase.
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.
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."
Excellent. Thank you.
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.
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
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.
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
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.
as stated in SAP Note for DMO (e.g. SAP Note 2198483 for DMO with SUM SP 16), running DMO on an additional application server (AAS) is only possible if your system is running with a separate ASCS instance. Otherwise SUM/DMO will not be able to start the PAS instance after the procedure.
Question is if it is possible to have an AAS on Win 2012 R2 for your existing system - I guess you already checked.
Allow me to add a general remark for all SUM (and SUM/DMO) scenarios targeting a system based on 7.50 (like EHP 8):
Best Regards, Boris
Thank you for the response.
However the original query remains unanswered still.
Is it possible to have an AAS on Win 2012 R2 for your existing system ?
We already have separate ASCS instance + Unicode system. We are now migrating that ASCS to a virtual machine 2012 R2 based so as to perform DMO HANA Migration to EHP8.
We can prevent that extra work; if you can mention if it is possible to run DMO on AAS on Win 2012 R2 so that we do not touch ASCS / DB / any existing app.servers in the System; we just install a new app.server on Windows 2012 R2 and proceed with running DMO on it.
Kindly confirm on the same.
+358 40 1327 151
sorry, the question is whether you it is supported to run an AAS on Win2012R2 for your source system - this is described in the PAM.
If this is supported, then SUM/DMO can be executed on that OS.
Any response on my query above ?
Thanks for the wonderful post. We are migrating ECC from DB2 to HANA. I came across a blog, suggesting to use HDB_MASSSIMPORT=YES to reduce the downtime import time. Can we use this parameter for ECC migration or its only applicable for BW or performing system copy/installation using SWPM?
For DMO, you should set below parameter in /SUM/abap/bin/SAPup_add.par
/clonepar/imp/procenv = HDB_MASSIMPORT=YES
However this parameter is retired by using the latest R3load and is set by default.
Please go thru the DMO guide for more info.
Thank you very much for your reply & suggestion. I have seen your other blogs & posts, please keep doing the good work 🙂 .
We are using latest R3load apart from KERNEL for Linux and we have done migrations thrice and downtime is around 30hrs for 5TB database. So, we are looking for more tuning options and came through the blog which suggets HDB_MASSIMPORT=YES.
Note:- We have used previous migration XML's for next migrations and would like to know if there is any impact by setting this parameter HDB_MASSIMPORT=YES, manually in SAPup_add.par apart from using latest R3load, R3trans, R3szchk & tp.
You are safe to use HDB_MASSIMPORT=YES provided you are using newer R3load which surpass DEC FLOAT bugs. Just do a search in support.sap.com/notes
In additional, there are plenty of good DMO optimization blogs in SCN to suggest to ensure 10GB network bandwidth, higher R3load with the number of CPU, remove/archive old or unnecessary data in source, relevant source db optimization (eg: statistic update, db parameter, patches and etc), using latest SUM / R3* binary and etc......
all these little pieces help...
During DMO with SUM1 SP17 we have encountered an issue in the phase MAIN_SHDRUN/SUBMOD_MIG_SMIGR/RUN_SMIGRCREATEDDL_740 it is failing with SELROWCOLSTORE.TQL No such file or directory SUM/abap/var.
I could see that the file exists under SUM/abap/var not sure why the SUM is not able to pick this file.
Source version: NW 7 EHP 2 SP13 on DB2 LUW 10.5 FP7
Target : NW 750 SP03 on HANA SP11 Rev112 on RHEL 6.7
Any suggestions pls
Can you reset the procedure if you have previously saved the SUM directory before the Cleanup after Postprocessing?
I know that you can reset the procedure and come back to the source database, as long as no cleanup has been triggered. But if:
1. I save the SUM directory to a separate location before triggering Cleanup in Postprocessing.
2. Do the Cleanup in SUM and stop SUM process.
3. After 1 day, for example, I need to come back to the source database and I put the SUM backup in the location where it first ran. - Can I start it here and do the Reset, so I can use the source database again?
I am asking this because I am thinking that maybe SUM Cleanup, cleans also upgrade related info from the database, and not from the SUM directory only.
well, I guess that this should work, but I did not try it.
Question is why you are executing the cleanup at all - this is not necessary after the DMO run ...
Thank you for the reply.
I am thinking of not leaving the something hanging and "fully completing" the SUM procedure.
Is it more advised not to trigger the Cleanup and just stop the OS process?
Have a great day,
I understand your point, still the SUM procedure is completed (and not "hanging") even without cleanup. Thanks for mentioning that it is recommended to stop the remaining OS process (SAPup).
We just hit an issue with regards to a record discrepancy between one of the tables on Oracle and on HANA, comparing on the rows of the table, they are not the same and had to fail. Is there any process to restart this specific table to migrate again?
We are still in the downtime migration phase when we got this issue
Feel lucky to know such good blogs.
I have a customer planning for Solman upgrade and DB migration.
From(SID: SMP): solman 7.1 SP14 + DB2, on VM
To(SMA,SMJ): solman 7.2 + HANA, on physical host
The initial plan is:
Customer wants to keep SMP up and running before cut-over.
Do you see any risk here?
I guess you are referring to Stefans blog for DMO on SAP Solution Manager:
I have to admit that I do not know which processes of SAP Solution Manager are critical, and about the switch procedure, sorry.
Thank you for the blog . We recently migrated Solution Manager using DMO method from Oracle/Solaris to Hana/Linux . As per your blog, we need source DB (Solaris) kernel and target DB( kernel) Linux for the export and import R3load .
But in our migration, only Source DB Kernel which is of Solaris is used. We did select for target DB (Linux) Kernel in Maintenance Planner , but this kernel was not selected at end . Migration went successfully without any issue and no where Linux Kernel was asked in SUM .
So, it has created a confusion for after reading your blog . Can you please let us know if there is any change recently with new version of SUM SP18.
Thanks and Regards
I am not able to provide an explanation why it seems that the other kernel was not used.
There was no change in the DMO procedure concerning the kernel usage.
We are planning for migration of 30 TB system from On premise to cloud, from oracle db to Hana db. What is SAP recommendation for it. How downtime can be minimized.
for a migration from on premise to cloud, you can use the heterogenous system copy (using the tool Software Provisioning Manager), or use "DMO with System Move" (using the tool Software Update Manager).
The approach "DMO with System Move" is described in the DMO guide, and restrictions are mentioned in the respective SAP note for DMO. You may check out the following blog as well:
Downtime optimization is possible using the parallel mode of "DMO with System Move".
First of all thank you for the shared knowledge, great documentation.
We are planning a DB Migration (Oracle to HANA) with Unicode Conversion via DMO procedure. As correctly indicated by you it's necessary that in the download directory kernel files of the target software release for both the source database and the target database are available. But in this case, with the integration of Unicode Conv. in the procedure, which version (Unicode or NotUnicode?) of the Shadow Kernel Oracle based is necessary? I think that some initial conversion activities related to the UC Conv are performed in the shadow repository so it could be necessary the availability of the kernel UC in the download directory even if the source kernel as like the source system was Not Unicode.
Thanks in advance,
for a non-Unicode source system, you will have to put the non-Unicode kernel (for the new release) for the source database into the download basket (and the Unicode kernel for the target database).
Hi Boris Rubarth
During DMO(SUM) process how many shadow instance gets created? It is like only one for all CI /DI or seperately for each instance.
there is only one shadow instance, created by the SUM on the App Server host on which the tool was started.
Thank you for all of the helpful information and videos regarding the DMO capability in SUM. We have a need to make several changes in our ERP landscape, and I am hoping I can use the DMO tool to take care of all of it in one project rather than having to split it up into two or three.
The SAP app servers are currently installed on Windows 2012, and the Oracle databases are installed on Solaris 11/ SPARC.
** Upgrade from EHP 7 to EHP 8. We are already Unicode compliant (I took care of this a few months ago).
** Change the database hardware and operating system from Solaris 11 to Linux. We have to keep the Oracle database for now, as we are not quite ready to move to HANA.
** Upgrade from Oracle 12.1.2 to Oracle 22.214.171.124.
Can you confirm whether I can perform all of these tasks utilizing DMO?
Thank you for your assistance,
my understanding is that you do not change the database type and keep Oracle, so this is not a scenario for DMO (which always includes a database migration). DMO does not support homogenous database migrations, as stated in the respective notes.
For changing the hardware (without DMO), you use the scenario "system copy" of Software Provisioning Manager (and not the Software Update Manager (SUM)).
Moreover, the SUM never adapts the database software, so the third point (Oracle upgrade) can't be covered.
The "regular" way I will have to do this is to do a heterogeneous system copy because the operating system is changing (export/import). The code page on Solaris is different than on Linux, so the database could not be read by the SAP system. Because of this, I thought that maybe the DMO option would work.
Boris, after the OS change (system copy), I will then have to upgrade the SAP system to EHP 8. I could also do the process the other way around - the upgrade then the OS change (system copy). It will be a two step process or two separate projects, so I was hoping I could use DMO and do them both in one process.
will SUM 1.0 / 2.0 DMO export work on Oracle Linux for system move?
well, sorry to say that I do not know exactly the core question: is it about if Linux as OS is supported? In general yes...
What is the result of your investigation? Landing page http://support.sap.com/sltoolset lists all relevant SAP Notes for DMO (both for SUM 1.0 and SUM 2.0). Let me know if a statement in one of the SAP Notes is unclear, thanks.
Is export and import process available in SUM DMO like SWPM. We have ECC 6.0 on EHP 0 oracle 10 and OS is HP UX. Now we need to move to migrate both OS and DB ( To new Hardware ) then convert the system to S/4 2020. Is it possible via SUM DMO.
not sure if you followed the community rules and did a search prior to asking, or followed the recommended introductory document - anyhow: https://blogs.sap.com/2017/05/22/dmo-with-system-move-the-use-case-to-change-pas-host-during-dmo/