Skip to Content
Technical Articles

DMO, SAP HANA and the Target DB SID

I recently stumbled across the DMO dialog Database Migration Initialization for the parameters of the SAP HANA target database, and would like to share my experience with you on the parameter Target DB SID.

Note: readers should be familiar with Database Migration Option (DMO), as introduced with the blog https://blogs.sap.com/2013/11/29/database-migration-option-dmo-of-sum-introduction/.

So you know about DMO as migration scenario, and you understand that the SUM tool asks for the parameters of your SAP HANA target database. So what’s the point?

The point is the parameter Target DB SID, and its relation to the system-ID of the ABAP source system.

The SUM tool fills the field with the value of your ABAP source system (not shown in screenshot). Question is now if this value is valid – and the answer depends on whether your SAP HANA target database is a single container or is using MDC: multitenant database container. See blog for details on MDC: https://blogs.saphana.com/2015/01/27/sap-hana-multitenant-database-containers/

Note: SAP HANA 2.0 is always MDC.

So the approach is:

  • If your target is a single container:
    You do not keep the value, but instead have to specify the existing system-ID of your SAP HANA database.
    SUM uses host name and instance number to connect to the database, and then checks if the system-ID is correct. So if use any other value, the tool will throw an error Wrong SID.
  • If your target is MDC / SAP HANA 2.0:
    You do keep the proposed value, and SUM will create a new tenant with that name in your SAP HANA database.
    You may use other values, even existing tenant names.
  • If you run “DMO with system move” [aspect added on May 14 ’20, corrected on June 19 ’20]
    You do keep the proposed value You provide the existing SID of the existing SAP HANA database, and SUM will re-create the tenant (which was created during provisioning of target PAS) with that name in your SAP HANA database

Note: this is independent on whether you use SUM 1.0 or SUM 2.0 (see blog https://blogs.sap.com/2017/08/10/sum-in-the-family-way/).

/
14 Comments
You must be Logged on to comment or reply to a post.
  •  

    Hello Boris

    Further to the approach “If your target is a single container:”

    When using SUM DMO 1.0 SP21, one wants to use a different target SID when migrating SAP ABAP system from e.g. Oracle to HEC including EHP upgrade, source SID = QS1, target SID=PS1.  Is this achiveable by not selecting “System move” and using the SUM DMO – changing schema name parameter: SAPup_add.par “/migrate/targetschemasid=<VAL>”

    Thanks

    • Hi Jack,
      please do not mix up the SID of the ABAP system with the schema name on database level. DMO does not allow to change the SID of the ABAP system. You may consider to use SWPM with System-Rename-functionality.
      Regards, Boris
  • Good afternoon Boris,

    As I know that you are an Expert of DB Migration I have a short Question: We have our Solution Manager in one Tenant DB with 2 Schemas (sapabap1 and sapjava1).

    I would like to take the sapjava1 Part out of this DB and move to a separate Tenant. What is the best way to do this?

    Kind regards

    Christoph

    • Hi Christoph,

      well, DMO does not allow this, as it works on ABAP stack only, and does not support a homogenous migration (HANA to HANA). Let me check if system copy is an option …

      Kind regards, Boris

       

      • Thank you Boris, I’m curious

        When we upgraded from Solution Manager 7.1 to 7.2SP5 we kept both Systems (The ABAP and the JAVA Part) in the same Tenant Database, what makes it now complicated to create a sandbox System …

        have a good day!

        Christoph

         

        • Hi Christoph,

          from what I understand, you will have to do a split first, only then it is possible to use SWPM to move the java stack to a different tenant.

          Kind regards, Boris

           

  • Hi Boris,

    You mean the Schema SAPABAP1 and SAPJAVA1? How do I split the Tenant DB first ?

    (Solution Manager 7.2 has already the ABAP and JAVA Application Server seperated)

    Kind regards

    Christoph

     

     

     

     

  • Very helpful Article Boris, Thank you! Just quick question, what’s the recommendation on DB <SID> with Hana 2.0, Is it better to keep it different than SAP system ID in an distributed environment? Also if we keep same SID, then won’t it cause any issue with the license? I found SAP note 1953429, It suggests to keep the different SID. Are there any known issues / concerns with either approach?

    Thanks

    Pranav

    • Hi Pranav,

      What I see as relevant is described in the note 1953429 you have referenced, esp. different SIDs required in that case of “central installation”. I have no further experience on concerns or issues.

      Regards, Boris

  • Hi Boris,

    Thanks for the article.

    Currently we are in process of converting to S4Hana with SUM DMO.

    In phase PREP_CONFIGURATION/SUBMOD_MIG_CONFIG/HDB_MIG_CONFIG we have to enter input for Target DB Schema

    When we enter SAPABAP1 or SAPHANADB as schema and click next immediately target S4hana application system R3trans -d is getting error as authentication error.

     

    hdbuserstore list output of current hana application server is:

    S4QUAAPP:sidadm 66> hdbuserstore list
    DATA FILE : /home/sidadm/.hdb/S4QUAAPP/SSFS_HDB.DAT
    KEY FILE : /home/sidadm/.hdb/S4QUAAPP/SSFS_HDB.KEY
    KEY DEFAULT
    ENV : S4QUADB:30013
    USER: SAPHANADB
    DATABASE: SID

    Could you please update what could be the issue?

     

    Regards,

    Srinivas

    /
    • Hi Srinivas,

      I have no idea, so my recommendation is to check all logs carefully. You may have to create an incident.

      Regards, Boris