Skip to Content
This blog discusses a technique to further reduce the downtime of the Database Migration Option (DMO) procedure of Software Update Manager (SUM). Before reading this content, be sure to be familiar with the general concept of DMO, explained in Database Migration Option (DMO) of SUM – Introduction and in DMO technical background

 

Scope

Downtime optimized DMO will reduce the downtime of the DMO procedure. It integrates a technology to enable the migration of selected (big) application tables during uptime processing of DMO, thereby reducing the downtime migration time.

 

Technology

During uptime processing, the source system is still available for end users. End user activity in the system may change application tables, so if these tables have already been migrated to the target database (SAP HANA database), the changes have to be recorded and transferred to the target database as well. A dedicated technology offers the required procedure to set triggers on the respective application tables to create log entries, frequently analyze the logs, and transfer the delta to the target database.

Specific considerations compared to “standard” DMO

  • A text file has to be created containing the application tables to be migrated during uptime (each table name in a separate line)
  • The allowed target release of SAP_BASIS is 750 or higher
  • The source system has to be on Unicode already

 

Known limitations

  • downtime optimized DMO works for SAP Business Suite systems (not for SAP BW)
  • Selection of application tables for uptime migration is currently a manual process
  • No monitoring of delta transfer ratio is offered yet
  • The following tables are not allowed:
    – Pool tables
    – Basis tables containing deep components (e.g. STRG)
    – Tables to be converted
    – Tables without primary key
    – Tables which start with /BI in the name
    – Application exchange tables
  • Note that cluster and basis tables are supported starting with SUM SP13 and higher
    (with the exception on basis tables with deep components, as listed above)
    (Basis tables: tables part of software components SAP_BASIS, SAP_GWFND, or SAP_UI)
  • downtime optimized DMO is not supported for the scenario System Conversion (targeting SAP S/4HANA)

 

Registration for customers

We have pilot projects running and accept a limited number of additional Projects.
The Projects must be conducted by SAP, and the SAP colleagues have to Register for the procedure by creating an SAP internal incident. Check SAP Note 2442926 for Details.

Abbreviations

  • PAS: Primary Application Server (fka CI)
  • PRD: Productive
  • SHD: Shadow
  • TGT: Target
  • CRR: change record and reply technology

 

Technical background

 

The initial situation is like for the “standard” DMO:

DMO_SLT_01.jpg

Again, like in standard DMO, the shadow repository is created by the shadow instance:

 

DMO_SLT_02.jpg

The shadow repository is copied from the source database to the target database, the SAP HANA database.

Note that the shadow instance is still existing, although currently not used, but not deleted as in the standard DMO.

DMO_SLT_03.jpg

Now the trigger for the selected application tables is set up, and the initial transfer of the triggered tables starts.

The triggers are set by SUM internal technology.

DMO_SLT_04.jpg

Still in uptime, the delta transfer of the application tables is then done. Therefore, a job starts the CRR replicator on the shadow instance to check for trigger logs, and transfer the delta to the Writer. For the Writer to write the data to the SAP HANA database, we need an additional instance

that uses the target version kernel for the SAP HANA database. This instance is called TMP instance (temporary).

doDMO_6.jpg

Downtime starts, now the remaining delta of the application tables are migrated.

doDMO_7.jpg

Now the remaining application tables (that have not been triggered) have to be migrated as in the standard DMO.

DMO_SLT_07.jpg

The target kernel is now applied to the PRD instance, the system is started to allow the update of the application tables. This is still business downtime.

DMO_SLT_08.jpg

Once the application tables are updated and the procedure is finished, the system is available again.

 

DMO_SLT_09.jpg

To report this post you need to login first.

47 Comments

