Skip to Content
Technical Articles
Author's profile photo Boris Rubarth

SUM: introduction to shadow system

Read this blog to get a simple introduction into the shadow system usage that the Software Update Manager (SUM) offers for the maintenance of ABAP-based SAP systems. You should be familiar with the general concept of the SUM, described in the blog Software Update Manager (SUM): introducing the tool for software maintenance

The goal of this blog is to explain the usage of a shadow system during the maintenance of ABAP based systems. This is in close correlation of the preconfiguration mode which is set in a SUM dialog during the configuration of a maintenance:

/wp-content/uploads/2014/04/preconfiguration_mode_option_417868.jpg

Comparing system maintenance with updating a house

If you want to renovate the house you live in, you may have a period of time during which the usage of the house is not possible.

/wp-content/uploads/2014/04/maintenance_without_shadow_418163.jpg

The “downtime” of the house may be long. And after the renovation has started, there is no easy reset to the initial state of your house.

Advantage is that you do not need additional resources for a shadow house (see below).

Now if you want to reduce the downtime in which you have no house available (imagine all your familiy members living in one tent instead …) you may consider to use a shadow house for your renovation/maintenance. Before starting the renovation, you create the shadow house, and then conduct the changes on the shadow house, while still living in your initial house. Once the renovation is done, you have only a short period of downtime for the move into the new house.

Using the shadow means

  • short downtime (only for the move)
  • simple reset possible (skip the move)
  • additional resources required: area and workers for shadow

/wp-content/uploads/2014/04/maintenance_with_shadow_418164.jpg

There are two different ways to create the shadow: either you copy your (customized) house, or you create a new house from blueprint.

Explaining the shadow system

A shadow (SHD) system can be used by SUM during system maintenance (or update) parallel to the existing ABAP system.

A shadow system uses the same system-ID as the original system, but has a separate instance (shadow instance, own instance number) and a separate repository (shadow repository).

/wp-content/uploads/2014/04/shadow_system_418165.jpg

ℹ An instance combines some processes on OS level (like work processes, gateway, dispatcher, …) that can be started and stopped together. It is somtetimes also called application server (software view).

ℹ The ABAP repository is a specific part of the database and consists of all development objects like programs, classes, database table definitions, and so on.

The shadow repository contains selected tables: basis tables, some customizing tables, but no application tables. The advantage is that the shadow instance is working on the shadow repository to update these tables to the new software level (target release) already during uptime processing so that the downtime processing is faster.

ℹ Uptime processing is the time during which the SUM is already preparing the update of the system, but the system is still available for end users to change data.

The shadow system has the advantage that the downtime is reduced, but you have to consider additional resources: memory on the application server for running the additional instance, and space on the database for the additional tables of the shadow repository. (Remember that the repository is typically only a very small part of the database content, and it is independent on the total DB size.)

The work on the shadow repository makes it necessary to prohibit changes on the original repository. That is why transport and development of ABAP objects are forbidden once the creation of the shadow repository started..

When and how a shadow system is used

If you now think that the preconfiguration mode Single System (see first figure above) means that no shadow system is being used, you may or may not be correct, as this depends on the type of system maintenace you are executing (explained below). All we can say right now is that both preconfiguration mode Standard and Advanced do use the shadow system.

Remember the two possibilities above to create the shadow house: “copy your house, or create from blueprint”?

For system maintenance, this is equivalent to the difference between update and upgrade:

An upgrade

  • is a release change (like SAP ERP 5.0 to 6.0)
  • creates the shadow repository from DVD

An update

  • is an implementation of EHP or SPs (like SAP ERP 6.0 EHP3 -> EHP7)
  • creates the shadow repository from the existing repository

     ❗ Note that the path to SAP ECC 6.0 EHP 8 is an upgrade path! See Why EHP 8 is different

     ℹ Note that in the documentation, we just say update for all scenarios, like the name of SUM contains only update as the general term.

Single System Mode

