For a customer I work for the current HANA hardware server did not have sufficient hardware capacity anymore.

In the past already hardware capacity was added to the physical server, this resulted in a HANA of 512 GB.

But now the memory of the server was fully used and there was a need for 1024 GB memory.

The switch over from the old to the new server is described in this document.

Basically the migration to the new HANA server is done via a backup/restore.

Difficult part was that this HANA server got its data from SAP ECC via a SAP SLT server.

So replication and database triggers should be taken into account when switching over.

The connections between the applications look like:

Appl Connections.JPG

The high level steps are:

  1. Suspend the replication on SAP SLT server
  2. Backup old SAP HANA server
  3. Stop the current / old SAP HANA server
  4. Move the backup files form HANA old to HANA new
  5. Install the exact same HANA software on the new HANA server
  6. Restore the backup on the new HANA server
  7. Perform technical test on new HANA server
  8. Adjust the HANA hostname and ip address in SLT
  9. Perform technical test on SLT server
  10. Replicate one small new table
  11. Turn on replication again on SLT for all tables
  12. Check if replication is going without issues
  13. Adjust the BO configuration for the HANA new server
  14. Perform technical tests on BO server and Portal
  15. Perform functional tests

Below the steps will be described in more detail.

1. Suspend the replication on SAP SLT server

Suspend the replication on SAP SLT server for all the tables in HANA Studio > Data Provisioning

HANA studio stop replication.jpg

HANA studio stop replication2.jpg

After this, stop the load jobs.

SAP transaction LTR on SLT server.

Then click on the schema name.

transaction_LTR.jpg

In “jobs and connections” choose for STOP

2. Backup old SAP HANA server

Perform a manual back up via the HANA studio.

Right click on the HANA system in the left side pane and choose backup.

Backup.JPG

3. Stop the current / old SAP HANA server

Use the normal stop command via operating system as <sid>adm

4. Move the backup files form HANA old to HANA new

We used SFTP to copy the files.

5. Install the exact same HANA software on the new HANA server

We will not go into detail of this as this document focuses on the move and not on the installation itself.

See HANA installation manual for more details.

6. Restore the backup on the new HANA server

Perform a manual restore via the HANA studio.

Right click on the HANA system in the left side pane and choose recover.

It will ask to stop the HANA database.

After this the recover wizard will start

Restore.JPG

Choose destination type is File.

And specify the backup location.

At the end of the restore we installed a valid license key so that HANA is started without issues.

7. Perform technical test on new HANA server

Check running services from HANA studio > Administration Console

Hana studio check services.jpg

And also from this screen check alerts-tab.

Check users in HANA studio

Right click on the HANA system in the left side pane and choose Security > Users

Check the existing tables from HANA studio

Right click on the HANA system in the left side pane and choose Catalog > <Schemaname> > Tables

8. Adjust the HANA hostname and ip address in SLT

Check on SLT server via transaction LTRC (IUUC_SYNC_MON) > Expert functions > Additional functions

Change settings for connection to target system

LTRC change hostname.jpg

LTRC change hostname2.jpg

9. Perform technical test on the SLT server

Check on SLT server if the hostname is changed via transaction LTR.

transaction_LTR.jpg

transaction_LTR_after.jpg

In our case the new hostname was not shown correctly!

We created an OSS call for this and it turned out that the change was successful but that this screen was not updated successfully. SAP will create a new OSS note to solve this issue in the future. But it was just a display issue and the change of the hostname was successful.

To be sure the change is successful check the content of table DBCON on the SLT server. The new hostname should be there.

10. Replicate one small new table

We first wanted to test a small new table before we turned on replication for the old tables.

In HANA Studio > Data Provisioning we added a small new table.

The replication was started normally without issues.

The log table and database trigger was created and entries were moved via SLT server to HANA.

11. Turn on replication again on SLT for all tables

In step 1 we suspended the replication of tables.

No we turn it on again.

This is done again from HANA Studio > Data Provisioning

12. Check if replication is going without issues

Start on SLT server transaction transaction LTRC (IUUC_SYNC_MON)

Check the Table Overview, Data Transfer Monitor and Application Logs

13. Adjust the BO configuration for the HANA new server

The BO server is connected to the HANA server.

On two places we need to adjust configuration settings to the new hostname.

First in the CMC

