For a BW on HANA Scale out proof of Concept that we recently worked on I would like to discuss the migration process and the issues we encountered and how we resolved or worked around them. This Blog is part two of a three part blog, you can find the first Blog called “BW on HANA scale out Migration Part 1: Preparation Checklist and known issues” here
Starting the GUI for the Software Provisioning Manager:
The OS for the BW application server was SUSE Linux 11.1. The SLES server build includes vncserver which is software to enable a virtual-desktop on Linux. You can use this software to start a GUI connection to the SWPM . A VNC session runs on the server so it can be disconnected/reconnected from the users laptop without interrupting the installation. In addition more than one person can connect and view what’s happening in a particular session. You can download TightVNC from the Internet – it is a single, lightweight executable.
Login to the HANA server using putty and type vncserver to start a new virtual desktop:
Multiple desktops can be started if more than one person is working on the machine. It can be left running after installation completes as a permanent desktop to use for any sapinst activity. Connect to the session using your vnc client:
Browse to the Directory that has the SWPM software and start using the command sapinst:
Initially I could not get the GUI to start and got the following error message:
The reason was that there were still some old sapinst processes running in the background. I could verify this by executing the command ps aux grep | sapinst at os level. I killed these processes using the KILL command:
Some times these problems with hanging processes happen if sapinst was not stopped correctly. The correct way to stop sapinst (to stop it completely, not only to close the GUI) is going to GUI and choose second menu option “SapInst” and then “Cancel”.
After doing this it was possible to run the command sapinst:
The Migration was done using the software provisioning manager version 1.0 SP02. First on the BW application server the ASCS Instance was installed, then the database instance (during this step the actual data is copied from export file to the HANA DB). The last step is to install the Primary application server instance.
DB Migration Import Performance:
For the Database Instance step we had Bad performance with the Import of the R/3 Load packages. This process took 120 hours. The main reason for this was poor I/O performance on one of the HANA nodes due to a Hardware problem with one of the scale out nodes where there was an issue with the RAID controller firmware version and the cache batteries. According to Development a runtime for the migration where the export and import are performed in parallel for an 8 TB system can be as low as 15 to 20 hours. Other factors that influenced the performance of the Import were : the kernel version we used did not have the MASSLOADER functionality (Kernel 721 has a mass loader that improves performance that kernel 720 does not have) and also there was room for more extensive table splitting. Even with the table splitting done there were a lot of R/3 Load packages with 100 million rows or more:
Errors Encountered with R/3 Load Packages:
Out of a total of 1,175 R3load Jobs there were 5 errors. Two of the errors indicated a resource problem during the Insert of the data and it was not clear what the root cause of the problem was. Without making any change the problem could be solved by using the retry button in the software provisioning manager and then the Jobs were successful.
The third error “invalid index name: column list already indexed” regarding the creation of an Index on a fact table could be ignored. “ERROR” status in TSK file set to “OK” and then used the retry button in the software provisioning manager.
The last error for two tables was rc=26. This means that a duplicate key error occurred. A possible cause might be the table does not have a primary key on the source system but now has one on the target system. The error was resolved by dropping the primary key on the two tables that had the error using the following SQL:
alter table ZHYTEST1 drop primary key
alter table “/BIC/4FSCO_C01F” drop primary key
I /BIC/4ESCO_C01F~P C ok
If you have some errors during the export/import or you need further help with tuning the performance of the migration process please refer to the best practice migration guide at the link below:
Stay tuned for Blog part 3 on the Post Migration steps for BW on HANA scaleout and the issues encountered 🙂