Skip to Content
Product Information

DMO: shadow repository on target database for conversion to SAP S/4HANA 1909

Abstract:

In some cases, SUM will create the shadow repository on the target database in the future.
This blog provides background information as well as the current status of this new approach.

Introducing the shadow system and shadow repository

The Software Update Manager (SUM) has several means to reduce the downtime of maintenance events like update/upgrade, database migration, or system conversion. One of these means is the shadow system.
A shadow system basically consists of a shadow instance and a shadow repository:
  • The shadow instance is an additional ABAP instance which is created by SUM on the application server on which the SUM was started. It is used to prepare steps executed during the downtime.
  • The shadow repository exists on target product version level. This means that the shadow instance must use the target kernel to create the shadow repository with potentially new object types.

The shadow system is alredy created and exists during uptime processing of SUM. As a consequence, the downtime is reduced.

[i] You can check this blog for an introduction to the shadow system, but this description does not yet cover the aspects discussed below.

Until now, SUM creates the shadow repository on the source database specifically for the migration scenarios Database Migration Option (DMO), and System Conversion to SAP S/4HANA for source systems with no SAP HANA database. (Note that non-migration scenarios have only one database, so that is no differentiation of source and target database is needed.)

This will change for a system conversion to SAP S/4HANA 1909 with SUM 2.0 SP 06 (general availability planned for mid of September 2019): SUM will create the shadow repository on the target database. (Again: This only applies if the source system is not yet on SAP HANA database and a database migration happens. Only then we have a source and a target database).

 

The figure illustrates:

  • SHD REP: the shadow repository
  • PAS: the primary application server
  • PRD REP: the current (productive) repository of the source system

SAP S/4HANA 1909 and the ABAP kernel

SAP S/4HANA 1909 uses SAP kernel 7.77. This kernel version is the first that works exclusively with SAP HANA as database. As the shadow instance must use the target kernel, it is obvious that the shadow instance for SAP S/4HANA 1909 can’t work with a database other than SAP HANA DB. That is the reason why SUM has to create the shadow repository on the target database for a migration scenario targeting SAP S/4HANA 1909.

No changes for SUM handling

If you have used SUM 2.0 for a system conversion before, you will not experience any difference in the dialogs concerning the shadow system handling with SUM 2.0 SP 06. So, there is no user choice or parameter on the shadow system creation – SUM will simply do what is required.

(There is a new dialog sequence introduced with SUM 2.0 SP 06 – described in an upcoming separate blog – but this is not related to the shadow system.)

Advantages for conversions to S/4HANA 1909

The shadow repository created on the source system was the reason for some migration requirements concerning the source database. As an example, Oracle 11.2 database on source systems had to be upgraded to version 12 prior to the conversion run (or NZDT had to be used). And in some cases, it was required to extend the tablespace of the source database to create shadow repository. These requirements are now obsolete, when the shadow repository is no longer created on the source database. Good news!

That was the easy part – now to the fine-print part of the story …

Additional aspects of the story

SUM 2.0 SP 06 is the first SP version of the tool that uses the shadow repository on the target database – but not for all possible cases. Let me clarify some aspects and typical questions:

These scenarios are planned to be supported in later SP versions of SUM 2.0.

Boris Rubarth
Product Manager SUM

12 Comments
You must be Logged on to comment or reply to a post.
  • Thanks Boris !! This is amazing, this cuts down lots of effort during source system preparation in a conversion project. On the other hand, DMO with system move is a restriction gives me a frown face. Can you please share a rationale for this?

     

    Regards,

    Prithivi Raj

    • Hi Prithivi,

      up to now, “DMO with system move” had created the shadow repository on the source system landscape. This is no longer possible, as we can’t assume to have a connection to the target (SAP HANA) database from the source landscape. The approach is more complex to be switched.

      Regards, Boris

  • Nice read, also for me as a non-basis person.

    So far, as an ABPAer, my contact with shadow instances is that during upgrade, there might be some  PARDIST_SHD DISTRIBUTION ERRORS, fellow basis-person will let me know,

    and I’ll AdT into the shadow instance to activate some CDS-views.

    Best
    Joachim

    • Hi Joachim,

      good part of the story is that connecting to the shadow system does not change. It uses the shadow instance, and their location does not change.

      Best, Boris

  • Thanks Boris. This is great feature indeed! since lots of customers has lesser resource on source system and you know source is going away, no sense to add resources… This is Amazing!!  Thank you again , Amit Lal

  • Hello Boris

     

    Thank you for a great blog.

    We are thinking of migrating to S4HANA/ Azure/ RHEL

    from ECC6.0 EHP6.0/Oracle 11.2/On-premise/RHEL.

     

    Reading youre previous blogs and sap notes, i know that for my above scenario, i need to use DMO with system move option and system update option.

    So if from SUM SP06, system move option is not supported (when SP06 is great creating the shadow rep on target), then we dont have choice to go like below??

     

    //Use SUM 2.0 SP05, go to S4HANA 1809 on Azure with system move option and afterwards update to 1909??

     

    Can we use normal DMO when going from onpremise to Azure cloud, so that we can use SUM 2.0 SP06??

     

    Regards

    • Hi Kotaro,

      thanks for your question.

      • yes, as you state “DMO with system move” is not applicable with SUM 2.0 SP 06 for target SAP S/4HANA 1909
      • yes, you may use SUM 2.0 SP 05 for DMO with system move targeting SAP S/4HANA 1809 on Azure (and do upgrade to 1909 then), but you may as well use SUM 2.0 SP 06 for that, as SP 06 supports DMO with system move if target is not S/4HANA 1909
      • No, plain DMO does not support a data center move or move to cloud (IAAS) as written in the respective SAP note for DMO

      Regards, Boris

      • Hello Boris,

        Thank you so much for an quick and informative reply!

        Understood about your reply!

         

        Btw, i heard when i was talking on the SAP expert chat that

        from SUM 2.0 SP06, the os of application server of the target system has to be supported for the target SAP release only according to PAM, not also the ap server of source system.

        Is it correct?

        • Hello Kotaro,

          sorry, I guess I did not yet understand your scenario.

          For a normal DMO scenario, the application server host remains, so there is no difference between AppServer of source and AppServer of target system.

          Regards, Boris

  • Hello Boris,

    In case of having HANA 1.0 on source system, will customers continue to have pre-requisite of updating HANA to a compatible DB version of S/4HANA Product (HANA 2.0), ahead of the Conversion Process?

    Can you kindly share if SAP is planning also to extend the possibility of having contemplated scenario below, with this new fancy feature?

     -> Source-> ECC 6.0 EHPxx running on HANA 1.0 SPS12

     -> Target-> S/4 HANA 1909 running on HANA 2.0 SPS4

     Kind Regards,

    Claudio Quina

    • Hi Claudio,

      thanks for asking – the requirement to start on SAP HANA 2.0 (if source is already on SAP HANA database) remains. The SUM never upgrades the source database software level, and this is true for SAP HANA db as well.

      Kind regards,

      Boris