In CMC > Applications and right click on Explorer > Properties.

(I removed the actual details like user/pw)

BO change host CMC.jpg

Second in the Information Design Tool (client tool) the connection to HANA can be altered.

BO change host IDT.jpg

The new connection(s) can be tested and after wards published.

14. Perform technical tests on BO server and Portal

This step is really customer specific.

For this customer we ran basic reports via the SAP portal. The reports were retrieved from SAP BO and this data was from HANA.

15. Perform functional tests

Also this step is customer specific.

The functional consultants and the users perform specific tests at this point.

Best regards,

Marco

To report this post you need to login first.

15 Comments

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

  1. Justin Molenaur

    Hi Marco, very nice writeup on this topic. I was looking into this for a client recently and came up with some similar steps.

    However, where I see a potential pain point in your outline is step 1 where you actually STOP the replication of existing tables. With your approach, you will be restoring previously replicated tables into HANA (via backup), and then having to completely reload (start replication again). Most customers with large volumes would likely not want to have to reload all the data again.

    Therefore, a proposal would be to stop the master job in SLT (not STOP replication of existing tables) for step 1. This way, the logging tables in the source system (say ECC) will continue to catch any changes to the already replicated tables, and just resume loading once the new instance comes up. You would follow the same steps for the remainder, just point SLT at the new instance for the delta data.

    I have not tested this, but seems like a valid way to avoid reloading large tables.

    Regards,

    Justin

    (0) 
    1. Justin Molenaur

      Now reading more into the details section, you are “resuming” data loads for existing tables. I was confused by your screenshot in step 1. I don’t think you need to perform any actions from the HANA side (STOP replication) at all.

      Your process would be to suspend/pause replication before stopping the SLT master job, and then once the new box came up, just resume.

      Regards,

      Justin

      (0) 
      1. M. Stitselaar Post author

        Hi Justin,

        You are correct the screenshot is confusing as the arrow is pointing tooSTOP instead of SUSPEND.

        It should be SUSPEND because we do not want to reload all HANA tables again (this would be days of work).

        For your information: we performed this procedure last weekend for this customer and it worked without any issue.

        Thanks I will adjust the picture,

        Regards,

        Marco

        (0) 
        1. Justin Molenaur

          Good deal. I would recommend removing the word STOP altogether from the checklist as it can cause a problem!

          Additionally, in theory it would be possible to avoid performing a suspend table by table, and just stopping the SLT master job.

          Another possibility for ease is to use the SLT interface LTRC to perform the suspend. You can perform a mass table suspend rather than one by one as done through studio.

          Again – great writeup.

          Regards,

          Justin

          (0) 
  2. Antony Jerald J

    Hi,

    Thanks for sharing the document.  It was really useful.

    Does it applicable to while moving from hana DB via SLT to suite on Hana,  Where Suite on hana doesn’t have SLT Server for replication?

    Regards,

    Antony Jerald.

    (0) 
    1. M. Stitselaar Post author

      Hi Anthony,

      This description is specifically for HANA when using an SLT server.

      This SLT server makes it a bit more difficult.

      When you have Suite on Hana, it is a bit different. The SLT system is not relevant for you.

      But you have to think about your Central Instance server. Does this also needs to move to new hardware or not.

      Regards, Marco

      (0) 
  3. Jerry Zhu

    Hi Marco, great blog! Just a side note: there is option to ‘scale out’ the HANA system by adding multiple nodes to exend the memory capacity.  In that case, you don’t need to copy the system and change the SLT configuration. Nevertheless I believe you have good reason too. Can you please share your thougths on your decision?

    (0) 
    1. M. Stitselaar Post author

      Hi Jerry,

      Sorry for the late reply (was on holiday 🙂 )

      Yes we thought of this option also. But scale out is not always possible (for example for BW on HANA it is OK but for Suite on HANA it is not allowed).

      In our case the hardware was already old and we did not want a HANA system of the same make/model/type and use it for scale out.

      Regards, Marco

      (0) 
  4. Mrutyumjai Kamana

    Hi All,

    Just considering a different approach to do the migration: How about setting up replication to the new hosts and then do a take over? Is this not recommended? If not, why?

    We can save a lot of time in taking a backup, copying the files, restoring the database again, etc.

    Thanks,

    Mrutyumjai

    (0) 

Leave a Reply