If you choose single system mode in the preconfiguration mode (see first screenshot above), this means:

  • An update (implementing SPs or EHPs) does not create or use a shadow system at all
    This maintenance type is sometimes also referred to as “transport like”
  • An upgrade (release change) creates a shadow repository (from DVD) and a shadow instance, but the original instance is stopped as long as the shadow instance works on the shadow repository; only a single system (instance) is running at a time -> “Single System Mode”
    Note:
    with SUM 2.0 SP 07 and higher, the single system mode is no longer offered for upgrades.

Single System Mode is sometimes also referred to as resource-minimized mode, as only few additional resources are required. On the other hand, the Standard and the Advanced Mode are both referred to as downtime-minimized mode, as only they offer downtime minimization. After handling the preconfiguration mode dialog (first screenshot above), the next dialog “Parameters for procedure” allows setting the number of processes, and it lists the mode as resource or downtime minimized (e.g. “The tool uses strategy Downtime-minimized.”).

Difference between Standard and Advanced Mode

  • Both use a shadow system to minimize the downtime
  • Choosing Advanced Mode sets the default parameters for the number of processes to higher values
    (which could be achieved manually with Standard Mode as well)
  • But only the Advanced Mode offers the option near Zero Downtime Maintenance (nZDM),
    as described in the following blog Near-Zero Downtime Maintenance for SAP Business Suite Systems
    Note:
    with SUM 2.0 SP 06 and higher, nZDM can be chosen on an earlier SUM dialog, and is independent on the choice of advanced mode, see blog
    https://blogs.sap.com/2019/10/02/new-dialog-sequence-with-sum-2.0-sp-06/
  • Further differences go beyond the scope of this introduction

