March 16, 2017 6 minute read

SAP HANA TDI Migration from M-Node to N-Node

Purpose
System Privileges
How to Perform a Backup
Manual Backup Check
Prereqs before Recovery
Recovery
Monitoring redistribution
Related Documents
Related SAP Notes/KBAs
Common Questions
knows issues and fixes
Tips

Purpose

This Document is to explain the steps on how to perform a TDI Migration of HANA Database from a HANA M servers appliance to HANA N servers appliance.

Environment where this TDI steps are performed.

source version

System Privileges

to perform backup and restore the user must have the following roles

BACKUP ADMIN or BACKUP OPERATOR

How to Perform a Backup.

Please refer to the detailed document on how to perform a backup for HANA database using hana studio click here ⇓

Backup verification

you can use following options to verify the backup hdbbackupcheck -v <Backup file> hdbbackupcheck -i <Backup id>

Restore

For M – N restore it is important to make a note of the number of nodes and number server services configured on the source system, most of these servers services has its own persistence are, which must be available on the target system for successful restore.

From the following Landscape/hosts tab of hana studio you can see it is a 8 nodes appliance.

and from the following Volumes tab you can see the number of services with persistence.

Target is install with new revision (it can be higher than the source version), here it is installed with version 12.05

Prereqs before Recovery

stop any SLT replication
stop any database replication to secondary locations.
disable if server reboots or server patching is scheduled.
get ready with the license ( you still have temporary license )
Get the required SSL/and SAML keys ready before go live.
Make sure you have the same number of server services available on target ascompare to source.

here you need one more index servers service to be created on target server. command to create additional index server service is

ALTER SYSTEM ALTER CONFIGURATION ('daemon.ini', 'host', '<hostname>') SET ('indexserver.c','instanceids') = '40' WITH RECONFIGURE;

we have choose instance id as 40, it can be anywhere from 40…42….44…..46… etc.,)

by default the index servers is created during the installation is registered with the port “34103” but the one we just created manually is registered with “34140”

after all the required servers services has been created on target server, now perform the restore.

For restore steps click here.⇓

you can see the restore process by node and by service , here you can see the restore status of the additional index server service.

This is will be status after completion of restore,

now it is required to remove the additional index server service create.

for that first we need to mark the respective index server service for removal.

call SYS.UPDATE_LANDSCAPE_CONFIGURATION('SET REMOVE','<hostname>:34940');

The above command will mark the index server for removal like in the below screen you can see it.

It is not yet started removing anything yet, if you are not comfortable at this moment to process with the process, you can undo it by executing the command .

call SYS.UPDATE_LANDSCAPE_CONFIGURATION('RESET REMOVE','<hostname>:34940');

now you have to execute the plan for the market index server service, command to generate the plan for removing the indexserver

call REORG_GENERATE(2,'')

here 2 is for redistribution. and then need to execute the generated plan for the index server service. and the command to execute the generated plan.

call REORG_EXECUTE(?)

Now you can see the following redistribution plan as started when you log go to Landscape –> Redistribution from HANA Studio.

and the respective service will be in status “REMOVING” once the above process/plan is finished you can remove the additional index server service completely from database with the command.

call SYS.UPDATE_LANDSCAPE_CONFIGURATION('EXECUTE REMOVE','<hostname>:34140');

during the removal process the active light will turn to yellow from green.

Final Status .

Monitoring redistribution

we need to make note of redistribution Plan ID to monitor the status, here it is 4

some monitoring statement

SELECT * FROM SYS.REORG_OVERVIEW;

SELECT * FROM SYS.REORG_PLAN;

SELECT * FROM SYS.REORG_STEPS WHERE REORG_ID = 4;

SELECT STATUS,COUNT * FROM SYS.REORG_STEPS WHERE REORG_ID = 4 group by STATUS;

Related SAP Notes/KBAs

2093572 – SAP HANA Migration from Multi-Node to Single-Node

1651055 – Scheduling SAP HANA Database Backups in Linux

2044438 – HANA: Backup fails for Out Of Memory error

2123153 – HANA Recovery Failing with “recovery strategy could not be determined”

1730932 – Using backup tools with Backint for HANA

1869119 – Checking backup with “hdbbackupcheck”

2372809 – Guideline for upgrading a SAP HANA 1.0 to SAP HANA 2.0 system

Common Questions

Q:- Can I restore the hana lower version backup to a higher version hana database.

A:- Yes it is possible, please refer point numer 44 in note 1948334 and 1642148 for Maintenance Revisions update Paths.

Q:- is it possible to mark multiple index server services to for removal at once.

A:- yes you can mark all removable index servers services for removal at once.

Q:- Can I use backup taken using backint for this process..

A:- yes, but make sure the backing is configured and ready for restore on target server.

knows issues and fixes

Error :- Could not execute ‘ALTER TABLE “SAP<SOD>”.”<BI table>” MOVE PARTITION 0 TO ‘<hostname>:<port>’ PHYSICAL’ in 22 ms 469 µs .

SAP DBTech JDBC: [2048]: column store error: fail to move index to location: [2999] : Could not find source UT container in objectInfos;object=SAP<SOD>”.”<BI table>”

Fix:- above errors will occur only if you are on BW on HANA Rev. 12.5 and below.

The root cause of these errors was due to incorrect handling of table that is not yet migrated to l2delta during move operation. They were reported SAP HANA programming errors in SPS12. the fixes would be delivered to our clients in Rev122.05 and schedule a system upgrade to HANA Rev122.05 and beyond to fix the errors.

Tips:-

If there is any purging or archiving has been performed on the HANA database before restoring it on to new Database, it is recommended to do restart of HANA database before taking the backup on source, because the every database reorganization is performed along with restart if parameters are enabled.
perform the restore during the non-peak hours as the restore would impact the network load and that may lead to delay in log backup of your other hana environments to NAS.

Be the first to leave a comment

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