You must be Logged on to comment or reply to a post.

  1. Ali Taner Guler

    Hi Boris,

    I am currently involved in a migration project. The project scope is migrating from MSSQL 2012 to ASE 16.0. While I am reading the guides I noticed that SUM has new feature called DMO and when I got deep into it, saw that DMO can only be used for target database ASE on request (min. required NW release must be SAP_BASIS 740 SP9).

    My Business Application Suite version and SP levels are: ERP EHP6, SAP_BASIS 731 SP07 and SAP_ABA 731 SP07.

    In this situation what are your suggestions to continue with? I would appreciate if you could advice.

    Regards,

    Ali Taner

    (0) 
    1. Boris Rubarth Post author

      Hi Ali,

      well, if the version and SP levels you listed are the start release, you may consider to reach a target level that is supported by “DMO with target ASE”.

      As far as I know, SP7 for EHP7 of SAP ECC 6.0 may be coming out soon, and it will be based on SAP_BASIS 7.40 SP09.

      If this does not fit, you will have to use Software Provisioning Manager.

      Regards, Boris

      (0) 
  2. Alexey Ukrainsky

    Hi Boris,

    some questions/clarifications:

    1- you say the unicode conversion is not possible? it is possible with SLT as long as RFC connections are used to read/write the data. SLT can also cluster/pool/INDX tables very well..

    2- BW are not supported? The majority of replication scenarios for SAP HANA are using the data replication into BW on HANA.

    (0) 
    1. Boris Rubarth Post author

      Hi Alexey,

      1 – yes, for downtime optimized DMO, is currently not possible to include the unicode conversion. Although the SLT technology is capable to cover the unicode conversion, the integrated usage in DMO does not (yet) allow the unicode conversion.

      2 – BW is not supported as a source system for downtime optimized DMO. I guess the replication scenarios that you refer to have an ECC backend as a source, where changes are replicated into BW on HANA – correct? This is different to the scenario where BW as a source would require triggers.

      Regards, Boris

      (0) 
      1. Ronald Halmen

        Hi Boris,

        if certain NW ABAP based products like BW or SCM (in case BW functionality is used) are not supported as source systems then please document this accordingly, also in the “Restrictions and Limitations” section of the related SAP note. Currently, this is not transparent.

        Thanks and regards,

        Ronald

        (0) 
  3. Jayesh Kothari

    Hi Boris,

    Thanks for this blog.

    I had a question on the usage of SLT with DMO of SUM.

    You mentioned to select DMIS addon as part of stack.

    What if our landscape already has the latest – DMIS SP08?  and we wish to use DMO of SUM to update/Migrate ?

    Do we manually setup SLT config naming the schema as  SAPSID , replicate the tables we need manually , and later start SUM to update/migrate to HANA ?

    Regards,

    Jayesh

    (0) 
    1. Boris Rubarth Post author

      Hi Jayesh,

      for downtime optimized DMO, the DMIS AddOn is used, but we do not use the setup like for SLT, so there will be no separate SLT replication server.

      The DMIS AddOn may or may not be installed on the source system, meanwhile SUM SP13 can handle both situations.

      If your landscape is using an SLT replication server, this will not be used for downtime optimized DMO. So no SLT setup required on that server.

      Regards, Boris

      (0) 
  4. Vikas Talekar

    Thanks Boris – Very good content.

    When we say not using other SLT server to replicate large tables ,

      1)  should we use Source system as SLT ?

      2)  will that replicate table data to same schema as target SUM schema i.e. ECC SAP<SID>

    3) if yes SLT configuration replicate data dictionary tables to target schema as default – is that ok to overwrite SUM transfer tables ?

    (0) 
  5. Nicholas Chang

    Hi Boris,

    May i know the estimate date for GA?

    Also, how many customer had registered themselves for using this tool and what’s the outcome?

    Thanks,

    Nicholas Chang

    (0) 
    1. Boris Rubarth Post author

      Hi Bhushan, Nicholas,

      downtime optimized DMO is still “available on request”, and we can’t estimate when it will be made general available (GA).

      It is not necessarily a consulting service: “available on request” means that customers / partners have to request the usage, and we will decide on project details as well as development capacity on the request. However, it is not a bad idea to have experienced SAP consulting colleagues involved.

      Regards, Boris

      (0) 
  6. Bhushan Agarwale

    Thanks Boris,

    I am trying to get the below note to understand optimized part for DMO. However, it is not yet released.

    2005472 – Downtime Optimized Database Migration Option for Software Update Manager

    Thanks,

    Bhushan

    (0) 
    1. Boris Rubarth Post author

      Hi Bhushan,

      this note is not released for customers, that it why you cannot access it.

      My hope was that this blog serves to understand “downtime optimized DMO” …

      Regards, Boris

      (0) 
      1. Bhushan Agarwale

        Hi Boris,

        The Downtime Optimized DMO is very much clear with your blog, thanks again for explaining in detail. Basically, for one of our clients, we proposed in-place DMO migration for their ERP system (ECC6-EHP5) on DB2 with size of 13 TB. The client only has the 24Hrs downtime window, and hence we were exploring the Optimized option. However, client wants to be sure the Optimized DMO is not a consulting offering.

        Thanks,

        Bhushan

        (0) 
  7. Gabe Mensching

    Boris I have tried opening an incident under component BC-UPG-TLS-TLA but I received a response that it was not the appropriate area.  Is there a different component that needs to be used? 

    Thank you for the blog.  This was very informative.

    (0) 
  8. Anil Murthy

    Hi Boris,

    I opened a ticket under BC-UPG-TLS-TLA and have been going back and forth with SAP. They are saying that there is no pilot anymore and I was referred to the standard DMO note 2161397. Can you please help us with this. I can provide the message number.

    Regards,

    Anil

    (0) 
    1. Ronald Halmen

      Hi Anil,

      apparently, the processor of your incident is not familiar with the procedure that enables you to take advantage of the “Downtime Optimized Database Migration Option” of SUM. Please send the incident back and ask for forwarding it to the Development Support level. It’s not SAP note 2161397 but 2005472 that needs to be considered in your case.

      Hope this helps,

      Ronald

      (0) 
      1. Anil Murthy

        Thanks Ronald…I just sent back the incident and asked the processor to forward it to Development support. Will let you know how it goes.

        Regards,

        Anil

        (0) 
  9. Robert Kundrat

    Hello,

    Could you please clarify for us if the near zero downtime offering for HANA migration  from SAP and the downtime-minimized DMO described here are two different scenario.

    Thanks,

    Robert

    (0) 
    1. Boris Rubarth Post author

      Hello Robert,

      not sure what you are referring to as “near zero downtime offering for HANA migration” – is it the nZDT service offering?

      Anyway these are two different technologies.

      Regards, Boris

      (0) 
  10. Ming Wei

    Hi Boris, I opened an mesg126683 in BC-UPG-TLS-TLA regarding the pilot of downtime optimized DMO, and attached all the info from our last normal DMO run in POC HANA. still no response from support. Is this the right queue?

    Thanks

    Ming

    (0) 
    1. rajdeep sarma

      Hello Boris,

      we have ran more 4 migration iterations for DMO run on a 20 TB ECC 6 EHP6 oracle system migrating to HANA.

      We have observed very poor performance during the first 12 hours of the migration where just around 2 TB of the data gets migrated from EUMIGRATEDT.logs. In the next 30 hours or so we get around 700 GB/hour throughput.

      We have tried many different options for optimize the migration , i.e. increasing /decreasing the table split options during split and increasing /decreasing the number of R3load processes during migration but that is not helping the speed up of the migration. We have observed the during this first 12 hours the CPU IO on the oracle DB server is always more than 60% and we have observed more than 100 blocked processes in SAR output.

      Keeping all these in mind, we want to explore possibility of migrating APP tables during uptime during this method the blog provides.

      Before opening the massage with SAP, I have a few questions for Borris

      1. My understanding is that this pilot service to analyze the tables by SAP development support is free of cost ?

      2. How much time does the SAP development support takes to get engaged  to analyzie our scenario and recommend solutions around tables which can be migrated online.

      3. After development support provides recommendation, is there any further involvement for SAP professional services during the rest of the project duration.

      Regards,

      Rajdeep

      (0) 
      1. Boris Rubarth Post author

        Hello Rajdeep,

        thanks for your question. I’d like to take this opportunity to clearify some aspects.

        1. This is not a pilot service, it is a feature that is piloted. The participation is not free of costs, as SAP colleagues from consulting and/or Active Global Support will have to be involved and will have to be paid by the customer.

        2. This is a program to pilot a feature, it is not a service to analyze your scenario. The time for the project depends on the scope of the project, like involved systems, number of iterations, …

        3. The involvement of the SAP colleagues is throughout the complete project, not just during a kind of analysis phase.

        My recommendation is to analyze your scenario thouroughly, and of course I can recommend to involve SAP colleagues for this. But this is not bound to the “downtime optimized DMO” feature.

        Regards, Boris

        (0) 
    1. Boris Rubarth Post author

      Hi Yoh,

      we do have plans to reduce the downtime of a system conversion to SAP S/4HANA: it is called “downtime optimized Data Conversion”. The idea is similar: do more during uptime to have less downtime. Technically it is a bit different, and more ambigious. I will try to post more on that soon.

      Regards, Boris

      (0) 
  11. Maurizio Grassi

    Hello Boris,

    thanks for this article. It gives a very good introduction about this topic. I still see the note as not released and no other articles regarding this. Is this still valid? What is the status now for downtime optimized DMO?
    I have found note 2153242 – Estimation of table sizes and downtime for SUM DMO with SLT  that gives a sort of starting point but nothing more.
    Thanks

    Martino

    (0) 
    1. Boris Rubarth Post author

      Hello Maurizio,
      thank you for the feedback.
      The status is still as mentioned: currently we do not accept further pilots due to the existing work load. I’d be glad to start with new pilots begin of next year, and will update the blog accordingly, so stay tuned.
      Regards, Boris

      (0) 
      1. Ambarish Satarkar

        Hi Boris,

         

        We are eagerly waiting for optimised dmo to be generally available.  This will help many SAP customers to avoid longer downtime for hana migration of production environments.

         

        Thanks,

        Ambarish

         

         

        (0) 
  12. Ambarish Satarkar

    Halllo Boris,

    We tried using UPGANA.xml file from previous DMO runs for ECC EHP6 upgrade and migration to EHP7 on HANA. SUM we used was SUM 1.0 SP17 PL8.

    When we provided UPGANA.xml in sapup_add.par file in /usr/sap/<SID>/SUM/abap/bin/ it was not accepted by SUM tool.

    We received below error in phase – MAIN_SHDIMP/SUBMOD_MIG_PREPARE/EU_CLONE_MIG_UT_PRP as follows –

    Illegal top level tag analysis in ‘/usr/sap/<SID>/Download_DIR/UPGANA.xml’ – expected ‘Clone durations’ .

    Can you please help on this?

    Thanks,

    Ambarish

     

    (0) 
    1. Boris Rubarth Post author

      Hello Ambarish,

      you can provide the UPGANA.XML file from a previous run by simply putting it into the download folder. If the error persists, please create an incident on component BC-UPG-TLS-TLA.

      Thanks, Boris

      (0) 
      1. Ambarish Satarkar

        Hi Boris,

        Files were copied to the download folder however we received same error for each run.

        We tried reusing UPGANA.xml from 3-4 mock runs and every time same error.

        Also we reused these files for same system with same SID.

        “MIGRATE_UT_DUR.XML & MIGRATE_DT_DUR.XML” were taken successfully by SUM tool.

        Problem as mentioned above occurred for “UPGANA.XML” file only.

        Could difference in DB size or table growth be the reason behind this?

        Thanks,
        Ambarish

        (0) 
        1. Boris Rubarth Post author

          Hi Ambarish,

          there is no need to use SAPup_add.par for both the duration files or the UPGANA.XML, as SUM will consider these automatically if found in the download folder.

          Regards, Boris

          (0) 
    1. Boris Rubarth Post author

       

      Hi Nicholas,

      thanks for asking: SAP BW is not supported for “downtime optimized DMO”. For SAP BW, the Delta Queue Cloning is the approach to optimize the downtime. We will have to adapt the slide in the referenced picture.

      Regards, Boris

      (0) 
    1. Boris Rubarth Post author

      Hi Suresh,

      thanks for asking. I have updated the blog now. The procedure is not GA.

      We accept a limited number of additional projects, as mentioned in the blog.

      Regards, Boris

      (0) 
  13. Nicholas Chang

    Hi Boris,

    Since DMO is not supporting Unicode Conversion, does Downtime Optimize DMO work on non-unicode source too?

    Thanks,

    Nicholas Chang

     

     

    (0) 
    1. Boris Rubarth Post author

      Hi Nicholas,
      hope it is OK if I adapt your statement:
      DMO is able to cover the Unicode Conversion, but not for target systems based on 7.50 and higher.
      Concerning “downtime optimized DMO”, one of the requirements is that the target system is based on 7.50 or higher. Yes, the conclusion is that “downtime optimized DMO” requires a Unicode source system.
      Regards, Boris

      (0) 
  14. Nicholas Chang

    Hi Boris,

    after revisited note 2377305 – Database Migration Option (DMO) of SUM 1.0 SP20, source non-unicode system can be converted, upgraded and migrated using DMO as long as the target release is <750

    Only if the target is >= 750, source system need to be on unicode.

    And noticed from 2442926 – Prerequisites and Restrictions of downtime-optimized DMO, allowed target release for downtime optimize DMO was changed to 750 or higher, previously i believe 7.40 was supported.

    Correct me if i’m wrong.

    Cheers,

    Thanks,

    Nicholas Chang

    (0) 

Leave a Reply