Assigned Tags

      44 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Thanks Boris, great as always. Would you care to share additional details on what exactly happens and when with the shadow system. Especially useful would be to know how data is imported and activated in the shadow system which is then switched to become the target system. Another useful piece of information would be when is the last point transports can be imported into the source system so that they will be included in the shadow or rather the target system. See this discussion thread for details.

      Author's profile photo Gaurav Rana
      Gaurav Rana

      Thanks Boris,for sharing such a nice document with us.

      Author's profile photo Ashok Babu Kumili
      Ashok Babu Kumili

      Hello Borris,

      Great blog with lot of information. thank you.

      Author's profile photo Sourabh Chordiya
      Sourabh Chordiya

      Great explanation with comparison to real life simple scenerio, this clarifies a lot of basic doubts

      Author's profile photo Kumar Avi
      Kumar Avi

      Very good explanation.... SUM is simplified 🙂 .

      Author's profile photo Vladimir Kogan
      Vladimir Kogan

      Than you . Just one question.  Is it possible in easy way to move the shadow instance to the specific application server? When upgrading production system users works usual, when shadows activation take place. Running shadow on dedicated sever can decrease the performance impact.

      I dint see this function in SUM, I cannot even select the instance number for shadow,

      Thank you

      Regards

      Vladimir Kogan

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Vladimir,

      see SUM guide, section 3.8 "Preconfiguration Mode Planning", option "Switch expert mode on": this option will offer the usage of a remote shadow instance.

      Regards, Boris

      Author's profile photo Vladimir Kogan
      Vladimir Kogan

      Yes. I found it.

      But one pint is still unclear.

      Let's assume I have 3 serves:  CI AP1 AP2.  I am running SUM on CI, and habve a new clean server AP3 for Shadow Instance only. Do I need to install a dialog instance at AP3 before the upgrade, or SUM can install the files structure /usr/sap and all services remotely?

      Regards

      Vladimir

      Author's profile photo Wipro Basis team
      Wipro Basis team

      We can install shadow instance either on existing dialog instance (AP1 and AP2) or on new server (AP3).

      Please find the below prerequisites for installing remote shadow instance:

      Applicable for Shadow Instance server:

      • The remote shadow instance can be installed on an existing Dialog instance server or any new server
      • If it is an existing dialog instance server, then we have to stop the dialog instance throughout the upgrade. After the upgrade, the instance can be used as usual.
      • If it is a new server, then we have to explicitly install Dialog instance manually before starting the upgrade. The instance Number should not be equal to Central instance number.
      • On the shadow instance host, enter the message server port of the shadow instance in the services file
        sapmsSHD<SAPSID>  36<instance number of SHD instance>/tcp
      • Install additional libraries by executing R3dllins.exe program is in the UM<U/N>_WINDOWS_<Platform>\DBINDEP\NTPATCH directory on the Upgrade Master DVD
      • Before upgrading to Release 7.01 or 7.10 and higher, you must execute the SAPMMC Installer instead of R3dllins
        • Patch - <DVD>\DATA_UNITS\K_710_UI_WINDOWS_<PROZESSOR>\DBINDEP\sapmmc<prozessor>u.msi.
        • SAP Note 1480785 contains much information
      • For the upgrade or update target release 7.01 or 7.10 and higher, install the C runtime manually on the host of the shadow instance
        • 684106 contains more information about this

      Applicable for Central Instance Host:

      • Share the folder /usr/sap/<SID>/SUM/abap as SHARE_PUT – provide full permissions for for SAP_>SID>_GlobalAdmin
      • Update the services of Central Instance server with below entries

      sapmsSHD<SID>  36<instance number of SHD instance>/tcp
      sapdp<instance number of SHD instance>  32<instance number of SHD instance>/tcp
      sapgw<instance number of SHD instance>   32<instance number of SHD instance>/tcp

      Author's profile photo Christopher Arias
      Christopher Arias

      Great!

      Author's profile photo MARCO BAIOCCO
      MARCO BAIOCCO

      Hi Boris, I have a question.

      You say that only _some_ customizing tables are cloned to the shadow instance.

      What is the criteria for selecting which table gets cloned and which not?

      What about, in particular, for customer created customizing tables?

      Thanks

      Author's profile photo Sourabh Chordiya
      Sourabh Chordiya

      Hi Marco,

      Only the customizing tables that will undergo a change in structure with upgrade are cloned to shadow instance in addition to mandatory basis tables which are required to keep shadow instance operational.

      Note that in addition the application tables are also copied to shadow instance in case you go for nZDM approach, the application tables in this case receive data via replication from primary instance to reduce the time consumed during downtime for switching/upgrading structure of shadow tables

      Author's profile photo MARCO BAIOCCO
      MARCO BAIOCCO

      Thank you so much for your info!

      Author's profile photo Mohomad Swalay
      Mohomad Swalay

      Hi,

      Such a useful document.

      Thanks.

      Rgds/Swalay

      Author's profile photo Former Member
      Former Member

      Great article. Thank you for sharing this information Boris!

      Gurbir

      Author's profile photo Roberto Hugo Hernandez Cardenas
      Roberto Hugo Hernandez Cardenas

      Hi Boris

      Great explanation, this should be included in the sum guides to get a better picture of preconfiguration system mode.

      Author's profile photo Former Member
      Former Member

      Hi Boris,

      Great explanation.if it is possible can you post in depth explanation on shadow system.

      means how upgrade will happen and all...

      Author's profile photo Former Member
      Former Member

      Hi Boris,

      That is very clear and a wonderful explanation on the upgrade/update process. Quick question on what happens to the original tables (non-upgraded) that were used for on-going operations once the system is switched to newer version. To be more clear - the REPO that was used for on-going production operations before the switch, do that tables get deleted or they still remain in DB? Thanks.

      Regards,

      Kalyan

      Author's profile photo David Anton Arias Garcia
      David Anton Arias Garcia

      Hi,

      Good job, great blog.

      What would happen if you choose different 'preconfiguration modes' in each upgrade cycles? For instance, 'single system' during cycle 1 and 'standard' during cycle 2 and go live. Would it have any effect on the upgrade?

      Regards.

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Arias,

      not sure what you mean with "any effect on the upgrade" - sure it will have an effect on the upgrade: the procedure will behave differently. In general, you should always use the same configuration for testing and for go-live.

      Regards, Boris

      Author's profile photo Ashish Kasat
      Ashish Kasat

      Thank you Boris, for sharing this useful information with us.

      Author's profile photo Sunil Meti
      Sunil Meti

      Hi Boris,

      Good summary. Cleared few doubts.

      Author's profile photo Former Member
      Former Member

      Hi Boris,

       

      Great Article and simple to comprehend.  Can you please furthur explain on what happens in the shadow instance. I mean, the customizing tables and basis related tables are imported into the shadow instance and while going for the nDMZ preconfiguration mode, even some of the application tables are loaded in the shadow repository. But my question is, whether it will require more space on the server. Say for example, if my source DB occupies 5 TB of space, do i need 5 TB more space on the server just for my shadow instance or a letter less maybe 3 TB more for my basis tables and customizing tables?

      Regards,

      Vishwanath B

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Vishwanath,
      for nZDM, please check the blog FAQ of near-Zero Downtime Maintenance for SAP Business Suite Systems with question "How to verify the needed database disc space?" - much less is required.
      Regards, Boris

      Author's profile photo Nilesh Vangujar
      Nilesh Vangujar

      How to create shadow system? practially? please advise.

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      The SUM tool creates the shadow system, not you. Your choice about the preconfiguration mode (explained above) decides whether the tool creates a shadow system or not.

      Author's profile photo Max Silaev
      Max Silaev

      Hello Boris!

      I hope you can help me to understand the impact on SQL database after SUM reset. We had to reset and clean up our update process before downtime phase. The reset was a success according to the message in SUM. However, our database size was not reverted back to pre update state. It looks like tables copied during shadow instance creation stayed. What are the means to remove unnecessary copied objects to bring the size of files to pre-update state? Thank you in advance!

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hello Max,

      using the RESET functionality of SUM will cover all necessary steps. Not sure what exactly you observed, if in doubt you may have to create an incident.

      Regards, Boris

      Author's profile photo Daniel basis
      Daniel basis

      Hi Boris,

      Is online replication happening in standard mode also?..

      Can it be monitored in the shadow instance and possible to initiate manually before the downtime if it does not happen?

      Thanks in advance..

       

       

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Daniel,

      sorry to say that I do not know what "online replication" is in this context.

      Regards, Boris

      Author's profile photo Bobby Gunawan
      Bobby Gunawan

      Hi Boris,

      For conversion to S/4HANA release prior to 1909, shadow system will still be created and built from DVD repository for release target version on the source database, before moving it to DB target host later on the process.

      If my source RDBMS is Oracle, does it mean SUM will first install HANA DB software along with S/4HANA product on the source database for the shadow repo?

      Author's profile photo Reagan Benjamin
      Reagan Benjamin

      Check blog - https://blogs.sap.com/2019/09/09/dmo-shadow-repository-on-target-database-for-conversion-to-sap-s4hana-1909/

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Bobby,
      in addition to the link that Reagan has already provided (thanks!), let me explain that SUM is not installing SAP HANA database software, and it is not installing any database software. SUM is just using the existing databases: source database (if source system is not running on SAP HANA), and target SAP HANA database.
      As explained in this blog, the shadow system consists of a shadow instance (executables, part of SAP KERNEL), and the shadow repository. As you state, if the targeted SAP S/4HANA release is prior to 1909, the current SUM is creating the shadow repository on the source database, in your case on Oracle - but this action is not related to SAP HANA database software.
      Regards, Boris

      Author's profile photo Bobby Gunawan
      Bobby Gunawan

      Hi Reagan,

      Thanks for the link. That article was actually the basis of my doubt, which I’ll mention below.
      It makes sense to me on S/4HANA 1909, when target repo is created in HANA DB.

       

      Hi Boris,

      Shadow repository is built from the clone of source REPO (in my example: ECC), and converted to target release with conversion/upgrade export (in my example, target release: S/4HANA). You verified this in your blog:

      The shadow repository exists on target product version level.

      I have no doubt about shadow repo until S/4HANA release, or specifically until you mentioned that starting with S/4HANA1909, Shadow REPO will be created in HANA DB instead of source RDBMS.

      So when I saw your last picture above, it made me wonder: How could S/4HANA REPO prior to 1909 live on a non-HANA DB structure.

      Also you mentioned that the shadow instance is based on the shadow kernel, which is the new kernel (new SAP release) for the old (source) database –> What is the new SAP release for Oracle DB equivalent to S/4HANA?

      Thanks,

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author
      Hi Bobby,
      thanks for asking. I am afraid you expect the shadow repository to be fully equivalent to a standard repository, which is not the case. Sorry that my simplified overview led to this impression.
      The shadow repository does not contain application table content, and - more technically - the shadow repository does not even have the application table definition on database level (database objects), only on the dictionary level (runtime objects). So there is no "new SAP release for Oracle DB equivalent to S/4HANA".
      Another minor comment on your sentence "Shadow repository is built from the clone of source REPO" - for a system conversion to SAP S/4HANA, the repository is not created from the source system but from the export delivered by SAP (load procedure, see SAP note 2318321).
      Regards, Boris
      Author's profile photo Bobby Gunawan
      Bobby Gunawan

      Hi Boris,

      Thanks for explaining.

      This line from SUM guide made me expect that it is built from the source REPO and adjusted by the conversion export/customer modification:

      The SUM builds up the shadow system by cloning parts of the original system.

      As for shadow kernel, you mentioned that SAP S/4HANA 1909 uses SAP kernel 7.77, which works exclusively with SAP HANA as database. So that's why REPO will always be created in target HANA host. 

      But I can still download database dependent kernel 7.77 for any DB.

      Regards,

       

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author
      Hi Bobby,
      thanks again for asking.
      Concerning the guide: yes, we can be more specific here - the statement in the guide generally speaks about the shadow system, not specific about the shadow repository.
      And concerning kernel 7.77: yes, this Kernel is available for non-HANA databases as well, but only to support secondary database connections. The primary connection works with SAP HANA exclusively.
      Regards, Boris
      Author's profile photo Bobby Gunawan
      Bobby Gunawan

      Hi Boris,

      Thank you for taking your time to explain how it works.

      Regards,

      Author's profile photo Sethupathii Sekar
      Sethupathii Sekar

      Thanks for clear explanation with perfect example!

       

      Regards

      Sethupathii S

      Author's profile photo C. Technical SAP Basis Support
      C. Technical SAP Basis Support

      kindly can someone comment in which step the kernel switch happens inside the execution phase

      Author's profile photo Subhradeep Saha
      Subhradeep Saha

      Hello Everyone,

       

      I just have a small doubt, So once the shadow instance gets created during the SUM process. If we come across any error where it mentions few inactive objects are still present in the system.

      where do we make the change(activate/delete assuming it is z* object which can also be deleted) on Shadow system(000 client) or Original system(100 - working client)?

      I would really appreciate the help on clarifying this doubt.

       

      Thanks,
      Subhradeep

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hello Subhradeep,

      you will do the change on the original instance, not on the shadow instance.

      Regards, Boris

      Author's profile photo Subhradeep Saha
      Subhradeep Saha

      Hi Boris,

       

      Thanks for your valuable information.

      However from the second "Maintenance with shadow" screenshot that you shared it seems the changes need to be done in the shadow system only.

      And in one of the upgrade where i was working SUM stopped in ACT_UPG phase due to the presence of some inactive Z* objects in the system and once i deleted them from Shadow then only those objects got removed from that SUM error.(even though they are still present on the original instance)

      So, i am bit confused here. Could you please clarify?

       

      Thanks,
      Subhradeep

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hello Subhradeep,

      I can't comment on the experience that you report. Just on the screenshot (rather: illustration) "Maintenance with shadow": this is a simplified view that can't explain all aspects.

      Regards, Boris