Switching over to new HANA hardware
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:
The high level steps are:
- Suspend the replication on SAP SLT server
- Backup old SAP HANA server
- Stop the current / old SAP HANA server
- Move the backup files form HANA old to HANA new
- Install the exact same HANA software on the new HANA server
- Restore the backup on the new HANA server
- Perform technical test on new HANA server
- Adjust the HANA hostname and ip address in SLT
- Perform technical test on SLT server
- Replicate one small new table
- Turn on replication again on SLT for all tables
- Check if replication is going without issues
- Adjust the BO configuration for the HANA new server
- Perform technical tests on BO server and Portal
- 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
After this, stop the load jobs.
SAP transaction LTR on SLT server.
Then click on the schema name.
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.
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
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
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
9. Perform technical test on the SLT server
Check on SLT server if the hostname is changed via transaction LTR.
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)
Second in the Information Design Tool (client tool) the connection to HANA can be altered.
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
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
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
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
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
Perfect suggestion. To eliminate confusion I replaced the stop-word.
Regards,
Marco
Great blog! thank you for sharing
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.
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
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?
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
Marco, that's a very practical reason I am aware of too. Thank you for your explaination.
Really a great document !!!
Nice work, thanks for the documentation!
Any issue in migrating to higher version. My understanding is backup and restore is forward compatible.
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